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

[Roger Quadros <rogerq@ti.com>]

Hi,

On 06/06/16 06:04, Lu Baolu wrote:
> Hi Peter,
> 
> On 06/06/2016 09:25 AM, Peter Chen wrote:
>> On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote:
>>> Hi Peter,
>>>
>>> On 06/04/2016 10:28 AM, Peter Chen wrote:
>>>> On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote:
>>>>>> from my point,it is a dual-role switch
>>>>>> driver too,
>>>>> No, it's not a dual-role switch driver, but a driver for USB port multiplexing.
>>>>>
>>>>> One example of port multiplexing can be found in several Intel SOC and PCH
>>>>> chips, inside of which, there are two independent USB controllers: host and
>>>>> device. They might share a single port and this port could be configured to
>>>>> route the line to one of these two controllers. This patch introduced a generic
>>>>> framework for port mux drivers. It aids the drivers to handle port mux by
>>>>> providing interfaces to 1) register/unregister a mux device; 2) lookup the
>>>>> mux device; and 3) switch the port.
>>>>>
>>>> For this case, I can't see it is different with dual-role switch.
>>> 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.
>> You have admitted port mux is one of the ports of dual-role switch,
>> Then, how they can co-work with each other? If can't, the dual-role
>> switch framework needs another input events management for switching.
> 
> My point is we need a generic framework for the port mux devices,
> just like we have that for PHY and regulator. OTG framework
> manages the port mux devices through the common interfaces
> provided by the port mux framework.
> 
> If we integrate the port mux device support into OTG itself, this  will
> force every use case of port mux to rely on the big OTG framework,
> although what it needs is only a single driver. That causes unnecessary
> software complexity.

I agree with Lu here.

Intel platforms seem to actually have a Mux device and we need a device driver for that.
OTG/dual-role core cannot directly handle the Mux device.

The Mux device can be used not only for dual-role but for other things so we can't
force it to use just OTG/dual-role.

For Mux devices implementing dual-role, the mux device driver _must_ use OTG/dual-role core
API so that a common ABI is presented to user space for OTG/dual-role.

I haven't yet looked at the mux framework but if we take care of the above point
then we are not introducing any redundancy.

> 
>>
>>>> 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.
>>>
>> Yes, it is the same. GPIO pin or device registers is like ID pin
>> event.
>>
> 
> <snip>
> 
>>> But this code is better co-work with OTG/Dual-role framework, we'd
>>> better have only interface that the user can know which role for the
>>> current port.
>>> OTG/Dual-role framework and portmux framework are not overlapped.
>>> The sysfs interface shouldn't be overlapped as well. Say, I have a port
>>> mux device and I have a driver for it. I am able to read the status of my
>>> port mux device through sysfs. This is not part of OTG/Dual-role as far
>>> as I can see.
>>>
>> Then how the user wants to switch the role through the mux driver's
>> sysfs or dual-role switch sysfs?
>>
> 
> It depends. If you have an OTG/DRD capable controllers, you need to
> do this through OTG sysfs; otherwise you only need to switch the port.
> 

--
cheers,
-roger