On Thu, Jun 26, 2014 at 11:08 AM, Stephen Warren [off-list ref] wrote:

On 06/25/2014 05:30 PM, Andrew Bresticker wrote:

quoted

On Wed, Jun 25, 2014 at 3:12 PM, Stephen Warren [off-list ref] wrote:

quoted

On 06/18/2014 12:16 AM, Andrew Bresticker wrote:

quoted

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.

quoted

diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c b/drivers/pinctrl/pinctrl-tegra-xusb.c

quoted

@@ -372,6 +720,193 @@ static int tegra_xusb_padctl_pinconf_group_set(struct pinctrl_dev *pinctrl,
                      padctl_writel(padctl, regval, lane->offset);
                      break;

+             case TEGRA_XUSB_PADCTL_USB3_PORT_NUM:
+                     if (value >= TEGRA_XUSB_PADCTL_USB3_PORTS) {
+                             dev_err(padctl->dev, "Invalid USB3 port: %lu\n",
+                                     value);
+                             return -EINVAL;
+                     }
+                     if (!is_pcie_sata_lane(group)) {
+                             dev_err(padctl->dev,
+                                     "USB3 port not applicable for pin %d\n",
+                                     group);
+                             return -EINVAL;
+                     }
+                     padctl->usb3_ports[value].lane = group;
+                     break;

It feels odd to use pinctrl for a SW-only purpose. In other words, that
chunk of code isn't writing the pinconf data to HW, but rather some
internal variable.

Well the mapping of lanes to USB3 ports is a hardware property and we
do use it when programming the hardware later to choose which set of
lane registers to program given a USB3 port, but it's true that it's
not some value we program into HW directly.

quoted

Perhaps it would make more sense for the DT binding to represent this
data directly in a custom property that's parsed at probe() time. That
way, pinctrl only touches "real" HW stuff.

I'm on the fence about this.  If you or others feel strongly about
this then I can make it a separate DT property and move it out of the
pinctrl properties.

I'd certainly prefer to use pinctrl bindings only for things that get
directly written into HW. Other configuration data should be easy to
retrieve directly from properties.

Ok, I'll make a separate DT property for the USB3 port <-> lane
assignments then.