On 2018-06-13 09:06, Andrzej Hajda wrote:
On 12.06.2018 19:33, Mats Karrman wrote:
Hi Andrzej,
On 2018-06-07 13:40, Andrzej Hajda wrote:
On 06.06.2018 23:36, Mats Karrman wrote:
Hello Gentlemen,
I'm trying to get my head around USB role switches in connection with Type-C ports
and device-trees. So far I have not found much documentation, e.g. there are no
device-tree bindings documented and really no good examples in existing device
trees, although there has been some attempts, e.g. [1] and [2]. Anyway, so I send
you a couple of questions instead:
1) tcpm uses the port device struct to find a single usb_role_switch but there is
room for three USB busses in the Type-C connector; one high speed and two (?) super-
speed. These would not all come from the same controller (there might even be
separate controllers for host and device mode for each bus).
The case I am working on now only have a single USB2 otg controller so it should
be possible to make that driver register a role switch but for other cases?
I imagine it would be possible to create a composite driver as a proxy for all role
switches but that would probably be different for every platform/product - not
very elegant. Could the role switch infrastructure be extended to handle arbitrary
sets of coordinated switches?
2) How should the connection between the Type-C port and the switches best be
expressed in a device tree? Using graph I presume, but should it be mixed into the
existing "usb-connector" or should this be a separate block?
I think it is unfortunate that the graph use numeric addresses that need to be
fixed by documentation
I also do not like port numbers, I even have argued for using names
during multiple discussions, but the discussion ended as is :(
and already I see problems with the current assignment
(0=HS, 1=SS, 2=SBU), e.g. if the host and device mode are handled by different
controllers. Graph do support multiple endpoints for one port but then we have
another level of magic numbers which does not exactly make things easier
(e.g. 0=dual or host controller, 1=device controller, 2=mode switch).
Where do you want to use these magic numbers? To describe endpoints? I
For some hypothetic worst case scenario where a switch needs to handle
different USB controllers for port host and device mode. However I think
Heikki and Hans are correct in saying we should wait to worry about that
until we have an actual use-case.
guess there should be controllable mux/switch behind the port, it could
be standalone, or a part of bigger IP.
Anyway it should be described by device node, probably parent of USB-C
child?
device-node, in such case only links from USB connector going to
different IPs should be described using OF graphs.
And in such case drivers of these devices should
ask/determine/change/communicate their role using in-kernel frameworks
(for example extcon).
There are many different configurations of USB-C ports
InterfaceControllers, Muxes/Switches, USB related devices, Alternate
Mode devices, PMICs, USB-PDs, ....
Could you describe particular one you have problem with, to make the
discussion more specific.
My use-case now is simple. I have a typec port that I need to connect to
a dual-role USB controller, probably extended with a usb-role-switch
device and I want to express that connection in the device-tree. I was looking
for a documented description or example of how to do this but I realize that
that is not yet available.
USB connector bindings [1] are not enough? Did you look at the example?
I do not know what is exactly your usb-role-switch. Can you provide some
I'm referring to commit fde0aa6c175a4d8aa19e82b86ae0f9278bc8563b
"usb: common: Small class for USB role switches" that is used by the tcpm.
So far I have found no examples of it's usage together with devicetree, only
acpi (and it's not documented in [1], yet).
BR // Mats
schematics? Or describe which physical lines of USB-C connector are
connected to which chips (including muxes/switches).
Two rules of thumb, I think quite simple:
1. Do you have USB interface controller? Ie chip which is connected to
CC lines of USB-C and performs cable detection, maybe PD negotiations,
etc. This device should be the parent of USB connector node.
2. Connections between connector and other chips should be described
using OF graph.
[1]:
https://www.kernel.org/doc/Documentation/devicetree/bindings/connector/usb-connector.txt
--
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
