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

[Mats Karrman <mats.dev.list@gmail.com>]

Hi Heikki,

On 05/07/2018 03:39 PM, Heikki Krogerus wrote:

> 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?

What I really want is to understand where you're going with this.

I started to write a lot of answers to your statements below but then I
got to where you write that you are thinking about ditching the current
mux handling and that really changes a lot of things so I skip that.

>  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.

So, the mux need to subscribe to each svid:mode pair it is interested in using 
typec_altmode_register_notifier() and then use those callbacks to switch the correct
signals to the connector. And a driver for an off-the-shelf mux device could have
the translation between svid:mode pairs and mux device specific control specified by
of/acpi properties. Right?

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

I will try ;-)

> Thanks,
>
BR // Mats
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html