From: Felipe Balbi <balbi@ti.com>
To: "Munegowda, Keshava" <keshava_mgowda@ti.com>
Cc: balbi@ti.com, Paul Walmsley <paul@pwsan.com>,
linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org, khilman@ti.com, b-cousson@ti.com,
gadiyar@ti.com, sameo@linux.intel.com, parthab@india.ti.com,
tony@atomide.com, johnstul@us.ibm.com, vishwanath.bs@ti.com
Subject: Re: [PATCH 3/5 v12] arm: omap: usb: register hwmods of usbhs
Date: Fri, 30 Sep 2011 12:32:32 +0300 [thread overview]
Message-ID: <20110930093231.GD3458@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <CAP05o4+Ww=R-hOVMbW5St2ZvwrK5cmPtM5_5Gj2pV8W1tdiQ-Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]
Hi,
On Fri, Sep 30, 2011 at 02:56:40PM +0530, Munegowda, Keshava wrote:
> >> >> Usually there's something wrong with omap_devices that contain
> >> >> multiple hwmods. Is there some reason why there isn't a separate driver
> >> >> for the TLL? Judging by a brief look at drivers/mfd/omap_usb_host.c, the
> >> >> TLL handling looks logically distinct?
> >> >
> >> > Yes, I have the same feeling. To my understanding, USB Host Subsystem on
> >> > OMAP is composed of the Transceiver-less link (TLL) and USB Host (UHH).
> >> > Aparently, they could be handled by separate drivers.
> >> >
> >> > --
> >> > balbi
> >>
> >> yes, it can be as two separate drivers for uhh and tll; But i don't
> >> think driver can be used effectively.
> >> Now ehci and ohci gets the clocks , config reg and port settings
> >> through usb host which is sufficient.
> >> If you make them as two different drivers; then ehci and ohci has to
> >> interact with both the drivers separately.
> >> which will be an unnecessary complications. I feel not divided this
> >> driver into two
> >
> > Come again, EHCI/OHCI need clocks from UHH and TLL ?? If that's the
> > case, then there's really no easy way to handle this as a device can
> > have only one parent.
>
> yes, if you are using ehci phy mode ( port modes of UHH_HOSTCONFIG register)
> then uhh functional ( omap3: interface clocks too) is sufficient;
> if you are using ehci in tll mode , then you need tll functional clock too.
But those clocks are fed into UHH and TLL respectively, not EHCI/OHCI,
right ? IOW, EHCI/OHCI only need those clocks to be stable in order for
it to work.
I'm trying to think of a way to decouple that but nothing comes to mind
right now... Ideally, calling pm_runtime_get_sync() on EHCI/OHCI would
make all clocks enabled and the only way I see for that to happen is to
make TLL parent of UHH which is parent of EHCI/OHCI, but I'm not sure
that makes a lot of sense.
Paul, do you have any tip which we could use ? What we need is to be
able to call pm_runtime_get_sync() or ehci-omap.c and that should enable
UHH clocks and if (port->mode == TLL) enable TLL clocks.
We still want to split UHH and TLL into separate drivers.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2011-09-30 9:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 5:41 [PATCH 3/5 v12] arm: omap: usb: register hwmods of usbhs Keshava Munegowda
2011-09-30 7:15 ` Paul Walmsley
2011-09-30 7:34 ` Felipe Balbi
2011-09-30 9:15 ` Munegowda, Keshava
2011-09-30 9:19 ` Felipe Balbi
2011-09-30 9:26 ` Munegowda, Keshava
2011-09-30 9:32 ` Felipe Balbi [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-09-29 14:24 [PATCH 0/5 v12] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers Keshava Munegowda
2011-09-29 14:24 ` [PATCH 1/5 v12] arm: omap: usb: ehci and ohci hwmod structures for omap4 Keshava Munegowda
2011-09-29 14:24 ` [PATCH 2/5 v12] arm: omap: usb: ehci and ohci hwmod structures for omap3 Keshava Munegowda
2011-09-29 14:24 ` [PATCH 3/5 v12] arm: omap: usb: register hwmods of usbhs Keshava Munegowda
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=20110930093231.GD3458@legolas.emea.dhcp.ti.com \
--to=balbi@ti.com \
--cc=b-cousson@ti.com \
--cc=gadiyar@ti.com \
--cc=johnstul@us.ibm.com \
--cc=keshava_mgowda@ti.com \
--cc=khilman@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=parthab@india.ti.com \
--cc=paul@pwsan.com \
--cc=sameo@linux.intel.com \
--cc=tony@atomide.com \
--cc=vishwanath.bs@ti.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