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). >> you specify the latency you need not the power level. We have >> interrupts that stop working at the lowest power level and this does >> not easily translate into a latency value. > > Could clock framwork be used for this? Possibly. > 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. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
