From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH V5 11/16] dt-bindings: PHY: P2U: Add Tegra 194 P2U block Date: Fri, 26 Apr 2019 13:05:09 -0500 Message-ID: <20190426180509.GB19329@bogus> References: <20190424052004.6270-1-vidyas@nvidia.com> <20190424052004.6270-12-vidyas@nvidia.com> <20190426154519.GA19329@bogus> <20190426160723.GB3204@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190426160723.GB3204@ulmo> Sender: linux-kernel-owner@vger.kernel.org To: Thierry Reding Cc: Vidya Sagar , lorenzo.pieralisi@arm.com, bhelgaas@google.com, mark.rutland@arm.com, jonathanh@nvidia.com, kishon@ti.com, catalin.marinas@arm.com, will.deacon@arm.com, jingoohan1@gmail.com, gustavo.pimentel@synopsys.com, mperttunen@nvidia.com, linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kthota@nvidia.com, mmaddireddy@nvidia.com, sagar.tv@gmail.com List-Id: linux-tegra@vger.kernel.org On Fri, Apr 26, 2019 at 06:07:23PM +0200, Thierry Reding wrote: > On Fri, Apr 26, 2019 at 10:45:19AM -0500, Rob Herring wrote: > > On Wed, Apr 24, 2019 at 10:49:59AM +0530, Vidya Sagar wrote: > > > Add support for Tegra194 P2U (PIPE to UPHY) module block which is a glue > > > module instantiated one for each PCIe lane between Synopsys Designware core > > > based PCIe IP and Universal PHY block. > > > > Missing Sob. > > > > > --- > > > Changes since [v4]: > > > * None > > > > > > Changes since [v3]: > > > * None > > > > > > Changes since [v2]: > > > * Changed node label to reflect new format that includes either 'hsio' or > > > 'nvhs' in its name to reflect which UPHY brick they belong to > > > > > > Changes since [v1]: > > > * This is a new patch in v2 series > > > > > > .../bindings/phy/phy-tegra194-p2u.txt | 28 +++++++++++++++++++ > > > 1 file changed, 28 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt > > > > > > diff --git a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt > > > new file mode 100644 > > > index 000000000000..8b543cba483b > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt > > > @@ -0,0 +1,28 @@ > > > +NVIDIA Tegra194 P2U binding > > > + > > > +Tegra194 has two PHY bricks namely HSIO (High Speed IO) and NVHS (NVIDIA High > > > +Speed) each interfacing with 12 and 8 P2U instances respectively. > > > +A P2U instance is a glue logic between Synopsys DesignWare Core PCIe IP's PIPE > > > +interface and PHY of HSIO/NVHS bricks. Each P2U instance represents one PCIe > > > +lane. > > > + > > > +Required properties: > > > +- compatible: For Tegra19x, must contain "nvidia,tegra194-p2u". > > > +- reg: Should be the physical address space and length of respective each P2U > > > + instance. > > > +- reg-names: Must include the entry "ctl". > > > > -names is pointless when there is only 1. > > We've occasionally done this in the past for other types of resources. > When we did it was to preempt having to verbosely describe exactly what > order -names entries need to be in if ever a new entry was required. > > For example, if we document only one clock for a module and leave out > the clock-names property, then if ever we need to add another clock, it > means that clock-names must be documented in such a way that the "main" > clock (the one that was always documented) would need to be first in the > list of clock-names, so that it's matching entry in the clocks property > is at index 0, because that's effectively what the ABI is. The original clock at index 0 is part of the ABI with or without names as long as that clock is always required. The purpose of '*-names' was to handle cases with multiple combinations of optional entries. That's the exception though and shouldn't be necessary too often. Clocks was an exception because the kernel's clock api required clock names (though only for more than 1). For the rest, everyone loves making up names and bloating their DT. (The last Plumbers had a discussion about replacing DT strings with numbers to shrink them, so it's not a non-issue for some.) In any case, I only point this out if I have other comments and you all can keep it if you want. I'm just not a fan. 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,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT 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 93E49C43219 for ; Fri, 26 Apr 2019 18:05:17 +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 692C220679 for ; Fri, 26 Apr 2019 18:05:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HqvlFm6W" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 692C220679 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=R3UiypxC53/SZi7N5opN1nsZ8QSNVydmf7NlpZjgAx4=; b=HqvlFm6W0oC8/L d/2wb93fr/HCxAwHVvmD5qt4FVga2okhaHNT2rKexSnKjmE04l5sXHr+1/tuBm/6A8NC1o3uh6wAz vWaZZ4iSfDDGN/vnfzLHJIuZMYWEveGRdf/ooe4/zcXHr/2tGyGWBYmG/0qZOke4h8f2rmzjYKJDe PnXnAjquSNS0U0wzrXgDaiT3JEgd5MIVTJ26/rUUpAJxjVajQpSbvlVy2xecEBkiD7jTCow6erGv+ PKui7WYJ/NlEwVK5yR/oJi49K77VUTychFa14dvBEMiKM0ixRa6411nUtERN9NJoatbnRz4h72IKd 7swSBonJDV0x+PixakTg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hK5Do-0000nl-Ex; Fri, 26 Apr 2019 18:05:16 +0000 Received: from mail-ot1-f68.google.com ([209.85.210.68]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hK5Dl-0000md-6I for linux-arm-kernel@lists.infradead.org; Fri, 26 Apr 2019 18:05:14 +0000 Received: by mail-ot1-f68.google.com with SMTP id d24so3375427otl.11 for ; Fri, 26 Apr 2019 11:05:11 -0700 (PDT) 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=zQtkRNUgw/vFCvnSqmhPpYcrqE3+8B2y1PZeuVMpevc=; b=Vv2Olxe1T1WFN4ShmsetcqputWZUJE0/m6eH+ck3WvGvBKSktfwOEh0X2ngFoWSlYb x+ZjI1vLsP81HyDCJLO/P5wb8B8Sq0irNTEwiVDdqwJIXrdDCYWbzKDnWDCJKRtSOoD1 QaPYSwhdgH6AgHLf4rVTa21v/B0cOc7vmv3sU5wwCQuC4Hmmbekltcv8FoTCbnvD9eWo MfOC7s1IxVuVqkdQuprsrwXH5HcftGbXQUNiW50WEeuWPyhnJ7wScshMuwAUE/Donb3b 9DtRzU2RqAtEKyWtaPd85RpXcaqtAuGSrTHZwDn6hyS6SyVDEgsfOBMfVcX3zVYXvWlq 3Yvw== X-Gm-Message-State: APjAAAWj3F93C7R2MXsOIquzFyIfZNtOPdqwhajYRBevuvgV85VK54Xd 9c4xBNqg6SKEsChYRkkShQ== X-Google-Smtp-Source: APXvYqxln9A5A7iSmPQpWDOcLJGBeq023K/7OjLJn8/Ia0ahcazPhqgaXSBOoVduHyvzKGxpC/ItjQ== X-Received: by 2002:a05:6830:1051:: with SMTP id b17mr1064827otp.341.1556301910679; Fri, 26 Apr 2019 11:05:10 -0700 (PDT) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id c3sm1061276otb.13.2019.04.26.11.05.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Apr 2019 11:05:09 -0700 (PDT) Date: Fri, 26 Apr 2019 13:05:09 -0500 From: Rob Herring To: Thierry Reding Subject: Re: [PATCH V5 11/16] dt-bindings: PHY: P2U: Add Tegra 194 P2U block Message-ID: <20190426180509.GB19329@bogus> References: <20190424052004.6270-1-vidyas@nvidia.com> <20190424052004.6270-12-vidyas@nvidia.com> <20190426154519.GA19329@bogus> <20190426160723.GB3204@ulmo> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190426160723.GB3204@ulmo> 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-20190426_110513_234680_69E99B44 X-CRM114-Status: GOOD ( 23.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com, mperttunen@nvidia.com, mmaddireddy@nvidia.com, linux-pci@vger.kernel.org, catalin.marinas@arm.com, Vidya Sagar , will.deacon@arm.com, linux-kernel@vger.kernel.org, kthota@nvidia.com, kishon@ti.com, linux-tegra@vger.kernel.org, gustavo.pimentel@synopsys.com, jingoohan1@gmail.com, bhelgaas@google.com, jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org, sagar.tv@gmail.com 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 Fri, Apr 26, 2019 at 06:07:23PM +0200, Thierry Reding wrote: > On Fri, Apr 26, 2019 at 10:45:19AM -0500, Rob Herring wrote: > > On Wed, Apr 24, 2019 at 10:49:59AM +0530, Vidya Sagar wrote: > > > Add support for Tegra194 P2U (PIPE to UPHY) module block which is a glue > > > module instantiated one for each PCIe lane between Synopsys Designware core > > > based PCIe IP and Universal PHY block. > > > > Missing Sob. > > > > > --- > > > Changes since [v4]: > > > * None > > > > > > Changes since [v3]: > > > * None > > > > > > Changes since [v2]: > > > * Changed node label to reflect new format that includes either 'hsio' or > > > 'nvhs' in its name to reflect which UPHY brick they belong to > > > > > > Changes since [v1]: > > > * This is a new patch in v2 series > > > > > > .../bindings/phy/phy-tegra194-p2u.txt | 28 +++++++++++++++++++ > > > 1 file changed, 28 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt > > > > > > diff --git a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt > > > new file mode 100644 > > > index 000000000000..8b543cba483b > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt > > > @@ -0,0 +1,28 @@ > > > +NVIDIA Tegra194 P2U binding > > > + > > > +Tegra194 has two PHY bricks namely HSIO (High Speed IO) and NVHS (NVIDIA High > > > +Speed) each interfacing with 12 and 8 P2U instances respectively. > > > +A P2U instance is a glue logic between Synopsys DesignWare Core PCIe IP's PIPE > > > +interface and PHY of HSIO/NVHS bricks. Each P2U instance represents one PCIe > > > +lane. > > > + > > > +Required properties: > > > +- compatible: For Tegra19x, must contain "nvidia,tegra194-p2u". > > > +- reg: Should be the physical address space and length of respective each P2U > > > + instance. > > > +- reg-names: Must include the entry "ctl". > > > > -names is pointless when there is only 1. > > We've occasionally done this in the past for other types of resources. > When we did it was to preempt having to verbosely describe exactly what > order -names entries need to be in if ever a new entry was required. > > For example, if we document only one clock for a module and leave out > the clock-names property, then if ever we need to add another clock, it > means that clock-names must be documented in such a way that the "main" > clock (the one that was always documented) would need to be first in the > list of clock-names, so that it's matching entry in the clocks property > is at index 0, because that's effectively what the ABI is. The original clock at index 0 is part of the ABI with or without names as long as that clock is always required. The purpose of '*-names' was to handle cases with multiple combinations of optional entries. That's the exception though and shouldn't be necessary too often. Clocks was an exception because the kernel's clock api required clock names (though only for more than 1). For the rest, everyone loves making up names and bloating their DT. (The last Plumbers had a discussion about replacing DT strings with numbers to shrink them, so it's not a non-issue for some.) In any case, I only point this out if I have other comments and you all can keep it if you want. I'm just not a fan. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel