On 10/10/2018 05:09 AM, Vinod wrote: > On 10-10-18, 12:44, Peter Ujfalusi wrote: >> >> >> On 2018-10-10 07:05, Vinod wrote: >>> On 24-09-18, 16:00, Peter Ujfalusi wrote: >>>> From: Grygorii Strashko <grygorii.strashko@xxxxxx> >>>> >>>> Certain users can not use right now the DMAengine API due to missing >>>> features in the core. Prime example is Networking. >>> >>> What are the features you have in mind? >> >> The two big ones are: >> 1. Support for out of order completion of descriptors (cookie management) >> >> This mostly concerns the DEV_TO_MEM. >> Currently we have dma_cookie_t (s32) to track which descriptor is >> completed, which one is issued and which one is pending. >> It is mandatory that descriptors are completed in the same order as they >> were issued. >> >> We need to have support for out of order completion of the issued >> descriptors and thus the s32 way of tracking is not working. >> >> We basically have three use cases needed to be supported: >> 1a: in order completion (currently supported by DMAengine) >> 1b: out of order completion in a channel, descriptors can complete in >> different order. >> 1c: out of order completion in a channel, the completion is ordered >> within 'classification type' of descriptors via the channel >> >> If we issue descriptors 1, 2, 3, 4, 5, 6, 7 >> >> We could receive back them >> 1a: 1, 2, 3, 4, 5, 6, 7 >> 1b: 4, 7, 2, 1, 3, 5, 6 >> >> in case of 1c we can classify descriptors when issuing: >> 1(c0), 2(c0), 3(c0), 4(c1), 5(c1), 6(c1), 7(c1) >> >> and we receive the back like: >> 4(c1), 5(c1), 1(c0), 2(c0), 6(c1), 3(c0), 7(c1) >> >> The descriptors are coming back in 'random' order, however they are in >> order within their classification. > > when you say classification you mean actual HW channels right, so to > support that why should the cookie be provided from the channel where > you schedule the descriptor for? > >> The must supported one is 1b at the moment, 1c should be reasonably >> simple to add support for. > > so you are adding 1b in this patch? > >> >> 2. NAPI support >> >> Via NAPI an RX looks something like this: >> - give the hardware bunch of descriptors to receive packets >> - when the first packet is received get notification >> - disable the interrupts >> - schedule NAPI >> - in the NAPI poll function read out the completed descriptors one by >> one, process them, then give back the descriptor (with new buffer) to >> the hardware. >> - after poll finished (no more packets or got the number of packets NAPI >> told us to read out) enable the interrupts and wait for packets to start >> to flow in. > > Can that not be done by using the interrupt/ack flags? > There is actually point 3) UDMA channels are very "universal" and support pretty high number of configuration possibilities, so each UDMA channel consumer need to configure each channel depending on its own needs and target IP. Some of the parameters might by dynamic - minimum for debugging purposes. The consumer driver usually knows what it needs to configure basing on compat string. it seems there is no other way now to pass custom channel configuration from consumer driver to the DMA engine driver except using DT (at least I've not found it) - which means only static configuration can be used (plus, DT bindings might grow significantly). Any way, this is not so critical as 1 and 2. I'll try to provide more info on 1 also. -- regards, -grygorii
