Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

Peter Chen
2016-06-06T06:54:38Z

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