> On Sun, Feb 8, 2009 at 1:30 PM, Pavel Machek <pavel@xxxxxx> 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@xxxxxx> 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
