From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D6D6C17447 for ; Wed, 13 Nov 2019 04:08:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D188D222C9 for ; Wed, 13 Nov 2019 04:08:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573618086; bh=1Xz1e3rpcu5Dl6WkiysgblTxtErL0d9tDfytLC7CXEo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=S53q/6ArqO4EDhBWnfte1T1EksBsgrnncBHfoFAamGSDi1SKWVbJ+SOoEgd+zobuo bHjY/5yNUIHSaBcShiyIvH0zj8gHfVsDV5jMtNmhZhnhL3azsoVOjWdFmHQZxwk5Zd kYniQSvhpjUCSCS5kDMfrj1Hg4UyB0gpACQLKV4E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727349AbfKMEIF (ORCPT ); Tue, 12 Nov 2019 23:08:05 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:41580 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727032AbfKMEIF (ORCPT ); Tue, 12 Nov 2019 23:08:05 -0500 Received: by mail-oi1-f193.google.com with SMTP id e9so538902oif.8; Tue, 12 Nov 2019 20:08:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SfWsvDTJzevdEjzMrngS03ZeASmUAsKr6Bk84qRvmhU=; b=lWkOrY6Ei/bGZoT3h0ZLzCVDxsZMY7ea12wDZxWc2DgCXpC1TNb3PLCdqz3gn9mOVa ZSWlnEGg7h822JuhyOSp2krq1BlFTwEh6SUTNMLxpC/+V6GrNbErqx8KkfaizqSI+dsO CfDDyT/u6Yg0oaWtcNiBE5I/gjW75lZQDm9CuVBJiKuK1b1tZF9gXYV9+nGyWvy3Arjh ADDGUPcQS0SqVsBWp8zKEL/nY8CBBr5BwOowVlgi30ECD48YjcuCZ+jOe1fVt7KqBqt1 7KgeEPrAmU632auPCVJ7nSgfevHf7OoHb/l6NVkRkLMRGPXWjWdy/1VGd1i/+n84vyEo KUhA== X-Gm-Message-State: APjAAAU6t7KtjWEA11atbzBaKxRvkkYu8De04FJFqF4w7Da1+qr9KvBM G4/1Xncuycb7zLtVzPqTRw== X-Google-Smtp-Source: APXvYqwRUjP0Ny/K1cwD676eUUZNEvW/sKvkoiqZmyITmDaRQZxyPexAR+dfGrVGINIfyHcGyj/tlQ== X-Received: by 2002:aca:5cd5:: with SMTP id q204mr900116oib.14.1573618083945; Tue, 12 Nov 2019 20:08:03 -0800 (PST) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id e193sm296871oib.53.2019.11.12.20.08.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 20:08:03 -0800 (PST) Date: Tue, 12 Nov 2019 22:08:02 -0600 From: Rob Herring To: Geert Uytterhoeven Cc: "Lad, Prabhakar" , Bjorn Helgaas , Mark Rutland , Magnus Damm , Kishon Vijay Abraham I , Marek Vasut , Yoshihiro Shimoda , linux-pci , Catalin Marinas , Will Deacon , Lorenzo Pieralisi , Arnd Bergmann , Greg Kroah-Hartman , Andrew Murray , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List , Linux ARM , Linux-Renesas , Chris Paterson , "Lad, Prabhakar" Subject: Re: [PATCH 3/5] PCI: rcar: Add R-Car PCIe endpoint device tree bindings Message-ID: <20191113040802.GA8269@bogus> References: <20191106193609.19645-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20191106193609.19645-4-prabhakar.mahadev-lad.rj@bp.renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 07, 2019 at 09:08:35PM +0100, Geert Uytterhoeven wrote: > Hi Prabhakar, > > On Thu, Nov 7, 2019 at 10:26 AM Lad, Prabhakar > wrote: > > On Thu, Nov 7, 2019 at 8:44 AM Geert Uytterhoeven wrote: > > > On Wed, Nov 6, 2019 at 8:36 PM Lad Prabhakar wrote: > > > > From: "Lad, Prabhakar" > > > > > > > > This patch adds the bindings for the R-Car PCIe endpoint driver. > > > > > > > > Signed-off-by: Lad, Prabhakar > > > > > > Thanks for your patch! > > > > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/pci/rcar-pci-ep.txt > > > > @@ -0,0 +1,43 @@ > > > > +* Renesas R-Car PCIe Endpoint Controller DT description > > > > + > > > > +Required properties: > > > > + "renesas,pcie-ep-r8a774c0" for the R8A774C0 SoC; > > > > + "renesas,pcie-ep-rcar-gen3" for a generic R-Car Gen3 or > > > > + RZ/G2 compatible device. > > > > > > Unless I'm missing something, this is for the exact same hardware block as > > > Documentation/devicetree/bindings/pci/rcar-pci.txt? > > > So shouldn't you amend those bindings, instead of adding new compatible > > > values? > > > Please remember that DT describes hardware, not software policy. > > > So IMHO choosing between host and endpoint is purely a configuration > > > issue, and could be indicated by the presence or lack of some DT properties. > > > E.g. host mode requires both "bus-range" and "device_type" properties, > > > so their absence could indicate endpoint mode. > > > > > yes its the same hardware block as described in the rcar-pci.txt, I > > did think about amending it > > but it might turn out to be bit messy, > > > > required properties host ======required properties Endpoint > > ====================||================== > > 1: reg || reg > > 2:bus-range || reg names > > 3: device_type || resets > > 4: ranges || clocks > > 5: dma-ranges || clock-names > > 6: interrupts || > > 7: interrupt-cells || > > 8: interrupt-map-mask || > > 9: clocks || > > 10: clock-names || > > We have a similar situation with SPI, where a controller can operate in > master or slave mode, based on the absence or presence of the > "spi-slave" DT property. > > > and if I go ahead with the same compatible string that would mean to > > add support for endpoint > > mode in the host driver itself. I did follow the examples of > > You can still have two separate drivers, binding against the same > compatible value. Just let the .probe() function return -ENODEV if it > discovers (by looking at DT properties) if the node is configured for > the other mode. > Which brings us to my next questions: is there any code that could be > shared between the drivers for the two modes? > > > rockchip/cadence/designware where > > its the same hardware block but has two different binding files one > > for host mode and other for > > endpoint mode. > > Having two separate DT binding documents sounds fine to me, if unifying > them makes things too complex. > However, I think they should use the same compatible value, because the > hardware block is the same, but just used in a different mode. > > Rob/Mark: Any input from the DT maintainers? Separate files makes sense because different modes will want to include different common schemas. We've generally been doing different compatibles too which makes validating the node has the right set of properties easier. > > > > +- reg: Five register ranges as listed in the reg-names property > > > > +- reg-names: Must include the following names > > > > + - "apb-base" > > > > + - "memory0" > > > > + - "memory1" > > > > + - "memory2" > > > > + - "memory3" > > > > > > What is the purpose of the last 4 regions? > > > Can they be chosen by the driver, at runtime? > > > > > no the driver cannot choose them at runtime, as these are the only > > PCIE memory(0/1/2/3) ranges > > in the AXI address space where host memory can be mapped. > > Are they fixed by the PCIe hardware, i.e. could they be looked up by the > driver based on the compatible value? That would be strange for a memory range. Sounds like like 'ranges' though I'm not sure if 'ranges' for an EP makes sense or what that should look like. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4445C43331 for ; Wed, 13 Nov 2019 04:08:11 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C17E222CF for ; Wed, 13 Nov 2019 04:08:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SIlvbmHq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C17E222CF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gMFRXedLLWbvc2ZrJyz56XFvbunwcN1E6nOm5M9cy6o=; b=SIlvbmHqD+Sb8u PSPpeP9jpOH8lsfa2zx3WabVD9+kgpow5mcViLnx3ugLj5uv8g9QbNQWHyuE/Ao+9eHHxRDbnZe92 4TM/4J/voA9JlZOB2tBDl9VVyazXf2ZVCBtUewVxkOT80P+a/PzxfIUJDTsSiMTmx2/Dg80fxCmyp oqp+RirVAqLmKJ2eGOgGJBza7U9jez44q20hJ8JnNnARZcr7QgDZuXAft6AHaUUcvz4rklalrTq8V dVvveENQgMQZEfvHKc51lhe/7ZOlhjEAJKGw56vWHOZcnV0hzNrYZWXmIddv9XbH7/8hVJ2ROTq9Q ul/zMkfy+EdXXClwEWyQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iUjwx-0005mG-6Y; Wed, 13 Nov 2019 04:08:11 +0000 Received: from mail-oi1-f195.google.com ([209.85.167.195]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iUjwt-0005kz-Rn for linux-arm-kernel@lists.infradead.org; Wed, 13 Nov 2019 04:08:09 +0000 Received: by mail-oi1-f195.google.com with SMTP id 22so547293oip.7 for ; Tue, 12 Nov 2019 20:08:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SfWsvDTJzevdEjzMrngS03ZeASmUAsKr6Bk84qRvmhU=; b=c+/H3d28Db3zs9Px6w3inNhYjV4uKel7D1D11zsbAP5CuOP3i0q+fjTVGdkI4sraNE sG8iU+pAjboVBBRPtMyum+Iyr0FwXYZDxVynU2DEaDWqogOj2B7F7UcMKXvtwsVvW1fF T4dvM7oJBoeIqytxa5hvwF1+O0fy0yOTP7tgNaQVH8s8s1GN0g4+ojTu8Jt/NQC/5tAI K/BDZYM4l3svpkwHhBKab0W67isvowSyiWirR2CetphO+BjkkF+EMuMMeGqkQoqUV0Ln zo6XSXZodbwmEFqTfTeUdLh2TGlfkU41KgH4E61IRwhMXIthJmTzTqRkvJzvfxvQx5O6 6hdQ== X-Gm-Message-State: APjAAAX1zZYJoTpyZU8aoIytyRCYYyHKcZIzXdjekhbLJeGZvs4AHrdF u96CReEu4I15iFFx0f1GhA== X-Google-Smtp-Source: APXvYqwRUjP0Ny/K1cwD676eUUZNEvW/sKvkoiqZmyITmDaRQZxyPexAR+dfGrVGINIfyHcGyj/tlQ== X-Received: by 2002:aca:5cd5:: with SMTP id q204mr900116oib.14.1573618083945; Tue, 12 Nov 2019 20:08:03 -0800 (PST) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id e193sm296871oib.53.2019.11.12.20.08.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 20:08:03 -0800 (PST) Date: Tue, 12 Nov 2019 22:08:02 -0600 From: Rob Herring To: Geert Uytterhoeven Subject: Re: [PATCH 3/5] PCI: rcar: Add R-Car PCIe endpoint device tree bindings Message-ID: <20191113040802.GA8269@bogus> References: <20191106193609.19645-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20191106193609.19645-4-prabhakar.mahadev-lad.rj@bp.renesas.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191112_200807_903006_AF49502D X-CRM114-Status: GOOD ( 34.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Chris Paterson , Lorenzo Pieralisi , "Lad, Prabhakar" , Arnd Bergmann , Greg Kroah-Hartman , linux-pci , Yoshihiro Shimoda , Magnus Damm , Linux Kernel Mailing List , Kishon Vijay Abraham I , Linux-Renesas , "Lad, Prabhakar" , Catalin Marinas , Bjorn Helgaas , Andrew Murray , Will Deacon , Linux ARM , Marek Vasut Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 07, 2019 at 09:08:35PM +0100, Geert Uytterhoeven wrote: > Hi Prabhakar, > > On Thu, Nov 7, 2019 at 10:26 AM Lad, Prabhakar > wrote: > > On Thu, Nov 7, 2019 at 8:44 AM Geert Uytterhoeven wrote: > > > On Wed, Nov 6, 2019 at 8:36 PM Lad Prabhakar wrote: > > > > From: "Lad, Prabhakar" > > > > > > > > This patch adds the bindings for the R-Car PCIe endpoint driver. > > > > > > > > Signed-off-by: Lad, Prabhakar > > > > > > Thanks for your patch! > > > > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/pci/rcar-pci-ep.txt > > > > @@ -0,0 +1,43 @@ > > > > +* Renesas R-Car PCIe Endpoint Controller DT description > > > > + > > > > +Required properties: > > > > + "renesas,pcie-ep-r8a774c0" for the R8A774C0 SoC; > > > > + "renesas,pcie-ep-rcar-gen3" for a generic R-Car Gen3 or > > > > + RZ/G2 compatible device. > > > > > > Unless I'm missing something, this is for the exact same hardware block as > > > Documentation/devicetree/bindings/pci/rcar-pci.txt? > > > So shouldn't you amend those bindings, instead of adding new compatible > > > values? > > > Please remember that DT describes hardware, not software policy. > > > So IMHO choosing between host and endpoint is purely a configuration > > > issue, and could be indicated by the presence or lack of some DT properties. > > > E.g. host mode requires both "bus-range" and "device_type" properties, > > > so their absence could indicate endpoint mode. > > > > > yes its the same hardware block as described in the rcar-pci.txt, I > > did think about amending it > > but it might turn out to be bit messy, > > > > required properties host ======required properties Endpoint > > ====================||================== > > 1: reg || reg > > 2:bus-range || reg names > > 3: device_type || resets > > 4: ranges || clocks > > 5: dma-ranges || clock-names > > 6: interrupts || > > 7: interrupt-cells || > > 8: interrupt-map-mask || > > 9: clocks || > > 10: clock-names || > > We have a similar situation with SPI, where a controller can operate in > master or slave mode, based on the absence or presence of the > "spi-slave" DT property. > > > and if I go ahead with the same compatible string that would mean to > > add support for endpoint > > mode in the host driver itself. I did follow the examples of > > You can still have two separate drivers, binding against the same > compatible value. Just let the .probe() function return -ENODEV if it > discovers (by looking at DT properties) if the node is configured for > the other mode. > Which brings us to my next questions: is there any code that could be > shared between the drivers for the two modes? > > > rockchip/cadence/designware where > > its the same hardware block but has two different binding files one > > for host mode and other for > > endpoint mode. > > Having two separate DT binding documents sounds fine to me, if unifying > them makes things too complex. > However, I think they should use the same compatible value, because the > hardware block is the same, but just used in a different mode. > > Rob/Mark: Any input from the DT maintainers? Separate files makes sense because different modes will want to include different common schemas. We've generally been doing different compatibles too which makes validating the node has the right set of properties easier. > > > > +- reg: Five register ranges as listed in the reg-names property > > > > +- reg-names: Must include the following names > > > > + - "apb-base" > > > > + - "memory0" > > > > + - "memory1" > > > > + - "memory2" > > > > + - "memory3" > > > > > > What is the purpose of the last 4 regions? > > > Can they be chosen by the driver, at runtime? > > > > > no the driver cannot choose them at runtime, as these are the only > > PCIE memory(0/1/2/3) ranges > > in the AXI address space where host memory can be mapped. > > Are they fixed by the PCIe hardware, i.e. could they be looked up by the > driver based on the compatible value? That would be strange for a memory range. Sounds like like 'ranges' though I'm not sure if 'ranges' for an EP makes sense or what that should look like. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel