On Mon, Jun 06, 2016 at 10:45:34AM +0800, Lu Baolu wrote: > Hi Peter, > > On 06/06/2016 10:05 AM, Peter Chen wrote: > > On Sun, Jun 05, 2016 at 04:46:55PM +0800, Lu Baolu wrote: > >> Hi, > >> > >> On 06/05/2016 04:33 PM, Jun Li wrote: > >>>> Port mux is part of dual role switch, but not the whole thing. > >>>>> Dual role switch includes at least below things: > >>>>> - ID or type-C event detection > >>>>> - port mux > >>>>> - VBUS management > >>>>> - start/stop host/device controllers > >>>>> > >>>>> An OTG/Dual-role framework can be used to keep all these things run > >>>>> together with an internal state machine. But it's not duplicated with a > >>>>> generic framework for port mux and the port mux drivers. > >>>>> > >>>>>>> Your > >>>>>>> case is just like Renesas case, which uses two different drivers > >>>>>>> between peripheral and host[1]. > >>>>> In my case, the port mux devices are physical devices and they can be > >>>>> controlled through GPIO pins or device registers. They are independent of > >>>>> both peripheral and host controllers. > >>>>> > >>> I also think current OTG/Dual role framework can support your case, if you > >>> find there is any limitation of it which can't meet your requirement, we > >>> should improve it, Roger also provide an example of dual role switch with > >>> USB3 based on his OTG core. > >> Why do we need an OTG framework to support a device driver? > > Just like you said above, OTG framework can manage role switch, the > > role switch may need to start or stop host/gadget driver according to > > different hardware signals or user input. > > We don't have any OTG or dual-role (reduced OTG) capable > controllers. So we don't need to aid OTG framework to > start/stop host/gadget drivers. > In your case, the related APIs are NULL. > > > >> Is it something like a bus or class driver? > > The DRD/OTG framework uses the same device structure with the caller, > > the caller can be a dual-role controller driver (like dwc3, chipidea, > > etc), or a separate switch driver which like your mux port driver. > > > > From my point of view, this isn't the right way to handle a port > mux device. > > We have many kinds of port mux devices across multiple archs, > we should have a generic framework for them, so that consumers, > (like OTG framework) can manipulate port mux devices through a > common interfaces. Just like we already have frameworks for PHY, > VBUS regulator and ... > But, in your framework, it will finish the role switch like OTG framework does. -- Best Regards, Peter Chen -- 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
