Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
> On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
> >> Hi paul and Felipe
> >>
> >> Here is the highlights of the change in the design of  USB Host which
> >> we can do after kernel 3.2 release;
> >>
> >> 1. separate the TLL changes  from UHH
> >> 2. The TLL is be a new platform driver in ./drivers/mfd
> >> 3. the TLL platform driver will export apis  for enable/disable clocks
> >> and settings.
> >
> > TLL should control its clocks through pm_runtime APIs like anything
> > else. If you really must export APIs to be used by UHH, you need to have
> > an API so that you can claim/release a TLL channel and get/put for
> > increasing/decreasing PM counters.
> >
> > I still think though, you should try to avoid exporting OMAP-specific
> > APIs all over the place. Ideally, we would be able to have some way of
> > saying that UHH and TLL are closely related... something like having the
> > ability to say e.g. two devices are sibblings of each other, so that we
> > could ask for a sibbling to wakeup/sleep depending if we need it or not.
> 
> do we have sibling structures today? I dont think so.

no we don't.

> > Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
> > APIs is wise.
> 
> so, it means , if we can have sibling structure, then we can
> conditionally enable it right?

the conditional would still lie in UHH driver, but at least it would be
made into a generic API. I mean, you could create a generic way of
defining sibbling devices, and a generic way to make them talk to each
other.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]