On 10-04-2014 15:14, David Laight wrote:
It doesn't do any pin muxing. It switches SoC internal USB
signals between
USB controllers. The pins remain the same.
Doesn't something like that already happen for the companion USB1
controllers for USB2 ports?
Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
Yes.
Why do you care which USB controller is driving the pins?
Because the controllers the driver switches between are not companions.
The multiplexing is between PCI EHCI/OHCI and Renesas USBHS (high speed device
controller in this case) controllers on port 0 and between PCI EHCI/OHCI and
non-PCI xHCI controller on port 2.
That also doesn't sound like you are changing the PHY.
I am changing one of the PHY registers that controls USB port
(Renesas calls it channel) multiplexing.
I'd have thought that would happen if you had a single controller
that select between multiply PHY.
No, it's not the case.
I realised that wasn't what you were doing, but at first it did seem
to be what you were doing.
The PHY really does belong to the USBHS controller but that multiplexing
register inside it controls routing of the ports 0 and 2; USBHS itself is on
port 0.
There is an interesting case, the USB3 shares a PHY with a SATA
and the PCIE and SATA also share a PHY on the R8A7790.
Some of those look like pcb design decisions - so there is no dynamic
changing, just config time plumbing.
No, there are also host/device mode DIP switches on the boards which
control port 0 signals (and the port 0 connector is micro-AB, so both a host
and device can be connected). The second board also has OTG chip on port 0
thru which USB ID pin can be read from the micro-AB connector.
David
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
