dma: edma: Provide granular residue accounting
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 6 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 6 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [patch 0/6] dma: edma: Provide granular residue accounting
Quoted 2 lines · Thomas Gleixner
The next obstacle was the missing per SG element reporting. We really can't wait for a full SG list for notification.
Err, dmaengine doesn't have per-SG element reporting.
What it does allow is several transactions to be submitted consecutively, so that the DMA engine can move to the next transaction once the previous one has been submitted.
Where it's important that this happens with the minimum of delay, there's nothing in the API that prevents the hardware scatterlist of the previous transaction being linked directly to the following transaction, provided of course the hardware can do that.
Many DMA engine implementations are just lazy - they implement stuff as:
setup hardware, run scatter list, get to the end, raise interrupt. Fire off tasklet. Tasklet runs, calls the callback, checks to see if there's another transaction, sets up hardware for the next one. That (as you would expect) gives quite a high latency to the following transaction.
I've coded at least one DMA engine driver to start the next transaction immediately that the previous one completes, before the tasklet is run. As I say above, there's really no reason to even wait for the interrupt... if people can be bothered to think about all the implications that brings (f.e. reporting completion status, and how many bytes remaining of a transaction, etc.)
Quoted 3 lines
So we'd trade the CAN interrupt per packet against the EDMA interrupt per packet. And the notification which is done via a tasklet is not really helpful either.
Again, the DMA engine API allows for the reception of the interrupt to be turned off (not every DMA engine implementation supports it though.) However, no interrupts means no callbacks (or an implementation may decide that the presence of a callback means that you do want interrupts - that's because a number of buggy drivers forget to give DMA_PREP_INTERRUPT.)
However, not using the callbacks then means you need to poll for completion - that's where tracking the cookies for the submitted transactions, calling dmaengine_tx_status() with a state argument, or dma_async_is_tx_complete() then allows you to use dma_async_is_complete() to quickly ascertain whether any of the other cookies have completed.
What you can't do though is decide whether you want an interrupt after submission.
Quoted 5 lines
The DCAN readout is 4 consecutive 32bit registers. The only way I got that working is by configuring the engine with:
cfg.direction = DMA_DEV_TO_MEM; cfg.src_addr_width = 16;
Hmm. This is an enum, and the expected values are limited to 1, 2, 4, and 8 for 8-bit, 16-bit, 32-bit and 64-bit respectively. The width is supposed to represent the width of the access used on the bus to the peripheral.
So, if we did have a DMA engine which supported 128-bit accesses, it would end up doing a 128-bit access for the above...
Quoted 1 line
cfg.src_maxburst = 1;
This is supposed to indicate the maximum number of accesses in a burst to the same register. It kind of makes sense, but I'm not sure it's in the spirit of the DMA engine API. I think strictly, to have a DMA engine perform 4 consecutive 32-bit accesses is quite a special requirement that we don't have a way to represent it at present.
Quoted 5 lines
With
cfg.src_addr_width = 4; cfg.src_maxburst = 4;it reads just 4 times the first register.
If it's just that the FIFO is spread over 4 consecutive locations (effectively due to not decoding bits 2,3 of the address bus for the register) then reading the first register four times is just as acceptable as reading them consecutively.
The reason that kind of thing was done in old days was to allow the ARM ldmia/stmia instructions to be used to access FIFOs, thereby allowing multiple words to be transferred with a single instruction. I can't believe that there's still people designing for that especially if they have a DMA engine...
Signature · 2 lines
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.