On 12/11/2017 07:37 AM, Noralf Trønnes wrote:
Den 11.12.2017 13.45, skrev Noralf Trønnes:
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?
The spi controller driver has told the spi core to allocate dummy
buffers for tx/rx: spi_sync -> __spi_pump_messages -> spi_map_msg
-> krealloc -> __do_krealloc -> kmalloc_track_caller
order:4 means it's trying to allocate 2^4*PAGE_SIZE = 64kB, which
probably is the max DMA limit. So this is a pixel data transfer.
On my Raspberry Pi I've got 43 chunks of 64kB available if I have
understood this right:
$ sudo cat /proc/buddyinfo
Node 0, zone Normal 40 68 66 51 43 46
13 1 3 3 75
I don't know what those dummy buffers are used for.
tinydrm has a spi_max module parameter that can set the chunk size.
I have wondered if I should just remove this parameter when spi-bcm2835
has been fixed as explained here:
https://lists.freedesktop.org/archives/dri-devel/2017-February/132725.html
I'm figuring it is better to add this parameter if the problem arises
again,
instead of preparing for something that might not be a problem anymore.
But now I'm reminded of this dummy buffer and if we were to send the entire
framebuffer in one go, the dummy buffer would have to be the same size as
the framebuffer. Not sure how well that works on long running boards with
little ram, to be able to allocate 320*480*2 = 300kB ~= 512kB (continous)
for the largest SPI displays on every flush, after months of run time.
How much ram do you have on the Lego module?
64MB
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
