linux-kernel - Re: [PATCH 3/5 v12] arm: omap: usb: register hwmods of usbhs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 30 Sep 2011 12:32:32 +0300
From:	Felipe Balbi <balbi@...com>
To:	"Munegowda, Keshava" <keshava_mgowda@...com>
Cc:	balbi@...com, Paul Walmsley <paul@...an.com>,
	linux-usb@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org, khilman@...com, b-cousson@...com,
	gadiyar@...com, sameo@...ux.intel.com, parthab@...ia.ti.com,
	tony@...mide.com, johnstul@...ibm.com, vishwanath.bs@...com
Subject: Re: [PATCH 3/5 v12] arm: omap: usb: register hwmods of usbhs

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

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)