tinydrm: page allocation failure

[David Lechner]

On 12/14/2017 01:55 PM, Noralf Trønnes wrote:
> 
> Den 14.12.2017 17.25, skrev David Lechner:
>> On 12/11/2017 06:45 AM, Noralf Trønnes wrote:
>>>
>>> Den 11.12.2017 04.28, skrev David Lechner:
>>>> I'm using drm-misc/drm-misc-next and occasionally getting errors as seen in the stack traces below. I'm not really sure what to make of it. Any ideas?
>>>>
>>
>> I'm starting to wonder if there is some sort of race condition involved. I only get this warning on some boots, but when I do, it happens multiple times. Also, when I was debugging a an unrelated problem, I enabled some of the spin lock checking kernel options that really slow down the kernel. When I did this, I got this warning all of the time.
>>
>> Would it be sensible to allocate a dummy RX buffer once instead of letting SPI allocate a new one for every transfer?
>>
> 
> I have looked at the code and the dummy buffer is needed by some
> drivers for DMA transfers. They need both tx and rx buffers to do the
> transfer. A solution might be to let tinydrm allocate a dummy rx buffer
> and attach it to every spi_transfer.
> 
> We could check if it's really needed:
> 
>      if (spi->controller->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX))
>          // allocate dummy rx buffer
> 
> And maybe something like this:
> 
> + * @dummy_rx_buf: Optional dummy rx buffer to avoid per transfer allocation of
> + *                dummy rx buffers in the spi core.
> 
>   int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
>                struct spi_transfer *header, u8 bpw, const void *buf,
> -             size_t len)
> +             size_t len, void dummy_rx_buf)
>   {
>       struct spi_transfer tr = {
>           .bits_per_word = bpw,
>           .speed_hz = speed_hz,
> +        .rx_buf = dummy_rx_buf,
>       };
> 
> Noralf.
> 

FWIW, the problem seems to go away if CONFIG_SWAP=y.

I also made the changes as suggested and it seems to be working for CONFIG_SWAP=n. Preventing constant reallocations seems like a good idea to me even when memory is not limited. I'll submit a patch after a bit more testing.