Hello, I wrote:
This is a new patch in series; it's too against the recent Linus'
kernel...
The code is not exactly trivial but hopefully self-documented, it
has been
successfulyl stress tested with CPPI 3.0 and 4.1 drivers, though
still needs
verification with Inventra DMA...
---
This looks very interesting, but it looks a bit too complex to
consider acking for 2.6.29, given there's a trivial "use PIO"
workaround and it's only been tested with one of the three DMA
engines in use.
It shouldn't change anything for TUSB since it doesn't sue Tx DMA
mode 1.
Sigh, I was naive thinking that the TUSB related code is
consistent... :-/ cppi_host_txdma_start() doesn't enable this mode but
tusb_omap_dma_program() itself does! Which brings out the question:
why cppi_host_txdma_start() is called after DMA channel is already
programmed at all for the TUSB case?
Moreover, with this driver's limitation of DMAthe length not
exceeding packet size, not only using DMA mode 1 doesn't win anything,
it just clearly loses because we have to switch to DMA mode 0 to get the
TxPktRDY=0 interrupt.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
