From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <5209FA05.6090702@gmail.com> Date: Tue, 13 Aug 2013 11:19:01 +0200 From: Sebastian Hesselbarth MIME-Version: 1.0 To: Kumar Gala CC: Russell King , Jason Cooper , Andrew Lunn , Bjorn Helgaas , Thomas Petazzoni , devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, Rob Herring , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO References: <1376333215-12885-1-git-send-email-sebastian.hesselbarth@gmail.com> <1376333215-12885-5-git-send-email-sebastian.hesselbarth@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: [Added DT maintainers directly for a question below] On 08/13/13 02:56, Kumar Gala wrote: > On Aug 12, 2013, at 1:46 PM, Sebastian Hesselbarth wrote: > >> This patch adds a check for DT passed reset-gpios property and deasserts/ >> asserts reset pin on probe/remove with configurable delay. Corresponding >> binding documentation is also updated. >> >> Signed-off-by: Sebastian Hesselbarth [...] >> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt >> index 638673a..f2fa261 100644 >> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt >> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt >> @@ -76,6 +76,8 @@ and the following optional properties: >> - marvell,pcie-lane: the physical PCIe lane number, for ports having >> multiple lanes. If this property is not found, we assume that the >> value is 0. >> +- reset-gpios: optional gpio to PERST# >> +- reset-delay-ms: delay in ms to wait after reset de-assertion > > Both of these should probably be marvell,reset... Kumar, as Thomas already mentioned, non-prefixed "foo-gpios" are quite common. As reset gpios are likely to be common among SoC pci controller setups, I though I'd stick with the non-prefixed property. But I have no strong opinion about it - but let's see how DT jurisdiction will vote :) > Does reset-delay-ms vary per board? I can't remember where the discussion got to about configuration info. Hmm, for Dove SoC, I only have one board to test - but the driver currently is for 4 different SoCs. I just did some quick evaluation of the reset delay required to bring up the device on the D3Plug. Using 10ms was too short, 20ms worked. I guess there will be other SoC/boards requiring different delays but I am fine with hardcoded 20ms and re-introduce reset-delay property only if it is really required. The driver's default is 20ms anyway. >> >> Example: > > It's usually good to update example to show all optional properties. Ok, will add the properties to one of the example ports. Thanks, Sebastian