On Thu, Mar 24, 2016 at 03:37:19PM +0100, Gregory CLEMENT wrote: > Hi Dan, > > On mar., mars 22 2016, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > On Tue, Mar 22, 2016 at 10:55 AM, Gregory CLEMENT > > <gregory.clement@xxxxxxxxxxxxxxxxxx> wrote: > >> Hi, > >> > >> On mar., mars 22 2016, Gregory CLEMENT <gregory.clement@xxxxxxxxxxxxxxxxxx> wrote: > >> > >>> Hi Dan, > >>> > >>> On mar., mars 22 2016, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > >>> > >>>> On Tue, Mar 22, 2016 at 8:36 AM, Gregory CLEMENT > >>>> <gregory.clement@xxxxxxxxxxxxxxxxxx> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> while using the dmatest module to test the mv_xor.c driver, I got > >>>>> failures. I finally found that when the "noverify" parameter is not set, > >>>>> then the buffer length used is totally random (modulo the maximum size > >>>>> of the buffer). But in the mv_xor_prep_dma_xor there is a test about the > >>>>> minimal size the dmaengine can use. So when the length was under this > >>>>> minimum size then I got some test failures like the following: "dmatest: > >>>>> dma1chan0-copy0: result #11: 'prep error' with src_off=0x29c9 > >>>>> dst_off=0x1c51 len=0x33 (0)". > >>>>> > >>>>> Unless the drivers are supposed to accept all buffer size I think it is > >>>>> not an error, and I would like to be able to use this dmatest for > >>>>> automatic test and not to have to check if the error is a real one or > >>>>> not. > >>>>> > >>>>> I think that the following patch could improve the dmatest module. > >>>>> > >>>>> What do you think about it? > >>>>> > >>>>> Did I miss something or is a good ieda to send a proper patch? > >>>> > >>>> Looks like a useful patch to me. > >>> > >>> Thanks for your prompt answer, so I am going to send patch on the ML to > >>> have a real review. > >> > >> In the meantime, my colleague Thomas Petazzoni found that it would make > >> more sens to make the framework aware of this limitation instead of > >> having to know the minimum size for each dma test. We could do it in the > >> same way that it was done for the alignment constraint. > >> > >> What do you think of it? > >> > > > > I think we should just enforce the minimum alignment as the minimum > > transfer size. I don't think we have a need to support unaligned > > transfer sizes. > > So I checked and for this XOR engine there is a real minimum transfer > size, whereas there is no constraint on the alignment. (Actually it is > better to be aligned on the burst size, but it is not mandatory at all) > > So I think it would make sens to add this information, as for the > alignment the modules using the dma engine still can ignore this but it > could be an interesting information. If it's really a minimum transfer size, no one should ignore it, and the framework should reject any transfer size lower than that. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
