On 17/01/2019 05:03, Vinod Koul wrote: > On 15-01-19, 13:02, Gustavo Pimentel wrote: >> On 15/01/2019 05:45, Andy Shevchenko wrote: >>> On Mon, Jan 14, 2019 at 11:44:22AM +0000, Gustavo Pimentel wrote: >>>> On 11/01/2019 19:48, Andy Shevchenko wrote: >>>>> On Fri, Jan 11, 2019 at 07:33:43PM +0100, Gustavo Pimentel wrote: >>>>>> Add Synopsys eDMA IP test and sample driver to be use for testing >>>>>> purposes and also as a reference for any developer who needs to >>>>>> implement and use Synopsys eDMA. >>>>>> >>>>>> This driver can be compile as built-in or external module in kernel. >>>>>> >>>>>> To enable this driver just select DW_EDMA_TEST option in kernel >>>>>> configuration, however it requires and selects automatically DW_EDMA >>>>>> option too. >>>>>> >>>>> >>>>> Hmm... This doesn't explain what's wrong with dmatest module. >>>> >>>> There isn't anything wrong with dmatest module, that I know of. In beginning I >>>> was planning to used it, however only works with MEM_TO_MEM transfers, that's >>>> why I created a similar module but for MEM_TO_DEV and DEV_TO_MEM with >>>> scatter-gather and cyclic transfers type for my use case. I don't know if can be >>>> applied to other cases, if that is feasible, I'm glad to share it. >>> >>> What I'm trying to tell is that the dmatest driver would be nice to have such >>> capability. >>> >> >> At the beginning I thought to add those features to dmatest module, but because >> of several points such as: >> - I didn't want, by any chance, to broke dmatest module while implementing the >> support of those new features; >> - Since I'm still gaining knowledge about this subsystem I preferred to do in a >> more controlled environment; >> - Since this driver is also a reference driver aim to teach and to be use by >> someone how to use the dmaengine API, I preferred to keep it simple. >> >> Maybe in the future both modules could be merged in just one tool, but for now I >> would prefer to keep it separated specially to fix any immaturity error of this >> module. > > With decent testing we should be able to iron out kinks in dmatest > module. It gets tested for memcpy controllers so we should easily catch > issues. Ok, since I don't have a setup to test that, may I count with you for test it? > > Said that, it would make sense to add support in generic dmatest so that > other folks can reuse and contribute as well. Future work always gets > side tracked by life, so lets do it now :) But there are some points that will need to be reworked or clarified. For instance, I require to know the physical and virtual address and the maximum size allowed for the Endpoint (in my case), where I will put/get the data. Another difference is, I create all threads and only after that I start them all simultaneously, the dmatest doesn't have that behavior. There are 1 or 2 more details, but the ones that have the greatest impact are those. > >
