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

From: Lu Baolu <baolu.lu@linux.intel.com>
To: Peter Chen <hzpeterchen@gmail.com>
Cc: Jun Li <jun.li@nxp.com>,
	"felipe.balbi@linux.intel.com" <felipe.balbi@linux.intel.com>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Lee Jones <lee.jones@linaro.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Roger Quadros <rogerq@ti.com>
Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
Date: Mon, 6 Jun 2016 10:45:34 +0800	[thread overview]
Message-ID: <5754E3CE.8030706@linux.intel.com> (raw)
In-Reply-To: <20160606020507.GB16012@shlinux2>

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.

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

Best regards,
Lu Baolu