Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp2258561imj; Mon, 18 Feb 2019 02:53:47 -0800 (PST) X-Google-Smtp-Source: AHgI3IYW7aHpTGR+TJtYcGYRHqe3Z8Hjcc4fTaWCe9FsQxozX3MWLFcFPzsid6rXoYTXRVX68Klz X-Received: by 2002:a63:a70b:: with SMTP id d11mr18193803pgf.213.1550487227513; Mon, 18 Feb 2019 02:53:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550487227; cv=none; d=google.com; s=arc-20160816; b=r4qp/EW98y0KWhmcqA8Uam0DPDdS029FSUGy+csVw3CuHJaEbqK8j4gTZBux8rtnGH jWtNdy8rnO5mo1UDN2iTm8zG5J4l/UW6HkCW4veS6LL2Eg7c8MIgo28Ykr0R76RW941l 2r5eYYKROIH3DZIiY4W89DFoNvH8LLy6qpOXQpQDOa+YFtzZ6TlQyRoWsj/UFFlU481D 7F5ywNWDAbAMFAsPzPZNH/RoJH68RAKEu6rBkNXyUK+P5y5shGwtuREhwdEMdx5E5oAj J5R60l9nrAuroEBL+WxiSC4VueHRAS5K6ttyrTi++sf4XT1qbF45EQFhU3hf4I5U8e7c 2kNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CC6KdorLKJMkicgELgpTwOMSFBb61BLug+n8sMHlNNE=; b=1CVP/F9o36Ugj75hgTfwSERVZrFA833mkMfY/VWRHZm92K1Wm4k9gvxbQ274IB/TQg X1y5j2WnF+Iz63GIiACxNoBqK6d9JwURXKaHF+zlMKky8eiQ7AGlTKM0lV4qutR8pqnZ Ru5XuorUFIf/WnvrUOjD8n/MXm2jQX6sDvaU7EvRFt6kdYWKOsO7dC9g/oC6cR3AayEk v4JLrWncAqN1pPJ36SLr5KBKLinmD/CpzUDZ1bEnibqJPERhpYp4BcvDzNXkbsPD0dnS QIwabzQUV3CxkbTbViAjCiUTFaoW/TAzQkBybP5nziKSjOf2dxM9Worz72hcH0rB+M4l LlBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aQ0FVTAg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cb3si15031086plb.196.2019.02.18.02.53.31; Mon, 18 Feb 2019 02:53:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aQ0FVTAg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730365AbfBRKw5 (ORCPT + 99 others); Mon, 18 Feb 2019 05:52:57 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:36714 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728258AbfBRKw4 (ORCPT ); Mon, 18 Feb 2019 05:52:56 -0500 Received: by mail-lj1-f196.google.com with SMTP id g11-v6so13973967ljk.3 for ; Mon, 18 Feb 2019 02:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CC6KdorLKJMkicgELgpTwOMSFBb61BLug+n8sMHlNNE=; b=aQ0FVTAgAh1AmDGYYGeP5HNVOgDbZIQteYFysIV8WjWXEkf1yp+T7u04DWjDBhBOeo 14Ldk8cyUD6YCbdrD+Np+wqszjJuxDSsLR2piGuurRL2X2MDsqJCY8Yg5bhDRMvnf/ek IQ3PAP/UcBLPGe0d+Ldgq0M2H1kWdAuTnAzRU/GBEdBRV6JAR91lol1oisE5AFj5Oq8h 1M/9FHtT4DgRDJYVHERn7BGIWyY+CHDJ0kW6xa4eiHuKrgr0lTJHbwiGR84G1VzeTtim 6Fc1Bx/zf8ohHxVTFHY6bdBgXmhm3bsmb0pEcwQOLAt3ck0x0SOrPqphy9XJv7mhFwvO lj4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CC6KdorLKJMkicgELgpTwOMSFBb61BLug+n8sMHlNNE=; b=RHRLPilhfkkLzNkLq5iXFbYr1Iuf5BRrJxFpCK5WH5ciosyma3LJ/4sYaQywtQ8ZBD vYQsByUema+W8YkdOH3V1yjNgV0l57lXI/hoFJ42OYcCVWA1va0KiddPuzGZRH5YNoqZ yNdrACatT76mn10/ibvrc9VDWAj5lAygFEA5kSbGNL5NnspVPPSgZhtPNoSZWD3Hs07n tdOPkvLfr2pK5Gn3T4NSbxbAngcnYGxv47lwQmMQUC3gHsy1TeLDe2KuEDkRHb5iSQGZ Hki3fXPzIfzhMSkoRk4iq6lIX5WS8VvpbyEe1lRKqvhq/TLIgL1VHOUDtPgjRXpsCQ9x 8YAw== X-Gm-Message-State: AHQUAua4O7Z8YJvwRZiDBU+wwUjhzwNF7jAobOirun31aUrGdqOeCNs6 s3Ea5joHteXG9WT6YpJvYDY6xqGMrMbC7Q0QKUUg4Q== X-Received: by 2002:a2e:6a18:: with SMTP id f24mr14330316ljc.97.1550487174177; Mon, 18 Feb 2019 02:52:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Baolin Wang Date: Mon, 18 Feb 2019 18:52:40 +0800 Message-ID: Subject: Re: [PATCH 1/3] dt-bindings: dmaengine: Add one new cell to present hardware slave id To: Arnd Bergmann Cc: Vinod Koul , Rob Herring , Mark Rutland , Olof Johansson , Orson Zhai , Lyra Zhang , Dan Williams , DTML , arm-soc , Linux ARM , Linux Kernel Mailing List , dmaengine@vger.kernel.org, eric.long@unisoc.com, Mark Brown Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On Mon, 18 Feb 2019 at 18:31, Arnd Bergmann wrote: > > On Tue, Feb 12, 2019 at 9:25 AM Baolin Wang wrote: > > On Fri, 1 Feb 2019 at 19:53, Baolin Wang wrote: > > > On Thu, 31 Jan 2019 at 00:52, Arnd Bergmann wrote: > > > > On Tue, Jan 22, 2019 at 2:21 PM Baolin Wang wrote: > > > > > > > > > > Client: > > > > > DMA clients connected to the Spreadtrum DMA controller must use the format > > > > > -described in the dma.txt file, using a two-cell specifier for each channel. > > > > > -The two cells in order are: > > > > > +described in the dma.txt file, using a three-cell specifier for each channel. > > > > > +The three cells in order are: > > > > > 1. A phandle pointing to the DMA controller. > > > > > 2. The channel id. > > > > > +3. The hardware slave id which is used for clients to trigger DMA engine > > > > > +automatically. > > > > > > > > I notice that this is an incompatible binding change. Is that necessary? > > > > If the current code works, I'd suggest allowing both #dma-cells=<2> > > > > and <3>, and then implementing both in the driver. > > > > > > Yes, this is necessary. > > > > > > Yes, current code can work, but the problem is that the DMA clients > > > must add one property (something like "sprd,slave-id") to specify the > > > slave id. So considering this, we want to change the dma-cells to 2, > > > including dma channel and dma slave id, which can avoid introducing > > > some similar properties for DMA clients. > > > > > > Now there are no DMA clients in mainline for Spreadtrum platform, and > > > we want to upstream our first DMA clients: SPI controller. So no other > > > drivers need to change when we changing dma cells. Thanks. > > > > Do you have any other concerns about this patch set? If not, I think > > Vinod can apply this patch set. Thanks. > > Sorry for the late reply. Yes, this makes sense since there are no > existing users then. For the DT changes going through the dmaengine > tree > > Acked-by: Arnd Bergmann Thanks for your reviewing. > > One more question, to make sure we don't need to edit it again: > Why do you need both a 'channel id' and a 'slave id' here? Is this > a strict hardware requirement for your DMA engine? In many > other designs, only a DMA request line number needs to > be described, and I think this would correspond to what you > call the 'hardware slave id' in your documentation. I try to explain why we need the slave id. For our DMA engine driver, we have software request mode and hardware request mode. For software request mode, the DMA engine driver need trigger DMA to start transfer manually. But for hardware request mode, we just set one unique slave id corresponding to the slave hardware to the DMA engine, then the slave hardware can trigger DMA automatically. And the slave id is not always same with the channel id according to the SoC design, so we add one cell to specify the slave id. > > Does each request line here correspond to a fixed channel > id as well, or can a channel be shared between multiple Yes, each request line corresponds to a fixed channel id. > slave devices? > > Arnd -- Baolin Wang Best Regards