* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-12 16:03 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla
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: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
1 file changed, 43 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..fdfa7ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,43 @@
+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 example)
+- reg: Address and length of the register set for the device
+- reg-names: The names of the register addresses corresponding to the
+ registers filled in "reg".
+- st,syscfg : Should be a phandle of the syscfg node.
+
+Example:
+
+ miphy365x_phy: miphy365x@0 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <1>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg= <&syscfg_rear>;
+ };
+
+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>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-12 16:03 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel
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: devicetree at vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
1 file changed, 43 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..fdfa7ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,43 @@
+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 example)
+- reg: Address and length of the register set for the device
+- reg-names: The names of the register addresses corresponding to the
+ registers filled in "reg".
+- st,syscfg : Should be a phandle of the syscfg node.
+
+Example:
+
+ miphy365x_phy: miphy365x at 0 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <1>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg= <&syscfg_rear>;
+ };
+
+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 at fe380000 {
+ ...
+ phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 2/4] phy: miphy365x: Add MiPHY365x header file for DT x Driver defines
2014-02-12 16:03 ` Lee Jones
@ 2014-02-12 16:03 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla
This provides the shared header file which will be reference from both
the MiPHY365x driver and its associated Device Tree node(s).
Cc: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
include/dt-bindings/phy/phy-miphy365x.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 include/dt-bindings/phy/phy-miphy365x.h
diff --git a/include/dt-bindings/phy/phy-miphy365x.h b/include/dt-bindings/phy/phy-miphy365x.h
new file mode 100644
index 0000000..8757c02
--- /dev/null
+++ b/include/dt-bindings/phy/phy-miphy365x.h
@@ -0,0 +1,25 @@
+/*
+ * This header provides constants for the phy framework
+ * based on the STMicroelectronics miphy365x.
+ */
+#ifndef _DT_BINDINGS_PHY_MIPHY
+#define _DT_BINDINGS_PHY_MIPHY
+
+/* Supports 16 ports without a datatype change (u8 & 0xF0). */
+#define MIPHY_PORT_0 0
+#define MIPHY_PORT_1 1
+#define MIPHY_PORT_2 2
+#define MIPHY_PORT_3 3
+
+/* Supports 16 types without a datatype change (u8 & 0x0F). */
+#define MIPHY_TYPE_SHIFT 4
+#define MIPHY_TYPE_SATA (0 << MIPHY_TYPE_SHIFT)
+#define MIPHY_TYPE_PCIE (1 << MIPHY_TYPE_SHIFT)
+#define MIPHY_TYPE_USB (2 << MIPHY_TYPE_SHIFT)
+
+#define MIPHY_SATA_PORT0 (MIPHY_TYPE_SATA) | (MIPHY_PORT_0)
+#define MIPHY_SATA_PORT1 (MIPHY_TYPE_SATA) | (MIPHY_PORT_1)
+#define MIPHY_PCIE_PORT0 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_0)
+#define MIPHY_PCIE_PORT1 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_1)
+
+#endif /* _DT_BINDINGS_PHY_MIPHY */
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 2/4] phy: miphy365x: Add MiPHY365x header file for DT x Driver defines
@ 2014-02-12 16:03 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel
This provides the shared header file which will be reference from both
the MiPHY365x driver and its associated Device Tree node(s).
Cc: devicetree at vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
include/dt-bindings/phy/phy-miphy365x.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 include/dt-bindings/phy/phy-miphy365x.h
diff --git a/include/dt-bindings/phy/phy-miphy365x.h b/include/dt-bindings/phy/phy-miphy365x.h
new file mode 100644
index 0000000..8757c02
--- /dev/null
+++ b/include/dt-bindings/phy/phy-miphy365x.h
@@ -0,0 +1,25 @@
+/*
+ * This header provides constants for the phy framework
+ * based on the STMicroelectronics miphy365x.
+ */
+#ifndef _DT_BINDINGS_PHY_MIPHY
+#define _DT_BINDINGS_PHY_MIPHY
+
+/* Supports 16 ports without a datatype change (u8 & 0xF0). */
+#define MIPHY_PORT_0 0
+#define MIPHY_PORT_1 1
+#define MIPHY_PORT_2 2
+#define MIPHY_PORT_3 3
+
+/* Supports 16 types without a datatype change (u8 & 0x0F). */
+#define MIPHY_TYPE_SHIFT 4
+#define MIPHY_TYPE_SATA (0 << MIPHY_TYPE_SHIFT)
+#define MIPHY_TYPE_PCIE (1 << MIPHY_TYPE_SHIFT)
+#define MIPHY_TYPE_USB (2 << MIPHY_TYPE_SHIFT)
+
+#define MIPHY_SATA_PORT0 (MIPHY_TYPE_SATA) | (MIPHY_PORT_0)
+#define MIPHY_SATA_PORT1 (MIPHY_TYPE_SATA) | (MIPHY_PORT_1)
+#define MIPHY_PCIE_PORT0 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_0)
+#define MIPHY_PCIE_PORT1 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_1)
+
+#endif /* _DT_BINDINGS_PHY_MIPHY */
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 3/4] ARM: DT: STi: Add DT node for MiPHY365x
2014-02-12 16:03 ` Lee Jones
@ 2014-02-12 16:03 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla
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: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/stih416-b2020-revE.dts | 6 +++++-
arch/arm/boot/dts/stih416-b2020.dts | 6 ++++++
arch/arm/boot/dts/stih416.dtsi | 13 +++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts b/arch/arm/boot/dts/stih416-b2020-revE.dts
index a874570..dbe67fa 100644
--- a/arch/arm/boot/dts/stih416-b2020-revE.dts
+++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
@@ -32,6 +32,10 @@
ethernet1: ethernet@fef08000 {
snps,reset-gpio = <&PIO0 7>;
};
- };
+ miphy365x_phy: miphy365x@0 {
+ st,pcie_tx_pol_inv = <1>;
+ st,sata_gen = "gen3";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
index 276f28d..fd9cbad 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -13,4 +13,10 @@
model = "STiH416 B2020";
compatible = "st,stih416", "st,stih416-b2020";
+ soc {
+ miphy365x_phy: miphy365x@0 {
+ st,pcie_tx_pol_inv = <1>;
+ st,sata_gen = "gen3";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 85b8063..9fd8efb 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -9,6 +9,8 @@
#include "stih41x.dtsi"
#include "stih416-clock.dtsi"
#include "stih416-pinctrl.dtsi"
+
+#include <dt-bindings/phy/phy-miphy365x.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset-controller/stih416-resets.h>
/ {
@@ -140,5 +142,16 @@
clocks = <&CLK_S_ICN_REG_0>;
};
+ miphy365x_phy: miphy365x@0 {
+ compatible = "st,miphy365x-phy";
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+
+ #phy-cells = <2>;
+ st,syscfg = <&syscfg_rear>;
+ };
};
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 3/4] ARM: DT: STi: Add DT node for MiPHY365x
@ 2014-02-12 16:03 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel
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: devicetree at vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/stih416-b2020-revE.dts | 6 +++++-
arch/arm/boot/dts/stih416-b2020.dts | 6 ++++++
arch/arm/boot/dts/stih416.dtsi | 13 +++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts b/arch/arm/boot/dts/stih416-b2020-revE.dts
index a874570..dbe67fa 100644
--- a/arch/arm/boot/dts/stih416-b2020-revE.dts
+++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
@@ -32,6 +32,10 @@
ethernet1: ethernet at fef08000 {
snps,reset-gpio = <&PIO0 7>;
};
- };
+ miphy365x_phy: miphy365x at 0 {
+ st,pcie_tx_pol_inv = <1>;
+ st,sata_gen = "gen3";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
index 276f28d..fd9cbad 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -13,4 +13,10 @@
model = "STiH416 B2020";
compatible = "st,stih416", "st,stih416-b2020";
+ soc {
+ miphy365x_phy: miphy365x at 0 {
+ st,pcie_tx_pol_inv = <1>;
+ st,sata_gen = "gen3";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 85b8063..9fd8efb 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -9,6 +9,8 @@
#include "stih41x.dtsi"
#include "stih416-clock.dtsi"
#include "stih416-pinctrl.dtsi"
+
+#include <dt-bindings/phy/phy-miphy365x.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset-controller/stih416-resets.h>
/ {
@@ -140,5 +142,16 @@
clocks = <&CLK_S_ICN_REG_0>;
};
+ miphy365x_phy: miphy365x at 0 {
+ compatible = "st,miphy365x-phy";
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+
+ #phy-cells = <2>;
+ st,syscfg = <&syscfg_rear>;
+ };
};
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
2014-02-12 16:03 ` Lee Jones
@ 2014-02-12 16:03 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, Kishon Vijay Abraham I
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>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/phy/Kconfig | 8 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 643 insertions(+)
create mode 100644 drivers/phy/phy-miphy365x.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..bb2706a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -21,6 +21,14 @@ config PHY_EXYNOS_MIPI_VIDEO
Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P
and EXYNOS SoCs.
+config PHY_MIPHY365X
+ tristate "STMicroelectronics MIPHY365X PHY driver for STiH41x series"
+ depends on ARCH_STI
+ depends on GENERIC_PHY
+ help
+ Enable this to support the miphy transceiver (for SATA/PCIE)
+ that is part of STMicroelectronics STiH41x SoC series.
+
config OMAP_USB2
tristate "OMAP USB2 PHY Driver"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..5879639 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,5 +5,6 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_MIPHY365X) += phy-miphy365x.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
new file mode 100644
index 0000000..c4124e3
--- /dev/null
+++ b/drivers/phy/phy-miphy365x.c
@@ -0,0 +1,634 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * STMicroelectronics PHY driver MiPHY365 (for SoC STiH416).
+ *
+ * Author: Alexandre Torgue <alexandre.torgue@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/clk.h>
+#include <linux/phy/phy.h>
+#include <linux/delay.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/phy/phy-miphy365x.h>
+
+#define HFC_TIMEOUT 50
+
+#define SYSCFG_2521 0x824
+#define SYSCFG_2522 0x828
+#define SYSCFG_PCIE_SATA_MASK BIT(1)
+#define SYSCFG_PCIE_SATA_POS 1
+
+/* MiPHY365x register definitiona */
+#define RESET_REG 0x00
+#define RST_PLL BIT(1)
+#define RST_PLL_CAL BIT(2)
+#define RST_RX BIT(4)
+#define RST_MACRO BIT(7)
+
+#define STATUS_REG 0x01
+#define IDLL_RDY BIT(0)
+#define PLL_RDY BIT(1)
+#define DES_BIT_LOCK BIT(2)
+#define DES_SYMBOL_LOCK BIT(3)
+
+#define CTRL_REG 0x02
+#define TERM_EN BIT(0)
+#define PCI_EN BIT(2)
+#define DES_BIT_LOCK_EN BIT(3)
+#define TX_POL BIT(5)
+
+#define INT_CTRL_REG 0x03
+
+#define BOUNDARY1_REG 0x10
+#define SPDSEL_SEL BIT(0)
+
+#define BOUNDARY3_REG 0x12
+#define TX_SPDSEL_GEN1_VAL 0
+#define TX_SPDSEL_GEN2_VAL 0x01
+#define TX_SPDSEL_GEN3_VAL 0x02
+#define RX_SPDSEL_GEN1_VAL 0
+#define RX_SPDSEL_GEN2_VAL (0x01 << 3)
+#define RX_SPDSEL_GEN3_VAL (0x02 << 3)
+
+#define PCIE_REG 0x16
+
+#define BUF_SEL_REG 0x20
+#define CONF_GEN_SEL_GEN3 0x02
+#define CONF_GEN_SEL_GEN2 0x01
+#define PD_VDDTFILTER BIT(4)
+
+#define TXBUF1_REG 0x21
+#define SWING_VAL 0x04
+#define SWING_VAL_GEN1 0x03
+#define PREEMPH_VAL (0x3 << 5)
+
+#define TXBUF2_REG 0x22
+#define TXSLEW_VAL 0x2
+#define TXSLEW_VAL_GEN1 0x4
+
+#define RXBUF_OFFSET_CTRL_REG 0x23
+
+#define RXBUF_REG 0x25
+#define SDTHRES_VAL 0x01
+#define EQ_ON3 (0x03 << 4)
+#define EQ_ON1 (0x01 << 4)
+
+#define COMP_CTRL1_REG 0x40
+#define START_COMSR BIT(0)
+#define START_COMZC BIT(1)
+#define COMP_AUTO_LOAD BIT(4)
+
+#define COMP_CTRL2_REG 0x41
+#define COMP_2MHZ_RAT_GEN1 0x1e
+#define COMP_2MHZ_RAT 0xf
+
+#define COMP_CTRL3_REG 0x42
+#define COMSR_COMP_REF 0x33
+
+#define COMP_IDLL_REG 0x47
+#define COMZC_IDLL 0x2a
+
+#define PLL_CTRL1_REG 0x50
+#define PLL_START_CAL BIT(0)
+#define BUF_EN BIT(2)
+#define SYNCHRO_TX BIT(3)
+#define SSC_EN BIT(6)
+#define CONFIG_PLL BIT(7)
+
+#define PLL_CTRL2_REG 0x51
+#define BYPASS_PLL_CAL BIT(1)
+
+#define PLL_RAT_REG 0x52
+
+#define PLL_SSC_STEP_MSB_REG 0x56
+#define PLL_SSC_STEP_MSB_VAL 0x03
+
+#define PLL_SSC_STEP_LSB_REG 0x57
+#define PLL_SSC_STEP_LSB_VAL 0x63
+
+#define PLL_SSC_PER_MSB_REG 0x58
+#define PLL_SSC_PER_MSB_VAL 0
+
+#define PLL_SSC_PER_LSB_REG 0x59
+#define PLL_SSC_PER_LSB_VAL 0xf1
+
+#define IDLL_TEST_REG 0x72
+#define START_CLK_HF BIT(6)
+
+#define DES_BITLOCK_REG 0x86
+#define BIT_LOCK_LEVEL 0x01
+#define BIT_LOCK_CNT_512 (0x03 << 5)
+
+static u8 ports[] = { MIPHY_PORT_0, MIPHY_PORT_1 };
+
+struct miphy365x_phy {
+ struct phy *phy;
+ void __iomem *base;
+ void __iomem *sata;
+ void __iomem *pcie;
+ u8 type;
+ u8 port;
+};
+
+struct miphy365x_dev {
+ struct device *dev;
+ struct mutex miphy_mutex;
+ struct miphy365x_phy phys[ARRAY_SIZE(ports)];
+ bool pcie_tx_pol_inv;
+ bool sata_tx_pol_inv;
+ u32 sata_gen;
+ struct regmap *regmap;
+};
+
+enum miphy_sata_gen {
+ SATA_GEN1,
+ SATA_GEN2,
+ SATA_GEN3
+};
+
+static u8 rx_tx_spd[] = {
+ TX_SPDSEL_GEN1_VAL | RX_SPDSEL_GEN1_VAL,
+ TX_SPDSEL_GEN2_VAL | RX_SPDSEL_GEN2_VAL,
+ TX_SPDSEL_GEN3_VAL | RX_SPDSEL_GEN3_VAL
+};
+
+#define miphy365x_phy_to_dev(inst) \
+ container_of((inst), struct miphy365x_dev, phys[(inst)->port]);
+
+/*
+ * This function selects the system configuration,
+ * either two SATA, one SATA and one PCIe, or two PCIe lanes.
+ */
+static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 config = miphy_phy->type | miphy_phy->port;
+ u32 mask = SYSCFG_PCIE_SATA_MASK;
+ u32 reg;
+ bool sata;
+
+ switch (config) {
+ case MIPHY_SATA_PORT0:
+ reg = SYSCFG_2521;
+ sata = true;
+ break;
+ case MIPHY_PCIE_PORT1:
+ reg = SYSCFG_2522;
+ sata = false;
+ break;
+ default:
+ dev_err(miphy_dev->dev, "Configuration not supported\n");
+ return -EINVAL;
+ }
+
+ return regmap_update_bits(miphy_dev->regmap, reg, mask,
+ sata << SYSCFG_PCIE_SATA_POS);
+}
+
+static void miphy365x_phy_init_pcie_port(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 val;
+
+ if (!miphy_dev->pcie_tx_pol_inv)
+ return;
+
+ /* Invert Tx polarity and clear pci_txdetect_pol bit */
+ val = TERM_EN | PCI_EN | DES_BIT_LOCK_EN | TX_POL;
+ writeb_relaxed(val, miphy_phy->base + CTRL_REG);
+ writeb_relaxed(0x00, miphy_phy->base + PCIE_REG);
+}
+
+static inline int miphy365x_phy_hfc_not_rdy(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ int timeout = HFC_TIMEOUT;
+ u8 mask = IDLL_RDY | PLL_RDY;
+ u8 regval;
+
+ do {
+ regval = readb_relaxed(miphy_phy->base + STATUS_REG);
+ usleep_range(2000, 2500);
+ } while (timeout-- && (regval & mask));
+
+ if (timeout < 0) {
+ dev_err(miphy_dev->dev, "HFC ready timeout!\n");
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static inline int miphy365x_phy_rdy(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ int timeout = HFC_TIMEOUT;
+ u8 mask = mask = IDLL_RDY | PLL_RDY;
+ u8 regval;
+
+ do {
+ regval = readb_relaxed(miphy_phy->base + STATUS_REG);
+ usleep_range(2000, 2500);
+ } while (timeout-- && ((regval & mask) != mask));
+
+ if (timeout < 0) {
+ dev_err(miphy_dev->dev, "PHY not ready timeout!\n");
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static inline void miphy365x_phy_set_comp(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 val, mask;
+
+ if (miphy_dev->sata_gen == SATA_GEN1)
+ writeb_relaxed(COMP_2MHZ_RAT_GEN1,
+ miphy_phy->base + COMP_CTRL2_REG);
+ else
+ writeb_relaxed(COMP_2MHZ_RAT,
+ miphy_phy->base + COMP_CTRL2_REG);
+
+ if (miphy_dev->sata_gen != SATA_GEN3) {
+ writeb_relaxed(COMSR_COMP_REF,
+ miphy_phy->base + COMP_CTRL3_REG);
+ /*
+ * Force VCO current to value defined by address 0x5A
+ * and disable PCIe100Mref bit
+ * Enable auto load compensation for pll_i_bias
+ */
+ writeb_relaxed(BYPASS_PLL_CAL, miphy_phy->base + PLL_CTRL2_REG);
+ writeb_relaxed(COMZC_IDLL, miphy_phy->base + COMP_IDLL_REG);
+ }
+
+ /*
+ * Force restart compensation and enable auto load
+ * for Comzc_Tx, Comzc_Rx and Comsr on macro
+ */
+ val = START_COMSR | START_COMZC | COMP_AUTO_LOAD;
+ writeb_relaxed(val, miphy_phy->base + COMP_CTRL1_REG);
+
+ mask = DES_BIT_LOCK | DES_SYMBOL_LOCK;
+ while ((readb_relaxed(miphy_phy->base + COMP_CTRL1_REG) & mask) != mask)
+ cpu_relax();
+}
+
+static inline void miphy365x_phy_set_ssc(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 val;
+
+ /*
+ * SSC Settings. SSC will be enabled through Link
+ * SSC Ampl. = 0.4%
+ * SSC Freq = 31KHz
+ */
+ writeb_relaxed(PLL_SSC_STEP_MSB_VAL,
+ miphy_phy->base + PLL_SSC_STEP_MSB_REG);
+ writeb_relaxed(PLL_SSC_STEP_LSB_VAL,
+ miphy_phy->base + PLL_SSC_STEP_LSB_REG);
+ writeb_relaxed(PLL_SSC_PER_MSB_VAL,
+ miphy_phy->base + PLL_SSC_PER_MSB_REG);
+ writeb_relaxed(PLL_SSC_PER_LSB_VAL,
+ miphy_phy->base + PLL_SSC_PER_LSB_REG);
+
+ /* SSC Settings complete */
+ if (miphy_dev->sata_gen == SATA_GEN1) {
+ val = PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
+ writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
+ } else {
+ val = SSC_EN | PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
+ writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
+ }
+}
+
+static int miphy365x_phy_init_sata_port(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ int ret;
+ u8 val;
+
+ /*
+ * Force PHY macro reset, PLL calibration reset, PLL reset
+ * and assert Deserializer Reset
+ */
+ val = RST_PLL | RST_PLL_CAL | RST_RX | RST_MACRO;
+ writeb_relaxed(val, miphy_phy->base + RESET_REG);
+
+ if (miphy_dev->sata_tx_pol_inv)
+ writeb_relaxed(TX_POL, miphy_phy->base + CTRL_REG);
+
+ /*
+ * Force macro1 to use rx_lspd, tx_lspd
+ * Force Rx_Clock on first I-DLL phase
+ * Force Des in HP mode on macro, rx_lspd, tx_lspd for Gen2/3
+ */
+ writeb_relaxed(SPDSEL_SEL, miphy_phy->base + BOUNDARY1_REG);
+ writeb_relaxed(START_CLK_HF, miphy_phy->base + IDLL_TEST_REG);
+ val = rx_tx_spd[miphy_dev->sata_gen];
+ writeb_relaxed(val, miphy_phy->base + BOUNDARY3_REG);
+
+ /* Wait for HFC_READY = 0 */
+ ret = miphy365x_phy_hfc_not_rdy(miphy_phy, miphy_dev);
+ if (ret)
+ return ret;
+
+ /* Compensation Recalibration */
+ miphy365x_phy_set_comp(miphy_phy, miphy_dev);
+
+ switch (miphy_dev->sata_gen) {
+ case SATA_GEN3:
+ /*
+ * TX Swing target 550-600mv peak to peak diff
+ * Tx Slew target 90-110ps rising/falling time
+ * Rx Eq ON3, Sigdet threshold SDTH1
+ */
+ val = PD_VDDTFILTER | CONF_GEN_SEL_GEN3;
+ writeb_relaxed(val, miphy_phy->base + BUF_SEL_REG);
+ val = SWING_VAL | PREEMPH_VAL;
+ writeb_relaxed(val, miphy_phy->base + TXBUF1_REG);
+ writeb_relaxed(TXSLEW_VAL, miphy_phy->base + TXBUF2_REG);
+ writeb_relaxed(0x00, miphy_phy->base + RXBUF_OFFSET_CTRL_REG);
+ val = SDTHRES_VAL | EQ_ON3;
+ writeb_relaxed(val, miphy_phy->base + RXBUF_REG);
+ break;
+ case SATA_GEN2:
+ /*
+ * conf gen sel=0x1 to program Gen2 banked registers
+ * VDDT filter ON
+ * Tx Swing target 550-600mV peak-to-peak diff
+ * Tx Slew target 90-110 ps rising/falling time
+ * RX Equalization ON1, Sigdet threshold SDTH1
+ */
+ writeb_relaxed(CONF_GEN_SEL_GEN2,
+ miphy_phy->base + BUF_SEL_REG);
+ writeb_relaxed(SWING_VAL, miphy_phy->base + TXBUF1_REG);
+ writeb_relaxed(TXSLEW_VAL, miphy_phy->base + TXBUF2_REG);
+ val = SDTHRES_VAL | EQ_ON1;
+ writeb_relaxed(val, miphy_phy->base + RXBUF_REG);
+ break;
+ case SATA_GEN1:
+ /*
+ * conf gen sel = 00b to program Gen1 banked registers
+ * VDDT filter ON
+ * Tx Swing target 500-550mV peak-to-peak diff
+ * Tx Slew target120-140 ps rising/falling time
+ */
+ writeb_relaxed(PD_VDDTFILTER, miphy_phy->base + BUF_SEL_REG);
+ writeb_relaxed(SWING_VAL_GEN1, miphy_phy->base + TXBUF1_REG);
+ writeb_relaxed(TXSLEW_VAL_GEN1, miphy_phy->base + TXBUF2_REG);
+ break;
+ default:
+ break;
+ }
+
+ /* Force Macro1 in partial mode & release pll cal reset */
+ writeb_relaxed(RST_RX, miphy_phy->base + RESET_REG);
+ usleep_range(100, 150);
+
+ miphy365x_phy_set_ssc(miphy_phy, miphy_dev);
+
+ /* Wait for phy_ready */
+ ret = miphy365x_phy_rdy(miphy_phy, miphy_dev);
+ if (ret)
+ return ret;
+
+ /*
+ * Enable macro1 to use rx_lspd & tx_lspd
+ * Release Rx_Clock on first I-DLL phase on macro1
+ * Assert deserializer reset
+ * des_bit_lock_en is set
+ * bit lock detection strength
+ * Deassert deserializer reset
+ */
+ writeb_relaxed(0x00, miphy_phy->base + BOUNDARY1_REG);
+ writeb_relaxed(0x00, miphy_phy->base + IDLL_TEST_REG);
+ writeb_relaxed(RST_RX, miphy_phy->base + RESET_REG);
+ val = miphy_dev->sata_tx_pol_inv ?
+ (TX_POL | DES_BIT_LOCK_EN) : DES_BIT_LOCK_EN;
+ writeb_relaxed(val, miphy_phy->base + CTRL_REG);
+
+ val = BIT_LOCK_CNT_512 | BIT_LOCK_LEVEL;
+ writeb_relaxed(val, miphy_phy->base + DES_BITLOCK_REG);
+ writeb_relaxed(0x00, miphy_phy->base + RESET_REG);
+
+ return 0;
+}
+
+static int miphy365x_phy_init(struct phy *phy)
+{
+ int ret = 0;
+ struct miphy365x_phy *miphy_phy = phy_get_drvdata(phy);
+ struct miphy365x_dev *miphy_dev = miphy365x_phy_to_dev(miphy_phy);
+
+ mutex_lock(&miphy_dev->miphy_mutex);
+
+ ret = miphy365x_set_path(miphy_phy, miphy_dev);
+ if (ret) {
+ mutex_unlock(&miphy_dev->miphy_mutex);
+ return ret;
+ }
+
+ /* Initialise Miphy for PCIe or SATA */
+ if (miphy_phy->type == MIPHY_TYPE_PCIE)
+ miphy365x_phy_init_pcie_port(miphy_phy, miphy_dev);
+ else
+ ret = miphy365x_phy_init_sata_port(miphy_phy, miphy_dev);
+
+ mutex_unlock(&miphy_dev->miphy_mutex);
+
+ return ret;
+}
+
+static int miphy365x_phy_power_on(struct phy *phy)
+{
+ return 0;
+}
+
+static int miphy365x_phy_power_off(struct phy *phy)
+{
+ return 0;
+}
+
+static struct phy *miphy365x_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct miphy365x_dev *state = dev_get_drvdata(dev);
+ u8 port = args->args[0];
+ u8 type = args->args[1];
+
+ if (WARN_ON(port >= ARRAY_SIZE(ports)))
+ return ERR_PTR(-EINVAL);
+
+ if (type == MIPHY_TYPE_SATA)
+ state->phys[port].base = state->phys[port].sata;
+ else if (type == MIPHY_TYPE_PCIE)
+ state->phys[port].base = state->phys[port].pcie;
+ else {
+ WARN(1, "Invalid type specified in DT");
+ return ERR_PTR(-EINVAL);
+ }
+
+ state->phys[port].type = type;
+
+ return state->phys[port].phy;
+}
+
+static struct phy_ops miphy365x_phy_ops = {
+ .init = miphy365x_phy_init,
+ .power_on = miphy365x_phy_power_on,
+ .power_off = miphy365x_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
+ struct miphy365x_phy *phy, u8 port)
+{
+ struct resource *res;
+ char sata[16];
+ char pcie[16];
+
+ sprintf(sata, "sata%d", port);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, sata);
+ if (!res)
+ return -ENODEV;
+
+ phy->sata = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (!phy->sata)
+ return -ENOMEM;
+
+ sprintf(pcie, "pcie%d", port);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pcie);
+ if (!res)
+ return -ENODEV;
+
+ phy->pcie = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (!phy->pcie)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int miphy365x_phy_of_probe(struct device_node *np,
+ struct miphy365x_dev *phy_dev)
+{
+ const char *sata_gen;
+
+ phy_dev->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+ if (IS_ERR(phy_dev->regmap)) {
+ dev_err(phy_dev->dev, "No syscfg phandle specified\n");
+ return PTR_ERR(phy_dev->regmap);
+ }
+
+ /* Default */
+ phy_dev->sata_gen = SATA_GEN1;
+
+ of_property_read_string(np, "st,sata_gen", &sata_gen);
+ if (sata_gen) {
+ if (!strcmp(sata_gen, "gen3"))
+ phy_dev->sata_gen = SATA_GEN3;
+ else if (!strcmp(sata_gen, "gen2"))
+ phy_dev->sata_gen = SATA_GEN2;
+ }
+
+ phy_dev->pcie_tx_pol_inv =
+ of_property_read_bool(np, "st,pcie_tx_pol_inv");
+
+ phy_dev->sata_tx_pol_inv =
+ of_property_read_bool(np, "st,sata_tx_pol_inv");
+
+ return 0;
+}
+
+static int miphy365x_phy_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct miphy365x_dev *phy_dev;
+ struct device *dev = &pdev->dev;
+ struct phy_provider *provider;
+ u8 port;
+ int ret;
+
+ if (!np) {
+ dev_err(dev, "No DT found\n");
+ return -EINVAL;
+ }
+
+ phy_dev = devm_kzalloc(dev, sizeof(*phy_dev), GFP_KERNEL);
+ if (!phy_dev)
+ return -ENOMEM;
+
+ ret = miphy365x_phy_of_probe(np, phy_dev);
+ if (ret)
+ return ret;
+
+ phy_dev->dev = dev;
+
+ dev_set_drvdata(dev, phy_dev);
+
+ mutex_init(&phy_dev->miphy_mutex);
+
+ provider = devm_of_phy_provider_register(dev, miphy365x_phy_xlate);
+ if (IS_ERR(provider))
+ return PTR_ERR(provider);
+
+ for (port = 0; port < ARRAY_SIZE(ports); port++) {
+ struct phy *phy;
+
+ phy = devm_phy_create(dev, &miphy365x_phy_ops, NULL);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create PHY on port %d\n", port);
+ return PTR_ERR(phy);
+ }
+
+ phy_dev->phys[port].phy = phy;
+ phy_dev->phys[port].port = port;
+
+ ret = miphy365x_phy_get_base_addr(pdev,
+ &phy_dev->phys[port], port);
+ if (ret)
+ return ret;
+
+ phy_set_drvdata(phy, &phy_dev->phys[port]);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id miphy365x_phy_of_match[] = {
+ { .compatible = "st,miphy365x-phy", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, miphy365x_phy_of_match);
+
+static struct platform_driver miphy365x_phy_driver = {
+ .probe = miphy365x_phy_probe,
+ .driver = {
+ .name = "miphy365x-phy",
+ .owner = THIS_MODULE,
+ .of_match_table = miphy365x_phy_of_match,
+ }
+};
+module_platform_driver(miphy365x_phy_driver);
+
+MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics miphy365x driver");
+MODULE_LICENSE("GPL v2");
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
@ 2014-02-12 16:03 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel
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>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/phy/Kconfig | 8 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 643 insertions(+)
create mode 100644 drivers/phy/phy-miphy365x.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..bb2706a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -21,6 +21,14 @@ config PHY_EXYNOS_MIPI_VIDEO
Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P
and EXYNOS SoCs.
+config PHY_MIPHY365X
+ tristate "STMicroelectronics MIPHY365X PHY driver for STiH41x series"
+ depends on ARCH_STI
+ depends on GENERIC_PHY
+ help
+ Enable this to support the miphy transceiver (for SATA/PCIE)
+ that is part of STMicroelectronics STiH41x SoC series.
+
config OMAP_USB2
tristate "OMAP USB2 PHY Driver"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..5879639 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,5 +5,6 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_MIPHY365X) += phy-miphy365x.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
new file mode 100644
index 0000000..c4124e3
--- /dev/null
+++ b/drivers/phy/phy-miphy365x.c
@@ -0,0 +1,634 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * STMicroelectronics PHY driver MiPHY365 (for SoC STiH416).
+ *
+ * Author: Alexandre Torgue <alexandre.torgue@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/clk.h>
+#include <linux/phy/phy.h>
+#include <linux/delay.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/phy/phy-miphy365x.h>
+
+#define HFC_TIMEOUT 50
+
+#define SYSCFG_2521 0x824
+#define SYSCFG_2522 0x828
+#define SYSCFG_PCIE_SATA_MASK BIT(1)
+#define SYSCFG_PCIE_SATA_POS 1
+
+/* MiPHY365x register definitiona */
+#define RESET_REG 0x00
+#define RST_PLL BIT(1)
+#define RST_PLL_CAL BIT(2)
+#define RST_RX BIT(4)
+#define RST_MACRO BIT(7)
+
+#define STATUS_REG 0x01
+#define IDLL_RDY BIT(0)
+#define PLL_RDY BIT(1)
+#define DES_BIT_LOCK BIT(2)
+#define DES_SYMBOL_LOCK BIT(3)
+
+#define CTRL_REG 0x02
+#define TERM_EN BIT(0)
+#define PCI_EN BIT(2)
+#define DES_BIT_LOCK_EN BIT(3)
+#define TX_POL BIT(5)
+
+#define INT_CTRL_REG 0x03
+
+#define BOUNDARY1_REG 0x10
+#define SPDSEL_SEL BIT(0)
+
+#define BOUNDARY3_REG 0x12
+#define TX_SPDSEL_GEN1_VAL 0
+#define TX_SPDSEL_GEN2_VAL 0x01
+#define TX_SPDSEL_GEN3_VAL 0x02
+#define RX_SPDSEL_GEN1_VAL 0
+#define RX_SPDSEL_GEN2_VAL (0x01 << 3)
+#define RX_SPDSEL_GEN3_VAL (0x02 << 3)
+
+#define PCIE_REG 0x16
+
+#define BUF_SEL_REG 0x20
+#define CONF_GEN_SEL_GEN3 0x02
+#define CONF_GEN_SEL_GEN2 0x01
+#define PD_VDDTFILTER BIT(4)
+
+#define TXBUF1_REG 0x21
+#define SWING_VAL 0x04
+#define SWING_VAL_GEN1 0x03
+#define PREEMPH_VAL (0x3 << 5)
+
+#define TXBUF2_REG 0x22
+#define TXSLEW_VAL 0x2
+#define TXSLEW_VAL_GEN1 0x4
+
+#define RXBUF_OFFSET_CTRL_REG 0x23
+
+#define RXBUF_REG 0x25
+#define SDTHRES_VAL 0x01
+#define EQ_ON3 (0x03 << 4)
+#define EQ_ON1 (0x01 << 4)
+
+#define COMP_CTRL1_REG 0x40
+#define START_COMSR BIT(0)
+#define START_COMZC BIT(1)
+#define COMP_AUTO_LOAD BIT(4)
+
+#define COMP_CTRL2_REG 0x41
+#define COMP_2MHZ_RAT_GEN1 0x1e
+#define COMP_2MHZ_RAT 0xf
+
+#define COMP_CTRL3_REG 0x42
+#define COMSR_COMP_REF 0x33
+
+#define COMP_IDLL_REG 0x47
+#define COMZC_IDLL 0x2a
+
+#define PLL_CTRL1_REG 0x50
+#define PLL_START_CAL BIT(0)
+#define BUF_EN BIT(2)
+#define SYNCHRO_TX BIT(3)
+#define SSC_EN BIT(6)
+#define CONFIG_PLL BIT(7)
+
+#define PLL_CTRL2_REG 0x51
+#define BYPASS_PLL_CAL BIT(1)
+
+#define PLL_RAT_REG 0x52
+
+#define PLL_SSC_STEP_MSB_REG 0x56
+#define PLL_SSC_STEP_MSB_VAL 0x03
+
+#define PLL_SSC_STEP_LSB_REG 0x57
+#define PLL_SSC_STEP_LSB_VAL 0x63
+
+#define PLL_SSC_PER_MSB_REG 0x58
+#define PLL_SSC_PER_MSB_VAL 0
+
+#define PLL_SSC_PER_LSB_REG 0x59
+#define PLL_SSC_PER_LSB_VAL 0xf1
+
+#define IDLL_TEST_REG 0x72
+#define START_CLK_HF BIT(6)
+
+#define DES_BITLOCK_REG 0x86
+#define BIT_LOCK_LEVEL 0x01
+#define BIT_LOCK_CNT_512 (0x03 << 5)
+
+static u8 ports[] = { MIPHY_PORT_0, MIPHY_PORT_1 };
+
+struct miphy365x_phy {
+ struct phy *phy;
+ void __iomem *base;
+ void __iomem *sata;
+ void __iomem *pcie;
+ u8 type;
+ u8 port;
+};
+
+struct miphy365x_dev {
+ struct device *dev;
+ struct mutex miphy_mutex;
+ struct miphy365x_phy phys[ARRAY_SIZE(ports)];
+ bool pcie_tx_pol_inv;
+ bool sata_tx_pol_inv;
+ u32 sata_gen;
+ struct regmap *regmap;
+};
+
+enum miphy_sata_gen {
+ SATA_GEN1,
+ SATA_GEN2,
+ SATA_GEN3
+};
+
+static u8 rx_tx_spd[] = {
+ TX_SPDSEL_GEN1_VAL | RX_SPDSEL_GEN1_VAL,
+ TX_SPDSEL_GEN2_VAL | RX_SPDSEL_GEN2_VAL,
+ TX_SPDSEL_GEN3_VAL | RX_SPDSEL_GEN3_VAL
+};
+
+#define miphy365x_phy_to_dev(inst) \
+ container_of((inst), struct miphy365x_dev, phys[(inst)->port]);
+
+/*
+ * This function selects the system configuration,
+ * either two SATA, one SATA and one PCIe, or two PCIe lanes.
+ */
+static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 config = miphy_phy->type | miphy_phy->port;
+ u32 mask = SYSCFG_PCIE_SATA_MASK;
+ u32 reg;
+ bool sata;
+
+ switch (config) {
+ case MIPHY_SATA_PORT0:
+ reg = SYSCFG_2521;
+ sata = true;
+ break;
+ case MIPHY_PCIE_PORT1:
+ reg = SYSCFG_2522;
+ sata = false;
+ break;
+ default:
+ dev_err(miphy_dev->dev, "Configuration not supported\n");
+ return -EINVAL;
+ }
+
+ return regmap_update_bits(miphy_dev->regmap, reg, mask,
+ sata << SYSCFG_PCIE_SATA_POS);
+}
+
+static void miphy365x_phy_init_pcie_port(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 val;
+
+ if (!miphy_dev->pcie_tx_pol_inv)
+ return;
+
+ /* Invert Tx polarity and clear pci_txdetect_pol bit */
+ val = TERM_EN | PCI_EN | DES_BIT_LOCK_EN | TX_POL;
+ writeb_relaxed(val, miphy_phy->base + CTRL_REG);
+ writeb_relaxed(0x00, miphy_phy->base + PCIE_REG);
+}
+
+static inline int miphy365x_phy_hfc_not_rdy(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ int timeout = HFC_TIMEOUT;
+ u8 mask = IDLL_RDY | PLL_RDY;
+ u8 regval;
+
+ do {
+ regval = readb_relaxed(miphy_phy->base + STATUS_REG);
+ usleep_range(2000, 2500);
+ } while (timeout-- && (regval & mask));
+
+ if (timeout < 0) {
+ dev_err(miphy_dev->dev, "HFC ready timeout!\n");
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static inline int miphy365x_phy_rdy(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ int timeout = HFC_TIMEOUT;
+ u8 mask = mask = IDLL_RDY | PLL_RDY;
+ u8 regval;
+
+ do {
+ regval = readb_relaxed(miphy_phy->base + STATUS_REG);
+ usleep_range(2000, 2500);
+ } while (timeout-- && ((regval & mask) != mask));
+
+ if (timeout < 0) {
+ dev_err(miphy_dev->dev, "PHY not ready timeout!\n");
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static inline void miphy365x_phy_set_comp(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 val, mask;
+
+ if (miphy_dev->sata_gen == SATA_GEN1)
+ writeb_relaxed(COMP_2MHZ_RAT_GEN1,
+ miphy_phy->base + COMP_CTRL2_REG);
+ else
+ writeb_relaxed(COMP_2MHZ_RAT,
+ miphy_phy->base + COMP_CTRL2_REG);
+
+ if (miphy_dev->sata_gen != SATA_GEN3) {
+ writeb_relaxed(COMSR_COMP_REF,
+ miphy_phy->base + COMP_CTRL3_REG);
+ /*
+ * Force VCO current to value defined by address 0x5A
+ * and disable PCIe100Mref bit
+ * Enable auto load compensation for pll_i_bias
+ */
+ writeb_relaxed(BYPASS_PLL_CAL, miphy_phy->base + PLL_CTRL2_REG);
+ writeb_relaxed(COMZC_IDLL, miphy_phy->base + COMP_IDLL_REG);
+ }
+
+ /*
+ * Force restart compensation and enable auto load
+ * for Comzc_Tx, Comzc_Rx and Comsr on macro
+ */
+ val = START_COMSR | START_COMZC | COMP_AUTO_LOAD;
+ writeb_relaxed(val, miphy_phy->base + COMP_CTRL1_REG);
+
+ mask = DES_BIT_LOCK | DES_SYMBOL_LOCK;
+ while ((readb_relaxed(miphy_phy->base + COMP_CTRL1_REG) & mask) != mask)
+ cpu_relax();
+}
+
+static inline void miphy365x_phy_set_ssc(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 val;
+
+ /*
+ * SSC Settings. SSC will be enabled through Link
+ * SSC Ampl. = 0.4%
+ * SSC Freq = 31KHz
+ */
+ writeb_relaxed(PLL_SSC_STEP_MSB_VAL,
+ miphy_phy->base + PLL_SSC_STEP_MSB_REG);
+ writeb_relaxed(PLL_SSC_STEP_LSB_VAL,
+ miphy_phy->base + PLL_SSC_STEP_LSB_REG);
+ writeb_relaxed(PLL_SSC_PER_MSB_VAL,
+ miphy_phy->base + PLL_SSC_PER_MSB_REG);
+ writeb_relaxed(PLL_SSC_PER_LSB_VAL,
+ miphy_phy->base + PLL_SSC_PER_LSB_REG);
+
+ /* SSC Settings complete */
+ if (miphy_dev->sata_gen == SATA_GEN1) {
+ val = PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
+ writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
+ } else {
+ val = SSC_EN | PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
+ writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
+ }
+}
+
+static int miphy365x_phy_init_sata_port(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ int ret;
+ u8 val;
+
+ /*
+ * Force PHY macro reset, PLL calibration reset, PLL reset
+ * and assert Deserializer Reset
+ */
+ val = RST_PLL | RST_PLL_CAL | RST_RX | RST_MACRO;
+ writeb_relaxed(val, miphy_phy->base + RESET_REG);
+
+ if (miphy_dev->sata_tx_pol_inv)
+ writeb_relaxed(TX_POL, miphy_phy->base + CTRL_REG);
+
+ /*
+ * Force macro1 to use rx_lspd, tx_lspd
+ * Force Rx_Clock on first I-DLL phase
+ * Force Des in HP mode on macro, rx_lspd, tx_lspd for Gen2/3
+ */
+ writeb_relaxed(SPDSEL_SEL, miphy_phy->base + BOUNDARY1_REG);
+ writeb_relaxed(START_CLK_HF, miphy_phy->base + IDLL_TEST_REG);
+ val = rx_tx_spd[miphy_dev->sata_gen];
+ writeb_relaxed(val, miphy_phy->base + BOUNDARY3_REG);
+
+ /* Wait for HFC_READY = 0 */
+ ret = miphy365x_phy_hfc_not_rdy(miphy_phy, miphy_dev);
+ if (ret)
+ return ret;
+
+ /* Compensation Recalibration */
+ miphy365x_phy_set_comp(miphy_phy, miphy_dev);
+
+ switch (miphy_dev->sata_gen) {
+ case SATA_GEN3:
+ /*
+ * TX Swing target 550-600mv peak to peak diff
+ * Tx Slew target 90-110ps rising/falling time
+ * Rx Eq ON3, Sigdet threshold SDTH1
+ */
+ val = PD_VDDTFILTER | CONF_GEN_SEL_GEN3;
+ writeb_relaxed(val, miphy_phy->base + BUF_SEL_REG);
+ val = SWING_VAL | PREEMPH_VAL;
+ writeb_relaxed(val, miphy_phy->base + TXBUF1_REG);
+ writeb_relaxed(TXSLEW_VAL, miphy_phy->base + TXBUF2_REG);
+ writeb_relaxed(0x00, miphy_phy->base + RXBUF_OFFSET_CTRL_REG);
+ val = SDTHRES_VAL | EQ_ON3;
+ writeb_relaxed(val, miphy_phy->base + RXBUF_REG);
+ break;
+ case SATA_GEN2:
+ /*
+ * conf gen sel=0x1 to program Gen2 banked registers
+ * VDDT filter ON
+ * Tx Swing target 550-600mV peak-to-peak diff
+ * Tx Slew target 90-110 ps rising/falling time
+ * RX Equalization ON1, Sigdet threshold SDTH1
+ */
+ writeb_relaxed(CONF_GEN_SEL_GEN2,
+ miphy_phy->base + BUF_SEL_REG);
+ writeb_relaxed(SWING_VAL, miphy_phy->base + TXBUF1_REG);
+ writeb_relaxed(TXSLEW_VAL, miphy_phy->base + TXBUF2_REG);
+ val = SDTHRES_VAL | EQ_ON1;
+ writeb_relaxed(val, miphy_phy->base + RXBUF_REG);
+ break;
+ case SATA_GEN1:
+ /*
+ * conf gen sel = 00b to program Gen1 banked registers
+ * VDDT filter ON
+ * Tx Swing target 500-550mV peak-to-peak diff
+ * Tx Slew target120-140 ps rising/falling time
+ */
+ writeb_relaxed(PD_VDDTFILTER, miphy_phy->base + BUF_SEL_REG);
+ writeb_relaxed(SWING_VAL_GEN1, miphy_phy->base + TXBUF1_REG);
+ writeb_relaxed(TXSLEW_VAL_GEN1, miphy_phy->base + TXBUF2_REG);
+ break;
+ default:
+ break;
+ }
+
+ /* Force Macro1 in partial mode & release pll cal reset */
+ writeb_relaxed(RST_RX, miphy_phy->base + RESET_REG);
+ usleep_range(100, 150);
+
+ miphy365x_phy_set_ssc(miphy_phy, miphy_dev);
+
+ /* Wait for phy_ready */
+ ret = miphy365x_phy_rdy(miphy_phy, miphy_dev);
+ if (ret)
+ return ret;
+
+ /*
+ * Enable macro1 to use rx_lspd & tx_lspd
+ * Release Rx_Clock on first I-DLL phase on macro1
+ * Assert deserializer reset
+ * des_bit_lock_en is set
+ * bit lock detection strength
+ * Deassert deserializer reset
+ */
+ writeb_relaxed(0x00, miphy_phy->base + BOUNDARY1_REG);
+ writeb_relaxed(0x00, miphy_phy->base + IDLL_TEST_REG);
+ writeb_relaxed(RST_RX, miphy_phy->base + RESET_REG);
+ val = miphy_dev->sata_tx_pol_inv ?
+ (TX_POL | DES_BIT_LOCK_EN) : DES_BIT_LOCK_EN;
+ writeb_relaxed(val, miphy_phy->base + CTRL_REG);
+
+ val = BIT_LOCK_CNT_512 | BIT_LOCK_LEVEL;
+ writeb_relaxed(val, miphy_phy->base + DES_BITLOCK_REG);
+ writeb_relaxed(0x00, miphy_phy->base + RESET_REG);
+
+ return 0;
+}
+
+static int miphy365x_phy_init(struct phy *phy)
+{
+ int ret = 0;
+ struct miphy365x_phy *miphy_phy = phy_get_drvdata(phy);
+ struct miphy365x_dev *miphy_dev = miphy365x_phy_to_dev(miphy_phy);
+
+ mutex_lock(&miphy_dev->miphy_mutex);
+
+ ret = miphy365x_set_path(miphy_phy, miphy_dev);
+ if (ret) {
+ mutex_unlock(&miphy_dev->miphy_mutex);
+ return ret;
+ }
+
+ /* Initialise Miphy for PCIe or SATA */
+ if (miphy_phy->type == MIPHY_TYPE_PCIE)
+ miphy365x_phy_init_pcie_port(miphy_phy, miphy_dev);
+ else
+ ret = miphy365x_phy_init_sata_port(miphy_phy, miphy_dev);
+
+ mutex_unlock(&miphy_dev->miphy_mutex);
+
+ return ret;
+}
+
+static int miphy365x_phy_power_on(struct phy *phy)
+{
+ return 0;
+}
+
+static int miphy365x_phy_power_off(struct phy *phy)
+{
+ return 0;
+}
+
+static struct phy *miphy365x_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct miphy365x_dev *state = dev_get_drvdata(dev);
+ u8 port = args->args[0];
+ u8 type = args->args[1];
+
+ if (WARN_ON(port >= ARRAY_SIZE(ports)))
+ return ERR_PTR(-EINVAL);
+
+ if (type == MIPHY_TYPE_SATA)
+ state->phys[port].base = state->phys[port].sata;
+ else if (type == MIPHY_TYPE_PCIE)
+ state->phys[port].base = state->phys[port].pcie;
+ else {
+ WARN(1, "Invalid type specified in DT");
+ return ERR_PTR(-EINVAL);
+ }
+
+ state->phys[port].type = type;
+
+ return state->phys[port].phy;
+}
+
+static struct phy_ops miphy365x_phy_ops = {
+ .init = miphy365x_phy_init,
+ .power_on = miphy365x_phy_power_on,
+ .power_off = miphy365x_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
+ struct miphy365x_phy *phy, u8 port)
+{
+ struct resource *res;
+ char sata[16];
+ char pcie[16];
+
+ sprintf(sata, "sata%d", port);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, sata);
+ if (!res)
+ return -ENODEV;
+
+ phy->sata = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (!phy->sata)
+ return -ENOMEM;
+
+ sprintf(pcie, "pcie%d", port);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pcie);
+ if (!res)
+ return -ENODEV;
+
+ phy->pcie = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (!phy->pcie)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int miphy365x_phy_of_probe(struct device_node *np,
+ struct miphy365x_dev *phy_dev)
+{
+ const char *sata_gen;
+
+ phy_dev->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+ if (IS_ERR(phy_dev->regmap)) {
+ dev_err(phy_dev->dev, "No syscfg phandle specified\n");
+ return PTR_ERR(phy_dev->regmap);
+ }
+
+ /* Default */
+ phy_dev->sata_gen = SATA_GEN1;
+
+ of_property_read_string(np, "st,sata_gen", &sata_gen);
+ if (sata_gen) {
+ if (!strcmp(sata_gen, "gen3"))
+ phy_dev->sata_gen = SATA_GEN3;
+ else if (!strcmp(sata_gen, "gen2"))
+ phy_dev->sata_gen = SATA_GEN2;
+ }
+
+ phy_dev->pcie_tx_pol_inv =
+ of_property_read_bool(np, "st,pcie_tx_pol_inv");
+
+ phy_dev->sata_tx_pol_inv =
+ of_property_read_bool(np, "st,sata_tx_pol_inv");
+
+ return 0;
+}
+
+static int miphy365x_phy_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct miphy365x_dev *phy_dev;
+ struct device *dev = &pdev->dev;
+ struct phy_provider *provider;
+ u8 port;
+ int ret;
+
+ if (!np) {
+ dev_err(dev, "No DT found\n");
+ return -EINVAL;
+ }
+
+ phy_dev = devm_kzalloc(dev, sizeof(*phy_dev), GFP_KERNEL);
+ if (!phy_dev)
+ return -ENOMEM;
+
+ ret = miphy365x_phy_of_probe(np, phy_dev);
+ if (ret)
+ return ret;
+
+ phy_dev->dev = dev;
+
+ dev_set_drvdata(dev, phy_dev);
+
+ mutex_init(&phy_dev->miphy_mutex);
+
+ provider = devm_of_phy_provider_register(dev, miphy365x_phy_xlate);
+ if (IS_ERR(provider))
+ return PTR_ERR(provider);
+
+ for (port = 0; port < ARRAY_SIZE(ports); port++) {
+ struct phy *phy;
+
+ phy = devm_phy_create(dev, &miphy365x_phy_ops, NULL);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create PHY on port %d\n", port);
+ return PTR_ERR(phy);
+ }
+
+ phy_dev->phys[port].phy = phy;
+ phy_dev->phys[port].port = port;
+
+ ret = miphy365x_phy_get_base_addr(pdev,
+ &phy_dev->phys[port], port);
+ if (ret)
+ return ret;
+
+ phy_set_drvdata(phy, &phy_dev->phys[port]);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id miphy365x_phy_of_match[] = {
+ { .compatible = "st,miphy365x-phy", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, miphy365x_phy_of_match);
+
+static struct platform_driver miphy365x_phy_driver = {
+ .probe = miphy365x_phy_probe,
+ .driver = {
+ .name = "miphy365x-phy",
+ .owner = THIS_MODULE,
+ .of_match_table = miphy365x_phy_of_match,
+ }
+};
+module_platform_driver(miphy365x_phy_driver);
+
+MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics miphy365x driver");
+MODULE_LICENSE("GPL v2");
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-02-12 16:03 ` Lee Jones
(?)
@ 2014-02-12 16:40 ` Mark Rutland
-1 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-02-12 16:40 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, devicetree,
Srinivas Kandagatla
On Wed, Feb 12, 2014 at 04:03:02PM +0000, 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: devicetree@vger.kernel.org
> Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 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..fdfa7ca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,43 @@
> +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 example)
The first example has #phy-cells = <1>.
What do the cells mean? What are the expected values?
> +- reg: Address and length of the register set for the device
> +- reg-names: The names of the register addresses corresponding to the
> + registers filled in "reg".
Whenever there is a ${PROP}-names property, there should be a list of
explicit values, and a description of how it relates to ${PROP}. Without
that it's a bit useless.
Please provide an explicit list of expected names here.
I assume here what you want is something like:
- reg: a list of address + length pairs, one for each entry in reg-names
- reg-names: should contain:
* "sata0" for the sata0 control registers...
* "sata1" ...
* "pcie0" ...
* "pcie1" ...
> +- st,syscfg : Should be a phandle of the syscfg node.
What's this used for?
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-12 16:40 ` Mark Rutland
0 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-02-12 16:40 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree, Srinivas Kandagatla, linux-kernel, linux-arm-kernel,
alexandre.torgue
On Wed, Feb 12, 2014 at 04:03:02PM +0000, 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: devicetree@vger.kernel.org
> Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 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..fdfa7ca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,43 @@
> +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 example)
The first example has #phy-cells = <1>.
What do the cells mean? What are the expected values?
> +- reg: Address and length of the register set for the device
> +- reg-names: The names of the register addresses corresponding to the
> + registers filled in "reg".
Whenever there is a ${PROP}-names property, there should be a list of
explicit values, and a description of how it relates to ${PROP}. Without
that it's a bit useless.
Please provide an explicit list of expected names here.
I assume here what you want is something like:
- reg: a list of address + length pairs, one for each entry in reg-names
- reg-names: should contain:
* "sata0" for the sata0 control registers...
* "sata1" ...
* "pcie0" ...
* "pcie1" ...
> +- st,syscfg : Should be a phandle of the syscfg node.
What's this used for?
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-12 16:40 ` Mark Rutland
0 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-02-12 16:40 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 04:03:02PM +0000, 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: devicetree at vger.kernel.org
> Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 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..fdfa7ca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,43 @@
> +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 example)
The first example has #phy-cells = <1>.
What do the cells mean? What are the expected values?
> +- reg: Address and length of the register set for the device
> +- reg-names: The names of the register addresses corresponding to the
> + registers filled in "reg".
Whenever there is a ${PROP}-names property, there should be a list of
explicit values, and a description of how it relates to ${PROP}. Without
that it's a bit useless.
Please provide an explicit list of expected names here.
I assume here what you want is something like:
- reg: a list of address + length pairs, one for each entry in reg-names
- reg-names: should contain:
* "sata0" for the sata0 control registers...
* "sata1" ...
* "pcie0" ...
* "pcie1" ...
> +- st,syscfg : Should be a phandle of the syscfg node.
What's this used for?
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
2014-02-12 16:03 ` Lee Jones
@ 2014-02-12 16:54 ` Mark Rutland
-1 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-02-12 16:54 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, Kishon Vijay Abraham I
On Wed, Feb 12, 2014 at 04:03:05PM +0000, 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>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 643 insertions(+)
> create mode 100644 drivers/phy/phy-miphy365x.c
>
[...]
> +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> + struct miphy365x_phy *phy, u8 port)
> +{
> + struct resource *res;
> + char sata[16];
> + char pcie[16];
Isn't 6 enough for either of these? There are at most two ports IIUC, so
we only need a single character for the port number.
> +
> + sprintf(sata, "sata%d", port);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, sata);
> + if (!res)
> + return -ENODEV;
> +
> + phy->sata = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!phy->sata)
> + return -ENOMEM;
> +
> + sprintf(pcie, "pcie%d", port);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pcie);
> + if (!res)
> + return -ENODEV;
> +
> + phy->pcie = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!phy->pcie)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_of_probe(struct device_node *np,
> + struct miphy365x_dev *phy_dev)
> +{
> + const char *sata_gen;
> +
> + phy_dev->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> + if (IS_ERR(phy_dev->regmap)) {
> + dev_err(phy_dev->dev, "No syscfg phandle specified\n");
> + return PTR_ERR(phy_dev->regmap);
> + }
> +
> + /* Default */
> + phy_dev->sata_gen = SATA_GEN1;
> +
> + of_property_read_string(np, "st,sata_gen", &sata_gen);
This wasn't in the binding documentation. It also violates dt style;
s/_/-/
Could these not be numbers, or can this not come from elsewhere?
Or are there some crazy SATA generations to support?
> + if (sata_gen) {
> + if (!strcmp(sata_gen, "gen3"))
> + phy_dev->sata_gen = SATA_GEN3;
> + else if (!strcmp(sata_gen, "gen2"))
> + phy_dev->sata_gen = SATA_GEN2;
> + }
> +
> + phy_dev->pcie_tx_pol_inv =
> + of_property_read_bool(np, "st,pcie_tx_pol_inv");
> +
> + phy_dev->sata_tx_pol_inv =
> + of_property_read_bool(np, "st,sata_tx_pol_inv");
Likewise for both of these on the first two points.
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct miphy365x_dev *phy_dev;
> + struct device *dev = &pdev->dev;
> + struct phy_provider *provider;
> + u8 port;
> + int ret;
> +
> + if (!np) {
> + dev_err(dev, "No DT found\n");
s/DT/node/ ?
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
@ 2014-02-12 16:54 ` Mark Rutland
0 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-02-12 16:54 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 04:03:05PM +0000, 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>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 643 insertions(+)
> create mode 100644 drivers/phy/phy-miphy365x.c
>
[...]
> +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> + struct miphy365x_phy *phy, u8 port)
> +{
> + struct resource *res;
> + char sata[16];
> + char pcie[16];
Isn't 6 enough for either of these? There are at most two ports IIUC, so
we only need a single character for the port number.
> +
> + sprintf(sata, "sata%d", port);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, sata);
> + if (!res)
> + return -ENODEV;
> +
> + phy->sata = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!phy->sata)
> + return -ENOMEM;
> +
> + sprintf(pcie, "pcie%d", port);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pcie);
> + if (!res)
> + return -ENODEV;
> +
> + phy->pcie = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!phy->pcie)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_of_probe(struct device_node *np,
> + struct miphy365x_dev *phy_dev)
> +{
> + const char *sata_gen;
> +
> + phy_dev->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> + if (IS_ERR(phy_dev->regmap)) {
> + dev_err(phy_dev->dev, "No syscfg phandle specified\n");
> + return PTR_ERR(phy_dev->regmap);
> + }
> +
> + /* Default */
> + phy_dev->sata_gen = SATA_GEN1;
> +
> + of_property_read_string(np, "st,sata_gen", &sata_gen);
This wasn't in the binding documentation. It also violates dt style;
s/_/-/
Could these not be numbers, or can this not come from elsewhere?
Or are there some crazy SATA generations to support?
> + if (sata_gen) {
> + if (!strcmp(sata_gen, "gen3"))
> + phy_dev->sata_gen = SATA_GEN3;
> + else if (!strcmp(sata_gen, "gen2"))
> + phy_dev->sata_gen = SATA_GEN2;
> + }
> +
> + phy_dev->pcie_tx_pol_inv =
> + of_property_read_bool(np, "st,pcie_tx_pol_inv");
> +
> + phy_dev->sata_tx_pol_inv =
> + of_property_read_bool(np, "st,sata_tx_pol_inv");
Likewise for both of these on the first two points.
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct miphy365x_dev *phy_dev;
> + struct device *dev = &pdev->dev;
> + struct phy_provider *provider;
> + u8 port;
> + int ret;
> +
> + if (!np) {
> + dev_err(dev, "No DT found\n");
s/DT/node/ ?
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
2014-02-12 16:03 ` Lee Jones
@ 2014-02-13 6:53 ` Kishon Vijay Abraham I
-1 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-02-13 6:53 UTC (permalink / raw)
To: Lee Jones, linux-arm-kernel, linux-kernel; +Cc: alexandre.torgue
Hi,
On Wednesday 12 February 2014 09:33 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
various SATA or PCIe devices in STMicroelectronics STiH41x SoC series?
> PCIe or one of each in any configuration.
>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 643 insertions(+)
> create mode 100644 drivers/phy/phy-miphy365x.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 330ef2d..bb2706a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -21,6 +21,14 @@ config PHY_EXYNOS_MIPI_VIDEO
> Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P
> and EXYNOS SoCs.
>
> +config PHY_MIPHY365X
> + tristate "STMicroelectronics MIPHY365X PHY driver for STiH41x series"
> + depends on ARCH_STI
> + depends on GENERIC_PHY
depends on CONFIG_OF and HAS_IOMEM?
> + help
> + Enable this to support the miphy transceiver (for SATA/PCIE)
> + that is part of STMicroelectronics STiH41x SoC series.
> +
> config OMAP_USB2
> tristate "OMAP USB2 PHY Driver"
> depends on ARCH_OMAP2PLUS
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index d0caae9..5879639 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -5,5 +5,6 @@
> obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> +obj-$(CONFIG_PHY_MIPHY365X) += phy-miphy365x.o
> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
> new file mode 100644
> index 0000000..c4124e3
> --- /dev/null
> +++ b/drivers/phy/phy-miphy365x.c
> @@ -0,0 +1,634 @@
> +/*
> + * Copyright (C) 2014 STMicroelectronics
> + *
> + * STMicroelectronics PHY driver MiPHY365 (for SoC STiH416).
> + *
> + * Author: Alexandre Torgue <alexandre.torgue@st.com>
The author of this patch is not Alexandre Torgue?
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2, as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/clk.h>
> +#include <linux/phy/phy.h>
> +#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +
> +#include <dt-bindings/phy/phy-miphy365x.h>
> +
> +#define HFC_TIMEOUT 50
> +
> +#define SYSCFG_2521 0x824
> +#define SYSCFG_2522 0x828
> +#define SYSCFG_PCIE_SATA_MASK BIT(1)
> +#define SYSCFG_PCIE_SATA_POS 1
> +
> +/* MiPHY365x register definitiona */
> +#define RESET_REG 0x00
> +#define RST_PLL BIT(1)
There are quite a few alignment problems with these macros. It needs to be fixed.
> +#define RST_PLL_CAL BIT(2)
> +#define RST_RX BIT(4)
> +#define RST_MACRO BIT(7)
> +
> +#define STATUS_REG 0x01
> +#define IDLL_RDY BIT(0)
> +#define PLL_RDY BIT(1)
> +#define DES_BIT_LOCK BIT(2)
> +#define DES_SYMBOL_LOCK BIT(3)
> +
> +#define CTRL_REG 0x02
> +#define TERM_EN BIT(0)
> +#define PCI_EN BIT(2)
> +#define DES_BIT_LOCK_EN BIT(3)
> +#define TX_POL BIT(5)
> +
> +#define INT_CTRL_REG 0x03
> +
> +#define BOUNDARY1_REG 0x10
> +#define SPDSEL_SEL BIT(0)
> +
> +#define BOUNDARY3_REG 0x12
> +#define TX_SPDSEL_GEN1_VAL 0
> +#define TX_SPDSEL_GEN2_VAL 0x01
> +#define TX_SPDSEL_GEN3_VAL 0x02
> +#define RX_SPDSEL_GEN1_VAL 0
> +#define RX_SPDSEL_GEN2_VAL (0x01 << 3)
> +#define RX_SPDSEL_GEN3_VAL (0x02 << 3)
> +
> +#define PCIE_REG 0x16
> +
> +#define BUF_SEL_REG 0x20
> +#define CONF_GEN_SEL_GEN3 0x02
> +#define CONF_GEN_SEL_GEN2 0x01
> +#define PD_VDDTFILTER BIT(4)
> +
> +#define TXBUF1_REG 0x21
> +#define SWING_VAL 0x04
> +#define SWING_VAL_GEN1 0x03
> +#define PREEMPH_VAL (0x3 << 5)
> +
> +#define TXBUF2_REG 0x22
> +#define TXSLEW_VAL 0x2
> +#define TXSLEW_VAL_GEN1 0x4
> +
> +#define RXBUF_OFFSET_CTRL_REG 0x23
> +
> +#define RXBUF_REG 0x25
> +#define SDTHRES_VAL 0x01
> +#define EQ_ON3 (0x03 << 4)
> +#define EQ_ON1 (0x01 << 4)
> +
> +#define COMP_CTRL1_REG 0x40
> +#define START_COMSR BIT(0)
> +#define START_COMZC BIT(1)
> +#define COMP_AUTO_LOAD BIT(4)
> +
> +#define COMP_CTRL2_REG 0x41
> +#define COMP_2MHZ_RAT_GEN1 0x1e
> +#define COMP_2MHZ_RAT 0xf
> +
> +#define COMP_CTRL3_REG 0x42
> +#define COMSR_COMP_REF 0x33
> +
> +#define COMP_IDLL_REG 0x47
> +#define COMZC_IDLL 0x2a
> +
> +#define PLL_CTRL1_REG 0x50
> +#define PLL_START_CAL BIT(0)
> +#define BUF_EN BIT(2)
> +#define SYNCHRO_TX BIT(3)
> +#define SSC_EN BIT(6)
> +#define CONFIG_PLL BIT(7)
> +
> +#define PLL_CTRL2_REG 0x51
> +#define BYPASS_PLL_CAL BIT(1)
> +
> +#define PLL_RAT_REG 0x52
> +
> +#define PLL_SSC_STEP_MSB_REG 0x56
> +#define PLL_SSC_STEP_MSB_VAL 0x03
> +
> +#define PLL_SSC_STEP_LSB_REG 0x57
> +#define PLL_SSC_STEP_LSB_VAL 0x63
> +
> +#define PLL_SSC_PER_MSB_REG 0x58
> +#define PLL_SSC_PER_MSB_VAL 0
> +
> +#define PLL_SSC_PER_LSB_REG 0x59
> +#define PLL_SSC_PER_LSB_VAL 0xf1
> +
> +#define IDLL_TEST_REG 0x72
> +#define START_CLK_HF BIT(6)
> +
> +#define DES_BITLOCK_REG 0x86
> +#define BIT_LOCK_LEVEL 0x01
> +#define BIT_LOCK_CNT_512 (0x03 << 5)
> +
> +static u8 ports[] = { MIPHY_PORT_0, MIPHY_PORT_1 };
> +
> +struct miphy365x_phy {
> + struct phy *phy;
> + void __iomem *base;
> + void __iomem *sata;
> + void __iomem *pcie;
> + u8 type;
> + u8 port;
> +};
> +
> +struct miphy365x_dev {
> + struct device *dev;
> + struct mutex miphy_mutex;
> + struct miphy365x_phy phys[ARRAY_SIZE(ports)];
> + bool pcie_tx_pol_inv;
> + bool sata_tx_pol_inv;
> + u32 sata_gen;
> + struct regmap *regmap;
> +};
> +
> +enum miphy_sata_gen {
> + SATA_GEN1,
> + SATA_GEN2,
> + SATA_GEN3
> +};
> +
> +static u8 rx_tx_spd[] = {
> + TX_SPDSEL_GEN1_VAL | RX_SPDSEL_GEN1_VAL,
> + TX_SPDSEL_GEN2_VAL | RX_SPDSEL_GEN2_VAL,
> + TX_SPDSEL_GEN3_VAL | RX_SPDSEL_GEN3_VAL
> +};
> +
> +#define miphy365x_phy_to_dev(inst) \
> + container_of((inst), struct miphy365x_dev, phys[(inst)->port]);
> +
> +/*
> + * This function selects the system configuration,
> + * either two SATA, one SATA and one PCIe, or two PCIe lanes.
> + */
> +static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + u8 config = miphy_phy->type | miphy_phy->port;
> + u32 mask = SYSCFG_PCIE_SATA_MASK;
> + u32 reg;
> + bool sata;
> +
> + switch (config) {
> + case MIPHY_SATA_PORT0:
> + reg = SYSCFG_2521;
> + sata = true;
How do we configure PORT1 for SATA here? Do we really support all the system
configuration?
> + break;
> + case MIPHY_PCIE_PORT1:
> + reg = SYSCFG_2522;
> + sata = false;
> + break;
> + default:
> + dev_err(miphy_dev->dev, "Configuration not supported\n");
> + return -EINVAL;
> + }
> +
> + return regmap_update_bits(miphy_dev->regmap, reg, mask,
> + sata << SYSCFG_PCIE_SATA_POS);
> +}
> +
> +static void miphy365x_phy_init_pcie_port(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + u8 val;
> +
> + if (!miphy_dev->pcie_tx_pol_inv)
> + return;
> +
> + /* Invert Tx polarity and clear pci_txdetect_pol bit */
> + val = TERM_EN | PCI_EN | DES_BIT_LOCK_EN | TX_POL;
> + writeb_relaxed(val, miphy_phy->base + CTRL_REG);
> + writeb_relaxed(0x00, miphy_phy->base + PCIE_REG);
> +}
> +
> +static inline int miphy365x_phy_hfc_not_rdy(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + int timeout = HFC_TIMEOUT;
> + u8 mask = IDLL_RDY | PLL_RDY;
> + u8 regval;
> +
> + do {
> + regval = readb_relaxed(miphy_phy->base + STATUS_REG);
> + usleep_range(2000, 2500);
Any comment on how this delay value is obtained?
> + } while (timeout-- && (regval & mask));
> +
> + if (timeout < 0) {
> + dev_err(miphy_dev->dev, "HFC ready timeout!\n");
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +
> +static inline int miphy365x_phy_rdy(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + int timeout = HFC_TIMEOUT;
> + u8 mask = mask = IDLL_RDY | PLL_RDY;
just u8 mask = IDLL_RDY | PLL_RDY; would suffice.
> + u8 regval;
> +
> + do {
> + regval = readb_relaxed(miphy_phy->base + STATUS_REG);
> + usleep_range(2000, 2500);
same here.
> + } while (timeout-- && ((regval & mask) != mask));
> +
> + if (timeout < 0) {
> + dev_err(miphy_dev->dev, "PHY not ready timeout!\n");
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +
> +static inline void miphy365x_phy_set_comp(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + u8 val, mask;
> +
> + if (miphy_dev->sata_gen == SATA_GEN1)
> + writeb_relaxed(COMP_2MHZ_RAT_GEN1,
> + miphy_phy->base + COMP_CTRL2_REG);
> + else
> + writeb_relaxed(COMP_2MHZ_RAT,
> + miphy_phy->base + COMP_CTRL2_REG);
> +
> + if (miphy_dev->sata_gen != SATA_GEN3) {
> + writeb_relaxed(COMSR_COMP_REF,
> + miphy_phy->base + COMP_CTRL3_REG);
> + /*
> + * Force VCO current to value defined by address 0x5A
> + * and disable PCIe100Mref bit
> + * Enable auto load compensation for pll_i_bias
> + */
> + writeb_relaxed(BYPASS_PLL_CAL, miphy_phy->base + PLL_CTRL2_REG);
> + writeb_relaxed(COMZC_IDLL, miphy_phy->base + COMP_IDLL_REG);
> + }
> +
> + /*
> + * Force restart compensation and enable auto load
> + * for Comzc_Tx, Comzc_Rx and Comsr on macro
> + */
> + val = START_COMSR | START_COMZC | COMP_AUTO_LOAD;
> + writeb_relaxed(val, miphy_phy->base + COMP_CTRL1_REG);
> +
> + mask = DES_BIT_LOCK | DES_SYMBOL_LOCK;
> + while ((readb_relaxed(miphy_phy->base + COMP_CTRL1_REG) & mask) != mask)
> + cpu_relax();
Don't we need to break from here at some point if the LOCK's are never set?
> +}
> +
> +static inline void miphy365x_phy_set_ssc(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + u8 val;
> +
> + /*
> + * SSC Settings. SSC will be enabled through Link
> + * SSC Ampl. = 0.4%
> + * SSC Freq = 31KHz
> + */
> + writeb_relaxed(PLL_SSC_STEP_MSB_VAL,
> + miphy_phy->base + PLL_SSC_STEP_MSB_REG);
> + writeb_relaxed(PLL_SSC_STEP_LSB_VAL,
> + miphy_phy->base + PLL_SSC_STEP_LSB_REG);
> + writeb_relaxed(PLL_SSC_PER_MSB_VAL,
> + miphy_phy->base + PLL_SSC_PER_MSB_REG);
> + writeb_relaxed(PLL_SSC_PER_LSB_VAL,
> + miphy_phy->base + PLL_SSC_PER_LSB_REG);
> +
> + /* SSC Settings complete */
> + if (miphy_dev->sata_gen == SATA_GEN1) {
> + val = PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
> + writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
> + } else {
> + val = SSC_EN | PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
> + writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
> + }
> +}
> +
> +static int miphy365x_phy_init_sata_port(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + int ret;
> + u8 val;
> +
> + /*
> + * Force PHY macro reset, PLL calibration reset, PLL reset
> + * and assert Deserializer Reset
> + */
> + val = RST_PLL | RST_PLL_CAL | RST_RX | RST_MACRO;
> + writeb_relaxed(val, miphy_phy->base + RESET_REG);
> +
> + if (miphy_dev->sata_tx_pol_inv)
> + writeb_relaxed(TX_POL, miphy_phy->base + CTRL_REG);
> +
> + /*
> + * Force macro1 to use rx_lspd, tx_lspd
> + * Force Rx_Clock on first I-DLL phase
> + * Force Des in HP mode on macro, rx_lspd, tx_lspd for Gen2/3
> + */
> + writeb_relaxed(SPDSEL_SEL, miphy_phy->base + BOUNDARY1_REG);
> + writeb_relaxed(START_CLK_HF, miphy_phy->base + IDLL_TEST_REG);
> + val = rx_tx_spd[miphy_dev->sata_gen];
> + writeb_relaxed(val, miphy_phy->base + BOUNDARY3_REG);
> +
> + /* Wait for HFC_READY = 0 */
> + ret = miphy365x_phy_hfc_not_rdy(miphy_phy, miphy_dev);
> + if (ret)
> + return ret;
> +
> + /* Compensation Recalibration */
> + miphy365x_phy_set_comp(miphy_phy, miphy_dev);
> +
> + switch (miphy_dev->sata_gen) {
> + case SATA_GEN3:
> + /*
> + * TX Swing target 550-600mv peak to peak diff
> + * Tx Slew target 90-110ps rising/falling time
> + * Rx Eq ON3, Sigdet threshold SDTH1
> + */
> + val = PD_VDDTFILTER | CONF_GEN_SEL_GEN3;
> + writeb_relaxed(val, miphy_phy->base + BUF_SEL_REG);
> + val = SWING_VAL | PREEMPH_VAL;
> + writeb_relaxed(val, miphy_phy->base + TXBUF1_REG);
> + writeb_relaxed(TXSLEW_VAL, miphy_phy->base + TXBUF2_REG);
> + writeb_relaxed(0x00, miphy_phy->base + RXBUF_OFFSET_CTRL_REG);
> + val = SDTHRES_VAL | EQ_ON3;
> + writeb_relaxed(val, miphy_phy->base + RXBUF_REG);
> + break;
> + case SATA_GEN2:
> + /*
> + * conf gen sel=0x1 to program Gen2 banked registers
> + * VDDT filter ON
> + * Tx Swing target 550-600mV peak-to-peak diff
> + * Tx Slew target 90-110 ps rising/falling time
> + * RX Equalization ON1, Sigdet threshold SDTH1
> + */
> + writeb_relaxed(CONF_GEN_SEL_GEN2,
> + miphy_phy->base + BUF_SEL_REG);
> + writeb_relaxed(SWING_VAL, miphy_phy->base + TXBUF1_REG);
> + writeb_relaxed(TXSLEW_VAL, miphy_phy->base + TXBUF2_REG);
> + val = SDTHRES_VAL | EQ_ON1;
> + writeb_relaxed(val, miphy_phy->base + RXBUF_REG);
> + break;
> + case SATA_GEN1:
> + /*
> + * conf gen sel = 00b to program Gen1 banked registers
> + * VDDT filter ON
> + * Tx Swing target 500-550mV peak-to-peak diff
> + * Tx Slew target120-140 ps rising/falling time
> + */
> + writeb_relaxed(PD_VDDTFILTER, miphy_phy->base + BUF_SEL_REG);
> + writeb_relaxed(SWING_VAL_GEN1, miphy_phy->base + TXBUF1_REG);
> + writeb_relaxed(TXSLEW_VAL_GEN1, miphy_phy->base + TXBUF2_REG);
> + break;
> + default:
> + break;
> + }
> +
> + /* Force Macro1 in partial mode & release pll cal reset */
> + writeb_relaxed(RST_RX, miphy_phy->base + RESET_REG);
> + usleep_range(100, 150);
> +
> + miphy365x_phy_set_ssc(miphy_phy, miphy_dev);
> +
> + /* Wait for phy_ready */
> + ret = miphy365x_phy_rdy(miphy_phy, miphy_dev);
> + if (ret)
> + return ret;
> +
> + /*
> + * Enable macro1 to use rx_lspd & tx_lspd
> + * Release Rx_Clock on first I-DLL phase on macro1
> + * Assert deserializer reset
> + * des_bit_lock_en is set
> + * bit lock detection strength
> + * Deassert deserializer reset
> + */
> + writeb_relaxed(0x00, miphy_phy->base + BOUNDARY1_REG);
> + writeb_relaxed(0x00, miphy_phy->base + IDLL_TEST_REG);
> + writeb_relaxed(RST_RX, miphy_phy->base + RESET_REG);
> + val = miphy_dev->sata_tx_pol_inv ?
> + (TX_POL | DES_BIT_LOCK_EN) : DES_BIT_LOCK_EN;
> + writeb_relaxed(val, miphy_phy->base + CTRL_REG);
> +
> + val = BIT_LOCK_CNT_512 | BIT_LOCK_LEVEL;
> + writeb_relaxed(val, miphy_phy->base + DES_BITLOCK_REG);
> + writeb_relaxed(0x00, miphy_phy->base + RESET_REG);
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_init(struct phy *phy)
> +{
> + int ret = 0;
> + struct miphy365x_phy *miphy_phy = phy_get_drvdata(phy);
> + struct miphy365x_dev *miphy_dev = miphy365x_phy_to_dev(miphy_phy);
> +
> + mutex_lock(&miphy_dev->miphy_mutex);
> +
> + ret = miphy365x_set_path(miphy_phy, miphy_dev);
> + if (ret) {
> + mutex_unlock(&miphy_dev->miphy_mutex);
> + return ret;
> + }
> +
> + /* Initialise Miphy for PCIe or SATA */
> + if (miphy_phy->type == MIPHY_TYPE_PCIE)
> + miphy365x_phy_init_pcie_port(miphy_phy, miphy_dev);
> + else
> + ret = miphy365x_phy_init_sata_port(miphy_phy, miphy_dev);
> +
> + mutex_unlock(&miphy_dev->miphy_mutex);
> +
> + return ret;
> +}
> +
> +static int miphy365x_phy_power_on(struct phy *phy)
> +{
> + return 0;
> +}
> +
> +static int miphy365x_phy_power_off(struct phy *phy)
> +{
> + return 0;
> +}
Both these empty functions can be removed.
> +
> +static struct phy *miphy365x_phy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct miphy365x_dev *state = dev_get_drvdata(dev);
> + u8 port = args->args[0];
> + u8 type = args->args[1];
> +
> + if (WARN_ON(port >= ARRAY_SIZE(ports)))
> + return ERR_PTR(-EINVAL);
> +
> + if (type == MIPHY_TYPE_SATA)
> + state->phys[port].base = state->phys[port].sata;
> + else if (type == MIPHY_TYPE_PCIE)
> + state->phys[port].base = state->phys[port].pcie;
> + else {
> + WARN(1, "Invalid type specified in DT");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + state->phys[port].type = type;
> +
> + return state->phys[port].phy;
> +}
> +
> +static struct phy_ops miphy365x_phy_ops = {
> + .init = miphy365x_phy_init,
> + .power_on = miphy365x_phy_power_on,
> + .power_off = miphy365x_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> + struct miphy365x_phy *phy, u8 port)
> +{
> + struct resource *res;
> + char sata[16];
> + char pcie[16];
It can be done with a single variable ;-)
> +
> + sprintf(sata, "sata%d", port);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, sata);
> + if (!res)
> + return -ENODEV;
> +
> + phy->sata = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!phy->sata)
> + return -ENOMEM;
> +
> + sprintf(pcie, "pcie%d", port);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pcie);
> + if (!res)
> + return -ENODEV;
> +
> + phy->pcie = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!phy->pcie)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_of_probe(struct device_node *np,
> + struct miphy365x_dev *phy_dev)
> +{
> + const char *sata_gen;
> +
> + phy_dev->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> + if (IS_ERR(phy_dev->regmap)) {
> + dev_err(phy_dev->dev, "No syscfg phandle specified\n");
> + return PTR_ERR(phy_dev->regmap);
> + }
> +
> + /* Default */
> + phy_dev->sata_gen = SATA_GEN1;
> +
> + of_property_read_string(np, "st,sata_gen", &sata_gen);
> + if (sata_gen) {
> + if (!strcmp(sata_gen, "gen3"))
> + phy_dev->sata_gen = SATA_GEN3;
> + else if (!strcmp(sata_gen, "gen2"))
> + phy_dev->sata_gen = SATA_GEN2;
> + }
> +
> + phy_dev->pcie_tx_pol_inv =
> + of_property_read_bool(np, "st,pcie_tx_pol_inv");
> +
> + phy_dev->sata_tx_pol_inv =
> + of_property_read_bool(np, "st,sata_tx_pol_inv");
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct miphy365x_dev *phy_dev;
> + struct device *dev = &pdev->dev;
> + struct phy_provider *provider;
> + u8 port;
> + int ret;
> +
> + if (!np) {
> + dev_err(dev, "No DT found\n");
> + return -EINVAL;
> + }
> +
> + phy_dev = devm_kzalloc(dev, sizeof(*phy_dev), GFP_KERNEL);
> + if (!phy_dev)
> + return -ENOMEM;
> +
> + ret = miphy365x_phy_of_probe(np, phy_dev);
> + if (ret)
> + return ret;
> +
> + phy_dev->dev = dev;
> +
> + dev_set_drvdata(dev, phy_dev);
> +
> + mutex_init(&phy_dev->miphy_mutex);
> +
> + provider = devm_of_phy_provider_register(dev, miphy365x_phy_xlate);
> + if (IS_ERR(provider))
> + return PTR_ERR(provider);
Phy provider register should be the last step in registering the PHY.
Thanks
Kishon
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
@ 2014-02-13 6:53 ` Kishon Vijay Abraham I
0 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-02-13 6:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Wednesday 12 February 2014 09:33 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
various SATA or PCIe devices in STMicroelectronics STiH41x SoC series?
> PCIe or one of each in any configuration.
>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 643 insertions(+)
> create mode 100644 drivers/phy/phy-miphy365x.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 330ef2d..bb2706a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -21,6 +21,14 @@ config PHY_EXYNOS_MIPI_VIDEO
> Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P
> and EXYNOS SoCs.
>
> +config PHY_MIPHY365X
> + tristate "STMicroelectronics MIPHY365X PHY driver for STiH41x series"
> + depends on ARCH_STI
> + depends on GENERIC_PHY
depends on CONFIG_OF and HAS_IOMEM?
> + help
> + Enable this to support the miphy transceiver (for SATA/PCIE)
> + that is part of STMicroelectronics STiH41x SoC series.
> +
> config OMAP_USB2
> tristate "OMAP USB2 PHY Driver"
> depends on ARCH_OMAP2PLUS
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index d0caae9..5879639 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -5,5 +5,6 @@
> obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> +obj-$(CONFIG_PHY_MIPHY365X) += phy-miphy365x.o
> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
> new file mode 100644
> index 0000000..c4124e3
> --- /dev/null
> +++ b/drivers/phy/phy-miphy365x.c
> @@ -0,0 +1,634 @@
> +/*
> + * Copyright (C) 2014 STMicroelectronics
> + *
> + * STMicroelectronics PHY driver MiPHY365 (for SoC STiH416).
> + *
> + * Author: Alexandre Torgue <alexandre.torgue@st.com>
The author of this patch is not Alexandre Torgue?
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2, as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/clk.h>
> +#include <linux/phy/phy.h>
> +#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +
> +#include <dt-bindings/phy/phy-miphy365x.h>
> +
> +#define HFC_TIMEOUT 50
> +
> +#define SYSCFG_2521 0x824
> +#define SYSCFG_2522 0x828
> +#define SYSCFG_PCIE_SATA_MASK BIT(1)
> +#define SYSCFG_PCIE_SATA_POS 1
> +
> +/* MiPHY365x register definitiona */
> +#define RESET_REG 0x00
> +#define RST_PLL BIT(1)
There are quite a few alignment problems with these macros. It needs to be fixed.
> +#define RST_PLL_CAL BIT(2)
> +#define RST_RX BIT(4)
> +#define RST_MACRO BIT(7)
> +
> +#define STATUS_REG 0x01
> +#define IDLL_RDY BIT(0)
> +#define PLL_RDY BIT(1)
> +#define DES_BIT_LOCK BIT(2)
> +#define DES_SYMBOL_LOCK BIT(3)
> +
> +#define CTRL_REG 0x02
> +#define TERM_EN BIT(0)
> +#define PCI_EN BIT(2)
> +#define DES_BIT_LOCK_EN BIT(3)
> +#define TX_POL BIT(5)
> +
> +#define INT_CTRL_REG 0x03
> +
> +#define BOUNDARY1_REG 0x10
> +#define SPDSEL_SEL BIT(0)
> +
> +#define BOUNDARY3_REG 0x12
> +#define TX_SPDSEL_GEN1_VAL 0
> +#define TX_SPDSEL_GEN2_VAL 0x01
> +#define TX_SPDSEL_GEN3_VAL 0x02
> +#define RX_SPDSEL_GEN1_VAL 0
> +#define RX_SPDSEL_GEN2_VAL (0x01 << 3)
> +#define RX_SPDSEL_GEN3_VAL (0x02 << 3)
> +
> +#define PCIE_REG 0x16
> +
> +#define BUF_SEL_REG 0x20
> +#define CONF_GEN_SEL_GEN3 0x02
> +#define CONF_GEN_SEL_GEN2 0x01
> +#define PD_VDDTFILTER BIT(4)
> +
> +#define TXBUF1_REG 0x21
> +#define SWING_VAL 0x04
> +#define SWING_VAL_GEN1 0x03
> +#define PREEMPH_VAL (0x3 << 5)
> +
> +#define TXBUF2_REG 0x22
> +#define TXSLEW_VAL 0x2
> +#define TXSLEW_VAL_GEN1 0x4
> +
> +#define RXBUF_OFFSET_CTRL_REG 0x23
> +
> +#define RXBUF_REG 0x25
> +#define SDTHRES_VAL 0x01
> +#define EQ_ON3 (0x03 << 4)
> +#define EQ_ON1 (0x01 << 4)
> +
> +#define COMP_CTRL1_REG 0x40
> +#define START_COMSR BIT(0)
> +#define START_COMZC BIT(1)
> +#define COMP_AUTO_LOAD BIT(4)
> +
> +#define COMP_CTRL2_REG 0x41
> +#define COMP_2MHZ_RAT_GEN1 0x1e
> +#define COMP_2MHZ_RAT 0xf
> +
> +#define COMP_CTRL3_REG 0x42
> +#define COMSR_COMP_REF 0x33
> +
> +#define COMP_IDLL_REG 0x47
> +#define COMZC_IDLL 0x2a
> +
> +#define PLL_CTRL1_REG 0x50
> +#define PLL_START_CAL BIT(0)
> +#define BUF_EN BIT(2)
> +#define SYNCHRO_TX BIT(3)
> +#define SSC_EN BIT(6)
> +#define CONFIG_PLL BIT(7)
> +
> +#define PLL_CTRL2_REG 0x51
> +#define BYPASS_PLL_CAL BIT(1)
> +
> +#define PLL_RAT_REG 0x52
> +
> +#define PLL_SSC_STEP_MSB_REG 0x56
> +#define PLL_SSC_STEP_MSB_VAL 0x03
> +
> +#define PLL_SSC_STEP_LSB_REG 0x57
> +#define PLL_SSC_STEP_LSB_VAL 0x63
> +
> +#define PLL_SSC_PER_MSB_REG 0x58
> +#define PLL_SSC_PER_MSB_VAL 0
> +
> +#define PLL_SSC_PER_LSB_REG 0x59
> +#define PLL_SSC_PER_LSB_VAL 0xf1
> +
> +#define IDLL_TEST_REG 0x72
> +#define START_CLK_HF BIT(6)
> +
> +#define DES_BITLOCK_REG 0x86
> +#define BIT_LOCK_LEVEL 0x01
> +#define BIT_LOCK_CNT_512 (0x03 << 5)
> +
> +static u8 ports[] = { MIPHY_PORT_0, MIPHY_PORT_1 };
> +
> +struct miphy365x_phy {
> + struct phy *phy;
> + void __iomem *base;
> + void __iomem *sata;
> + void __iomem *pcie;
> + u8 type;
> + u8 port;
> +};
> +
> +struct miphy365x_dev {
> + struct device *dev;
> + struct mutex miphy_mutex;
> + struct miphy365x_phy phys[ARRAY_SIZE(ports)];
> + bool pcie_tx_pol_inv;
> + bool sata_tx_pol_inv;
> + u32 sata_gen;
> + struct regmap *regmap;
> +};
> +
> +enum miphy_sata_gen {
> + SATA_GEN1,
> + SATA_GEN2,
> + SATA_GEN3
> +};
> +
> +static u8 rx_tx_spd[] = {
> + TX_SPDSEL_GEN1_VAL | RX_SPDSEL_GEN1_VAL,
> + TX_SPDSEL_GEN2_VAL | RX_SPDSEL_GEN2_VAL,
> + TX_SPDSEL_GEN3_VAL | RX_SPDSEL_GEN3_VAL
> +};
> +
> +#define miphy365x_phy_to_dev(inst) \
> + container_of((inst), struct miphy365x_dev, phys[(inst)->port]);
> +
> +/*
> + * This function selects the system configuration,
> + * either two SATA, one SATA and one PCIe, or two PCIe lanes.
> + */
> +static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + u8 config = miphy_phy->type | miphy_phy->port;
> + u32 mask = SYSCFG_PCIE_SATA_MASK;
> + u32 reg;
> + bool sata;
> +
> + switch (config) {
> + case MIPHY_SATA_PORT0:
> + reg = SYSCFG_2521;
> + sata = true;
How do we configure PORT1 for SATA here? Do we really support all the system
configuration?
> + break;
> + case MIPHY_PCIE_PORT1:
> + reg = SYSCFG_2522;
> + sata = false;
> + break;
> + default:
> + dev_err(miphy_dev->dev, "Configuration not supported\n");
> + return -EINVAL;
> + }
> +
> + return regmap_update_bits(miphy_dev->regmap, reg, mask,
> + sata << SYSCFG_PCIE_SATA_POS);
> +}
> +
> +static void miphy365x_phy_init_pcie_port(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + u8 val;
> +
> + if (!miphy_dev->pcie_tx_pol_inv)
> + return;
> +
> + /* Invert Tx polarity and clear pci_txdetect_pol bit */
> + val = TERM_EN | PCI_EN | DES_BIT_LOCK_EN | TX_POL;
> + writeb_relaxed(val, miphy_phy->base + CTRL_REG);
> + writeb_relaxed(0x00, miphy_phy->base + PCIE_REG);
> +}
> +
> +static inline int miphy365x_phy_hfc_not_rdy(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + int timeout = HFC_TIMEOUT;
> + u8 mask = IDLL_RDY | PLL_RDY;
> + u8 regval;
> +
> + do {
> + regval = readb_relaxed(miphy_phy->base + STATUS_REG);
> + usleep_range(2000, 2500);
Any comment on how this delay value is obtained?
> + } while (timeout-- && (regval & mask));
> +
> + if (timeout < 0) {
> + dev_err(miphy_dev->dev, "HFC ready timeout!\n");
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +
> +static inline int miphy365x_phy_rdy(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + int timeout = HFC_TIMEOUT;
> + u8 mask = mask = IDLL_RDY | PLL_RDY;
just u8 mask = IDLL_RDY | PLL_RDY; would suffice.
> + u8 regval;
> +
> + do {
> + regval = readb_relaxed(miphy_phy->base + STATUS_REG);
> + usleep_range(2000, 2500);
same here.
> + } while (timeout-- && ((regval & mask) != mask));
> +
> + if (timeout < 0) {
> + dev_err(miphy_dev->dev, "PHY not ready timeout!\n");
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +
> +static inline void miphy365x_phy_set_comp(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + u8 val, mask;
> +
> + if (miphy_dev->sata_gen == SATA_GEN1)
> + writeb_relaxed(COMP_2MHZ_RAT_GEN1,
> + miphy_phy->base + COMP_CTRL2_REG);
> + else
> + writeb_relaxed(COMP_2MHZ_RAT,
> + miphy_phy->base + COMP_CTRL2_REG);
> +
> + if (miphy_dev->sata_gen != SATA_GEN3) {
> + writeb_relaxed(COMSR_COMP_REF,
> + miphy_phy->base + COMP_CTRL3_REG);
> + /*
> + * Force VCO current to value defined by address 0x5A
> + * and disable PCIe100Mref bit
> + * Enable auto load compensation for pll_i_bias
> + */
> + writeb_relaxed(BYPASS_PLL_CAL, miphy_phy->base + PLL_CTRL2_REG);
> + writeb_relaxed(COMZC_IDLL, miphy_phy->base + COMP_IDLL_REG);
> + }
> +
> + /*
> + * Force restart compensation and enable auto load
> + * for Comzc_Tx, Comzc_Rx and Comsr on macro
> + */
> + val = START_COMSR | START_COMZC | COMP_AUTO_LOAD;
> + writeb_relaxed(val, miphy_phy->base + COMP_CTRL1_REG);
> +
> + mask = DES_BIT_LOCK | DES_SYMBOL_LOCK;
> + while ((readb_relaxed(miphy_phy->base + COMP_CTRL1_REG) & mask) != mask)
> + cpu_relax();
Don't we need to break from here at some point if the LOCK's are never set?
> +}
> +
> +static inline void miphy365x_phy_set_ssc(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + u8 val;
> +
> + /*
> + * SSC Settings. SSC will be enabled through Link
> + * SSC Ampl. = 0.4%
> + * SSC Freq = 31KHz
> + */
> + writeb_relaxed(PLL_SSC_STEP_MSB_VAL,
> + miphy_phy->base + PLL_SSC_STEP_MSB_REG);
> + writeb_relaxed(PLL_SSC_STEP_LSB_VAL,
> + miphy_phy->base + PLL_SSC_STEP_LSB_REG);
> + writeb_relaxed(PLL_SSC_PER_MSB_VAL,
> + miphy_phy->base + PLL_SSC_PER_MSB_REG);
> + writeb_relaxed(PLL_SSC_PER_LSB_VAL,
> + miphy_phy->base + PLL_SSC_PER_LSB_REG);
> +
> + /* SSC Settings complete */
> + if (miphy_dev->sata_gen == SATA_GEN1) {
> + val = PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
> + writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
> + } else {
> + val = SSC_EN | PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
> + writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
> + }
> +}
> +
> +static int miphy365x_phy_init_sata_port(struct miphy365x_phy *miphy_phy,
> + struct miphy365x_dev *miphy_dev)
> +{
> + int ret;
> + u8 val;
> +
> + /*
> + * Force PHY macro reset, PLL calibration reset, PLL reset
> + * and assert Deserializer Reset
> + */
> + val = RST_PLL | RST_PLL_CAL | RST_RX | RST_MACRO;
> + writeb_relaxed(val, miphy_phy->base + RESET_REG);
> +
> + if (miphy_dev->sata_tx_pol_inv)
> + writeb_relaxed(TX_POL, miphy_phy->base + CTRL_REG);
> +
> + /*
> + * Force macro1 to use rx_lspd, tx_lspd
> + * Force Rx_Clock on first I-DLL phase
> + * Force Des in HP mode on macro, rx_lspd, tx_lspd for Gen2/3
> + */
> + writeb_relaxed(SPDSEL_SEL, miphy_phy->base + BOUNDARY1_REG);
> + writeb_relaxed(START_CLK_HF, miphy_phy->base + IDLL_TEST_REG);
> + val = rx_tx_spd[miphy_dev->sata_gen];
> + writeb_relaxed(val, miphy_phy->base + BOUNDARY3_REG);
> +
> + /* Wait for HFC_READY = 0 */
> + ret = miphy365x_phy_hfc_not_rdy(miphy_phy, miphy_dev);
> + if (ret)
> + return ret;
> +
> + /* Compensation Recalibration */
> + miphy365x_phy_set_comp(miphy_phy, miphy_dev);
> +
> + switch (miphy_dev->sata_gen) {
> + case SATA_GEN3:
> + /*
> + * TX Swing target 550-600mv peak to peak diff
> + * Tx Slew target 90-110ps rising/falling time
> + * Rx Eq ON3, Sigdet threshold SDTH1
> + */
> + val = PD_VDDTFILTER | CONF_GEN_SEL_GEN3;
> + writeb_relaxed(val, miphy_phy->base + BUF_SEL_REG);
> + val = SWING_VAL | PREEMPH_VAL;
> + writeb_relaxed(val, miphy_phy->base + TXBUF1_REG);
> + writeb_relaxed(TXSLEW_VAL, miphy_phy->base + TXBUF2_REG);
> + writeb_relaxed(0x00, miphy_phy->base + RXBUF_OFFSET_CTRL_REG);
> + val = SDTHRES_VAL | EQ_ON3;
> + writeb_relaxed(val, miphy_phy->base + RXBUF_REG);
> + break;
> + case SATA_GEN2:
> + /*
> + * conf gen sel=0x1 to program Gen2 banked registers
> + * VDDT filter ON
> + * Tx Swing target 550-600mV peak-to-peak diff
> + * Tx Slew target 90-110 ps rising/falling time
> + * RX Equalization ON1, Sigdet threshold SDTH1
> + */
> + writeb_relaxed(CONF_GEN_SEL_GEN2,
> + miphy_phy->base + BUF_SEL_REG);
> + writeb_relaxed(SWING_VAL, miphy_phy->base + TXBUF1_REG);
> + writeb_relaxed(TXSLEW_VAL, miphy_phy->base + TXBUF2_REG);
> + val = SDTHRES_VAL | EQ_ON1;
> + writeb_relaxed(val, miphy_phy->base + RXBUF_REG);
> + break;
> + case SATA_GEN1:
> + /*
> + * conf gen sel = 00b to program Gen1 banked registers
> + * VDDT filter ON
> + * Tx Swing target 500-550mV peak-to-peak diff
> + * Tx Slew target120-140 ps rising/falling time
> + */
> + writeb_relaxed(PD_VDDTFILTER, miphy_phy->base + BUF_SEL_REG);
> + writeb_relaxed(SWING_VAL_GEN1, miphy_phy->base + TXBUF1_REG);
> + writeb_relaxed(TXSLEW_VAL_GEN1, miphy_phy->base + TXBUF2_REG);
> + break;
> + default:
> + break;
> + }
> +
> + /* Force Macro1 in partial mode & release pll cal reset */
> + writeb_relaxed(RST_RX, miphy_phy->base + RESET_REG);
> + usleep_range(100, 150);
> +
> + miphy365x_phy_set_ssc(miphy_phy, miphy_dev);
> +
> + /* Wait for phy_ready */
> + ret = miphy365x_phy_rdy(miphy_phy, miphy_dev);
> + if (ret)
> + return ret;
> +
> + /*
> + * Enable macro1 to use rx_lspd & tx_lspd
> + * Release Rx_Clock on first I-DLL phase on macro1
> + * Assert deserializer reset
> + * des_bit_lock_en is set
> + * bit lock detection strength
> + * Deassert deserializer reset
> + */
> + writeb_relaxed(0x00, miphy_phy->base + BOUNDARY1_REG);
> + writeb_relaxed(0x00, miphy_phy->base + IDLL_TEST_REG);
> + writeb_relaxed(RST_RX, miphy_phy->base + RESET_REG);
> + val = miphy_dev->sata_tx_pol_inv ?
> + (TX_POL | DES_BIT_LOCK_EN) : DES_BIT_LOCK_EN;
> + writeb_relaxed(val, miphy_phy->base + CTRL_REG);
> +
> + val = BIT_LOCK_CNT_512 | BIT_LOCK_LEVEL;
> + writeb_relaxed(val, miphy_phy->base + DES_BITLOCK_REG);
> + writeb_relaxed(0x00, miphy_phy->base + RESET_REG);
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_init(struct phy *phy)
> +{
> + int ret = 0;
> + struct miphy365x_phy *miphy_phy = phy_get_drvdata(phy);
> + struct miphy365x_dev *miphy_dev = miphy365x_phy_to_dev(miphy_phy);
> +
> + mutex_lock(&miphy_dev->miphy_mutex);
> +
> + ret = miphy365x_set_path(miphy_phy, miphy_dev);
> + if (ret) {
> + mutex_unlock(&miphy_dev->miphy_mutex);
> + return ret;
> + }
> +
> + /* Initialise Miphy for PCIe or SATA */
> + if (miphy_phy->type == MIPHY_TYPE_PCIE)
> + miphy365x_phy_init_pcie_port(miphy_phy, miphy_dev);
> + else
> + ret = miphy365x_phy_init_sata_port(miphy_phy, miphy_dev);
> +
> + mutex_unlock(&miphy_dev->miphy_mutex);
> +
> + return ret;
> +}
> +
> +static int miphy365x_phy_power_on(struct phy *phy)
> +{
> + return 0;
> +}
> +
> +static int miphy365x_phy_power_off(struct phy *phy)
> +{
> + return 0;
> +}
Both these empty functions can be removed.
> +
> +static struct phy *miphy365x_phy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct miphy365x_dev *state = dev_get_drvdata(dev);
> + u8 port = args->args[0];
> + u8 type = args->args[1];
> +
> + if (WARN_ON(port >= ARRAY_SIZE(ports)))
> + return ERR_PTR(-EINVAL);
> +
> + if (type == MIPHY_TYPE_SATA)
> + state->phys[port].base = state->phys[port].sata;
> + else if (type == MIPHY_TYPE_PCIE)
> + state->phys[port].base = state->phys[port].pcie;
> + else {
> + WARN(1, "Invalid type specified in DT");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + state->phys[port].type = type;
> +
> + return state->phys[port].phy;
> +}
> +
> +static struct phy_ops miphy365x_phy_ops = {
> + .init = miphy365x_phy_init,
> + .power_on = miphy365x_phy_power_on,
> + .power_off = miphy365x_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> + struct miphy365x_phy *phy, u8 port)
> +{
> + struct resource *res;
> + char sata[16];
> + char pcie[16];
It can be done with a single variable ;-)
> +
> + sprintf(sata, "sata%d", port);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, sata);
> + if (!res)
> + return -ENODEV;
> +
> + phy->sata = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!phy->sata)
> + return -ENOMEM;
> +
> + sprintf(pcie, "pcie%d", port);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pcie);
> + if (!res)
> + return -ENODEV;
> +
> + phy->pcie = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!phy->pcie)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_of_probe(struct device_node *np,
> + struct miphy365x_dev *phy_dev)
> +{
> + const char *sata_gen;
> +
> + phy_dev->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> + if (IS_ERR(phy_dev->regmap)) {
> + dev_err(phy_dev->dev, "No syscfg phandle specified\n");
> + return PTR_ERR(phy_dev->regmap);
> + }
> +
> + /* Default */
> + phy_dev->sata_gen = SATA_GEN1;
> +
> + of_property_read_string(np, "st,sata_gen", &sata_gen);
> + if (sata_gen) {
> + if (!strcmp(sata_gen, "gen3"))
> + phy_dev->sata_gen = SATA_GEN3;
> + else if (!strcmp(sata_gen, "gen2"))
> + phy_dev->sata_gen = SATA_GEN2;
> + }
> +
> + phy_dev->pcie_tx_pol_inv =
> + of_property_read_bool(np, "st,pcie_tx_pol_inv");
> +
> + phy_dev->sata_tx_pol_inv =
> + of_property_read_bool(np, "st,sata_tx_pol_inv");
> +
> + return 0;
> +}
> +
> +static int miphy365x_phy_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct miphy365x_dev *phy_dev;
> + struct device *dev = &pdev->dev;
> + struct phy_provider *provider;
> + u8 port;
> + int ret;
> +
> + if (!np) {
> + dev_err(dev, "No DT found\n");
> + return -EINVAL;
> + }
> +
> + phy_dev = devm_kzalloc(dev, sizeof(*phy_dev), GFP_KERNEL);
> + if (!phy_dev)
> + return -ENOMEM;
> +
> + ret = miphy365x_phy_of_probe(np, phy_dev);
> + if (ret)
> + return ret;
> +
> + phy_dev->dev = dev;
> +
> + dev_set_drvdata(dev, phy_dev);
> +
> + mutex_init(&phy_dev->miphy_mutex);
> +
> + provider = devm_of_phy_provider_register(dev, miphy365x_phy_xlate);
> + if (IS_ERR(provider))
> + return PTR_ERR(provider);
Phy provider register should be the last step in registering the PHY.
Thanks
Kishon
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
2014-02-13 6:53 ` Kishon Vijay Abraham I
@ 2014-02-13 10:29 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-13 10:29 UTC (permalink / raw)
To: Kishon Vijay Abraham I; +Cc: linux-arm-kernel, linux-kernel, alexandre.torgue
> > 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
>
> various SATA or PCIe devices in STMicroelectronics STiH41x SoC series?
To tell you the truth, I'm not sure if it is limited to ST's h/w, but
I think it can only be found there, so I'm happy to fixup.
<snip>
> > +config PHY_MIPHY365X
> > + tristate "STMicroelectronics MIPHY365X PHY driver for STiH41x series"
> > + depends on ARCH_STI
> > + depends on GENERIC_PHY
> depends on CONFIG_OF and HAS_IOMEM?
Sure, I'll fix.
<snip>
> > + * Copyright (C) 2014 STMicroelectronics
> > + *
> > + * STMicroelectronics PHY driver MiPHY365 (for SoC STiH416).
> > + *
> > + * Author: Alexandre Torgue <alexandre.torgue@st.com>
>
> The author of this patch is not Alexandre Torgue?
The history of this driver is long and the authors are many. Alex
did the last internal over-haul and converted it to use Generic PHY. I
took Alex's driver and made significant changes in order to upstream.
<snip>
> > +#define HFC_TIMEOUT 50
> > +
> > +#define SYSCFG_2521 0x824
> > +#define SYSCFG_2522 0x828
> > +#define SYSCFG_PCIE_SATA_MASK BIT(1)
> > +#define SYSCFG_PCIE_SATA_POS 1
> > +
> > +/* MiPHY365x register definitiona */
> > +#define RESET_REG 0x00
> > +#define RST_PLL BIT(1)
>
> There are quite a few alignment problems with these macros. It needs
> to be fixed.
This is just Git playing up.
In reality everything is perfectly aligned and all using tabs.
<snip>
> > +/*
> > + * This function selects the system configuration,
> > + * either two SATA, one SATA and one PCIe, or two PCIe lanes.
> > + */
> > +static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
> > + struct miphy365x_dev *miphy_dev)
> > +{
> > + u8 config = miphy_phy->type | miphy_phy->port;
> > + u32 mask = SYSCFG_PCIE_SATA_MASK;
> > + u32 reg;
> > + bool sata;
> > +
> > + switch (config) {
> > + case MIPHY_SATA_PORT0:
> > + reg = SYSCFG_2521;
> > + sata = true;
>
> How do we configure PORT1 for SATA here? Do we really support all the system
> configuration?
Good spot eagle-eye!
Actually in the current version there is a h/w bug which only allows
the SATA_PORT0 and PCIE_PORT1 configuration. When a new version fixing
this is released I will add version detection to the driver and we can
support full intended configuration options.
<snip>
> > +static inline int miphy365x_phy_hfc_not_rdy(struct miphy365x_phy *miphy_phy,
> > + struct miphy365x_dev *miphy_dev)
> > +{
> > + int timeout = HFC_TIMEOUT;
> > + u8 mask = IDLL_RDY | PLL_RDY;
> > + u8 regval;
> > +
> > + do {
> > + regval = readb_relaxed(miphy_phy->base + STATUS_REG);
> > + usleep_range(2000, 2500);
>
> Any comment on how this delay value is obtained?
I don't have any specific comments, I believe the 2000us it taken from
the datasheet and the 2500 is us playing nice with the scheduler.
<snip>
> > +static inline int miphy365x_phy_rdy(struct miphy365x_phy *miphy_phy,
> > + struct miphy365x_dev *miphy_dev)
> > +{
> > + int timeout = HFC_TIMEOUT;
> > + u8 mask = mask = IDLL_RDY | PLL_RDY;
>
> just u8 mask = IDLL_RDY | PLL_RDY; would suffice.
Hmm... not sure how this slipped through - will fix.
> > + u8 regval;
> > +
> > + do {
> > + regval = readb_relaxed(miphy_phy->base + STATUS_REG);
> > + usleep_range(2000, 2500);
>
> same here.
As above.
<snip>
> > + mask = DES_BIT_LOCK | DES_SYMBOL_LOCK;
> > + while ((readb_relaxed(miphy_phy->base + COMP_CTRL1_REG) & mask) != mask)
> > + cpu_relax();
>
> Don't we need to break from here at some point if the LOCK's are never set?
I'm sure sure that's possible, but I will invesigate and fixup if req'd.
<snip>
> > +static int miphy365x_phy_power_on(struct phy *phy)
> > +{
> > + return 0;
> > +}
> > +
> > +static int miphy365x_phy_power_off(struct phy *phy)
> > +{
> > + return 0;
> > +}
>
> Both these empty functions can be removed.
You're right, I see the NULL checks, thanks.
<snip>
> > +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> > + struct miphy365x_phy *phy, u8 port)
> > +{
> > + struct resource *res;
> > + char sata[16];
> > + char pcie[16];
>
> It can be done with a single variable ;-)
Right. :)
<snip>
> Phy provider register should be the last step in registering the PHY.
Okay, will fix, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
@ 2014-02-13 10:29 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-13 10:29 UTC (permalink / raw)
To: linux-arm-kernel
> > 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
>
> various SATA or PCIe devices in STMicroelectronics STiH41x SoC series?
To tell you the truth, I'm not sure if it is limited to ST's h/w, but
I think it can only be found there, so I'm happy to fixup.
<snip>
> > +config PHY_MIPHY365X
> > + tristate "STMicroelectronics MIPHY365X PHY driver for STiH41x series"
> > + depends on ARCH_STI
> > + depends on GENERIC_PHY
> depends on CONFIG_OF and HAS_IOMEM?
Sure, I'll fix.
<snip>
> > + * Copyright (C) 2014 STMicroelectronics
> > + *
> > + * STMicroelectronics PHY driver MiPHY365 (for SoC STiH416).
> > + *
> > + * Author: Alexandre Torgue <alexandre.torgue@st.com>
>
> The author of this patch is not Alexandre Torgue?
The history of this driver is long and the authors are many. Alex
did the last internal over-haul and converted it to use Generic PHY. I
took Alex's driver and made significant changes in order to upstream.
<snip>
> > +#define HFC_TIMEOUT 50
> > +
> > +#define SYSCFG_2521 0x824
> > +#define SYSCFG_2522 0x828
> > +#define SYSCFG_PCIE_SATA_MASK BIT(1)
> > +#define SYSCFG_PCIE_SATA_POS 1
> > +
> > +/* MiPHY365x register definitiona */
> > +#define RESET_REG 0x00
> > +#define RST_PLL BIT(1)
>
> There are quite a few alignment problems with these macros. It needs
> to be fixed.
This is just Git playing up.
In reality everything is perfectly aligned and all using tabs.
<snip>
> > +/*
> > + * This function selects the system configuration,
> > + * either two SATA, one SATA and one PCIe, or two PCIe lanes.
> > + */
> > +static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
> > + struct miphy365x_dev *miphy_dev)
> > +{
> > + u8 config = miphy_phy->type | miphy_phy->port;
> > + u32 mask = SYSCFG_PCIE_SATA_MASK;
> > + u32 reg;
> > + bool sata;
> > +
> > + switch (config) {
> > + case MIPHY_SATA_PORT0:
> > + reg = SYSCFG_2521;
> > + sata = true;
>
> How do we configure PORT1 for SATA here? Do we really support all the system
> configuration?
Good spot eagle-eye!
Actually in the current version there is a h/w bug which only allows
the SATA_PORT0 and PCIE_PORT1 configuration. When a new version fixing
this is released I will add version detection to the driver and we can
support full intended configuration options.
<snip>
> > +static inline int miphy365x_phy_hfc_not_rdy(struct miphy365x_phy *miphy_phy,
> > + struct miphy365x_dev *miphy_dev)
> > +{
> > + int timeout = HFC_TIMEOUT;
> > + u8 mask = IDLL_RDY | PLL_RDY;
> > + u8 regval;
> > +
> > + do {
> > + regval = readb_relaxed(miphy_phy->base + STATUS_REG);
> > + usleep_range(2000, 2500);
>
> Any comment on how this delay value is obtained?
I don't have any specific comments, I believe the 2000us it taken from
the datasheet and the 2500 is us playing nice with the scheduler.
<snip>
> > +static inline int miphy365x_phy_rdy(struct miphy365x_phy *miphy_phy,
> > + struct miphy365x_dev *miphy_dev)
> > +{
> > + int timeout = HFC_TIMEOUT;
> > + u8 mask = mask = IDLL_RDY | PLL_RDY;
>
> just u8 mask = IDLL_RDY | PLL_RDY; would suffice.
Hmm... not sure how this slipped through - will fix.
> > + u8 regval;
> > +
> > + do {
> > + regval = readb_relaxed(miphy_phy->base + STATUS_REG);
> > + usleep_range(2000, 2500);
>
> same here.
As above.
<snip>
> > + mask = DES_BIT_LOCK | DES_SYMBOL_LOCK;
> > + while ((readb_relaxed(miphy_phy->base + COMP_CTRL1_REG) & mask) != mask)
> > + cpu_relax();
>
> Don't we need to break from here at some point if the LOCK's are never set?
I'm sure sure that's possible, but I will invesigate and fixup if req'd.
<snip>
> > +static int miphy365x_phy_power_on(struct phy *phy)
> > +{
> > + return 0;
> > +}
> > +
> > +static int miphy365x_phy_power_off(struct phy *phy)
> > +{
> > + return 0;
> > +}
>
> Both these empty functions can be removed.
You're right, I see the NULL checks, thanks.
<snip>
> > +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> > + struct miphy365x_phy *phy, u8 port)
> > +{
> > + struct resource *res;
> > + char sata[16];
> > + char pcie[16];
>
> It can be done with a single variable ;-)
Right. :)
<snip>
> Phy provider register should be the last step in registering the PHY.
Okay, will fix, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
2014-02-12 16:54 ` Mark Rutland
@ 2014-02-13 10:47 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-13 10:47 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, Kishon Vijay Abraham I
> > 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>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/phy/Kconfig | 8 +
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 643 insertions(+)
> > create mode 100644 drivers/phy/phy-miphy365x.c
> >
>
> [...]
>
> > +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> > + struct miphy365x_phy *phy, u8 port)
> > +{
> > + struct resource *res;
> > + char sata[16];
> > + char pcie[16];
>
> Isn't 6 enough for either of these? There are at most two ports IIUC, so
> we only need a single character for the port number.
Yep, being a bit overzealous there, will fix.
<snip>
> > +
> > + of_property_read_string(np, "st,sata_gen", &sata_gen);
>
> This wasn't in the binding documentation. It also violates dt style;
> s/_/-/
No problem, will fix.
> Could these not be numbers, or can this not come from elsewhere?
>
> Or are there some crazy SATA generations to support?
Nope, just [1|2|3] I think. Can be numbers, will fix.
> > + if (sata_gen) {
> > + if (!strcmp(sata_gen, "gen3"))
> > + phy_dev->sata_gen = SATA_GEN3;
> > + else if (!strcmp(sata_gen, "gen2"))
> > + phy_dev->sata_gen = SATA_GEN2;
> > + }
> > +
> > + phy_dev->pcie_tx_pol_inv =
> > + of_property_read_bool(np, "st,pcie_tx_pol_inv");
> > +
> > + phy_dev->sata_tx_pol_inv =
> > + of_property_read_bool(np, "st,sata_tx_pol_inv");
>
> Likewise for both of these on the first two points.
1. Roger will fix.
2. Not probeable I'm afraid.
> > +
> > + return 0;
> > +}
> > +
> > +static int miphy365x_phy_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + struct miphy365x_dev *phy_dev;
> > + struct device *dev = &pdev->dev;
> > + struct phy_provider *provider;
> > + u8 port;
> > + int ret;
> > +
> > + if (!np) {
> > + dev_err(dev, "No DT found\n");
>
> s/DT/node/ ?
s/DT/DT node/
Will fix, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
@ 2014-02-13 10:47 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-13 10:47 UTC (permalink / raw)
To: linux-arm-kernel
> > 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>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/phy/Kconfig | 8 +
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 643 insertions(+)
> > create mode 100644 drivers/phy/phy-miphy365x.c
> >
>
> [...]
>
> > +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> > + struct miphy365x_phy *phy, u8 port)
> > +{
> > + struct resource *res;
> > + char sata[16];
> > + char pcie[16];
>
> Isn't 6 enough for either of these? There are at most two ports IIUC, so
> we only need a single character for the port number.
Yep, being a bit overzealous there, will fix.
<snip>
> > +
> > + of_property_read_string(np, "st,sata_gen", &sata_gen);
>
> This wasn't in the binding documentation. It also violates dt style;
> s/_/-/
No problem, will fix.
> Could these not be numbers, or can this not come from elsewhere?
>
> Or are there some crazy SATA generations to support?
Nope, just [1|2|3] I think. Can be numbers, will fix.
> > + if (sata_gen) {
> > + if (!strcmp(sata_gen, "gen3"))
> > + phy_dev->sata_gen = SATA_GEN3;
> > + else if (!strcmp(sata_gen, "gen2"))
> > + phy_dev->sata_gen = SATA_GEN2;
> > + }
> > +
> > + phy_dev->pcie_tx_pol_inv =
> > + of_property_read_bool(np, "st,pcie_tx_pol_inv");
> > +
> > + phy_dev->sata_tx_pol_inv =
> > + of_property_read_bool(np, "st,sata_tx_pol_inv");
>
> Likewise for both of these on the first two points.
1. Roger will fix.
2. Not probeable I'm afraid.
> > +
> > + return 0;
> > +}
> > +
> > +static int miphy365x_phy_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + struct miphy365x_dev *phy_dev;
> > + struct device *dev = &pdev->dev;
> > + struct phy_provider *provider;
> > + u8 port;
> > + int ret;
> > +
> > + if (!np) {
> > + dev_err(dev, "No DT found\n");
>
> s/DT/node/ ?
s/DT/DT node/
Will fix, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-02-12 16:40 ` Mark Rutland
(?)
@ 2014-02-13 11:03 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-13 11:03 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, devicetree,
Srinivas Kandagatla
> > 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: devicetree@vger.kernel.org
> > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> > 1 file changed, 43 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..fdfa7ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > @@ -0,0 +1,43 @@
> > +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 example)
>
> The first example has #phy-cells = <1>.
Right, will fix. Should be 2.
> What do the cells mean? What are the expected values?
http://www.spinics.net/lists/arm-kernel/msg307209.html
> > +- reg: Address and length of the register set for the device
> > +- reg-names: The names of the register addresses corresponding to the
> > + registers filled in "reg".
>
> Whenever there is a ${PROP}-names property, there should be a list of
> explicit values, and a description of how it relates to ${PROP}. Without
> that it's a bit useless.
>
> Please provide an explicit list of expected names here.
>
> I assume here what you want is something like:
>
> - reg: a list of address + length pairs, one for each entry in reg-names
> - reg-names: should contain:
> * "sata0" for the sata0 control registers...
> * "sata1" ...
> * "pcie0" ...
> * "pcie1" ...
Can do.
> > +- st,syscfg : Should be a phandle of the syscfg node.
>
> What's this used for?
It's used to gain access to the system configuration
registers. Specifically in this case the bits to choose between PCI or
SATA mode.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-13 11:03 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-13 11:03 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, devicetree,
Srinivas Kandagatla
> > 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: devicetree@vger.kernel.org
> > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> > 1 file changed, 43 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..fdfa7ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > @@ -0,0 +1,43 @@
> > +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 example)
>
> The first example has #phy-cells = <1>.
Right, will fix. Should be 2.
> What do the cells mean? What are the expected values?
http://www.spinics.net/lists/arm-kernel/msg307209.html
> > +- reg: Address and length of the register set for the device
> > +- reg-names: The names of the register addresses corresponding to the
> > + registers filled in "reg".
>
> Whenever there is a ${PROP}-names property, there should be a list of
> explicit values, and a description of how it relates to ${PROP}. Without
> that it's a bit useless.
>
> Please provide an explicit list of expected names here.
>
> I assume here what you want is something like:
>
> - reg: a list of address + length pairs, one for each entry in reg-names
> - reg-names: should contain:
> * "sata0" for the sata0 control registers...
> * "sata1" ...
> * "pcie0" ...
> * "pcie1" ...
Can do.
> > +- st,syscfg : Should be a phandle of the syscfg node.
>
> What's this used for?
It's used to gain access to the system configuration
registers. Specifically in this case the bits to choose between PCI or
SATA mode.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-13 11:03 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-13 11:03 UTC (permalink / raw)
To: linux-arm-kernel
> > 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: devicetree at vger.kernel.org
> > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> > 1 file changed, 43 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..fdfa7ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > @@ -0,0 +1,43 @@
> > +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 example)
>
> The first example has #phy-cells = <1>.
Right, will fix. Should be 2.
> What do the cells mean? What are the expected values?
http://www.spinics.net/lists/arm-kernel/msg307209.html
> > +- reg: Address and length of the register set for the device
> > +- reg-names: The names of the register addresses corresponding to the
> > + registers filled in "reg".
>
> Whenever there is a ${PROP}-names property, there should be a list of
> explicit values, and a description of how it relates to ${PROP}. Without
> that it's a bit useless.
>
> Please provide an explicit list of expected names here.
>
> I assume here what you want is something like:
>
> - reg: a list of address + length pairs, one for each entry in reg-names
> - reg-names: should contain:
> * "sata0" for the sata0 control registers...
> * "sata1" ...
> * "pcie0" ...
> * "pcie1" ...
Can do.
> > +- st,syscfg : Should be a phandle of the syscfg node.
>
> What's this used for?
It's used to gain access to the system configuration
registers. Specifically in this case the bits to choose between PCI or
SATA mode.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-02-13 11:03 ` Lee Jones
(?)
@ 2014-02-13 12:23 ` Mark Rutland
-1 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-02-13 12:23 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, devicetree,
Srinivas Kandagatla
On Thu, Feb 13, 2014 at 11:03:14AM +0000, 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: devicetree@vger.kernel.org
> > > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> > > 1 file changed, 43 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..fdfa7ca
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > > @@ -0,0 +1,43 @@
> > > +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 example)
> >
> > The first example has #phy-cells = <1>.
>
> Right, will fix. Should be 2.
>
> > What do the cells mean? What are the expected values?
>
> http://www.spinics.net/lists/arm-kernel/msg307209.html
Ok. Could that be mentioned in the binding document then?
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-13 12:23 ` Mark Rutland
0 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-02-13 12:23 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
Srinivas Kandagatla
On Thu, Feb 13, 2014 at 11:03:14AM +0000, 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: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > Cc: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
> > > Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > ---
> > > .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> > > 1 file changed, 43 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..fdfa7ca
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > > @@ -0,0 +1,43 @@
> > > +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 example)
> >
> > The first example has #phy-cells = <1>.
>
> Right, will fix. Should be 2.
>
> > What do the cells mean? What are the expected values?
>
> http://www.spinics.net/lists/arm-kernel/msg307209.html
Ok. Could that be mentioned in the binding document then?
Cheers,
Mark.
--
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
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-13 12:23 ` Mark Rutland
0 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-02-13 12:23 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 13, 2014 at 11:03:14AM +0000, 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: devicetree at vger.kernel.org
> > > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> > > 1 file changed, 43 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..fdfa7ca
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > > @@ -0,0 +1,43 @@
> > > +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 example)
> >
> > The first example has #phy-cells = <1>.
>
> Right, will fix. Should be 2.
>
> > What do the cells mean? What are the expected values?
>
> http://www.spinics.net/lists/arm-kernel/msg307209.html
Ok. Could that be mentioned in the binding document then?
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-06-24 14:08 ` Arnd Bergmann
(?)
@ 2014-06-24 14:51 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-24 14:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kishon Vijay Abraham I, Sergei Shtylyov, devicetree,
linux-arm-kernel, linux-kernel
On Tue, 24 Jun 2014, Arnd Bergmann wrote:
> On Tuesday 24 June 2014 13:46:34 Lee Jones wrote:
> > > > > > converting all addresses to to resources so drivers can easily pull
> > > > > > them out using platform_get_resource() and friends. Pushing the reg
> > > > >
> > > > > right. Can't we use of_address_to_resource here?
> > > >
> > > > We could, but that would be an extra layer. We'd be pulling the
> > > > address, putting it into a resource, then pulling it from the resource
> > > > for use. If we're going to be pulling addresses out manually, we're
> > > > probably better off using of_get_address(). But again, we're just
> > > > carrying out functionality which is already provided by the
> > > > framework.
> > >
> > > there is also of_ioremap().
> >
> > Isn't this SPARK only? And doesn't it require a populated resource?
> > Which is what I'm saying is the issue here i.e. we don't have one.
>
> Sorry, I meant of_iomap(). I think it's only for historic reaons
> that we have both. Probably of_iomap started out on powerpc with
> the same intention as the sparc of_ioremap.
>
> of_iomap does not require a resource, just an index.
Ah, this sounds like a better solution. I'll have a play, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-24 14:51 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-24 14:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kishon Vijay Abraham I, Sergei Shtylyov, devicetree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Tue, 24 Jun 2014, Arnd Bergmann wrote:
> On Tuesday 24 June 2014 13:46:34 Lee Jones wrote:
> > > > > > converting all addresses to to resources so drivers can easily pull
> > > > > > them out using platform_get_resource() and friends. Pushing the reg
> > > > >
> > > > > right. Can't we use of_address_to_resource here?
> > > >
> > > > We could, but that would be an extra layer. We'd be pulling the
> > > > address, putting it into a resource, then pulling it from the resource
> > > > for use. If we're going to be pulling addresses out manually, we're
> > > > probably better off using of_get_address(). But again, we're just
> > > > carrying out functionality which is already provided by the
> > > > framework.
> > >
> > > there is also of_ioremap().
> >
> > Isn't this SPARK only? And doesn't it require a populated resource?
> > Which is what I'm saying is the issue here i.e. we don't have one.
>
> Sorry, I meant of_iomap(). I think it's only for historic reaons
> that we have both. Probably of_iomap started out on powerpc with
> the same intention as the sparc of_ioremap.
>
> of_iomap does not require a resource, just an index.
Ah, this sounds like a better solution. I'll have a play, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-24 14:51 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-24 14:51 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 24 Jun 2014, Arnd Bergmann wrote:
> On Tuesday 24 June 2014 13:46:34 Lee Jones wrote:
> > > > > > converting all addresses to to resources so drivers can easily pull
> > > > > > them out using platform_get_resource() and friends. Pushing the reg
> > > > >
> > > > > right. Can't we use of_address_to_resource here?
> > > >
> > > > We could, but that would be an extra layer. We'd be pulling the
> > > > address, putting it into a resource, then pulling it from the resource
> > > > for use. If we're going to be pulling addresses out manually, we're
> > > > probably better off using of_get_address(). But again, we're just
> > > > carrying out functionality which is already provided by the
> > > > framework.
> > >
> > > there is also of_ioremap().
> >
> > Isn't this SPARK only? And doesn't it require a populated resource?
> > Which is what I'm saying is the issue here i.e. we don't have one.
>
> Sorry, I meant of_iomap(). I think it's only for historic reaons
> that we have both. Probably of_iomap started out on powerpc with
> the same intention as the sparc of_ioremap.
>
> of_iomap does not require a resource, just an index.
Ah, this sounds like a better solution. I'll have a play, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-06-24 12:46 ` Lee Jones
(?)
@ 2014-06-24 14:08 ` Arnd Bergmann
-1 siblings, 0 replies; 69+ messages in thread
From: Arnd Bergmann @ 2014-06-24 14:08 UTC (permalink / raw)
To: Lee Jones
Cc: Kishon Vijay Abraham I, Sergei Shtylyov, devicetree,
linux-arm-kernel, linux-kernel
On Tuesday 24 June 2014 13:46:34 Lee Jones wrote:
> > > > > converting all addresses to to resources so drivers can easily pull
> > > > > them out using platform_get_resource() and friends. Pushing the reg
> > > >
> > > > right. Can't we use of_address_to_resource here?
> > >
> > > We could, but that would be an extra layer. We'd be pulling the
> > > address, putting it into a resource, then pulling it from the resource
> > > for use. If we're going to be pulling addresses out manually, we're
> > > probably better off using of_get_address(). But again, we're just
> > > carrying out functionality which is already provided by the
> > > framework.
> >
> > there is also of_ioremap().
>
> Isn't this SPARK only? And doesn't it require a populated resource?
> Which is what I'm saying is the issue here i.e. we don't have one.
Sorry, I meant of_iomap(). I think it's only for historic reaons
that we have both. Probably of_iomap started out on powerpc with
the same intention as the sparc of_ioremap.
of_iomap does not require a resource, just an index.
Arnd
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-24 14:08 ` Arnd Bergmann
0 siblings, 0 replies; 69+ messages in thread
From: Arnd Bergmann @ 2014-06-24 14:08 UTC (permalink / raw)
To: Lee Jones
Cc: Kishon Vijay Abraham I, Sergei Shtylyov, devicetree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Tuesday 24 June 2014 13:46:34 Lee Jones wrote:
> > > > > converting all addresses to to resources so drivers can easily pull
> > > > > them out using platform_get_resource() and friends. Pushing the reg
> > > >
> > > > right. Can't we use of_address_to_resource here?
> > >
> > > We could, but that would be an extra layer. We'd be pulling the
> > > address, putting it into a resource, then pulling it from the resource
> > > for use. If we're going to be pulling addresses out manually, we're
> > > probably better off using of_get_address(). But again, we're just
> > > carrying out functionality which is already provided by the
> > > framework.
> >
> > there is also of_ioremap().
>
> Isn't this SPARK only? And doesn't it require a populated resource?
> Which is what I'm saying is the issue here i.e. we don't have one.
Sorry, I meant of_iomap(). I think it's only for historic reaons
that we have both. Probably of_iomap started out on powerpc with
the same intention as the sparc of_ioremap.
of_iomap does not require a resource, just an index.
Arnd
--
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
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-24 14:08 ` Arnd Bergmann
0 siblings, 0 replies; 69+ messages in thread
From: Arnd Bergmann @ 2014-06-24 14:08 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 24 June 2014 13:46:34 Lee Jones wrote:
> > > > > converting all addresses to to resources so drivers can easily pull
> > > > > them out using platform_get_resource() and friends. Pushing the reg
> > > >
> > > > right. Can't we use of_address_to_resource here?
> > >
> > > We could, but that would be an extra layer. We'd be pulling the
> > > address, putting it into a resource, then pulling it from the resource
> > > for use. If we're going to be pulling addresses out manually, we're
> > > probably better off using of_get_address(). But again, we're just
> > > carrying out functionality which is already provided by the
> > > framework.
> >
> > there is also of_ioremap().
>
> Isn't this SPARK only? And doesn't it require a populated resource?
> Which is what I'm saying is the issue here i.e. we don't have one.
Sorry, I meant of_iomap(). I think it's only for historic reaons
that we have both. Probably of_iomap started out on powerpc with
the same intention as the sparc of_ioremap.
of_iomap does not require a resource, just an index.
Arnd
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-06-24 9:38 ` Arnd Bergmann
@ 2014-06-24 12:46 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-24 12:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kishon Vijay Abraham I, Sergei Shtylyov, devicetree,
linux-arm-kernel, linux-kernel
> > > > converting all addresses to to resources so drivers can easily pull
> > > > them out using platform_get_resource() and friends. Pushing the reg
> > >
> > > right. Can't we use of_address_to_resource here?
> >
> > We could, but that would be an extra layer. We'd be pulling the
> > address, putting it into a resource, then pulling it from the resource
> > for use. If we're going to be pulling addresses out manually, we're
> > probably better off using of_get_address(). But again, we're just
> > carrying out functionality which is already provided by the
> > framework.
>
> there is also of_ioremap().
Isn't this SPARK only? And doesn't it require a populated resource?
Which is what I'm saying is the issue here i.e. we don't have one.
> > > > properties down into a child node means that we have to now iterate
> > > > over the sub-nodes and pull them out manually. This will lead to a
> > >
> > > You anyway iterate while creating PHYs based on some constant. Now you have to
> > > iterate over the sub-nodes.
> > > > pretty messy implementation IMHO.
> >
> > This much is true.
> >
> > > > Can you point me in the direction of previous implementations where you
> > > > have stipulated the same set of constraints please?
> > >
> > > ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> > > this will just add to the complexity of the driver.
> >
> > =:)
> >
> > > Maybe we should ask the opinion of others?
> >
> > We could. I'll CC Arnd as he likes this PHY stuff. :)
> >
> > > [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
>
> Having sub-nodes for each individual PHY managed by a controller seems
> very reasonable to me. Making them show up as separate platform devices
> seems less useful though.
Are there any examples of other nodes with reg properties, but not
compatible strings i.e. ones that aren't probed independently and
aren't platform devices that I can use for reference. I'm having a
hard time figuring out how to _easily_ obtain indexed addresses
without adding a bunch of new code. Perhaps if we did something in
the core there would be less overhead overall?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-24 12:46 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-24 12:46 UTC (permalink / raw)
To: linux-arm-kernel
> > > > converting all addresses to to resources so drivers can easily pull
> > > > them out using platform_get_resource() and friends. Pushing the reg
> > >
> > > right. Can't we use of_address_to_resource here?
> >
> > We could, but that would be an extra layer. We'd be pulling the
> > address, putting it into a resource, then pulling it from the resource
> > for use. If we're going to be pulling addresses out manually, we're
> > probably better off using of_get_address(). But again, we're just
> > carrying out functionality which is already provided by the
> > framework.
>
> there is also of_ioremap().
Isn't this SPARK only? And doesn't it require a populated resource?
Which is what I'm saying is the issue here i.e. we don't have one.
> > > > properties down into a child node means that we have to now iterate
> > > > over the sub-nodes and pull them out manually. This will lead to a
> > >
> > > You anyway iterate while creating PHYs based on some constant. Now you have to
> > > iterate over the sub-nodes.
> > > > pretty messy implementation IMHO.
> >
> > This much is true.
> >
> > > > Can you point me in the direction of previous implementations where you
> > > > have stipulated the same set of constraints please?
> > >
> > > ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> > > this will just add to the complexity of the driver.
> >
> > =:)
> >
> > > Maybe we should ask the opinion of others?
> >
> > We could. I'll CC Arnd as he likes this PHY stuff. :)
> >
> > > [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
>
> Having sub-nodes for each individual PHY managed by a controller seems
> very reasonable to me. Making them show up as separate platform devices
> seems less useful though.
Are there any examples of other nodes with reg properties, but not
compatible strings i.e. ones that aren't probed independently and
aren't platform devices that I can use for reference. I'm having a
hard time figuring out how to _easily_ obtain indexed addresses
without adding a bunch of new code. Perhaps if we did something in
the core there would be less overhead overall?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-06-18 10:04 ` Lee Jones
(?)
@ 2014-06-24 9:38 ` Arnd Bergmann
-1 siblings, 0 replies; 69+ messages in thread
From: Arnd Bergmann @ 2014-06-24 9:38 UTC (permalink / raw)
To: Lee Jones
Cc: Kishon Vijay Abraham I, Sergei Shtylyov, devicetree,
linux-arm-kernel, linux-kernel
On Wednesday 18 June 2014 11:04:11 Lee Jones wrote:
> > On Tuesday 17 June 2014 04:53 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.
> > >>
> > >> I've asked others who wrote multi-phy PHY providers to model each individual
> > >> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
> > >> do. So in this case the dt node should look something like:
> > >>
> > >> miphy365x_phy: miphy365x@fe382000 {
> > >> compatible = "st,miphy365x-phy";
> > >> #phy-cells = <2>;
> > >> st,syscfg = <&syscfg_rear>;
> > >> channel@0 {
> > >> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
> > >> reg-names = "sata", "pcie";
> > >> }
> > >>
> > >> channel@1{
> > >> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
> > >> reg-names = "sata", "pcie";
> > >> }
> > >>
> > >> };
> > >
> > > I'm interested to know why you've taken this approach, as it makes the
> > > code much more complex. The DT framework goes to the trouble of
> >
> > It looks to be much closer representation of the hardware in dt. It also
> > enables to have more control of each individual PHYs. For example, we can have
> > something like status="disabled" for channels which is disabled.
>
> If you wanted to disable the channels in this way, you would either
> have to A) add your own code to parse that property or B) have each
> channel set itself up as platform device and would probe (or not if
> status = "disabled") individually. If you choose the later option,
> the platform resource would also be populated.
We have of_device_is_available() and for_each_available_child_of_node()
to check for the status property. This doesn't seem much extra overhead.
> > > converting all addresses to to resources so drivers can easily pull
> > > them out using platform_get_resource() and friends. Pushing the reg
> >
> > right. Can't we use of_address_to_resource here?
>
> We could, but that would be an extra layer. We'd be pulling the
> address, putting it into a resource, then pulling it from the resource
> for use. If we're going to be pulling addresses out manually, we're
> probably better off using of_get_address(). But again, we're just
> carrying out functionality which is already provided by the
> framework.
there is also of_ioremap().
> > > properties down into a child node means that we have to now iterate
> > > over the sub-nodes and pull them out manually. This will lead to a
> >
> > You anyway iterate while creating PHYs based on some constant. Now you have to
> > iterate over the sub-nodes.
> > > pretty messy implementation IMHO.
>
> This much is true.
>
> > > Can you point me in the direction of previous implementations where you
> > > have stipulated the same set of constraints please?
> >
> > ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> > this will just add to the complexity of the driver.
>
> =:)
>
> > Maybe we should ask the opinion of others?
>
> We could. I'll CC Arnd as he likes this PHY stuff. :)
>
> > [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
Having sub-nodes for each individual PHY managed by a controller seems
very reasonable to me. Making them show up as separate platform devices
seems less useful though.
Arnd
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-24 9:38 ` Arnd Bergmann
0 siblings, 0 replies; 69+ messages in thread
From: Arnd Bergmann @ 2014-06-24 9:38 UTC (permalink / raw)
To: Lee Jones
Cc: Kishon Vijay Abraham I, Sergei Shtylyov, devicetree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Wednesday 18 June 2014 11:04:11 Lee Jones wrote:
> > On Tuesday 17 June 2014 04:53 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.
> > >>
> > >> I've asked others who wrote multi-phy PHY providers to model each individual
> > >> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
> > >> do. So in this case the dt node should look something like:
> > >>
> > >> miphy365x_phy: miphy365x@fe382000 {
> > >> compatible = "st,miphy365x-phy";
> > >> #phy-cells = <2>;
> > >> st,syscfg = <&syscfg_rear>;
> > >> channel@0 {
> > >> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
> > >> reg-names = "sata", "pcie";
> > >> }
> > >>
> > >> channel@1{
> > >> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
> > >> reg-names = "sata", "pcie";
> > >> }
> > >>
> > >> };
> > >
> > > I'm interested to know why you've taken this approach, as it makes the
> > > code much more complex. The DT framework goes to the trouble of
> >
> > It looks to be much closer representation of the hardware in dt. It also
> > enables to have more control of each individual PHYs. For example, we can have
> > something like status="disabled" for channels which is disabled.
>
> If you wanted to disable the channels in this way, you would either
> have to A) add your own code to parse that property or B) have each
> channel set itself up as platform device and would probe (or not if
> status = "disabled") individually. If you choose the later option,
> the platform resource would also be populated.
We have of_device_is_available() and for_each_available_child_of_node()
to check for the status property. This doesn't seem much extra overhead.
> > > converting all addresses to to resources so drivers can easily pull
> > > them out using platform_get_resource() and friends. Pushing the reg
> >
> > right. Can't we use of_address_to_resource here?
>
> We could, but that would be an extra layer. We'd be pulling the
> address, putting it into a resource, then pulling it from the resource
> for use. If we're going to be pulling addresses out manually, we're
> probably better off using of_get_address(). But again, we're just
> carrying out functionality which is already provided by the
> framework.
there is also of_ioremap().
> > > properties down into a child node means that we have to now iterate
> > > over the sub-nodes and pull them out manually. This will lead to a
> >
> > You anyway iterate while creating PHYs based on some constant. Now you have to
> > iterate over the sub-nodes.
> > > pretty messy implementation IMHO.
>
> This much is true.
>
> > > Can you point me in the direction of previous implementations where you
> > > have stipulated the same set of constraints please?
> >
> > ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> > this will just add to the complexity of the driver.
>
> =:)
>
> > Maybe we should ask the opinion of others?
>
> We could. I'll CC Arnd as he likes this PHY stuff. :)
>
> > [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
Having sub-nodes for each individual PHY managed by a controller seems
very reasonable to me. Making them show up as separate platform devices
seems less useful though.
Arnd
--
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
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-24 9:38 ` Arnd Bergmann
0 siblings, 0 replies; 69+ messages in thread
From: Arnd Bergmann @ 2014-06-24 9:38 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 18 June 2014 11:04:11 Lee Jones wrote:
> > On Tuesday 17 June 2014 04:53 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.
> > >>
> > >> I've asked others who wrote multi-phy PHY providers to model each individual
> > >> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
> > >> do. So in this case the dt node should look something like:
> > >>
> > >> miphy365x_phy: miphy365x at fe382000 {
> > >> compatible = "st,miphy365x-phy";
> > >> #phy-cells = <2>;
> > >> st,syscfg = <&syscfg_rear>;
> > >> channel at 0 {
> > >> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
> > >> reg-names = "sata", "pcie";
> > >> }
> > >>
> > >> channel at 1{
> > >> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
> > >> reg-names = "sata", "pcie";
> > >> }
> > >>
> > >> };
> > >
> > > I'm interested to know why you've taken this approach, as it makes the
> > > code much more complex. The DT framework goes to the trouble of
> >
> > It looks to be much closer representation of the hardware in dt. It also
> > enables to have more control of each individual PHYs. For example, we can have
> > something like status="disabled" for channels which is disabled.
>
> If you wanted to disable the channels in this way, you would either
> have to A) add your own code to parse that property or B) have each
> channel set itself up as platform device and would probe (or not if
> status = "disabled") individually. If you choose the later option,
> the platform resource would also be populated.
We have of_device_is_available() and for_each_available_child_of_node()
to check for the status property. This doesn't seem much extra overhead.
> > > converting all addresses to to resources so drivers can easily pull
> > > them out using platform_get_resource() and friends. Pushing the reg
> >
> > right. Can't we use of_address_to_resource here?
>
> We could, but that would be an extra layer. We'd be pulling the
> address, putting it into a resource, then pulling it from the resource
> for use. If we're going to be pulling addresses out manually, we're
> probably better off using of_get_address(). But again, we're just
> carrying out functionality which is already provided by the
> framework.
there is also of_ioremap().
> > > properties down into a child node means that we have to now iterate
> > > over the sub-nodes and pull them out manually. This will lead to a
> >
> > You anyway iterate while creating PHYs based on some constant. Now you have to
> > iterate over the sub-nodes.
> > > pretty messy implementation IMHO.
>
> This much is true.
>
> > > Can you point me in the direction of previous implementations where you
> > > have stipulated the same set of constraints please?
> >
> > ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> > this will just add to the complexity of the driver.
>
> =:)
>
> > Maybe we should ask the opinion of others?
>
> We could. I'll CC Arnd as he likes this PHY stuff. :)
>
> > [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
Having sub-nodes for each individual PHY managed by a controller seems
very reasonable to me. Making them show up as separate platform devices
seems less useful though.
Arnd
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-06-18 9:50 ` Kishon Vijay Abraham I
@ 2014-06-18 10:04 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-18 10:04 UTC (permalink / raw)
To: Kishon Vijay Abraham I, arnd
Cc: Sergei Shtylyov, devicetree, linux-arm-kernel, linux-kernel
> On Tuesday 17 June 2014 04:53 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.
> >>
> >> I've asked others who wrote multi-phy PHY providers to model each individual
> >> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
> >> do. So in this case the dt node should look something like:
> >>
> >> miphy365x_phy: miphy365x@fe382000 {
> >> compatible = "st,miphy365x-phy";
> >> #phy-cells = <2>;
> >> st,syscfg = <&syscfg_rear>;
> >> channel@0 {
> >> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
> >> reg-names = "sata", "pcie";
> >> }
> >>
> >> channel@1{
> >> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
> >> reg-names = "sata", "pcie";
> >> }
> >>
> >> };
> >
> > I'm interested to know why you've taken this approach, as it makes the
> > code much more complex. The DT framework goes to the trouble of
>
> It looks to be much closer representation of the hardware in dt. It also
> enables to have more control of each individual PHYs. For example, we can have
> something like status="disabled" for channels which is disabled.
If you wanted to disable the channels in this way, you would either
have to A) add your own code to parse that property or B) have each
channel set itself up as platform device and would probe (or not if
status = "disabled") individually. If you choose the later option,
the platform resource would also be populated.
> > converting all addresses to to resources so drivers can easily pull
> > them out using platform_get_resource() and friends. Pushing the reg
>
> right. Can't we use of_address_to_resource here?
We could, but that would be an extra layer. We'd be pulling the
address, putting it into a resource, then pulling it from the resource
for use. If we're going to be pulling addresses out manually, we're
probably better off using of_get_address(). But again, we're just
carrying out functionality which is already provided by the
framework.
> > properties down into a child node means that we have to now iterate
> > over the sub-nodes and pull them out manually. This will lead to a
>
> You anyway iterate while creating PHYs based on some constant. Now you have to
> iterate over the sub-nodes.
> > pretty messy implementation IMHO.
This much is true.
> > Can you point me in the direction of previous implementations where you
> > have stipulated the same set of constraints please?
>
> ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> this will just add to the complexity of the driver.
=:)
> Maybe we should ask the opinion of others?
We could. I'll CC Arnd as he likes this PHY stuff. :)
> [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-18 10:04 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-18 10:04 UTC (permalink / raw)
To: linux-arm-kernel
> On Tuesday 17 June 2014 04:53 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.
> >>
> >> I've asked others who wrote multi-phy PHY providers to model each individual
> >> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
> >> do. So in this case the dt node should look something like:
> >>
> >> miphy365x_phy: miphy365x at fe382000 {
> >> compatible = "st,miphy365x-phy";
> >> #phy-cells = <2>;
> >> st,syscfg = <&syscfg_rear>;
> >> channel at 0 {
> >> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
> >> reg-names = "sata", "pcie";
> >> }
> >>
> >> channel at 1{
> >> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
> >> reg-names = "sata", "pcie";
> >> }
> >>
> >> };
> >
> > I'm interested to know why you've taken this approach, as it makes the
> > code much more complex. The DT framework goes to the trouble of
>
> It looks to be much closer representation of the hardware in dt. It also
> enables to have more control of each individual PHYs. For example, we can have
> something like status="disabled" for channels which is disabled.
If you wanted to disable the channels in this way, you would either
have to A) add your own code to parse that property or B) have each
channel set itself up as platform device and would probe (or not if
status = "disabled") individually. If you choose the later option,
the platform resource would also be populated.
> > converting all addresses to to resources so drivers can easily pull
> > them out using platform_get_resource() and friends. Pushing the reg
>
> right. Can't we use of_address_to_resource here?
We could, but that would be an extra layer. We'd be pulling the
address, putting it into a resource, then pulling it from the resource
for use. If we're going to be pulling addresses out manually, we're
probably better off using of_get_address(). But again, we're just
carrying out functionality which is already provided by the
framework.
> > properties down into a child node means that we have to now iterate
> > over the sub-nodes and pull them out manually. This will lead to a
>
> You anyway iterate while creating PHYs based on some constant. Now you have to
> iterate over the sub-nodes.
> > pretty messy implementation IMHO.
This much is true.
> > Can you point me in the direction of previous implementations where you
> > have stipulated the same set of constraints please?
>
> ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> this will just add to the complexity of the driver.
=:)
> Maybe we should ask the opinion of others?
We could. I'll CC Arnd as he likes this PHY stuff. :)
> [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-06-17 11:23 ` Lee Jones
(?)
@ 2014-06-18 9:50 ` Kishon Vijay Abraham I
-1 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-06-18 9:50 UTC (permalink / raw)
To: Lee Jones, Sergei Shtylyov, devicetree; +Cc: linux-arm-kernel, linux-kernel
Hi,
On Tuesday 17 June 2014 04:53 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.
>>
>> I've asked others who wrote multi-phy PHY providers to model each individual
>> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
>> do. So in this case the dt node should look something like:
>>
>> miphy365x_phy: miphy365x@fe382000 {
>> compatible = "st,miphy365x-phy";
>> #phy-cells = <2>;
>> st,syscfg = <&syscfg_rear>;
>> channel@0 {
>> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
>> reg-names = "sata", "pcie";
>> }
>>
>> channel@1{
>> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
>> reg-names = "sata", "pcie";
>> }
>>
>> };
>
> I'm interested to know why you've taken this approach, as it makes the
> code much more complex. The DT framework goes to the trouble of
It looks to be much closer representation of the hardware in dt. It also
enables to have more control of each individual PHYs. For example, we can have
something like status="disabled" for channels which is disabled.
> converting all addresses to to resources so drivers can easily pull
> them out using platform_get_resource() and friends. Pushing the reg
right. Can't we use of_address_to_resource here?
> properties down into a child node means that we have to now iterate
> over the sub-nodes and pull them out manually. This will lead to a
You anyway iterate while creating PHYs based on some constant. Now you have to
iterate over the sub-nodes.
> pretty messy implementation IMHO.
>
> Can you point me in the direction of previous implementations where you
> have stipulated the same set of constraints please?
ah.. there isn't any. The author of the other multi-phy driver [1] also feels
this will just add to the complexity of the driver.
Maybe we should ask the opinion of others?
[1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-18 9:50 ` Kishon Vijay Abraham I
0 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-06-18 9:50 UTC (permalink / raw)
To: Lee Jones, Sergei Shtylyov, devicetree; +Cc: linux-arm-kernel, linux-kernel
Hi,
On Tuesday 17 June 2014 04:53 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.
>>
>> I've asked others who wrote multi-phy PHY providers to model each individual
>> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
>> do. So in this case the dt node should look something like:
>>
>> miphy365x_phy: miphy365x@fe382000 {
>> compatible = "st,miphy365x-phy";
>> #phy-cells = <2>;
>> st,syscfg = <&syscfg_rear>;
>> channel@0 {
>> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
>> reg-names = "sata", "pcie";
>> }
>>
>> channel@1{
>> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
>> reg-names = "sata", "pcie";
>> }
>>
>> };
>
> I'm interested to know why you've taken this approach, as it makes the
> code much more complex. The DT framework goes to the trouble of
It looks to be much closer representation of the hardware in dt. It also
enables to have more control of each individual PHYs. For example, we can have
something like status="disabled" for channels which is disabled.
> converting all addresses to to resources so drivers can easily pull
> them out using platform_get_resource() and friends. Pushing the reg
right. Can't we use of_address_to_resource here?
> properties down into a child node means that we have to now iterate
> over the sub-nodes and pull them out manually. This will lead to a
You anyway iterate while creating PHYs based on some constant. Now you have to
iterate over the sub-nodes.
> pretty messy implementation IMHO.
>
> Can you point me in the direction of previous implementations where you
> have stipulated the same set of constraints please?
ah.. there isn't any. The author of the other multi-phy driver [1] also feels
this will just add to the complexity of the driver.
Maybe we should ask the opinion of others?
[1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-18 9:50 ` Kishon Vijay Abraham I
0 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-06-18 9:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Tuesday 17 June 2014 04:53 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.
>>
>> I've asked others who wrote multi-phy PHY providers to model each individual
>> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
>> do. So in this case the dt node should look something like:
>>
>> miphy365x_phy: miphy365x at fe382000 {
>> compatible = "st,miphy365x-phy";
>> #phy-cells = <2>;
>> st,syscfg = <&syscfg_rear>;
>> channel at 0 {
>> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
>> reg-names = "sata", "pcie";
>> }
>>
>> channel at 1{
>> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
>> reg-names = "sata", "pcie";
>> }
>>
>> };
>
> I'm interested to know why you've taken this approach, as it makes the
> code much more complex. The DT framework goes to the trouble of
It looks to be much closer representation of the hardware in dt. It also
enables to have more control of each individual PHYs. For example, we can have
something like status="disabled" for channels which is disabled.
> converting all addresses to to resources so drivers can easily pull
> them out using platform_get_resource() and friends. Pushing the reg
right. Can't we use of_address_to_resource here?
> properties down into a child node means that we have to now iterate
> over the sub-nodes and pull them out manually. This will lead to a
You anyway iterate while creating PHYs based on some constant. Now you have to
iterate over the sub-nodes.
> pretty messy implementation IMHO.
>
> Can you point me in the direction of previous implementations where you
> have stipulated the same set of constraints please?
ah.. there isn't any. The author of the other multi-phy driver [1] also feels
this will just add to the complexity of the driver.
Maybe we should ask the opinion of others?
[1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-06-10 11:00 ` Kishon Vijay Abraham I
@ 2014-06-17 11:23 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-17 11:23 UTC (permalink / raw)
To: Kishon Vijay Abraham I; +Cc: linux-arm-kernel, linux-kernel
> > 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.
>
> I've asked others who wrote multi-phy PHY providers to model each individual
> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
> do. So in this case the dt node should look something like:
>
> miphy365x_phy: miphy365x@fe382000 {
> compatible = "st,miphy365x-phy";
> #phy-cells = <2>;
> st,syscfg = <&syscfg_rear>;
> channel@0 {
> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
> reg-names = "sata", "pcie";
> }
>
> channel@1{
> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
> reg-names = "sata", "pcie";
> }
>
> };
I'm interested to know why you've taken this approach, as it makes the
code much more complex. The DT framework goes to the trouble of
converting all addresses to to resources so drivers can easily pull
them out using platform_get_resource() and friends. Pushing the reg
properties down into a child node means that we have to now iterate
over the sub-nodes and pull them out manually. This will lead to a
pretty messy implementation IMHO.
Can you point me in the direction of previous implementations where you
have stipulated the same set of constraints please?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-17 11:23 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-06-17 11:23 UTC (permalink / raw)
To: linux-arm-kernel
> > 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.
>
> I've asked others who wrote multi-phy PHY providers to model each individual
> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
> do. So in this case the dt node should look something like:
>
> miphy365x_phy: miphy365x at fe382000 {
> compatible = "st,miphy365x-phy";
> #phy-cells = <2>;
> st,syscfg = <&syscfg_rear>;
> channel at 0 {
> reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
> reg-names = "sata", "pcie";
> }
>
> channel at 1{
> reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
> reg-names = "sata", "pcie";
> }
>
> };
I'm interested to know why you've taken this approach, as it makes the
code much more complex. The DT framework goes to the trouble of
converting all addresses to to resources so drivers can easily pull
them out using platform_get_resource() and friends. Pushing the reg
properties down into a child node means that we have to now iterate
over the sub-nodes and pull them out manually. This will lead to a
pretty messy implementation IMHO.
Can you point me in the direction of previous implementations where you
have stipulated the same set of constraints please?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-05-22 13:53 ` Lee Jones
@ 2014-06-10 11:00 ` Kishon Vijay Abraham I
-1 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-06-10 11:00 UTC (permalink / raw)
To: Lee Jones, linux-arm-kernel, linux-kernel
Hi,
On Thursday 22 May 2014 07:23 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.
I've asked others who wrote multi-phy PHY providers to model each individual
PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
do. So in this case the dt node should look something like:
miphy365x_phy: miphy365x@fe382000 {
compatible = "st,miphy365x-phy";
#phy-cells = <2>;
st,syscfg = <&syscfg_rear>;
channel@0 {
reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
reg-names = "sata", "pcie";
}
channel@1{
reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
reg-names = "sata", "pcie";
}
};
Thanks
Kishon
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-06-10 11:00 ` Kishon Vijay Abraham I
0 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-06-10 11:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Thursday 22 May 2014 07:23 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.
I've asked others who wrote multi-phy PHY providers to model each individual
PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
do. So in this case the dt node should look something like:
miphy365x_phy: miphy365x at fe382000 {
compatible = "st,miphy365x-phy";
#phy-cells = <2>;
st,syscfg = <&syscfg_rear>;
channel at 0 {
reg = <0xfe382000 0x100>, <0xfe394000 0x100>;
reg-names = "sata", "pcie";
}
channel at 1{
reg = <0xfe38a000 0x100>, <0xfe804000 0x100>;
reg-names = "sata", "pcie";
}
};
Thanks
Kishon
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-05-22 13:53 [RESEND 0/4] phy: Introduce support for MiPHY365x Lee Jones
@ 2014-05-22 13:53 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-05-22 13:53 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, kishon; +Cc: Lee Jones
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 | 62 ++++++++++++++++++++++
1 file changed, 62 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..cb39de1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,62 @@
+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)
+
+Example:
+
+ miphy365x_phy: miphy365x@fe382000 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg = <&syscfg_rear>;
+ };
+
+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>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-05-22 13:53 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-05-22 13:53 UTC (permalink / raw)
To: linux-arm-kernel
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 | 62 ++++++++++++++++++++++
1 file changed, 62 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..cb39de1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,62 @@
+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)
+
+Example:
+
+ miphy365x_phy: miphy365x at fe382000 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg = <&syscfg_rear>;
+ };
+
+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 at fe380000 {
+ ...
+ phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-05-19 14:00 ` Kishon Vijay Abraham I
@ 2014-05-19 14:07 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-05-19 14:07 UTC (permalink / raw)
To: Kishon Vijay Abraham I; +Cc: linux-arm-kernel, linux-kernel, kernel
> > Did you receive this set okay? I believe it's still unmerged?
>
> I think I missed it. But I'm already done with the PULL REQUEST to greg for
> 3.16 merge window.
Really, already? It's only -rc5?
> Can't we take it through dt tree for miphy?
Well there are 3 patches. 2 of which could go through your DT tree,
but the 3rd one is the driver itself.
> >> 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 | 62 ++++++++++++++++++++++
> >> 1 file changed, 62 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..cb39de1
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> >> @@ -0,0 +1,62 @@
> >> +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)
> >> +
> >> +Example:
> >> +
> >> + miphy365x_phy: miphy365x@fe382000 {
> >> + compatible = "st,miphy365x-phy";
> >> + #phy-cells = <2>;
> >> + reg = <0xfe382000 0x100>,
> >> + <0xfe38a000 0x100>,
> >> + <0xfe394000 0x100>,
> >> + <0xfe804000 0x100>;
> >> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> >> + st,syscfg = <&syscfg_rear>;
> >> + };
> >> +
> >> +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>;
> >> + ...
> >> + };
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-05-19 14:07 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-05-19 14:07 UTC (permalink / raw)
To: linux-arm-kernel
> > Did you receive this set okay? I believe it's still unmerged?
>
> I think I missed it. But I'm already done with the PULL REQUEST to greg for
> 3.16 merge window.
Really, already? It's only -rc5?
> Can't we take it through dt tree for miphy?
Well there are 3 patches. 2 of which could go through your DT tree,
but the 3rd one is the driver itself.
> >> 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 | 62 ++++++++++++++++++++++
> >> 1 file changed, 62 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..cb39de1
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> >> @@ -0,0 +1,62 @@
> >> +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)
> >> +
> >> +Example:
> >> +
> >> + miphy365x_phy: miphy365x at fe382000 {
> >> + compatible = "st,miphy365x-phy";
> >> + #phy-cells = <2>;
> >> + reg = <0xfe382000 0x100>,
> >> + <0xfe38a000 0x100>,
> >> + <0xfe394000 0x100>,
> >> + <0xfe804000 0x100>;
> >> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> >> + st,syscfg = <&syscfg_rear>;
> >> + };
> >> +
> >> +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 at fe380000 {
> >> + ...
> >> + phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
> >> + ...
> >> + };
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-05-19 13:56 ` Lee Jones
@ 2014-05-19 14:00 ` Kishon Vijay Abraham I
-1 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-05-19 14:00 UTC (permalink / raw)
To: Lee Jones, linux-arm-kernel, linux-kernel; +Cc: kernel
Hi,
On Monday 19 May 2014 07:26 PM, Lee Jones wrote:
> Kishon,
>
> Did you receive this set okay? I believe it's still unmerged?
I think I missed it. But I'm already done with the PULL REQUEST to greg for
3.16 merge window.
Can't we take it through dt tree for miphy?
Thanks
Kishon
>
>> 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 | 62 ++++++++++++++++++++++
>> 1 file changed, 62 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..cb39de1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
>> @@ -0,0 +1,62 @@
>> +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)
>> +
>> +Example:
>> +
>> + miphy365x_phy: miphy365x@fe382000 {
>> + compatible = "st,miphy365x-phy";
>> + #phy-cells = <2>;
>> + reg = <0xfe382000 0x100>,
>> + <0xfe38a000 0x100>,
>> + <0xfe394000 0x100>,
>> + <0xfe804000 0x100>;
>> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
>> + st,syscfg = <&syscfg_rear>;
>> + };
>> +
>> +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>;
>> + ...
>> + };
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-05-19 14:00 ` Kishon Vijay Abraham I
0 siblings, 0 replies; 69+ messages in thread
From: Kishon Vijay Abraham I @ 2014-05-19 14:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Monday 19 May 2014 07:26 PM, Lee Jones wrote:
> Kishon,
>
> Did you receive this set okay? I believe it's still unmerged?
I think I missed it. But I'm already done with the PULL REQUEST to greg for
3.16 merge window.
Can't we take it through dt tree for miphy?
Thanks
Kishon
>
>> 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 | 62 ++++++++++++++++++++++
>> 1 file changed, 62 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..cb39de1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
>> @@ -0,0 +1,62 @@
>> +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)
>> +
>> +Example:
>> +
>> + miphy365x_phy: miphy365x at fe382000 {
>> + compatible = "st,miphy365x-phy";
>> + #phy-cells = <2>;
>> + reg = <0xfe382000 0x100>,
>> + <0xfe38a000 0x100>,
>> + <0xfe394000 0x100>,
>> + <0xfe804000 0x100>;
>> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
>> + st,syscfg = <&syscfg_rear>;
>> + };
>> +
>> +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 at fe380000 {
>> + ...
>> + phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
>> + ...
>> + };
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-04-29 7:21 ` Lee Jones
@ 2014-05-19 13:56 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-05-19 13:56 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: kernel, Kishon Vijay Abraham I
Kishon,
Did you receive this set okay? I believe it's still unmerged?
> 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 | 62 ++++++++++++++++++++++
> 1 file changed, 62 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..cb39de1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,62 @@
> +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)
> +
> +Example:
> +
> + miphy365x_phy: miphy365x@fe382000 {
> + compatible = "st,miphy365x-phy";
> + #phy-cells = <2>;
> + reg = <0xfe382000 0x100>,
> + <0xfe38a000 0x100>,
> + <0xfe394000 0x100>,
> + <0xfe804000 0x100>;
> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> + st,syscfg = <&syscfg_rear>;
> + };
> +
> +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>;
> + ...
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-05-19 13:56 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-05-19 13:56 UTC (permalink / raw)
To: linux-arm-kernel
Kishon,
Did you receive this set okay? I believe it's still unmerged?
> 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 | 62 ++++++++++++++++++++++
> 1 file changed, 62 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..cb39de1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,62 @@
> +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)
> +
> +Example:
> +
> + miphy365x_phy: miphy365x at fe382000 {
> + compatible = "st,miphy365x-phy";
> + #phy-cells = <2>;
> + reg = <0xfe382000 0x100>,
> + <0xfe38a000 0x100>,
> + <0xfe394000 0x100>,
> + <0xfe804000 0x100>;
> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> + st,syscfg = <&syscfg_rear>;
> + };
> +
> +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 at fe380000 {
> + ...
> + phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
> + ...
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-04-29 7:21 [PATCH 0/4] phy: Introduce support for MiPHY365x Lee Jones
@ 2014-04-29 7:21 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-04-29 7:21 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: lee.jones, kernel, Kishon Vijay Abraham I
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 | 62 ++++++++++++++++++++++
1 file changed, 62 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..cb39de1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,62 @@
+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)
+
+Example:
+
+ miphy365x_phy: miphy365x@fe382000 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg = <&syscfg_rear>;
+ };
+
+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>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-04-29 7:21 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-04-29 7:21 UTC (permalink / raw)
To: linux-arm-kernel
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 | 62 ++++++++++++++++++++++
1 file changed, 62 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..cb39de1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,62 @@
+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)
+
+Example:
+
+ miphy365x_phy: miphy365x at fe382000 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg = <&syscfg_rear>;
+ };
+
+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 at fe380000 {
+ ...
+ phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-03-12 13:14 [PATCH 0/4] phy: Introduce support for MiPHY365x Lee Jones
@ 2014-03-12 13:14 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-03-12 13:14 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: lee.jones, kernel, alexandre.torgue, Kishon Vijay Abraham I
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 | 62 ++++++++++++++++++++++
1 file changed, 62 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..cb39de1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,62 @@
+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)
+
+Example:
+
+ miphy365x_phy: miphy365x@fe382000 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg = <&syscfg_rear>;
+ };
+
+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>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-03-12 13:14 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-03-12 13:14 UTC (permalink / raw)
To: linux-arm-kernel
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 | 62 ++++++++++++++++++++++
1 file changed, 62 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..cb39de1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,62 @@
+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)
+
+Example:
+
+ miphy365x_phy: miphy365x at fe382000 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg = <&syscfg_rear>;
+ };
+
+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 at fe380000 {
+ ...
+ phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-03-05 8:40 ` Lee Jones
(?)
@ 2014-03-05 9:12 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-03-05 9:12 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, devicetree,
Srinivas Kandagatla
> > > +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>;
> > > + ...
> > > + };
> >
> > Is there not a generic phy binding we can point to? It seems a bit
> > redundant to do this in each phy binding.
>
> Sure, but that wouldn't make much of an example.
>
> Documentation/devicetree/bindings/phy/phy-bindings.txt
Ah sorry, I see what you mean now.
No, not yet. That's the next thing to go up into Mainline.
I will replace this second example with a link when the other
documentation document has been accepted.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-03-05 9:12 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-03-05 9:12 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
Srinivas Kandagatla
> > > +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>;
> > > + ...
> > > + };
> >
> > Is there not a generic phy binding we can point to? It seems a bit
> > redundant to do this in each phy binding.
>
> Sure, but that wouldn't make much of an example.
>
> Documentation/devicetree/bindings/phy/phy-bindings.txt
Ah sorry, I see what you mean now.
No, not yet. That's the next thing to go up into Mainline.
I will replace this second example with a link when the other
documentation document has been accepted.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-03-05 9:12 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-03-05 9:12 UTC (permalink / raw)
To: linux-arm-kernel
> > > +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 at fe380000 {
> > > + ...
> > > + phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
> > > + ...
> > > + };
> >
> > Is there not a generic phy binding we can point to? It seems a bit
> > redundant to do this in each phy binding.
>
> Sure, but that wouldn't make much of an example.
>
> Documentation/devicetree/bindings/phy/phy-bindings.txt
Ah sorry, I see what you mean now.
No, not yet. That's the next thing to go up into Mainline.
I will replace this second example with a link when the other
documentation document has been accepted.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-03-05 7:34 ` Mark Rutland
(?)
@ 2014-03-05 8:40 ` Lee Jones
-1 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-03-05 8:40 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, devicetree,
Srinivas Kandagatla
On Wed, 05 Mar 2014, Mark Rutland wrote:
> On Fri, Feb 14, 2014 at 11:23:53AM +0000, 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: devicetree@vger.kernel.org
> > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
> > 1 file changed, 54 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..96f269f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > @@ -0,0 +1,54 @@
> > +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; MIPHY_PORT_{0,1}
> > + Second cell is device type; MIPHY_TYPE_{SATA,PCI}
>
> Either this should refer to the header file, or specific values should
> be given in the binding document.
When you say specific values you mean break out the {,}s?
I thought most people would know what they mean.
> > +- reg: Address and length of the register set for the device
> > +- reg-names: The names of the register addresses corresponding to the
> > + registers filled in "reg"
> > + Options are; sata{0,1} and pcie{0,1} (See first example)
>
> How about something like:
Same here.
> - reg: a list of offset + length pairs, one for each entry in reg-names
> - reg-names: should contain some of:
> * "sata0" for ...
> * "sata1" for ...
> * "pcie0" for ...
> * "pcie1" for ...
>
> Where ... might just be "the sata port 0 registers"
Seems awfully redundant.
> > +- st,syscfg : Should be a phandle of the system configuration register group
> > + which contain the SATA, PCIe mode setting bits
>
> I'll assume this is well-defined by some other binding.
Right.
> > +
> > +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)
>
> It might just be me, but the phrase "invert the polarity {SATA,PCIe} Tx"
> sounds odd. What exactly is being inverted?
>From the doc (and the only reference of this functionallity):
rx_polarity:
1: switch rxp/rxn
tx_polarity:
1: switch txp/txn
If we don't set these registers up to reflect the h/w configuration of
the board, the MiPHY will not work.
> > +
> > +Example:
> > +
> > + miphy365x_phy: miphy365x@0 {
> > + compatible = "st,miphy365x-phy";
> > + #phy-cells = <2>;
> > + reg = <0xfe382000 0x100>,
> > + <0xfe38a000 0x100>,
> > + <0xfe394000 0x100>,
> > + <0xfe804000 0x100>;
> > + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> > + st,syscfg= <&syscfg_rear>;
>
> Nit: missing space before '='.
Will fix.
> > + };
> > +
> > +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>;
> > + ...
> > + };
>
> Is there not a generic phy binding we can point to? It seems a bit
> redundant to do this in each phy binding.
Sure, but that wouldn't make much of an example.
Documentation/devicetree/bindings/phy/phy-bindings.txt
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-03-05 8:40 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-03-05 8:40 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, devicetree,
Srinivas Kandagatla
On Wed, 05 Mar 2014, Mark Rutland wrote:
> On Fri, Feb 14, 2014 at 11:23:53AM +0000, 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: devicetree@vger.kernel.org
> > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
> > 1 file changed, 54 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..96f269f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > @@ -0,0 +1,54 @@
> > +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; MIPHY_PORT_{0,1}
> > + Second cell is device type; MIPHY_TYPE_{SATA,PCI}
>
> Either this should refer to the header file, or specific values should
> be given in the binding document.
When you say specific values you mean break out the {,}s?
I thought most people would know what they mean.
> > +- reg: Address and length of the register set for the device
> > +- reg-names: The names of the register addresses corresponding to the
> > + registers filled in "reg"
> > + Options are; sata{0,1} and pcie{0,1} (See first example)
>
> How about something like:
Same here.
> - reg: a list of offset + length pairs, one for each entry in reg-names
> - reg-names: should contain some of:
> * "sata0" for ...
> * "sata1" for ...
> * "pcie0" for ...
> * "pcie1" for ...
>
> Where ... might just be "the sata port 0 registers"
Seems awfully redundant.
> > +- st,syscfg : Should be a phandle of the system configuration register group
> > + which contain the SATA, PCIe mode setting bits
>
> I'll assume this is well-defined by some other binding.
Right.
> > +
> > +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)
>
> It might just be me, but the phrase "invert the polarity {SATA,PCIe} Tx"
> sounds odd. What exactly is being inverted?
From the doc (and the only reference of this functionallity):
rx_polarity:
1: switch rxp/rxn
tx_polarity:
1: switch txp/txn
If we don't set these registers up to reflect the h/w configuration of
the board, the MiPHY will not work.
> > +
> > +Example:
> > +
> > + miphy365x_phy: miphy365x@0 {
> > + compatible = "st,miphy365x-phy";
> > + #phy-cells = <2>;
> > + reg = <0xfe382000 0x100>,
> > + <0xfe38a000 0x100>,
> > + <0xfe394000 0x100>,
> > + <0xfe804000 0x100>;
> > + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> > + st,syscfg= <&syscfg_rear>;
>
> Nit: missing space before '='.
Will fix.
> > + };
> > +
> > +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>;
> > + ...
> > + };
>
> Is there not a generic phy binding we can point to? It seems a bit
> redundant to do this in each phy binding.
Sure, but that wouldn't make much of an example.
Documentation/devicetree/bindings/phy/phy-bindings.txt
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-03-05 8:40 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-03-05 8:40 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 05 Mar 2014, Mark Rutland wrote:
> On Fri, Feb 14, 2014 at 11:23:53AM +0000, 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: devicetree at vger.kernel.org
> > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
> > 1 file changed, 54 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..96f269f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > @@ -0,0 +1,54 @@
> > +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; MIPHY_PORT_{0,1}
> > + Second cell is device type; MIPHY_TYPE_{SATA,PCI}
>
> Either this should refer to the header file, or specific values should
> be given in the binding document.
When you say specific values you mean break out the {,}s?
I thought most people would know what they mean.
> > +- reg: Address and length of the register set for the device
> > +- reg-names: The names of the register addresses corresponding to the
> > + registers filled in "reg"
> > + Options are; sata{0,1} and pcie{0,1} (See first example)
>
> How about something like:
Same here.
> - reg: a list of offset + length pairs, one for each entry in reg-names
> - reg-names: should contain some of:
> * "sata0" for ...
> * "sata1" for ...
> * "pcie0" for ...
> * "pcie1" for ...
>
> Where ... might just be "the sata port 0 registers"
Seems awfully redundant.
> > +- st,syscfg : Should be a phandle of the system configuration register group
> > + which contain the SATA, PCIe mode setting bits
>
> I'll assume this is well-defined by some other binding.
Right.
> > +
> > +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)
>
> It might just be me, but the phrase "invert the polarity {SATA,PCIe} Tx"
> sounds odd. What exactly is being inverted?
>From the doc (and the only reference of this functionallity):
rx_polarity:
1: switch rxp/rxn
tx_polarity:
1: switch txp/txn
If we don't set these registers up to reflect the h/w configuration of
the board, the MiPHY will not work.
> > +
> > +Example:
> > +
> > + miphy365x_phy: miphy365x at 0 {
> > + compatible = "st,miphy365x-phy";
> > + #phy-cells = <2>;
> > + reg = <0xfe382000 0x100>,
> > + <0xfe38a000 0x100>,
> > + <0xfe394000 0x100>,
> > + <0xfe804000 0x100>;
> > + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> > + st,syscfg= <&syscfg_rear>;
>
> Nit: missing space before '='.
Will fix.
> > + };
> > +
> > +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 at fe380000 {
> > + ...
> > + phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
> > + ...
> > + };
>
> Is there not a generic phy binding we can point to? It seems a bit
> redundant to do this in each phy binding.
Sure, but that wouldn't make much of an example.
Documentation/devicetree/bindings/phy/phy-bindings.txt
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
2014-02-14 11:23 ` Lee Jones
(?)
@ 2014-03-05 7:34 ` Mark Rutland
-1 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-03-05 7:34 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, alexandre.torgue, devicetree,
Srinivas Kandagatla
On Fri, Feb 14, 2014 at 11:23:53AM +0000, 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: devicetree@vger.kernel.org
> Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
> 1 file changed, 54 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..96f269f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,54 @@
> +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; MIPHY_PORT_{0,1}
> + Second cell is device type; MIPHY_TYPE_{SATA,PCI}
Either this should refer to the header file, or specific values should
be given in the binding document.
> +- reg: Address and length of the register set for the device
> +- reg-names: The names of the register addresses corresponding to the
> + registers filled in "reg"
> + Options are; sata{0,1} and pcie{0,1} (See first example)
How about something like:
- reg: a list of offset + length pairs, one for each entry in reg-names
- reg-names: should contain some of:
* "sata0" for ...
* "sata1" for ...
* "pcie0" for ...
* "pcie1" for ...
Where ... might just be "the sata port 0 registers"
> +- st,syscfg : Should be a phandle of the system configuration register group
> + which contain the SATA, PCIe mode setting bits
I'll assume this is well-defined by some other binding.
> +
> +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)
It might just be me, but the phrase "invert the polarity {SATA,PCIe} Tx"
sounds odd. What exactly is being inverted?
> +
> +Example:
> +
> + miphy365x_phy: miphy365x@0 {
> + compatible = "st,miphy365x-phy";
> + #phy-cells = <2>;
> + reg = <0xfe382000 0x100>,
> + <0xfe38a000 0x100>,
> + <0xfe394000 0x100>,
> + <0xfe804000 0x100>;
> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> + st,syscfg= <&syscfg_rear>;
Nit: missing space before '='.
> + };
> +
> +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>;
> + ...
> + };
Is there not a generic phy binding we can point to? It seems a bit
redundant to do this in each phy binding.
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-03-05 7:34 ` Mark Rutland
0 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-03-05 7:34 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree, Srinivas Kandagatla, linux-kernel, linux-arm-kernel,
alexandre.torgue
On Fri, Feb 14, 2014 at 11:23:53AM +0000, 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: devicetree@vger.kernel.org
> Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
> 1 file changed, 54 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..96f269f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,54 @@
> +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; MIPHY_PORT_{0,1}
> + Second cell is device type; MIPHY_TYPE_{SATA,PCI}
Either this should refer to the header file, or specific values should
be given in the binding document.
> +- reg: Address and length of the register set for the device
> +- reg-names: The names of the register addresses corresponding to the
> + registers filled in "reg"
> + Options are; sata{0,1} and pcie{0,1} (See first example)
How about something like:
- reg: a list of offset + length pairs, one for each entry in reg-names
- reg-names: should contain some of:
* "sata0" for ...
* "sata1" for ...
* "pcie0" for ...
* "pcie1" for ...
Where ... might just be "the sata port 0 registers"
> +- st,syscfg : Should be a phandle of the system configuration register group
> + which contain the SATA, PCIe mode setting bits
I'll assume this is well-defined by some other binding.
> +
> +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)
It might just be me, but the phrase "invert the polarity {SATA,PCIe} Tx"
sounds odd. What exactly is being inverted?
> +
> +Example:
> +
> + miphy365x_phy: miphy365x@0 {
> + compatible = "st,miphy365x-phy";
> + #phy-cells = <2>;
> + reg = <0xfe382000 0x100>,
> + <0xfe38a000 0x100>,
> + <0xfe394000 0x100>,
> + <0xfe804000 0x100>;
> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> + st,syscfg= <&syscfg_rear>;
Nit: missing space before '='.
> + };
> +
> +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>;
> + ...
> + };
Is there not a generic phy binding we can point to? It seems a bit
redundant to do this in each phy binding.
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-03-05 7:34 ` Mark Rutland
0 siblings, 0 replies; 69+ messages in thread
From: Mark Rutland @ 2014-03-05 7:34 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 14, 2014 at 11:23:53AM +0000, 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: devicetree at vger.kernel.org
> Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
> 1 file changed, 54 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..96f269f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,54 @@
> +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; MIPHY_PORT_{0,1}
> + Second cell is device type; MIPHY_TYPE_{SATA,PCI}
Either this should refer to the header file, or specific values should
be given in the binding document.
> +- reg: Address and length of the register set for the device
> +- reg-names: The names of the register addresses corresponding to the
> + registers filled in "reg"
> + Options are; sata{0,1} and pcie{0,1} (See first example)
How about something like:
- reg: a list of offset + length pairs, one for each entry in reg-names
- reg-names: should contain some of:
* "sata0" for ...
* "sata1" for ...
* "pcie0" for ...
* "pcie1" for ...
Where ... might just be "the sata port 0 registers"
> +- st,syscfg : Should be a phandle of the system configuration register group
> + which contain the SATA, PCIe mode setting bits
I'll assume this is well-defined by some other binding.
> +
> +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)
It might just be me, but the phrase "invert the polarity {SATA,PCIe} Tx"
sounds odd. What exactly is being inverted?
> +
> +Example:
> +
> + miphy365x_phy: miphy365x at 0 {
> + compatible = "st,miphy365x-phy";
> + #phy-cells = <2>;
> + reg = <0xfe382000 0x100>,
> + <0xfe38a000 0x100>,
> + <0xfe394000 0x100>,
> + <0xfe804000 0x100>;
> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> + st,syscfg= <&syscfg_rear>;
Nit: missing space before '='.
> + };
> +
> +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 at fe380000 {
> + ...
> + phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
> + ...
> + };
Is there not a generic phy binding we can point to? It seems a bit
redundant to do this in each phy binding.
Cheers,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-14 11:23 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-14 11:23 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla
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: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
1 file changed, 54 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..96f269f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,54 @@
+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; MIPHY_PORT_{0,1}
+ Second cell is device type; MIPHY_TYPE_{SATA,PCI}
+- reg: Address and length of the register set for the device
+- reg-names: The names of the register addresses corresponding to the
+ registers filled in "reg"
+ Options are; sata{0,1} and pcie{0,1} (See first example)
+- 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)
+
+Example:
+
+ miphy365x_phy: miphy365x@0 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg= <&syscfg_rear>;
+ };
+
+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>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-14 11:23 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-14 11:23 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: alexandre.torgue-qxv4g6HH51o, Lee Jones,
devicetree-u79uwXL29TY76Z2rM5mHXA, Srinivas Kandagatla
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: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
1 file changed, 54 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..96f269f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,54 @@
+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; MIPHY_PORT_{0,1}
+ Second cell is device type; MIPHY_TYPE_{SATA,PCI}
+- reg: Address and length of the register set for the device
+- reg-names: The names of the register addresses corresponding to the
+ registers filled in "reg"
+ Options are; sata{0,1} and pcie{0,1} (See first example)
+- 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)
+
+Example:
+
+ miphy365x_phy: miphy365x@0 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg= <&syscfg_rear>;
+ };
+
+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>;
+ ...
+ };
--
1.8.3.2
--
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
^ permalink raw reply related [flat|nested] 69+ messages in thread
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
@ 2014-02-14 11:23 ` Lee Jones
0 siblings, 0 replies; 69+ messages in thread
From: Lee Jones @ 2014-02-14 11:23 UTC (permalink / raw)
To: linux-arm-kernel
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: devicetree at vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
1 file changed, 54 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..96f269f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,54 @@
+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; MIPHY_PORT_{0,1}
+ Second cell is device type; MIPHY_TYPE_{SATA,PCI}
+- reg: Address and length of the register set for the device
+- reg-names: The names of the register addresses corresponding to the
+ registers filled in "reg"
+ Options are; sata{0,1} and pcie{0,1} (See first example)
+- 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)
+
+Example:
+
+ miphy365x_phy: miphy365x at 0 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg= <&syscfg_rear>;
+ };
+
+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 at fe380000 {
+ ...
+ phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ ...
+ };
--
1.8.3.2
^ permalink raw reply related [flat|nested] 69+ messages in thread
end of thread, other threads:[~2014-06-24 14:52 UTC | newest]
Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-12 16:03 [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x Lee Jones
2014-02-12 16:03 ` Lee Jones
2014-02-12 16:03 ` [PATCH 2/4] phy: miphy365x: Add MiPHY365x header file for DT x Driver defines Lee Jones
2014-02-12 16:03 ` Lee Jones
2014-02-12 16:03 ` [PATCH 3/4] ARM: DT: STi: Add DT node for MiPHY365x Lee Jones
2014-02-12 16:03 ` Lee Jones
2014-02-12 16:03 ` [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY Lee Jones
2014-02-12 16:03 ` Lee Jones
2014-02-12 16:54 ` Mark Rutland
2014-02-12 16:54 ` Mark Rutland
2014-02-13 10:47 ` Lee Jones
2014-02-13 10:47 ` Lee Jones
2014-02-13 6:53 ` Kishon Vijay Abraham I
2014-02-13 6:53 ` Kishon Vijay Abraham I
2014-02-13 10:29 ` Lee Jones
2014-02-13 10:29 ` Lee Jones
2014-02-12 16:40 ` [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x Mark Rutland
2014-02-12 16:40 ` Mark Rutland
2014-02-12 16:40 ` Mark Rutland
2014-02-13 11:03 ` Lee Jones
2014-02-13 11:03 ` Lee Jones
2014-02-13 11:03 ` Lee Jones
2014-02-13 12:23 ` Mark Rutland
2014-02-13 12:23 ` Mark Rutland
2014-02-13 12:23 ` Mark Rutland
2014-02-14 11:23 Lee Jones
2014-02-14 11:23 ` Lee Jones
2014-02-14 11:23 ` Lee Jones
2014-03-05 7:34 ` Mark Rutland
2014-03-05 7:34 ` Mark Rutland
2014-03-05 7:34 ` Mark Rutland
2014-03-05 8:40 ` Lee Jones
2014-03-05 8:40 ` Lee Jones
2014-03-05 8:40 ` Lee Jones
2014-03-05 9:12 ` Lee Jones
2014-03-05 9:12 ` Lee Jones
2014-03-05 9:12 ` Lee Jones
2014-03-12 13:14 [PATCH 0/4] phy: Introduce support for MiPHY365x Lee Jones
2014-03-12 13:14 ` [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x Lee Jones
2014-03-12 13:14 ` Lee Jones
2014-04-29 7:21 [PATCH 0/4] phy: Introduce support for MiPHY365x Lee Jones
2014-04-29 7:21 ` [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x Lee Jones
2014-04-29 7:21 ` Lee Jones
2014-05-19 13:56 ` Lee Jones
2014-05-19 13:56 ` Lee Jones
2014-05-19 14:00 ` Kishon Vijay Abraham I
2014-05-19 14:00 ` Kishon Vijay Abraham I
2014-05-19 14:07 ` Lee Jones
2014-05-19 14:07 ` Lee Jones
2014-05-22 13:53 [RESEND 0/4] phy: Introduce support for MiPHY365x Lee Jones
2014-05-22 13:53 ` [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x Lee Jones
2014-05-22 13:53 ` Lee Jones
2014-06-10 11:00 ` Kishon Vijay Abraham I
2014-06-10 11:00 ` Kishon Vijay Abraham I
2014-06-17 11:23 ` Lee Jones
2014-06-17 11:23 ` Lee Jones
2014-06-18 9:50 ` Kishon Vijay Abraham I
2014-06-18 9:50 ` Kishon Vijay Abraham I
2014-06-18 9:50 ` Kishon Vijay Abraham I
2014-06-18 10:04 ` Lee Jones
2014-06-18 10:04 ` Lee Jones
2014-06-24 9:38 ` Arnd Bergmann
2014-06-24 9:38 ` Arnd Bergmann
2014-06-24 9:38 ` Arnd Bergmann
2014-06-24 12:46 ` Lee Jones
2014-06-24 12:46 ` Lee Jones
2014-06-24 14:08 ` Arnd Bergmann
2014-06-24 14:08 ` Arnd Bergmann
2014-06-24 14:08 ` Arnd Bergmann
2014-06-24 14:51 ` Lee Jones
2014-06-24 14:51 ` Lee Jones
2014-06-24 14:51 ` Lee Jones
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.