On Sun, Oct 28, 2018 at 09:46:43PM +0100, Noralf Trønnes wrote: > > Den 28.10.2018 21.21, skrev David Lechner: > > On 10/26/2018 05:38 PM, Noralf Trønnes wrote: > > > Den 17.10.2018 15.04, skrev Noralf Trønnes: > > > > This move makes tinydrm useful for more drivers. tinydrm doesn't need > > > > continuous memory, but at the time it was convenient to use the CMA > > > > library. The spi core can do dma on is_vmalloc() addresses making this > > > > possible. > > > > > > > > Cc: David Lechner <david@xxxxxxxxxxxxxx> > > > > Signed-off-by: Noralf Trønnes <noralf@xxxxxxxxxxx> > > > > Acked-by: David Lechner <david@xxxxxxxxxxxxxx> > > > > Tested-by: David Lechner <david@xxxxxxxxxxxxxx> > > > > --- > > > David, > > > FYI This series is scratched. > > > See the shmem helper patch thread for details. > > > > > Yes, I saw that. Thank you. > > > > I don't suppose there is a way to configure the DMA controller to do > > the byte swapping? > > > > Not that I know of. > "Proper" SPI hw can do 16-bit transfers and for them there's no problem. > The DMA capable SPI block on the Pi can only do 8-bit, hence the swapping. > > But that wasn't the problem, the byteswapping actually papered over the > problem. I'm no -mm expert so I don't know why the problem onyl showed > up when using the virtual address of the buffer used by fbcon and not on > mmap'ed fbdev as Daniel suggested would happen. Hm, I missed that detail. This sounds like one of the mappings ended up being write-combining (which avoids all the issues with dirty cpu cache lines), while the broken one was not. Or we ended up with a flush somewhere by accident. > Either way shmem not being coherent is a problem on the Pi, even though > I expected the DMA streaming API called by the spi core to flush "things". It should do that for you. At least if it's using dma_map/unmap_sg and friends. > The solution I'm aiming for is to make it easy for tinydrm drivers to use > the > buffer type they want, instead of having one type they all have to use. General recommendation for this is "less midlayer, more helper". Which was the goal of all this ... Oh well :-/ Maybe we can progress in other areas meanwhile. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
