On Tue, 20 Jun 2023 15:07:37 +0300 Serge Semin <fancer.lancer@xxxxxxxxx> wrote: > > This one is only hypothetical. It appears to me that writing the control > > after the configuration of sar and dar is more relevant to prevent race > > issues and should be the usual coding choice. Also you are right saying > > that it will be relevant only for the LL tree entries recycling. > > Simple question from non DMA expert: isn't cyclic DMA mode recycle the LL > > tree entries? > > Ideally the driver should have been designed in the way you say: > define a ring of the Linked List entries and recycle the already used > entries while the already enabled entries are being handled by the > DMA-engine (a similar approach is described in the DW PCIe/eDMA hw > manual). DW eDMA engine CSRs and LLI descriptor provide enough > functionality for that. Alas the driver implementation is more > straightforward: > 1. Each DMA-engine config: SG-list, cyclic, interleaved is split up > into the "burst" entries. SG-list entries are directly mapped to the > eDMA "burst" entries. Cyclic iterations are unrolled into the > respective number of eDMA "burst" entries. A similar story with the > interleaved transactions. > 2. If there is no enough entries in the Linked-List memory to fully > execute the requested DMA-transfers, then another so called DW eDMA > "chunk" is allocated. > 3. DW eDMA engine executes the "chunks" one after another stopping at > the end of each one and recharging the engine with the next "chunk" until > the last one is finished. > > It isn't the most effective architecture, but that's how it was > originally developed by Gustavo. Anyway discussing it is a good food > for thoughts for the driver refactoring though.) thanks for enlightening me, then indeed we will never face the issue solved by this patches as we won't recycle LL tree entries.
