Prev: [PATCH -mm 2/3] call_usermodehelper: simplify/fix UMH_NO_WAIT case
Next: [PATCH -mmotm 3/5] page_cgroup: introduce file cache flags
From: Corentin Chary on 16 Mar 2010 03:00 On Sat, Mar 13, 2010 at 1:50 PM, Fabio Comolli <fabio.comolli(a)gmail.com> wrote: > Well, I'm confused. > > I rebooted with the "vanilla" eeepc-laptop.c and I'm sorry to say that > the situation it's not like the one I described in the post I wrote 2 > days ago. Actually the situation with the patch reverted is the same I > have with the patch applied. > > What I mean is that if I boot on AC power /proc/cpuinfo always reports > 900MHz and 1800 bogomips. It I boot on battery /proc/cpuinfo always > reports 630MHz and 1260 bogomips. Plugging / unplugging the AC does > not change the situation. Only reboot does. > > But the cpufv interface does indeed seem to work, as glxgears and > stellarium show the frame rate change accordingly to the powersave / > performance selection. > > So my question is: what does really the cpufv interface do? Is it > supposed to change the processor frequency? Or does it change > something else? > > And if the answer to the latest question is affirmative, why > /proc/cpuinfo seems to ignore it? > > Sorry for the confusion. > Regards, > Fabio > Here is what I can read in your DSDT: When INIT or _Q31 is called, the bios check the the battery is present, and call FSBA(0) or FSBA(1). _Q31 seems to be called by an hotkey, could you run "acpi_listen" and search the hotkey that generate 0x50 or 0x51 ? FSBA is the method called by CFVS. When you do "echo 1 > cpufv" it calls CFVS(1), then FSBA(1). FSBA got 2 presets on 900. Using these presets, is write some bytes to the EC and to something wich sounds like clock (RCLK, WCKB, WLCK) By the name it seems that it set the FSB, it may also surely change the CPU Clock. Now, I don't know why cpuinfo always show the same value, maybe because the cpu clock is not changed by a cpufreq driver. -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Fabio Comolli on 16 Mar 2010 16:40 Hi. On Tue, Mar 16, 2010 at 7:54 AM, Corentin Chary <corentin.chary(a)gmail.com> wrote: > On Sat, Mar 13, 2010 at 1:50 PM, Fabio Comolli <fabio.comolli(a)gmail.com> wrote: >> Well, I'm confused. >> >> I rebooted with the "vanilla" eeepc-laptop.c and I'm sorry to say that >> the situation it's not like the one I described in the post I wrote 2 >> days ago. Actually the situation with the patch reverted is the same I >> have with the patch applied. >> >> What I mean is that if I boot on AC power /proc/cpuinfo always reports >> 900MHz and 1800 bogomips. It I boot on battery /proc/cpuinfo always >> reports 630MHz and 1260 bogomips. Plugging / unplugging the AC does >> not change the situation. Only reboot does. >> >> But the cpufv interface does indeed seem to work, as glxgears and >> stellarium show the frame rate change accordingly to the powersave / >> performance selection. >> >> So my question is: what does really the cpufv interface do? Is it >> supposed to change the processor frequency? Or does it change >> something else? >> >> And if the answer to the latest question is affirmative, why >> /proc/cpuinfo seems to ignore it? >> >> Sorry for the confusion. >> Regards, >> Fabio >> > > Here is what I can read in your DSDT: > > When INIT or _Q31 is called, the bios check the the battery is > present, and call FSBA(0) or FSBA(1). > _Q31 seems to be called by an hotkey, could you run "acpi_listen" and > search the hotkey that generate 0x50 or 0x51 ? This is the output requested. hotkey ATKD 0000002e 00000000 hotkey ATKD 0000002f 00000000 hotkey ATKD 00000030 00000000 hotkey ATKD 00000012 00000000 hotkey ATKD 00000013 00000000 hotkey ATKD 00000014 00000000 hotkey ATKD 00000015 00000000 hotkey ATKD 00000010 00000000 button/sleep SLPB 00000080 00000001 hotkey ATKD 00000010 00000001 > > FSBA is the method called by CFVS. When you do "echo 1 > cpufv" it > calls CFVS(1), then FSBA(1). > FSBA got 2 presets on 900. > > Using these presets, is write some bytes to the EC and to something > wich sounds like clock (RCLK, WCKB, WLCK) > By the name it seems that it set the FSB, it may also surely change > the CPU Clock. > > Now, I don't know why cpuinfo always show the same value, maybe > because the cpu clock is not changed > by a cpufreq driver. Well, the cpuinfo frequency value seems to be set only at boot: 630 if booting from battery, 900 from AC. > > -- > Corentin Chary > http://xf.iksaif.net > Thanks, Fabio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Corentin Chary on 17 Mar 2010 04:30 On Tue, Mar 16, 2010 at 9:31 PM, Fabio Comolli <fabio.comolli(a)gmail.com> wrote: > Hi. > > On Tue, Mar 16, 2010 at 7:54 AM, Corentin Chary > <corentin.chary(a)gmail.com> wrote: >> On Sat, Mar 13, 2010 at 1:50 PM, Fabio Comolli <fabio.comolli(a)gmail.com> wrote: >>> Well, I'm confused. >>> >>> I rebooted with the "vanilla" eeepc-laptop.c and I'm sorry to say that >>> the situation it's not like the one I described in the post I wrote 2 >>> days ago. Actually the situation with the patch reverted is the same I >>> have with the patch applied. >>> >>> What I mean is that if I boot on AC power /proc/cpuinfo always reports >>> 900MHz and 1800 bogomips. It I boot on battery /proc/cpuinfo always >>> reports 630MHz and 1260 bogomips. Plugging / unplugging the AC does >>> not change the situation. Only reboot does. >>> >>> But the cpufv interface does indeed seem to work, as glxgears and >>> stellarium show the frame rate change accordingly to the powersave / >>> performance selection. >>> >>> So my question is: what does really the cpufv interface do? Is it >>> supposed to change the processor frequency? Or does it change >>> something else? >>> >>> And if the answer to the latest question is affirmative, why >>> /proc/cpuinfo seems to ignore it? >>> >>> Sorry for the confusion. >>> Regards, >>> Fabio >>> >> >> Here is what I can read in your DSDT: >> >> When INIT or _Q31 is called, the bios check the the battery is >> present, and call FSBA(0) or FSBA(1). >> _Q31 seems to be called by an hotkey, could you run "acpi_listen" and >> search the hotkey that generate 0x50 or 0x51 ? > > This is the output requested. > > hotkey ATKD 0000002e 00000000 > hotkey ATKD 0000002f 00000000 > hotkey ATKD 00000030 00000000 > hotkey ATKD 00000012 00000000 > hotkey ATKD 00000013 00000000 > hotkey ATKD 00000014 00000000 > hotkey ATKD 00000015 00000000 > hotkey ATKD 00000010 00000000 > button/sleep SLPB 00000080 00000001 > hotkey ATKD 00000010 00000001 None of thesed generate 0x50 or 0x51, may be somehting else :/ -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Jenkins on 17 Mar 2010 10:50 On 3/13/10, Fabio Comolli <fabio.comolli(a)gmail.com> wrote: > Well, I'm confused. > > I rebooted with the "vanilla" eeepc-laptop.c and I'm sorry to say that > the situation it's not like the one I described in the post I wrote 2 > days ago. Actually the situation with the patch reverted is the same I > have with the patch applied. > > What I mean is that if I boot on AC power /proc/cpuinfo always reports > 900MHz and 1800 bogomips. It I boot on battery /proc/cpuinfo always > reports 630MHz and 1260 bogomips. Plugging / unplugging the AC does > not change the situation. Only reboot does. > > But the cpufv interface does indeed seem to work, as glxgears and > stellarium show the frame rate change accordingly to the powersave / > performance selection. > > So my question is: what does really the cpufv interface do? Is it > supposed to change the processor frequency? Yes, writing to cpufv asks the BIOS to set the CPU speed. > And if the answer to the latest question is affirmative, why > /proc/cpuinfo seems to ignore it? It's because eeepc-laptop doesn't register as a real cpufreq driver. The BIOS doesn't tell us what frequency it switches to. Theoretically you could re-use the boot code, but I'm not sure how you would make it co-operate with the cpufreq core. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Fabio Comolli on 17 Mar 2010 11:50
Hi On Wed, Mar 17, 2010 at 3:49 PM, Alan Jenkins <sourcejedi.lkml(a)googlemail.com> wrote: > On 3/13/10, Fabio Comolli <fabio.comolli(a)gmail.com> wrote: >> Well, I'm confused. >> >> I rebooted with the "vanilla" eeepc-laptop.c and I'm sorry to say that >> the situation it's not like the one I described in the post I wrote 2 >> days ago. Actually the situation with the patch reverted is the same I >> have with the patch applied. >> >> What I mean is that if I boot on AC power /proc/cpuinfo always reports >> 900MHz and 1800 bogomips. It I boot on battery /proc/cpuinfo always >> reports 630MHz and 1260 bogomips. Plugging / unplugging the AC does >> not change the situation. Only reboot does. >> >> But the cpufv interface does indeed seem to work, as glxgears and >> stellarium show the frame rate change accordingly to the powersave / >> performance selection. >> >> So my question is: what does really the cpufv interface do? Is it >> supposed to change the processor frequency? > > Yes, writing to cpufv asks the BIOS to set the CPU speed. OK > >> And if the answer to the latest question is affirmative, why >> /proc/cpuinfo seems to ignore it? > > It's because eeepc-laptop doesn't register as a real cpufreq driver. > The BIOS doesn't tell us what frequency it switches to. Theoretically > you could re-use the boot code, but I'm not sure how you would make it > co-operate with the cpufreq core. OK, now I understand. Thanks. So it seems that the only way to get the actual CPU frequency is to query the cpufv sysfs file. Good to know. Unless someone with the required knowledge comes up with the code needed to register eeepc-laptop as a real cpufreq driver (hint, hint :-) ) > > Alan > Thanks, Fabio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |