> But then you don't have the DMA chain linked. Which I wonder if the controller > has any problem with or not. I tried yesterday, got wrotes working perfectly, > but still had issues with reads, which is exactly what needs to be chained. Yes, the read needs chaining of two "DMA command blocks". That should be the only chain needed, because of how the driver handles reads. It is still one I2C message, though. > I'll poke further eventually. I really hope it works out! That would be great. > > Regarding Figure 27-10, the first I2C write command could be sent > > seperately (probably even via PIOQUEUE). > > I wonder if we want to combine pioqueue and DMA, that might create quite some > franken-driver. Might be true, yet I hope it won't. Most I2C transfers tend to be very small, so PIOQEUE would have some advantage here (less overhead). > > The only thing to be chained is the I2C read command and the actual > > reading of the data. > > > > Just checked, the FSL driver does it basically this way, too. > > Which doesn't mean FSL driver does it correctly, but it probably > worked for them and there was some bug in my DMA tinkering. It's only a proof-of-concept. We both know that :) (If it works, that is, AFAICT that one will fail for transfers bigger than PAGE_SIZE, too). Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
