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@xxxxxx> 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:
signature.asc
Description: Digital signature
