From patchwork Thu Mar 24 14:37:19 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gregory CLEMENT X-Patchwork-Id: 8661341 Return-Path: X-Original-To: patchwork-dmaengine@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id A23E1C0553 for ; Thu, 24 Mar 2016 14:37:29 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A0A532017D for ; Thu, 24 Mar 2016 14:37:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9BFFA20125 for ; Thu, 24 Mar 2016 14:37:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755094AbcCXOhW (ORCPT ); Thu, 24 Mar 2016 10:37:22 -0400 Received: from down.free-electrons.com ([37.187.137.238]:55934 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751365AbcCXOhV (ORCPT ); Thu, 24 Mar 2016 10:37:21 -0400 Received: by mail.free-electrons.com (Postfix, from userid 110) id F113F3E2; Thu, 24 Mar 2016 15:37:18 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from localhost (81-67-231-93.rev.numericable.fr [81.67.231.93]) by mail.free-electrons.com (Postfix) with ESMTPSA id B5E8D8A; Thu, 24 Mar 2016 15:37:18 +0100 (CET) From: Gregory CLEMENT To: Dan Williams Cc: "dmaengine\@vger.kernel.org" , Vinod Koul , Maxime Ripard , Thomas Petazzoni Subject: Re: Adding a parameter to set a minimal length for dmatest References: <87y49aplrf.fsf@free-electrons.com> <87twjypksw.fsf@free-electrons.com> <87mvpqpfbt.fsf@free-electrons.com> Date: Thu, 24 Mar 2016 15:37:19 +0100 In-Reply-To: (Dan Williams's message of "Tue, 22 Mar 2016 11:14:24 -0700") Message-ID: <87fuvgndr4.fsf@free-electrons.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Dan, On mar., mars 22 2016, Dan Williams wrote: > On Tue, Mar 22, 2016 at 10:55 AM, Gregory CLEMENT > wrote: >> Hi, >> >> On mar., mars 22 2016, Gregory CLEMENT wrote: >> >>> Hi Dan, >>> >>> On mar., mars 22 2016, Dan Williams wrote: >>> >>>> On Tue, Mar 22, 2016 at 8:36 AM, Gregory CLEMENT >>>> 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. I think to something like that: Thanks, Gregory > -- > To unsubscribe from this list: send the line "unsubscribe dmaengine" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index 017433712833..a6a2f99fa9f9 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -707,6 +707,10 @@ struct dma_device { enum dmaengine_alignment xor_align; enum dmaengine_alignment pq_align; enum dmaengine_alignment fill_align; + size_t copy_min_len; + size_t xor_min_len; + size_t pq_min_len; + size_t fill_min_len; #define DMA_HAS_PQ_CONTINUE (1 << 15) int dev_id;