maemo.org - Talk - BFS for the power kernel

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - BFS for the power kernel (https://talk.maemo.org/showthread.php?t=58780)

Re: BFS for the power kernel

FWIW,

fcam-drivers and bleeding-edge-wl1251 will need to be rebuilt against the headers for the most recent bfs6 builds. I'm looking at you, Tigerite :P

Re: BFS for the power kernel

IDont, according to last irc meeting @ mamemo-kernel-power, Pali will be releasing kp49 quickly (mostly, to fix bug known as "save as"), so he won't be able to introduce *every* path created by colin.stephane and freemangordon up to date (for example, further tweaking of FM transmitter API's).

That mean bfs kernel will be "little" ahead - which I think is all right due to spirit of project :) Just posting this, to avoid confusion, when You'll find out that some updates you've included didn't made it to kp49. "they" will, just later.

It's also possible (but I think unlikely) that patches to be found on kp49 will be tweaked a little further before releasing (compared to ones from link I've provided), so it may be good to keep an eye on code and update things that seems sane.

I know it sounds little messy, I hope freemangordon and colin.stephane will finally request maintainership and we're gonna get more predictable update stream ;)

Re: BFS for the power kernel

this is the most amazing mod ive ever done. without fail. i would suggest it has made my device about 35 percent faster. overclocked to 1100, the same as i had with power48. and limiting the scaling to 4 frequencies. the speed is phenominal. fantastic work everyone! im chuffed!

*edit. only thing is tactile feedback seems to have been enabled and i dunno how to turn it off. seems to vibrate slightly when pressing screen. any ideas?

Re: BFS for the power kernel

just uninstall it.

apt-get remove tactile

Re: BFS for the power kernel

i get 'tactile is not installed so not removed'.

also when opening xterm get....

BusyBox v1.19.2 (Debian 1.19.2power1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

-sh: /home/user/.bashrc: line 5: can't create /dev/cgroup/cpu/user/2600/tasks: nonexistent directory
-sh: /home/user/.bashrc: line 5: can't create /dev/cgroup/cpu/user/2600/notify_on_release: nonexistent directory

*edit.... now im really confused about the tactile vibration. i dont have it installed, its set to 0 in the cssu transitions.ini. it seems to only vibrate sometimes and vary in vibration. what on earth?!

*edit 2.... fixed it! was just the touch vibration option under display. durrr. somehow reenabled on install

Re: BFS for the power kernel

Quote:

Originally Posted by hawaii (Post 1088562)

FWIW,

fcam-drivers and bleeding-edge-wl1251 will need to be rebuilt against the headers for the most recent bfs6 builds. I'm looking at you, Tigerite :P

I haven't got any experience with building the bleeding-edge wl1251 driver, but here are the fcam-drivers: https://garage.maemo.org/frs/downloa....7-2_armel.deb.
I've modified the source to include kernel-bfs' fcam drivers next to the ones for kernel-power and kernel-omap, instead of having one of the last two replaced. This new fcam package should be pushable to Maemo's repositories too.

By the way, about the wlan1251 driver, pali noted it's on his TODO list to look into integrating it into kernel-power, which would IMO be a really nice and clean solution.

Quote:

Originally Posted by Estel (Post 1088650)

That mean bfs kernel will be "little" ahead - which I think is all right due to spirit of project :) Just posting this, to avoid confusion, when You'll find out that some updates you've included didn't made it to kp49. "they" will, just later.

We've been there before; It's just that we hadn't made any releases back then ;).

Quote:

Originally Posted by Estel (Post 1088650)

It's also possible (but I think unlikely) that patches to be found on kp49 will be tweaked a little further before releasing (compared to ones from link I've provided), so it may be good to keep an eye on code and update things that seems sane.

I'll keep an eye on the source, thanks for mentioning.

Quote:

Originally Posted by imacmillan (Post 1088840)

Whoa, I'm glad you're content with kernel-bfs :)

Re: BFS for the power kernel

Quote:

Originally Posted by iDont (Post 1086102)

In my experience, some short distortion means that the problem is still there, and that you'll eventually get a more severe distorted call later. Please do report back though :).

I've been talking with Tigerite about releasing kernel-bfs to Maemo's repositories with only the BFS patches enabled up to v0.330. This because of the following reasons:
a) I don't see the distortion being fixed anytime soon
b) kernel-bfs has some advantages over kernel-power. For example the -ck patches. (Subjective point)
c) BFS 330 is still BFS. Whilst it isn't the latest version, it still offers BFS' (design) advantages over CFS.

I've been running this configuration as my stable configuration for several weeks now, without any issues. Expect this release soon.

yeah you were right... the call distortion came back now to an extent where I had them even a few times a day. strange thing though that I haven't experienced it even once in some days after the cssu update.

anyway I'm just giving the new kernel with bfs 330 a try and it's working pretty smooth, thanks!

Re: BFS for the power kernel

Hey iDont, I have idea, that may make BFS kernel even more bleeding-edge ;)

As You may remember, there was a path in power-kernel tree, that allowed bq27x00_battery module and BME to live together (happily). Path was turned off, due to it being violating standards (theoretically, bq_27x00_battery and BME should not access same i2c). Ho ever, there was *never* true report of it causing any problems (every one I've heard of, resulted in finding other source of problems), so decision was rather "ideological" than practical. AFAIK, no one know why it worked perfectly (when theoretically, it should not), and we won't know, cause BME is closed source - there is possibility, that something there is also "out of standards"l, allowing combo to work ;)

If You could enable it in BFS kernel, many, many people would be happy penguins (including me ;) ). I'm sure it would bring quite wider audience for project, but, more importantly, it would be in spirit of project - incorporating features that are working great and bringing joy, but denied mainline ;)

/Estel

// Edit

If someone wonder, why even bother - let me name first thing from top of my head. Using it with advanced power monitor (and after calibrating fuel gauge chip), we can make our battery status applet to show *real* amount of battery left, with mistake lower than +-0,1% (absolutely true mAh readings + battery percentage readings).

Re: BFS for the power kernel

Quote:

Originally Posted by Estel (Post 1096766)

Hey iDont, I have idea, that may make BFS kernel even more bleeding-edge ;)

Well, being bleeding-edge is not a goal in itself; it just happens to come with many goodies ;)

Quote:

Originally Posted by Estel (Post 1096766)

As You may remember, there was a path in power-kernel tree, that allowed bq27x00_battery module and BME to live together (happily). Path was turned off, due to it being violating standards (theoretically, bq_27x00_battery and BME should not access same i2c). Ho ever, there was *never* true report of it causing any problems (every one I've heard of, resulted in finding other source of problems), so decision was rather "ideological" than practical. AFAIK, no one know why it worked perfectly (when theoretically, it should not), and we won't know, cause BME is closed source - there is possibility, that something there is also "out of standards"l, allowing combo to work ;)

If You could enable it in BFS kernel, many, many people would be happy penguins (including me ;) ). I'm sure it would bring quite wider audience for project, but, more importantly, it would be in spirit of project - incorporating features that are working great and bringing joy, but denied mainline ;)

Yes, I've noticed the whole i2c-dev patch discussion on IRC. Personally, I think the patch should be left disabled. I know there aren't any confirmed reports on it causing trouble, but this doesn't alleviate the fact that you're removing a very important safety mechanism.

However, to give everyone some freedom of choice, I've created a patch that allows you to toggle the safety mechanism in question on or off at runtime. The patch consists of Matan's original patch + some sysfs code wrapped around it (from the kernel documentation, with love). I've used a slightly provocative name for the sysfs entry, but that seems only fair considering what you're actually doing ;).

If you understand the risks of the (original) patch, then here goes the tutorial:

Code:

Nokia-N900:~# cd /sys/kernel/n900/

Nokia-N900:/sys/kernel/n900# echo 1 > i2c-dev_break_ioctl

After enabling the hack, you can stop/start bme even though bq27x00_battery is loaded, as desired:

Code:

Nokia-N900:/sys/kernel/n900# modprobe bq27x00_battery

Nokia-N900:/sys/kernel/n900# stop bme

bme (stop) running, process 774

bme (stop) pre-stop, process 2184

        main process 774

bme (stop) stopping, process 774

bme (stop) killed, process 774

bme (stop) post-stop, process 2187

bme (stop) waiting

Nokia-N900:/sys/kernel/n900# start bme

bme (start) waiting

bme (start) starting

bme (start) pre-start, process 2201

bme (start) spawned, process 2207

bme (start) post-start, (main) process 2207

bme (start) running, process 2207

The above scenario will result in an instant reboot when i2c-dev_break_ioctl is 0. You can also verify that the pre-KP48 path is active by checking your kernel log:

Code:

Nokia-N900:/sys/kernel/n900# dmesg | grep HACK

[  351.532806] i2c-dev: HACK: omitting lock (EBUSY)

[  351.532836] i2c-dev: HACK: omitting lock (EBUSY)

after starting BME ;)

Precompiled debs plus the patch itself can be found on kernel-bfs' garage page. Please test it and report back. I haven't got any previous experience with kobjects/sysfs, so some elements of the patch could probably be implemented in a cleaner manner. This doesn't affect its workings however. Feedback is appreciated / patches are welcome :).

p.s. I'll send the patch to pali later as well.
edit 2: patch is sent. Pali replied that he's already working on a different solution which works by redirecting ioctls. That solution allows us to have both bq27x00_battery and bme working together without removing the safety mechanism in i2c-dev. There's no ETA on that yet though.

Re: BFS for the power kernel

hello iDont just wanna ask is the call distortion problem still exist on the current builds?