Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp2244196imj; Mon, 18 Feb 2019 02:34:17 -0800 (PST) X-Google-Smtp-Source: AHgI3Ib8GOCZzeOs6PhA3D+jvBv7uDtqx/BxizEI4I0OFH2Zfi2IrcTVQg401zWKNEjNlFmp1GFS X-Received: by 2002:a65:4104:: with SMTP id w4mr17959993pgp.158.1550486057070; Mon, 18 Feb 2019 02:34:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550486057; cv=none; d=google.com; s=arc-20160816; b=teMUoaOZydebVI5Xq7TSNB9jF/XSXu9a7nf4qItZ3mnTvE+h670tewrIkYEapsP9B6 zghCtuOwi/IPuliTcCz4CwUKORo7qS7sHVZ7lhSST0gXjVYSIBt5Lmu99aZl++xHCq4s /2Vcrqo20n0//B71d5Np8o/GYZGqBuGvkT8w8GpAhBOu7/+Eal8Ho8MMfQiV6WBfr2vg POfXuq663jGnJS4dwluPn45o+UF8dL47+9gMg2AcJc/8YyLM+YLWR4OizoNRW2kMRXsz fcVtRlape5tex7PlageU5RK+LGOGxwwu7K3THjzZQ5Pr4Lx2hNKLGfZSnN67E5zysDWl HTmw== 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; bh=JeAiCwTdj8ylL6sF0x2uByC9gBRqCOAVMEnpZGUkBbU=; b=fp7J3z2opDuwYi2drLPcBF1OdTB5j3KNqxAjne6yih2yMgPw0ZOOODm5NHR5AfsI+o F/GZoqkPxpkH9jp6V5frwLQ70p781Sq9cR1z81w4FJXNa/ho0zOQuN91GfGe7GS//3Jp 9ZPRpo7WTOX0UrhabQUccqT0GJyssdNLJsf1pmUrnkWAJ7mpWECkIitZpCbzy+bpDE1e fPmT/ySNwGT2tb8EcxL4+98ZAdCe/ZvZOloBFf1nA1MU6YZm+1E4B9iObz/lqaXzaABn J8KCDyXPj+FOeuZ3YE6p7Vt7K4nXs1g9in5FfaKfzBS5SoqUYOuYEktcVH+hehZ5oVbJ oWNw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r17si11893231pgv.329.2019.02.18.02.34.01; Mon, 18 Feb 2019 02:34:17 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729510AbfBRKbv (ORCPT + 99 others); Mon, 18 Feb 2019 05:31:51 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:39338 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727004AbfBRKbu (ORCPT ); Mon, 18 Feb 2019 05:31:50 -0500 Received: by mail-qt1-f193.google.com with SMTP id o6so18571442qtk.6; Mon, 18 Feb 2019 02:31:49 -0800 (PST) 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=JeAiCwTdj8ylL6sF0x2uByC9gBRqCOAVMEnpZGUkBbU=; b=s6cNxLf6t5MiOYZH8QTTV8YarjrGMITf3kmgv+CxoWEjDoi7arZYB0JWu2+wTh4vJT MTJr9cArlGuoG7FJ/Wb/3DUQTWp0LWm5yt65cWI47eag/DI+YTuE2WOl+2MaoMEr6NmO m7urO9/N9yEld+4NieQtVi/iZctE4hXqqWqMP++lwLf+1rp0NEzEm/3WI3JCto0HqJBq rtQqrEryDryTczbru0rXvn0yjf4D21s33Fn7wG3LkCqtWpKt4WGKNiO0tOmgF4+bB64K 02CYKX8HzJqiocvwfGpW/oi8xnn4QfMk4Hc2DDST+cS0HLAXr1a+6701g2Kx8skPvkdJ ggvg== X-Gm-Message-State: AHQUAuarQ+pPZUP4jeIyGsmSnVr2ytfpFFoQuEvKDPA82XWTSL6/hKx+ w+nHm305nwlmw/IdUj5YFX64PBHYCYdCHAtygEE= X-Received: by 2002:ac8:4141:: with SMTP id e1mr16997325qtm.96.1550485909026; Mon, 18 Feb 2019 02:31:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Mon, 18 Feb 2019 11:31:32 +0100 Message-ID: Subject: Re: [PATCH 1/3] dt-bindings: dmaengine: Add one new cell to present hardware slave id To: Baolin Wang 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 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 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. Does each request line here correspond to a fixed channel id as well, or can a channel be shared between multiple slave devices? Arnd