linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Chen <peter.chen@freescale.com>
To: Andrew Bresticker <abrestic@chromium.org>
Cc: Roger Quadros <rogerq@ti.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Felipe Balbi <balbi@ti.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	jun.li@freescale.com,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	tony@atomide.com, Joao.Pinto@synopsys.com,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-omap@vger.kernel.org,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality
Date: Tue, 14 Jul 2015 08:59:44 +0800	[thread overview]
Message-ID: <20150714005942.GB31197@shlinux2> (raw)
In-Reply-To: <CAL1qeaEJ9uX1vgvwO4-ABdGi5C96HZ2jBYWeKiGHJ-uqv6ooGg@mail.gmail.com>

On Mon, Jul 13, 2015 at 12:14:43PM -0700, Andrew Bresticker wrote:
> Hi Roger,
> 
> On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros <rogerq@ti.com> wrote:
> > Usage model:
> > -----------
> >
> > - The OTG controller device is assumed to be the parent of
> > the host and gadget controller. It must call usb_otg_register()
> > before populating the host and gadget devices so that the OTG
> > core is aware that it is an OTG device before the host & gadget
> > register. The OTG controller must provide struct otg_fsm_ops *
> > which will be called by the OTG core depending on OTG bus state.
> 
> I'm wondering if the requirement that the OTG controller be the parent
> of the USB host/device-controllers makes sense.  For some context, I'm
> working on adding dual-role support for Tegra210, specifically on a
> system with USB Type-C.  On Tegra, the USB host-controller and USB
> device-controller are two separate IP blocks (XUSB host and XUSB
> device) with another, separate, IP block (XUSB padctl) for the USB PHY
> and OTG support.  In the non-Type-C case, your OTG framework could
> work well, though it's debatable as to whether or not the XUSB padctl
> device should be a parent to the XUSB host/device-controller devices
> (currently it isn't - it's just a PHY provider).  But in the Type-C
> case, it's an off-chip embedded controller that determines the
> dual-role status of the Type-C port, so the above requirement doesn't
> make sense at all.

Hi Andrew,

I think your problem is how to add your core driver to manage device and
host functionality together, and once you find how (through padctl/type-c
controller) to do it based on current code, it will be clear how to use roger
proposal framework at that time.

Most of current core drivers, we use extcon driver (through gpio) or USB
vbus/id pin (through internal registers) to manager roles.

> 
> My idea was to have the OTG/DRD controller explicitly specify its host
> and device controllers, so in DT, something like:
> 
> otg-controller {
>     ...
>     device-controller = <&usb_device>;
>     host-controller = <&usb_host>;
>     ...
> };
> 
> usb_device: usb-device@.... {
>     ...
> };
> 
> usb_host: usb-host@... {
>     ...
> };
> 
> What do you think?
> 
> Thanks,
> Andrew

-- 

Best Regards,
Peter Chen

  reply	other threads:[~2015-07-14  0:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1436350777-28056-1-git-send-email-rogerq@ti.com>
     [not found] ` <1436350777-28056-1-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
2015-07-13 19:14   ` [PATCH v3 00/11] USB: OTG/DRD Core functionality Andrew Bresticker
2015-07-14  0:59     ` Peter Chen [this message]
2015-07-14 18:18       ` Andrew Bresticker
2015-07-15  2:13         ` Peter Chen
2015-07-15 13:26     ` Roger Quadros
     [not found]       ` <55A65F98.203-l0cyMroinI0@public.gmane.org>
2015-07-16 18:29         ` Andrew Bresticker
2015-07-17 10:34           ` 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=20150714005942.GB31197@shlinux2 \
    --to=peter.chen@freescale.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=abrestic@chromium.org \
    --cc=balbi@ti.com \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jun.li@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=rogerq@ti.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tony@atomide.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).