Hi,
Thanks for taking a look at this..
On Sun, Nov 26, 2017 at 12:23:31PM +0100, Hans de Goede wrote:
> Hi Heiko,
>
> On 28-09-17 13:35, Heikki Krogerus wrote:
> > Hi guys,
> >
> > The bus allows SVID specific communication with the partners to be
> > handled in separate drivers for each alternate mode.
> >
> > Alternate mode handling happens with two separate logical devices:
> > 1. Partner alternate mode devices which represent the alternate modes
> > on the partner. The driver for them will handle the alternate mode
> > specific communication with the partner using VDMs.
> > 2. Port alternate mode devices which represent connections from the
> > USB Type-C port to devices on the platform.
> >
> > The drivers will be bind to the partner alternate modes. The alternate
> > mode drivers will need to deliver the result of the negotiated pin
> > configurations to the rest of the platform (towards the port alternate
> > mode devices). This series includes API for that, however, not the
> > final implementation yet.
> >
> > The connections to the other devices on the platform the ports have
> > can be described by using the remote endpoint concept [1][2] on ACPI
> > and DT platforms, but I have no solution for the "platform data" case
> > where we have neither DT nor ACPI to describe the connections for us.
>
> Sorry about the slow reply, I've been a bit swamped with other stuff,
> but now I would like to get back to this.
>
> I've been trying to wrap my head around what you're proposing here and
> I see how this can help with implementing display-port alternate mode
> support, but I don't see how it is going to help with regular superspeed
> USB support / the mux problem.
>
> The problems I see / questions I have are:
>
> 1) This seems to be driven by having a bus using svid-s as match functions,
> but the standard USB function does not have any svid, or at least currently
> does not show as such under e.g. /sys/class/typec/port0/port0-partner
USB is the "normal" mode, not alt-mode. We don't need any specific
driver for the USB mode. In alternate modes, we have to communicate
with the partner using SVID specific messages, and that is what we
need the drivers for.
> 2) The alt-mode drivers you are suggesting seem to be about 2 things:
> a) Alt-mode specific PD communication
> b) Telling other components about pin-configs, e.g. telling the i915 driver how
> much display port lanes are configured
>
> What this seems to miss a mechanism to control the mux between the "superspeed"
> data-pairs on the port and the dp-port pins on the SoC / the superspeed USB
> pins on the SoC. Even leaving display-port out of the picture for now we still
> need to control the port -> SoC superspeed pins routing which need to be
> one of: tristated (default) / normal / upside-down routing.
We will need to deliver the orientation to the GPU/DP drivers and I'm
not supporting that yet in this draft. I'm preparing a more complete
version of these, and I'll propose something for the orientation as
well, though it is a little bit out side the scope of this series.
That information comes from the device drivers or tcpm, not the
alternate mode drivers.
The USB MUX question is a separate topic, however, the idea of
describing the connections a Type-C port (or any usb port) has to
other components in ACPI and DT, including the USB mux, should be done
using device graph (remote-endpoints) in the future. For the existing
boards we need to figure out somekind of a lookup method to do the
same, and that is the biggest missing thing we still have IMO.
---------------
| Type-C port |
---------------
|
-------
/ MUX \
-----------
/ \
/ \
/ \
---------- ---------
| GPU | / USB MUX \
---------- -------------
/ \
/ \
/ \
------------------- ---------------------
| Host controller | | Device controller |
------------------- ---------------------
> ### end Type-c discussion ###
>
> ### Related USB device/host mode switch discussion ###
>
> Another problem for USB is even once the right pins on the port are routed to
> the right pins on the SoC then the SoC may have an internal mux to route
> all the USB pins (both USB-2 and superspeed) to either the host or device
> USB controller.
>
> My previous patches for this tried to use the mux framework for this, but that
> was nacked because of a misunderstanding how the current mux framemork works.
>
> The current mux framework is based on the notion of there being a shared
> bus between e.g. the SoC and various devices, where the devices are not
> directly addressable from the bus, but there is a mux in between which
> connects the SoC to the device it wants to talk to. So the SoC can reach
> all connected devices, but only one add at a time. To make this clear
> a driver talking to one of the devices needs to switch the mux to a
> specific device and then release the mux when it is done. If another
> driver tries to switch the mux before it is released its request will
> block until the mux gets released.
If the framework was designed for only such specific cases, I'm not
sure it should be called "mux framework" at all.
> With USB OTG / Type-C things are different, there is only one device
> connected, and depending on which type of device is detected as being
> connected we need to connect the OTG / Type-C port pins to the
> corresponding controller inside the SoC. There is no "time-shared"
> access to multiple devices at the same time. Thus the current mux
> subsys is a poor match for the needs for USB OTG / Type-C.
>
> One option I've been considering is to introduce a new usb_mux subsys
> when I get around to this (hopefully sometime the coming month) which
> will be modelled after the mux subsys, but without the "time-sharing"
> concepts and thus without the need to release a mux setting before
> the mux can be switched to route the data else where.
Wasn't that basically what Baolu proposed [1] ?
I really hoped we had a generic mux framework instead of usb specific
one. How about if you call it "demux framework" :-)
In any case, we still need a way to describe the connections. I don't
think we should propose yet an other framework specific lookup method.
There really should be a generic "device graph for board files"
solution that we could use also here. Well, ideally.
> My primary target here is using this on devices with a micro-usb
> connector, traditionally on ARM systems the mux in these devices has
> been hidden inside the phy-driver. But on x86 systems:
> a) The phy is setup from firmware and we don't have a phy driver; and
> b) Often the mux is not part of the phy at all, instead we have a
> separate mux (sometimes in separate IC outside the SoC) driven by
> gpios or i2c.
>
> I think we could extend this usb_mux subsys easily to also handle the
> mux parts of type-c (specifically controlling mux ICs such as the
> PI3USB30532 USB switch).
[1] https://lkml.org/lkml/2016/6/1/980
Thanks,
--
heikki
--
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
