From: Lucas Stach <l.stach@pengutronix.de>
To: Phil.Edworthy@renesas.com
Cc: devicetree@vger.kernel.org, Simon Horman <horms@verge.net.au>,
linux-sh@vger.kernel.org, linux-pci@vger.kernel.org,
Magnus Damm <magnus.damm@gmail.com>,
Valentine Barshak <valentine.barshak@cogentembedded.com>,
Ben Dooks <ben.dooks@codethink.co.uk>,
Bjorn Helgaas <bhelgaas@google.com>,
LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 5/9] dt-bindings: pci: rcar pcie device tree bindings
Date: Fri, 21 Mar 2014 15:30:13 +0100 [thread overview]
Message-ID: <1395412213.4554.17.camel@weser.hi.pengutronix.de> (raw)
In-Reply-To: <OF03C9E23D.07B7D998-ON80257CA2.004E5877-80257CA2.004E9BFB@eu.necel.com>
Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy@renesas.com:
> Hi Lucas,
>
> On 21/03/2014 11:24, Lucas wrote:
> > Subject: Re: [PATCH v4 5/9] dt-bindings: pci: rcar pcie device tree
> bindings
> >
> > Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:
> > > This patch adds the bindings for the rcar PCIE driver. The driver
> > > resides under drivers/pci/host/pcie-rcar.c
> > >
> > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> >
> > I have one question below. If you can answer this with yes after
> > thinking again about it, this is:
> >
> > Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> > > ---
> > > Documentation/devicetree/bindings/pci/rcar-pci.txt | 40
> ++++++++++++++++++++++
> > > 1 file changed, 40 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/
> > Documentation/devicetree/bindings/pci/rcar-pci.txt
> > > new file mode 100644
> > > index 0000000..0e219b0
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> > > @@ -0,0 +1,40 @@
> > > +* Renesas RCar PCIe interface
> > > +
> > > +Required properties:
> > > +- compatible: should contain one of the following
> > > + "renesas,r8a7779-pcie", "renesas,r8a7790-pcie",
> "renesas,r8a7791-pcie"
> > > +- reg: base addresses and lengths of the pcie controller.
> > > +- #address-cells: set to <3>
> > > +- #size-cells: set to <2>
> > > +- device_type: set to "pci"
> > > +- ranges: ranges for the PCI memory and I/O regions
> > > +- interrupts: interrupt values for MSI interrupt
> > > +- #interrupt-cells: set to <1>
> > > +- interrupt-map-mask and interrupt-map: standard PCI properties
> > > + to define the mapping of the PCIe interface to interrupt
> > > + numbers.
> > > +- clocks: from common clock binding: handle to pci clock.
> > > +- clock-names: from common clock binding: should be "pcie"
> >
> > You really only have one PCIe clock? So the controller is generating the
> > PCIe bus clock from it's register clock? No need to enable any other
> > clock for PCIe to work?
> Yes, just the one clock. The PCIe bus clock is an external clock dedicated
> to PCIe and SATA, and we have no control over it.
>
Is this some kind of always-on clock? If not you probably want a
reference to it from the PCIe driver even if it's shared between SATA
and PCIe. After all you don't want to end up unconditionally enabling
this clock from the board or SoC level just to have PCIe working, right?
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2014-03-21 14:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1395397968-6242-1-git-send-email-phil.edworthy@renesas.com>
2014-03-21 10:32 ` [PATCH v4 5/9] dt-bindings: pci: rcar pcie device tree bindings Phil Edworthy
2014-03-21 11:23 ` Lucas Stach
2014-03-21 14:18 ` Phil.Edworthy
2014-03-21 14:30 ` Lucas Stach [this message]
2014-03-21 15:02 ` Phil.Edworthy
[not found] ` <OFC7DD5DAC.D378B300-ON80257CA2.0051ECEE-80257CA2.00529F98@LocalDomain>
2014-03-24 12:04 ` Phil.Edworthy
2014-03-24 12:15 ` Ben Dooks
2014-03-24 12:25 ` Phil.Edworthy
[not found] ` <OF85DD7B1D.716DE42D-ON80257CA5.00443087-80257CA5.004447DB@LocalDomain>
2014-03-24 12:46 ` Phil.Edworthy
[not found] ` <OF01E3AAFE.D9BF866A-ON80257CA5.0045F63A-80257CA5.00463029-mWMTcI9IYFFWk0Htik3J/w@public.gmane.org>
2014-03-24 12:53 ` Lucas Stach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1395412213.4554.17.camel@weser.hi.pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=Phil.Edworthy@renesas.com \
--cc=ben.dooks@codethink.co.uk \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=valentine.barshak@cogentembedded.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).