| 00:05.48 | *** join/#maemo andril (~andril@c-73-205-135-117.hsd1.fl.comcast.net) |
| 00:18.16 | sunshavi- | hi guys. any experience compiling maemo/n800/diablo kernel with bridge utils? |
| 00:25.45 | sunshavi- | <PROTECTED> |
| 00:25.46 | sunshavi- | <PROTECTED> |
| 00:25.46 | sunshavi- | /msg NickServ SET HIDEMAIL ON |
| 01:00.23 | *** join/#maemo NIN101 (~core@mail2.quitesimple.org) |
| 01:16.03 | *** join/#maemo lobito (~lobito@190.177.221.93) |
| 01:17.57 | *** join/#maemo eMHa (~mh@p579DB9CA.dip0.t-ipconnect.de) |
| 01:20.08 | *** join/#maemo Oksana (~chatzilla@Maemo/community/council/Wikiwide) |
| 01:23.54 | sunshavi- | I'm using Circe version 2.0 with GNU Emacs 24.5.1 (of 2015-09-09) |
| 01:29.51 | *** join/#maemo beford (~beford@unaffiliated/beford) |
| 01:56.40 | *** join/#maemo Defiant (erik@f050175086.adsl.alicedsl.de) |
| 02:13.14 | *** join/#maemo sunshavi (~aramirez@190.234.106.10) |
| 02:14.14 | *** part/#maemo sunshavi (~aramirez@190.234.106.10) |
| 02:46.27 | *** join/#maemo SpeedEvil (~quassel@tor/regular/SpeedEvil) |
| 03:14.15 | *** join/#maemo FlameReaper-PC (~honoo-pc@175.137.168.63) |
| 03:22.46 | *** join/#maemo Roth (~quassel@2601:18c:c700:f254:757b:ee23:e8b1:b9c5) |
| 04:18.30 | *** join/#maemo auenf (David@120.155.29.18) |
| 04:27.43 | DocScrutinizer05 | https://github.com/TI-OpenLink/firmwares/commit/d726804dbc8dad88587b6be17716714cd91ed86c |
| 04:34.21 | *** join/#maemo githogori (~githogori@c-73-222-69-223.hsd1.ca.comcast.net) |
| 04:34.46 | DocScrutinizer05 | do NOT update wl1251-nvs.bin! |
| 04:42.07 | DocScrutinizer05 | nevermind, at least on *my* N900 the firmware is already "up to date" - strange the last commit was Felipe Balbi on Oct 2, 2013 |
| 04:46.43 | *** join/#maemo japa-fi (~jani@dsl-hkibrasgw4-50dc54-11.dhcp.inet.fi) |
| 05:11.07 | KotCzarny | doc, does that mean every n900 has unique firmware or just specific version for n900-device |
| 05:12.35 | DocScrutinizer05 | this means every wl1251 device seems to use same firmware as N900. even the NVS calibration |
| 05:13.43 | DocScrutinizer05 | and I checked on t900 (my devel device that's basically still on PR1.2) - same firmware and nvs there, dates 2010 |
| 05:14.32 | DocScrutinizer05 | so it seems Felippe Balbi checked in to github in 2013 what been shipped with N900 since 2009 |
| 05:15.07 | DocScrutinizer05 | anyway interesting stuff maybe: http://linuxwireless.org/en/users/Drivers/wl12xx/calibrator/ |
| 05:27.00 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 05:46.02 | *** join/#maemo RedW (~redw@89-76-164-87.dynamic.chello.pl) |
| 05:51.11 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 06:01.57 | *** join/#maemo sunny_s (~sunny_s@p57802862.dip0.t-ipconnect.de) |
| 06:05.18 | *** join/#maemo guerby (~guerby@ip165-ipv6.tetaneutral.net) |
| 06:14.11 | *** join/#maemo FlameReaper-PC (~honoo-pc@175.137.168.63) |
| 06:29.43 | *** join/#maemo LauRoman (~LauRoman@5-14-15-167.residential.rdsnet.ro) |
| 06:44.27 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 06:56.28 | *** join/#maemo peetah (~peetah@cha92-9-82-236-202-86.fbx.proxad.net) |
| 07:00.15 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 07:20.14 | *** join/#maemo vectis (~phil@79-65-220-10.host.pobb.as13285.net) |
| 07:31.13 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 08:48.49 | *** join/#maemo xray256 (~xray256@90.208.97.228) |
| 09:02.47 | *** join/#maemo sparetire_ (~sparetire@unaffiliated/sparetire) |
| 09:12.28 | *** join/#maemo zGrr (~grr@public-gprs351250.centertel.pl) |
| 09:12.43 | *** join/#maemo andrei1089 (~andrei108@82.137.14.52) |
| 09:57.18 | *** join/#maemo andril (~andril@73.205.135.117) |
| 10:13.54 | *** join/#maemo odin_ (~Odin@575184c1.skybroadband.com) |
| 10:15.47 | *** join/#maemo rm_work (rm_work@Maemo/community/cssu/rm-you) |
| 10:55.11 | *** join/#maemo rm_work (rm_work@Maemo/community/cssu/rm-you) |
| 10:55.50 | *** join/#maemo zap (~zap@178.130.40.87) |
| 11:18.54 | Wizzup | ~flashing |
| 11:18.54 | infobot | somebody said maemo-flashing was http://wiki.maemo.org/Updating_the_tablet_firmware, or - on linux PC - download&extract http://maemo.cloud-7.de/maemo5/patches_n_tools/maemo-my-private-workdir.tgz, cd into it, do sudo ./flash-it-all.sh |
| 11:19.04 | Wizzup | ~emmc |
| 11:19.04 | infobot | well, emmc is is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22YHFSICNA/--LID--FiRe1275051276916/AE98ED9D_RX-51_2009SE_10.2010.13-2.CENTRAL-EUROPE_PR_EMMC_MR0_ARM.bin or see ~emmc2 |
| 11:19.13 | Wizzup | ~emmc2 |
| 11:19.14 | infobot | it has been said that emmc2 is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22FGDOJCSI/--LID--FiRe1275064390175/163EC1AE_RX-51_2009SE_10.2010.13-2.IBERIA_PR_EMMC_MR0_ARM.bin, or http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22VHGOMWUG/--LID--FiRe1274862877184/E3AD4912_RX-51_2009SE_10.2010.13-2.SEAP_PR_EMMC_MR0_ARM.bin, or see emmc3 |
| 11:19.28 | KotCzarny | o.O |
| 11:19.34 | Wizzup | hm? |
| 11:19.43 | KotCzarny | ~listkeys emmc |
| 11:19.47 | Wizzup | hehe |
| 11:19.53 | Wizzup | What was the other part/image that you need to flash |
| 11:19.58 | KotCzarny | thought it will list images for every region |
| 11:19.58 | Wizzup | (I'm helping someone else get the images) |
| 11:20.07 | KotCzarny | wizzup, just use the doc's script |
| 11:20.11 | KotCzarny | ./flash-it-all.sh |
| 11:20.18 | Wizzup | ack |
| 11:20.19 | KotCzarny | it will do everything automatically |
| 11:20.39 | KotCzarny | also it will ask if you need flashing emmc too |
| 11:21.10 | Wizzup | ok, but it doesn't contain the images |
| 11:21.14 | KotCzarny | it does |
| 11:21.18 | Wizzup | I just downloaded it |
| 11:21.22 | KotCzarny | run it |
| 11:22.45 | Wizzup | right, the script fetches them |
| 11:23.03 | KotCzarny | if not present already |
| 11:23.16 | Wizzup | well, the tar is 54k |
| 11:23.19 | Wizzup | clearly they are not :P |
| 11:23.22 | Wizzup | thx. |
| 11:26.16 | *** join/#maemo Oksana (~chatzilla@Maemo/community/council/Wikiwide) |
| 11:39.08 | *** join/#maemo erlehmann (~erlehmann@89.204.135.15) |
| 11:42.42 | jon_y | ~listkeys extras |
| 11:43.03 | jon_y | ~extras-devel |
| 11:43.03 | infobot | it has been said that extras-devel is http://wiki.maemo.org/Extras-devel |
| 11:55.17 | *** join/#maemo Kabouik (~quassel@147.99.219.229) |
| 12:00.13 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 12:46.58 | *** join/#maemo DrCode (~DrCode@5.28.134.3) |
| 12:59.50 | *** join/#maemo ToJa92 (~ToJa92@90-231-48-223-no126.tbcn.telia.com) |
| 13:05.46 | *** join/#maemo ToJa92 (~ToJa92@90-231-48-223-no126.tbcn.telia.com) |
| 13:08.11 | *** join/#maemo lobito1 (~lobito@190.177.193.199) |
| 13:52.41 | *** join/#maemo beford (~beford@unaffiliated/beford) |
| 13:56.39 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 14:14.28 | *** join/#maemo futpib (~futpib@176.104.194.78) |
| 14:31.48 | *** join/#maemo DrCode (~DrCode@5.28.134.3) |
| 14:33.42 | *** join/#maemo ZetaR (~user@2602:47:3fb:fc00:c184:cbcd:b4bb:730b) |
| 14:38.28 | *** join/#maemo ssvb (~ssvb@85-76-177-33-nat.elisa-mobile.fi) |
| 14:39.12 | *** join/#maemo sunshavi (~aramirez@190.234.106.10) |
| 14:42.16 | *** join/#maemo ZetaR (~user@71.3.251.252) |
| 14:56.38 | *** join/#maemo inz (inz@inz.fi) |
| 15:06.58 | *** join/#maemo thomasjfox (~thomasjfo@rockbox/developer/thomasjfox) |
| 15:20.15 | *** join/#maemo txt-file (~txt.file@is.txtfile.eu) |
| 15:46.32 | *** part/#maemo sunshavi (~aramirez@190.234.106.10) |
| 16:38.23 | *** join/#maemo vectis (~phil@79-65-224-81.host.pobb.as13285.net) |
| 16:44.53 | *** join/#maemo darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 16:53.47 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 16:56.08 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 17:15.47 | *** join/#maemo erlehmann (~erlehmann@x4db4a311.dyn.telefonica.de) |
| 17:22.47 | *** join/#maemo Ex-Opesa (~Ex-Opesa@unaffiliated/ex-opesa) |
| 17:24.13 | *** join/#maemo rm_work (rm_work@Maemo/community/cssu/rm-you) |
| 17:32.10 | *** join/#maemo Neutron112 (~neutron@218-177-11.connect.netcom.no) |
| 17:47.09 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 17:58.18 | *** join/#maemo trumee (~trumee@c-73-155-84-209.hsd1.tx.comcast.net) |
| 18:00.31 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 18:00.39 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 18:04.00 | *** join/#maemo Kabouik (~quassel@65.76.93.92.rev.sfr.net) |
| 18:04.44 | *** join/#maemo sq-one (~sq-one@HSI-KBW-5-56-236-246.hsi17.kabel-badenwuerttemberg.de) |
| 18:30.03 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 18:31.13 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 18:35.20 | *** join/#maemo sunshavi (~aramirez@190.234.106.10) |
| 18:36.14 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 18:36.37 | *** join/#maemo futpib (~futpib@176.104.194.78) |
| 18:41.33 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 18:48.28 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 18:52.03 | *** join/#maemo phlixi_ (~phlixi@host-188-174-198-234.customer.m-online.net) |
| 18:52.13 | *** join/#maemo shamus (~shmaus@ip-206-192-194-12.marylandheights.ip.cablemo.net) |
| 19:09.20 | *** join/#maemo shentey (~shentey@x5ce10604.dyn.telefonica.de) |
| 19:19.36 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 19:20.55 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 19:29.51 | *** join/#maemo handaxe (~royden@c83-248-16-67.bredband.comhem.se) |
| 19:30.28 | *** join/#maemo Neutron112 (~neutron@ti0042a400-4979.bb.online.no) |
| 19:42.29 | *** join/#maemo LauRoman (~LauRoman@5-14-15-167.residential.rdsnet.ro) |
| 19:53.24 | *** join/#maemo zap (~zap@178.130.40.87) |
| 19:56.07 | *** join/#maemo Vajb (~Vajb@85-76-97-105-nat.elisa-mobile.fi) |
| 20:06.19 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 20:06.27 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 20:12.37 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 20:18.16 | *** join/#maemo shentey (~shentey@x5ce10604.dyn.telefonica.de) |
| 20:47.45 | *** join/#maemo shamus (~shmaus@ip-206-192-194-12.marylandheights.ip.cablemo.net) |
| 20:50.13 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 20:54.00 | *** join/#maemo trumee (~trumee@c-73-155-84-209.hsd1.tx.comcast.net) |
| 21:01.44 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 21:31.49 | *** join/#maemo RedW (~redw@89-76-164-87.dynamic.chello.pl) |
| 21:36.02 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 21:39.05 | *** join/#maemo shentey (~shentey@x5ce10604.dyn.telefonica.de) |
| 21:46.19 | *** join/#maemo stryngs (~stryngs@unaffiliated/stryngs) |
| 21:51.26 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 21:59.20 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 21:59.49 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:01.43 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:02.17 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:07.16 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:07.48 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:26.22 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:26.49 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:28.00 | Maxdamantus | Almost done translating bq27200.sh to C. |
| 22:30.39 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:31.00 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:36.30 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 22:37.41 | ShadowJK | ehh.. Pali did that kinda for the kernel version of it? |
| 22:38.27 | Maxdamantus | Kernel version as in a userspace program that reads /sys/class/power_supply/bq27200-0/registers ? |
| 22:39.12 | Maxdamantus | or kernel version as in the module that provides that directory in sysfs? |
| 22:41.07 | Wizzup | The mainline kernel has that build in yeah |
| 22:41.11 | Wizzup | afaik |
| 22:41.14 | Wizzup | built* |
| 22:41.15 | Wizzup | merged and all |
| 22:42.31 | Maxdamantus | Actually, I don't think the mainline kernel provides as much information. |
| 22:43.07 | Maxdamantus | and the module in the N900 kernel doesn't provide all that information textually. It just provides a "registers" file that you can interpret from userspace. |
| 22:43.24 | Maxdamantus | along with common things like mAh, capacity, etc in separate files. |
| 22:44.12 | Maxdamantus | (by the mainline kernel not providing that much information, I mean I don't think it provides that "registers" file, so you can't gather all that information) |
| 22:47.51 | Maxdamantus | https://gist.github.com/Maxdamantus/3b4f2fbcb2c49fc663f9 |
| 22:48.51 | DocScrutinizer05 | why do you need that in C? |
| 22:49.09 | Wizzup | Maxdamantus: have you tried mainline? |
| 22:49.32 | Maxdamantus | Wizzup: yes, and iirc, I observed what I described. |
| 22:49.54 | Maxdamantus | DocScrutinizer05: because it's a waste of CPU creating a sed process to read it. |
| 22:50.07 | Wizzup | DocScrutinizer05: he doesn't like the UNIX philosophyt :) |
| 22:50.08 | DocScrutinizer05 | hmm |
| 22:51.19 | Maxdamantus | Actually, I don't think sed is the expensive part in my modified bash part .. it's just the fact that it's doing all the arithmetic in bash. |
| 22:51.34 | Maxdamantus | which involves converting strings to ints and back again. |
| 22:51.59 | Maxdamantus | and doing normal bash reduction on strings. |
| 22:52.23 | DocScrutinizer05 | I can't find a sed invocation in bq27200.sh |
| 22:52.55 | Maxdamantus | `user 0m0.234s` vs. `user 0m0.000s` |
| 22:52.57 | ShadowJK | The i2cget calls use most of the cpu |
| 22:53.03 | ShadowJK | or whatever it was named |
| 22:53.17 | Maxdamantus | Yeah, I replaced the i2cget calls with something that reads an array produced by sed. |
| 22:53.33 | DocScrutinizer05 | huh? |
| 22:54.06 | ShadowJK | DocScrutinizer05: more like the version you had for freerunner, I think? |
| 22:54.15 | DocScrutinizer05 | prolly |
| 22:54.30 | Maxdamantus | https://gist.githubusercontent.com/Maxdamantus/0e743d419ccf8b38c278/raw/3d8cf7b691dd87147de89c500c0133ce13a137d1/gistfile1.txt |
| 22:54.35 | Maxdamantus | eval "$(sed 's/^/registers[$((/; s/=/))]=/' </sys/class/power_supply/bq27200-0/registers)" |
| 22:54.37 | DocScrutinizer05 | using the /dump aka /registers sysfs node I guess |
| 22:54.38 | Maxdamantus | ./i2cget (){ echo "${registers[$(($4))]}"; } |
| 22:56.04 | Maxdamantus | Also, the C version looks a lot cleaner. |
| 22:56.15 | DocScrutinizer05 | aha |
| 22:56.25 | DocScrutinizer05 | well, whatever pleases you :-) |
| 22:56.54 | Maxdamantus | even though most of it was translated with sed. |
| 22:58.27 | DocScrutinizer05 | http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail-perl http://maemo.cloud-7.de/maemo5/patches_n_tools/bq27k.py |
| 22:59.54 | DocScrutinizer05 | from a resources POV the I2C queries to the bq27200 schip are eating more energy than the CPU processing this stuff in whatever source language |
| 23:00.11 | DocScrutinizer05 | chip* |
| 23:01.11 | Maxdamantus | unless it's bash. |
| 23:01.40 | DocScrutinizer05 | and probably i2cdump or /sys/*/*/*/(registers|dump) is using less energy than reading the chip's registers one by one |
| 23:02.09 | DocScrutinizer05 | no, even with bash the CPU energy use is way smaller than what's eaten by I2C bus |
| 23:02.28 | DocScrutinizer05 | my guess |
| 23:02.56 | DocScrutinizer05 | CPU can actually do an insane amount of calculations with very low energy |
| 23:03.17 | DocScrutinizer05 | IO via GPIOs otoh eats electric energy by design |
| 23:09.46 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 23:16.20 | Maxdamantus | Anyway, https://gist.github.com/Maxdamantus/ada1412f3ef6ae1c440e |
| 23:19.38 | Maxdamantus | The excessive brackets are the reminants of the bash notation. |
| 23:27.11 | DocScrutinizer05 | http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail2 ;-) |
| 23:28.38 | Maxdamantus | doesn't have anything matched by that `find` |
| 23:29.27 | DocScrutinizer05 | that find is for FreeRunner |
| 23:29.35 | Maxdamantus | Ah. |
| 23:30.16 | DocScrutinizer05 | could easily get adapted to also work on N900, when bq27xx kernel module loaded (which is only the case with power kernel and BME replacement afaik) |
| 23:30.16 | Maxdamantus | and that `s3c24xx_pwm.0` presumably has a different set of registers. |
| 23:30.52 | DocScrutinizer05 | no, the registers are all the same, the chip is bq27000 on freeRunner |
| 23:31.47 | DocScrutinizer05 | the structure of /sys/*/dump is slightly different to N900's /sys/*/registers though, I guess |
| 23:32.21 | DocScrutinizer05 | s3c24xx is the SoC of Freerunner |
| 23:34.07 | DocScrutinizer05 | HDQ is the 1wire protocol of BQ27000 |
| 23:38.33 | DocScrutinizer05 | other than I2C vs HDQ interface, the Bq27200 and BQ2700 chips are identical |
| 23:42.56 | DocScrutinizer05 | but your c binary has one huge advantage: can get set suid, so normal unprivileged user may use it as well |
| 23:42.58 | *** join/#maemo Kabouik (~quassel@65.76.93.92.rev.sfr.net) |
| 23:43.26 | Maxdamantus | You can read the `registers` file from sysfs without root ime. |
| 23:43.32 | Maxdamantus | maybe that's why it's not in mainline. |
| 23:43.38 | Maxdamantus | (again, iirc) |
| 23:44.30 | DocScrutinizer05 | hmm, yeah for that sysfs registers node that's OK. However for normal users we don't have that and you need to revert to i2cget or i2cdump, and that for sure needs root permissions |
| 23:45.19 | DocScrutinizer05 | and no, there's nothing wrong with /sys/*/registers being world readable |
| 23:45.59 | Maxdamantus | wouldn't reading it constantly use more power than a busy loop? |
| 23:46.06 | Maxdamantus | unless it's throttled by the kernel module. |
| 23:46.11 | DocScrutinizer05 | sorry? |
| 23:46.29 | Maxdamantus | dunno if it does the commands over i2c every time it's read. |
| 23:46.47 | DocScrutinizer05 | shouldn't afaik |
| 23:47.03 | DocScrutinizer05 | but that's err, what's the point? |
| 23:47.06 | Maxdamantus | I remember looking at the source code for it, can't remember what I found. |
| 23:47.24 | Maxdamantus | if it uses lots of power issuing commands over i2c, as you said earlier. |
| 23:47.46 | DocScrutinizer05 | still don't get the "wouldn't reading it constantly use more power than a busy loop?" |
| 23:47.47 | *** part/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 23:47.55 | *** join/#maemo L29Ah (~L29Ah@nezmar.jabbim.cz) |
| 23:48.00 | Maxdamantus | 11:02:09 < DocScrutinizer05> no, even with bash the CPU energy use is way smaller than what's eaten by I2C bus |
| 23:48.03 | Maxdamantus | 11:02:56 < DocScrutinizer05> CPU can actually do an insane amount of calculations with very low energy |
| 23:48.06 | Maxdamantus | 11:03:17 < DocScrutinizer05> IO via GPIOs otoh eats electric energy by design |
| 23:48.36 | DocScrutinizer05 | where do I mention a busy loop there? |
| 23:49.36 | Maxdamantus | You're saying that the computations involved in handling the results of the i2c reads are going to use less power than the i2c reads themselves. |
| 23:49.46 | DocScrutinizer05 | yes |
| 23:50.20 | Maxdamantus | so if someone intentionally or accidentally drained power using a busy loop, it wouldn't be as effective as draining the power using a busy i2c reading loop. |
| 23:50.40 | DocScrutinizer05 | err, yes |
| 23:51.10 | DocScrutinizer05 | for whatever reason somebody would want to do that, the mere statement is correct |
| 23:51.35 | Maxdamantus | Right, and that might be something mainline would be concerned about. |
| 23:51.44 | DocScrutinizer05 | why? |
| 23:51.49 | DocScrutinizer05 | and how? |
| 23:52.09 | Maxdamantus | because the ability to use computing power is a given for userspace. |
| 23:52.26 | Maxdamantus | as well as power involved in hardware it has access to through /dev etc |
| 23:52.40 | Maxdamantus | both of those things can be controlled using already well-undestood means (ulimit, file permissions) |
| 23:52.58 | Maxdamantus | if you can waste power just by reading files in /sys, it's kind of weird and unexpected. |
| 23:53.10 | DocScrutinizer05 | err, really? |
| 23:53.13 | Wizzup | uh |
| 23:53.16 | Maxdamantus | I imagine so. |
| 23:53.17 | Wizzup | that stuff is on-demand |
| 23:53.27 | Wizzup | it's not all reading-from-kernel-structures |
| 23:53.32 | Maxdamantus | tar -c /sys >/dev/null |
| 23:53.33 | Wizzup | that's what /proc is mostly |
| 23:53.46 | Wizzup | Maxdamantus: ... those are nodes |
| 23:53.52 | Wizzup | wait, no, that's dev. |
| 23:54.07 | Maxdamantus | dev isn't special. |
| 23:54.21 | Wizzup | Please don't take what I say out of context |
| 23:54.23 | Maxdamantus | sys and proc are special, and it's up to the implementors of the files. |
| 23:54.40 | Wizzup | My train of thought was that tax simply takes the nodes from dev, without reading the contents. |
| 23:54.47 | Wizzup | was that tar* |
| 23:54.57 | Wizzup | but I wrongly applied that to /sys |
| 23:55.06 | Maxdamantus | Ah, right. |
| 23:55.12 | DocScrutinizer05 | what about access to storage, via "while :;do ls -R /;done"? even more effective wasting power on interface to a subsystem than I2C access via /sys |
| 23:55.25 | Maxdamantus | Yes, because /dev isn't special, it just has normal device files, which aren't read by tar. |
| 23:55.31 | Wizzup | yes |
| 23:55.51 | Wizzup | I believe that not all info in /sys is "just ready", I would be surprised if it is, at least. Reading said files invokes kernel functions, some of them may do comms |
| 23:56.29 | Maxdamantus | Wizzup: I'd intuitively expect it not to waste too much power doing it. |
| 23:56.34 | Wizzup | also, tar on /sys raises a lot of errors, so the time it takes may not be too proper |
| 23:56.45 | Maxdamantus | since part of the point of /sys is that the user should be able to look through it and guess the interfaces. |
| 23:57.02 | Wizzup | stat is not the same as read/open, though |
| 23:57.13 | Maxdamantus | so if there's some information there that's expensive to retrieve, the kernel module providing it should be caching it or something. |
| 23:57.18 | DocScrutinizer05 | guessing is a rather difficult to implement algorithm |
| 23:57.34 | DocScrutinizer05 | I tried it with "find" |
| 23:57.43 | Wizzup | Maxdamantus: or ... fetch it every x ms? that may waste more time |
| 23:57.54 | Wizzup | if it's only an on demand value, better let userspace figure that out |
| 23:58.01 | Wizzup | but yeah, IDN. I'd have to look at the source. |
| 23:58.04 | Wizzup | bedtime. :) |
| 23:58.41 | Maxdamantus | I figured out how to control the status light by looking through /sys |
| 23:58.45 | DocScrutinizer05 | this went far off original topic, anyway |
| 23:58.56 | Maxdamantus | at least, how to set it to particular colours, not program it. |
| 23:59.17 | Wizzup | Maxdamantus: yes - I found them on mainline as well. wrt programming: depending on what you mean, you can use the led trigger system |
| 23:59.23 | Wizzup | or alt. just write to the files |
| 23:59.44 | Wizzup | for example, you can hookup usb activity to leds using the proper trigger |
| 23:59.51 | Maxdamantus | Wizzup: I mean loading and executing code understood by the LED controller, whatever it's called. |
| 23:59.58 | Wizzup | Ah. |