public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: Lu Baolu <baolu.lu@linux.intel.com>, Jun Li <jun.li@nxp.com>,
	Peter Chen <hzpeterchen@gmail.com>
Cc: "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>
Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
Date: Tue, 7 Jun 2016 15:58:03 +0300	[thread overview]
Message-ID: <5756C4DB.1050400@ti.com> (raw)
In-Reply-To: <5756999B.9020809@linux.intel.com>

On 07/06/16 12:53, Lu Baolu wrote:
> Hi,
> 
> On 06/07/2016 11:03 AM, Jun Li wrote:
>> Hi Roger
>>
>>>  
>>> 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.
>> That's the only point we have concern, do dual role switch through
>> OTG/dual-role core, not do it by itself.
>>
>>> 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.
>>>
>> Roger, actually this is my worry on OTG core: those dual role switch
>> users just tends to do it simply by itself(straightforward and easy),
>> not through the OTG core(some complicated in first look),
> 
> I'm sorry, but I'm really confused.
> 
> Why do we need to drop "straightforward and easy", but have to run
> an *unnecessary* OTG state machine? Don't you think that will (1) add
> *unnecessary* software complexity; (2) increase *unnecessary* memory
> footprint; and (3) increase the debugging efforts?
> 
>> this is just an example for us to convince people to select a better
>> way:)
> 
> Sure. Let's take my case for an example.
> 
> My system has a third-party port mux, which is not part any USB controllers.
> Also, my system doesn't have any DRD capable devices. I need a
> "straightforward and easy" driver for it. Otherwise, the system could not be
> waken up from system suspend.
> 
> But you said I must run an unnecessary OTG state machine, even thought it
> has nothing to do with my system, only because the two sides of my port
> mux device is a host and peripheral controller.

We have a minimal dual-role state machine that just looks at ID pin and toggles
the port role.

How are you switching the port mux between host and peripheral? Only by sysfs
or do you have a GPIO for ID pin as well?

What happens to the gadget controller when the port is muxed to the host controller?
Is it stopped or it continues to run?

cheers,
-roger

  reply	other threads:[~2016-06-07 12:58 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
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 [this message]
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=5756C4DB.1050400@ti.com \
    --to=rogerq@ti.com \
    --cc=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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox