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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
