lkml.org 
[lkml]   [2011]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
From
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.

>
> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-10-10 11:19    [W:0.052 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site