On Mon, Oct 30, 2017 at 06:39:07PM +0530, Shevchenko, Andriy wrote: > Hi! > > During ELCE 2017 Lars, Alexey and me had a chat with regards to DMA > subsystem. There were IIRC few topics. Let me summarize what was being > discussed and the next steps. thank you guys for discussions and notes > > (Lars, Alexey, please correct me if / where I'm wrong) > > DesignWare DMA driver (AHB) > --------------------------- > I have a lot of stuff to do besides this one driver. Moreover, it looks > like there is nothing (features) anticipated to be done to the driver > from me since Intel switched to its own DMA engine, IDMA, which looks > like DW DMA, though 64-bit (though 32-bit version of it, that present in > few Intel SoCs, had been embedded to DesignWare DMA driver already). > > Thus, I would like to step down from co-maintainer to just a designated > reviewer for the driver. Synopsys may take over, and Alexey has a > candidate in his mind. > > I also think Viresh can do the same. Viresh? > > That said, we will keep an eye on driver changes. > > The proposed change is a patch from Synopsys against MAINTAINERS data > base from the potential (co-)maintainer of the driver where Viresh and > me are moved under R: and new maintainer under M: records respectively. > > > DesignWare DMA driver (AXI) > --------------------------- > There were some issues with the code, though it looks like the lack of > explanation in commit message why it's done one way than other. > > We agreed with Alexey that next version of the patch will clarify it. > > > DMA error reporting > ------------------- > There was (still is?) an issue with good error reporting to a user, in > particularly DW DMA (AXI) [see above] needs it. As far as I understood > current situation is much better. Caller could register a callback which > will be called on error condition. The enum provides plain integer error > codes where just few now are registered and there is enough room to add > more on demand. thats right. Dave added the ones he needed, if need be we can certainly add more > > > Per channel DMA parameters structure and sg_list (re-)split > ----------------------------------------------------------- > Potentially some of DMA controllers may have different configuration > options on per channel basis. Inside struct device we have embedded > struct dma_parms which provides two fields: 1) maximum segment size, and > 2) alignment boundary. API to set and retrieve these parameters is > bound to struct device. We might need something similar for struct > dma_chan. Sorry am not sure I follow, which parameters are we talking about here? Is it for dma_slave_caps? > (That's why I stopped doing my patch series with sg_list split for DMA > controller drivers) > > Some frameworks (SPI core, for example) are already using this to > prepare sg_list accordingly. > > The benefit of the change is to decrease latency for DMA setup when > sg_list is prepared without actual knowledge about DMA channel > parameters. > > Alexey shared opinion that there is no rush to implement it because > there is no example of such device in practice. > > Lars has different view on this, pointing to flexibility of the drivers > (drivers know for sure all limitations and advantages of certain DMA > controller) and necessity to do at least a check since not all > subsystems are supporting mentioned API. -- ~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
