Check status of all files in /etc/modprobe.d/ Also check file /etc/modules (all modules in this fill will be loaded, ignoring blacklist). You can also check dmesg output and find when was bq module loaded. Try also finding bq27x00_battery string in all files in /etc/: grep "bq27x00_battery" -R /etc/

After installing KP49, I switch the device off and then on and then immediately get this message:
Can't flash kernel, required files not found
Guru meditation #00000025.62017712
Hit any key to panic

And then I have to reboot to backupmenu and restore to the previous state (with kp48)

i installed kp49 with (all files are with version of 16-11):
dpkg -i kernel-power_2.6.28-10power49_armel.deb
dpkg -i kernel-power-modules_2.6.28-10power49_armel.deb
dpkg -i kernel-power-flasher_2.6.28-10power49_armel.deb
and rebooted.

@impeham:
if you want multiboot support install -bootimg package.

@pali - KP seems stable enough to be put in devel repo, what do you think?

Ok, I look at maemo package interface bug and try to push dsc package which has package interface now...

Hi today i dicided to install kp49,but i have a problem after type:
/usr/sbin/kernel-config show
the result was:
/usr/sbin/kernel-config: shift: line 352: can't shift that many

any ideas
note:i have installed: power,modules,headers,bootimg and flasher

you forgot install new -settings package

Thanks for fast answer

Bingo! It as entry in /etc/modules. I have no idea, how it appeared there - I definitely haven't put it inside, and I haven't had problems with kp48 or kernel-bfs. Anyway, it's working fine now.

---

I've tested latest kp49 with 500-900 mhz and sr_vdd1 *on*, and it's rock stable. I've stressed it with situations requiring many fast changes of used frequency, and by ones resulting in max load @900, + high power draw from battery too (700-800 mA total). Everything worked fine, without any glitches.

Now, few questions:

1. Should we also use vdd2, or is it not properly calculated yet (I remember freemangordon's post, about possible need for recalculating it too)?

2. What about situations, where CPU usage isn't high, but DSP is? Particularly, I mean 3D programs, using OpenGLES. For example, while I play Neverball, CPU is around 70% load @ 500 mhz, but - AIUI - DSP is calculating graphic, so any "slowness" situations, are caused by under-clocked (@ 500 mhz CPU) DSP.

In such situations, could we benefit from overclocking DSP to high number @ 500 mhz CPU (then, after finished with such programs, revert it back to regular profile), or I missunderstood something?

Thanks for this awesome work.

/Estel

// Edit

It seems, that vdd2 calculates 44 as value for every frequency. Doesn't sound correct, yes? It seems to stay in line with what freemangordon said about original mechanics - value calculated to work with 600, so too high for 125/250, and too low for 900.

On the other hand, vdd1 calculates all values perfectly - from 20 @ 125, to 55 @ 900.

@Estel - while calculated values for vdd2 are not optimal, it is still better to set SR for vdd2 on too, voltages will be lower than without SR.

Re DSP - DSP driver clocks the chip according to current load and maximum allowed frequency.

The logic is (from DSP side):

What my is current load? If it is above high threshold I need to call the diver to increase my frequency otherwise if it is bellow low threshold I need to call the driver to lower my frequency.

And from driver side(driven by event):
DSP wants a frequency change. OK could we go any further(up or down). If no, do nothing, otherwise check which is next DSP frequency(setup in profile file). Now, try to find valid DSP frequency which is equal or above that. Setup MPU to OPP for that frequency. Notify DSP for frequency(OPP) change.

So, in short, DSP driver rises and lowers DSP(and MPU accordongly) frequency when needed, you don't need to play with them. And when DSP is on MPU frequency never goes bellow 500.

Valid DSP frequencies are:
90,180,360,400,430, (450?), 480,500,520,540,560,580,600

Not 100% sure for the above and too lazy now to open dspbridge.c but close enough.