usb: typec: Generalize mux mode names
RFC 1/7 usb: typec: Generalize mux mode names
Quoted 35 lines · Mats Karrman
Hi Heikki,
Quoted 31 lines · Heikki Krogerus
Quoted 24 lines · Heikki Krogerus
Hi Mats,
Quoted 6 lines · Mats Karrman
The current naming used for
tcpc_mux_modeconstants makes too much assumptioms about the usage of the signals. This patch replaces the names with generic names more closely tied to the Type-C specifications and also adds some new ones. At the same time TCPC_MUX_* defines are removed as they do not fit the new concept and currently have no in-tree users.I'm afraid trying to generalize the modal connector states even like this is not going to work. We can't make any assumptions about how the alternate modes configure the pins, or the connector in general.
The only way this will work is that every alternate mode has its own configurations defined separately, and I'm talking about the actual pin configurations that the specifications for each alternate mode defines, so something like
TYPEC_MUX_DPandTYPEC_MUX_DOCKwill not work for sure.The connector states that are defined in USB Type-C specification (so basically USB Operation and USB Safe State) can be generalized, but those states just should not be defined in
tcpm.h. We need to use them in other drivers as well.Quoted 4 lines
I'm in the middle of preparing more complete support for alternate modes. If you check the RFC [1] I send previously, in the first patch of the series I'm adding documentation that should explain the plan.
Sorry, I forgot the link:
Quoted 8 lines
Quoted 1 line
Oh, sorry I forgot about that post in the first place... I reread it now.
Since the modal
TYPEC_STATE_are overlapping for each AM, this means that the mux driver "set" must know which AM is active, right?And each mux driver also need to support all possible alt modes?
There are two options for the mux drivers to link with the alternate modes. They can use the typec API where a single mux is linked to a single port. Alternatively they can use the notifiers from the alternate modes themselves, which allows a single mux to be liked to multiple alternate modes. Both methods will be available.
Is this what you were asking?
Quoted 8 lines
I was thinking that it must be a finite number of possible routes between the local connections of a mux and the four available SS lanes of the cable but of course there is no theoretical limit to the number of local connections...
Do we want to set a limitation of one mux device per port? I guess we could and then let people write "composite" mux drivers if it should ever be necessary.
I think I answered to this one above.
Quoted 10 lines
Still it's difficult to write a mux device driver that support everything, but I'm thinking that it might be possible to write a "mode agnostic" mux driver that uses properties to match the "AM:STATE" pairs the board needs to support to the hardware mux device specific muxing modes available?
It would be very interesting to see a devicetree example on how you picture things being connected to each other.
Btw. You're using "mode" and "state" interchangeably which is a bit confusing. Could you settle for one?
OK, I'll try to be more consistent and pick one.
Thanks,