Hi Kishon,
This patchset is based on the two core patches you sent to the
list which facilitate creating PHYs residing on multi-channel
controllers. The changes since the last submission centre
around dynamic PHY creation based solely on what is provided via
Device Tree, as requested. The other review comments have also
been addressed in this set.
Kind regards,
Lee
.../devicetree/bindings/phy/phy-miphy365x.txt | 76 +++
arch/arm/boot/dts/stih416-b2020-revE.dts | 10 +
arch/arm/boot/dts/stih416-b2020.dts | 12 +
arch/arm/boot/dts/stih416.dtsi | 22 +
drivers/phy/Kconfig | 10 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-miphy365x.c | 636 +++++++++++++++++++++
include/dt-bindings/phy/phy-miphy365x.h | 14 +
8 files changed, 781 insertions(+)
This provides the shared header file which will be reference from both
the MiPHY365x driver and its associated Device Tree node(s).
Cc: Kishon Vijay Abraham I <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Acked-by: Alexandre Torgue <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
include/dt-bindings/phy/phy-miphy365x.h | 14 ++++++++++++++
1 file changed, 14 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..8ef8aba
--- /dev/null
+++ b/include/dt-bindings/phy/phy-miphy365x.h
@@ -0,0 +1,14 @@
+/*
+ * This header provides constants for the phy framework
+ * based on the STMicroelectronics MiPHY365x.
+ *
+ * Author: Lee Jones <[email protected]>
+ */
+#ifndef _DT_BINDINGS_PHY_MIPHY
+#define _DT_BINDINGS_PHY_MIPHY
+
+#define MIPHY_TYPE_SATA 1
+#define MIPHY_TYPE_PCIE 2
+#define MIPHY_TYPE_USB 3
+
+#endif /* _DT_BINDINGS_PHY_MIPHY */
--
1.8.3.2
This has the added advantages of being able to enable/disable each
of the channels as simply as enabling/disabling the DT node.
Suggested-by: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
drivers/phy/phy-miphy365x.c | 256 ++++++++++++++++++++++++--------------------
1 file changed, 138 insertions(+), 118 deletions(-)
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
index 65ecd04..e111baf 100644
--- a/drivers/phy/phy-miphy365x.c
+++ b/drivers/phy/phy-miphy365x.c
@@ -18,6 +18,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_platform.h>
+#include <linux/of_address.h>
#include <linux/clk.h>
#include <linux/phy/phy.h>
#include <linux/delay.h>
@@ -28,10 +29,8 @@
#define HFC_TIMEOUT 100
-#define SYSCFG_2521 0x824
-#define SYSCFG_2522 0x828
-#define SYSCFG_PCIE_SATA_MASK BIT(1)
-#define SYSCFG_PCIE_SATA_POS 1
+#define SYSCFG_SELECT_SATA_MASK BIT(1)
+#define SYSCFG_SELECT_SATA_POS 1
/* MiPHY365x register definitions */
#define RESET_REG 0x00
@@ -136,25 +135,21 @@
#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;
+ bool pcie_tx_pol_inv;
+ bool sata_tx_pol_inv;
+ u32 sata_gen;
+ u64 ctrlreg;
u8 type;
- u8 port;
};
struct miphy365x_dev {
struct device *dev;
struct regmap *regmap;
struct mutex miphy_mutex;
- struct miphy365x phys[ARRAY_SIZE(ports)];
- bool pcie_tx_pol_inv;
- bool sata_tx_pol_inv;
- u32 sata_gen;
+ struct miphy365x_phy **phys;
};
/*
@@ -180,27 +175,12 @@ static u8 rx_tx_spd[] = {
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;
- }
+ bool sata = (miphy_phy->type == MIPHY_TYPE_SATA);
- return regmap_update_bits(miphy_dev->regmap, reg, mask,
- sata << SYSCFG_PCIE_SATA_POS);
+ return regmap_update_bits(miphy_dev->regmap,
+ (unsigned int)miphy_phy->ctrlreg,
+ SYSCFG_SELECT_SATA_MASK,
+ sata << SYSCFG_SELECT_SATA_POS);
}
static int miphy365x_init_pcie_port(struct miphy365x_phy *miphy_phy,
@@ -261,14 +241,14 @@ static inline void miphy365x_set_comp(struct miphy365x_phy *miphy_phy,
{
u8 val, mask;
- if (miphy_dev->sata_gen == SATA_GEN1)
+ if (miphy_phy->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) {
+ if (miphy_phy->sata_gen != SATA_GEN3) {
writeb_relaxed(COMSR_COMP_REF,
miphy_phy->base + COMP_CTRL3_REG);
/*
@@ -312,7 +292,7 @@ static inline void miphy365x_set_ssc(struct miphy365x_phy *miphy_phy,
miphy_phy->base + PLL_SSC_PER_LSB_REG);
/* SSC Settings complete */
- if (miphy_dev->sata_gen == SATA_GEN1) {
+ if (miphy_phy->sata_gen == SATA_GEN1) {
val = PLL_START_CAL | BUF_EN | SYNCHRO_TX | CONFIG_PLL;
writeb_relaxed(val, miphy_phy->base + PLL_CTRL1_REG);
} else {
@@ -334,7 +314,7 @@ static int miphy365x_init_sata_port(struct miphy365x_phy *miphy_phy,
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)
+ if (miphy_phy->sata_tx_pol_inv)
writeb_relaxed(TX_POL, miphy_phy->base + CTRL_REG);
/*
@@ -344,7 +324,7 @@ static int miphy365x_init_sata_port(struct miphy365x_phy *miphy_phy,
*/
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];
+ val = rx_tx_spd[miphy_phy->sata_gen];
writeb_relaxed(val, miphy_phy->base + BOUNDARY3_REG);
/* Wait for HFC_READY = 0 */
@@ -355,7 +335,7 @@ static int miphy365x_init_sata_port(struct miphy365x_phy *miphy_phy,
/* Compensation Recalibration */
miphy365x_set_comp(miphy_phy, miphy_dev);
- switch (miphy_dev->sata_gen) {
+ switch (miphy_phy->sata_gen) {
case SATA_GEN3:
/*
* TX Swing target 550-600mv peak to peak diff
@@ -423,7 +403,7 @@ static int miphy365x_init_sata_port(struct miphy365x_phy *miphy_phy,
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 ?
+ val = miphy_phy->sata_tx_pol_inv ?
(TX_POL | DES_BIT_LOCK_EN) : DES_BIT_LOCK_EN;
writeb_relaxed(val, miphy_phy->base + CTRL_REG);
@@ -459,40 +439,95 @@ static int miphy365x_init(struct phy *phy)
return ret;
}
+int miphy365x_get_addr(struct device *dev, struct miphy365x_phy *miphy_phy,
+ int index)
+{
+ struct device_node *phynode = miphy_phy->phy->dev.of_node;
+ const char *name;
+ const __be32 *taddr;
+ int type = miphy_phy->type;
+ int ret;
+
+ ret = of_property_read_string_index(phynode, "reg-names", index, &name);
+ if (ret) {
+ dev_err(dev, "no reg-names property not found\n");
+ return ret;
+ }
+
+ if (!strncmp(name, "syscfg", 6)) {
+ taddr = of_get_address(phynode, index, NULL, NULL);
+ if (!taddr) {
+ dev_err(dev, "failed to fetch syscfg address\n");
+ return -EINVAL;
+ }
+
+ miphy_phy->ctrlreg = of_translate_address(phynode, taddr);
+ if (miphy_phy->ctrlreg == OF_BAD_ADDR) {
+ dev_err(dev, "failed to translate syscfg address\n");
+ return -EINVAL;
+ }
+
+ return 0;
+ }
+
+ if (!((!strncmp(name, "sata", 4) && type == MIPHY_TYPE_SATA) ||
+ (!strncmp(name, "pcie", 4) && type == MIPHY_TYPE_PCIE)))
+ return 0;
+
+ miphy_phy->base = of_iomap(phynode, index);
+ if (!miphy_phy->base) {
+ dev_err(dev, "Failed to map %s\n", phynode->full_name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static struct phy *miphy365x_xlate(struct device *dev,
struct of_phandle_args *args)
{
- struct miphy365x_dev *state = dev_get_drvdata(dev);
- u8 port, type;
+ struct miphy365x_dev *miphy_dev = dev_get_drvdata(dev);
+ struct miphy365x_phy *miphy_phy = NULL;
+ struct device_node *phynode = args->np;
+ int ret, index;
+
+ if (!of_device_is_available(phynode)) {
+ dev_warn(dev, "Requested PHY is disabled\n");
+ return ERR_PTR(-ENODEV);
+ }
- if (args->count != 2) {
+ if (args->args_count != 1) {
dev_err(dev, "Invalid number of cells in 'phy' property\n");
return ERR_PTR(-EINVAL);
}
- if (args->args[0] & 0xFFFFFF00 || args->args[1] & 0xFFFFFF00) {
- dev_err(dev, "Unsupported flags set in 'phy' property\n");
+ for (index = 0; index < of_get_child_count(dev->of_node); index++)
+ if (phynode == miphy_dev->phys[index]->phy->dev.of_node) {
+ miphy_phy = miphy_dev->phys[index];
+ break;
+ }
+
+ if (!miphy_phy) {
+ dev_err(dev, "Failed to find appropriate phy\n");
return ERR_PTR(-EINVAL);
}
- port = args->args[0];
- type = args->args[1];
-
- if (WARN_ON(port >= ARRAY_SIZE(ports)))
- return ERR_PTR(-EINVAL);
+ miphy_phy->type = args->args[0];
- 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");
+ if (!(miphy_phy->type == MIPHY_TYPE_SATA ||
+ miphy_phy->type == MIPHY_TYPE_PCIE)) {
+ dev_err(dev, "Unsupported device type: %d\n", miphy_phy->type);
return ERR_PTR(-EINVAL);
}
- state->phys[port].type = type;
+ /* Each port handles SATA and PCIE - third entry is always sysconf. */
+ for (index = 0; index < 3; index++) {
+ ret = miphy365x_get_addr(dev, miphy_phy, index);
+ if (ret < 0)
+ return ERR_PTR(ret);
+ }
- return state->phys[port].phy;
+ return miphy_phy->phy;
}
static struct phy_ops miphy365x_ops = {
@@ -500,95 +535,80 @@ static struct phy_ops miphy365x_ops = {
.owner = THIS_MODULE,
};
-static int miphy365x_get_base_addr(struct platform_device *pdev,
- struct miphy365x_phy *phy, u8 port)
+static int miphy365x_of_probe(struct device_node *phynode,
+ struct miphy365x_phy *miphy_phy)
{
- struct resource *res;
- char type[6];
+ of_property_read_u32(phynode, "st,sata-gen", &miphy_phy->sata_gen);
+ if (!miphy_phy->sata_gen)
+ miphy_phy->sata_gen = SATA_GEN1;
- sprintf(type, "sata%d", port);
+ miphy_phy->pcie_tx_pol_inv =
+ of_property_read_bool(phynode, "st,pcie-tx-pol-inv");
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, type);
- phy->sata = devm_ioremap_resource(&pdev->dev, res));
- if (!phy->sata)
- return -ENOMEM;
-
- sprintf(type, "pcie%d", port);
-
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, type);
- phy->pcie = devm_ioremap_resource(&pdev->dev, res));
- if (!phy->pcie)
- return -ENOMEM;
-
- return 0;
-}
-
-static int miphy365x_of_probe(struct device_node *np,
- struct miphy365x_dev *phy_dev)
-{
- 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);
- }
-
- of_property_read_u32(np, "st,sata-gen", &phy_dev->sata_gen);
- if (!phy_dev->sata_gen)
- phy_dev->sata_gen = SATA_GEN1;
-
- 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");
+ miphy_phy->sata_tx_pol_inv =
+ of_property_read_bool(phynode, "st,sata-tx-pol-inv");
return 0;
}
static int miphy365x_probe(struct platform_device *pdev)
{
- struct device_node *np = pdev->dev.of_node;
- struct miphy365x_dev *phy_dev;
- struct device *dev = &pdev->dev;
+ struct device_node *child, *np = pdev->dev.of_node;
+ struct miphy365x_dev *miphy_dev;
struct phy_provider *provider;
- u8 port;
+ struct phy *phy;
+ int chancount, port = 0;
int ret;
- phy_dev = devm_kzalloc(dev, sizeof(*phy_dev), GFP_KERNEL);
- if (!phy_dev)
+ miphy_dev = devm_kzalloc(&pdev->dev, sizeof(*miphy_dev), GFP_KERNEL);
+ if (!miphy_dev)
return -ENOMEM;
- ret = miphy365x_of_probe(np, phy_dev);
- if (ret)
- return ret;
+ chancount = of_get_child_count(np);
+ miphy_dev->phys = devm_kzalloc(&pdev->dev, sizeof(phy) * chancount,
+ GFP_KERNEL);
+ if (!miphy_dev->phys)
+ return -ENOMEM;
+
+ miphy_dev->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+ if (IS_ERR(miphy_dev->regmap)) {
+ dev_err(miphy_dev->dev, "No syscfg phandle specified\n");
+ return PTR_ERR(miphy_dev->regmap);
+ }
+
+ miphy_dev->dev = &pdev->dev;
+
+ dev_set_drvdata(&pdev->dev, miphy_dev);
- phy_dev->dev = dev;
+ mutex_init(&miphy_dev->miphy_mutex);
- dev_set_drvdata(dev, phy_dev);
+ for_each_child_of_node(np, child) {
+ struct miphy365x_phy *miphy_phy;
- mutex_init(&phy_dev->miphy_mutex);
+ miphy_phy = devm_kzalloc(&pdev->dev, sizeof(*miphy_phy),
+ GFP_KERNEL);
+ if (!miphy_phy)
+ return -ENOMEM;
- for (port = 0; port < ARRAY_SIZE(ports); port++) {
- struct phy *phy;
+ miphy_dev->phys[port] = miphy_phy;
- phy = devm_phy_create(dev, &miphy365x_ops, NULL);
+ phy = devm_phy_create(&pdev->dev, child, &miphy365x_ops, NULL);
if (IS_ERR(phy)) {
- dev_err(dev, "failed to create PHY on port %d\n", port);
+ dev_err(&pdev->dev, "failed to create PHY\n");
return PTR_ERR(phy);
}
- phy_dev->phys[port].phy = phy;
- phy_dev->phys[port].port = port;
+ miphy_dev->phys[port]->phy = phy;
- ret = miphy365x_get_base_addr(pdev,
- &phy_dev->phys[port], port);
+ ret = miphy365x_of_probe(child, miphy_phy);
if (ret)
return ret;
- phy_set_drvdata(phy, &phy_dev->phys[port]);
+ phy_set_drvdata(phy, miphy_dev->phys[port]);
+ port++;
}
- provider = devm_of_phy_provider_register(dev, miphy365x_xlate);
+ provider = devm_of_phy_provider_register(&pdev->dev, miphy365x_xlate);
if (IS_ERR(provider))
return PTR_ERR(provider);
--
1.8.3.2
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.
Acked-by: Mark Rutland <[email protected]>
Acked-by: Alexandre Torgue <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/stih416-b2020-revE.dts | 10 ++++++++++
arch/arm/boot/dts/stih416-b2020.dts | 12 ++++++++++++
arch/arm/boot/dts/stih416.dtsi | 22 ++++++++++++++++++++++
3 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts b/arch/arm/boot/dts/stih416-b2020-revE.dts
index ba0fa2c..80aff0f 100644
--- a/arch/arm/boot/dts/stih416-b2020-revE.dts
+++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
@@ -31,5 +31,15 @@
ethernet1: dwmac@fef08000 {
snps,reset-gpio = <&PIO0 7>;
};
+
+ miphy365x_phy: miphy365x@fe382000 {
+ phy_port0: port@fe382000 {
+ st,sata-gen = <3>;
+ };
+
+ phy_port1: port@fe38a000 {
+ st,pcie-tx-pol-inv;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
index 4e2df66..c3c2ac6 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -12,4 +12,16 @@
/ {
model = "STiH416 B2020";
compatible = "st,stih416-b2020", "st,stih416";
+
+ soc {
+ miphy365x_phy: miphy365x@fe382000 {
+ phy_port0: port@fe382000 {
+ st,sata-gen = <3>;
+ };
+
+ phy_port1: port@fe38a000 {
+ st,pcie-tx-pol-inv;
+ };
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 06473c5..e62fdd3 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>
/ {
@@ -236,5 +238,25 @@
resets = <&powerdown STIH416_KEYSCAN_POWERDOWN>,
<&softreset STIH416_KEYSCAN_SOFTRESET>;
};
+
+ miphy365x_phy: miphy365x@fe382000 {
+ compatible = "st,miphy365x-phy";
+ st,syscfg = <&syscfg_rear>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ phy_port0: port@fe382000 {
+ #phy-cells = <1>;
+ reg = <0xfe382000 0x100>, <0xfe394000 0x100>, <0x824 0x4>;
+ reg-names = "sata", "pcie", "syscfg";
+ };
+
+ phy_port1: port@fe38a000 {
+ #phy-cells = <1>;
+ reg = <0xfe38a000 0x100>, <0xfe804000 0x100>, <0x828 0x4>;
+ reg-names = "sata", "pcie", "syscfg";
+ };
+ };
};
};
--
1.8.3.2
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.
Acked-by: Mark Rutland <[email protected]>
Signed-off-by: Alexandre Torgue <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
drivers/phy/Kconfig | 10 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-miphy365x.c | 616 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 627 insertions(+)
create mode 100644 drivers/phy/phy-miphy365x.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 16a2f06..5d54dcf 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -31,6 +31,16 @@ config PHY_MVEBU_SATA
depends on OF
select GENERIC_PHY
+config PHY_MIPHY365X
+ tristate "STMicroelectronics MIPHY365X PHY driver for STiH41x series"
+ depends on ARCH_STI
+ depends on GENERIC_PHY
+ depends on HAS_IOMEM
+ depends on OF
+ help
+ Enable this to support the miphy transceiver (for SATA/PCIE)
+ that is part of STMicroelectronics STiH41x SoC series.
+
config OMAP_CONTROL_PHY
tristate "OMAP CONTROL PHY Driver"
depends on ARCH_OMAP2PLUS || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index b4f1d57..4602f67 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.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_MVEBU_SATA) += phy-mvebu-sata.o
+obj-$(CONFIG_PHY_MIPHY365X) += phy-miphy365x.o
obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
new file mode 100644
index 0000000..65ecd04
--- /dev/null
+++ b/drivers/phy/phy-miphy365x.c
@@ -0,0 +1,616 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics – All Rights Reserved
+ *
+ * STMicroelectronics PHY driver MiPHY365 (for SoC STiH416).
+ *
+ * Authors: Alexandre Torgue <[email protected]>
+ * Lee Jones <[email protected]>
+ *
+ * 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 100
+
+#define SYSCFG_2521 0x824
+#define SYSCFG_2522 0x828
+#define SYSCFG_PCIE_SATA_MASK BIT(1)
+#define SYSCFG_PCIE_SATA_POS 1
+
+/* MiPHY365x register definitions */
+#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 COMSR_DONE BIT(2)
+#define COMZC_DONE BIT(3)
+#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 regmap *regmap;
+ struct mutex miphy_mutex;
+ struct miphy365x phys[ARRAY_SIZE(ports)];
+ bool pcie_tx_pol_inv;
+ bool sata_tx_pol_inv;
+ u32 sata_gen;
+};
+
+/*
+ * These values are represented in Device tree. They are considered to be ABI
+ * and although they can be extended any existing values must not change.
+ */
+enum miphy_sata_gen {
+ SATA_GEN1 = 1,
+ 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
+};
+
+/*
+ * 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 int miphy365x_init_pcie_port(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ u8 val;
+
+ if (miphy_phy->pcie_tx_pol_inv) {
+ /* 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);
+ }
+
+ return 0;
+}
+
+static inline int miphy365x_hfc_not_rdy(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(HFC_TIMEOUT);
+ u8 mask = IDLL_RDY | PLL_RDY;
+ u8 regval;
+
+ do {
+ regval = readb_relaxed(miphy_phy->base + STATUS_REG);
+ if (!(regval & mask))
+ return 0;
+
+ usleep_range(2000, 2500);
+ } while (time_before(jiffies, timeout));
+
+ dev_err(miphy_dev->dev, "HFC ready timeout!\n");
+ return -EBUSY;
+}
+
+static inline int miphy365x_rdy(struct miphy365x_phy *miphy_phy,
+ struct miphy365x_dev *miphy_dev)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(HFC_TIMEOUT);
+ u8 mask = IDLL_RDY | PLL_RDY;
+ u8 regval;
+
+ do {
+ regval = readb_relaxed(miphy_phy->base + STATUS_REG);
+ if ((regval & mask) == mask)
+ return 0;
+
+ usleep_range(2000, 2500);
+ } while (time_before(jiffies, timeout));
+
+ dev_err(miphy_dev->dev, "PHY not ready timeout!\n");
+ return -EBUSY;
+}
+
+static inline void miphy365x_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 = COMSR_DONE | COMZC_DONE;
+ while ((readb_relaxed(miphy_phy->base + COMP_CTRL1_REG) & mask) != mask)
+ cpu_relax();
+}
+
+static inline void miphy365x_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_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_hfc_not_rdy(miphy_phy, miphy_dev);
+ if (ret)
+ return ret;
+
+ /* Compensation Recalibration */
+ miphy365x_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_set_ssc(miphy_phy, miphy_dev);
+
+ /* Wait for phy_ready */
+ ret = miphy365x_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_init(struct phy *phy)
+{
+ struct miphy365x_phy *miphy_phy = phy_get_drvdata(phy);
+ struct miphy365x_dev *miphy_dev = dev_get_drvdata(phy->dev.parent);
+ int ret = 0;
+
+ 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)
+ ret = miphy365x_init_pcie_port(miphy_phy, miphy_dev);
+ else
+ ret = miphy365x_init_sata_port(miphy_phy, miphy_dev);
+
+ mutex_unlock(&miphy_dev->miphy_mutex);
+
+ return ret;
+}
+
+static struct phy *miphy365x_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct miphy365x_dev *state = dev_get_drvdata(dev);
+ u8 port, type;
+
+ if (args->count != 2) {
+ dev_err(dev, "Invalid number of cells in 'phy' property\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (args->args[0] & 0xFFFFFF00 || args->args[1] & 0xFFFFFF00) {
+ dev_err(dev, "Unsupported flags set in 'phy' property\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ port = args->args[0];
+ 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_ops = {
+ .init = miphy365x_init,
+ .owner = THIS_MODULE,
+};
+
+static int miphy365x_get_base_addr(struct platform_device *pdev,
+ struct miphy365x_phy *phy, u8 port)
+{
+ struct resource *res;
+ char type[6];
+
+ sprintf(type, "sata%d", port);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, type);
+ phy->sata = devm_ioremap_resource(&pdev->dev, res));
+ if (!phy->sata)
+ return -ENOMEM;
+
+ sprintf(type, "pcie%d", port);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, type);
+ phy->pcie = devm_ioremap_resource(&pdev->dev, res));
+ if (!phy->pcie)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int miphy365x_of_probe(struct device_node *np,
+ struct miphy365x_dev *phy_dev)
+{
+ 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);
+ }
+
+ of_property_read_u32(np, "st,sata-gen", &phy_dev->sata_gen);
+ if (!phy_dev->sata_gen)
+ phy_dev->sata_gen = SATA_GEN1;
+
+ 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_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;
+
+ phy_dev = devm_kzalloc(dev, sizeof(*phy_dev), GFP_KERNEL);
+ if (!phy_dev)
+ return -ENOMEM;
+
+ ret = miphy365x_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);
+
+ for (port = 0; port < ARRAY_SIZE(ports); port++) {
+ struct phy *phy;
+
+ phy = devm_phy_create(dev, &miphy365x_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_get_base_addr(pdev,
+ &phy_dev->phys[port], port);
+ if (ret)
+ return ret;
+
+ phy_set_drvdata(phy, &phy_dev->phys[port]);
+ }
+
+ provider = devm_of_phy_provider_register(dev, miphy365x_xlate);
+ if (IS_ERR(provider))
+ return PTR_ERR(provider);
+
+ return 0;
+}
+
+static const struct of_device_id miphy365x_of_match[] = {
+ { .compatible = "st,miphy365x-phy", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, miphy365x_of_match);
+
+static struct platform_driver miphy365x_driver = {
+ .probe = miphy365x_probe,
+ .driver = {
+ .name = "miphy365x-phy",
+ .owner = THIS_MODULE,
+ .of_match_table = miphy365x_of_match,
+ }
+};
+module_platform_driver(miphy365x_driver);
+
+MODULE_AUTHOR("Alexandre Torgue <[email protected]>");
+MODULE_DESCRIPTION("STMicroelectronics miphy365x driver");
+MODULE_LICENSE("GPL v2");
--
1.8.3.2
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 <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Acked-by: Alexandre Torgue <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 76 ++++++++++++++++++++++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
new file mode 100644
index 0000000..7337ac2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,76 @@
+STMicroelectronics STi MIPHY365x PHY binding
+============================================
+
+This binding describes a miphy device that is used to control PHY hardware
+for SATA and PCIe.
+
+Required properties (controller (parent) node):
+- compatible : Should be "st,miphy365x-phy"
+- st,syscfg : Should be a phandle of the system configuration register group
+ which contain the SATA, PCIe mode setting bits
+
+Required nodes : A sub-node is required for each channel the controller
+ provides. Address range information including the usual
+ 'reg' and 'reg-names' properties are used inside these
+ nodes to describe the controller's topology. These nodes
+ are translated by the driver's .xlate() function.
+
+Required properties (port (child) node):
+- #phy-cells : Should be 1 (See second example)
+ Cell after port phandle 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":
+ - sata: For SATA devices
+ - pcie: For PCIe devices
+ - syscfg: To specify the syscfg based config register
+
+Optional properties (port (child) node):
+- 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";
+ st,syscfg = <&syscfg_rear>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ phy_port0: port@fe382000 {
+ reg = <0xfe382000 0x100>, <0xfe394000 0x100>, <0x824 0x4>;
+ reg-names = "sata", "pcie", "syscfg";
+ #phy-cells = <1>;
+ st,sata-gen = <3>;
+ };
+
+ phy_port1: port@fe38a000 {
+ reg = <0xfe38a000 0x100>, <0xfe804000 0x100>, <0x828 0x4>;;
+ reg-names = "sata", "pcie", "syscfg";
+ #phy-cells = <1>;
+ st,pcie-tx-pol-inv;
+ };
+ };
+
+Specifying phy control of devices
+=================================
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type.
+
+Example:
+
+#include <dt-bindings/phy/phy-miphy365x.h>
+
+ sata0: sata@fe380000 {
+ ...
+ phys = <&miphy365x_phy MIPHY_TYPE_SATA>;
+ ...
+ };
--
1.8.3.2
Hi Lee
One question below,
On 9 July 2014 13:41, Lee Jones <[email protected]> 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 <[email protected]>
> Acked-by: Mark Rutland <[email protected]>
> Acked-by: Alexandre Torgue <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> new file mode 100644
> index 0000000..7337ac2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,76 @@
> +STMicroelectronics STi MIPHY365x PHY binding
> +============================================
> +
> +This binding describes a miphy device that is used to control PHY hardware
> +for SATA and PCIe.
> +
> +Required properties (controller (parent) node):
> +- compatible : Should be "st,miphy365x-phy"
> +- st,syscfg : Should be a phandle of the system configuration register group
> + which contain the SATA, PCIe mode setting bits
> +
> +Required nodes : A sub-node is required for each channel the controller
> + provides. Address range information including the usual
> + 'reg' and 'reg-names' properties are used inside these
> + nodes to describe the controller's topology. These nodes
> + are translated by the driver's .xlate() function.
> +
> +Required properties (port (child) node):
> +- #phy-cells : Should be 1 (See second example)
> + Cell after port phandle 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":
> + - sata: For SATA devices
> + - pcie: For PCIe devices
> + - syscfg: To specify the syscfg based config register
> +
> +Optional properties (port (child) node):
> +- 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";
> + st,syscfg = <&syscfg_rear>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + phy_port0: port@fe382000 {
> + reg = <0xfe382000 0x100>, <0xfe394000 0x100>, <0x824 0x4>;
> + reg-names = "sata", "pcie", "syscfg";
> + #phy-cells = <1>;
> + st,sata-gen = <3>;
> + };
> +
> + phy_port1: port@fe38a000 {
> + reg = <0xfe38a000 0x100>, <0xfe804000 0x100>, <0x828 0x4>;;
> + reg-names = "sata", "pcie", "syscfg";
> + #phy-cells = <1>;
> + st,pcie-tx-pol-inv;
> + };
> + };
> +
> +Specifying phy control of devices
> +=================================
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy port node and a device type.
> +
> +Example:
> +
> +#include <dt-bindings/phy/phy-miphy365x.h>
> +
> + sata0: sata@fe380000 {
> + ...
> + phys = <&miphy365x_phy MIPHY_TYPE_SATA>;
> + ...
In this example you select the type (SATA) but I don't understand how
do you select
the port (phy_port0 or phy_port1)
BR
Gabriel
> + };
> --
> 1.8.3.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Lee,
On Wednesday 09 July 2014 05:11 PM, Lee Jones wrote:
> Hi Kishon,
>
> This patchset is based on the two core patches you sent to the
> list which facilitate creating PHYs residing on multi-channel
> controllers. The changes since the last submission centre
> around dynamic PHY creation based solely on what is provided via
> Device Tree, as requested. The other review comments have also
> been addressed in this set.
This series looks good to me. Will queue it next week.
Thanks
Kishon
>
> Kind regards,
> Lee
>
> .../devicetree/bindings/phy/phy-miphy365x.txt | 76 +++
> arch/arm/boot/dts/stih416-b2020-revE.dts | 10 +
> arch/arm/boot/dts/stih416-b2020.dts | 12 +
> arch/arm/boot/dts/stih416.dtsi | 22 +
> drivers/phy/Kconfig | 10 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-miphy365x.c | 636 +++++++++++++++++++++
> include/dt-bindings/phy/phy-miphy365x.h | 14 +
> 8 files changed, 781 insertions(+)
>
On Wed, 09 Jul 2014, Gabriel Fernandez wrote:
> On 9 July 2014 13:41, Lee Jones <[email protected]> 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 <[email protected]>
> > Acked-by: Mark Rutland <[email protected]>
> > Acked-by: Alexandre Torgue <[email protected]>
> > Signed-off-by: Lee Jones <[email protected]>
> > ---
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 76 ++++++++++++++++++++++
> > 1 file changed, 76 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
[...]
> > +Specifying phy control of devices
> > +=================================
> > +
> > +Device nodes should specify the configuration required in their "phys"
> > +property, containing a phandle to the phy port node and a device type.
> > +
> > +Example:
> > +
> > +#include <dt-bindings/phy/phy-miphy365x.h>
> > +
> > + sata0: sata@fe380000 {
> > + ...
> > + phys = <&miphy365x_phy MIPHY_TYPE_SATA>;
> > + ...
>
> In this example you select the type (SATA) but I don't understand how
> do you select
> the port (phy_port0 or phy_port1)
Right, historical typo. Will send a v+1 as a reply, so it's easy for
Kishon to collect when he applies next week.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
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.
Acked-by: Mark Rutland <[email protected]>
Acked-by: Alexandre Torgue <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
new file mode 100644
index 0000000..42c88088
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,76 @@
+STMicroelectronics STi MIPHY365x PHY binding
+============================================
+
+This binding describes a miphy device that is used to control PHY hardware
+for SATA and PCIe.
+
+Required properties (controller (parent) node):
+- compatible : Should be "st,miphy365x-phy"
+- st,syscfg : Should be a phandle of the system configuration register group
+ which contain the SATA, PCIe mode setting bits
+
+Required nodes : A sub-node is required for each channel the controller
+ provides. Address range information including the usual
+ 'reg' and 'reg-names' properties are used inside these
+ nodes to describe the controller's topology. These nodes
+ are translated by the driver's .xlate() function.
+
+Required properties (port (child) node):
+- #phy-cells : Should be 1 (See second example)
+ Cell after port phandle 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":
+ - sata: For SATA devices
+ - pcie: For PCIe devices
+ - syscfg: To specify the syscfg based config register
+
+Optional properties (port (child) node):
+- 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";
+ st,syscfg = <&syscfg_rear>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ phy_port0: port@fe382000 {
+ reg = <0xfe382000 0x100>, <0xfe394000 0x100>, <0x824 0x4>;
+ reg-names = "sata", "pcie", "syscfg";
+ #phy-cells = <1>;
+ st,sata-gen = <3>;
+ };
+
+ phy_port1: port@fe38a000 {
+ reg = <0xfe38a000 0x100>, <0xfe804000 0x100>, <0x828 0x4>;;
+ reg-names = "sata", "pcie", "syscfg";
+ #phy-cells = <1>;
+ st,pcie-tx-pol-inv;
+ };
+ };
+
+Specifying phy control of devices
+=================================
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type.
+
+Example:
+
+#include <dt-bindings/phy/phy-miphy365x.h>
+
+ sata0: sata@fe380000 {
+ ...
+ phys = <&phy_port0 MIPHY_TYPE_SATA>;
+ ...
+ };
Hi Lee / Kishon,
One small point, patch 5 which adds the DT nodes may not apply as the file got
renamed from stih416-b2020-revE.dts to stih416-b2020e.dts.
Apart from that, for the series:
Acked-by: Peter Griffin <[email protected]>
regards,
Peter.
Hi Lee
One suggestion
On 9 July 2014 13:41, Lee Jones <[email protected]> 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.
>
> Acked-by: Mark Rutland <[email protected]>
> Signed-off-by: Alexandre Torgue <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> ---
> drivers/phy/Kconfig | 10 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-miphy365x.c | 616 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 627 insertions(+)
> create mode 100644 drivers/phy/phy-miphy365x.c
>
[...]
> diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
> new file mode 100644
> index 0000000..65ecd04
> --- /dev/null
> +++ b/drivers/phy/phy-miphy365x.c
> @@ -0,0 +1,616 @@
[...]
> +
> +struct miphy365x_phy {
> + struct phy *phy;
> + void __iomem *base;
> + void __iomem *sata;
> + void __iomem *pcie;
> + u8 type;
> + u8 port;
if we add:
struct miphy365x_dev *phydev;
it's could simplified call of procedures below ?
for e.g.
static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
struct miphy365x_dev *miphy_dev)
into
static int miphy365x_set_path(struct miphy365x_phy *miphy_phy)
{
struct miphy365x_dev *miphy_dev=miphy_phy->phydev;
[...]
Best regards
Gabriel
Hi Lee
On 9 July 2014 13:41, Lee Jones <[email protected]> wrote:
> This provides the shared header file which will be reference from both
> the MiPHY365x driver and its associated Device Tree node(s).
>
> Cc: Kishon Vijay Abraham I <[email protected]>
> Acked-by: Mark Rutland <[email protected]>
> Acked-by: Alexandre Torgue <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> ---
> include/dt-bindings/phy/phy-miphy365x.h | 14 ++++++++++++++
> 1 file changed, 14 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..8ef8aba
> --- /dev/null
> +++ b/include/dt-bindings/phy/phy-miphy365x.h
> @@ -0,0 +1,14 @@
> +/*
> + * This header provides constants for the phy framework
> + * based on the STMicroelectronics MiPHY365x.
> + *
> + * Author: Lee Jones <[email protected]>
> + */
> +#ifndef _DT_BINDINGS_PHY_MIPHY
> +#define _DT_BINDINGS_PHY_MIPHY
> +
> +#define MIPHY_TYPE_SATA 1
why it start to 1 ? for my side i prefer 0.
BR.
Gabriel.
> +#define MIPHY_TYPE_PCIE 2
> +#define MIPHY_TYPE_USB 3
> +
> +#endif /* _DT_BINDINGS_PHY_MIPHY */
> --
> 1.8.3.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, 11 Jul 2014, Gabriel Fernandez wrote:
> Hi Lee
>
> On 9 July 2014 13:41, Lee Jones <[email protected]> wrote:
> > This provides the shared header file which will be reference from both
> > the MiPHY365x driver and its associated Device Tree node(s).
> >
> > Cc: Kishon Vijay Abraham I <[email protected]>
> > Acked-by: Mark Rutland <[email protected]>
> > Acked-by: Alexandre Torgue <[email protected]>
> > Signed-off-by: Lee Jones <[email protected]>
> > ---
> > include/dt-bindings/phy/phy-miphy365x.h | 14 ++++++++++++++
> > 1 file changed, 14 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..8ef8aba
> > --- /dev/null
> > +++ b/include/dt-bindings/phy/phy-miphy365x.h
> > @@ -0,0 +1,14 @@
> > +/*
> > + * This header provides constants for the phy framework
> > + * based on the STMicroelectronics MiPHY365x.
> > + *
> > + * Author: Lee Jones <[email protected]>
> > + */
> > +#ifndef _DT_BINDINGS_PHY_MIPHY
> > +#define _DT_BINDINGS_PHY_MIPHY
> > +
> > +#define MIPHY_TYPE_SATA 1
>
> why it start to 1 ? for my side i prefer 0.
Because 0 is a default state after using devm_kzalloc(), meaning
'unset', which would be an error.
> > +#define MIPHY_TYPE_PCIE 2
> > +#define MIPHY_TYPE_USB 3
> > +
> > +#endif /* _DT_BINDINGS_PHY_MIPHY */
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
> One small point, patch 5 which adds the DT nodes may not apply as the file got
> renamed from stih416-b2020-revE.dts to stih416-b2020e.dts.
Not required, Git should handle this seamlessly.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Lee,
On Fri, 11 Jul 2014, Lee Jones wrote:
> > One small point, patch 5 which adds the DT nodes may not apply as the file got
> > renamed from stih416-b2020-revE.dts to stih416-b2020e.dts.
>
> Not required, Git should handle this seamlessly.
I didn't ask you to do anything.
Also when I made the same mistake, GIT
did not handle it seamlessly and I got the following query
from Ulf http://www.mail-archive.com/[email protected]/msg33926.html
So in case Kishon has the same problem I thought I'd do a pre-emptive strike!
regards,
Peter.
Hi,
On Friday 11 July 2014 04:35 PM, Peter Griffin wrote:
> Hi Lee,
>
> On Fri, 11 Jul 2014, Lee Jones wrote:
>>> One small point, patch 5 which adds the DT nodes may not apply as the file got
>>> renamed from stih416-b2020-revE.dts to stih416-b2020e.dts.
>>
>> Not required, Git should handle this seamlessly.
>
> I didn't ask you to do anything.
>
> Also when I made the same mistake, GIT
> did not handle it seamlessly and I got the following query
> from Ulf http://www.mail-archive.com/[email protected]/msg33926.html
>
> So in case Kishon has the same problem I thought I'd do a pre-emptive strike!
thanks.. but I wouldn't be merging the dt node stuff. I think the second patch
is shared by both dt patch and driver. In that case one of me or whoever merges
the dt patch will create a branch and both of us will merge it.
Lee,
Your cover letter did not have the patch subjects. When you send the next
version can you use --cover-letter option to create the cover letter?
Thanks
Kishon
On Fri, 11 Jul 2014, Peter Griffin wrote:
> On Fri, 11 Jul 2014, Lee Jones wrote:
> > > One small point, patch 5 which adds the DT nodes may not apply as the file got
> > > renamed from stih416-b2020-revE.dts to stih416-b2020e.dts.
> >
> > Not required, Git should handle this seamlessly.
>
> I didn't ask you to do anything.
Ah, I misread, my bad.
> Also when I made the same mistake, GIT
> did not handle it seamlessly and I got the following query
> from Ulf http://www.mail-archive.com/[email protected]/msg33926.html
Oh, it looks like the renaming patch went into -rc3 as part of Max's
-fixes branch. I assumed it would go in via -next. This is
different, so yes, it will have to be rebased onto -rc3.
Maxime,
Do you want me to do that, or are you happy to?
> So in case Kishon has the same problem I thought I'd do a pre-emptive strike!
Yes, good call.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On 07/11/2014 01:30 PM, Lee Jones wrote:
> On Fri, 11 Jul 2014, Peter Griffin wrote:
>> On Fri, 11 Jul 2014, Lee Jones wrote:
>>>> One small point, patch 5 which adds the DT nodes may not apply as the file got
>>>> renamed from stih416-b2020-revE.dts to stih416-b2020e.dts.
>>>
>>> Not required, Git should handle this seamlessly.
>>
>> I didn't ask you to do anything.
>
> Ah, I misread, my bad.
>
>> Also when I made the same mistake, GIT
>> did not handle it seamlessly and I got the following query
>> from Ulf http://www.mail-archive.com/[email protected]/msg33926.html
>
> Oh, it looks like the renaming patch went into -rc3 as part of Max's
> -fixes branch. I assumed it would go in via -next. This is
> different, so yes, it will have to be rebased onto -rc3.
>
> Maxime,
> Do you want me to do that, or are you happy to?
Actually, I already rebase the next branch for DT stuff on top of -rc3.
This is not available on stlinux git yet because of mirroring issue.
I will let you know when this is fixed, then you can rebase your DT
patches on top of it.
Regards,
Maxime
>
>> So in case Kishon has the same problem I thought I'd do a pre-emptive strike!
>
> Yes, good call.
>
On Fri, 11 Jul 2014, Kishon Vijay Abraham I wrote:
> On Friday 11 July 2014 04:35 PM, Peter Griffin wrote:
> > On Fri, 11 Jul 2014, Lee Jones wrote:
> >>> One small point, patch 5 which adds the DT nodes may not apply as the file got
> >>> renamed from stih416-b2020-revE.dts to stih416-b2020e.dts.
> >>
> >> Not required, Git should handle this seamlessly.
[...]
> Your cover letter did not have the patch subjects. When you send the next
> version can you use --cover-letter option to create the cover letter?
Using --annotate and --compose has done me well up until now and no
one has ever complained before. But yes, I can use --cover-letter if
having the list of patch subjects in the 0/x patch is important
somehow.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Fri, 11 Jul 2014, Maxime Coquelin wrote:
> On 07/11/2014 01:30 PM, Lee Jones wrote:
> >On Fri, 11 Jul 2014, Peter Griffin wrote:
> >>On Fri, 11 Jul 2014, Lee Jones wrote:
> >>>>One small point, patch 5 which adds the DT nodes may not apply as the file got
> >>>>renamed from stih416-b2020-revE.dts to stih416-b2020e.dts.
> >>>
> >>>Not required, Git should handle this seamlessly.
> >>
> >>I didn't ask you to do anything.
> >
> >Ah, I misread, my bad.
> >
> >>Also when I made the same mistake, GIT
> >>did not handle it seamlessly and I got the following query
> >>from Ulf http://www.mail-archive.com/[email protected]/msg33926.html
> >
> >Oh, it looks like the renaming patch went into -rc3 as part of Max's
> >-fixes branch. I assumed it would go in via -next. This is
> >different, so yes, it will have to be rebased onto -rc3.
> >
> >Maxime,
> > Do you want me to do that, or are you happy to?
>
> Actually, I already rebase the next branch for DT stuff on top of -rc3.
> This is not available on stlinux git yet because of mirroring issue.
> I will let you know when this is fixed, then you can rebase your DT
> patches on top of it.
I'll rebase onto -rc3 now and submit the patch as a vX+1.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
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.
Acked-by: Mark Rutland <[email protected]>
Acked-by: Alexandre Torgue <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
index 4e2df66..c3c2ac6 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -12,4 +12,16 @@
/ {
model = "STiH416 B2020";
compatible = "st,stih416-b2020", "st,stih416";
+
+ soc {
+ miphy365x_phy: miphy365x@fe382000 {
+ phy_port0: port@fe382000 {
+ st,sata-gen = <3>;
+ };
+
+ phy_port1: port@fe38a000 {
+ st,pcie-tx-pol-inv;
+ };
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416-b2020e.dts b/arch/arm/boot/dts/stih416-b2020e.dts
index ba0fa2c..80aff0f 100644
--- a/arch/arm/boot/dts/stih416-b2020e.dts
+++ b/arch/arm/boot/dts/stih416-b2020e.dts
@@ -31,5 +31,15 @@
ethernet1: dwmac@fef08000 {
snps,reset-gpio = <&PIO0 7>;
};
+
+ miphy365x_phy: miphy365x@fe382000 {
+ phy_port0: port@fe382000 {
+ st,sata-gen = <3>;
+ };
+
+ phy_port1: port@fe38a000 {
+ st,pcie-tx-pol-inv;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 84758d7..2b98a0a 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>
/ {
@@ -236,5 +238,25 @@
resets = <&powerdown STIH416_KEYSCAN_POWERDOWN>,
<&softreset STIH416_KEYSCAN_SOFTRESET>;
};
+
+ miphy365x_phy: miphy365x@fe382000 {
+ compatible = "st,miphy365x-phy";
+ st,syscfg = <&syscfg_rear>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ phy_port0: port@fe382000 {
+ #phy-cells = <1>;
+ reg = <0xfe382000 0x100>, <0xfe394000 0x100>, <0x824 0x4>;
+ reg-names = "sata", "pcie", "syscfg";
+ };
+
+ phy_port1: port@fe38a000 {
+ #phy-cells = <1>;
+ reg = <0xfe38a000 0x100>, <0xfe804000 0x100>, <0x828 0x4>;
+ reg-names = "sata", "pcie", "syscfg";
+ };
+ };
};
};
Hello.
On 07/11/2014 03:54 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.
> Acked-by: Mark Rutland <[email protected]>
> Acked-by: Alexandre Torgue <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
> index 4e2df66..c3c2ac6 100644
> --- a/arch/arm/boot/dts/stih416-b2020.dts
> +++ b/arch/arm/boot/dts/stih416-b2020.dts
> @@ -12,4 +12,16 @@
> / {
> model = "STiH416 B2020";
> compatible = "st,stih416-b2020", "st,stih416";
> +
> + soc {
> + miphy365x_phy: miphy365x@fe382000 {
> + phy_port0: port@fe382000 {
I don't understand why are you creating the duplicate labels; doesn't
'dtc' complain about them? You could instead refer to them as:
&miphy365x_phy {
};
> + st,sata-gen = <3>;
> + };
> +
> + phy_port1: port@fe38a000 {
> + st,pcie-tx-pol-inv;
> + };
> + };
> + };
> };
[...]
> diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
> index 84758d7..2b98a0a 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>
> / {
> @@ -236,5 +238,25 @@
> resets = <&powerdown STIH416_KEYSCAN_POWERDOWN>,
> <&softreset STIH416_KEYSCAN_SOFTRESET>;
> };
> +
> + miphy365x_phy: miphy365x@fe382000 {
The ePAPR standard [1] says:
The name of a node should be somewhat generic, reflecting the function of the
device and not its precise programming model.
> + compatible = "st,miphy365x-phy";
> + st,syscfg = <&syscfg_rear>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + phy_port0: port@fe382000 {
> + #phy-cells = <1>;
If these are PHY devices, they should be named "phy", not "port".
> + reg = <0xfe382000 0x100>, <0xfe394000 0x100>, <0x824 0x4>;
> + reg-names = "sata", "pcie", "syscfg";
> + };
> +
> + phy_port1: port@fe38a000 {
> + #phy-cells = <1>;
> + reg = <0xfe38a000 0x100>, <0xfe804000 0x100>, <0x828 0x4>;
> + reg-names = "sata", "pcie", "syscfg";
> + };
> + };
> };
> };
WBR, Sergei
On Sat, 12 Jul 2014, Sergei Shtylyov wrote:
> Hello.
>
> On 07/11/2014 03:54 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.
>
> >Acked-by: Mark Rutland <[email protected]>
> >Acked-by: Alexandre Torgue <[email protected]>
> >Signed-off-by: Lee Jones <[email protected]>
>
> >diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
> >index 4e2df66..c3c2ac6 100644
> >--- a/arch/arm/boot/dts/stih416-b2020.dts
> >+++ b/arch/arm/boot/dts/stih416-b2020.dts
> >@@ -12,4 +12,16 @@
> > / {
> > model = "STiH416 B2020";
> > compatible = "st,stih416-b2020", "st,stih416";
> >+
> >+ soc {
> >+ miphy365x_phy: miphy365x@fe382000 {
> >+ phy_port0: port@fe382000 {
>
> I don't understand why are you creating the duplicate labels;
> doesn't 'dtc' complain about them?
I've never seen dtc complain about this:
DTC arch/arm/boot/dts/dra72-evm.dtb
DTC arch/arm/boot/dts/stih407-b2120.dtb
DTC arch/arm/boot/dts/stih415-b2000.dtb
DTC arch/arm/boot/dts/stih415-b2020.dtb
DTC arch/arm/boot/dts/stih416-b2000.dtb
DTC arch/arm/boot/dts/stih416-b2020.dtb
DTC arch/arm/boot/dts/stih416-b2020e.dtb
DTC arch/arm/boot/dts/armada-375-db.dtb
Probably because they're not actually 'duplicate' per say. Rather
they are the same node split into different files. I can remove the
labels if required though.
> You could instead refer to them
> as:
>
> &miphy365x_phy {
> };
I dislike this formatting. I find it convolutes the hierarchical
structure and makes DTS (and some DTSI) files hard to read i.e hides
parenthood etc.
[...]
> >+ miphy365x_phy: miphy365x@fe382000 {
>
> The ePAPR standard [1] says:
>
> The name of a node should be somewhat generic, reflecting the
> function of the device and not its precise programming model.
Good point. Will change to 'phy'.
> >+ compatible = "st,miphy365x-phy";
> >+ st,syscfg = <&syscfg_rear>;
> >+ #address-cells = <1>;
> >+ #size-cells = <1>;
> >+ ranges;
> >+
> >+ phy_port0: port@fe382000 {
> >+ #phy-cells = <1>;
>
> If these are PHY devices, they should be named "phy", not "port".
Then what do you call the parent node?
I see it as:
phy {
port {
};
};
Or
phy {
channel {
};
};
What does Kishon think?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hello.
On 07/14/2014 11:58 AM, 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.
>>> Acked-by: Mark Rutland <[email protected]>
>>> Acked-by: Alexandre Torgue <[email protected]>
>>> Signed-off-by: Lee Jones <[email protected]>
>>> diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
>>> index 4e2df66..c3c2ac6 100644
>>> --- a/arch/arm/boot/dts/stih416-b2020.dts
>>> +++ b/arch/arm/boot/dts/stih416-b2020.dts
>>> @@ -12,4 +12,16 @@
>>> / {
>>> model = "STiH416 B2020";
>>> compatible = "st,stih416-b2020", "st,stih416";
>>> +
>>> + soc {
>>> + miphy365x_phy: miphy365x@fe382000 {
>>> + phy_port0: port@fe382000 {
>> I don't understand why are you creating the duplicate labels;
>> doesn't 'dtc' complain about them?
> I've never seen dtc complain about this:
> DTC arch/arm/boot/dts/dra72-evm.dtb
> DTC arch/arm/boot/dts/stih407-b2120.dtb
> DTC arch/arm/boot/dts/stih415-b2000.dtb
> DTC arch/arm/boot/dts/stih415-b2020.dtb
> DTC arch/arm/boot/dts/stih416-b2000.dtb
> DTC arch/arm/boot/dts/stih416-b2020.dtb
> DTC arch/arm/boot/dts/stih416-b2020e.dtb
> DTC arch/arm/boot/dts/armada-375-db.dtb
> Probably because they're not actually 'duplicate' per say. Rather
> they are the same node split into different files. I can remove the
> labels if required though.
Yeah, I don't see why you need them if you don't refer to them anywhere.
>> You could instead refer to them
>> as:
>> &miphy365x_phy {
>> };
> I dislike this formatting. I find it convolutes the hierarchical
> structure and makes DTS (and some DTSI) files hard to read i.e hides
> parenthood etc.
Good point...
> [...]
>>> + miphy365x_phy: miphy365x@fe382000 {
>> The ePAPR standard [1] says:
>> The name of a node should be somewhat generic, reflecting the
>> function of the device and not its precise programming model.
> Good point. Will change to 'phy'.
>>> + compatible = "st,miphy365x-phy";
>>> + st,syscfg = <&syscfg_rear>;
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>> + phy_port0: port@fe382000 {
>>> + #phy-cells = <1>;
>> If these are PHY devices, they should be named "phy", not "port".
> Then what do you call the parent node?
Oh, don't ask me, it wasn't my idea to have PHY subnodes. :-)
WBR, Sergei
Hi Kishon,
> > This patchset is based on the two core patches you sent to the
> > list which facilitate creating PHYs residing on multi-channel
> > controllers. The changes since the last submission centre
> > around dynamic PHY creation based solely on what is provided via
> > Device Tree, as requested. The other review comments have also
> > been addressed in this set.
>
> Merged the first four patches of this series. (merged v3+1 for 1st patch).
> I'm not sure who would be merging the dt patch (5/5). But for now I've merged
> 2/5 in linux-phy tree since the phy patch seems to be dependent on it.
> So the dt patch can be merged only after -rc1. However if whoever merges
> dt wants to get it merged during the merge window, I can prepare a common
> branch which both of us can merge to. Either ways, dt Maintainer should
> let me know.
Thanks for applying. It would be really helpful if you could put just
patch 2/5 onto an immutable branch and provide a tag e that Maxime
could pull from.
Kind regards,
Lee
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 76 +++
> > arch/arm/boot/dts/stih416-b2020-revE.dts | 10 +
> > arch/arm/boot/dts/stih416-b2020.dts | 12 +
> > arch/arm/boot/dts/stih416.dtsi | 22 +
> > drivers/phy/Kconfig | 10 +
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-miphy365x.c | 636 +++++++++++++++++++++
> > include/dt-bindings/phy/phy-miphy365x.h | 14 +
> > 8 files changed, 781 insertions(+)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi,
On Monday 21 July 2014 01:09 PM, Lee Jones wrote:
> Hi Kishon,
>
>>> This patchset is based on the two core patches you sent to the
>>> list which facilitate creating PHYs residing on multi-channel
>>> controllers. The changes since the last submission centre
>>> around dynamic PHY creation based solely on what is provided via
>>> Device Tree, as requested. The other review comments have also
>>> been addressed in this set.
>>
>> Merged the first four patches of this series. (merged v3+1 for 1st patch).
>> I'm not sure who would be merging the dt patch (5/5). But for now I've merged
>> 2/5 in linux-phy tree since the phy patch seems to be dependent on it.
>> So the dt patch can be merged only after -rc1. However if whoever merges
>> dt wants to get it merged during the merge window, I can prepare a common
>> branch which both of us can merge to. Either ways, dt Maintainer should
>> let me know.
>
> Thanks for applying. It would be really helpful if you could put just
> patch 2/5 onto an immutable branch and provide a tag e that Maxime
> could pull from.
Sure. Created tag
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
miphy365x_dt_common_header (branch:miphy365x_dt_header). It is based on 3.16-rc5.
Thanks
Kishon
>
> Kind regards,
> Lee
>
>>> .../devicetree/bindings/phy/phy-miphy365x.txt | 76 +++
>>> arch/arm/boot/dts/stih416-b2020-revE.dts | 10 +
>>> arch/arm/boot/dts/stih416-b2020.dts | 12 +
>>> arch/arm/boot/dts/stih416.dtsi | 22 +
>>> drivers/phy/Kconfig | 10 +
>>> drivers/phy/Makefile | 1 +
>>> drivers/phy/phy-miphy365x.c | 636 +++++++++++++++++++++
>>> include/dt-bindings/phy/phy-miphy365x.h | 14 +
>>> 8 files changed, 781 insertions(+)
>
On 07/22/2014 09:23 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 21 July 2014 01:09 PM, Lee Jones wrote:
>> Hi Kishon,
>>
>>>> This patchset is based on the two core patches you sent to the
>>>> list which facilitate creating PHYs residing on multi-channel
>>>> controllers. The changes since the last submission centre
>>>> around dynamic PHY creation based solely on what is provided via
>>>> Device Tree, as requested. The other review comments have also
>>>> been addressed in this set.
>>>
>>> Merged the first four patches of this series. (merged v3+1 for 1st patch).
>>> I'm not sure who would be merging the dt patch (5/5). But for now I've merged
>>> 2/5 in linux-phy tree since the phy patch seems to be dependent on it.
>>> So the dt patch can be merged only after -rc1. However if whoever merges
>>> dt wants to get it merged during the merge window, I can prepare a common
>>> branch which both of us can merge to. Either ways, dt Maintainer should
>>> let me know.
>>
>> Thanks for applying. It would be really helpful if you could put just
>> patch 2/5 onto an immutable branch and provide a tag e that Maxime
>> could pull from.
>
> Sure. Created tag
> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
> miphy365x_dt_common_header (branch:miphy365x_dt_header). It is based on 3.16-rc5.
Thanks Kishon, I will merge it today.
Regards,
Maxime
>
> Thanks
> Kishon
>>
>> Kind regards,
>> Lee
>>
>>>> .../devicetree/bindings/phy/phy-miphy365x.txt | 76 +++
>>>> arch/arm/boot/dts/stih416-b2020-revE.dts | 10 +
>>>> arch/arm/boot/dts/stih416-b2020.dts | 12 +
>>>> arch/arm/boot/dts/stih416.dtsi | 22 +
>>>> drivers/phy/Kconfig | 10 +
>>>> drivers/phy/Makefile | 1 +
>>>> drivers/phy/phy-miphy365x.c | 636 +++++++++++++++++++++
>>>> include/dt-bindings/phy/phy-miphy365x.h | 14 +
>>>> 8 files changed, 781 insertions(+)
>>
>
> _______________________________________________
> Kernel mailing list
> [email protected]
> http://www.stlinux.com/mailman/listinfo/kernel
>
Hi Lee,
On 07/11/2014 01:54 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.
>
> Acked-by: Mark Rutland <[email protected]>
> Acked-by: Alexandre Torgue <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
>
Added to my queue for v3.17.
Thanks,
Maxime
Hi Kishon,
On 07/22/2014 09:23 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 21 July 2014 01:09 PM, Lee Jones wrote:
>> Hi Kishon,
>>
>>>> This patchset is based on the two core patches you sent to the
>>>> list which facilitate creating PHYs residing on multi-channel
>>>> controllers. The changes since the last submission centre
>>>> around dynamic PHY creation based solely on what is provided via
>>>> Device Tree, as requested. The other review comments have also
>>>> been addressed in this set.
>>>
>>> Merged the first four patches of this series. (merged v3+1 for 1st patch).
>>> I'm not sure who would be merging the dt patch (5/5). But for now I've merged
>>> 2/5 in linux-phy tree since the phy patch seems to be dependent on it.
>>> So the dt patch can be merged only after -rc1. However if whoever merges
>>> dt wants to get it merged during the merge window, I can prepare a common
>>> branch which both of us can merge to. Either ways, dt Maintainer should
>>> let me know.
>>
>> Thanks for applying. It would be really helpful if you could put just
>> patch 2/5 onto an immutable branch and provide a tag e that Maxime
>> could pull from.
>
> Sure. Created tag
> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
> miphy365x_dt_common_header (branch:miphy365x_dt_header). It is based on 3.16-rc5.
Merged into git://git.stlinux.com/devel/kernel/linux-sti.git sti-dt-for-v3.17-1
Thanks!
Maxime
>
> Thanks
> Kishon
>>
>> Kind regards,
>> Lee
>>
>>>> .../devicetree/bindings/phy/phy-miphy365x.txt | 76 +++
>>>> arch/arm/boot/dts/stih416-b2020-revE.dts | 10 +
>>>> arch/arm/boot/dts/stih416-b2020.dts | 12 +
>>>> arch/arm/boot/dts/stih416.dtsi | 22 +
>>>> drivers/phy/Kconfig | 10 +
>>>> drivers/phy/Makefile | 1 +
>>>> drivers/phy/phy-miphy365x.c | 636 +++++++++++++++++++++
>>>> include/dt-bindings/phy/phy-miphy365x.h | 14 +
>>>> 8 files changed, 781 insertions(+)
>>
>
> _______________________________________________
> Kernel mailing list
> [email protected]
> http://www.stlinux.com/mailman/listinfo/kernel
>
On Wednesday 23 July 2014 01:28 PM, Maxime Coquelin wrote:
> Hi Kishon,
>
> On 07/22/2014 09:23 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Monday 21 July 2014 01:09 PM, Lee Jones wrote:
>>> Hi Kishon,
>>>
>>>>> This patchset is based on the two core patches you sent to the
>>>>> list which facilitate creating PHYs residing on multi-channel
>>>>> controllers. The changes since the last submission centre
>>>>> around dynamic PHY creation based solely on what is provided via
>>>>> Device Tree, as requested. The other review comments have also
>>>>> been addressed in this set.
>>>>
>>>> Merged the first four patches of this series. (merged v3+1 for 1st patch).
>>>> I'm not sure who would be merging the dt patch (5/5). But for now I've merged
>>>> 2/5 in linux-phy tree since the phy patch seems to be dependent on it.
>>>> So the dt patch can be merged only after -rc1. However if whoever merges
>>>> dt wants to get it merged during the merge window, I can prepare a common
>>>> branch which both of us can merge to. Either ways, dt Maintainer should
>>>> let me know.
>>>
>>> Thanks for applying. It would be really helpful if you could put just
>>> patch 2/5 onto an immutable branch and provide a tag e that Maxime
>>> could pull from.
>>
>> Sure. Created tag
>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
>> miphy365x_dt_common_header (branch:miphy365x_dt_header). It is based on 3.16-rc5.
>
> Merged into git://git.stlinux.com/devel/kernel/linux-sti.git sti-dt-for-v3.17-1
cool, thanks.
-Kishon
>
> Thanks!
> Maxime
>
>>
>> Thanks
>> Kishon
>>>
>>> Kind regards,
>>> Lee
>>>
>>>>> .../devicetree/bindings/phy/phy-miphy365x.txt | 76 +++
>>>>> arch/arm/boot/dts/stih416-b2020-revE.dts | 10 +
>>>>> arch/arm/boot/dts/stih416-b2020.dts | 12 +
>>>>> arch/arm/boot/dts/stih416.dtsi | 22 +
>>>>> drivers/phy/Kconfig | 10 +
>>>>> drivers/phy/Makefile | 1 +
>>>>> drivers/phy/phy-miphy365x.c | 636 +++++++++++++++++++++
>>>>> include/dt-bindings/phy/phy-miphy365x.h | 14 +
>>>>> 8 files changed, 781 insertions(+)
>>>
>>
>> _______________________________________________
>> Kernel mailing list
>> [email protected]
>> http://www.stlinux.com/mailman/listinfo/kernel
>>