Re: [PATCH 01/13] PM: Add wake lock api.

[Pavel Machek <pavel@ucw.cz>]

> On Sun, Feb 8, 2009 at 1:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Thu 2009-02-05 16:28:28, Arve Hj?nnev?g wrote:
> >> On Thu, Feb 5, 2009 at 1:11 AM, Pavel Machek <pavel@ucw.cz> wrote:
> >> > On Wed 2009-02-04 18:50:14, Arve Hj??nnev??g wrote:
> >> >> +A locked wakelock, depending on its type, prevents the system from entering
> >> >> +suspend or other low-power states. When creating a wakelock, you can select
> >> >> +if it prevents suspend or low-power idle states.  If the type is
> >> >> set to
> >> >
> >> > idle states are very different from suspend. Mixing them does not look
> >> > like good idea... and IIRC we already have API somewhere to prevent
> >> > deep idle states. Intel did it for their wireless cards IIRC.
> >>
> >> If you are talking about the pm_qos interface, then yes there is some
> >> overlap. We did not use the pm_qos interface since it does a linear
> >> scan for a string every time you change a requirement, and it only
> >> let
> >
> > If pm_qos code is too slow for you, just fix it!
> 
> The problem is with the api. It uses strings as handles. It was easier
> for us to just add another wakelock type since the wakelock code
> already supported two types (I have since removed one).

Please use pm_qos code.

> > Or maybe you just want to prevent low idle states as long as those
> > interrupts are claimed, no new api needed?
> 
> I thnik this is a better solution, and we do this for the main
> interrupt controller. We did not do this for gpio interrupts since we
> did not have a list.

Ok, if you can do this for gpios, too, that would be ideal.


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html