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=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS autolearn=ham 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 AA038C10F0E for ; Tue, 9 Apr 2019 11:31:05 +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 7406020857 for ; Tue, 9 Apr 2019 11:31:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eq7bvFaV"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="amVCCPKd"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="hvahlhVt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7406020857 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xTZ5Yg3tpalvefzqr7mfcQCNg9Yiu3Hn5gSgl4wqXTg=; b=eq7bvFaVwnT7Diq83acpBNsLV 0XLywYhrzxLEQmg/7OKOsKc2oV3sHJ/+Oqj+9s+ONOYs8eIG/NdL8iRvcJTJeUjCaG8JVWaydggUY mRN++VdqFttH4PLvd4WIV7asarO6ECpdZKDo7NgoUFTyq1CWEiyrWdbCUq3HxURqMe6ubR0XDTsg6 ZdQGMS9iv1BXIwBgE0/E3c67zXCeDqWXpKNFvYEI/lJ1spmRvVV5/QbWKAaT7zvhWUVrZVOj/Hnj+ e0Ww3DooL2Pt6yiBtqMTLX/NAHZhvopBV0rUT1Sjv2MdnY39OOCyvfRYNeQF4D7EHKQP3BKhO/iiT Yt1oOstvg==; 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 1hDoy1-0006Bo-0I; Tue, 09 Apr 2019 11:31:05 +0000 Received: from merlin.infradead.org ([2001:8b0:10b:1231::1]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDoxv-0006BT-8D for linux-arm-kernel@bombadil.infradead.org; Tue, 09 Apr 2019 11:31:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:CC:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=N1nnyvXOfaDuoBPuQK76FcBPj57zRnc3vr5od/I6x6U=; b=amVCCPKd15SQqt9J+QGH7BD4sS Vw4MGJKIQPShDihSlZANtq6tRV+gEfdlTwyqxN5Bd9bGv62MZjX3GINBXTG97KIUYFsrWDHYyaO8a UU9OH0paMSdwLx8NF4ahQgbn4ZIR5Zs1JdAkZ/VY36hmu7lThQgAvYR8PN1i/GmanLylFAls8FbES oCsgl343TIgWjClyOphD5vA+I4kXWNn1nLKCIt/i10TuRHC9NhhRTDBA437vy/SG6whLd9OTD3BzM r3uPcSNQW4/B3b602OA8s0MnUIC78yJJopYLXgO7stnUALCUIZ7KuWXrVX5GmFAlEORfX3jsT4FYk Zh0X5UtA==; Received: from hqemgate16.nvidia.com ([216.228.121.65]) by merlin.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDoc1-0006ci-Bb for linux-arm-kernel@lists.infradead.org; Tue, 09 Apr 2019 11:08:23 +0000 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Tue, 09 Apr 2019 04:08:13 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Tue, 09 Apr 2019 04:08:16 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 09 Apr 2019 04:08:16 -0700 Received: from [10.24.47.181] (10.124.1.5) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 11:08:03 +0000 Subject: Re: [PATCH 05/10] dt-bindings: PCI: tegra: Add device tree support for T194 To: Trent Piepho , "robh@kernel.org" References: <1553613207-3988-1-git-send-email-vidyas@nvidia.com> <1553613207-3988-6-git-send-email-vidyas@nvidia.com> <5ca06149.1c69fb81.720fd.79e1@mx.google.com> <5ef50168-2476-1088-7156-8a4488d7a2e1@nvidia.com> <1554748151.2142.31.camel@impinj.com> X-Nvconfidentiality: public From: Vidya Sagar Message-ID: <3b1539ab-8d51-491d-a8e5-9fe00cc4762b@nvidia.com> Date: Tue, 9 Apr 2019 16:37:59 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1554748151.2142.31.camel@impinj.com> X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL108.nvidia.com (172.18.146.13) To HQMAIL101.nvidia.com (172.20.187.10) Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1554808093; bh=N1nnyvXOfaDuoBPuQK76FcBPj57zRnc3vr5od/I6x6U=; h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=hvahlhVtQCeWq7CH7hdOALCG8JKp7L8ethlfwVW/re0BOpcB//KvY+29hcKE3jOPv hlofuMWi2fOPycxfmpc6fOyhM5BQ5z9979gRqWUyExYT38C1M1BKpYev023FSWKLKL R9F0yUVw39pcMAmZz8nM6OcZlYWhI/KdvGgAfVgGxOnMuVAJW7jG+0nXYubK54HmaH EdjwIy/JBbO55jGSfbmiExvPx9fGRcXuLHsQyRdCGdOJmIxlfFL7tpqf29m2pXJFZY s13nSNDMsE1askMSPbi4Ttr9z4hn6TZlfbSPWvakYTV+mIBwXv/6Z5s5T72Wap/E6o S4aUyd06q3Q/A== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190409_070821_806181_4E9D5CA6 X-CRM114-Status: GOOD ( 43.25 ) 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" , "heiko@sntech.de" , "hayashi.kunihiko@socionext.com" , "maxime.ripard@bootlin.com" , "catalin.marinas@arm.com" , "spujar@nvidia.com" , "liviu.dudau@arm.com" , "kthota@nvidia.com" , "bjorn.andersson@linaro.org" , "bhelgaas@google.com" , "thierry.reding@gmail.com" , "kishon@ti.com" , "stefan.wahren@i2se.com" , "lorenzo.pieralisi@arm.com" , "krzk@kernel.org" , "jonathanh@nvidia.com" , "tiwai@suse.de" , "jagan@amarulasolutions.com" , "linux-pci@vger.kernel.org" , "andy.gross@linaro.org" , "shawn.lin@rock-chips.com" , "devicetree@vger.kernel.org" , "mmaddireddy@nvidia.com" , "marc.w.gonzalez@free.fr" , "will.deacon@arm.com" , "yue.wang@amlogic.com" , "enric.balletbo@collabora.com" , "linux-tegra@vger.kernel.org" , "horms+renesas@verge.net.au" , "mperttunen@nvidia.com" , "ezequiel@collabora.com" , "linux-arm-kernel@lists.infradead.org" , "xiaowei.bao@nxp.com" , "jingoohan1@gmail.com" , "linux-kernel@vger.kernel.org" , "skomatineni@nvidia.com" , "gustavo.pimentel@synopsys.com" , "olof@lixom.net" , "l.stach@pengutronix.de" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 4/8/2019 11:59 PM, Trent Piepho wrote: > On Mon, 2019-04-01 at 16:48 +0530, Vidya Sagar wrote: >> On 3/31/2019 12:12 PM, Rob Herring wrote: >>> On Tue, Mar 26, 2019 at 08:43:22PM +0530, Vidya Sagar wrote: >>>> >>>> +- clock-names: Must include the following entries: >>>> + - core_clk > > Basically every single device has a "core" clock. Yet, there's just > only one device using "core_clk" as the name. So it doesn't seem like > a very good choice. Just "core" is used 186 times. But if you have > just the one clock, then you don't need to provide "clock-names" at > all. Name is changed to 'core' from 'core_clk' in V2 patch series which is already sent out for review. Regarding 'clock-names', I thought it is better to have it this way as we may send patches in future with some more clock names to enable some features. > >>>> +- resets: Must contain an entry for each entry in reset-names. >>>> + See ../reset/reset.txt for details. >>>> +- reset-names: Must include the following entries: >>>> + - core_apb_rst >>>> + - core_rst > > IMHO, it's redundant to name the reset "core reset". We already know > it's a reset. So I scanned the current kernel dts files to see the > convention, and I couldn't find a single driver that uses "*_rst" for > the reset names. "core" is used a number of times, and there are a few > "apb" resets. > > Suggest naming these "core" and "apb". Already changed in V2 patch set. > >>>> +- phys: Must contain a phandle to P2U PHY for each entry in phy-names. >>>> +- phy-names: Must include an entry for each active lane. >>>> + "pcie-p2u-N": where N ranges from 0 to one less than the total number of lanes >>>> +- Controller dependent register offsets >>>> + - nvidia,event-cntr-ctrl: EVENT_COUNTER_CONTROL reg offset >>>> + 0x168 - FPGA >>>> + 0x1a8 - C1, C2 and C3 >>>> + 0x1c4 - C4 >>>> + 0x1d8 - C0 and C5 >>>> + - nvidia,event-cntr-data: EVENT_COUNTER_DATA reg offset >>>> + 0x16c - FPGA >>>> + 0x1ac - C1, C2 and C3 >>>> + 0x1c8 - C4 >>>> + 0x1dc - C0 and C5 > > Does the event counter count events that are not part of pci-e? Looks > like there are lots of empty spaces in the register map we see above > for other things. Seems like the way this should be done is with a > driver for the event counter, and have handle here to an index in the > event counter driver. I think there's a generic driver for something > like this that is just a register array shared between different > devices. These counters are used to count link's entry into different ASPM states and PCIe spec doesn't have any registers defined for this activity. Since different controller instances have these registers placed at different offsets, I'm passing them through device-tree. Since this is Tegra's implementation, I'm not sure if I can use any generic driver and also just for reading these registers, having a separate driver looks overkill to me. > >>>> +- nvidia,controller-id : Controller specific ID >>>> + 0x0 - C0 >>>> + 0x1 - C1 >>>> + 0x2 - C2 >>>> + 0x3 - C3 >>>> + 0x4 - C4 >>>> + 0x5 - C5 > > Do you need this for something in the driver? If you are trying to > enumerate controllers, then the board's aliases node would be the way > to do that. Yes. this is needed to be passed as an argument to BPMP-FW to enable/disable respective controller. > >>>> +- vddio-pex-ctl-supply: Regulator supply for PCIe side band signals >>>> + >>>> +Optional properties: >>>> +- nvidia,max-speed: limits controllers max speed to this value. >>>> + 1 - Gen-1 (2.5 GT/s) >>>> + 2 - Gen-2 (5 GT/s) >>>> + 3 - Gen-3 (8 GT/s) >>>> + 4 - Gen-4 (16 GT/s) >>>> +- nvidia,init-speed: limits controllers init speed to this value. >>>> + 1 - Gen-1 (2. 5 GT/s) >>>> + 2 - Gen-2 (5 GT/s) >>>> + 3 - Gen-3 (8 GT/s) >>>> + 4 - Gen-4 (16 GT/s) >>> >>> Don't we have standard speed properties? >> >> Not that I'm aware of. If you come across any, please do let me know and >> I'll change these. > > This is already in Documentation/devicetree/bindings/pci/pci.txt > > - max-link-speed: > If present this property specifies PCI gen for link capability. Host > drivers could add this as a strategy to avoid unnecessary operation or > unsupported link speed, for instance, trying to do training for > unsupported link speed, etc. Must be '4' for gen4, '3' for gen3, '2' > for gen2, and '1' for gen1. Any other values are invalid. > Yes. Thierry Reding pointed this already and V2 patch set which is out for review has it. Thanks for pointing it though. >>> Why do we need 2 values? >> >> max-speed configures the controller to advertise the speed mentioned through >> this flag, whereas, init-speed gets the link up at this speed and software >> can further take the link speed to a different speed by retraining the link. >> This is to give flexibility to developers depending on the platform. > > It doesn't seem like this is a hardware description then. It seems > like Linux driver configuration. Yes. This is more like a helper for Linux driver to configure hardware to behave in a specific way. I'm waiting for Rob's call whether to keep it or remove it. > >>>> +- nvidia,disable-aspm-states : controls advertisement of ASPM states >>>> + bit-0 to '1' : disables advertisement of ASPM-L0s >>>> + bit-1 to '1' : disables advertisement of ASPM-L1. This also disables >>>> + advertisement of ASPM-L1.1 and ASPM-L1.2 >>>> + bit-2 to '1' : disables advertisement of ASPM-L1.1 >>>> + bit-3 to '1' : disables advertisement of ASPM-L1.2 >>> >>> Seems like these too should be common. >> >> This flag controls the advertisement of different ASPM states by root port. >> Again, I'm not aware of any common method for this. > > Found this one in rockchip. > > Optional Property: > - aspm-no-l0s: RC won't support ASPM L0s. This property is needed if > using 24MHz OSC for RC's PHY. > > Using individual boolean properties would be more device tree style > than encoding bits in a single property. Ok. Again, I'm waiting for Rob's opinion on this and if his views also are same, then, I'll change it to having individual entries for each ASPM state. > >>> >>>> +- nvidia,disable-clock-request : gives a hint to driver that there is no >>>> + CLKREQ signal routing on board >>>> +- nvidia,update-fc-fixup : needs it to improve perf when a platform is designed >>>> + in such a way that it satisfies at least one of the following conditions >>>> + 1. If C0/C4/C5 run at x1/x2 link widths (irrespective of speed and MPS) >>>> + 2. If C0/C1/C2/C3/C4/C5 operate at their respective max link widths and >>> >>> What is Cx? >> >> Cx is the Controller with its ID. >> >>> >>>> + a) speed is Gen-2 and MPS is 256B >>>> + b) speed is >= Gen-3 with any MPS > > Could the driver figure it out on its own if it needs this? Looks like > the rules are defined. Not really. Driver can find out details required here only after the link is established and the programming to be done based on these should take place before going for link up. Its like chicken and egg problem. So, this information is passed through device-tree. > >>>> +- nvidia,cdm-check : Enables CDM checking. For more information, refer Synopsis >>>> + DesignWare Cores PCI Express Controller Databook r4.90a Chapter S.4 > > Should this be snps or dwc property then? In V2 series, I made it as Synopsys DWC property. > >>>> +- nvidia,enable-power-down : Enables power down of respective controller and >>>> + corresponding PLLs if they are not shared by any other entity >>>> +- "nvidia,pex-wake" : Add PEX_WAKE gpio number to provide wake support. > > GPIO number? Shouldn't this be phandle to gpio provider and address of > gpio? Yup. It is phandle to GPIO provider and address of GPIO. Description is misleading here. I'll correct it in my next patch. Thanks for this. > >>>> +- "nvidia,plat-gpios" : Add gpio number that needs to be configured before >>>> + system goes for enumeration. There could be platforms where enabling 3.3V and >>>> + 12V power supplies are done through GPIOs, in which case, list of all such >>>> + GPIOs can be specified through this property. >>> >>> These should be split out to their specific function. >> >> Enabling Power rails is just an example and depending on the platform, there could be >> some on-board muxes which are controlled through GPIOs and all such platform specific >> configuration can be handled through this flag. > > Wouldn't regulator framework be proper place to put enabling power for > device? There is already standard support for adding a phandle to a > regulator to a device to enable the regulator. I've removed it in V2 series already. Based on platform requirement, we'll use regulator framework to add supplies. > >>>> +- "nvidia,aspm-cmrt" : Common Mode Restore time for proper operation of ASPM to >>>> + be specified in microseconds >>>> +- "nvidia,aspm-pwr-on-t" : Power On time for proper operation of ASPM to be >>>> + specified in microseconds >>>> +- "nvidia,aspm-l0s-entrance-latency" : ASPM L0s entrance latency to be specified >>>> + in microseconds >>> >>> properties with units need unit suffixes as defined in >>> property-units.txt. >> >> Done. I'll take care of this in next patch series. >> >>> >>>> + >>>> +Examples: >>>> +========= >>>> + >>>> +Tegra194: >>>> +-------- >>>> + >>>> +SoC DTSI: >>>> + >>>> + pcie@14180000 { >>>> + compatible = "nvidia,tegra194-pcie", "snps,dw-pcie"; >>>> + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8B>; >>>> + reg = <0x00 0x14180000 0x0 0x00020000 /* appl registers (128K) */ >>>> + 0x00 0x38000000 0x0 0x00040000 /* configuration space (256K) */ >>>> + 0x00 0x38040000 0x0 0x00040000>; /* iATU_DMA reg space (256K) */ >>>> + reg-names = "appl", "config", "atu_dma"; >>>> + >>>> + status = "disabled"; >>>> + >>>> + #address-cells = <3>; >>>> + #size-cells = <2>; >>>> + device_type = "pci"; >>>> + num-lanes = <8>; >>>> + linux,pci-domain = <0>; >>>> + >>>> + clocks = <&bpmp TEGRA194_CLK_PEX0_CORE_0>; >>>> + clock-names = "core_clk"; >>>> + >>>> + resets = <&bpmp TEGRA194_RESET_PEX0_CORE_0_APB>, >>>> + <&bpmp TEGRA194_RESET_PEX0_CORE_0>; >>>> + reset-names = "core_apb_rst", "core_rst"; >>>> + >>>> + interrupts = , /* controller interrupt */ >>>> + ; /* MSI interrupt */ >>>> + interrupt-names = "intr", "msi"; >>>> + >>>> + #interrupt-cells = <1>; >>>> + interrupt-map-mask = <0 0 0 0>; >>>> + interrupt-map = <0 0 0 0 &gic 0 72 0x04>; >>>> + >>>> + nvidia,bpmp = <&bpmp>; >>>> + >>>> + nvidia,max-speed = <4>; >>>> + nvidia,disable-aspm-states = <0xf>; >>>> + nvidia,controller-id = <&bpmp 0x0>; >>>> + nvidia,aux-clk-freq = <0x13>; >>>> + nvidia,preset-init = <0x5>; >>>> + nvidia,aspm-cmrt = <0x3C>; >>>> + nvidia,aspm-pwr-on-t = <0x14>; >>>> + nvidia,aspm-l0s-entrance-latency = <0x3>; >>>> + >>>> + bus-range = <0x0 0xff>; >>>> + ranges = <0x81000000 0x0 0x38100000 0x0 0x38100000 0x0 0x00100000 /* downstream I/O (1MB) */ >>>> + 0x82000000 0x0 0x38200000 0x0 0x38200000 0x0 0x01E00000 /* non-prefetchable memory (30MB) */ >>>> + 0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory (16GB) */ >>>> + >>>> + nvidia,cfg-link-cap-l1sub = <0x1c4>; >>>> + nvidia,cap-pl16g-status = <0x174>; >>>> + nvidia,cap-pl16g-cap-off = <0x188>; >>>> + nvidia,event-cntr-ctrl = <0x1d8>; >>>> + nvidia,event-cntr-data = <0x1dc>; >>>> + nvidia,dl-feature-cap = <0x30c>; >>>> + }; >>>> + >>>> +Board DTS: >>>> + >>>> + pcie@14180000 { >>>> + status = "okay"; >>>> + >>>> + vddio-pex-ctl-supply = <&vdd_1v8ao>; >>>> + >>>> + phys = <&p2u_2>, >>>> + <&p2u_3>, >>>> + <&p2u_4>, >>>> + <&p2u_5>; >>>> + phy-names = "pcie-p2u-0", "pcie-p2u-1", "pcie-p2u-2", >>>> + "pcie-p2u-3"; >>>> + }; >>>> 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..cc0de8e8e8db >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt >>>> @@ -0,0 +1,34 @@ >>>> +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-phy-p2u". >>>> +- reg: Should be the physical address space and length of respective each P2U >>>> + instance. >>>> +- reg-names: Must include the entry "base". >>>> + >>>> +Required properties for PHY port node: >>>> +- #phy-cells: Defined by generic PHY bindings. Must be 0. >>>> + >>>> +Refer to phy/phy-bindings.txt for the generic PHY binding properties. >>>> + >>>> +Example: >>>> + >>>> +hsio-p2u { >>>> + compatible = "simple-bus"; >>>> + #address-cells = <2>; >>>> + #size-cells = <2>; >>>> + ranges; >>>> + p2u_0: p2u@03e10000 { >>>> + compatible = "nvidia,tegra194-phy-p2u"; >>>> + reg = <0x0 0x03e10000 0x0 0x00010000>; >>>> + reg-names = "base"; >>>> + >>>> + #phy-cells = <0>; >>>> + }; >>>> +} >>>> -- >>>> 2.7.4 >>>> >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel