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
next prev parent reply other threads:[~2016-06-06 2:45 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-02 1:37 [PATCH v10 0/7] usb: add support for Intel dual role port mux Lu Baolu
2016-06-02 1:37 ` [PATCH v10 1/7] regulator: fixed: add support for ACPI interface Lu Baolu
2016-06-08 4:42 ` Greg Kroah-Hartman
2016-06-08 13:43 ` Mark Brown
2016-06-08 15:46 ` Greg Kroah-Hartman
2016-06-09 2:43 ` Lu Baolu
2016-06-02 1:37 ` [PATCH v10 2/7] usb: mux: add generic code for dual role port mux Lu Baolu
2016-06-03 7:41 ` Peter Chen
2016-06-03 8:16 ` Heikki Krogerus
2016-06-03 9:20 ` Peter Chen
2016-06-03 16:06 ` Lu Baolu
2016-06-04 2:28 ` Peter Chen
2016-06-05 6:55 ` Lu Baolu
2016-06-05 8:33 ` Jun Li
2016-06-05 8:46 ` Lu Baolu
2016-06-06 1:08 ` Jun Li
2016-06-06 2:30 ` Lu Baolu
2016-06-06 2:05 ` Peter Chen
2016-06-06 2:45 ` Lu Baolu [this message]
2016-06-06 6:48 ` Peter Chen
2016-06-06 1:25 ` Peter Chen
2016-06-06 3:04 ` Lu Baolu
2016-06-06 7:02 ` Roger Quadros
2016-06-07 3:03 ` Jun Li
2016-06-07 6:27 ` Lu Baolu
2016-06-07 6:34 ` Jun Li
2016-06-07 9:27 ` Lu Baolu
2016-06-07 12:49 ` Roger Quadros
2016-06-07 9:53 ` Lu Baolu
2016-06-07 12:58 ` Roger Quadros
2016-06-07 13:04 ` Felipe Balbi
2016-06-07 14:02 ` Roger Quadros
2016-06-07 15:05 ` Felipe Balbi
2016-06-08 3:04 ` Jun Li
[not found] ` <5757A8CB.90402@linux.intel.com>
2016-06-08 6:20 ` Jun Li
2016-06-08 6:25 ` Peter Chen
2016-06-08 7:58 ` Roger Quadros
2016-06-06 7:02 ` Peter Chen
2016-06-06 7:35 ` Lu Baolu
2016-06-02 1:37 ` [PATCH v10 3/7] usb: mux: add driver for Intel gpio controlled " Lu Baolu
2016-06-02 1:37 ` [PATCH v10 4/7] usb: mux: add driver for Intel drcfg " Lu Baolu
2016-06-02 1:37 ` [PATCH v10 5/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver Lu Baolu
2016-06-02 1:37 ` [PATCH v10 6/7] usb: pci-quirks: add Intel USB drcfg mux device Lu Baolu
2016-06-08 4:45 ` Greg Kroah-Hartman
2016-06-08 7:56 ` Lu Baolu
2016-06-08 15:45 ` Greg Kroah-Hartman
2016-06-09 2:39 ` Lu Baolu
2016-06-16 0:27 ` Lu Baolu
2016-06-18 0:58 ` Greg Kroah-Hartman
2016-06-19 9:52 ` Lu Baolu
2016-06-02 1:37 ` [PATCH v10 7/7] MAINTAINERS: add maintainer entry for Intel USB dual role mux drivers Lu Baolu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5754E3CE.8030706@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=broonie@kernel.org \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=hzpeterchen@gmail.com \
--cc=jun.li@nxp.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=rogerq@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.