Re: [PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support
On Mon, Aug 25, 2014 at 9:22 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/18/2014 11:08 AM, Andrew Bresticker wrote: In addition to the PCIe and SATA PHYs, the XUSB pad controller also supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single PCIe or SATA lane and is mapped to one of the three UTMI ports. The xHCI controller will also send messages intended for the PHY driver, so request and listen for messages on the mailbox's PHY channel. I'd like a review from Thierry here as the HW expert. I need an ack from LinusW in order to take this pinctrl patch through the Tegra tree. Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support
On Mon, Aug 25, 2014 at 12:22 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
In addition to the PCIe and SATA PHYs, the XUSB pad controller also
supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single
PCIe or SATA lane and is mapped to one of the three UTMI ports.
The xHCI controller will also send messages intended for the PHY driver,
so request and listen for messages on the mailbox's PHY channel.
I'd like a review from Thierry here as the HW expert.
I need an ack from LinusW in order to take this pinctrl patch through the
Tegra tree.
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
b/drivers/pinctrl/pinctrl-tegra-xusb.c
+static int usb3_phy_power_on(struct phy *phy)
+{
+ struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+ int port = usb3_phy_to_port(phy);
+ int lane = padctl-usb3_ports[port].lane;
+ u32 value, offset;
+
+ if (!is_pcie_or_sata_lane(lane)) {
+ dev_err(padctl-dev, USB3 PHY %d mapped to invalid lane:
%d\n,
+ port, lane);
+ return -EINVAL;
+ }
An aside: This implies that the SATA driver should be talking to this
pinctrl driver and explicitly powering on the XUSB pins. However, the SATA
driver doesn't depend on this series. I'm a bit confused how that works.
Perhaps it's just by accident? Mikko, can you comment?
As Mikko mentioned, the enabling of the SATA lane in
usb3_phy_power_on() is for when the SATA lane is being used for USB3.
+static int utmi_phy_to_port(struct phy *phy)
+{
+ struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+ int i;
+
+ for (i = 0; i TEGRA_XUSB_UTMI_PHYS; i++) {
+ if (phy == padctl-phys[TEGRA_XUSB_PADCTL_UTMI_P0 + i])
+ break;
+ }
+ BUG_ON(i == TEGRA_XUSB_UTMI_PHYS);
Can this be triggered by e.g. bad DT content? If so, returning an error
would be nicer. The comment applies to other xxx_to_port() functions.
No, it cannot. The struct phy that's passed in here comes from the
PHY core and must be a PHY that we registered earlier in probe().
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support
On 25/08/14 22:22, Stephen Warren wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
In addition to the PCIe and SATA PHYs, the XUSB pad controller also
supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single
PCIe or SATA lane and is mapped to one of the three UTMI ports.
The xHCI controller will also send messages intended for the PHY driver,
so request and listen for messages on the mailbox's PHY channel.
I'd like a review from Thierry here as the HW expert.
I need an ack from LinusW in order to take this pinctrl patch through
the Tegra tree.
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
b/drivers/pinctrl/pinctrl-tegra-xusb.c
+static int usb3_phy_power_on(struct phy *phy)
+{
+struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+int port = usb3_phy_to_port(phy);
+int lane = padctl-usb3_ports[port].lane;
+u32 value, offset;
+
+if (!is_pcie_or_sata_lane(lane)) {
+dev_err(padctl-dev, USB3 PHY %d mapped to invalid lane: %d\n,
+port, lane);
+return -EINVAL;
+}
An aside: This implies that the SATA driver should be talking to this
pinctrl driver and explicitly powering on the XUSB pins. However, the
SATA driver doesn't depend on this series. I'm a bit confused how that
works. Perhaps it's just by accident? Mikko, can you comment?
The SATA driver does depend on the pinctrl-tegra-xusb driver to power on
the SATA lane. It looks like what this patch does is it adds support for
using the SATA pad for USB3, in which case the SATA lane also needs to
be powered on. At least that's the understanding I got from a quick read.
Mikko
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
In addition to the PCIe and SATA PHYs, the XUSB pad controller also
supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single
PCIe or SATA lane and is mapped to one of the three UTMI ports.
The xHCI controller will also send messages intended for the PHY driver,
so request and listen for messages on the mailbox's PHY channel.
I'd like a review from Thierry here as the HW expert.
I need an ack from LinusW in order to take this pinctrl patch through
the Tegra tree.
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
b/drivers/pinctrl/pinctrl-tegra-xusb.c
+static int usb3_phy_power_on(struct phy *phy)
+{
+ struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+ int port = usb3_phy_to_port(phy);
+ int lane = padctl-usb3_ports[port].lane;
+ u32 value, offset;
+
+ if (!is_pcie_or_sata_lane(lane)) {
+ dev_err(padctl-dev, USB3 PHY %d mapped to invalid lane: %d\n,
+ port, lane);
+ return -EINVAL;
+ }
An aside: This implies that the SATA driver should be talking to this
pinctrl driver and explicitly powering on the XUSB pins. However, the
SATA driver doesn't depend on this series. I'm a bit confused how that
works. Perhaps it's just by accident? Mikko, can you comment?
+static int utmi_phy_to_port(struct phy *phy)
+{
+ struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+ int i;
+
+ for (i = 0; i TEGRA_XUSB_UTMI_PHYS; i++) {
+ if (phy == padctl-phys[TEGRA_XUSB_PADCTL_UTMI_P0 + i])
+ break;
+ }
+ BUG_ON(i == TEGRA_XUSB_UTMI_PHYS);
Can this be triggered by e.g. bad DT content? If so, returning an error
would be nicer. The comment applies to other xxx_to_port() functions.
@@ -896,6 +1933,22 @@ static int tegra_xusb_padctl_probe(struct platform_device
*pdev)
+ for (i = 0; i TEGRA_XUSB_USB3_PHYS; i++) {
+ char prop[sizeof(nvidia,usb3-port-N-lane)];
+ u32 lane;
+
+ sprintf(prop, nvidia,usb3-port-%d-lane, i);
+ if (!of_property_read_u32(pdev-dev.of_node, prop, lane)) {
+ if (!is_pcie_or_sata_lane(lane)) {
+ err = -EINVAL;
+ goto unregister;
It'd be nice to print a message so that the user/developer knows what's
wrong with the DT.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support
In addition to the PCIe and SATA PHYs, the XUSB pad controller also supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single PCIe or SATA lane and is mapped to one of the three UTMI ports. The xHCI controller will also send messages intended for the PHY driver, so request and listen for messages on the mailbox's PHY channel. Signed-off-by: Andrew Bresticker abres...@chromium.org --- Changes from v1: - Updated to use common mailbox API. - Added SATA PHY enable sequence for USB3 ports using the SATA lane. - Made USB3 port-to-lane mappins a top-level binding rather than a pinconfig binding. --- drivers/pinctrl/Kconfig |1 + drivers/pinctrl/pinctrl-tegra-xusb.c | 1170 +- include/soc/tegra/xusb.h |7 + 3 files changed, 1150 insertions(+), 28 deletions(-) diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index bfd2c2e..d5bc4f5 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -265,6 +265,7 @@ config PINCTRL_TEGRA_XUSB select GENERIC_PHY select PINCONF select PINMUX + select MAILBOX config PINCTRL_TZ1090 bool Toumaz Xenif TZ1090 pin control driver diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c b/drivers/pinctrl/pinctrl-tegra-xusb.c index a066204..1091ce7 100644 --- a/drivers/pinctrl/pinctrl-tegra-xusb.c +++ b/drivers/pinctrl/pinctrl-tegra-xusb.c @@ -13,23 +13,53 @@ #include linux/delay.h #include linux/io.h +#include linux/mailbox_client.h #include linux/module.h #include linux/of.h #include linux/phy/phy.h #include linux/pinctrl/pinctrl.h #include linux/pinctrl/pinmux.h #include linux/platform_device.h +#include linux/regulator/consumer.h #include linux/reset.h +#include soc/tegra/fuse.h +#include soc/tegra/xusb.h + #include dt-bindings/pinctrl/pinctrl-tegra-xusb.h #include core.h #include pinctrl-utils.h +#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PADX_SHIFT(x) ((x) ? 15 : 0) +#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PAD_MASK 0x3f +#define FUSE_SKU_CALIB_HS_IREF_CAP_SHIFT 13 +#define FUSE_SKU_CALIB_HS_IREF_CAP_MASK 0x3 +#define FUSE_SKU_CALIB_HS_SQUELCH_LEVEL_SHIFT 11 +#define FUSE_SKU_CALIB_HS_SQUELCH_LEVEL_MASK 0x3 +#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_SHIFT 7 +#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_MASK 0xf + +#define XUSB_PADCTL_USB2_PORT_CAP 0x008 +#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_SHIFT(x) ((x) * 4) +#define XUSB_PADCTL_USB2_PORT_CAP_PORT_CAP_MASK 0x3 +#define XUSB_PADCTL_USB2_PORT_CAP_DISABLED 0x0 +#define XUSB_PADCTL_USB2_PORT_CAP_HOST 0x1 +#define XUSB_PADCTL_USB2_PORT_CAP_DEVICE 0x2 +#define XUSB_PADCTL_USB2_PORT_CAP_OTG 0x3 + +#define XUSB_PADCTL_SS_PORT_MAP 0x014 +#define XUSB_PADCTL_SS_PORT_MAP_PORTX_SHIFT(x) ((x) * 4) +#define XUSB_PADCTL_SS_PORT_MAP_PORT_MASK 0x7 + #define XUSB_PADCTL_ELPG_PROGRAM 0x01c #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_VCORE_DOWN (1 26) #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_CLAMP_EN_EARLY (1 25) #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_CLAMP_EN (1 24) +#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_VCORE_DOWN(x) (1 (18 + (x) * 4)) +#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_CLAMP_EN_EARLY(x) \ + (1 (17 + (x) * 4)) +#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_CLAMP_EN(x) (1 (16 + (x) * 4)) #define XUSB_PADCTL_IOPHY_PLL_P0_CTL1 0x040 #define XUSB_PADCTL_IOPHY_PLL_P0_CTL1_PLL0_LOCKDET (1 19) @@ -41,17 +71,136 @@ #define XUSB_PADCTL_IOPHY_PLL_P0_CTL2_TXCLKREF_EN (1 5) #define XUSB_PADCTL_IOPHY_PLL_P0_CTL2_TXCLKREF_SEL (1 4) +#define XUSB_PADCTL_IOPHY_USB3_PADX_CTL2(x) (0x058 + (x) * 4) +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_CDR_CNTL_SHIFT 24 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_CDR_CNTL_MASK 0xff +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_Z_SHIFT 16 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_Z_MASK 0x3f +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_G_SHIFT 8 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_G_MASK 0x3f +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_SHIFT 8 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_MASK 0x +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_WANDER_SHIFT 4 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_WANDER_MASK 0x7 + +#define XUSB_PADCTL_IOPHY_USB3_PADX_CTL4(x) (0x068 + (x) * 4) +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_TAP_SHIFT 24 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_TAP_MASK 0x1f +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_AMP_SHIFT 16 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_AMP_MASK 0x7f + +#define XUSB_PADCTL_IOPHY_MISC_PAD_PX_CTL2(x) ((x) 2 ? 0x078 + (x) * 4 : \ + 0x0f8 + (x) * 4) +#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL2_SPARE_IN_SHIFT 28 +#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL2_SPARE_IN_MASK 0x3 + +#define XUSB_PADCTL_IOPHY_MISC_PAD_PX_CTL5(x) ((x) 2 ? 0x090 + (x) * 4 : \ + 0x11c + (x) * 4) +#define
