Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 30 Sep 2011, Munegowda, Keshava wrote:

> On Fri, Sep 30, 2011 at 2:02 PM, Paul Walmsley <paul@xxxxxxxxx> wrote:
> > On Wed, 28 Sep 2011, Munegowda, Keshava wrote:
> >
> >> Thanks paul,
> >>
> >> But In USB Host case, there is a challenge!
> >>
> >> I need both usbhost_48m_fck and usbhost_120m_fck to be turned on when
> >> I invoke pm_runtime_get_sync ; so there are couple of options to do this
> >>
> >> 1. use clk_get with hard coded  usbhost_120m_fck name in  usbhs driver
> >>        enable this clock after invoking pm_runtime_get_sync
> >>
> >> 2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable
> >>            main clock as well as optional clocks
> >>
> >> please comment on these two approaches..
> >
> > Looks like you picked approach #1 which is fine with me.
> >
> > Here's what I don't understand about how this clock is used, though.
> > According to the 34xx TRM vZR Section 24.2.3.1.2 "High-Speed USB Host
> > Subsystem Clocks", this is only used to "clock EHCI controller internal
> > logic".  So if EHCI is not being used, it would seem to me that this clock
> > shouldn't be enabled?  But patch #5 seems to enable and disable it
> > unconditionally.  Am I missing something here?
> 
> OK. are you suggesting that this clock should be enabled/disabled; only
> if atleast one port is selected for ehci?

Seems to make sense to me?  If the clock really isn't needed for OHCI, 
then it shouldn't be enabled when only OHCI is in use?


- Paul

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux