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.