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

[David Lechner]

On 7/25/19 9:16 AM, Noralf Trønnes wrote:
> 
> 
> 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.
> 

I've let this sit running for several days and I don't see the error
any more. So perhaps something was fixed in the DMA driver? Or maybe
I just haven't seen the error because it is sitting idle and not under
heavy memory usage? (I just ran some apt commands that crashed because
of OOM and nothing happened with the display driver.)

Interestingly, I was getting a similar allocation error from zram
in the 5.2 kernel, usually triggered by starting a SSH session (totally
unrelated to DRM).

So, unless I start seeing the problem again, I think we can leave it
alone for now.