From: vivek.gautam@codeaurora.org
To: Roger Quadros <rogerq@ti.com>
Cc: Felipe Balbi <balbi@kernel.org>,
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-kernel@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 20:45:50 +0530 [thread overview]
Message-ID: <3c95b592d78aa569de33d420c4c93018@codeaurora.org> (raw)
In-Reply-To: <16136231-7dfd-2f84-064f-f78a6ffe073b@ti.com>
Hi Roger,
On 2017-01-19 17:45, Roger Quadros wrote:
> 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].
>> test
>> 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.
Okay, good to know that. I will be happy to take a look at the
patches and test them for msm.
Thanks for sharing the info.
>
>> 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
Regards
Vivek
next prev parent reply other threads:[~2017-01-19 15:16 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
2017-01-19 15:15 ` vivek.gautam [this message]
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=3c95b592d78aa569de33d420c4c93018@codeaurora.org \
--to=vivek.gautam@codeaurora.org \
--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=rogerq@ti.com \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=tony@atomide.com \
--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).