All of
 help / color / mirror / Atom feed
From: Mats Karrman <>
To: Heikki Krogerus <>
Cc: Hans de Goede <>,
	Guenter Roeck <>,
	Greg Kroah-Hartman <>,
	Rob Herring <>,
Subject: [RFC,1/7] usb: typec: Generalize mux mode names
Date: Mon, 7 May 2018 23:19:40 +0200	[thread overview]
Message-ID: <> (raw)

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]
>>>> 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
More majordomo info at

             reply	other threads:[~2018-05-07 21:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-07 21:19 Mats Karrman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-05-21 13:04 [RFC,1/7] usb: typec: Generalize mux mode names Heikki Krogerus
2018-05-18  5:26 Mats Karrman
2018-05-17 11:50 Heikki Krogerus
2018-05-16 21:11 Mats Karrman
2018-05-16 11:43 Heikki Krogerus
2018-05-15 21:24 Mats Karrman
2018-05-15  7:30 Heikki Krogerus
2018-05-11 19:28 Mats Karrman
2018-05-09 12:49 Heikki Krogerus
2018-05-08 19:10 Mats Karrman
2018-05-08 14:25 Heikki Krogerus
2018-05-07 13:39 Heikki Krogerus
2018-05-04 16:57 Mats Karrman
2018-05-04 14:56 Heikki Krogerus
2018-05-02 13:13 Mats Karrman
2018-05-02  8:25 Heikki Krogerus
2018-05-02  8:23 Heikki Krogerus
2018-05-01 22:21 Mats Karrman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.