[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150714005942.GB31197@shlinux2>
Date: Tue, 14 Jul 2015 08:59:44 +0800
From: Peter Chen <peter.chen@...escale.com>
To: Andrew Bresticker <abrestic@...omium.org>
CC: Roger Quadros <rogerq@...com>,
Alan Stern <stern@...land.harvard.edu>,
Felipe Balbi <balbi@...com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dan Williams <dan.j.williams@...el.com>,
<jun.li@...escale.com>,
"Mathias Nyman" <mathias.nyman@...ux.intel.com>,
<tony@...mide.com>, <Joao.Pinto@...opsys.com>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
<linux-omap@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality
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@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists