[RFC,1/7] usb: typec: Generalize mux mode names

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

Hi Mats,

On Fri, May 04, 2018 at 06:57:31PM +0200, Mats Karrman wrote:
> 
> On 2018-05-04 16:56, Heikki Krogerus wrote:
> 
> > On Wed, May 02, 2018 at 03:13:44PM +0200, Mats Karrman wrote:
> > > Hi Heikki,
> > > 
> > > On 2018-05-02 10:25, Heikki Krogerus wrote:
> > > 
> > > > On Wed, May 02, 2018 at 11:23:35AM +0300, Heikki Krogerus wrote:
> > > > > Hi Mats,
> > > > > 
> > > > > On Wed, May 02, 2018 at 12:21:07AM +0200, Mats Karrman wrote:
> > > > > > The current naming used for tcpc_mux_mode constants 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_DP and TYPEC_MUX_DOCK will 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.
> > > > > 
> > > > > 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:
> > > > 
> > > > [1] https://www.spinics.net/lists/linux-usb/msg166520.html
> > > 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?
> 
> Well, sort of... My angle is from the mux driver writers side. A hardware mux
> device does not care what logical signals is being muxed and neither should the
> mux driver I think. But the system designer must be able to make the mux driver
> respond to the correct AM:STATE.

So what you want is "generic" mux drivers? The mux drivers are the
ones that need to interpret the alternate mode specific connector
states into actual pin muxing, not the type-c drivers. The type-c
alternate mode drivers and frameworks should not even need to know if
an alternate mode specific connector state requires pin muxing at all.
They should be able quite simply pass forward the negotiated connector
state, and be done with it. That is the only way we can keep this
whole thing flexible enough to fit all kinds of platforms.

Interpreting the alternate mode specific connector states is
straightforward for the mux drivers, and that is all that they need to
do in this case, but expecting the type-c drivers to supply the exact
pin configuration to the mux drivers just so the mux driver can be a
little bit more "dummy" does not only mean duplicated effort (the
alternate mode drivers and the type-c frameworks still need to handle
the actual alternate mode specific connector states), but also a
roadmap to hacks like virtual/NOP mux drivers and platform specific
quirks in the alternate mode drivers.

The configuration of the type-c connector will simply not always
happen the same way. We will not always have the muxes directly under
operating system control. Sometimes the USB Type-C/PD controller
handles them, or like in my case, a microcontroller on the system
controls the muxes and the drivers need to communicate with the
microcontroller. We don't know the requirements the various ways to
configure the connectors have.

So we don't want to end up in a scenario where we are uncertain about
what does the underlying mux handling expect from the alternate mode
driver (for example, do we need to inform about the Linux specific pin
configuration value you are proposing, or the actual alternate mode
specific connector state) but that is exactly what will happen.

> So, do you think it would be a viable approach to let the mux driver be
> configured through dt/acpi properties that link AM:STATE pairs to some internal
> muxing mode of the hardware mux device?

If the mux is able to route the pins to multiple locations on top of
USB, the driver for it needs to get all the supported SVIDs, modes and
their SVID specific connector states that require pin re-configuration
from the hardware description. That should be enough for them.

> Even so, when the mux driver "set" function is called, it will just get the
> mode argument but since the mode (TYPEC_STATE_...) is overlapping for different
> AMs if I understand your proposal correctly, the mux also needs to know what AM
> is active.
> Does this imply that the mux set function signature need to change?

My plan was actually to propose we get rid of the current mux handling
(just leave the orientation switch) in favour of the notifications I'm
introducing with the type-c bus for the alternate modes. The current
mux handling is definitely not enough, and does not work in every
scenario, like also you pointed out.

Btw. Could you please not use abbreviations like "AM". Please just say
"alternate mode" when you want to talk about alternate modes.


Thanks,