http://wiki.webos-internals.org/api.php?action=feedcontributions&feedformat=atom&user=SbromwichWebOS Internals - User contributions [en]2026-04-16T11:20:10ZUser contributionsMediaWiki 1.35.1http://wiki.webos-internals.org/index.php?title=WhoIsWho&diff=11065WhoIsWho2010-08-28T22:08:49Z<p>Sbromwich: </p>
<hr />
<div>This page lists all the WebOS Internals developers, and the projects and activities for which each is responsible. Names are listed in chronological order of officially joining the WebOS Internals team.<br />
<br />
{{AboutMe|alias=rwhitby|realname=Rod Whitby|responsibility=Founder and Project Lead for WebOS Internals and Preware |aboutme=Homebrew Ecosystem Architect. Lead developer for Save/Restore. Co-Lead developer for Preware, Govnah and UberKernel. Co-developer for a number of other packages. Oh, and a family and full-time day job too.}}<br />
<br />
{{AboutMe|alias=ka6sox|realname=Tom King|responsibility=Chief Server Infrastructure Architect and Sys-Admin Team Lead(aka BOFH)|aboutme=FT:High Power RF, VHDL/Verilog Design, Play Time: Dabble with Kernel development.}}<br />
<br />
{{AboutMe|alias=rboatright|realname=Rick Boatright|responsibility=Chief Evangelist|aboutme=}}<br />
<br />
{{AboutMe|alias=destinal|realname=|responsibility=|aboutme=}}<br />
<br />
{{AboutMe|alias=PuffTheMagic|realname=Ryan Hope|responsibility=Play devil's advocate|aboutme=Research assistant / cognitive science grad student by day; webos developer by night }}<br />
<br />
{{AboutMe|alias=egaudet|realname=Eric Gaudet|responsibility=AUPT architect|aboutme=}}<br />
<br />
{{AboutMe|alias=oil|realname=Brandon VanBelle|responsibility=Minister of Awesomeness|aboutme=It's not my fault!}}<br />
<br />
{{AboutMe|alias=dtzWill|realname=Will Dietz|responsibility=Various WebOS Internals games, X11, WIDK management|aboutme=CS grad student who spends entirely too much time on WebOS }}<br />
<br />
{{AboutMe|alias=zsoc|realname=|responsibility=Multimedia subsystem architect|aboutme=}}<br />
<br />
{{AboutMe|alias=uNiXpSyChO|realname=Marco Benton|responsibility=BOFH and Kernel hacker|aboutme=[[Full-time]]; SysAdmin, SAN Admin, Network Admin. [[Part-time]]; System integration and network design consulting. [[Free-time]]; programming - since that's what i used to do full-time 20 years ago. }}<br />
<br />
{{AboutMe|alias=sbromwich|realname=Steve Bromwich|responsibility=Kernel developer|aboutme=Dilettante kernel programmer concentrating mostly on extending battery life.}}<br />
<br />
{{AboutMe|alias=swisstomcat|realname=Markus Leutwyler|responsibility=Chief German Translator (ja, genau!) and Javascript Parts Donator to different Projects. Also European Propaganda Minister. |aboutme=Web and Mobile Developer}}<br />
<br />
{{AboutMe|alias=jhojho|realname=|responsibility=Warthog kernel developer|aboutme=}}<br />
<br />
{{AboutMe|alias=cryptk|realname=Chris Jowett|responsibility=Server administration and management|aboutme=I work as a full time linux systems administratior as my day job and lend that knowledge to keep the WebOS Internals servers running as well as they possibly can.}}<br />
<br />
{{AboutMe|alias=sconix|realname=Janne Julkunen|responsibility=Creating nice patches and developing Mode Switcher|aboutme=Involved with Linux way too much :)}}</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=How_To_Recover&diff=10570How To Recover2010-07-23T00:29:42Z<p>Sbromwich: </p>
<hr />
<div>= Pre not booting? webOS Doctor How-To =<br />
{{tux|Tux_with_Broken_Pre.png|float:right;}}<br />
Fortunately, Palm has created a tool called webOS Doctor intended for users to easily restore their devices in the event that they cannot boot for one reason or another.<br />
<br />
Note: Before Trying the following steps below. Try removing the battery first and reinsert the battery and turn on the device this will determine whether or not you need to perform the following steps.<br />
<br />
Note 2: As of WebOS 1.3.1 your USB data (Pictures, Videos, etc.) is no longer deleted during the process. Older versions of WebOS Doctor WILL DELETE ALL YOUR PERSONAL DATA ON THE DEVICE.<br />
<br />
<br />
'''Palm webOS Doctor:''' [http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html]<br />
<br />
'''All Palm WebOS Doctor Versions:''' [http://www.webos-internals.org/wiki/Webos_Doctor_Versions http://www.webos-internals.org/wiki/Webos_Doctor_Versions]<br />
<br />
After the download is complete, launch webOS Doctor:<br />
<br />
# Select you language<br />
# Accept the license agreement<br />
# Connect your Pre to you PC via USB and select "Next" when it becomes available<br />
{{tux|Tux_with_Pre_and_Screwdriver.png|float:right;}}<br />
After completion the device will reboot and present you with the activation set-up.<br />
<br />
If your PC does not recognize your Pre and you cannot go past step 3 above, try the following steps:<br />
<br />
# With the USB cable connected, completely power off the Pre (hold down the power button until the option to power off appears)<br />
# Hold down the Up button on the volume rocker<br />
# While holding the Up button, power on the Pre<br />
# "Next" should now be enabled - proceed with the recovery<br />
{{tux|Tux_with_Pre.png|float:right;}}<br />
The above steps will put the Pre into bootloader recovery mode and should allow the PC to recognize your device and proceed with the restore. In this mode the screen will display a giant USB logo instead of the usual Palm startup logo.<br />
<br />
The process usually proceeds as follows:<br />
<br />
(If you're on a Mac, you can follow the progress in /var/log/system.log)<br />
<br />
# WebOS Doctor begins<br />
# At 3%, a ramdisk is transferred to the phone, and the phone is rebooted <br />
# At 4%, the screen changes to the palm logo<br />
# At 9%, the screen changes to a big arrow pointing down to an integrated circuit<br />
# Novaterm access is available from 12% onwards<br />
# The progress bar advances by 2% increments every 20 seconds or so<br />
# If it gets stuck at 52% for more than 30 seconds, it's not going to progress further and you will need to try again.<br />
# Around 54% the filesystems are being partitioned<br />
# Around 64% the modem firmware is being reflashed<br />
# Around 72% the carrier apps are being installed<br />
# Around 82% the ROM is being verified<br />
<br />
If the process fails at 84% or later, the flash and modem have actually been written, so if you reboot you will get what you were flashing.<br />
<br />
== Modifications to the recovery process ==<br />
<br />
Between about 18% and 54% complete, you can novaterm into the device while it is being flashed, and modify the filesystem that will be run after the phone reboots (e.g. to touch /var/luna/preferences/ran-first-use).<br />
<br />
If you stay in a mounted directory, you can even cause the flashing to abort after the carrier apps are installed and just before the ROM is verified. This is another point where manual modifications can be made.<br />
<br />
After you have made your modifications, unmount any filesystems you have mounted and "tellbootie reboot".<br />
<br />
<br />
== Can't boot into recovery mode? ==<br />
<br />
In the very unlikely event that your Pre will not boot into recovery mode (indicating that your boot loader on the flash disk may be damaged or corrupted) you can try booting bootie into recovery mode over USB instead: [[Last_Resort_Emergency_BootLoader_Recovery]] '''Note that there has only been one incidence of this being required which ultimately was due to hardware failure, we do not recommend that you attempt this unless you have tried all the steps above exactly as described at least 10 times.'''<br />
<br />
Short of hardware damage, it should not be possible to "brick" a Pre.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=10473Application:SBromwichKernel2010-07-13T01:09:04Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
The kernels are currently available at http://ipkg.preware.org/feeds/webos-kernels/testing/1.4.1.1/ and can be added using any standard package manager in the standard format (deducing this is left as an exercise for the reader).<br />
<br />
= Patches applied for 1.4.1-75 =<br />
<br />
* Pulled prcm patches to help test if this is causing an issue for warthog<br />
<br />
= Patches applied for 1.4.1-63 =<br />
<br />
* defconfig patches tweaked to avoid patch collision with screenstate governor settings<br />
* Makefile patched to use cs2010q1 gcc compiler from CodeSourcery<br />
<br />
= Patches applied for 1.4.1-61 ("tebbo") =<br />
<br />
* Tweaked prcm patches to extend battery life.<br />
<br />
= Patches applied for 1.4.1-28 ("nt4cats") =<br />
<br />
* Applied patches to remove debug settings for:<br />
** board-sirloin-headset-detect.c.diff<br />
** omap_fb.c.diff<br />
** omap_misc_hsuart.c<br />
** pm_cpuidle.c.diff <br />
<br />
This may reduce the "high load on wakeup" that some people are seeing.<br />
<br />
= Patches applied for 1.4.1-26 ("yoda") =<br />
<br />
* wfi instruction re-enabled after several sources confirmed it did not hinder<br />
* Tweaked timeouts for prcm bitbanging, particularly with DOM_PER to see if that reduces battery drain at the expense of (possibly) more hangs coming out of suspend.<br />
<br />
= Patches applied for 1.4.1-25 ("adric") =<br />
<br />
* wfi instruction on prcm fail removed to validate if this is a regression causing battery drain.<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.<br />
<br />
= Settings used with this kernel =<br />
<br />
I use the following event.d script:<br />
<br />
<tt><br />
description "Local tuning modes"<br />
start on stopped finish<br />
stop on runlevel [!2]<br />
console none<br />
script<br />
# Set governor<br />
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br />
# Set min frequency<br />
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq<br />
# Set max frequency<br />
echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq<br />
# Set io scheduler to anticipatory<br />
echo anticipatory > /sys/block/mmcblk0/queue/scheduler<br />
# Powertop Suggestion: increase the VM dirty writeback time from 5.00 to 15<br />
# seconds. 0.50s works better on flash as it has slow writes. Needs more testing.<br />
echo 50 > /proc/sys/vm/dirty_writeback_centisecs<br />
# Use YeaH TCP as it's fairer over wireless<br />
echo yeah > /proc/sys/net/ipv4/tcp_congestion_control<br />
# Don't cache route metrics since we're mobile<br />
echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save<br />
# Ramp up the tx/rx network buffers in case we get bursty<br />
echo 1048576 > /proc/sys/net/core/rmem_max<br />
echo 1048576 > /proc/sys/net/core/wmem_max<br />
echo 3000 > /proc/sys/net/core/netdev_max_backlog<br />
nohup /usr/local/bin/pt.pl > /dev/null 2>&1 &<br />
/usr/sbin/iptables -D INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT > /dev/null 2>&1<br />
/usr/sbin/iptables -I INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT<br />
echo 5 > /proc/sys/vm/laptop_mode<br />
end script<br />
# end of file<br />
</tt><br />
<br />
In addition, I am using my naive perl scheduler at http://www.fop.ns.ca/pre/pt/pt.pl to manage the CPU frequency.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=10412Application:SBromwichKernel2010-06-30T14:03:05Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
The kernels are currently available at http://ipkg.preware.org/feeds/webos-kernels/testing/1.4.1.1/ and can be added using any standard package manager in the standard format (deducing this is left as an exercise for the reader).<br />
<br />
= Patches applied for 1.4.1-63 =<br />
<br />
* defconfig patches tweaked to avoid patch collision with screenstate governor settings<br />
* Makefile patched to use cs2010q1 gcc compiler from CodeSourcery<br />
<br />
= Patches applied for 1.4.1-61 ("tebbo") =<br />
<br />
* Tweaked prcm patches to extend battery life.<br />
<br />
= Patches applied for 1.4.1-28 ("nt4cats") =<br />
<br />
* Applied patches to remove debug settings for:<br />
** board-sirloin-headset-detect.c.diff<br />
** omap_fb.c.diff<br />
** omap_misc_hsuart.c<br />
** pm_cpuidle.c.diff <br />
<br />
This may reduce the "high load on wakeup" that some people are seeing.<br />
<br />
= Patches applied for 1.4.1-26 ("yoda") =<br />
<br />
* wfi instruction re-enabled after several sources confirmed it did not hinder<br />
* Tweaked timeouts for prcm bitbanging, particularly with DOM_PER to see if that reduces battery drain at the expense of (possibly) more hangs coming out of suspend.<br />
<br />
= Patches applied for 1.4.1-25 ("adric") =<br />
<br />
* wfi instruction on prcm fail removed to validate if this is a regression causing battery drain.<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.<br />
<br />
= Settings used with this kernel =<br />
<br />
I use the following event.d script:<br />
<br />
<tt><br />
description "Local tuning modes"<br />
start on stopped finish<br />
stop on runlevel [!2]<br />
console none<br />
script<br />
# Set governor<br />
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br />
# Set min frequency<br />
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq<br />
# Set max frequency<br />
echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq<br />
# Set io scheduler to anticipatory<br />
echo anticipatory > /sys/block/mmcblk0/queue/scheduler<br />
# Powertop Suggestion: increase the VM dirty writeback time from 5.00 to 15<br />
# seconds. 0.50s works better on flash as it has slow writes. Needs more testing.<br />
echo 50 > /proc/sys/vm/dirty_writeback_centisecs<br />
# Use YeaH TCP as it's fairer over wireless<br />
echo yeah > /proc/sys/net/ipv4/tcp_congestion_control<br />
# Don't cache route metrics since we're mobile<br />
echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save<br />
# Ramp up the tx/rx network buffers in case we get bursty<br />
echo 1048576 > /proc/sys/net/core/rmem_max<br />
echo 1048576 > /proc/sys/net/core/wmem_max<br />
echo 3000 > /proc/sys/net/core/netdev_max_backlog<br />
nohup /usr/local/bin/pt.pl > /dev/null 2>&1 &<br />
/usr/sbin/iptables -D INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT > /dev/null 2>&1<br />
/usr/sbin/iptables -I INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT<br />
echo 5 > /proc/sys/vm/laptop_mode<br />
end script<br />
# end of file<br />
</tt><br />
<br />
In addition, I am using my naive perl scheduler at http://www.fop.ns.ca/pre/pt/pt.pl to manage the CPU frequency.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=10409Application:SBromwichKernel2010-06-30T00:19:26Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
The kernels are currently available at http://ipkg.preware.org/feeds/webos-kernels/testing/1.4.1.1/ and can be added using any standard package manager in the standard format (deducing this is left as an exercise for the reader).<br />
<br />
= Patches applied for 1.4.1-61 ("tebbo") =<br />
<br />
* Tweaked prcm patches to extend battery life.<br />
<br />
= Patches applied for 1.4.1-28 ("nt4cats") =<br />
<br />
* Applied patches to remove debug settings for:<br />
** board-sirloin-headset-detect.c.diff<br />
** omap_fb.c.diff<br />
** omap_misc_hsuart.c<br />
** pm_cpuidle.c.diff <br />
<br />
This may reduce the "high load on wakeup" that some people are seeing.<br />
<br />
= Patches applied for 1.4.1-26 ("yoda") =<br />
<br />
* wfi instruction re-enabled after several sources confirmed it did not hinder<br />
* Tweaked timeouts for prcm bitbanging, particularly with DOM_PER to see if that reduces battery drain at the expense of (possibly) more hangs coming out of suspend.<br />
<br />
= Patches applied for 1.4.1-25 ("adric") =<br />
<br />
* wfi instruction on prcm fail removed to validate if this is a regression causing battery drain.<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.<br />
<br />
= Settings used with this kernel =<br />
<br />
I use the following event.d script:<br />
<br />
<tt><br />
description "Local tuning modes"<br />
start on stopped finish<br />
stop on runlevel [!2]<br />
console none<br />
script<br />
# Set governor<br />
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br />
# Set min frequency<br />
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq<br />
# Set max frequency<br />
echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq<br />
# Set io scheduler to anticipatory<br />
echo anticipatory > /sys/block/mmcblk0/queue/scheduler<br />
# Powertop Suggestion: increase the VM dirty writeback time from 5.00 to 15<br />
# seconds. 0.50s works better on flash as it has slow writes. Needs more testing.<br />
echo 50 > /proc/sys/vm/dirty_writeback_centisecs<br />
# Use YeaH TCP as it's fairer over wireless<br />
echo yeah > /proc/sys/net/ipv4/tcp_congestion_control<br />
# Don't cache route metrics since we're mobile<br />
echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save<br />
# Ramp up the tx/rx network buffers in case we get bursty<br />
echo 1048576 > /proc/sys/net/core/rmem_max<br />
echo 1048576 > /proc/sys/net/core/wmem_max<br />
echo 3000 > /proc/sys/net/core/netdev_max_backlog<br />
nohup /usr/local/bin/pt.pl > /dev/null 2>&1 &<br />
/usr/sbin/iptables -D INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT > /dev/null 2>&1<br />
/usr/sbin/iptables -I INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT<br />
echo 5 > /proc/sys/vm/laptop_mode<br />
end script<br />
# end of file<br />
</tt><br />
<br />
In addition, I am using my naive perl scheduler at http://www.fop.ns.ca/pre/pt/pt.pl to manage the CPU frequency.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=10048Application:SBromwichKernel2010-05-25T12:15:01Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
The kernels are currently available at http://ipkg.preware.org/feeds/webos-kernels/testing/1.4.1.1/ and can be added using any standard package manager in the standard format (deducing this is left as an exercise for the reader).<br />
<br />
= Patches applied for 1.4.1-28 ("nt4cats") =<br />
<br />
* Applied patches to remove debug settings for:<br />
** board-sirloin-headset-detect.c.diff<br />
** omap_fb.c.diff<br />
** omap_misc_hsuart.c<br />
** pm_cpuidle.c.diff <br />
<br />
This may reduce the "high load on wakeup" that some people are seeing.<br />
<br />
= Patches applied for 1.4.1-26 ("yoda") =<br />
<br />
* wfi instruction re-enabled after several sources confirmed it did not hinder<br />
* Tweaked timeouts for prcm bitbanging, particularly with DOM_PER to see if that reduces battery drain at the expense of (possibly) more hangs coming out of suspend.<br />
<br />
= Patches applied for 1.4.1-25 ("adric") =<br />
<br />
* wfi instruction on prcm fail removed to validate if this is a regression causing battery drain.<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.<br />
<br />
= Settings used with this kernel =<br />
<br />
I use the following event.d script:<br />
<br />
<tt><br />
description "Local tuning modes"<br />
start on stopped finish<br />
stop on runlevel [!2]<br />
console none<br />
script<br />
# Set governor<br />
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br />
# Set min frequency<br />
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq<br />
# Set max frequency<br />
echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq<br />
# Set io scheduler to anticipatory<br />
echo anticipatory > /sys/block/mmcblk0/queue/scheduler<br />
# Powertop Suggestion: increase the VM dirty writeback time from 5.00 to 15<br />
# seconds. 0.50s works better on flash as it has slow writes. Needs more testing.<br />
echo 50 > /proc/sys/vm/dirty_writeback_centisecs<br />
# Use YeaH TCP as it's fairer over wireless<br />
echo yeah > /proc/sys/net/ipv4/tcp_congestion_control<br />
# Don't cache route metrics since we're mobile<br />
echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save<br />
# Ramp up the tx/rx network buffers in case we get bursty<br />
echo 1048576 > /proc/sys/net/core/rmem_max<br />
echo 1048576 > /proc/sys/net/core/wmem_max<br />
echo 3000 > /proc/sys/net/core/netdev_max_backlog<br />
nohup /usr/local/bin/pt.pl > /dev/null 2>&1 &<br />
/usr/sbin/iptables -D INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT > /dev/null 2>&1<br />
/usr/sbin/iptables -I INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT<br />
echo 5 > /proc/sys/vm/laptop_mode<br />
end script<br />
# end of file<br />
</tt><br />
<br />
In addition, I am using my naive perl scheduler at http://www.fop.ns.ca/pre/pt/pt.pl to manage the CPU frequency.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9865Application:SBromwichKernel2010-05-10T17:11:15Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
The kernels are currently available at http://ipkg.preware.org/feeds/webos-kernels/testing/1.4.1.1/ and can be added using any standard package manager in the standard format (deducing this is left as an exercise for the reader).<br />
<br />
= Patches applied for 1.4.1-26 ("yoda") =<br />
<br />
* wfi instruction re-enabled after several sources confirmed it did not hinder<br />
* Tweaked timeouts for prcm bitbanging, particularly with DOM_PER to see if that reduces battery drain at the expense of (possibly) more hangs coming out of suspend.<br />
<br />
= Patches applied for 1.4.1-25 ("adric") =<br />
<br />
* wfi instruction on prcm fail removed to validate if this is a regression causing battery drain.<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.<br />
<br />
= Settings used with this kernel =<br />
<br />
I use the following event.d script:<br />
<br />
<tt><br />
description "Local tuning modes"<br />
start on stopped finish<br />
stop on runlevel [!2]<br />
console none<br />
script<br />
# Set governor<br />
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br />
# Set min frequency<br />
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq<br />
# Set max frequency<br />
echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq<br />
# Set io scheduler to anticipatory<br />
echo anticipatory > /sys/block/mmcblk0/queue/scheduler<br />
# Powertop Suggestion: increase the VM dirty writeback time from 5.00 to 15<br />
# seconds. 0.50s works better on flash as it has slow writes. Needs more testing.<br />
echo 50 > /proc/sys/vm/dirty_writeback_centisecs<br />
# Use YeaH TCP as it's fairer over wireless<br />
echo yeah > /proc/sys/net/ipv4/tcp_congestion_control<br />
# Don't cache route metrics since we're mobile<br />
echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save<br />
# Ramp up the tx/rx network buffers in case we get bursty<br />
echo 1048576 > /proc/sys/net/core/rmem_max<br />
echo 1048576 > /proc/sys/net/core/wmem_max<br />
echo 3000 > /proc/sys/net/core/netdev_max_backlog<br />
nohup /usr/local/bin/pt.pl > /dev/null 2>&1 &<br />
/usr/sbin/iptables -D INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT > /dev/null 2>&1<br />
/usr/sbin/iptables -I INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT<br />
echo 5 > /proc/sys/vm/laptop_mode<br />
end script<br />
# end of file<br />
</tt><br />
<br />
In addition, I am using my naive perl scheduler at http://www.fop.ns.ca/pre/pt/pt.pl to manage the CPU frequency.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9864Application:SBromwichKernel2010-05-10T15:40:00Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
The kernels are currently available at http://ipkg.preware.org/feeds/webos-kernels/testing/1.4.1.1/ and can be added using any standard package manager in the standard format (deducing this is left as an exercise for the reader).<br />
<br />
= Patches applied for 1.4.1-25 ("adric") =<br />
<br />
* wfi instruction on prcm fail removed to validate if this is a regression causing battery drain.<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.<br />
<br />
= Settings used with this kernel =<br />
<br />
I use the following event.d script:<br />
<br />
<tt><br />
description "Local tuning modes"<br />
start on stopped finish<br />
stop on runlevel [!2]<br />
console none<br />
script<br />
# Set governor<br />
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br />
# Set min frequency<br />
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq<br />
# Set max frequency<br />
echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq<br />
# Set io scheduler to anticipatory<br />
echo anticipatory > /sys/block/mmcblk0/queue/scheduler<br />
# Powertop Suggestion: increase the VM dirty writeback time from 5.00 to 15<br />
# seconds. 0.50s works better on flash as it has slow writes. Needs more testing.<br />
echo 50 > /proc/sys/vm/dirty_writeback_centisecs<br />
# Use YeaH TCP as it's fairer over wireless<br />
echo yeah > /proc/sys/net/ipv4/tcp_congestion_control<br />
# Don't cache route metrics since we're mobile<br />
echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save<br />
# Ramp up the tx/rx network buffers in case we get bursty<br />
echo 1048576 > /proc/sys/net/core/rmem_max<br />
echo 1048576 > /proc/sys/net/core/wmem_max<br />
echo 3000 > /proc/sys/net/core/netdev_max_backlog<br />
nohup /usr/local/bin/pt.pl > /dev/null 2>&1 &<br />
/usr/sbin/iptables -D INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT > /dev/null 2>&1<br />
/usr/sbin/iptables -I INPUT -i eth0 -p tcp --sport 5222 -s 205.140.203.0/24 -j ACCEPT<br />
echo 5 > /proc/sys/vm/laptop_mode<br />
end script<br />
# end of file<br />
</tt><br />
<br />
In addition, I am using my naive perl scheduler at http://www.fop.ns.ca/pre/pt/pt.pl to manage the CPU frequency.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9859Application:SBromwichKernel2010-05-10T00:47:11Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
The kernels are currently available at http://ipkg.preware.org/feeds/webos-kernels/testing/1.4.1.1/ and can be added using any standard package manager in the standard format (deducing this is left as an exercise for the reader).<br />
<br />
= Patches applied for 1.4.1-25 ("adric") =<br />
<br />
* wfi instruction on prcm fail removed to validate if this is a regression causing battery drain.<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9857Application:SBromwichKernel2010-05-09T13:26:47Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
The kernels are currently available at http://ipkg.preware.org/feeds/webos-kernels/testing/1.4.1.1/ and can be added using any standard package manager in the standard format (deducing this is left as an exercise for the reader).<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SkyNet&diff=9842Application:SkyNet2010-05-09T03:03:16Z<p>Sbromwich: </p>
<hr />
<div>SkyNet is an application which manages the secure linking of webOS (and other) devices together over the internet.<br />
<br />
It uses secure exchange of ssh keys, and management of restricted rsync command lines in the authorized_keys file, to allow secure, managed, authorized transfers of files between devices.<br />
<br />
It can also be used to set up secure tunnels and VPN networks of devices using openvpn.<br />
<br />
All actions must be carefully controlled and authorised by the user, lest it become the SkyNet of the Terminator variety ...<br />
<br />
Discussion welcome on how we achieve this. Let's use this as a working page for architecture and design ideas. Just write them below.<br />
<br />
Add vpnc support.<br />
<br />
Add some sort of profile support; eg if I am at work connected through wifi on the corporate SSID I don't want the Pre to attempt to VPN in to get to work resources, and conversely at home I don't want to tunnel to my home network if I am already attached by wifi.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9841Application:SBromwichKernel2010-05-09T02:36:10Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
= Patches applied for 1.4.1-24 ("jangofett") =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 ("bobafett") =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9840Application:SBromwichKernel2010-05-09T02:33:00Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are the kernels I run on my phone with all current webos-internals testing patches applied, plus my patches, plus my kernel configuration.<br />
<br />
= Patches applied for 1.4.1-24 =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9838Application:SBromwichKernel2010-05-09T02:26:50Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own patches.<br />
<br />
= Patches applied for 1.4.1-24 =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain. This may have an adverse affect on wake from suspend.<br />
<br />
= Patches applied for 1.4.1-23 =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9835Application:SBromwichKernel2010-05-09T02:03:35Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own patches.<br />
<br />
= Patches applied for 1.4.1-24 =<br />
<br />
* Reduce number of scheduling calls made to try to reduce battery drain.<br />
<br />
= Patches applied for 1.4.1-23 =<br />
<br />
* Debug settings removed from default kernel build.<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc.<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails.<br />
* Enable preempt kernel.<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9834Application:SBromwichKernel2010-05-09T01:06:02Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own patches.<br />
<br />
= Patches applied for 1.4.1-23 =<br />
<br />
* Debug settings removed from default kernel build<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails<br />
* Enable preempt kernel<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.<br />
* Some users have reported increased battery usage when running this kernel.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9830Application:SBromwichKernel2010-05-08T17:40:13Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own patches.<br />
<br />
= Patches applied for 1.4.1-23 =<br />
<br />
* Debug settings removed from default kernel build<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails<br />
* Enable preempt kernel<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Install SmartReflex patches at your own risk. SmartReflex is not expected to work.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9829Application:SBromwichKernel2010-05-08T17:33:25Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own patches.<br />
<br />
= Patches applied for 1.4.1-23 =<br />
<br />
* Debug settings removed from default kernel build<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails<br />
* Enable preempt kernel<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.<br />
* Run SmartReflex at your own risk. It is not expected to work.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9828Application:SBromwichKernel2010-05-08T17:02:41Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own patches.<br />
<br />
= Patches applied for 1.4.1-23 =<br />
<br />
* Debug settings removed from default kernel build<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails<br />
* Enable preempt kernel<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk. Not compliant with point 6 of http://forums.precentral.net/webos-internals/241355-next-generation-kernel-development-packaging.html .<br />
* anticipatory io scheduler recommended.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9827Application:SBromwichKernel2010-05-08T15:35:54Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own patches.<br />
<br />
= Patches applied for 1.4.1-23 =<br />
<br />
* Debug settings removed from default kernel build<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails<br />
* Enable preempt kernel<br />
<br />
= Known problems =<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.<br />
<br />
= Improvements =<br />
<br />
* User interactivity latency should be lower (time to respond to keypresses, etc).<br />
* Fewer powerd wakeups allowing the system to sleep longer.<br />
<br />
= Warnings =<br />
<br />
* My patch makes the kernel boot at 800MHz. Run this kernel at your own risk.<br />
* anticipatory io scheduler recommended</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9826Application:SBromwichKernel2010-05-08T15:29:11Z<p>Sbromwich: </p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own. Currently these are:<br />
<br />
* Debug settings removed from default kernel build<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails<br />
* Enable preempt kernel<br />
<br />
Known problems:<br />
<br />
* Pre can take some extra time to respond to certain activities, especially when waking up; lags of up to 2 seconds can be experienced on wakeup. The alternative is a reboot, which will take even longer.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:SBromwichKernel&diff=9796Application:SBromwichKernel2010-05-06T01:00:51Z<p>Sbromwich: New page: The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own. Currently these are: * Debug settings removed from default kernel bui...</p>
<hr />
<div>The sbromwich series of kernels are my kernels with all current webos-internals testing patches applied, plus my own. Currently these are:<br />
<br />
* Debug settings removed from default kernel build<br />
* Compile kernel with explicit cortex-a8 tuning flags for gcc<br />
* Tweak prcm power manager to more explicitly wait for power set calls to return, remove debug cruft, and add Wait For Interrupt instruction if a prcm setting attempt fails<br />
* Enable preempt kernel</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9795Adding patches through git2010-05-06T00:50:46Z<p>Sbromwich: </p>
<hr />
<div>'''WIP incomplete'''<br />
<br />
Add kernel patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rwhitby is able to do this)<br />
* GPL compliant patch to submit (preferably with a .patch extension)<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <br />
<br />
<source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source><br />
<br />
A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <br />
<br />
<source lang="text">git tag -l</source><br />
<br />
In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <br />
<br />
<source lang="text">git push ; git push --tags</source> <br />
<br />
For example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
= Commit the tagged files to git =<br />
<br />
Committing the tagged files is the following three step process:<br />
<br />
* git add filenames<br />
* git commit -m "commit message" filenames<br />
* git push<br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git add *<br />
mason~/kernels/patches/prcm$ git commit -m "PRCM resume from suspend fix/kludge" *<br />
Created commit 16fbb97: PRCM resume from suspend fix/kludge<br />
3 files changed, 84 insertions(+), 0 deletions(-)<br />
create mode 100644 prcm/README<br />
create mode 100644 prcm/prcm_clk.c.diff<br />
create mode 100644 prcm/proc_pwr.c.diff<br />
mason~/kernels/patches/prcm$ git push<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 7, done.<br />
Compressing objects: 100% (6/6), done.<br />
Writing objects: 100% (6/6), 1.96 KiB, done.<br />
Total 6 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
b949e1d..16fbb97 master -> master<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
= Uh-oh, I screwed up a commit - how do I remove a file? =<br />
<br />
If you inadvertently commit a file in error, it is easy to remove with <br />
<br />
<source lang="text"><br />
git remove filename<br />
git commit -m "commit message" filename<br />
</source><br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/build/hardware/uber-kernel-pre/build$ git rm src-1.4.1-6/linux-2.6.24/.config<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/.config'<br />
mason~/build/hardware/uber-kernel-pre/build$ git commit -m "Removing .config that should not have been committed in the first place" src-1.4.1-6/linux-2.6.24/.config<br />
Created commit cd95fd3: Removing .config that should not have been committed in the first place<br />
1 files changed, 0 insertions(+), 1892 deletions(-)<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/.config<br />
mason~/build/hardware/uber-kernel-pre/build$ <br />
</source><br />
<br />
If you have modified the file, you will need to force the commit with the -f flag, as follows:<br />
<br />
<source lang="text"><br />
mason~/build/hardware/uber-kernel-pre/build$ git rm -f src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c'<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h'<br />
mason~/build/hardware/uber-kernel-pre/build$ git commit -m "Removing commits that should not have been committed" src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
Created commit 73eb872: Removing commits that should not have been committed<br />
2 files changed, 0 insertions(+), 1885 deletions(-)<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
mason~/build/hardware/uber-kernel-pre/build$ <br />
</source><br />
<br />
= git conceptual tutorial =<br />
<br />
An excellent conceptual tutorial on how git works is available at http://www.eecs.harvard.edu/~cduan/technical/git/ courtesy of Charles Duan.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9774Adding patches through git2010-05-04T00:50:31Z<p>Sbromwich: Put in correct syntax for git tag</p>
<hr />
<div>'''WIP incomplete'''<br />
<br />
Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rwhitby is able to do this)<br />
* GPL compliant patch to submit (preferably with a .patch extension)<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <br />
<br />
<source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source><br />
<br />
A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <br />
<br />
<source lang="text">git tag -l</source><br />
<br />
In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <br />
<br />
<source lang="text">git push ; git push --tags</source> <br />
<br />
For example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
= Commit the tagged files to git =<br />
<br />
Committing the tagged files is the following three step process:<br />
<br />
* git add filenames<br />
* git commit -m "commit message" filenames<br />
* git push<br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git add *<br />
mason~/kernels/patches/prcm$ git commit -m "PRCM resume from suspend fix/kludge" *<br />
Created commit 16fbb97: PRCM resume from suspend fix/kludge<br />
3 files changed, 84 insertions(+), 0 deletions(-)<br />
create mode 100644 prcm/README<br />
create mode 100644 prcm/prcm_clk.c.diff<br />
create mode 100644 prcm/proc_pwr.c.diff<br />
mason~/kernels/patches/prcm$ git push<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 7, done.<br />
Compressing objects: 100% (6/6), done.<br />
Writing objects: 100% (6/6), 1.96 KiB, done.<br />
Total 6 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
b949e1d..16fbb97 master -> master<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
= Uh-oh, I screwed up a commit - how do I remove a file? =<br />
<br />
If you inadvertently commit a file in error, it is easy to remove with <br />
<br />
<source lang="text"><br />
git remove filename<br />
git commit -m "commit message" filename<br />
</source><br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/build/hardware/uber-kernel-pre/build$ git rm src-1.4.1-6/linux-2.6.24/.config<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/.config'<br />
mason~/build/hardware/uber-kernel-pre/build$ git commit -m "Removing .config that should not have been committed in the first place" src-1.4.1-6/linux-2.6.24/.config<br />
Created commit cd95fd3: Removing .config that should not have been committed in the first place<br />
1 files changed, 0 insertions(+), 1892 deletions(-)<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/.config<br />
mason~/build/hardware/uber-kernel-pre/build$ <br />
</source><br />
<br />
If you have modified the file, you will need to force the commit with the -f flag, as follows:<br />
<br />
<source lang="text"<br />
mason~/build/hardware/uber-kernel-pre/build$ git rm -f src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c'<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h'<br />
mason~/build/hardware/uber-kernel-pre/build$ git commit -m "Removing commits that should not have been committed" src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
Created commit 73eb872: Removing commits that should not have been committed<br />
2 files changed, 0 insertions(+), 1885 deletions(-)<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
mason~/build/hardware/uber-kernel-pre/build$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9709Application:Govnah2010-04-27T15:10:29Z<p>Sbromwich: </p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Rotate graphs in main screen when device is rotated as well as individual graphs.<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
*** Auto-generate wallpaper with current graphs<br />
*** Time in state - colour code from slowest freq (green) to highest freq (red)<br />
*** Load average - figures are current, 5 min and 15 min (eg 1.0 0.5 0.4). Graph all 3 with some sort of alpha blend with a parallax effect from running 15 min graph 15x slower than current, ditto for 5 min?<br />
*** Keep a record of record highest and lowest temperatures seen on the device<br />
** Power draw - display graph for power draw (sawmill?) to match to see what the device thinks the power usage is like.<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
<br />
<br />
== Governor Settings ==<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".<br />
<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
<br />
* powersave<br />
** Nothing special<br />
<br />
* performance<br />
** Nothing special<br />
<br />
<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html<br />
* http://www.pdfgeni.com/book/Performance-analysis-of-loss-based-high-speed-TCP-congestion-control-algorithms-pdf.html - collection of documents on implementation of different IPv4 congestion control methods.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Research_Pre_Boot_Process&diff=9706Research Pre Boot Process2010-04-26T16:00:25Z<p>Sbromwich: </p>
<hr />
<div>== Bootloader & kernel startup ==<br />
<br />
When the pre is starting it loads the boot.bin image into ram. This is the booloader bootie which loads the linux kernel. The Linux kernel is loaded with the following cmdline (which is build out of the env vars from bootie):<br />
<source lang=bash><br />
root=/dev/mmcblk0p2 rootwait ro fb=0x8f600000 fbcon=disable console=tty1 nduid=ea413b0b980b26d75c6658199d532472049644ae klog=0x8ff00000 klog_len=0x100000 boardtype=castle-dvt3 dsp_base=0x8f900000 dsp_len=0x600000<br />
</source><br />
<br />
When using the nova-installer-image-castle.uImage image bootie hands over the following cmdline to the kernel:<br />
<br />
<source lang=bash><br />
root=/dev/ram0 ramdisk=32768 ro fb=0x8f600000 fbcon=disable console=tty1 nduid=ea413b0b980b26d75c6658199d532472049644ae klog=0x8ff00000 klog_len=0x100000 boardtype=castle-dvt3 dsp_base=0x8f900000 dsp_len=0x600000 lastboot=recover<br />
</source><br />
<br />
The nova-installer-image-castle.uImage image uses a initrd an not an initramfs. Somehow bootie detects if the kernel which is loaded has an initrd build in. If yes, then bootie changes the cmdline for the kernel to the env var bootargs-ramdisk. <br />
<br />
You can even boot a kernel from your local host with novacom. First, log in with novaterm and run tellbootie recover. Wait for the USB logo to appear, then boot the kernel as follows:<br />
<br />
<source lang=bash><br />
novacom boot mem:// < uImage-kexecboot-2.6.24-r50-palmpre.bin<br />
</source><br />
<br />
novacom loads the kernel into ram and then boots it. The kernel is loaded with the same cmdline as mentioned above. Note that this does not write the kernel to the Pre's storage, and the next time the device is rebooted the original kernel is loaded. If the Palm logo displays but does not start glowing, your kernel has probably locked up during boot. You can also run tail -f /var/log/messages to see if the devices is re-recognised during bootup; as soon as novacom goes online you should be able to novaterm in. Note that if the device is in airline mode (phone disabled) the kernel may fail to boot.<br />
<br />
<br />
== General ==<br />
On startup /dev/root is mounted as rootfs. Then /sbin/init is called which mounts /dev/mapper/store-root as the new rootfs. Finally the init script on /dev/root calls the init script in /sbin /dev/mapper/store-root.<br />
<br />
The init script on /dev/mapper/store-root starts upstart or the miniboot.sh script in /etc.<br />
<br />
== Networking ==<br />
When upstart is starting it executes a script called usbctrl whichs load the right usb driver and configuration for novacom or usbnetworking. Depending which machine is used the g_composite driver is loaded with a different product id.<br />
<br />
<source lang=bash><br />
if [[ "$machineType" == "armv7l" ]];then<br />
if [[ -e /var/gadget/usbnet_enabled && -e /var/gadget/novacom_enabled ]]; then<br />
/sbin/modprobe -q g_composite product=0x101 || true<br />
elif [ -e /var/gadget/usbnet_enabled ]; then<br />
/sbin/modprobe -q g_composite product=0x101 || true<br />
elif [ -e /var/gadget/novacom_enabled ]; then<br />
/sbin/modprobe -q g_composite product=0x8002 || true<br />
else<br />
/sbin/modprobe -q g_composite product=0x8004 || true<br />
fi<br />
elif [[ "$machineType" == "armv6l" ]];then<br />
if [[ -e /var/gadget/usbnet_enabled && -e /var/gadget/novacom_enabled ]]; then<br />
/sbin/modprobe -q g_composite product=0x103 || true<br />
elif [ -e /var/gadget/usbnet_enabled ]; then<br />
/sbin/modprobe -q g_composite product=0x103 || true<br />
elif [ -e /var/gadget/novacom_enabled ]; then<br />
/sbin/modprobe -q g_composite product=0x8012 || true<br />
else<br />
/sbin/modprobe -q g_composite product=0x8012 || true<br />
fi<br />
else<br />
/sbin/modprobe -q g_composite || true<br />
fi<br />
</source><br />
<br />
Is the g_composite driver is build in the kernel the script changes the configuration of the gadget driver through a sysfs entry.<br />
<source lang=bash><br />
if [[ -e /var/gadget/usbnet_enabled && -e /var/gadget/novacom_enabled ]]; then<br />
echo 5 > /sys/class/usb_gadget/config_num<br />
elif [ -e /var/gadget/usbnet_enabled ]; then<br />
echo 5 > /sys/class/usb_gadget/config_num<br />
elif [ -e /var/gadget/novacom_enabled ]; then<br />
echo 2 > /sys/class/usb_gadget/config_num<br />
else<br />
echo 1 > /sys/class/usb_gadget/config_num<br />
fi<br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9705Application:Govnah2010-04-26T12:49:07Z<p>Sbromwich: </p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Rotate graphs in main screen when device is rotated as well as individual graphs.<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
*** Auto-generate wallpaper with current graphs<br />
*** Time in state - colour code from slowest freq (green) to highest freq (red)<br />
*** Load average - figures are current, 5 min and 15 min (eg 1.0 0.5 0.4). Graph all 3 with some sort of alpha blend with a parallax effect from running 15 min graph 15x slower than current, ditto for 5 min?<br />
*** Keep a record of record highest and lowest temperatures seen on the device<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".<br />
<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
<br />
* powersave<br />
** Nothing special<br />
<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html<br />
* http://www.pdfgeni.com/book/Performance-analysis-of-loss-based-high-speed-TCP-congestion-control-algorithms-pdf.html - collection of documents on implementation of different IPv4 congestion control methods.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9704Application:Govnah2010-04-26T04:36:54Z<p>Sbromwich: </p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
*** Auto-generate wallpaper with current graphs<br />
*** Time in state - colour code from slowest freq (green) to highest freq (red)<br />
*** Load average - figures are current, 5 min and 15 min (eg 1.0 0.5 0.4). Graph all 3 with some sort of alpha blend with a parallax effect from running 15 min graph 15x slower than current, ditto for 5 min?<br />
*** Keep a record of record highest and lowest temperatures seen on the device<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".<br />
<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
<br />
* powersave<br />
** Nothing special<br />
<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html<br />
* http://www.pdfgeni.com/book/Performance-analysis-of-loss-based-high-speed-TCP-congestion-control-algorithms-pdf.html - collection of documents on implementation of different IPv4 congestion control methods.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9703Application:Govnah2010-04-26T01:19:58Z<p>Sbromwich: </p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
*** Auto-generate wallpaper with current graphs<br />
*** Time in state - colour code from slowest freq (green) to highest freq (red)<br />
*** Load average - figures are current, 5 min and 15 min (eg 1.0 0.5 0.4). Graph all 3 with some sort of alpha blend with a parallax effect from running 15 min graph 15x slower than current, ditto for 5 min?<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".<br />
<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
<br />
* powersave<br />
** Nothing special<br />
<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html<br />
* http://www.pdfgeni.com/book/Performance-analysis-of-loss-based-high-speed-TCP-congestion-control-algorithms-pdf.html - collection of documents on implementation of different IPv4 congestion control methods.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9702Application:Govnah2010-04-26T01:16:20Z<p>Sbromwich: </p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
*** Auto-generate wallpaper with current graphs<br />
*** Time in state - colour code from slowest freq (green) to highest freq (red)<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".<br />
<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
<br />
* powersave<br />
** Nothing special<br />
<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html<br />
* http://www.pdfgeni.com/book/Performance-analysis-of-loss-based-high-speed-TCP-congestion-control-algorithms-pdf.html - collection of documents on implementation of different IPv4 congestion control methods.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9698Application:Govnah2010-04-25T17:14:18Z<p>Sbromwich: </p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
*** Auto-generate wallpaper with current graphs<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".<br />
<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
<br />
* powersave<br />
** Nothing special<br />
<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html<br />
* http://www.pdfgeni.com/book/Performance-analysis-of-loss-based-high-speed-TCP-congestion-control-algorithms-pdf.html - collection of documents on implementation of different IPv4 congestion control methods.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9697Application:Govnah2010-04-25T14:34:17Z<p>Sbromwich: Added pdfgeni link for TCP congestion control</p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".<br />
<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
<br />
* powersave<br />
** Nothing special<br />
<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html<br />
* http://www.pdfgeni.com/book/Performance-analysis-of-loss-based-high-speed-TCP-congestion-control-algorithms-pdf.html - collection of documents on implementation of different IPv4 congestion control methods.</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9696Application:Govnah2010-04-25T14:03:29Z<p>Sbromwich: More powersave_bias clarification and a little tidying up</p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".<br />
<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
<br />
* powersave<br />
** Nothing special<br />
<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9695Application:Govnah2010-04-25T14:01:00Z<p>Sbromwich: </p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average".<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
* powersave<br />
** Nothing special<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9694Application:Govnah2010-04-25T14:00:33Z<p>Sbromwich: Clarified powersave bias with info from Venkatesh Pallipadi</p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_themes.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
<br />
* CPU Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* IO Scheduler Scene<br />
** Dropdown to select scheduler (cfq, noop, as etc.)<br />
<br />
* TCP Congestion Algo Scene?<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
** powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization,<br />
and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average".<br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
* powersave<br />
** Nothing special<br />
* performance<br />
** Nothing special<br />
<br />
== Links ==<br />
* http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html<br />
* http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/cpufreq/TheOndemandGovernor.htm<br />
* http://fasterdata.es.net/TCP-tuning/linux.html</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9681Application:Govnah2010-04-23T12:05:36Z<p>Sbromwich: </p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_ss1.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
Available in the WebOS Internals Testing Feed<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Settings)<br />
** Current Frequency<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
<br />
* Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
=== Load Reduction ===<br />
* Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
* Use sqlite db for saving?<br />
* To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
* Preference setting for frequency of polling.<br />
* Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)<br />
<br />
=== Governor Settings ===<br />
* Generic items (needed for all)<br />
** scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies<br />
** scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.<br />
* ondemand<br />
** sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.<br />
** sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also. <br />
** up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased. <br />
** ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. <br />
* conservative<br />
** freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor. <br />
** down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased. <br />
** sampling_rate - same as ondemand.<br />
** sampling_rate_(min|max) - same as ondemand.<br />
** up_threshold - same as ondemand.<br />
** ignore_nice_load - same as ondemand.<br />
* userspace<br />
** scaling_setspeed - one of the values from scaling_available_frequencies<br />
** NB - when userspace is selected LunaSysMgr will change the frequency as it feels.<br />
* powersave<br />
** Nothing special<br />
* performance<br />
** Nothing special</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9659Adding patches through git2010-04-23T00:23:11Z<p>Sbromwich: </p>
<hr />
<div>'''WIP incomplete'''<br />
<br />
Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rwhitby is able to do this)<br />
* GPL compliant patch to submit (preferably with a .patch extension)<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <br />
<br />
<source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source><br />
<br />
A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <br />
<br />
<source lang="text">git -l</source><br />
<br />
In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <br />
<br />
<source lang="text">git push ; git push --tags</source> <br />
<br />
For example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
= Commit the tagged files to git =<br />
<br />
Committing the tagged files is the following three step process:<br />
<br />
* git add filenames<br />
* git commit -m "commit message" filenames<br />
* git push<br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git add *<br />
mason~/kernels/patches/prcm$ git commit -m "PRCM resume from suspend fix/kludge" *<br />
Created commit 16fbb97: PRCM resume from suspend fix/kludge<br />
3 files changed, 84 insertions(+), 0 deletions(-)<br />
create mode 100644 prcm/README<br />
create mode 100644 prcm/prcm_clk.c.diff<br />
create mode 100644 prcm/proc_pwr.c.diff<br />
mason~/kernels/patches/prcm$ git push<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 7, done.<br />
Compressing objects: 100% (6/6), done.<br />
Writing objects: 100% (6/6), 1.96 KiB, done.<br />
Total 6 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
b949e1d..16fbb97 master -> master<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
= Uh-oh, I screwed up a commit - how do I remove a file? =<br />
<br />
If you inadvertently commit a file in error, it is easy to remove with <br />
<br />
<source lang="text"><br />
git remove filename<br />
git commit -m "commit message" filename<br />
</source><br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/build/hardware/uber-kernel-pre/build$ git rm src-1.4.1-6/linux-2.6.24/.config<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/.config'<br />
mason~/build/hardware/uber-kernel-pre/build$ git commit -m "Removing .config that should not have been committed in the first place" src-1.4.1-6/linux-2.6.24/.config<br />
Created commit cd95fd3: Removing .config that should not have been committed in the first place<br />
1 files changed, 0 insertions(+), 1892 deletions(-)<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/.config<br />
mason~/build/hardware/uber-kernel-pre/build$ <br />
</source><br />
<br />
If you have modified the file, you will need to force the commit with the -f flag, as follows:<br />
<br />
<source lang="text"<br />
mason~/build/hardware/uber-kernel-pre/build$ git rm -f src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c'<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h'<br />
mason~/build/hardware/uber-kernel-pre/build$ git commit -m "Removing commits that should not have been committed" src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
Created commit 73eb872: Removing commits that should not have been committed<br />
2 files changed, 0 insertions(+), 1885 deletions(-)<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/arch/arm/mach-omap3pe/prcm_pwr.c<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/include/linux/vermagic.h<br />
mason~/build/hardware/uber-kernel-pre/build$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9658Adding patches through git2010-04-23T00:17:32Z<p>Sbromwich: </p>
<hr />
<div>'''WIP incomplete'''<br />
<br />
Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rwhitby is able to do this)<br />
* GPL compliant patch to submit (preferably with a .patch extension)<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <br />
<br />
<source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source><br />
<br />
A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <br />
<br />
<source lang="text">git -l</source><br />
<br />
In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <br />
<br />
<source lang="text">git push ; git push --tags</source> <br />
<br />
For example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
= Commit the tagged files to git =<br />
<br />
Committing the tagged files is the following three step process:<br />
<br />
* git add filenames<br />
* git commit -m "commit message" filenames<br />
* git push<br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git add *<br />
mason~/kernels/patches/prcm$ git commit -m "PRCM resume from suspend fix/kludge" *<br />
Created commit 16fbb97: PRCM resume from suspend fix/kludge<br />
3 files changed, 84 insertions(+), 0 deletions(-)<br />
create mode 100644 prcm/README<br />
create mode 100644 prcm/prcm_clk.c.diff<br />
create mode 100644 prcm/proc_pwr.c.diff<br />
mason~/kernels/patches/prcm$ git push<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 7, done.<br />
Compressing objects: 100% (6/6), done.<br />
Writing objects: 100% (6/6), 1.96 KiB, done.<br />
Total 6 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
b949e1d..16fbb97 master -> master<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
= Uh-oh, I screwed up a commit - how do I remove a file? =<br />
<br />
If you inadvertently commit a file in error, it is easy to remove with <br />
<br />
<source lang="text"><br />
git remove filename<br />
git commit -m "commit message" filename<br />
</source><br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/build/hardware/uber-kernel-pre/build$ git rm src-1.4.1-6/linux-2.6.24/.config<br />
rm 'hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/.config'<br />
mason~/build/hardware/uber-kernel-pre/build$ git commit -m "Removing .config that should not have been committed in the first place" src-1.4.1-6/linux-2.6.24/.config<br />
Created commit cd95fd3: Removing .config that should not have been committed in the first place<br />
1 files changed, 0 insertions(+), 1892 deletions(-)<br />
delete mode 100644 hardware/uber-kernel-pre/build/src-1.4.1-6/linux-2.6.24/.config<br />
mason~/build/hardware/uber-kernel-pre/build$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9657Adding patches through git2010-04-23T00:07:00Z<p>Sbromwich: /* Prerequisites */</p>
<hr />
<div>'''WIP incomplete'''<br />
<br />
Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rwhitby is able to do this)<br />
* GPL compliant patch to submit (preferably with a .patch extension)<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <br />
<br />
<source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source><br />
<br />
A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <br />
<br />
<source lang="text">git -l</source><br />
<br />
In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <br />
<br />
<source lang="text">git push ; git push --tags</source> <br />
<br />
For example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
= Commit the tagged files to git =<br />
<br />
Committing the tagged files is the following three step process:<br />
<br />
* git add filenames<br />
* git commit -m "commit message" filenames<br />
* git push<br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git add *<br />
mason~/kernels/patches/prcm$ git commit -m "PRCM resume from suspend fix/kludge" *<br />
Created commit 16fbb97: PRCM resume from suspend fix/kludge<br />
3 files changed, 84 insertions(+), 0 deletions(-)<br />
create mode 100644 prcm/README<br />
create mode 100644 prcm/prcm_clk.c.diff<br />
create mode 100644 prcm/proc_pwr.c.diff<br />
mason~/kernels/patches/prcm$ git push<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 7, done.<br />
Compressing objects: 100% (6/6), done.<br />
Writing objects: 100% (6/6), 1.96 KiB, done.<br />
Total 6 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
b949e1d..16fbb97 master -> master<br />
mason~/kernels/patches/prcm$<br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9656Adding patches through git2010-04-22T23:42:54Z<p>Sbromwich: </p>
<hr />
<div>'''WIP incomplete'''<br />
<br />
Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <br />
<br />
<source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source><br />
<br />
A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <br />
<br />
<source lang="text">git -l</source><br />
<br />
In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <br />
<br />
<source lang="text">git push ; git push --tags</source> <br />
<br />
For example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
= Commit the tagged files to git =<br />
<br />
Committing the tagged files is the following three step process:<br />
<br />
* git add filenames<br />
* git commit -m "commit message" filenames<br />
* git push<br />
<br />
Worked example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git add *<br />
mason~/kernels/patches/prcm$ git commit -m "PRCM resume from suspend fix/kludge" *<br />
Created commit 16fbb97: PRCM resume from suspend fix/kludge<br />
3 files changed, 84 insertions(+), 0 deletions(-)<br />
create mode 100644 prcm/README<br />
create mode 100644 prcm/prcm_clk.c.diff<br />
create mode 100644 prcm/proc_pwr.c.diff<br />
mason~/kernels/patches/prcm$ git push<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 7, done.<br />
Compressing objects: 100% (6/6), done.<br />
Writing objects: 100% (6/6), 1.96 KiB, done.<br />
Total 6 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
b949e1d..16fbb97 master -> master<br />
mason~/kernels/patches/prcm$<br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9655Adding patches through git2010-04-22T22:55:00Z<p>Sbromwich: </p>
<hr />
<div>'''WIP incomplete'''<br />
<br />
Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <br />
<br />
<source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source><br />
<br />
A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <br />
<br />
<source lang="text">git -l</source><br />
<br />
In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <br />
<br />
<source lang="text">git push ; git push --tags</source> <br />
<br />
For example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9654Adding patches through git2010-04-22T22:51:18Z<p>Sbromwich: </p>
<hr />
<div>Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <br />
<br />
<source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source><br />
<br />
A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <br />
<br />
<source lang="text">git -l</source><br />
<br />
In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <br />
<br />
<source lang="text">git push ; git push --tags</source> <br />
<br />
For example:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9653Adding patches through git2010-04-22T22:50:13Z<p>Sbromwich: </p>
<hr />
<div>Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source> . A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <source lang="text">git -l</source> . In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <source lang="text">git push ; git push --tags</source> as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9652Adding patches through git2010-04-22T22:49:30Z<p>Sbromwich: </p>
<hr />
<div>Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <source lang="text">git clone git@git.webos-internals.org:kernels/patches.git</source> . A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <source lang="text"git -l</source> . In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <source lang="text"git push ; git push --tags</source> as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9651Adding patches through git2010-04-22T22:48:17Z<p>Sbromwich: </p>
<hr />
<div>Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with <source lang="text"git clone git@git.webos-internals.org:kernels/patches.git</source> . A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with <source lang="text"git -l</source> . In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with <source lang="text"git push ; git push --tags</source> as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9650Adding patches through git2010-04-22T22:47:11Z<p>Sbromwich: </p>
<hr />
<div>Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with {{{git clone git@git.webos-internals.org:kernels/patches.git}}} . A worked example is as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
</source><br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with {{{git -l}} . In the following case, the next tag is v1.4.1-10:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
</source><br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with {{{git push ; git push --tags}}} as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9649Adding patches through git2010-04-22T22:46:34Z<p>Sbromwich: </p>
<hr />
<div>Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with {{{git clone git@git.webos-internals.org:kernels/patches.git}}} . A worked example is as follows:<br />
<br />
{{{<br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
}}}<br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with {{{git -l}} . In the following case, the next tag is v1.4.1-10:<br />
<br />
{{{<br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
}}}<br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source><br />
<br />
* Send the tagged files to the upstream repository with {{{git push ; git push --tags}}} as follows:<br />
<br />
<source lang="text"><br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
</source></div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Adding_patches_through_git&diff=9648Adding patches through git2010-04-22T22:45:04Z<p>Sbromwich: New page: Add patches to be committed to the Preware feed by following this guide. = Prerequisites = * SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rh...</p>
<hr />
<div>Add patches to be committed to the Preware feed by following this guide.<br />
<br />
= Prerequisites =<br />
<br />
* SSH key generated, with the id_dsa.pub authorised for commital on git.webos-internals.org (rhwitby is able to do this)<br />
* GPL compliant patch to submit<br />
<br />
= Initialising your local repository =<br />
<br />
* You will need to pull down the kernel/patches repository as a starting point with {{{git clone git@git.webos-internals.org:kernels/patches.git}}} . A worked example is as follows:<br />
<br />
{{{<br />
mason~/kernels$ git clone git@git.webos-internals.org:kernels/patches.git<br />
Initialized empty Git repository in /home/sbromwich/kernels/patches/.git/<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa':<br />
remote: Counting objects: 70, done.<br />
remote: Compressing objects: 100% (68/68), done.<br />
remote: Total 70 (delta 23), reused 0 (delta 0)<br />
Receiving objects: 100% (70/70), 15.21 KiB, done.<br />
Resolving deltas: 100% (23/23), done.<br />
mason~/kernels$ ls<br />
patches<br />
mason~/kernels$ ls -l<br />
total 4<br />
drwxr-xr-x 5 sbromwich sbromwich 4096 Apr 22 22:17 patches<br />
mason~/kernels$ cd patches/<br />
mason~/kernels/patches$ ls<br />
LICENSE overclocking sensors<br />
mason~/kernels/patches$ ls -l<br />
total 12<br />
-rw-r--r-- 1 sbromwich sbromwich 88 Apr 22 22:17 LICENSE<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 overclocking<br />
drwxr-xr-x 2 sbromwich sbromwich 4096 Apr 22 22:17 sensors<br />
mason~/kernels/patches$<br />
}}}<br />
<br />
* Create a directory for your patch(es) and copy them in there.<br />
<br />
= Tag patches and submit to git =<br />
<br />
* Find the next available git tag with {{{git -l}} . In the following case, the next tag is v1.4.1-10:<br />
<br />
{{{<br />
mason~/kernels/patches/prcm$ git tag -l<br />
v1.4.0-0<br />
v1.4.0-1<br />
v1.4.1-1<br />
v1.4.1-2<br />
v1.4.1-3<br />
v1.4.1-4<br />
v1.4.1-5<br />
v1.4.1-6<br />
v1.4.1-7<br />
v1.4.1-8<br />
v1.4.1-9<br />
mason~/kernels/patches/prcm$<br />
}}}<br />
<br />
* Tag the files with a meaningful commit message and the tag from the previous step:<br />
<br />
{{{<br />
mason~/kernels/patches/prcm$ git tag -a -m "PRCM resume from suspend fix/kludge" v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
}}}<br />
<br />
* Send the tagged files to the upstream repository with {{{git push ; git push --tags}}} as follows:<br />
<br />
{{{<br />
mason~/kernels/patches/prcm$ git push ; git push --tags<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Everything up-to-date<br />
Enter passphrase for key '/home/sbromwich/.ssh/id_dsa': <br />
Counting objects: 1, done.<br />
Writing objects: 100% (1/1), 187 bytes, done.<br />
Total 1 (delta 0), reused 0 (delta 0)<br />
To git@git.webos-internals.org:kernels/patches.git<br />
* [new tag] v1.4.1-10 -> v1.4.1-10<br />
mason~/kernels/patches/prcm$ <br />
}}}</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Portal:Tools&diff=9647Portal:Tools2010-04-22T22:34:55Z<p>Sbromwich: </p>
<hr />
<div>__notoc__<br />
{{portal-header|<br />
This page lists tools used in any form.<br />
}}<br />
{{portal-two-columns<br />
|column1=<br />
== webOS Internal Related Tools ==<br />
<br />
* [[Getting started|Accessing Developer Mode]]<br />
* [[Backing_Up_via_Rsync|Backing Up via Rsync]]<br />
* [[Com Palm Appinstaller]]<br />
* [[Com Palm Downloadmanager|Com Palm Downloadmanager]] <br />
* [[Crond|Crond]]<br />
* [[Detecting Application Errors, Syslog|Detecting Application Errors, Syslog]] <br />
* [[How to solve 3G data problems]]<br />
* [[Important_Personal_Data_Locations|Important Personal Data Locations]]<br />
<!--* [[/var/luna/data|/var/luna/data]]--><br />
* [[/usr/bin/lunaprop|/usr/bin/lunaprop]]<br />
* [[Java Services|Java Services]] <br />
* [[Luna Send|Luna Send]] <br />
* [[PalmDatabase.db3 File|PalmDatabase.db3 File]] <br />
<!--* [[mediadb.db3 File|mediadb.db3 File]]--><br />
<!--* [[fileindexer File|fileindexer File]]--><br />
* [[Profile.d|Profile.d]] <br />
* [[Tellbootie|Tellbootie]]<br />
* [[Webos Doctor Versions|Webos Doctor Versions]]<br />
<br />
==Cross-Compiling and Kernels==<br />
* [[Autobuilder Setup|Autobuilder Setup]]<br />
* [[WebOS Internals PDK]]<br />
* [[Cross Compiling|Cross Compiling]] <br />
* [[Custom Kernels|Custom Kernels]] <br />
* [[Optware Cross Compilation|Optware Cross Compilation]] <br />
* [[Building_a_cross_toolchain|Building a cross-toolchain for armv7 on Gentoo]]<br />
* [[Adding_patches_through_git|Adding patches through git]]<br />
<br />
|column2=<br />
==SDK Related Tools ([[Comparison of Editors|Comparison Chart]]) ==<br />
<!-- Warning Do not edit the order of the top two editors (Eclipse and Komodo) --><br />
===Eclipse===<br />
<br />
[http://www.eclipse.org/downloads/ Eclipse] is the editor officially supported by Palm. You can find the Eclipse WebOS plugin [http://developer.palm.com/index.php?option=com_content&view=article&id=1639 here].<br />
<br />
===Komodo Edit===<br />
<br />
[http://www.activestate.com/komodo_edit/ Komodo Edit] is an easy to use cross platform open source editor. Use along side the webOS [http://www.webos.templarian.com/komodo/ Add-on] for easier development. Complete [http://www.webos.templarian.com/komodo/ Code Completion] is also available for Mojo. [[Komodo|Wiki Page with Screensots and Install Guide]].<br />
<br />
===Aptana Studio===<br />
<br />
[http://www.aptana.com/studio/download Aptana Studio] is a standalone version of an Eclipse plugin. Very easy to use. You can install the Aptana WebOS plugin by directing Aptana to check [https://cdn.downloads.palm.com/sdkdownloads/1.1/eclipse-plugin/eclipse-3.4/site.xml this link]. If you do not know how to set this up, please look at official Palm documentation [http://developer.palm.com/index.php?option=com_content&view=article&id=1639 here].<br />
}}</div>Sbromwichhttp://wiki.webos-internals.org/index.php?title=Application:Govnah&diff=9645Application:Govnah2010-04-22T18:46:29Z<p>Sbromwich: Adding suggestions for load reduction from IRC conversation 20100422</p>
<hr />
<div>{{application<br />
|name=Govnah<br />
|type=webOS<br />
|version=In Development<br />
|tag=Utilities<br />
|screenshot=Govnah_ss1.png<br />
|description=}}<br />
<br />
== Summary == <br />
{{icon|Icon_WebOSInternals_Govnah.png|float:right;}}An App to do things.<br />
<br />
<br />
== Design ==<br />
* Main Scene<br />
** Title Header (like preware/wirc/etc webos-internals apps)<br />
** Current Governor (Tap to go to Governor Scene)<br />
** Misc Stats<br />
*** ...?<br />
*** Graph of CPU temp over time<br />
<br />
* Governor Scene<br />
** Dropdown to change governor (SelectList)<br />
** Form of all current settings for selected governor (dynamically generated from information provided by service)<br />
<br />
* App Icon (changes to display indication of CPU temp)<br />
<br />
* Load reduction<br />
** Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.<br />
** Use sqlite db for saving?<br />
** To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.<br />
** Preference setting for frequency of polling.<br />
** Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)</div>Sbromwich