[PATCH 00/15] Enhance CP110 COMPHY support

[PATCH 00/15] Enhance CP110 COMPHY support

[Miquel Raynal]

Armada CP110 have a COMPHY IP which supports configuring SERDES lanes
in one mode, either:
- SATA
- USB3 host
- PCIe (several width)
- Ethernet (several modes)

As of today, only a few Ethernet modes are supported and the code is
embedded in the Linux driver. A more complete COMPHY driver that can
be used by both Linux and U-Boot is embedded in the firmware and can
be run through SMC calls.

First the current COMPHY driver is updated to use SMC calls but
fallbacks to the already existing functions if the firmware is not
up-to-date. Then, more Ethernet modes are added (through SMC calls
only). SATA, USB3H and PCIe modes are also supported one by one.

There is one subtle difference with the PCIe functions: we must tell
the firmware the number of lanes to configure (x1, x2 or x4). This
parameter depends on the number of entries in the 'phys' property
describing the PCIe PHY. We use the "submode" parameter of the generic
PHY API to carry this value. The Armada-8k PCIe driver has been
updated to follow this idea, see [1].

Finally, as pointed by Rob during a review, there is a phy-supply
property (part of the generic PHY framework) which is supposed to take
over the usb-phy property, while at modifying PHY properties, we do
the translation for COMPHY PHYs.

[1] http://patchwork.ozlabs.org/patch/1072763/

Thanks,
Miquèl


Miquel Raynal (15):
  phy: mvebu-cp110-comphy: Explicitly initialize the lane submode
  phy: mvebu-cp110-comphy: Add SMC call support
  phy: mvebu-cp110-comphy: List already supported Ethernet modes
  phy: mvebu-cp110-comphy: Add RXAUI support
  phy: mvebu-cp110-comphy: Rename the macro handling only Ethernet modes
  phy: mvebu-cp110-comphy: Allow non-Ethernet modes to be configured
  phy: mvebu-cp110-comphy: Add USB3 host/device support
  phy: mvebu-cp110-comphy: Add SATA support
  phy: mvebu-cp110-comphy: Cosmetic change in a helper
  phy: mvebu-cp110-comphy: Add PCIe support
  phy: mvebu-cp110-comphy: Update comment about powering off all lanes
    at boot
  arm64: dts: marvell: Add 7k/8k per-port PHYs in SATA nodes
  arm64: dts: marvell: Add 7k/8k PHYs in USB3 nodes
  arm64: dts: marvell: Add 7k/8k PHYs in PCIe nodes
  arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply

 .../arm64/boot/dts/marvell/armada-7040-db.dts |  37 ++-
 .../marvell/armada-8040-clearfog-gt-8k.dts    |  22 +-
 .../arm64/boot/dts/marvell/armada-8040-db.dts |  43 ++-
 .../boot/dts/marvell/armada-8040-mcbin.dtsi   |  37 ++-
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c  | 293 +++++++++++++++---
 5 files changed, 355 insertions(+), 77 deletions(-)

-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 01/15] phy: mvebu-cp110-comphy: Explicitly initialize the lane submode

[Miquel Raynal]

Explicitly set the lane submode (enum) to a known invalid value.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index d98e0451f6a1..3f50a1521f01 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -635,6 +635,7 @@ static int mvebu_comphy_probe(struct platform_device *pdev)
 
 		lane->priv = priv;
 		lane->mode = PHY_MODE_INVALID;
+		lane->submode = PHY_INTERFACE_MODE_NA;
 		lane->id = val;
 		lane->port = -1;
 		phy_set_drvdata(phy, lane);
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 02/15] phy: mvebu-cp110-comphy: Add SMC call support

[Miquel Raynal]

Keep the exact same list of supported configurations but first try to
use the firmware's implementation. If it fails, try the legacy method:
Linux implementation.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 200 +++++++++++++++----
 1 file changed, 164 insertions(+), 36 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index 3f50a1521f01..4aaf161503d6 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -5,6 +5,7 @@
  * Antoine Tenart <antoine.tenart@free-electrons.com>
  */
 
+#include <linux/arm-smccc.h>
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/mfd/syscon.h>
@@ -115,51 +116,88 @@
 #define MVEBU_COMPHY_LANES	6
 #define MVEBU_COMPHY_PORTS	3
 
+#define COMPHY_SIP_POWER_ON	0x82000001
+#define COMPHY_SIP_POWER_OFF	0x82000002
+
+/*
+ * A lane is described by the following bitfields:
+ * [ 1- 0]: COMPHY polarity invertion
+ * [ 2- 7]: COMPHY speed
+ * [ 5-11]: COMPHY port index
+ * [12-16]: COMPHY mode
+ * [17]: Clock source
+ */
+#define COMPHY_FW_POL_OFFSET	0
+#define COMPHY_FW_POL_MASK	GENMASK(1, 0)
+#define COMPHY_FW_SPEED_OFFSET	2
+#define COMPHY_FW_SPEED_MASK	GENMASK(7, 2)
+#define COMPHY_FW_SPEED_MAX	COMPHY_FW_SPEED_MASK
+#define COMPHY_FW_PORT_OFFSET	8
+#define COMPHY_FW_PORT_MASK	GENMASK(11, 8)
+#define COMPHY_FW_MODE_OFFSET	12
+#define COMPHY_FW_MODE_MASK	GENMASK(16, 12)
+
+#define COMPHY_FW_PARAM_FULL(mode, port, speed, pol)			\
+	((((pol) << COMPHY_FW_POL_OFFSET) & COMPHY_FW_POL_MASK) |	\
+	 (((mode) << COMPHY_FW_MODE_OFFSET) & COMPHY_FW_MODE_MASK) |	\
+	 (((port) << COMPHY_FW_PORT_OFFSET) & COMPHY_FW_PORT_MASK) |	\
+	 (((speed) << COMPHY_FW_SPEED_OFFSET) & COMPHY_FW_SPEED_MASK))
+
+#define COMPHY_FW_PARAM(mode, port)					\
+	COMPHY_FW_PARAM_FULL(mode, port, COMPHY_FW_SPEED_MAX, 0)
+
+#define COMPHY_FW_MODE_SGMII		0x2 /* SGMII 1G */
+#define COMPHY_FW_MODE_HS_SGMII		0x3 /* SGMII 2.5G */
+#define COMPHY_FW_MODE_SFI		0x9 /* XFI: 0x8 (is treated like SFI) */
+
 struct mvebu_comphy_conf {
 	enum phy_mode mode;
 	int submode;
 	unsigned lane;
 	unsigned port;
 	u32 mux;
+	u32 fw_mode;
 };
 
-#define MVEBU_COMPHY_CONF(_lane, _port, _submode, _mux)	\
+#define MVEBU_COMPHY_CONF(_lane, _port, _submode, _mux, _fw)	\
 	{						\
 		.lane = _lane,				\
 		.port = _port,				\
 		.mode = PHY_MODE_ETHERNET,		\
 		.submode = _submode,			\
 		.mux = _mux,				\
+		.fw_mode = _fw,				\
 	}
 
 static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	/* lane 0 */
-	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1),
-	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1),
+	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 1 */
-	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1),
-	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1),
+	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 2 */
-	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1),
-	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1),
-	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1),
+	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
 	/* lane 3 */
-	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2),
-	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2),
+	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
+	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 4 */
-	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2),
-	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2),
-	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2),
-	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1),
+	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
+	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
+	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2, COMPHY_FW_MODE_SFI),
+	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	/* lane 5 */
-	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1),
-	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1),
+	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 };
 
 struct mvebu_comphy_priv {
 	void __iomem *base;
 	struct regmap *regmap;
 	struct device *dev;
+	unsigned long cp_phys;
 };
 
 struct mvebu_comphy_lane {
@@ -170,8 +208,18 @@ struct mvebu_comphy_lane {
 	int port;
 };
 
-static int mvebu_comphy_get_mux(int lane, int port,
-				enum phy_mode mode, int submode)
+static int mvebu_comphy_smc(unsigned long function, unsigned long phys,
+			    unsigned long lane, unsigned long mode)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_smc(function, phys, lane, mode, 0, 0, 0, 0, &res);
+
+	return res.a0;
+}
+
+static int mvebu_comphy_get_mode(bool fw_mode, int lane, int port,
+				 enum phy_mode mode, int submode)
 {
 	int i, n = ARRAY_SIZE(mvebu_comphy_cp110_modes);
 
@@ -190,7 +238,22 @@ static int mvebu_comphy_get_mux(int lane, int port,
 	if (i == n)
 		return -EINVAL;
 
-	return mvebu_comphy_cp110_modes[i].mux;
+	if (fw_mode)
+		return mvebu_comphy_cp110_modes[i].fw_mode;
+	else
+		return mvebu_comphy_cp110_modes[i].mux;
+}
+
+static inline int mvebu_comphy_get_mux(int lane, int port,
+				       enum phy_mode mode, int submode)
+{
+	return mvebu_comphy_get_mode(false, lane, port, mode, submode);
+}
+
+static inline int mvebu_comphy_get_fw_mode(int lane, int port,
+					   enum phy_mode mode, int submode)
+{
+	return mvebu_comphy_get_mode(true, lane, port, mode, submode);
 }
 
 static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane)
@@ -476,7 +539,7 @@ static int mvebu_comphy_set_mode_10gkr(struct phy *phy)
 	return mvebu_comphy_init_plls(lane);
 }
 
-static int mvebu_comphy_power_on(struct phy *phy)
+static int mvebu_comphy_power_on_legacy(struct phy *phy)
 {
 	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
 	struct mvebu_comphy_priv *priv = lane->priv;
@@ -517,6 +580,50 @@ static int mvebu_comphy_power_on(struct phy *phy)
 	return ret;
 }
 
+static int mvebu_comphy_power_on(struct phy *phy)
+{
+	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
+	struct mvebu_comphy_priv *priv = lane->priv;
+	u32 fw_param = 0;
+	int fw_mode;
+	int ret;
+
+	fw_mode = mvebu_comphy_get_fw_mode(lane->id, lane->port,
+					   lane->mode, lane->submode);
+	if (fw_mode < 0)
+		goto try_legacy;
+
+	/* Try SMC flow first */
+	switch (lane->mode) {
+	case PHY_MODE_ETHERNET:
+		dev_dbg(priv->dev, "set lane %d to Ethernet mode\n", lane->id);
+		switch (lane->submode) {
+		case PHY_INTERFACE_MODE_SGMII:
+		case PHY_INTERFACE_MODE_2500BASEX:
+		case PHY_INTERFACE_MODE_10GKR:
+			fw_param = COMPHY_FW_PARAM(fw_mode, lane->port);
+			break;
+		default:
+			dev_err(priv->dev, "unsupported Ethernet mode (%d)\n",
+				lane->submode);
+			return -ENOTSUPP;
+		}
+		break;
+	default:
+		dev_err(priv->dev, "unsupported PHY mode (%d)\n", lane->mode);
+		return -ENOTSUPP;
+	}
+
+	ret = mvebu_comphy_smc(COMPHY_SIP_POWER_ON, priv->cp_phys, lane->id,
+			       fw_param);
+	if (!ret)
+		return ret;
+
+try_legacy:
+	/* Fallback to Linux's implementation */
+	return mvebu_comphy_power_on_legacy(phy);
+}
+
 static int mvebu_comphy_set_mode(struct phy *phy,
 				 enum phy_mode mode, int submode)
 {
@@ -528,7 +635,7 @@ static int mvebu_comphy_set_mode(struct phy *phy,
 	if (submode == PHY_INTERFACE_MODE_1000BASEX)
 		submode = PHY_INTERFACE_MODE_SGMII;
 
-	if (mvebu_comphy_get_mux(lane->id, lane->port, mode, submode) < 0)
+	if (mvebu_comphy_get_fw_mode(lane->id, lane->port, mode, submode) < 0)
 		return -EINVAL;
 
 	lane->mode = mode;
@@ -536,27 +643,42 @@ static int mvebu_comphy_set_mode(struct phy *phy,
 	return 0;
 }
 
+static int mvebu_comphy_power_off_legacy(struct phy *phy)
+{
+	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
+	struct mvebu_comphy_priv *priv = lane->priv;
+	u32 val;
+
+	val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
+	val &= ~(MVEBU_COMPHY_SERDES_CFG1_RESET |
+		 MVEBU_COMPHY_SERDES_CFG1_CORE_RESET |
+		 MVEBU_COMPHY_SERDES_CFG1_RF_RESET);
+	writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
+
+	regmap_read(priv->regmap, MVEBU_COMPHY_SELECTOR, &val);
+	val &= ~(0xf << MVEBU_COMPHY_SELECTOR_PHY(lane->id));
+	regmap_write(priv->regmap, MVEBU_COMPHY_SELECTOR, val);
+
+	regmap_read(priv->regmap, MVEBU_COMPHY_PIPE_SELECTOR, &val);
+	val &= ~(0xf << MVEBU_COMPHY_PIPE_SELECTOR_PIPE(lane->id));
+	regmap_write(priv->regmap, MVEBU_COMPHY_PIPE_SELECTOR, val);
+
+	return 0;
+}
+
 static int mvebu_comphy_power_off(struct phy *phy)
 {
 	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
 	struct mvebu_comphy_priv *priv = lane->priv;
-	u32 val;
+	int ret;
 
-	val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
-	val &= ~(MVEBU_COMPHY_SERDES_CFG1_RESET |
-		 MVEBU_COMPHY_SERDES_CFG1_CORE_RESET |
-		 MVEBU_COMPHY_SERDES_CFG1_RF_RESET);
-	writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
+	ret = mvebu_comphy_smc(COMPHY_SIP_POWER_OFF, priv->cp_phys,
+			       lane->id, 0);
+	if (!ret)
+		return ret;
 
-	regmap_read(priv->regmap, MVEBU_COMPHY_SELECTOR, &val);
-	val &= ~(0xf << MVEBU_COMPHY_SELECTOR_PHY(lane->id));
-	regmap_write(priv->regmap, MVEBU_COMPHY_SELECTOR, val);
-
-	regmap_read(priv->regmap, MVEBU_COMPHY_PIPE_SELECTOR, &val);
-	val &= ~(0xf << MVEBU_COMPHY_PIPE_SELECTOR_PIPE(lane->id));
-	regmap_write(priv->regmap, MVEBU_COMPHY_PIPE_SELECTOR, val);
-
-	return 0;
+	/* Fallback to Linux's implementation */
+	return mvebu_comphy_power_off_legacy(phy);
 }
 
 static const struct phy_ops mvebu_comphy_ops = {
@@ -607,6 +729,12 @@ static int mvebu_comphy_probe(struct platform_device *pdev)
 	if (IS_ERR(priv->base))
 		return PTR_ERR(priv->base);
 
+	/*
+	 * Hack to retrieve a physical offset relative to this CP that will be
+	 * given to the firmware
+	 */
+	priv->cp_phys = res->start;
+
 	for_each_available_child_of_node(pdev->dev.of_node, child) {
 		struct mvebu_comphy_lane *lane;
 		struct phy *phy;
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 03/15] phy: mvebu-cp110-comphy: List already supported Ethernet modes

[Miquel Raynal]

Currently, the driver supports setting lanes to 1000BASEX, 2500BASEX,
10GKR. Complete the COMPHY modes list by adding two (already
supported) cases for lane 4.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index 4aaf161503d6..b6890d3c34a3 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -188,6 +188,8 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
 	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2, COMPHY_FW_MODE_SFI),
 	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_2500BASEX, -1, COMPHY_FW_MODE_HS_SGMII),
+	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_10GKR, -1, COMPHY_FW_MODE_SFI),
 	/* lane 5 */
 	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 04/15] phy: mvebu-cp110-comphy: Add RXAUI support

[Miquel Raynal]

Add support for RXAUI mode by adding an entry in the COMPHY modes list.

There is nothing more to handle besides avoiding to return an error to
the caller: someone using a DT updated with the right 'phys' property
with an old firmware would get an error when initializing the lanes in
RXAUI mode, while it could have already been initialized by eg. the
bootloader. It would prevent the interface to work with no reason.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index b6890d3c34a3..393dfcc59a33 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -148,6 +148,7 @@
 
 #define COMPHY_FW_MODE_SGMII		0x2 /* SGMII 1G */
 #define COMPHY_FW_MODE_HS_SGMII		0x3 /* SGMII 2.5G */
+#define COMPHY_FW_MODE_RXAUI		0x7
 #define COMPHY_FW_MODE_SFI		0x9 /* XFI: 0x8 (is treated like SFI) */
 
 struct mvebu_comphy_conf {
@@ -179,18 +180,22 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	/* lane 2 */
 	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
 	/* lane 3 */
 	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
+	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	/* lane 4 */
 	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
 	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2, COMPHY_FW_MODE_SFI),
+	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_2500BASEX, -1, COMPHY_FW_MODE_HS_SGMII),
 	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_10GKR, -1, COMPHY_FW_MODE_SFI),
 	/* lane 5 */
+	MVEBU_COMPHY_CONF(5, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 };
@@ -586,6 +591,7 @@ static int mvebu_comphy_power_on(struct phy *phy)
 {
 	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
 	struct mvebu_comphy_priv *priv = lane->priv;
+	bool hide_error = false; /* Handle new DT & old firmware */
 	u32 fw_param = 0;
 	int fw_mode;
 	int ret;
@@ -600,6 +606,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
 	case PHY_MODE_ETHERNET:
 		dev_dbg(priv->dev, "set lane %d to Ethernet mode\n", lane->id);
 		switch (lane->submode) {
+		case PHY_INTERFACE_MODE_RXAUI:
+			hide_error = true;
 		case PHY_INTERFACE_MODE_SGMII:
 		case PHY_INTERFACE_MODE_2500BASEX:
 		case PHY_INTERFACE_MODE_10GKR:
@@ -618,8 +626,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
 
 	ret = mvebu_comphy_smc(COMPHY_SIP_POWER_ON, priv->cp_phys, lane->id,
 			       fw_param);
-	if (!ret)
-		return ret;
+	if (!ret || hide_error)
+		return 0;
 
 try_legacy:
 	/* Fallback to Linux's implementation */
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 05/15] phy: mvebu-cp110-comphy: Rename the macro handling only Ethernet modes

[Miquel Raynal]

Before adding support for other PHY modes (not Ethernet ones), let's
rename the MVEBU_COMPHY_CONF macro to a more specific (and shorter)
appellation.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 44 ++++++++++----------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index 393dfcc59a33..f8f2bca7413d 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -160,7 +160,7 @@ struct mvebu_comphy_conf {
 	u32 fw_mode;
 };
 
-#define MVEBU_COMPHY_CONF(_lane, _port, _submode, _mux, _fw)	\
+#define ETH_CONF(_lane, _port, _submode, _mux, _fw)	\
 	{						\
 		.lane = _lane,				\
 		.port = _port,				\
@@ -172,32 +172,32 @@ struct mvebu_comphy_conf {
 
 static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	/* lane 0 */
-	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
-	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	ETH_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	ETH_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 1 */
-	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
-	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	ETH_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	ETH_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 2 */
-	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
-	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
-	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
-	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
+	ETH_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	ETH_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	ETH_CONF(2, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
+	ETH_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
 	/* lane 3 */
-	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
-	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
-	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
+	ETH_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
+	ETH_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
+	ETH_CONF(3, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	/* lane 4 */
-	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
-	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
-	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2, COMPHY_FW_MODE_SFI),
-	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
-	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
-	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_2500BASEX, -1, COMPHY_FW_MODE_HS_SGMII),
-	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_10GKR, -1, COMPHY_FW_MODE_SFI),
+	ETH_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
+	ETH_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
+	ETH_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2, COMPHY_FW_MODE_SFI),
+	ETH_CONF(4, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
+	ETH_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	ETH_CONF(4, 1, PHY_INTERFACE_MODE_2500BASEX, -1, COMPHY_FW_MODE_HS_SGMII),
+	ETH_CONF(4, 1, PHY_INTERFACE_MODE_10GKR, -1, COMPHY_FW_MODE_SFI),
 	/* lane 5 */
-	MVEBU_COMPHY_CONF(5, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
-	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
-	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	ETH_CONF(5, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
+	ETH_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
+	ETH_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 };
 
 struct mvebu_comphy_priv {
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 06/15] phy: mvebu-cp110-comphy: Allow non-Ethernet modes to be configured

[Miquel Raynal]

The COMPHY can configure the SERDES lanes in several non-Ethernet
modes: SATA, USB3, PCIe. Drop the condition limiting the driver to
Ethernet modes only before adding support for more.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index f8f2bca7413d..21431e3e085a 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -639,9 +639,6 @@ static int mvebu_comphy_set_mode(struct phy *phy,
 {
 	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
 
-	if (mode != PHY_MODE_ETHERNET)
-		return -EINVAL;
-
 	if (submode == PHY_INTERFACE_MODE_1000BASEX)
 		submode = PHY_INTERFACE_MODE_SGMII;
 
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 07/15] phy: mvebu-cp110-comphy: Add USB3 host/device support

[Miquel Raynal]

Add USB3 host/device support by adding the right entries in the COMPHY
modes table. A new macro is created to instantiate a "generic" mode
ie. not an Ethernet one. This macro will be re-used when adding SATA
support.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 24 ++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index 21431e3e085a..3eb92a629dcc 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -148,6 +148,8 @@
 
 #define COMPHY_FW_MODE_SGMII		0x2 /* SGMII 1G */
 #define COMPHY_FW_MODE_HS_SGMII		0x3 /* SGMII 2.5G */
+#define COMPHY_FW_MODE_USB3H		0x4
+#define COMPHY_FW_MODE_USB3D		0x5
 #define COMPHY_FW_MODE_RXAUI		0x7
 #define COMPHY_FW_MODE_SFI		0x9 /* XFI: 0x8 (is treated like SFI) */
 
@@ -170,11 +172,23 @@ struct mvebu_comphy_conf {
 		.fw_mode = _fw,				\
 	}
 
+#define GEN_CONF(_lane, _port, _mode, _fw)		\
+	{						\
+		.lane = _lane,				\
+		.port = _port,				\
+		.mode = _mode,				\
+		.submode = PHY_INTERFACE_MODE_NA,	\
+		.mux = -1,				\
+		.fw_mode = _fw,				\
+	}
+
 static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	/* lane 0 */
 	ETH_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 1 */
+	GEN_CONF(1, 0, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
+	GEN_CONF(1, 0, PHY_MODE_USB_DEVICE_SS, COMPHY_FW_MODE_USB3D),
 	ETH_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 2 */
@@ -182,15 +196,19 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	ETH_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	ETH_CONF(2, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	ETH_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
+	GEN_CONF(2, 0, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
 	/* lane 3 */
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
+	GEN_CONF(3, 1, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
 	/* lane 4 */
 	ETH_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
 	ETH_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2, COMPHY_FW_MODE_SFI),
 	ETH_CONF(4, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
+	GEN_CONF(4, 0, PHY_MODE_USB_DEVICE_SS, COMPHY_FW_MODE_USB3D),
+	GEN_CONF(4, 1, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
 	ETH_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(4, 1, PHY_INTERFACE_MODE_2500BASEX, -1, COMPHY_FW_MODE_HS_SGMII),
 	ETH_CONF(4, 1, PHY_INTERFACE_MODE_10GKR, -1, COMPHY_FW_MODE_SFI),
@@ -619,6 +637,12 @@ static int mvebu_comphy_power_on(struct phy *phy)
 			return -ENOTSUPP;
 		}
 		break;
+	case PHY_MODE_USB_HOST_SS:
+	case PHY_MODE_USB_DEVICE_SS:
+		hide_error = true;
+		dev_dbg(priv->dev, "set lane %d to USB3 mode\n", lane->id);
+		fw_param = COMPHY_FW_PARAM(fw_mode, lane->port);
+		break;
 	default:
 		dev_err(priv->dev, "unsupported PHY mode (%d)\n", lane->mode);
 		return -ENOTSUPP;
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 08/15] phy: mvebu-cp110-comphy: Add SATA support

[Miquel Raynal]

Add the corresponding entries in the COMPHY modes table.

SATA support does not need any additional care.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index 3eb92a629dcc..7e25469919eb 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -146,6 +146,7 @@
 #define COMPHY_FW_PARAM(mode, port)					\
 	COMPHY_FW_PARAM_FULL(mode, port, COMPHY_FW_SPEED_MAX, 0)
 
+#define COMPHY_FW_MODE_SATA		0x1
 #define COMPHY_FW_MODE_SGMII		0x2 /* SGMII 1G */
 #define COMPHY_FW_MODE_HS_SGMII		0x3 /* SGMII 2.5G */
 #define COMPHY_FW_MODE_USB3H		0x4
@@ -186,9 +187,11 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	/* lane 0 */
 	ETH_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	GEN_CONF(0, 1, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
 	/* lane 1 */
 	GEN_CONF(1, 0, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
 	GEN_CONF(1, 0, PHY_MODE_USB_DEVICE_SS, COMPHY_FW_MODE_USB3D),
+	GEN_CONF(1, 0, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
 	ETH_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 2 */
@@ -197,11 +200,13 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	ETH_CONF(2, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	ETH_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
 	GEN_CONF(2, 0, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
+	GEN_CONF(2, 0, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
 	/* lane 3 */
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	GEN_CONF(3, 1, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
+	GEN_CONF(3, 1, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
 	/* lane 4 */
 	ETH_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
@@ -214,6 +219,7 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	ETH_CONF(4, 1, PHY_INTERFACE_MODE_10GKR, -1, COMPHY_FW_MODE_SFI),
 	/* lane 5 */
 	ETH_CONF(5, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
+	GEN_CONF(5, 1, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
 	ETH_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 };
@@ -643,6 +649,11 @@ static int mvebu_comphy_power_on(struct phy *phy)
 		dev_dbg(priv->dev, "set lane %d to USB3 mode\n", lane->id);
 		fw_param = COMPHY_FW_PARAM(fw_mode, lane->port);
 		break;
+	case PHY_MODE_SATA:
+		hide_error = true;
+		dev_dbg(priv->dev, "set lane %d to SATA mode\n", lane->id);
+		fw_param = COMPHY_FW_PARAM(fw_mode, lane->port);
+		break;
 	default:
 		dev_err(priv->dev, "unsupported PHY mode (%d)\n", lane->mode);
 		return -ENOTSUPP;
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 09/15] phy: mvebu-cp110-comphy: Cosmetic change in a helper

[Miquel Raynal]

Before adding more logic, simplify a bit the writing of the
mvebu_comphy_get_mode() helper by using a pointer instead of
referencing a configuration with the entire table name.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index 7e25469919eb..ab1f46b1dbe1 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -253,16 +253,18 @@ static int mvebu_comphy_get_mode(bool fw_mode, int lane, int port,
 				 enum phy_mode mode, int submode)
 {
 	int i, n = ARRAY_SIZE(mvebu_comphy_cp110_modes);
+	const struct mvebu_comphy_conf *conf;
 
 	/* Unused PHY mux value is 0x0 */
 	if (mode == PHY_MODE_INVALID)
 		return 0;
 
 	for (i = 0; i < n; i++) {
-		if (mvebu_comphy_cp110_modes[i].lane == lane &&
-		    mvebu_comphy_cp110_modes[i].port == port &&
-		    mvebu_comphy_cp110_modes[i].mode == mode &&
-		    mvebu_comphy_cp110_modes[i].submode == submode)
+		conf = &mvebu_comphy_cp110_modes[i];
+		if (conf->lane == lane &&
+		    conf->port == port &&
+		    conf->mode == mode &&
+		    conf->submode == submode)
 			break;
 	}
 
@@ -270,9 +272,9 @@ static int mvebu_comphy_get_mode(bool fw_mode, int lane, int port,
 		return -EINVAL;
 
 	if (fw_mode)
-		return mvebu_comphy_cp110_modes[i].fw_mode;
+		return conf->fw_mode;
 	else
-		return mvebu_comphy_cp110_modes[i].mux;
+		return conf->mux;
 }
 
 static inline int mvebu_comphy_get_mux(int lane, int port,
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 10/15] phy: mvebu-cp110-comphy: Add PCIe support

[Miquel Raynal]

Add PCIe support by filling the COMPHY modes table.

Also add a new macro to generate the right value for the firmware
depending on the width (PCI x1, x2, x4, etc). The width will be passed
by the core as the "submode" argument of the ->set_mode() callback. If
this argument is zero, default to x1 mode.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 36 +++++++++++++++++---
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index ab1f46b1dbe1..d66412b38ff7 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -126,6 +126,7 @@
  * [ 5-11]: COMPHY port index
  * [12-16]: COMPHY mode
  * [17]: Clock source
+ * [18-20]: PCIe width (x1, x2, x4)
  */
 #define COMPHY_FW_POL_OFFSET	0
 #define COMPHY_FW_POL_MASK	GENMASK(1, 0)
@@ -136,21 +137,28 @@
 #define COMPHY_FW_PORT_MASK	GENMASK(11, 8)
 #define COMPHY_FW_MODE_OFFSET	12
 #define COMPHY_FW_MODE_MASK	GENMASK(16, 12)
+#define COMPHY_FW_WIDTH_OFFSET	18
+#define COMPHY_FW_WIDTH_MASK	GENMASK(20, 18)
 
-#define COMPHY_FW_PARAM_FULL(mode, port, speed, pol)			\
+#define COMPHY_FW_PARAM_FULL(mode, port, speed, pol, width)		\
 	((((pol) << COMPHY_FW_POL_OFFSET) & COMPHY_FW_POL_MASK) |	\
 	 (((mode) << COMPHY_FW_MODE_OFFSET) & COMPHY_FW_MODE_MASK) |	\
 	 (((port) << COMPHY_FW_PORT_OFFSET) & COMPHY_FW_PORT_MASK) |	\
-	 (((speed) << COMPHY_FW_SPEED_OFFSET) & COMPHY_FW_SPEED_MASK))
+	 (((speed) << COMPHY_FW_SPEED_OFFSET) & COMPHY_FW_SPEED_MASK) |	\
+	 (((width) << COMPHY_FW_WIDTH_OFFSET) & COMPHY_FW_WIDTH_MASK))
 
 #define COMPHY_FW_PARAM(mode, port)					\
-	COMPHY_FW_PARAM_FULL(mode, port, COMPHY_FW_SPEED_MAX, 0)
+	COMPHY_FW_PARAM_FULL(mode, port, COMPHY_FW_SPEED_MAX, 0, 0)
+
+#define COMPHY_FW_PARAM_PCIE(mode, port, width)				\
+	COMPHY_FW_PARAM_FULL(mode, port, 0x3F, 0, width)
 
 #define COMPHY_FW_MODE_SATA		0x1
 #define COMPHY_FW_MODE_SGMII		0x2 /* SGMII 1G */
 #define COMPHY_FW_MODE_HS_SGMII		0x3 /* SGMII 2.5G */
 #define COMPHY_FW_MODE_USB3H		0x4
 #define COMPHY_FW_MODE_USB3D		0x5
+#define COMPHY_FW_MODE_PCIE		0x6
 #define COMPHY_FW_MODE_RXAUI		0x7
 #define COMPHY_FW_MODE_SFI		0x9 /* XFI: 0x8 (is treated like SFI) */
 
@@ -185,6 +193,7 @@ struct mvebu_comphy_conf {
 
 static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	/* lane 0 */
+	GEN_CONF(0, 0, PHY_MODE_PCIE, COMPHY_FW_MODE_PCIE),
 	ETH_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	GEN_CONF(0, 1, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
@@ -192,6 +201,7 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	GEN_CONF(1, 0, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
 	GEN_CONF(1, 0, PHY_MODE_USB_DEVICE_SS, COMPHY_FW_MODE_USB3D),
 	GEN_CONF(1, 0, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
+	GEN_CONF(1, 0, PHY_MODE_PCIE, COMPHY_FW_MODE_PCIE),
 	ETH_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
 	/* lane 2 */
@@ -201,7 +211,9 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	ETH_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
 	GEN_CONF(2, 0, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
 	GEN_CONF(2, 0, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
+	GEN_CONF(2, 0, PHY_MODE_PCIE, COMPHY_FW_MODE_PCIE),
 	/* lane 3 */
+	GEN_CONF(3, 0, PHY_MODE_PCIE, COMPHY_FW_MODE_PCIE),
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
 	ETH_CONF(3, 1, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
@@ -214,6 +226,7 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	ETH_CONF(4, 0, PHY_INTERFACE_MODE_RXAUI, -1, COMPHY_FW_MODE_RXAUI),
 	GEN_CONF(4, 0, PHY_MODE_USB_DEVICE_SS, COMPHY_FW_MODE_USB3D),
 	GEN_CONF(4, 1, PHY_MODE_USB_HOST_SS, COMPHY_FW_MODE_USB3H),
+	GEN_CONF(4, 1, PHY_MODE_PCIE, COMPHY_FW_MODE_PCIE),
 	ETH_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(4, 1, PHY_INTERFACE_MODE_2500BASEX, -1, COMPHY_FW_MODE_HS_SGMII),
 	ETH_CONF(4, 1, PHY_INTERFACE_MODE_10GKR, -1, COMPHY_FW_MODE_SFI),
@@ -222,6 +235,7 @@ static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
 	GEN_CONF(5, 1, PHY_MODE_SATA, COMPHY_FW_MODE_SATA),
 	ETH_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
 	ETH_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
+	GEN_CONF(5, 2, PHY_MODE_PCIE, COMPHY_FW_MODE_PCIE),
 };
 
 struct mvebu_comphy_priv {
@@ -253,6 +267,8 @@ static int mvebu_comphy_get_mode(bool fw_mode, int lane, int port,
 				 enum phy_mode mode, int submode)
 {
 	int i, n = ARRAY_SIZE(mvebu_comphy_cp110_modes);
+	/* Ignore PCIe submode: it represents the width */
+	bool ignore_submode = (mode == PHY_MODE_PCIE);
 	const struct mvebu_comphy_conf *conf;
 
 	/* Unused PHY mux value is 0x0 */
@@ -264,7 +280,7 @@ static int mvebu_comphy_get_mode(bool fw_mode, int lane, int port,
 		if (conf->lane == lane &&
 		    conf->port == port &&
 		    conf->mode == mode &&
-		    conf->submode == submode)
+		    (conf->submode == submode || ignore_submode))
 			break;
 	}
 
@@ -656,6 +672,13 @@ static int mvebu_comphy_power_on(struct phy *phy)
 		dev_dbg(priv->dev, "set lane %d to SATA mode\n", lane->id);
 		fw_param = COMPHY_FW_PARAM(fw_mode, lane->port);
 		break;
+	case PHY_MODE_PCIE:
+		hide_error = true;
+		dev_dbg(priv->dev, "set lane %d to PCIe mode (x%d)\n", lane->id,
+			lane->submode);
+		fw_param = COMPHY_FW_PARAM_PCIE(fw_mode, lane->port,
+						lane->submode);
+		break;
 	default:
 		dev_err(priv->dev, "unsupported PHY mode (%d)\n", lane->mode);
 		return -ENOTSUPP;
@@ -684,6 +707,11 @@ static int mvebu_comphy_set_mode(struct phy *phy,
 
 	lane->mode = mode;
 	lane->submode = submode;
+
+	/* PCIe submode represents the width */
+	if (mode == PHY_MODE_PCIE && !lane->submode)
+		lane->submode = 1;
+
 	return 0;
 }
 
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 11/15] phy: mvebu-cp110-comphy: Update comment about powering off all lanes at boot

[Miquel Raynal]

Now that all COMPHY modes are supported by the driver, update the
comment stating that mvebu_comphy_power_off() should be called for
each lane. This is still wrong because for compatibility reasons, it
might break users running an old firmware (the driver only uses SMC
calls for SATA, USB and PCIe configuration, there is no code in Linux
to fallback on in these cases.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index d66412b38ff7..6f6c26c1c622 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -841,9 +841,11 @@ static int mvebu_comphy_probe(struct platform_device *pdev)
 		phy_set_drvdata(phy, lane);
 
 		/*
-		 * Once all modes are supported in this driver we should call
+		 * All modes are supported in this driver so we could call
 		 * mvebu_comphy_power_off(phy) here to avoid relying on the
-		 * bootloader/firmware configuration.
+		 * bootloader/firmware configuration, but for compatibility
+		 * reasons we cannot de-configure the COMPHY without being sure
+		 * that the firmware is up-to-date and fully-featured.
 		 */
 	}
 
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 12/15] arm64: dts: marvell: Add 7k/8k per-port PHYs in SATA nodes

[Miquel Raynal]

Fill-in the missing SATA phys/phy-names DT properties of Armada 7k/8k
based boards.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 arch/arm64/boot/dts/marvell/armada-7040-db.dts |  5 +++++
 .../dts/marvell/armada-8040-clearfog-gt-8k.dts |  5 +++++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts | 18 ++++++++++++++++++
 .../boot/dts/marvell/armada-8040-mcbin.dtsi    | 18 ++++++++++++++++--
 4 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index d20d84ce7ca8..0ece9d5b16b4 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -191,6 +191,11 @@
 
 &cp0_sata0 {
 	status = "okay";
+
+	sata-port@1 {
+		phys = <&cp0_comphy3 1>;
+		phy-names = "cp0-sata1-phy";
+	};
 };
 
 &cp0_usb3_0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
index 2468762283a5..4ee063d2b16d 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
@@ -336,6 +336,11 @@
 &cp1_sata0 {
 	pinctrl-0 = <&cp0_pci1_reset_pins>;
 	status = "okay";
+
+	sata-port@1 {
+		phys = <&cp1_comphy0 1>;
+		phy-names = "cp1-sata1-phy";
+	};
 };
 
 &cp1_mdio {
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index 9f4f939ab65f..a2e75609b1ad 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -146,6 +146,15 @@
 /* CON4 on CP0 expansion */
 &cp0_sata0 {
 	status = "okay";
+
+	sata-port@0 {
+		phys = <&cp0_comphy1 0>;
+		phy-names = "cp0-sata0-phy";
+	};
+	sata-port@1 {
+		phys = <&cp0_comphy3 1>;
+		phy-names = "cp0-sata1-phy";
+	};
 };
 
 /* CON9 on CP0 expansion */
@@ -276,6 +285,15 @@
 /* CON4 on CP1 expansion */
 &cp1_sata0 {
 	status = "okay";
+
+	sata-port@0 {
+		phys = <&cp1_comphy1 0>;
+		phy-names = "cp1-sata0-phy";
+	};
+	sata-port@1 {
+		phys = <&cp1_comphy3 1>;
+		phy-names = "cp1-sata1-phy";
+	};
 };
 
 /* CON9 on CP1 expansion */
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
index 329f8ceeebea..28d380769506 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
@@ -237,8 +237,13 @@
 };
 
 &cp0_sata0 {
-	/* CPM Lane 0 - U29 */
+	/* CPM Lane 5 - U29 */
 	status = "okay";
+
+	sata-port@1 {
+		phys = <&cp0_comphy5 1>;
+		phy-names = "cp0-sata1-phy";
+	};
 };
 
 &cp0_sdhci0 {
@@ -322,9 +327,18 @@
 };
 
 &cp1_sata0 {
+	status = "okay";
+
 	/* CPS Lane 1 - U32 */
+	sata-port@0 {
+		phys = <&cp1_comphy1 0>;
+		phy-names = "cp1-sata0-phy";
+	};
 	/* CPS Lane 3 - U31 */
-	status = "okay";
+	sata-port@1 {
+		phys = <&cp1_comphy3 1>;
+		phy-names = "cp1-sata1-phy";
+	};
 };
 
 &cp1_spi1 {
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 13/15] arm64: dts: marvell: Add 7k/8k PHYs in USB3 nodes

[Miquel Raynal]

Fill-in the missing USB3 phys/phy-names DT properties of Armada 7k/8k
based boards. Only update nodes actually enabling USB3 in the default
(mainline) configuration. A few USB nodes are enabled but there is
only USB2 working on them.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 arch/arm64/boot/dts/marvell/armada-7040-db.dts             | 4 ++++
 arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts | 2 ++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts             | 2 ++
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi         | 2 ++
 4 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 0ece9d5b16b4..09e1805565c8 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -200,11 +200,15 @@
 
 &cp0_usb3_0 {
 	usb-phy = <&cp0_usb3_0_phy>;
+	phys = <&cp0_comphy1 0>;
+	phy-names = "cp0-usb3h0-comphy";
 	status = "okay";
 };
 
 &cp0_usb3_1 {
 	usb-phy = <&cp0_usb3_1_phy>;
+	phys = <&cp0_comphy4 1>;
+	phy-names = "cp0-usb3h1-comphy";
 	status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
index 4ee063d2b16d..04e64743de14 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
@@ -462,5 +462,7 @@
 
 &cp1_usb3_0 {
 	usb-phy = <&usb3h0_phy>;
+	phys = <&cp1_comphy2 0>;
+	phy-names = "cp1-usb3h0-comphy";
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index a2e75609b1ad..057af4ea2570 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -166,6 +166,8 @@
 /* CON10 on CP0 expansion */
 &cp0_usb3_1 {
 	usb-phy = <&cp0_usb3_1_phy>;
+	phys = <&cp0_comphy4 1>;
+	phy-names = "cp0-usb3h1-comphy";
 	status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
index 28d380769506..f0ead11cc5fa 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
@@ -356,5 +356,7 @@
 &cp1_usb3_0 {
 	/* CPS Lane 2 - CON7 */
 	usb-phy = <&usb3h0_phy>;
+	phys = <&cp1_comphy2 0>;
+	phy-names = "cp1-usb3h0-comphy";
 	status = "okay";
 };
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 14/15] arm64: dts: marvell: Add 7k/8k PHYs in PCIe nodes

[Miquel Raynal]

Fill-in the missing PCIe phys/phy-names DT properties of Armada 7k/8k
based boards.

The MacchiatoBin is a bit particular as the Armada8k-PCI IP supports
x4 link widths and in this case the PHY for each lane must be
referenced.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 arch/arm64/boot/dts/marvell/armada-7040-db.dts         |  2 ++
 .../boot/dts/marvell/armada-8040-clearfog-gt-8k.dts    |  2 ++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts         | 10 ++++++++++
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi     |  4 ++++
 4 files changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 09e1805565c8..131ce4229db0 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -96,6 +96,8 @@
 
 &cp0_pcie2 {
 	status = "okay";
+	phys = <&cp0_comphy5 2>;
+	phy-names = "cp0-pcie2-x1-phy";
 };
 
 &cp0_i2c0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
index 04e64743de14..b3716d206fbf 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
@@ -237,6 +237,8 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&cp0_pci0_reset_pins>;
 	reset-gpios = <&cp0_gpio2 0 GPIO_ACTIVE_LOW>;
+	phys = <&cp0_comphy0 0>;
+	phy-names = "cp0-pcie0-x1-phy";
 	status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index 057af4ea2570..91c51188650a 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -111,11 +111,15 @@
 
 /* CON6 on CP0 expansion */
 &cp0_pcie0 {
+	phys = <&cp0_comphy0 0>;
+	phy-names = "cp0-pcie0-x1-phy";
 	status = "okay";
 };
 
 /* CON5 on CP0 expansion */
 &cp0_pcie2 {
+	phys = <&cp0_comphy5 2>;
+	phy-names = "cp0-pcie2-x1-phy";
 	status = "okay";
 };
 
@@ -201,16 +205,22 @@
 
 /* CON6 on CP1 expansion */
 &cp1_pcie0 {
+	phys = <&cp1_comphy0 0>;
+	phy-names = "cp1-pcie0-x1-phy";
 	status = "okay";
 };
 
 /* CON7 on CP1 expansion */
 &cp1_pcie1 {
+	phys = <&cp1_comphy4 1>;
+	phy-names = "cp1-pcie1-x1-phy";
 	status = "okay";
 };
 
 /* CON5 on CP1 expansion */
 &cp1_pcie2 {
+	phys = <&cp1_comphy5 2>;
+	phy-names = "cp1-pcie2-x1-phy";
 	status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
index f0ead11cc5fa..0639437ab4b4 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
@@ -184,6 +184,10 @@
 	num-lanes = <4>;
 	num-viewport = <8>;
 	reset-gpios = <&cp0_gpio2 20 GPIO_ACTIVE_LOW>;
+	phys = <&cp0_comphy0 0>, <&cp0_comphy1 0>,
+	       <&cp0_comphy2 0>, <&cp0_comphy3 0>;
+	phy-names = "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy",
+		    "cp0-pcie0-x4-lane2-phy", "cp0-pcie0-x4-lane3-phy";
 	status = "okay";
 };
 
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 15/15] arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply

[Miquel Raynal]

Update Aramda 7k/8k DTs to use the phy-supply property of the (recent)
generic PHY framework instead of the (legacy) usb-phy preperty. Both
enable the supply when the PHY is enabled.

The COMPHY nodes only provide SERDES lanes configuration. The power
supply that is represented by the phy-supply property is just a
regulator wired to the USB connector, hence the creation of connector
nodes as child of the COMPHY nodes and the supply attached to it.

Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 .../arm64/boot/dts/marvell/armada-7040-db.dts | 26 ++++++++++---------
 .../marvell/armada-8040-clearfog-gt-8k.dts    | 13 +++++-----
 .../arm64/boot/dts/marvell/armada-8040-db.dts | 13 +++++-----
 .../boot/dts/marvell/armada-8040-mcbin.dtsi   | 13 +++++-----
 4 files changed, 35 insertions(+), 30 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 131ce4229db0..4b8df359b1cc 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -45,16 +45,6 @@
 		enable-active-high;
 		gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
 	};
-
-	cp0_usb3_0_phy: cp0-usb3-0-phy {
-		compatible = "usb-nop-xceiv";
-		vcc-supply = <&cp0_reg_usb3_0_vbus>;
-	};
-
-	cp0_usb3_1_phy: cp0-usb3-1-phy {
-		compatible = "usb-nop-xceiv";
-		vcc-supply = <&cp0_reg_usb3_1_vbus>;
-	};
 };
 
 &i2c0 {
@@ -200,15 +190,27 @@
 	};
 };
 
+&cp0_comphy1 {
+	cp0_usbh0_con: connector {
+		compatible = "usb-a-connector";
+		phy-supply = <&cp0_reg_usb3_0_vbus>;
+	};
+};
+
 &cp0_usb3_0 {
-	usb-phy = <&cp0_usb3_0_phy>;
 	phys = <&cp0_comphy1 0>;
 	phy-names = "cp0-usb3h0-comphy";
 	status = "okay";
 };
 
+&cp0_comphy4 {
+	cp0_usbh1_con: connector {
+		compatible = "usb-a-connector";
+		phy-supply = <&cp0_reg_usb3_1_vbus>;
+	};
+};
+
 &cp0_usb3_1 {
-	usb-phy = <&cp0_usb3_1_phy>;
 	phys = <&cp0_comphy4 1>;
 	phy-names = "cp0-usb3h1-comphy";
 	status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
index b3716d206fbf..58b7e859b61d 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
@@ -51,11 +51,6 @@
 		status = "okay";
 	};
 
-	usb3h0_phy: usb3_phy0 {
-		compatible = "usb-nop-xceiv";
-		vcc-supply = <&v_5v0_usb3_hst_vbus>;
-	};
-
 	sfp_cp0_eth0: sfp-cp0-eth0 {
 		compatible = "sff,sfp";
 		i2c-bus = <&cp0_i2c1>;
@@ -462,8 +457,14 @@
 	};
 };
 
+&cp1_comphy2 {
+	cp1_usbh0_con: connector {
+		compatible = "usb-a-connector";
+		phy-supply = <&v_5v0_usb3_hst_vbus>;
+	};
+};
+
 &cp1_usb3_0 {
-	usb-phy = <&usb3h0_phy>;
 	phys = <&cp1_comphy2 0>;
 	phy-names = "cp1-usb3h0-comphy";
 	status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index 91c51188650a..f73cb3a96393 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -52,11 +52,6 @@
 		vcc-supply = <&cp0_reg_usb3_0_vbus>;
 	};
 
-	cp0_usb3_1_phy: cp0-usb3-1-phy {
-		compatible = "usb-nop-xceiv";
-		vcc-supply = <&cp0_reg_usb3_1_vbus>;
-	};
-
 	cp1_reg_usb3_0_vbus: cp1-usb3-0-vbus {
 		compatible = "regulator-fixed";
 		regulator-name = "cp1-usb3h0-vbus";
@@ -167,9 +162,15 @@
 	status = "okay";
 };
 
+&cp0_comphy4 {
+	cp0_usbh1_con: connector {
+		compatible = "usb-a-connector";
+		phy-supply = <&cp0_reg_usb3_1_vbus>;
+	};
+};
+
 /* CON10 on CP0 expansion */
 &cp0_usb3_1 {
-	usb-phy = <&cp0_usb3_1_phy>;
 	phys = <&cp0_comphy4 1>;
 	phy-names = "cp0-usb3h1-comphy";
 	status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
index 0639437ab4b4..061533589356 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
@@ -61,11 +61,6 @@
 		status = "okay";
 	};
 
-	usb3h0_phy: usb3_phy0 {
-		compatible = "usb-nop-xceiv";
-		vcc-supply = <&v_5v0_usb3_hst_vbus>;
-	};
-
 	sfp_eth0: sfp-eth0 {
 		/* CON15,16 - CPM lane 4 */
 		compatible = "sff,sfp";
@@ -357,9 +352,15 @@
 	};
 };
 
+&cp1_comphy2 {
+	cp1_usbh0_con: connector {
+		compatible = "usb-a-connector";
+		phy-supply = <&v_5v0_usb3_hst_vbus>;
+	};
+};
+
 &cp1_usb3_0 {
 	/* CPS Lane 2 - CON7 */
-	usb-phy = <&usb3h0_phy>;
 	phys = <&cp1_comphy2 0>;
 	phy-names = "cp1-usb3h0-comphy";
 	status = "okay";
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 04/15] phy: mvebu-cp110-comphy: Add RXAUI support

[Maxime Chevallier]

Hi Miquel,

On Mon,  1 Apr 2019 18:51:20 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:

>Add support for RXAUI mode by adding an entry in the COMPHY modes list.
>
>There is nothing more to handle besides avoiding to return an error to
>the caller: someone using a DT updated with the right 'phys' property
>with an old firmware would get an error when initializing the lanes in
>RXAUI mode, while it could have already been initialized by eg. the
>bootloader. It would prevent the interface to work with no reason.

However, this would mask-away errors that could occur when we have a
correct firmware and DT.

Maybe we should simply return the error, this mode isn't supported in
PPv2 yet so I don't expect this to break any existing setups.

Maxime

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 04/15] phy: mvebu-cp110-comphy: Add RXAUI support

[Miquel Raynal]

Hi Maxime,

Maxime Chevallier <maxime.chevallier@bootlin.com> wrote on Tue, 2 Apr
2019 10:43:49 +0200:

> Hi Miquel,
> 
> On Mon,  1 Apr 2019 18:51:20 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> 
> >Add support for RXAUI mode by adding an entry in the COMPHY modes list.
> >
> >There is nothing more to handle besides avoiding to return an error to
> >the caller: someone using a DT updated with the right 'phys' property
> >with an old firmware would get an error when initializing the lanes in
> >RXAUI mode, while it could have already been initialized by eg. the
> >bootloader. It would prevent the interface to work with no reason.  
> 
> However, this would mask-away errors that could occur when we have a
> correct firmware and DT.
> 
> Maybe we should simply return the error, this mode isn't supported in
> PPv2 yet so I don't expect this to break any existing setups.

I am fine with this approach too. I think this is acceptable for RXAUI
but not for the other SATA/USB3/PCIe modes which already work because
of U-Boot configuration (while RXAUI seems to not be configured
anyway).


Thanks,
Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/15] arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply

[Martin Blumenstingl]

Hi Miquel,

thank you for keeping me in the loop!

On Mon, Apr 1, 2019 at 6:52 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Update Aramda 7k/8k DTs to use the phy-supply property of the (recent)
> generic PHY framework instead of the (legacy) usb-phy preperty. Both
> enable the supply when the PHY is enabled.
>
> The COMPHY nodes only provide SERDES lanes configuration. The power
> supply that is represented by the phy-supply property is just a
> regulator wired to the USB connector, hence the creation of connector
> nodes as child of the COMPHY nodes and the supply attached to it.
shouldn't this also be reflected in the dt-bindings?

> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  .../arm64/boot/dts/marvell/armada-7040-db.dts | 26 ++++++++++---------
>  .../marvell/armada-8040-clearfog-gt-8k.dts    | 13 +++++-----
>  .../arm64/boot/dts/marvell/armada-8040-db.dts | 13 +++++-----
>  .../boot/dts/marvell/armada-8040-mcbin.dtsi   | 13 +++++-----
>  4 files changed, 35 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> index 131ce4229db0..4b8df359b1cc 100644
> --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> @@ -45,16 +45,6 @@
>                 enable-active-high;
>                 gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
>         };
> -
> -       cp0_usb3_0_phy: cp0-usb3-0-phy {
> -               compatible = "usb-nop-xceiv";
> -               vcc-supply = <&cp0_reg_usb3_0_vbus>;
> -       };
> -
> -       cp0_usb3_1_phy: cp0-usb3-1-phy {
> -               compatible = "usb-nop-xceiv";
> -               vcc-supply = <&cp0_reg_usb3_1_vbus>;
> -       };
>  };
>
>  &i2c0 {
> @@ -200,15 +190,27 @@
>         };
>  };
>
> +&cp0_comphy1 {
> +       cp0_usbh0_con: connector {
> +               compatible = "usb-a-connector";
> +               phy-supply = <&cp0_reg_usb3_0_vbus>;
> +       };
> +};
(disclaimer: I don't have any board with a marvell SoC, so I don't
understand how it works and I can't debug it)
I know about the "phy-supply" property inside the PHY node itself
(that would be cp0_comphy1 in this case).
The connector binding does not mention a phy-supply property:
Documentation/devicetree/bindings/connector/usb-connector.txt

I don't understand which driver enables the phy-supply when it's part
of a "connector" child-node.
do you have a hint where I should start looking?


Regards
Martin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/15] arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply

[Miquel Raynal]

Hi Martin,

Rob, a few questions for you below :)

Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote on Tue,
2 Apr 2019 21:35:26 +0200:

> Hi Miquel,
> 
> thank you for keeping me in the loop!
> 
> On Mon, Apr 1, 2019 at 6:52 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Update Aramda 7k/8k DTs to use the phy-supply property of the (recent)
> > generic PHY framework instead of the (legacy) usb-phy preperty. Both
> > enable the supply when the PHY is enabled.
> >
> > The COMPHY nodes only provide SERDES lanes configuration. The power
> > supply that is represented by the phy-supply property is just a
> > regulator wired to the USB connector, hence the creation of connector
> > nodes as child of the COMPHY nodes and the supply attached to it.  
> shouldn't this also be reflected in the dt-bindings?

I don't think it deserves an update in the bindings as this is just an
update for a better hardware representation. The COMPHY block is
already documented, the connector one too. I thought adding a connector
node in the COMPHY node was okay when I read Rob's answer to your
series as this has nothing to do with the IP itself but is just
describing how the board is built. Maybe Rob can confirm this?

> 
> > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> >  .../arm64/boot/dts/marvell/armada-7040-db.dts | 26 ++++++++++---------
> >  .../marvell/armada-8040-clearfog-gt-8k.dts    | 13 +++++-----
> >  .../arm64/boot/dts/marvell/armada-8040-db.dts | 13 +++++-----
> >  .../boot/dts/marvell/armada-8040-mcbin.dtsi   | 13 +++++-----
> >  4 files changed, 35 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > index 131ce4229db0..4b8df359b1cc 100644
> > --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > @@ -45,16 +45,6 @@
> >                 enable-active-high;
> >                 gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
> >         };
> > -
> > -       cp0_usb3_0_phy: cp0-usb3-0-phy {
> > -               compatible = "usb-nop-xceiv";
> > -               vcc-supply = <&cp0_reg_usb3_0_vbus>;
> > -       };
> > -
> > -       cp0_usb3_1_phy: cp0-usb3-1-phy {
> > -               compatible = "usb-nop-xceiv";
> > -               vcc-supply = <&cp0_reg_usb3_1_vbus>;
> > -       };
> >  };
> >
> >  &i2c0 {
> > @@ -200,15 +190,27 @@
> >         };
> >  };
> >
> > +&cp0_comphy1 {
> > +       cp0_usbh0_con: connector {
> > +               compatible = "usb-a-connector";
> > +               phy-supply = <&cp0_reg_usb3_0_vbus>;
> > +       };
> > +};  
> (disclaimer: I don't have any board with a marvell SoC, so I don't
> understand how it works and I can't debug it)
> I know about the "phy-supply" property inside the PHY node itself
> (that would be cp0_comphy1 in this case).
> The connector binding does not mention a phy-supply property:
> Documentation/devicetree/bindings/connector/usb-connector.txt

That's right, can Rob confirm that this is valid? If yes I can add an
optional "phy-supply" property there.

> I don't understand which driver enables the phy-supply when it's part
> of a "connector" child-node.
> do you have a hint where I should start looking?

I honestly have no idea, but apparently it works.


Thanks,
Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 02/15] phy: mvebu-cp110-comphy: Add SMC call support

[Grzegorz Jaszczyk]

Hi Miquel,

pon., 1 kwi 2019 o 18:52 Miquel Raynal <miquel.raynal@bootlin.com> napisał(a):
> +static int mvebu_comphy_power_on(struct phy *phy)
> +{
> +       struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> +       struct mvebu_comphy_priv *priv = lane->priv;
> +       u32 fw_param = 0;
> +       int fw_mode;
> +       int ret;
> +
> +       fw_mode = mvebu_comphy_get_fw_mode(lane->id, lane->port,
> +                                          lane->mode, lane->submode);
> +       if (fw_mode < 0)
> +               goto try_legacy;
> +
> +       /* Try SMC flow first */
> +       switch (lane->mode) {
> +       case PHY_MODE_ETHERNET:
> +               dev_dbg(priv->dev, "set lane %d to Ethernet mode\n", lane->id);
> +               switch (lane->submode) {
> +               case PHY_INTERFACE_MODE_SGMII:
> +               case PHY_INTERFACE_MODE_2500BASEX:
> +               case PHY_INTERFACE_MODE_10GKR:
> +                       fw_param = COMPHY_FW_PARAM(fw_mode, lane->port);

It seems it will not work for SGMII and 2500BASEX. It is because you
are setting max speed for all comphy modes inside COMPHY_FW_PARAM
macro which is wrong. Did you test it?
BTW can you point to some public temporary git branch where this
patchset can be found?

regards,
Grzegorz

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 02/15] phy: mvebu-cp110-comphy: Add SMC call support

[Miquel Raynal]

Hi Grzegorz,

Grzegorz Jaszczyk <jaz@semihalf.com> wrote on Wed, 3 Apr 2019 11:02:15
+0200:

> Hi Miquel,
> 
> pon., 1 kwi 2019 o 18:52 Miquel Raynal <miquel.raynal@bootlin.com> napisał(a):
> > +static int mvebu_comphy_power_on(struct phy *phy)
> > +{
> > +       struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> > +       struct mvebu_comphy_priv *priv = lane->priv;
> > +       u32 fw_param = 0;
> > +       int fw_mode;
> > +       int ret;
> > +
> > +       fw_mode = mvebu_comphy_get_fw_mode(lane->id, lane->port,
> > +                                          lane->mode, lane->submode);
> > +       if (fw_mode < 0)
> > +               goto try_legacy;
> > +
> > +       /* Try SMC flow first */
> > +       switch (lane->mode) {
> > +       case PHY_MODE_ETHERNET:
> > +               dev_dbg(priv->dev, "set lane %d to Ethernet mode\n", lane->id);
> > +               switch (lane->submode) {
> > +               case PHY_INTERFACE_MODE_SGMII:
> > +               case PHY_INTERFACE_MODE_2500BASEX:
> > +               case PHY_INTERFACE_MODE_10GKR:
> > +                       fw_param = COMPHY_FW_PARAM(fw_mode, lane->port);
> 
> It seems it will not work for SGMII and 2500BASEX. It is because you
> are setting max speed for all comphy modes inside COMPHY_FW_PARAM
> macro which is wrong. Did you test it?

I misread ATF implementation, I was sure the speed was derived from the
type and this parameter was useless. I'll do the modification.

> BTW can you point to some public temporary git branch where this
> patchset can be found?

Just pushed there if you want to take a look:
https://github.com/miquelraynal/linux.git marvell/5.1-rc1/cp110-comphy


Thanks for the review!
Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 02/15] phy: mvebu-cp110-comphy: Add SMC call support

[Russell King - ARM Linux admin]

On Mon, Apr 01, 2019 at 06:51:18PM +0200, Miquel Raynal wrote:
> Keep the exact same list of supported configurations but first try to
> use the firmware's implementation. If it fails, try the legacy method:
> Linux implementation.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 200 +++++++++++++++----
>  1 file changed, 164 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> index 3f50a1521f01..4aaf161503d6 100644
> --- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> @@ -5,6 +5,7 @@
>   * Antoine Tenart <antoine.tenart@free-electrons.com>
>   */
>  
> +#include <linux/arm-smccc.h>
>  #include <linux/io.h>
>  #include <linux/iopoll.h>
>  #include <linux/mfd/syscon.h>
> @@ -115,51 +116,88 @@
>  #define MVEBU_COMPHY_LANES	6
>  #define MVEBU_COMPHY_PORTS	3
>  
> +#define COMPHY_SIP_POWER_ON	0x82000001
> +#define COMPHY_SIP_POWER_OFF	0x82000002
> +
> +/*
> + * A lane is described by the following bitfields:
> + * [ 1- 0]: COMPHY polarity invertion
> + * [ 2- 7]: COMPHY speed
> + * [ 5-11]: COMPHY port index
> + * [12-16]: COMPHY mode
> + * [17]: Clock source
> + */
> +#define COMPHY_FW_POL_OFFSET	0
> +#define COMPHY_FW_POL_MASK	GENMASK(1, 0)
> +#define COMPHY_FW_SPEED_OFFSET	2
> +#define COMPHY_FW_SPEED_MASK	GENMASK(7, 2)
> +#define COMPHY_FW_SPEED_MAX	COMPHY_FW_SPEED_MASK
> +#define COMPHY_FW_PORT_OFFSET	8
> +#define COMPHY_FW_PORT_MASK	GENMASK(11, 8)
> +#define COMPHY_FW_MODE_OFFSET	12
> +#define COMPHY_FW_MODE_MASK	GENMASK(16, 12)
> +
> +#define COMPHY_FW_PARAM_FULL(mode, port, speed, pol)			\
> +	((((pol) << COMPHY_FW_POL_OFFSET) & COMPHY_FW_POL_MASK) |	\
> +	 (((mode) << COMPHY_FW_MODE_OFFSET) & COMPHY_FW_MODE_MASK) |	\
> +	 (((port) << COMPHY_FW_PORT_OFFSET) & COMPHY_FW_PORT_MASK) |	\
> +	 (((speed) << COMPHY_FW_SPEED_OFFSET) & COMPHY_FW_SPEED_MASK))
> +
> +#define COMPHY_FW_PARAM(mode, port)					\
> +	COMPHY_FW_PARAM_FULL(mode, port, COMPHY_FW_SPEED_MAX, 0)
> +
> +#define COMPHY_FW_MODE_SGMII		0x2 /* SGMII 1G */
> +#define COMPHY_FW_MODE_HS_SGMII		0x3 /* SGMII 2.5G */
> +#define COMPHY_FW_MODE_SFI		0x9 /* XFI: 0x8 (is treated like SFI) */
> +
>  struct mvebu_comphy_conf {
>  	enum phy_mode mode;
>  	int submode;
>  	unsigned lane;
>  	unsigned port;
>  	u32 mux;
> +	u32 fw_mode;
>  };
>  
> -#define MVEBU_COMPHY_CONF(_lane, _port, _submode, _mux)	\
> +#define MVEBU_COMPHY_CONF(_lane, _port, _submode, _mux, _fw)	\
>  	{						\
>  		.lane = _lane,				\
>  		.port = _port,				\
>  		.mode = PHY_MODE_ETHERNET,		\
>  		.submode = _submode,			\
>  		.mux = _mux,				\
> +		.fw_mode = _fw,				\
>  	}
>  
>  static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
>  	/* lane 0 */
> -	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1),
> -	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> +	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
> +	MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
>  	/* lane 1 */
> -	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1),
> -	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> +	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
> +	MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
>  	/* lane 2 */
> -	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1),
> -	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> -	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1),
> +	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
> +	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
> +	MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1, COMPHY_FW_MODE_SFI),
>  	/* lane 3 */
> -	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2),
> -	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2),
> +	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
> +	MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
>  	/* lane 4 */
> -	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2),
> -	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2),
> -	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2),
> -	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1),
> +	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2, COMPHY_FW_MODE_SGMII),
> +	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2, COMPHY_FW_MODE_HS_SGMII),
> +	MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2, COMPHY_FW_MODE_SFI),
> +	MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
>  	/* lane 5 */
> -	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1),
> -	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> +	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1, COMPHY_FW_MODE_SGMII),
> +	MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1, COMPHY_FW_MODE_HS_SGMII),
>  };
>  
>  struct mvebu_comphy_priv {
>  	void __iomem *base;
>  	struct regmap *regmap;
>  	struct device *dev;
> +	unsigned long cp_phys;
>  };
>  
>  struct mvebu_comphy_lane {
> @@ -170,8 +208,18 @@ struct mvebu_comphy_lane {
>  	int port;
>  };
>  
> -static int mvebu_comphy_get_mux(int lane, int port,
> -				enum phy_mode mode, int submode)
> +static int mvebu_comphy_smc(unsigned long function, unsigned long phys,
> +			    unsigned long lane, unsigned long mode)
> +{
> +	struct arm_smccc_res res;
> +
> +	arm_smccc_smc(function, phys, lane, mode, 0, 0, 0, 0, &res);

Before we switch to using the ATF implementation, I have serious
concerns about the API here.  The physical address is passed from
the kernel to ATF for the hardware, and ATF does very little
validation of that address.

This means that it's trivially possible to overrun arrays in ATF,
and even get ATF to read/write other areas of memory.

I would rather this issue was resolved before the kernel starts to
use what is a badly defined interface.

> +
> +	return res.a0;
> +}
> +
> +static int mvebu_comphy_get_mode(bool fw_mode, int lane, int port,
> +				 enum phy_mode mode, int submode)
>  {
>  	int i, n = ARRAY_SIZE(mvebu_comphy_cp110_modes);
>  
> @@ -190,7 +238,22 @@ static int mvebu_comphy_get_mux(int lane, int port,
>  	if (i == n)
>  		return -EINVAL;
>  
> -	return mvebu_comphy_cp110_modes[i].mux;
> +	if (fw_mode)
> +		return mvebu_comphy_cp110_modes[i].fw_mode;
> +	else
> +		return mvebu_comphy_cp110_modes[i].mux;
> +}
> +
> +static inline int mvebu_comphy_get_mux(int lane, int port,
> +				       enum phy_mode mode, int submode)
> +{
> +	return mvebu_comphy_get_mode(false, lane, port, mode, submode);
> +}
> +
> +static inline int mvebu_comphy_get_fw_mode(int lane, int port,
> +					   enum phy_mode mode, int submode)
> +{
> +	return mvebu_comphy_get_mode(true, lane, port, mode, submode);
>  }
>  
>  static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane)
> @@ -476,7 +539,7 @@ static int mvebu_comphy_set_mode_10gkr(struct phy *phy)
>  	return mvebu_comphy_init_plls(lane);
>  }
>  
> -static int mvebu_comphy_power_on(struct phy *phy)
> +static int mvebu_comphy_power_on_legacy(struct phy *phy)
>  {
>  	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
>  	struct mvebu_comphy_priv *priv = lane->priv;
> @@ -517,6 +580,50 @@ static int mvebu_comphy_power_on(struct phy *phy)
>  	return ret;
>  }
>  
> +static int mvebu_comphy_power_on(struct phy *phy)
> +{
> +	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> +	struct mvebu_comphy_priv *priv = lane->priv;
> +	u32 fw_param = 0;
> +	int fw_mode;
> +	int ret;
> +
> +	fw_mode = mvebu_comphy_get_fw_mode(lane->id, lane->port,
> +					   lane->mode, lane->submode);
> +	if (fw_mode < 0)
> +		goto try_legacy;
> +
> +	/* Try SMC flow first */
> +	switch (lane->mode) {
> +	case PHY_MODE_ETHERNET:
> +		dev_dbg(priv->dev, "set lane %d to Ethernet mode\n", lane->id);
> +		switch (lane->submode) {
> +		case PHY_INTERFACE_MODE_SGMII:
> +		case PHY_INTERFACE_MODE_2500BASEX:
> +		case PHY_INTERFACE_MODE_10GKR:
> +			fw_param = COMPHY_FW_PARAM(fw_mode, lane->port);
> +			break;
> +		default:
> +			dev_err(priv->dev, "unsupported Ethernet mode (%d)\n",
> +				lane->submode);
> +			return -ENOTSUPP;
> +		}
> +		break;
> +	default:
> +		dev_err(priv->dev, "unsupported PHY mode (%d)\n", lane->mode);
> +		return -ENOTSUPP;
> +	}
> +
> +	ret = mvebu_comphy_smc(COMPHY_SIP_POWER_ON, priv->cp_phys, lane->id,
> +			       fw_param);
> +	if (!ret)
> +		return ret;
> +
> +try_legacy:
> +	/* Fallback to Linux's implementation */
> +	return mvebu_comphy_power_on_legacy(phy);
> +}
> +
>  static int mvebu_comphy_set_mode(struct phy *phy,
>  				 enum phy_mode mode, int submode)
>  {
> @@ -528,7 +635,7 @@ static int mvebu_comphy_set_mode(struct phy *phy,
>  	if (submode == PHY_INTERFACE_MODE_1000BASEX)
>  		submode = PHY_INTERFACE_MODE_SGMII;
>  
> -	if (mvebu_comphy_get_mux(lane->id, lane->port, mode, submode) < 0)
> +	if (mvebu_comphy_get_fw_mode(lane->id, lane->port, mode, submode) < 0)
>  		return -EINVAL;
>  
>  	lane->mode = mode;
> @@ -536,27 +643,42 @@ static int mvebu_comphy_set_mode(struct phy *phy,
>  	return 0;
>  }
>  
> +static int mvebu_comphy_power_off_legacy(struct phy *phy)
> +{
> +	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> +	struct mvebu_comphy_priv *priv = lane->priv;
> +	u32 val;
> +
> +	val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +	val &= ~(MVEBU_COMPHY_SERDES_CFG1_RESET |
> +		 MVEBU_COMPHY_SERDES_CFG1_CORE_RESET |
> +		 MVEBU_COMPHY_SERDES_CFG1_RF_RESET);
> +	writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +
> +	regmap_read(priv->regmap, MVEBU_COMPHY_SELECTOR, &val);
> +	val &= ~(0xf << MVEBU_COMPHY_SELECTOR_PHY(lane->id));
> +	regmap_write(priv->regmap, MVEBU_COMPHY_SELECTOR, val);
> +
> +	regmap_read(priv->regmap, MVEBU_COMPHY_PIPE_SELECTOR, &val);
> +	val &= ~(0xf << MVEBU_COMPHY_PIPE_SELECTOR_PIPE(lane->id));
> +	regmap_write(priv->regmap, MVEBU_COMPHY_PIPE_SELECTOR, val);
> +
> +	return 0;
> +}
> +
>  static int mvebu_comphy_power_off(struct phy *phy)
>  {
>  	struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
>  	struct mvebu_comphy_priv *priv = lane->priv;
> -	u32 val;
> +	int ret;
>  
> -	val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> -	val &= ~(MVEBU_COMPHY_SERDES_CFG1_RESET |
> -		 MVEBU_COMPHY_SERDES_CFG1_CORE_RESET |
> -		 MVEBU_COMPHY_SERDES_CFG1_RF_RESET);
> -	writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +	ret = mvebu_comphy_smc(COMPHY_SIP_POWER_OFF, priv->cp_phys,
> +			       lane->id, 0);
> +	if (!ret)
> +		return ret;
>  
> -	regmap_read(priv->regmap, MVEBU_COMPHY_SELECTOR, &val);
> -	val &= ~(0xf << MVEBU_COMPHY_SELECTOR_PHY(lane->id));
> -	regmap_write(priv->regmap, MVEBU_COMPHY_SELECTOR, val);
> -
> -	regmap_read(priv->regmap, MVEBU_COMPHY_PIPE_SELECTOR, &val);
> -	val &= ~(0xf << MVEBU_COMPHY_PIPE_SELECTOR_PIPE(lane->id));
> -	regmap_write(priv->regmap, MVEBU_COMPHY_PIPE_SELECTOR, val);
> -
> -	return 0;
> +	/* Fallback to Linux's implementation */
> +	return mvebu_comphy_power_off_legacy(phy);
>  }
>  
>  static const struct phy_ops mvebu_comphy_ops = {
> @@ -607,6 +729,12 @@ static int mvebu_comphy_probe(struct platform_device *pdev)
>  	if (IS_ERR(priv->base))
>  		return PTR_ERR(priv->base);
>  
> +	/*
> +	 * Hack to retrieve a physical offset relative to this CP that will be
> +	 * given to the firmware
> +	 */
> +	priv->cp_phys = res->start;
> +
>  	for_each_available_child_of_node(pdev->dev.of_node, child) {
>  		struct mvebu_comphy_lane *lane;
>  		struct phy *phy;
> -- 
> 2.19.1
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/15] arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply

[Miquel Raynal]

Hi Rob,

Gentle ping on the questions below, if you have some time to check.

Thank you very much,
Miquèl

Miquel Raynal <miquel.raynal@bootlin.com> wrote on Wed, 3 Apr 2019
10:06:42 +0200:

> Hi Martin,
> 
> Rob, a few questions for you below :)
> 
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote on Tue,
> 2 Apr 2019 21:35:26 +0200:
> 
> > Hi Miquel,
> > 
> > thank you for keeping me in the loop!
> > 
> > On Mon, Apr 1, 2019 at 6:52 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > >
> > > Update Aramda 7k/8k DTs to use the phy-supply property of the (recent)
> > > generic PHY framework instead of the (legacy) usb-phy preperty. Both
> > > enable the supply when the PHY is enabled.
> > >
> > > The COMPHY nodes only provide SERDES lanes configuration. The power
> > > supply that is represented by the phy-supply property is just a
> > > regulator wired to the USB connector, hence the creation of connector
> > > nodes as child of the COMPHY nodes and the supply attached to it.    
> > shouldn't this also be reflected in the dt-bindings?  
> 
> I don't think it deserves an update in the bindings as this is just an
> update for a better hardware representation. The COMPHY block is
> already documented, the connector one too. I thought adding a connector
> node in the COMPHY node was okay when I read Rob's answer to your
> series as this has nothing to do with the IP itself but is just
> describing how the board is built. Maybe Rob can confirm this?
> 
> >   
> > > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > >  .../arm64/boot/dts/marvell/armada-7040-db.dts | 26 ++++++++++---------
> > >  .../marvell/armada-8040-clearfog-gt-8k.dts    | 13 +++++-----
> > >  .../arm64/boot/dts/marvell/armada-8040-db.dts | 13 +++++-----
> > >  .../boot/dts/marvell/armada-8040-mcbin.dtsi   | 13 +++++-----
> > >  4 files changed, 35 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > > index 131ce4229db0..4b8df359b1cc 100644
> > > --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > > +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > > @@ -45,16 +45,6 @@
> > >                 enable-active-high;
> > >                 gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
> > >         };
> > > -
> > > -       cp0_usb3_0_phy: cp0-usb3-0-phy {
> > > -               compatible = "usb-nop-xceiv";
> > > -               vcc-supply = <&cp0_reg_usb3_0_vbus>;
> > > -       };
> > > -
> > > -       cp0_usb3_1_phy: cp0-usb3-1-phy {
> > > -               compatible = "usb-nop-xceiv";
> > > -               vcc-supply = <&cp0_reg_usb3_1_vbus>;
> > > -       };
> > >  };
> > >
> > >  &i2c0 {
> > > @@ -200,15 +190,27 @@
> > >         };
> > >  };
> > >
> > > +&cp0_comphy1 {
> > > +       cp0_usbh0_con: connector {
> > > +               compatible = "usb-a-connector";
> > > +               phy-supply = <&cp0_reg_usb3_0_vbus>;
> > > +       };
> > > +};    
> > (disclaimer: I don't have any board with a marvell SoC, so I don't
> > understand how it works and I can't debug it)
> > I know about the "phy-supply" property inside the PHY node itself
> > (that would be cp0_comphy1 in this case).
> > The connector binding does not mention a phy-supply property:
> > Documentation/devicetree/bindings/connector/usb-connector.txt  
> 
> That's right, can Rob confirm that this is valid? If yes I can add an
> optional "phy-supply" property there.
> 
> > I don't understand which driver enables the phy-supply when it's part
> > of a "connector" child-node.
> > do you have a hint where I should start looking?  
> 
> I honestly have no idea, but apparently it works.
> 
> 
> Thanks,
> Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/15] arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply

[Martin Blumenstingl]

Hi Miquel,

On Mon, Apr 8, 2019 at 10:51 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Rob,
>
> Gentle ping on the questions below, if you have some time to check.
>
> Thank you very much,
> Miquèl
>
> Miquel Raynal <miquel.raynal@bootlin.com> wrote on Wed, 3 Apr 2019
> 10:06:42 +0200:
>
> > Hi Martin,
> >
> > Rob, a few questions for you below :)
> >
> > Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote on Tue,
> > 2 Apr 2019 21:35:26 +0200:
> >
> > > Hi Miquel,
> > >
> > > thank you for keeping me in the loop!
> > >
> > > On Mon, Apr 1, 2019 at 6:52 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Update Aramda 7k/8k DTs to use the phy-supply property of the (recent)
> > > > generic PHY framework instead of the (legacy) usb-phy preperty. Both
> > > > enable the supply when the PHY is enabled.
> > > >
> > > > The COMPHY nodes only provide SERDES lanes configuration. The power
> > > > supply that is represented by the phy-supply property is just a
> > > > regulator wired to the USB connector, hence the creation of connector
> > > > nodes as child of the COMPHY nodes and the supply attached to it.
> > > shouldn't this also be reflected in the dt-bindings?
> >
> > I don't think it deserves an update in the bindings as this is just an
> > update for a better hardware representation. The COMPHY block is
> > already documented, the connector one too. I thought adding a connector
> > node in the COMPHY node was okay when I read Rob's answer to your
> > series as this has nothing to do with the IP itself but is just
> > describing how the board is built. Maybe Rob can confirm this?
> >
> > >
> > > > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > > >  .../arm64/boot/dts/marvell/armada-7040-db.dts | 26 ++++++++++---------
> > > >  .../marvell/armada-8040-clearfog-gt-8k.dts    | 13 +++++-----
> > > >  .../arm64/boot/dts/marvell/armada-8040-db.dts | 13 +++++-----
> > > >  .../boot/dts/marvell/armada-8040-mcbin.dtsi   | 13 +++++-----
> > > >  4 files changed, 35 insertions(+), 30 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > > > index 131ce4229db0..4b8df359b1cc 100644
> > > > --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > > > +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> > > > @@ -45,16 +45,6 @@
> > > >                 enable-active-high;
> > > >                 gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
> > > >         };
> > > > -
> > > > -       cp0_usb3_0_phy: cp0-usb3-0-phy {
> > > > -               compatible = "usb-nop-xceiv";
> > > > -               vcc-supply = <&cp0_reg_usb3_0_vbus>;
> > > > -       };
> > > > -
> > > > -       cp0_usb3_1_phy: cp0-usb3-1-phy {
> > > > -               compatible = "usb-nop-xceiv";
> > > > -               vcc-supply = <&cp0_reg_usb3_1_vbus>;
> > > > -       };
> > > >  };
> > > >
> > > >  &i2c0 {
> > > > @@ -200,15 +190,27 @@
> > > >         };
> > > >  };
> > > >
> > > > +&cp0_comphy1 {
> > > > +       cp0_usbh0_con: connector {
> > > > +               compatible = "usb-a-connector";
> > > > +               phy-supply = <&cp0_reg_usb3_0_vbus>;
> > > > +       };
> > > > +};
> > > (disclaimer: I don't have any board with a marvell SoC, so I don't
> > > understand how it works and I can't debug it)
> > > I know about the "phy-supply" property inside the PHY node itself
> > > (that would be cp0_comphy1 in this case).
> > > The connector binding does not mention a phy-supply property:
> > > Documentation/devicetree/bindings/connector/usb-connector.txt
> >
> > That's right, can Rob confirm that this is valid? If yes I can add an
> > optional "phy-supply" property there.
Icenowy (here: [0]) and Chunfeng (here: [1]) are working on this as
far as I can tell
Icenowy is parsing the "vbus-supply" regulator manually from within
the PHY driver, see [2]

the additional info from their patches doesn't fully answer my questions yet.
I CC'ed both to this mail hoping that they can provide additional
insight what the greater picture is (at least in terms of which driver
is controlling the USB VBUS signal) on Allwinner and Mediatek SoCs.


Regards
Martin


[0] https://patchwork.kernel.org/patch/10887839/
[1] https://patchwork.kernel.org/patch/10844251/
[2] https://patchwork.kernel.org/patch/10887841/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel