[PATCH 06/10] drm/tinydrm: Move tinydrm_spi_transfer()

Noralf Trønnes noralf at tronnes.org
Thu Jul 25 14:16:08 UTC 2019



Den 18.07.2019 14.14, skrev Noralf Trønnes:
> 
> 
> Den 17.07.2019 21.48, skrev David Lechner:
>> On 7/17/19 6:58 AM, Noralf Trønnes wrote:
>>> This is only used by mipi-dbi drivers so move it there.
>>>
>>> The reason this isn't moved to the SPI subsystem is that it will in a
>>> later patch pass a dummy rx buffer for SPI controllers that need this.
>>> Low memory boards (64MB) can run into a problem allocating such a "large"
>>> contiguous buffer on every transfer after a long up time.
>>> This leaves a very specific use case, so we'll keep the function here.
>>> mipi-dbi will first go through a refactoring though, before this will
>>> be done.
>>>
>>> Remove SPI todo entry now that we're done with the tinydrm.ko SPI code.
>>>
>>> Additionally move the mipi_dbi_spi_init() declaration to the other SPI
>>> functions.
>>>
>>> Cc: David Lechner <david at lechnology.com>
>>> Signed-off-by: Noralf Trønnes <noralf at tronnes.org>
>>> ---
>>
>> Acked-by: : David Lechner <david at lechnology.com>
>>
>> I assume that the comments here might have something to do with the
>> issue[1] I raised a while back? Should I dust that patch off and resend
>> it after this series lands?
>>
>> [1]:
>> https://lore.kernel.org/lkml/1519082461-32405-1-git-send-email-david@lechnology.com/
>>
> 
> Yep, that's the one. I want to refactor mipi-dbi first splitting struct
> mipi_dbi into an interface and display pipeline part. The helper is
> going to be moved to drivers/gpu/drm with the other helpers.
> Please wait until that is done, I want to see what kind of coupling I
> end up between the two structs and don't want another dependency to deal
> with if I can avoid it.
> 

I've applied the series now.

Do you have this problem only on the EV3 and with only one
display/driver? If so I'm wondering if there's a way to implement this
that doesn't affect the other drivers since you need a special use case
to be hit by this.

Noralf.


More information about the dri-devel mailing list