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

[Lu Baolu]

Hi Jun,

On 06/06/2016 09:08 AM, Jun Li wrote:
>
>> -----Original Message-----
>> From: Lu Baolu [mailto:baolu.lu@xxxxxxxxxxxxxxx]
>> Sent: Sunday, June 05, 2016 4:47 PM
>> To: Jun Li <jun.li@xxxxxxx>; Peter Chen <hzpeterchen@xxxxxxxxx>
>> Cc: felipe.balbi@xxxxxxxxxxxxxxx; Mathias Nyman <mathias.nyman@xxxxxxxxx>;
>> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Lee Jones
>> <lee.jones@xxxxxxxxxx>; Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>;
>> Liam Girdwood <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>;
>> linux-usb@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Roger Quadros
>> <rogerq@xxxxxx>
>> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
>> mux
>>
>> 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?
> Currently there are many controller drivers which are dual role
> capable, all has its specific approach/implementation, your case
> is another one, actually there are common part we can share and
> reuse, Roger is introducing a common framework which cooperates
> into usb core and udc-core. With that, each OTG/dual role user
> only need take care of its small specific part.

Intel's USB controllers aren't dual role capable, and we don't
need any dual role capable drivers either. It's just two USB
controllers which shares a single port and it has a physical
port mux device which could control the route of lines. We
only need drivers for the port mux devices.

>   
>> Is it something like a bus or class driver?
> It's not actually a driver, instead, it's more like a lib or
> helper routines. You just need register your host and gadget
> into OTG core, and define the ops routines if required, OTG state
> machine will help you do the switch.

As I said above, we don't have any dual role capable controllers.
We don't need to have any dual role capable host or gadget drivers
to register into OTG core. We only provide drivers for port mux
devices, just like what we already have for phy or regulator
devices.

Best regards,
Lu Baolu