Re: [PATCH v17 2/3] usb: USB Type-C connector class

[Heikki Krogerus]

On Tue, Mar 07, 2017 at 11:30:54PM +0100, Mats Karrman wrote:
> > > So, both the DP controller and the USB PD phy are I2C devices, and now I have to make them both
> > > attach to the AM bus as well?
> > The DP controller would provide the driver and the USB PD phy
> > (actually, the typec class) the device.
> > 
> > Would it be a problem to register these I2C devices with some other
> > subsystem, was it extcon or something like AM bus? It really would not
> > be that uncommon. Or have I misunderstood your question?
> 
> OK, so a bus could be used for drivers to find each other but it still does not say
> anything about how those drivers are supposed to communicate so that must be prescribed
> separately, right?

Yes.

> If I read Heikki's original suggestion I understand it like the DP driver would be
> responsible for AM specific USB PD/VDM communication. But wouldn't that lead
> to a lot of code duplication since the AM protocol is the same for all drivers of
> a kind?

No that's not what I mean. I'm still mixing your PD controller with
something else above, sorry about that. Your PD controller driver
should not ideally even need to be aware of Type-C connector, right?
It definitely does not need to do any USB PD communication.

I would imagine you have on top of the DP controller, a mux (which
could be a DP/USB3 PHY like on Rockchip RK3399, discrete mux like
Pericom PI3USB30532, or something else), and a USB Type-C PHY or USB
PD controller. The bus would be tying the mux to the Type-C port (PHY
or PD controller) and its partner (note that it does not tie the mux
to the DP controller). Please correct me if I'm wrong about your
hardware.

Assuming that is how your board roughly looks like, the driver for the
mux would be the driver for the DP altmode devices. That driver would
be the one converting things like the Attention messages notifying
about HPD into toggling of GPIOs, or what ever is needed on your
board, etc.

The actual PD communication with VDMs should be considered as just the
protocol, so we probable should have "protocol drivers". For example
DP alternate mode VDMs and communication will always be the same
despite of the hardware. The DP alternate mode "protocol driver" would
then be tied to the alternate mode device for the partner, and that
driver could have its own hooks for what ever is needed, like HPD
signal handling, configuration changes, whatever. In any case,
hopefully making things easy and straightforward for the "mux driver",
_so that it does not need to care about the actual PD communication_.


Thanks,

-- 
heikki