Thread (1 message) 1 message, 1 author, 2014-03-24

Re: [PATCH v4 5/9] dt-bindings: pci: rcar pcie device tree bindings

From: Lucas Stach <hidden>
Date: 2014-03-24 12:53:47
Also in: linux-arm-kernel, linux-pci, linux-sh

Am Montag, den 24.03.2014, 12:46 +0000 schrieb
Phil.Edworthy-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org:
Hi Ben,

On: 24/03/2014 12:25, Phil wrote:
quoted
Subject: Re: [PATCH v4 5/9] dt-bindings: pci: rcar pcie device tree 
bindings
quoted
Hi Ben,

On: 24/03/2014 12:16, Ben wrote:
quoted
Subject: Re: [PATCH v4 5/9] dt-bindings: pci: rcar pcie device tree 
bindings
quoted
quoted
On 24/03/14 12:04, Phil.Edworthy-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org wrote:
quoted
Hi Lucas,

On: 21/03/2014 15:02, Phil wrote:
quoted
Subject: Re: [PATCH v4 5/9] dt-bindings: pci: rcar pcie device tree
bindings
quoted
Hi Lucas,

On: 21/03/2014 14:31, Lucas wrote:
quoted
Subject: Re: [PATCH v4 5/9] dt-bindings: pci: rcar pcie device 
tree
quoted
quoted
quoted
bindings
quoted
quoted
Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org:
quoted
Hi Lucas,

On 21/03/2014 11:24, Lucas wrote:
quoted
Subject: Re: [PATCH v4 5/9] dt-bindings: pci: rcar pcie device
tree
quoted
quoted
quoted
bindings
quoted
Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:
quoted
This patch adds the bindings for the rcar PCIE driver. The
driver
quoted
quoted
quoted
quoted
quoted
resides under drivers/pci/host/pcie-rcar.c

Signed-off-by: Phil Edworthy <redacted>
I have one question below. If you can answer this with yes after
thinking again about it, this is:

Reviewed-by: Lucas Stach <redacted>
quoted
---
  Documentation/devicetree/bindings/pci/rcar-pci.txt | 40
++++++++++++++++++++++
quoted
quoted
  1 file changed, 40 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/pci/rcar-pci.txt
quoted
quoted
quoted
quoted
quoted
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt
b/
quoted
quoted
quoted
quoted
Documentation/devicetree/bindings/pci/rcar-pci.txt
quoted
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"
quoted
quoted
+- 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
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
+   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
quoted
quoted
quoted
quoted
PCIe bus clock from it's register clock? No need to enable any
other
quoted
quoted
quoted
quoted
clock for PCIe to work?
Yes, just the one clock. The PCIe bus clock is an external clock
dedicated
quoted
quoted
quoted
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
quoted
quoted
quoted
quoted
quoted
and PCIe. After all you don't want to end up unconditionally 
enabling
quoted
quoted
quoted
quoted
quoted
this clock from the board or SoC level just to have PCIe working,
right?
quoted
Ok, I see, I'll need a reference to a board clock, even if it's 
always
quoted
quoted
quoted
on for
quoted
these boards.
One small question...

The patches added the PCIe host controller to two devices, r8a7790 
and
quoted
quoted
quoted
r8a7791. The r8a7790-based Lager board doesn't have the necessary 
hardware
quoted
quoted
quoted
to use PCIe, so should I add a dummy pcie_bus clock to the Lager 
board
quoted
quoted
quoted
dts, even though PCIe is not used?

I'm just wondering what the dts file looks like for a board that 
doesn't
quoted
quoted
quoted
support many interfaces. Does it become littered with dummy clocks 
and
quoted
quoted
quoted
regulators?
The bridge node should be set to disabled by default so it never gets
probed. Any boards that want to use it can over-ride the status to be
enabled.
Ok, thanks.
Hmm, yes it doesn't get probed, but you still get a build problem as the 
DT entry references an clock that doesn't exist. Maybe I'm missing 
something...
If the clock is a board supplied one then you have to supply to clocks
property from the board dts, to get rid of the compile failure. You can
not have phandles in the PCIe node referencing a non-existing clock.

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 |

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help