From: Roger Quadros <rogerq@ti.com>
To: Vivek Gautam <vivek.gautam@codeaurora.org>,
Felipe Balbi <balbi@kernel.org>
Cc: Peter Chen <hzpeterchen@gmail.com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
<peter.chen@freescale.com>, Tony Lindgren <tony@atomide.com>,
Greg KH <gregkh@linuxfoundation.org>, <dan.j.williams@intel.com>,
Mathias Nyman <mathias.nyman@linux.intel.com>,
<Joao.Pinto@synopsys.com>,
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
<jun.li@freescale.com>, <grygorii.strashko@ti.com>,
Rob Herring <robh@kernel.org>, <nsekhar@ti.com>, <b-liu@ti.com>,
Joe Perches <joe@perches.com>,
Linux USB Mailing List <linux-usb@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core
Date: Thu, 19 Jan 2017 14:15:24 +0200 [thread overview]
Message-ID: <16136231-7dfd-2f84-064f-f78a6ffe073b@ti.com> (raw)
In-Reply-To: <CAFp+6iEpnHTWQe196zWPJu3vqb+L=47rfU_8nfuUNC=Gjvc8Gg@mail.gmail.com>
Vivek,
On 19/01/17 13:56, Vivek Gautam wrote:
> Hi,
>
>
> On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros <rogerq@ti.com> wrote:
>
> Luckily hit this thread while checking about DRD role functionality for DWC3.
>
>> On 22/06/16 11:14, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Roger Quadros <rogerq@ti.com> writes:
>>>>>>>>>>>> For the real use case, some Carplay platforms need it.
>>>>>>>>>>>
>>>>>>>>>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>>>>>>>>>>> specification which is not OTG-compliant.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>>>>>>>>>> states to finish role swap.
>>>>>>>>>
>>>>>>>>> What are you referring to as "finish role swap"? I don't get that.
>>>>>>>>
>>>>>>>> Change current role from host to peripheral.
>>>>>>>
>>>>>>> Okay, we have two scenarios here:
>>>>>>>
>>>>>>> 1. You need full OTG compliance
>>>>>>>
>>>>>>> For this, granted, you need the state machine if your HW doesn't
>>>>>>> track it. This is a given. With only one user, however, perhaps
>>>>>>> we don't need a generic layer. There are not enough different
>>>>>>> setups to design a good enough generic layer. We will end up
>>>>>>> with a pseudo-generic framework which is coupled with its only
>>>>>>> user.
>>>>>>>
>>>>>>> 2. Dual-role support, without OTG compliance
>>>>>>>
>>>>>>> In this case, you don't need a stack. All you need is a signal
>>>>>>> to tell you state of ID pin and another to tell you state of
>>>>>>> VBUS level. If you have those, you don't need to walk an OTG
>>>>>>> state machine at all. You don't need any of those quirky OTG
>>>>>>> timers, agreed?
>>>>>>>
>>>>>>> Given the above, why would you even want to use a subset of OTG
>>>>>>> state machine to implement something that's _usually_ as simple
>>>>>>> as:
>>>>>>>
>>>>>>> 8<----------------------------------------------------------------------
>>>>>>> vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>>>>>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>>>>>>
>>>>>>> set_role(id);
>>>>>>> set_vbus(vbus);
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>> In fact, the individual driver can do it by itself. The chipidea driver
>>>>>> handles OTG and dual-role well currently. By considering this OTG/DRD
>>>>>> framework is worthwhile or not, we would like to see if it can
>>>>>> simplify DRD design for each driver, and can benefit the platforms which
>>>>>> has different drivers for host and peripheral to finish the role switch
>>>>>> well.
>>>>>
>>>>> simplify how? By adding unnecessary workqueues and a level indirection
>>>>> that just goes back to the same driver?
>>>>
>>>> What do you mean by same driver?
>>>
>>> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
>>> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
>>> layer jumps to a callback that goes back to dwc3 to e.g. start
>>> peripheral side.
>>>
>>> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>>>
>>>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>>>> be 3 totally independent drivers unlike dwc3 where you have a single
>>>> driver in control of both host and gadget.
>>>
>>> That's a totally different issue and one not being tackled by OTG
>>> layer, because there are no such users yet. We can't design anything
>>> based solely on speculation of what might happen.
>>>
>>> If there aren't enough users, there is no way to design a good generic
>>> layer.
>>>
>>>> Questions not clear to me are:
>>>>
>>>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>>>> role swap? Probably the PHY/MUX driver?
>>>
>>> This is implementation dependent. For TI's USB subsystem, we have PMIC
>>> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
>>> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
>>> has no intervention.
>>>
>>> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
>>> internal mux (much like TI's UTMI mailbox, but slightly different) to
>>> switch between a separate XHCI or a separate dwc3. The same mux can be
>>> put in HW-mode where SW has no intervention.
>>>
>>> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
>>> driver just detects role (at least for Type-C based plats) and executes
>>> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
>>> VBUS and, for type-C, toggle VCONN when needed.
>>>
>>>> 2) How does it perform the role swap? Probably a register write to the
>>>> PHY/MUX without needing to stop/start controllers? Easy case is both
>>>> controllers can run in co-existence without interference. Is there any
>>>> platform other than dwc3 where this is not the case?
>>>
>>> Again speculation. But to answer your question, only dwc3 is in such a
>>> case today. But even for dwc3 we can have DRD with a much, much simpler
>>> setup as I have already explained.
>>>
>>>> 3) Even if host and gadget controllers can operate in coexistence,
>>>> there is no need for both to be running for embedded applications
>>>> which are usually power conservative. How can we achieve that?
>>>
>>> Now you're also speculating that you're running on embedded applications
>>> and that we _can_ power off parts of the IP. I happen to know that we
>>> can't power off XHCI part of dwc3 in TI's SoC because that's fed by same
>>> Clocks and power rails as the peripheral side.
>>>
>>> [1] https://lkml.org/lkml/2016/6/21/658
>>>
>> For TI's case it is dwc3 and you are implementing the role swap in the dwc3
>> driver where you do intend to remove the XHCI platform device. So I'm not
>> much concerned about that.
>>
>> I was concerned about other platforms. I guess I'll let the other platform
>> people speak up as to what they need.
>
> I will talk about the msm platforms using dwc3 hardware.
> DWC3 controller on msm doesn't seem to have full otg functionality,
> and the driver makes use of switching between host and device
> using PRTCAPDIR register in of the core [1].
>
> We plan to support this DRD role switching (swapping host and device
> functionality based on id/vbus interrupts) in upstream.
>
> Do we see a valid case to have this framework?
Felipe wanted to have a minimal dual-role logic inside dwc3 which is
independent of any DRD/OTG framework.
I have implemented this and will send out patches today for review.
> Or, may be add a 'drd' layer for dwc3 that handles
> role switching (using PRTCAPDIR) based on the id/vbus extcon notifications.
>
>
> [1] https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/usb/dwc3/dwc3-msm.c?h=msm-3.18
> "dwc3_otg_start_host()"
> "dwc3_otg_start_peripheral()"
>
>
regards,
-roger
next prev parent reply other threads:[~2017-01-19 14:15 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 13:07 [PATCH v10 00/14] USB OTG/dual-role framework Roger Quadros
2016-06-10 13:07 ` [PATCH v10 01/14] usb: hcd: Initialize hcd->flags to 0 Roger Quadros
2016-06-14 8:16 ` Roger Quadros
2016-06-10 13:07 ` [PATCH v10 02/14] usb: otg-fsm: Prevent build warning "VDBG" redefined Roger Quadros
2016-06-10 13:07 ` [PATCH v10 03/14] usb: hcd.h: Add OTG to HCD interface Roger Quadros
2016-06-14 8:17 ` Roger Quadros
2016-06-14 14:21 ` Alan Stern
2016-06-15 7:14 ` Roger Quadros
2016-06-10 13:07 ` [PATCH v10 04/14] usb: otg-fsm: use usb_otg wherever possible Roger Quadros
2016-06-10 13:07 ` [PATCH v10 05/14] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops Roger Quadros
2016-06-10 13:07 ` [PATCH v10 06/14] usb: gadget.h: Add OTG to gadget interface Roger Quadros
2016-06-12 9:13 ` Peter Chen
2016-06-20 7:21 ` Felipe Balbi
2016-06-20 7:28 ` Roger Quadros
2016-06-20 8:13 ` Felipe Balbi
2016-06-20 8:25 ` Roger Quadros
2016-06-20 9:24 ` Felipe Balbi
2016-06-20 9:43 ` Roger Quadros
2016-06-10 13:07 ` [PATCH v10 07/14] usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG Roger Quadros
2016-06-10 13:07 ` [PATCH v10 08/14] usb: otg: add OTG/dual-role core Roger Quadros
2016-06-12 11:21 ` Peter Chen
2016-06-13 7:42 ` Roger Quadros
2016-06-13 7:56 ` [PATCH v11 " Roger Quadros
2016-06-13 7:58 ` Peter Chen
2016-06-20 7:45 ` Felipe Balbi
2016-06-20 10:13 ` Roger Quadros
2016-06-20 12:03 ` Felipe Balbi
2016-06-20 12:26 ` Roger Quadros
2016-06-20 12:46 ` Felipe Balbi
2016-06-21 6:39 ` Peter Chen
2016-06-21 7:19 ` Felipe Balbi
2016-06-21 8:02 ` Peter Chen
2016-06-21 8:18 ` Felipe Balbi
2016-06-21 9:14 ` Peter Chen
2016-06-21 12:35 ` Felipe Balbi
2016-06-21 13:12 ` Peter Chen
2016-06-21 14:47 ` Felipe Balbi
2016-06-22 3:33 ` Peter Chen
2016-06-22 6:51 ` Felipe Balbi
2016-06-22 7:30 ` Peter Chen
2016-06-22 8:00 ` Felipe Balbi
2016-06-23 7:41 ` Yoshihiro Shimoda
2016-06-21 2:30 ` Yoshihiro Shimoda
2016-06-21 7:21 ` Felipe Balbi
2016-06-20 11:49 ` Peter Chen
2016-06-20 12:08 ` Felipe Balbi
2016-06-21 6:05 ` Peter Chen
2016-06-21 7:26 ` Felipe Balbi
2016-06-21 9:07 ` Peter Chen
2016-06-21 10:02 ` Felipe Balbi
2016-06-21 10:43 ` Tony Lindgren
2016-06-21 10:56 ` Felipe Balbi
2016-06-21 13:05 ` Peter Chen
2016-06-22 6:56 ` Felipe Balbi
2016-06-22 7:33 ` Peter Chen
2016-06-22 8:03 ` Felipe Balbi
2016-06-22 7:49 ` Roger Quadros
2016-06-22 8:14 ` Felipe Balbi
2016-06-22 8:30 ` Roger Quadros
2017-01-19 11:56 ` Vivek Gautam
2017-01-19 12:15 ` Roger Quadros [this message]
2017-01-19 15:15 ` vivek.gautam
2017-01-20 8:30 ` Roger Quadros
2017-01-20 11:39 ` Vivek Gautam
2016-06-23 7:42 ` Yoshihiro Shimoda
2016-06-10 13:07 ` [PATCH v10 09/14] usb: of: add an API to get OTG device from USB controller node Roger Quadros
2016-06-13 8:13 ` Jun Li
2016-06-13 8:16 ` Roger Quadros
2016-06-13 8:23 ` [PATCH v11 " Roger Quadros
2016-06-10 13:07 ` [PATCH v10 10/14] usb: otg: add hcd companion support Roger Quadros
2016-06-10 13:07 ` [PATCH v10 11/14] usb: otg: use dev_vdbg() instead of VDBG() Roger Quadros
2016-06-10 13:07 ` [PATCH v10 12/14] usb: hcd: Adapt to OTG core Roger Quadros
2016-06-14 8:17 ` Roger Quadros
2016-06-10 13:07 ` [PATCH v10 13/14] usb: gadget: udc: adapt " Roger Quadros
2016-06-12 11:36 ` Peter Chen
2016-06-13 7:14 ` Roger Quadros
2016-06-13 7:20 ` Peter Chen
2016-06-13 7:37 ` Roger Quadros
2016-06-13 7:40 ` Peter Chen
2016-06-13 7:55 ` [PATCH v11 " Roger Quadros
2016-06-13 7:56 ` Peter Chen
2016-06-13 8:06 ` Roger Quadros
2016-06-10 13:07 ` [PATCH v10 14/14] usb: host: xhci-plat: Add otg device to platform data Roger Quadros
2016-06-14 8:18 ` Roger Quadros
2016-06-14 2:17 ` [PATCH v10 00/14] USB OTG/dual-role framework Peter Chen
2016-06-14 8:12 ` Roger Quadros
2016-06-16 11:07 ` Roger Quadros
2016-06-17 7:17 ` Felipe Balbi
2016-06-17 7:31 ` Roger Quadros
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=16136231-7dfd-2f84-064f-f78a6ffe073b@ti.com \
--to=rogerq@ti.com \
--cc=Joao.Pinto@synopsys.com \
--cc=b-liu@ti.com \
--cc=balbi@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=grygorii.strashko@ti.com \
--cc=hzpeterchen@gmail.com \
--cc=joe@perches.com \
--cc=jun.li@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=nsekhar@ti.com \
--cc=peter.chen@freescale.com \
--cc=robh@kernel.org \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=tony@atomide.com \
--cc=vivek.gautam@codeaurora.org \
--cc=yoshihiro.shimoda.uh@renesas.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;
as well as URLs for NNTP newsgroup(s).