On Wed, Aug 16, 2017 at 10:16:31AM -0700, Dave Jiang wrote: > > > On 08/16/2017 10:06 AM, Dan Williams wrote: > > On Wed, Aug 16, 2017 at 9:50 AM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote: > >> On Thu, Aug 03, 2017 at 09:14:13AM -0700, Dan Williams wrote: > >>> All my suggestions would involve a lot more work. If we had infinite > >>> time we'd stop with the per-operation-type entry points and make this > >>> look like a typical driver sub-system that takes commands like > >>> block-devices or usb, but perhaps that ship has sailed. > >> > >> Can you elaborate on this :) > >> > >> I have been thinking about the need to redo the API. So lets discuss :) > > > > The high level is straightforward, the devil is in the details. Define > > a generic dma command object, perhaps 'struct dma_io' certainly not > > 'struct dma_async_tx_descriptor', and have just one entry point > > per-driver. That 'struct dma_io' would carry a generic command number > > a target address and a scatterlist. The driver entry point would then > > convert and build the command to the hardware command format plus > > submission queue. The basic driving design principle is convert all > > the current function pointer complexity with the prep_* routines into > > data structure complexity in the common command format. > > > > This trades off some efficiency because now you need to write the > > generic command and write the descriptor, but I think if the operation > > is worth offloading those conversion costs must already be in the > > noise. yes the trade off IMO seems a good one actually. In the hindsight the proliferation of prep_* wasn't a good one. Also for request processing I feel lot more burden should be undertaken by dmaengine core rather than drivers, we should just give requests to driver. The descriptors should be managed in the core... To ease the change, we can create the new API and not accept drivers to old API and start moving off drivers one bit at a time. Yes that will take a lot of time but the conversion will be less painful hopefully... > Vinod, I think if you want to look at existing examples take a look at > the block layer request queue. Or even better blk-mq. I think this is > pretty close to what Dan is envisioning? Also, it's probably time we > looking into supporting hotplugging for DMA engines? Maybe this will > make it easier to do so. I'm willing to help and hoping that it will > make things easier for me for the next gen hardware. Okay i will look it up. Thanks for the help, we need all the help here :) > -- > To unsubscribe from this list: send the line "unsubscribe dmaengine" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
