Hi Vinod, Laurent, On 13/02/2020 16.07, Vinod Koul wrote: > On 13-02-20, 15:48, Laurent Pinchart wrote: >> Hi Vinod, >> >> On Thu, Feb 13, 2020 at 06:59:38PM +0530, Vinod Koul wrote: >>> On 10-02-20, 16:06, Laurent Pinchart wrote: >>> >>>>>>> The use case here is not to switch to a new configuration, but to switch >>>>>>> to a new buffer. If the transfer had to be terminated manually first, >>>>>>> the DMA engine would potentially miss a frame, which is not acceptable. >>>>>>> We need an atomic way to switch to the next transfer. >>>>>> >>>>>> So in this case you have, let's say a cyclic descriptor with N buffers >>>>>> and they are cyclically capturing data and providing to client/user.. >>>>> >>>>> For the display case it's cyclic over a single buffer that is repeatedly >>>>> displayed over and over again until a new one replaces it, when >>>>> userspace wants to change the content on the screen. Userspace only has >>>>> to provide a new buffer when content changes, otherwise the display has >>>>> to keep displaying the same one. >>>> >>>> Is the use case clear enough, or do you need more information ? Are you >>>> fine with the API for this kind of use case ? >>> >>> So we *know* when a new buffer is being used? >> >> The user of the DMA engine (the DRM DPSUB driver in this case) knows >> when a new buffer needs to be used, as it receives it from userspace. In >> response, it prepares a new interleaved cyclic transaction and queues >> it. At the next IRQ, the DMA engine driver switches to the new >> transaction (the implementation is slightly more complex to handle race >> conditions, but that's the idea). >> >>> IOW would it be possible for display (rather a dmaengine facing >>> display wrapper) to detect that we are reusing an old buffer and keep >>> the cyclic and once detected prepare a new descriptor, submit a new >>> one and then terminate old one which should trigger next transaction >>> to be submitted >> >> I'm not sure to follow you. Do you mean that the display driver should >> submit a non-cyclic transaction for every frame, reusing the same buffer >> for every transaction, until a new buffer is available ? The issue with >> this is that if the CPU load gets high, we may miss a frame, and the >> display will break. The DPDMA hardware implements cyclic support for >> this reason, and we want to use that feature to comply with the real >> time requirements. > > Sorry to cause confusion :) I mean cyclic > > So, DRM DPSUB get first buffer > A.1 Prepare cyclic interleave txn > A.2 Submit the txn (it doesn't start here) > A.3 Invoke issue_pending (that starts the txn) > > DRM DPSUB gets next buffer: > B.1 Prepare cyclic interleave txn > B.2 Submit the txn > B.3 Call terminate for current cyclic txn (we need an updated terminate > which terminates the current txn, right now we have terminate_all which > is a sledge hammer approach) > B.4 Next txn would start once current one is started > > Does this help and make sense in your case That would be a clean way to handle it. We were missing this API for a long time to be able to cancel the ongoing transfer (whether it is cyclic or slave_sg, or memcpy) and move to the next one if there is one pending. +1 from me if it counts ;) > > Thanks > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
