| Message ID | 1404133317-25953-2-git-send-email-lee.jones@linaro.org |
|---|---|
| State | New |
| Headers | show |
Hi, On Monday 30 June 2014 06:31 PM, Lee Jones wrote: > The MiPHY365x is a Generic PHY which can serve various SATA or PCIe > devices. It has 2 ports which it can use for either; both SATA, both > PCIe or one of each in any configuration. > > Cc: Kishon Vijay Abraham I <kishon@ti.com> > Acked-by: Mark Rutland <mark.rutland@arm.com> > Acked-by: Alexandre Torgue <alexandre.torgue@st.com> > Signed-off-by: Lee Jones <lee.jones@linaro.org> > --- > .../devicetree/bindings/phy/phy-miphy365x.txt | 76 ++++++++++++++++++++++ > 1 file changed, 76 insertions(+) > create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt > > diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt > new file mode 100644 > index 0000000..d75f300 > --- /dev/null > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt > @@ -0,0 +1,76 @@ > +STMicroelectronics STi MIPHY365x PHY binding > +============================================ > + > +This binding describes a miphy device that is used to control PHY hardware > +for SATA and PCIe. > + > +Required properties: > +- compatible : Should be "st,miphy365x-phy" > +- #phy-cells : Should be 2 (See second example) > + First cell is the port number from: > + - MIPHY_PORT_0 > + - MIPHY_PORT_1 I'm just thinking if we can directly give phandle to the sub-node (channel0/channel1 or port0/port1) we won't need this information in the PHY specifier. This might need some modification in the phy-core but that can be done. > + Second cell is device type from: > + - MIPHY_TYPE_SATA > + - MIPHY_TYPE_PCI > +- reg : Address and length of register sets for each device in > + "reg-names" > +- reg-names : The names of the register addresses corresponding to the > + registers filled in "reg", from: > + - sata0: For SATA port 0 registers > + - sata1: For SATA port 1 registers > + - pcie0: For PCIE port 0 registers > + - pcie1: For PCIE port 1 registers this information should be in the documentation of sub-nodes. Cheers Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Wed, 02 Jul 2014, Kishon Vijay Abraham I wrote: > On Monday 30 June 2014 06:31 PM, Lee Jones wrote: > > The MiPHY365x is a Generic PHY which can serve various SATA or PCIe > > devices. It has 2 ports which it can use for either; both SATA, both > > PCIe or one of each in any configuration. > > > > Cc: Kishon Vijay Abraham I <kishon@ti.com> > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > Acked-by: Alexandre Torgue <alexandre.torgue@st.com> > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > > --- > > .../devicetree/bindings/phy/phy-miphy365x.txt | 76 ++++++++++++++++++++++ > > 1 file changed, 76 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt > > > > diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt > > new file mode 100644 > > index 0000000..d75f300 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt > > @@ -0,0 +1,76 @@ > > +STMicroelectronics STi MIPHY365x PHY binding > > +============================================ > > + > > +This binding describes a miphy device that is used to control PHY hardware > > +for SATA and PCIe. > > + > > +Required properties: > > +- compatible : Should be "st,miphy365x-phy" > > +- #phy-cells : Should be 2 (See second example) > > + First cell is the port number from: > > + - MIPHY_PORT_0 > > + - MIPHY_PORT_1 > > I'm just thinking if we can directly give phandle to the sub-node > (channel0/channel1 or port0/port1) we won't need this information in the PHY > specifier. This might need some modification in the phy-core but that can be done. If we do that, we need a new property to identify the port number. I figured using an existing cell to identify the port would be better than to try an introduce yet another property. > > + Second cell is device type from: > > + - MIPHY_TYPE_SATA > > + - MIPHY_TYPE_PCI > > +- reg : Address and length of register sets for each device in > > + "reg-names" > > +- reg-names : The names of the register addresses corresponding to the > > + registers filled in "reg", from: > > + - sata0: For SATA port 0 registers > > + - sata1: For SATA port 1 registers > > + - pcie0: For PCIE port 0 registers > > + - pcie1: For PCIE port 1 registers > > this information should be in the documentation of sub-nodes. You're right, will fix.
Hi, On Wednesday 02 July 2014 05:36 PM, Lee Jones wrote: > On Wed, 02 Jul 2014, Kishon Vijay Abraham I wrote: >> On Monday 30 June 2014 06:31 PM, Lee Jones wrote: >>> The MiPHY365x is a Generic PHY which can serve various SATA or PCIe >>> devices. It has 2 ports which it can use for either; both SATA, both >>> PCIe or one of each in any configuration. >>> >>> Cc: Kishon Vijay Abraham I <kishon@ti.com> >>> Acked-by: Mark Rutland <mark.rutland@arm.com> >>> Acked-by: Alexandre Torgue <alexandre.torgue@st.com> >>> Signed-off-by: Lee Jones <lee.jones@linaro.org> >>> --- >>> .../devicetree/bindings/phy/phy-miphy365x.txt | 76 ++++++++++++++++++++++ >>> 1 file changed, 76 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt >>> >>> diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt >>> new file mode 100644 >>> index 0000000..d75f300 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt >>> @@ -0,0 +1,76 @@ >>> +STMicroelectronics STi MIPHY365x PHY binding >>> +============================================ >>> + >>> +This binding describes a miphy device that is used to control PHY hardware >>> +for SATA and PCIe. >>> + >>> +Required properties: >>> +- compatible : Should be "st,miphy365x-phy" >>> +- #phy-cells : Should be 2 (See second example) >>> + First cell is the port number from: >>> + - MIPHY_PORT_0 >>> + - MIPHY_PORT_1 >> >> I'm just thinking if we can directly give phandle to the sub-node >> (channel0/channel1 or port0/port1) we won't need this information in the PHY >> specifier. This might need some modification in the phy-core but that can be done. > > If we do that, we need a new property to identify the port number. I > figured using an existing cell to identify the port would be better > than to try an introduce yet another property. If we can directly give phandle to the sub-node where do you think port number would be used? Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt new file mode 100644 index 0000000..d75f300 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt @@ -0,0 +1,76 @@ +STMicroelectronics STi MIPHY365x PHY binding +============================================ + +This binding describes a miphy device that is used to control PHY hardware +for SATA and PCIe. + +Required properties: +- compatible : Should be "st,miphy365x-phy" +- #phy-cells : Should be 2 (See second example) + First cell is the port number from: + - MIPHY_PORT_0 + - MIPHY_PORT_1 + Second cell is device type from: + - MIPHY_TYPE_SATA + - MIPHY_TYPE_PCI +- reg : Address and length of register sets for each device in + "reg-names" +- reg-names : The names of the register addresses corresponding to the + registers filled in "reg", from: + - sata0: For SATA port 0 registers + - sata1: For SATA port 1 registers + - pcie0: For PCIE port 0 registers + - pcie1: For PCIE port 1 registers +- st,syscfg : Should be a phandle of the system configuration register group + which contain the SATA, PCIe mode setting bits + +Optional properties: +- st,sata-gen : Generation of locally attached SATA IP. Expected values + are {1,2,3). If not supplied generation 1 hardware will + be expected +- st,pcie-tx-pol-inv : Bool property to invert the polarity PCIe Tx (Txn/Txp) +- st,sata-tx-pol-inv : Bool property to invert the polarity SATA Tx (Txn/Txp) + +Required nodes : A sub-node is required for each channel the controller + provides. Address range information including the usual + 'reg' and 'reg-names' properties are used inside these + nodes to describe the controller's topology. These nodes + are translated by the driver's .xlate() function. + +Example: + + miphy365x_phy: miphy365x@fe382000 { + compatible = "st,miphy365x-phy"; + st,syscfg = <&syscfg_rear>; + #phy-cells = <2>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + phy_port0: port@fe382000 { + reg = <0xfe382000 0x100>, <0xfe394000 0x100>; + reg-names = "sata", "pcie"; + }; + + phy_port1: port@fe38a000 { + reg = <0xfe38a000 0x100>, <0xfe804000 0x100>; + reg-names = "sata", "pcie"; + }; + }; + +Specifying phy control of devices +================================= + +Device nodes should specify the configuration required in their "phys" +property, containing a phandle to the miphy device node, a port number +and a device type. + +Example: + +#include <dt-bindings/phy/phy-miphy365x.h> + + sata0: sata@fe380000 { + ... + phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>; + ... + };