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 -- 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
