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