On 07/31/2014 03:55 PM, Simon Glass wrote:
On 31 July 2014 19:00, Stefan Agner <ste...@agner.ch> wrote:
Am 2014-07-31 19:41, schrieb Simon Glass:
On 31 July 2014 18:36, Stefan Agner <ste...@agner.ch> wrote:
This adds board support for the Toradex Colibri T30 module.
+/*
+ * Enable AX88772B USB to LAN controller
+ */
+void pin_mux_usb(void)
+{
+ /* Enable LAN_VBUS */
+ gpio_request(GPIO_PDD2, NULL);
+ gpio_direction_output(GPIO_PDD2, 1);
+
+ /* Reset ASIX using LAN_RESET */
+ gpio_request(GPIO_PDD0, NULL);
+ gpio_direction_output(GPIO_PDD0, 0);
+
+ udelay(5);
+
+ gpio_set_value(GPIO_PDD0, 1);
You are using device tree for sdhci - shouldn't we use it for USB also?
The Colibri T30 has a ASIX USB to Ethernet chip on its board. We
reset/power the ASIX here. It is a very board specific reset/powering,
hence I put it in here.
In my initial patches I had it in the nvidia,phy-reset-gpio and
nvidia,vbus-gpio properties. Technically, it would work to have this
GPIOs in the device tree as USB properties, but I think this would be
logically wrong...
For VBUS I think it would be correct to put it in the USB. For the
reset, I'm not sure - it looks like a separate pin so putting it in
the device tree for USB would be wrong I think.
What does the kernel do for these?
The kernel doesn't yet have a good answer to things like this, i.e. data
that's not directly driven by the requirements of a controller or
protocol, but rather the custom/out-of-band aspects of the device that's
connected to the controller.
So, a GPIO for VBUS is something very closely tied to the USB
specification, and basically any USB controller needs to represent and
handle it in the same way.
However, a GPIO to reset/enable a USB device is something completely
outside the scope of the USB specification, and is very device specific,
and there's currently no good answer re: how to handle it.
There have been various attempts to solve it such as a generic "power
sequences" DT binding, various proposals for a "slot" or "connector" or
"target device" binding, or even explicitly defining the attached device
in DT (even though it can be probed) and having the driver for that
handle all the HW-specific details. However these threads have
unfortunately all languished.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
