| 01:21.26 | *** join/#neo900 timc1assic (~timc1assi@cpe-72-229-235-218.nyc.res.rr.com) |
| 01:22.42 | timc1assic | Weird. Booted up my new N900 and Ovi Maps seems to function. On my CSSU system it doesn't seem to have map data. Should I expect it to work? |
| 04:05.38 | *** join/#neo900 norly (~norly@enpas.org) |
| 05:08.23 | *** join/#neo900 NIN101_ (~core@n900.quitesimple.org) |
| 05:16.18 | *** join/#neo900 x29a (~x29a@unaffiliated/x29a) |
| 06:05.13 | *** join/#neo900 ashneo76 (~ashneo76@c-71-194-247-250.hsd1.il.comcast.net) |
| 07:02.47 | *** join/#neo900 timc1assic (~timc1assi@cpe-72-229-235-218.nyc.res.rr.com) |
| 07:23.34 | *** join/#neo900 webmeister (webmeister@unaffiliated/webmeister) |
| 07:39.38 | *** join/#neo900 webmeister (webmeister@unaffiliated/webmeister) |
| 07:54.25 | *** join/#neo900 webmeister (webmeister@unaffiliated/webmeister) |
| 08:14.42 | *** join/#neo900 webmeister (webmeister@unaffiliated/webmeister) |
| 08:16.05 | *** join/#neo900 PeperPots____ (sid1218@gateway/web/irccloud.com/x-ibnahjwjfyjjtqrw) |
| 08:16.50 | DocScrutinizer05 | timclassic: depending on your eMMC aka VANILLA version your device may have local map data installed |
| 08:16.59 | DocScrutinizer05 | iirc |
| 08:19.43 | DocScrutinizer05 | but I think the Nokia map data server still supposed to work, so on CSSU you should be able to download the data needed when you're online. It will get cached locally so you need to download only once (and for updates) |
| 08:21.31 | DocScrutinizer05 | also note that ovi maps afaik doesn't know to do on-board routing, for calculating any route you need online anyway |
| 08:23.08 | DocScrutinizer05 | check the alternative map apps (marble, mappero, etc), they can use alternative map data sets and some of them come with on-board routing and even guidance |
| 08:28.57 | DocScrutinizer05 | http://talk.maemo.org/showthread.php?t=66985 http://talk.maemo.org/showthread.php?p=1200564#post1200564 https://wiki.maemo.org/Navigation_Tools |
| 08:42.12 | DocScrutinizer51 | at least marble and modRana come with configurable bulk download for map data |
| 09:04.23 | *** join/#neo900 PeperPots____ (sid1218@gateway/web/irccloud.com/x-nwsidvsqkzvomubm) |
| 09:20.15 | *** join/#neo900 webmeister (webmeister@unaffiliated/webmeister) |
| 09:29.55 | *** join/#neo900 PeperPots____ (sid1218@gateway/web/irccloud.com/x-nayinwhxtgqoqcoq) |
| 09:33.15 | freemangordon | DocScrutinizer05: according to the BB-xm schematics, it is possible to change the sys_boot config with a little bit of a soldering, see bbxm-revC schematics, page 4 https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf?raw=true |
| 09:33.32 | DocScrutinizer05 | :-D |
| 09:33.50 | DocScrutinizer05 | maybe you can answer directly to internal ML? |
| 09:34.11 | DocScrutinizer05 | it might reject or put on moderation your mail. Please report |
| 09:37.05 | freemangordon | DocScrutinizer05: also, it is possible to overwrite the sys_boot, by the so-called "Software Booting Configuration", see 26.4.4.4 in SWPU177AA (36xx TRM) |
| 09:37.42 | freemangordon | DocScrutinizer05: please you do it this time (the reply), I have to go afk for some time |
| 09:37.52 | DocScrutinizer05 | yeah, maybe, but we'd want to load MLO from NAND anyway ;-) |
| 09:38.01 | freemangordon | yes, but for test... |
| 09:38.16 | DocScrutinizer05 | ok I'll simply forward the irc log |
| 09:39.22 | DocScrutinizer05 | any further notes before I send mail? |
| 09:41.42 | freemangordon | I guess Nik already knows that :) |
| 09:42.18 | DocScrutinizer05 | I'm sure he does, but cooperatime engineering means we also state the obvious, just in case :-) |
| 09:42.29 | DocScrutinizer05 | cooperative* |
| 09:43.06 | DocScrutinizer05 | for example your link to the schem helped me a lot |
| 09:43.29 | freemangordon | the sys_boot is on the lower-right corner |
| 09:43.38 | DocScrutinizer05 | found it :-) |
| 09:44.05 | freemangordon | BTW what revision is "our" BB? |
| 09:44.19 | DocScrutinizer05 | we have a zoo of different version |
| 09:44.26 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 09:44.38 | freemangordon | well, the 1GB one |
| 09:44.48 | DocScrutinizer05 | I dunno the version of the particular one board |
| 09:45.02 | DocScrutinizer05 | I'll add the question to mail |
| 09:45.03 | freemangordon | Pali: hi! Yes, all of the gadgets should have that __init removed |
| 09:45.14 | freemangordon | DocScrutinizer05: naah, it is not that important |
| 09:45.23 | DocScrutinizer05 | but iteresting also for me |
| 09:45.44 | *** part/#neo900 timc1assic (~timc1assi@cpe-72-229-235-218.nyc.res.rr.com) |
| 09:45.48 | Pali | I think that too! |
| 09:46.00 | freemangordon | Pali: I remember the last 2-3 monhs there were lots of crashing modules all over the kernel, because something was change in the __init semantics |
| 09:46.08 | freemangordon | *changed |
| 09:48.08 | DocScrutinizer05 | that's 'nice'¡ |
| 09:48.29 | DocScrutinizer05 | ohmy, kernel devs |
| 09:48.45 | DocScrutinizer05 | when they can't break something, they are not happy ;-) |
| 09:49.03 | Pali | this is again code maintained by mr. balbi |
| 09:49.10 | freemangordon | Pali: hmm, maybe the point is - bindxxx functions are not really called when the module is loaded, but on a later stage, when the core detects something matching (id?) |
| 09:49.12 | Pali | (you should remember his name) |
| 09:49.22 | freemangordon | Pali: yeah, I know that name :) |
| 09:49.24 | Pali | yes, I think that too |
| 09:49.46 | DocScrutinizer05 | Felippe Balbi? Sounds somewhat familir ;-) |
| 09:49.50 | freemangordon | :D |
| 09:50.36 | freemangordon | I guess he (along with the network guy) are our favorite kernel maintainers :) |
| 09:50.53 | freemangordon | anyway, I am afk for a while |
| 09:51.01 | DocScrutinizer05 | ((point is - bindxxx functions are not really called when the module is loaded)) [2015-02-07 Sat 23:16:21] <DocScrutinizer05> __init bind? maks no sense since you want to keep binding |
| 09:51.34 | DocScrutinizer05 | freemangordon: enjoy your Sunday! |
| 09:55.44 | *** join/#neo900 modem (~modem@fsf/member/modem) |
| 10:05.51 | *** join/#neo900 paulk-aldrin (~paulk@armstrong.paulk.fr) |
| 10:23.59 | *** join/#neo900 SylvieLorxu (~SylvieLor@dhcp-077-251-165-191.chello.nl) |
| 10:26.58 | DocScrutinizer05 | Pali: http://elinux.org/N900 for "Board snd-soc-rx51 Sound SoC Wiring" says "N/A" in first (doc) column. Shouldn't that rather be "<a href=...>N900 schematics</a>" ? |
| 10:27.44 | DocScrutinizer05 | same for other stuff like "GPIO gpio-keys Proximity sensor" |
| 10:29.50 | DocScrutinizer05 | btw the proximity sensor (component) is (99.9% certain) a http://www.osram-os.com/Graphics/XPic7/00083619_0.pdf/SFH 7741, Lead (Pb) Free Product - RoHS Compliant.pdf |
| 10:30.02 | DocScrutinizer05 | <http://www.osram-os.com/Graphics/XPic7/00083619_0.pdf/SFH 7741, Lead (Pb) Free Product - RoHS Compliant.pdf> |
| 10:34.59 | Pali | do you know <a href=" "> for schemantics? |
| 10:35.10 | DocScrutinizer05 | hmm |
| 10:35.27 | Pali | feel free to edit wiki page |
| 10:35.38 | DocScrutinizer05 | http://wiki.maemo.org/N900_Hardware_Schematic |
| 10:35.55 | DocScrutinizer05 | nah, reluctant to edit that stuff, I'm not expert enough for it |
| 11:16.14 | *** join/#neo900 xes (~xes@unaffiliated/xes) |
| 11:34.54 | *** join/#neo900 merlin1991 (~merlin@Maemo/community/cssu/merlin1991) |
| 12:02.36 | DocScrutinizer05 | Pali: also I'm not a registered user of elinux.org and thus can't edit stuff there |
| 12:08.42 | *** join/#neo900 raccoon_ (~user@meta.wtf) |
| 12:15.46 | *** join/#neo900 che1 (~che@h240.tum.vpn.lrz.de) |
| 12:57.30 | freemangordon | Pali: did you looked at what conflicts with gpio-switch driver? |
| 12:57.48 | freemangordon | *look |
| 12:58.19 | Pali | there is omap gpio switch driver which export that nokia gpio values under sys |
| 12:58.40 | Pali | but other drivers (like sound/jack or gpio buttons) use those gpios |
| 12:58.53 | Pali | and I disabled problematic one in omap gpio switch |
| 12:59.03 | Pali | it just export fake values in /sys |
| 12:59.03 | freemangordon | ok |
| 12:59.07 | Pali | to prevent conflicts |
| 12:59.20 | freemangordon | and is my cmt_speech patch included? |
| 12:59.29 | Pali | I think yes |
| 12:59.38 | freemangordon | hmm, weird |
| 12:59.51 | freemangordon | libcmtspeechdata: hw6x_backend: unable to open device /dev/cmt_speech ('No such file or directory'). |
| 13:00.23 | freemangordon | oh: "omap_ssi: probe of omap_ssi.0 failed with error -22" |
| 13:00.54 | freemangordon | and: "gpio-switch: gpio_reguest failed for cam_focus 68" |
| 13:01.01 | freemangordon | along with 5 more gpios |
| 13:01.23 | Pali | now I updated v3.19-rc5-n900 branch |
| 13:01.38 | Pali | try to recompile again |
| 13:01.41 | freemangordon | ah, I see :) |
| 13:01.53 | freemangordon | did you fix g_xxx stuff? |
| 13:01.57 | Pali | *now* = 1 minute ago |
| 13:02.06 | Pali | not yet |
| 13:02.24 | freemangordon | ok |
| 13:03.28 | Pali | btw, look at patch a8f3cb498f5b0436aa626e1dace15864b38f0baf if is really needed |
| 13:03.33 | Pali | omap3-n900.dts: fix i2c busses numbering |
| 13:03.45 | freemangordon | yes, it is |
| 13:03.48 | freemangordon | for fremantle |
| 13:04.17 | freemangordon | otherwise it cannot find devices on the bus |
| 13:04.23 | Pali | and what it is doing? |
| 13:04.37 | Pali | i2c1 = &i2c1; |
| 13:05.04 | freemangordon | renumbering the buses from i2c0..i2c2 to i2c1..i2c3 |
| 13:05.13 | DocScrutinizer05 | duh! |
| 13:05.36 | Pali | "i2c1 = &i2c1;" is what? |
| 13:05.44 | Pali | it really rename? |
| 13:05.49 | DocScrutinizer05 | cruft :-) |
| 13:06.30 | DocScrutinizer05 | anyway, what happened? kernel devels decided that I2C0 is called I2C-SR now? |
| 13:09.22 | freemangordon | Pali: iiuc on the left is what gets exported and on the right is the device |
| 13:09.32 | freemangordon | but don't quote me on that one :) |
| 13:09.58 | DocScrutinizer05 | if it was rename, one of both should be i2c2, no? |
| 13:09.58 | Pali | then it is useless |
| 13:10.11 | Pali | assign 1 for 1 |
| 13:10.15 | Pali | or what? |
| 13:10.16 | DocScrutinizer05 | :nod: |
| 13:10.27 | freemangordon | Pali: no, as in omap3.dts we have i2c0 = &i2c1 etc |
| 13:10.40 | freemangordon | and we need to overwrite that |
| 13:10.47 | DocScrutinizer05 | ugh |
| 13:11.04 | Pali | ah, so overwrite overwritten alias... |
| 13:11.09 | freemangordon | yep |
| 13:11.11 | DocScrutinizer05 | so the DT devels decided to break stuff |
| 13:11.27 | Pali | freemangordon: board code had also that alias? |
| 13:11.43 | Pali | if not then it is regression and your commit should go to upstream for rx51 |
| 13:12.15 | freemangordon | yes. it is a regression, but I am not in a mood to fight with upstream devs right now :) |
| 13:12.22 | DocScrutinizer05 | anyway seems the idea actually been to not count the SR I2C bus |
| 13:12.29 | freemangordon | https://lkml.org/lkml/2014/6/1/49 |
| 13:12.32 | DocScrutinizer05 | which happens to be I2C0 |
| 13:12.45 | DocScrutinizer05 | nonsense |
| 13:13.21 | DocScrutinizer05 | bean-counters |
| 13:14.03 | Pali | this should be easy, Tony already asked us for reporting all regression which happend after rx51 moved from board code to DT |
| 13:14.13 | DocScrutinizer05 | actually I think that's a bug in DT |
| 13:14.26 | freemangordon | hmm, seems I said I will send a patch :) |
| 13:14.32 | Pali | ok :-) |
| 13:15.05 | DocScrutinizer05 | so please kill that nonsense. A i2c bus is what it is, as written on chip pin table |
| 13:15.15 | Pali | https://lkml.org/lkml/2013/10/16/744 |
| 13:15.17 | freemangordon | hmm? |
| 13:15.57 | freemangordon | Pali: yep |
| 13:16.25 | Pali | ok, question is: what was i2c0 and what happened with it? |
| 13:16.54 | DocScrutinizer05 | Pali: see my rant above |
| 13:17.03 | DocScrutinizer05 | I2C0 is SmartReflex |
| 13:17.17 | freemangordon | Pali: http://comments.gmane.org/gmane.linux.ports.arm.omap/115326 |
| 13:18.28 | freemangordon | there is no i2c0, it is just an alias for i2c1 |
| 13:18.42 | DocScrutinizer05 | freemangordon: ^^^ good, but rationale rather should be "a device name SHALL be in line with the name of the physical interface, as labeled in chip's TRM" |
| 13:19.06 | freemangordon | ok, why arguing with me?!? :) |
| 13:19.13 | Pali | freemangordon: was your alias patch accepted to mainline? |
| 13:19.16 | DocScrutinizer05 | not arguing with you |
| 13:19.20 | freemangordon | Pali: no |
| 13:19.29 | Pali | ok, so we need it in -n900 tree |
| 13:19.31 | freemangordon | but it is not really needed |
| 13:20.06 | Pali | hm.. why? |
| 13:20.08 | freemangordon | the a8f3cb498f5b0436aa626e1dace15864b38f0baf does the trick without it |
| 13:20.35 | Pali | ok |
| 13:20.44 | Pali | then send a8f3cb498f5b0436aa626e1dace15864b38f0baf patch to ML :-) |
| 13:20.58 | freemangordon | ok |
| 13:21.08 | freemangordon | needs to remember how :) |
| 13:21.55 | Pali | commit patch to git (add signed-off-by in commit message), then git format-patch HEAD^ and then git send-email file --to=... --cc=... |
| 13:22.11 | freemangordon | it is already signed by me, ain't? |
| 13:22.18 | Pali | and check ./scripts/get_mailtainer.pl file |
| 13:22.30 | Pali | it is |
| 13:22.47 | DocScrutinizer05 | http://wstaw.org/m/2015/02/08/plasma-desktopbs1891.png dunno what's going on there, but I'd expect the dev/<name> be in line with TRM |
| 13:22.50 | freemangordon | oh, I guess I should do it agains vanilla |
| 13:23.10 | freemangordon | DocScrutinizer05: :nod: |
| 13:23.27 | freemangordon | maybe we should really fix omap3.dtsi instead |
| 13:23.38 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
| 13:23.39 | DocScrutinizer05 | that's what I think, yes |
| 13:23.39 | Pali | DocScrutinizer05: we are expecting same numbering as in Maemo and as in mainline kernel without DT :-) |
| 13:23.47 | Pali | to not break anything else again... |
| 13:24.19 | freemangordon | on the other hand, the numbering with legacy boot comes from the board code |
| 13:24.22 | DocScrutinizer05 | yes, that's what we *need* - I told what I'd *expect*, dunno if that's identical |
| 13:24.55 | DocScrutinizer05 | I always thought SR is on physical as well as logical I2C0 |
| 13:25.18 | freemangordon | isn;t that behind the TWL? |
| 13:25.30 | freemangordon | so not really seen by the MPU? |
| 13:25.51 | DocScrutinizer05 | huh? no, this is a dedicated I2C *between* TWL and CPU |
| 13:26.07 | freemangordon | oh, yes |
| 13:26.43 | DocScrutinizer05 | you _could_ however use I2C0 on CPU in arbitrary other ways and simply disable SR |
| 13:27.09 | DocScrutinizer05 | I2C1 is general purpose I2C between CPU and TWL |
| 13:27.10 | freemangordon | seems to caught doc's flue :( |
| 13:27.18 | DocScrutinizer05 | eeew |
| 13:27.47 | Pali | in qemu with above alias patch I see: # ls /dev/i2c-* |
| 13:27.47 | Pali | /dev/i2c-1 /dev/i2c-2 /dev/i2c-3 |
| 13:28.04 | freemangordon | and that's the correct numbering |
| 13:28.05 | DocScrutinizer05 | I2C0 on CPU is special in that it's the only I2C IF that can do SR |
| 13:28.11 | freemangordon | without it you'll see 0..2 |
| 13:28.14 | DocScrutinizer05 | aiui |
| 13:28.57 | DocScrutinizer05 | well, I2C0 is "not available" when used for SR |
| 13:29.09 | DocScrutinizer05 | pinmux, I guess |
| 13:29.29 | Pali | without patch I see: # ls /dev/i2c* |
| 13:29.29 | Pali | /dev/i2c-0 /dev/i2c-1 /dev/i2c-2 |
| 13:29.33 | DocScrutinizer05 | this however doesn't "rename" I2C1 |
| 13:29.44 | freemangordon | yep, it changes the aliases |
| 13:30.01 | DocScrutinizer05 | I2C1 is I2C1 is I2C1 |
| 13:30.10 | Pali | and we want starts numbering from 1 |
| 13:30.15 | DocScrutinizer05 | yes |
| 13:30.37 | *** join/#neo900 NIN101 (~core@n900.quitesimple.org) |
| 13:30.41 | DocScrutinizer05 | to stay in line with OMAP TRM |
| 13:30.55 | Pali | right, so we need freemangordon's patch in mainline |
| 13:30.58 | DocScrutinizer05 | and schematics and all |
| 13:31.13 | freemangordon | ok, I am fetching linus tree, will send a patch later |
| 13:31.19 | DocScrutinizer05 | we should fix DT which seems fubar |
| 13:31.50 | DocScrutinizer05 | prolly DT once again doesn't knlow how to correctly handle this |
| 13:32.01 | freemangordon | hmm, I'll check if NIshant is online, maybe he will want to fix the omap3.dtsi |
| 13:32.17 | freemangordon | no, he's mia |
| 13:32.46 | DocScrutinizer05 | freemangordon: get some rum with tea! |
| 13:32.51 | freemangordon | DocScrutinizer05: no, DT is fine, it is NM's patch that numbered those that way |
| 13:32.58 | DocScrutinizer05 | oooh |
| 13:33.06 | DocScrutinizer05 | so we only need to revert the patch? |
| 13:33.22 | DocScrutinizer05 | :-) |
| 13:33.25 | freemangordon | DocScrutinizer05: already had a coldrex (dunno if it is known in Germany), but it is paracetamol |
| 13:33.31 | freemangordon | DocScrutinizer05: no, we can't |
| 13:33.41 | DocScrutinizer05 | dang! |
| 13:33.42 | freemangordon | as without it busses are numbered in a random order :D |
| 13:34.00 | DocScrutinizer05 | DT is 'awesome'¡ |
| 13:34.01 | freemangordon | is afk for a while |
| 13:34.39 | DocScrutinizer05 | I really think DT wasn't made for embedded. No way |
| 13:34.43 | Pali | its not problem of DT, but way how kernel register i2c busses... |
| 13:34.48 | Pali | see description of: https://lkml.org/lkml/2013/10/16/744 |
| 13:35.12 | freemangordon | :nod: |
| 13:35.18 | DocScrutinizer05 | yeah, the kernel at large fails at consistent numbering |
| 13:35.36 | DocScrutinizer05 | but DT doesn't help to fix the problem |
| 13:35.58 | DocScrutinizer05 | despite I thought that's one of DT's main purposes |
| 13:36.04 | Pali | basically all numbering in kernel is done in way: first come, first take |
| 13:36.15 | DocScrutinizer05 | that's idiocy |
| 13:36.20 | Pali | and if you need fixed number (eg. 42) you need to tell it to kernel |
| 13:36.36 | Pali | by default is first available (which is not reserved) |
| 13:37.17 | DocScrutinizer05 | there should've been a mechanism like udev for this. In kernel |
| 13:37.35 | Pali | yes there is. in DT it is alias |
| 13:38.10 | Pali | just say that device XYZ has number 1, device ABC number 2, etc... |
| 13:38.10 | DocScrutinizer05 | like "umm, this is I2C-HWADDR0x40080, and I'm told to alias it to I2C2" |
| 13:38.43 | DocScrutinizer05 | exactly |
| 13:39.00 | DocScrutinizer05 | so that's what's missing in DT, and it should get fixed |
| 13:39.37 | Pali | yes, freemangordon patch add alias, i2c1 has number 1, i2c2 has number 2, i2c2 has number 3 and nobody has number 0 |
| 13:40.09 | DocScrutinizer05 | that sounds ok, just I'd expect it getting done in DT |
| 13:40.28 | DocScrutinizer05 | for all OMAP3, even all OMAP |
| 13:40.47 | DocScrutinizer05 | even for all I2C |
| 13:41.00 | Pali | for some reasons Nishanth Menon did in patch https://lkml.org/lkml/2013/10/16/744 but starting from zero, not one |
| 13:41.27 | DocScrutinizer05 | assigning the I2C0 pins to second function in pinmux doesn't rename I2C1 in real life, so it shouldn't in linux as well |
| 13:41.37 | Pali | maybe there is TI userspace which numbers it from zero (i2c1 as 0) |
| 13:42.16 | DocScrutinizer05 | hardly |
| 13:42.16 | Pali | I know that developers are very creative, so I bet there can be boards which userspace needs it... |
| 13:43.21 | DocScrutinizer05 | it's kernel devel "booohooowaaa I *want* devices get numbered starting at #0. ALWAYS!!!" |
| 13:43.27 | Pali | hahaha, ubuntu except numbering from zero :-) |
| 13:43.29 | Pali | not one |
| 13:43.49 | Pali | expecting /dev/i2c-0 |
| 13:44.40 | DocScrutinizer05 | in HDA/SDA they invented naming by label because of their idiotic non-stable numbering concept |
| 13:44.44 | Pali | I think it is because kernel devices are numbered from zero (and not one) |
| 13:45.21 | Pali | and they want to have same numbering in all schemes |
| 13:45.22 | Pali | not mess |
| 13:45.38 | DocScrutinizer05 | it's because kernel device devels want it started at 0 |
| 13:46.05 | DocScrutinizer05 | mess == device names not in line with TRM names |
| 13:46.23 | Pali | you can export device description |
| 13:46.30 | Pali | and write there correct name |
| 13:46.43 | Pali | I think that numbering of devices is not stable |
| 13:47.21 | DocScrutinizer05 | such random numbering that has only one constant rule which is "pragma origin=0" is useful for a random set of absolutely equivalent devices *only* |
| 13:47.47 | DocScrutinizer05 | I2C1 bus is NOT equivalent to I2C2 bus |
| 13:47.59 | Pali | anyway if you need to use i2c bus, you need to enumerate all i2c devices in /dev/ and choose those which you want to use (check name of i2c device, etc) |
| 13:48.05 | Pali | same is for disks |
| 13:48.19 | Pali | /dev/sda does not have to be always same disk |
| 13:48.46 | Pali | its up to udev to do some stable numbering (e.g. using permanent cache rules) |
| 13:49.02 | Pali | /etc/udev/rules.d/70-persistent-cd.rules |
| 13:49.05 | Pali | /etc/udev/rules.d/70-persistent-net.rules |
| 13:49.08 | DocScrutinizer05 | as I told above. it's idiocy for SDA and there you actually _could_ swap attached drives. For I2C you _never_ have any option to swap |
| 13:49.09 | Pali | etc... |
| 13:49.29 | DocScrutinizer05 | I2C is no pluggable interface |
| 13:49.52 | DocScrutinizer05 | unlike SDA, USB, NET |
| 13:49.54 | DocScrutinizer05 | ... |
| 13:50.37 | Pali | yes, but that number is used only for userspace (if I understand correctly) and for entires in /dev/ is responsible userspace/udev |
| 13:50.48 | DocScrutinizer05 | and unlike those, I2C is *very* low system level, other kernel drivers depend on it |
| 13:50.49 | Pali | kernel does not have to export stable names |
| 13:51.13 | Pali | other kernel drivers use DT description of devices, not kernel number! |
| 13:51.47 | Pali | DT is device tree, you put other i2c devices to correct node in that tree |
| 13:51.58 | DocScrutinizer05 | well, the whole thing is again a fuckup done by kernel devels who got no clue about hardware, as usual |
| 13:53.09 | DocScrutinizer05 | how the heck is userland supposed to know which I2C bus is the right one, when they don't get stable numbering from DT or kernel itself? |
| 13:53.41 | Pali | they check description of i2c bus... same as for non removable hard disks |
| 13:54.01 | DocScrutinizer05 | digging up hw addr of I2C bus in the doomed corners of /sys ? |
| 13:54.17 | Pali | how would I know if that disk (hitachi) is /dev/sda? and not /dev/sdb? |
| 13:54.33 | DocScrutinizer05 | that is NOT DT! |
| 13:54.49 | Pali | yes, but same problem for userspace applications |
| 13:54.54 | DocScrutinizer05 | DT has NFC which drive is plugged to which SATA interface |
| 13:55.16 | DocScrutinizer05 | for I2C there *are no* plugs involved |
| 13:55.31 | DocScrutinizer05 | so I expect DT do it _right_ |
| 13:55.53 | DocScrutinizer05 | and name I2C devices same way they are named in schematics and TRM |
| 13:56.07 | DocScrutinizer05 | just like SDA is SATA bus #1 |
| 13:56.21 | Pali | yes dt can do it right, it can aslo set "device description" |
| 13:56.25 | DocScrutinizer05 | (the first one) always. It's written on board |
| 13:57.15 | DocScrutinizer05 | same way I2C1 is "written on board" |
| 13:57.23 | Pali | if somebody in TRM decide to choose string name "i2c1 - special device" for first device, then you can specify that string name in DT for correct device |
| 13:57.41 | Pali | but I would say, internal kernel numbering of devices starts from zero |
| 13:58.01 | DocScrutinizer05 | so I expect I2C1 being one bus I can point at without checking any furhter, just like I can point to SDA SATA bus jack |
| 13:58.13 | Pali | and from userspace, you choose i2c device with string name "i2c1 - special device" like you see in TRM |
| 13:59.13 | DocScrutinizer05 | well, as mentioned for sATA it's even less strict since those are pluggable |
| 13:59.58 | Pali | OT: in some context i2c is also pluggable... (display adapters HDMI/DVI) |
| 13:59.58 | DocScrutinizer05 | whatever sting name means |
| 14:00.27 | DocScrutinizer05 | err still not really |
| 14:00.38 | Pali | you can hotplug HDMI cable |
| 14:00.40 | DocScrutinizer05 | it's invariably the HDMI I2C |
| 14:01.16 | DocScrutinizer05 | and I'd wonder whom to kill if userland needs to find out which of I2C* is the one connected to the HDMI port |
| 14:02.03 | Pali | $ sudo i2cdetect -l |
| 14:02.07 | DocScrutinizer05 | I look at schematics and see "aaah, that MUST be I2C-4" then use /dev/I2C-4 to access HDMI |
| 14:02.30 | DocScrutinizer05 | dafaq! read big fat WARNING about I2Cdetect and similar stuff |
| 14:02.56 | Pali | its param '-l' |
| 14:03.02 | Pali | it just ask kernel for names |
| 14:03.30 | DocScrutinizer05 | this definitely is NOT what userland is supposed to do, to find which /dev/i2c-* to use to talk to HDMI |
| 14:04.00 | Pali | -l is doing some find /sys and call ioctl which ask kernel for correct string name |
| 14:04.03 | DocScrutinizer05 | honestly, kernel devels gone mad, or what? |
| 14:04.31 | Pali | you can ask for that name via /sys/class/i2c-dev/<dev>/name |
| 14:04.52 | DocScrutinizer05 | again, that's NOT what userland is supposed to do |
| 14:05.04 | Pali | why? this is what is suppsed to do |
| 14:05.17 | DocScrutinizer05 | ohmy |
| 14:05.55 | Pali | I have two graphics cards, each card has more ports (hdmi1, hdmi2, dvi, vga, ...) and each graphics card has more i2c busses... |
| 14:06.07 | Pali | only one card can assign number 1 to kernel |
| 14:06.19 | DocScrutinizer05 | those ARE NOT IN DT!!! |
| 14:06.38 | Pali | you really should ask for kernel description of i2c busses |
| 14:06.45 | Pali | and not except some internal kernel numbering |
| 14:07.39 | Pali | there are other platform which do not use DT (eg. x86) and kernel cannot add special code for some platform (e.g arm) to provide other numbring in i2c subsystem |
| 14:07.54 | Pali | it will be big mess which is unmaintainable... |
| 14:08.04 | DocScrutinizer05 | I don't want to check my device like transformers if it's currently configured as helicoper, boat, or jet, before I talk to the chip that's living on I2C#2 bus |
| 14:08.37 | DocScrutinizer05 | and *always* will live on that very I2C bus, on same address |
| 14:08.45 | Pali | then you will ask kernel for i2c bus which has description "I2C#2 bus" |
| 14:09.09 | Pali | /dev/ is not stable and never it was (without udev) |
| 14:09.11 | DocScrutinizer05 | bullshit, I will access /dev/i2c-2 |
| 14:09.28 | Pali | is there any documentation which say that? |
| 14:09.42 | DocScrutinizer05 | yes, 30 years of linux |
| 14:09.59 | Pali | read Documentation/i2c/dev-interface |
| 14:10.11 | Pali | "Each registered i2c adapter gets a number, counting from 0." |
| 14:10.17 | DocScrutinizer05 | why the heck does kernel need to randomize stuff so userland needs to un-randomize it later on? |
| 14:10.59 | Pali | because drivers are loaded in ranom order (and asynchronous) |
| 14:11.02 | DocScrutinizer05 | (documentation/i2c) signed: Poettering |
| 14:11.16 | DocScrutinizer05 | then that's a bug |
| 14:11.44 | Pali | no, git tells me that this is since 2.6.12 (when linux moved to git) |
| 14:11.55 | kerio | lol |
| 14:12.07 | DocScrutinizer05 | when a driver can't tell "ooh this is hw addr 0.0080, so this is bus #2 on OMAP", not even with help of DT, then this is fubar |
| 14:12.12 | Pali | if you want, I can search in full linux history when was numbering from 0 introducted |
| 14:13.03 | Pali | DocScrutinizer05: there are two different things: 1) internal kernel numbering (which is by definitions from zero) and 2) external string description of bus |
| 14:13.53 | Pali | and if you did not read i2c *kernel* API 10 years ago (since which this is stable) you did not used i2c API on linux correctly |
| 14:14.39 | DocScrutinizer05 | meh, I got better things to do than to blame kernel devels for all the idiocy they introduced and continue to introduce. With every new kernel version. I already said they are not happy when thy can't break things, if onyl for stuff like "we changed pragma origin=1 to pragma origin=0 this time" |
| 14:15.07 | Pali | there is one thing, userspace API is not going to break |
| 14:15.30 | DocScrutinizer05 | just devels implementing a idiotic rule 10 years ago doesn't make it right |
| 14:15.56 | DocScrutinizer05 | yeah, and since /sys is NOT part of userland API... |
| 14:16.10 | DocScrutinizer05 | good luck with all that shit |
| 14:16.17 | kerio | "it's not how i imagined it to work therefore it's bad" |
| 14:16.18 | Pali | full /sys not, but some parts yes! |
| 14:16.54 | Pali | bitkeeper tells me that numbering from zero is at least from 2002 |
| 14:18.01 | DocScrutinizer05 | numbering is worthless, no matter if from 0 or from 4711, when numbers are random anyway |
| 14:18.14 | Pali | "you have to decide which adapter you want to access. You should inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this." |
| 14:18.21 | Pali | this is what say API ^^^ |
| 14:18.39 | DocScrutinizer05 | now check changelog of /sys |
| 14:18.51 | DocScrutinizer05 | brainfuck |
| 14:18.53 | Pali | /sys/class/i2c-dev/ is stable api |
| 14:19.15 | DocScrutinizer05 | suuuure, since 20 years |
| 14:19.45 | Pali | did not you hear about Documentation/ABI/stable? |
| 14:20.01 | Pali | before blaming you should read kernel docs! |
| 14:20.03 | DocScrutinizer05 | bye |
| 14:20.28 | DocScrutinizer05 | when kernel docs are bullshit i don't need to read them before starting ranting |
| 14:20.47 | Pali | you did not read them, so you cannot say it is bullshit |
| 14:20.57 | DocScrutinizer05 | I see the result |
| 14:21.13 | DocScrutinizer05 | so it IS bullshit |
| 14:21.42 | Pali | result of what??? that you want to use internal kernel numbering and excepting that internal numbering will be always same and stable? |
| 14:22.18 | DocScrutinizer05 | why the f*ck is *internal* kernel nubering showing up in /dev? |
| 14:22.31 | Pali | because some numbering must be used |
| 14:22.35 | DocScrutinizer05 | sorry, I'm out. This is futile |
| 14:23.22 | Pali | also in output of ifconfig -a is used internal numbering |
| 14:23.27 | *** join/#neo900 ashneo76 (~ashneo76@2002:47c2:f7fa:1:db49:886d:f90e:7868) |
| 14:23.53 | ShadowJK | So it's a bit like /dev/sd* numbering changing across reboots etc? |
| 14:24.18 | Pali | yes, because kernel does not have windows like registry where to store numbering |
| 14:24.20 | DocScrutinizer05 | yes, obviously for *all* /dev/* |
| 14:24.33 | ShadowJK | My PC sometimes comes up with harddrives sda sdb sdc, sometimes sda sdf sdg |
| 14:24.33 | Pali | if you want stable /dev/ there is udev for it |
| 14:24.46 | Wizzup | systemd-udevd * ;-) |
| 14:24.51 | DocScrutinizer05 | since... /dev is not a stable userland API. /sys is, partially |
| 14:25.11 | DocScrutinizer05 | :-S |
| 14:25.27 | Pali | if you use stable netlink daemon (= old udev version on systemded), then you can have stable /dev/ |
| 14:25.35 | DocScrutinizer05 | /dev isn't since kernel likes to randomize stuff, just for fun |
| 14:26.00 | Pali | kernel just tell: new device with name NAME, id ID and description DESC was created |
| 14:26.12 | Pali | and netlink based daemon parse this message and create node in /dev/ |
| 14:26.29 | Pali | its up to which userspace daemon will use for that |
| 14:27.10 | Pali | if DESC == "i2c bus number 2" ID == 0 SUBSYSTEM==I2C then its up to that daemon what will do |
| 14:27.41 | Pali | udev will probably create /dev/SUBSYSTEM-ID node |
| 14:27.44 | DocScrutinizer05 | yeah, while kernel using $RANDOM for the name |
| 14:28.17 | DocScrutinizer05 | excellent approach |
| 14:28.18 | Pali | DESC is what is sed by kernel driver or in DT (e.g that string from TRM), ID is first available |
| 14:29.07 | Pali | nobody force you to use systemd or *default* udev rules (which some userspace devs created) |
| 14:30.39 | Pali | you still do not see point? kernel tell you all information which you need (to userspace) |
| 14:31.07 | Pali | and its up to you what will you do with it (or what will your program with processing those information do) |
| 14:33.00 | Pali | kernel must solve also problems like: two different devices (card1 and card2) provides i2c busses and both cards have bussed with number 2... |
| 14:33.20 | Pali | i2c subsystem is generic for all platforms and must deal with this problem an all platforms |
| 14:33.21 | DocScrutinizer05 | HUH? |
| 14:33.33 | Pali | (even on arm you can have 2 graphiscs cards) |
| 14:33.34 | DocScrutinizer05 | s/i2c/usb/ |
| 14:34.50 | Pali | and so devices are numbered internally (for historic reason from zero, not one) and its up to userspace daemon (e.g udev) if that number use for naming in /dev/ or not |
| 14:35.59 | DocScrutinizer05 | I just wonder why kernel not simply creates /dev/device0000 to /dev/device9999 and completely hides all info that's already available to kernel drivers, like i2c bus number. after all some platform could have TWO fans or TWO power supplies or even 5 power switches |
| 14:37.59 | Pali | because it is created by userspace, not kernel :-) |
| 14:38.00 | DocScrutinizer05 | all the info would go to /sys so later on userland may find out what the heck is /dev/device4711 |
| 14:38.38 | Pali | ok, seems you totally did not understand it |
| 14:38.48 | DocScrutinizer05 | what? /dev/ nodes are created by userland? |
| 14:38.50 | Pali | /dev/ nodes are created by userspace |
| 14:38.59 | Pali | /sys/ is exported by kernel |
| 14:39.02 | Pali | /proc/ by kernel too |
| 14:39.54 | dos1 | (/dev/ nodes are created by userspace) unless you use devtmpfs |
| 14:39.55 | Pali | udev monitoring /sys (or waiting for messages from AF_NETLINK socket) and with information from rules it populates /dev/ |
| 14:40.15 | kerio | dos1: rip devtmpfs ;-; |
| 14:40.41 | DocScrutinizer05 | then what the fuck is the problem of DT with I2C numbering? |
| 14:40.45 | Pali | new versions of linux have devtmpfs pseudo FS, which automatically create devices in /dev/ by schme which was used by by some version of udev |
| 14:40.49 | DocScrutinizer05 | why did it even change? |
| 14:41.01 | DocScrutinizer05 | while maemo userland clearly NOT changed |
| 14:41.43 | Pali | maemo usersland incorrectly use /dev/i2c* devices |
| 14:42.04 | DocScrutinizer05 | if what you say was 100% correct, the I2C names must not change by changing kernel |
| 14:42.06 | Pali | nokia hardcoded /dev/i2c* files instead checking bus description |
| 14:42.50 | Pali | and they hardcoded i2c device IDS into n900 board files as 1,2,3 |
| 14:42.59 | Pali | and violated i2c documentation in kernel |
| 14:43.01 | DocScrutinizer05 | yes, since that's a sane thing to do, since the hardware never chabges, so why not hardcode it? |
| 14:43.06 | DocScrutinizer05 | changes* |
| 14:43.12 | *** join/#neo900 arcean (~arcean@aacv34.neoplus.adsl.tpnet.pl) |
| 14:43.28 | ShadowJK | And since the OS uses busybox, why bother testing scripts in bash :D |
| 14:43.33 | Pali | and because it was used for a long time, we do not want to break it... and because fix is very easy and *only* for n900, we can send patch for it |
| 14:43.44 | Pali | which does not introduce problems for other devices |
| 14:43.58 | DocScrutinizer05 | ShadowJK: ...and dash and tcsh and csh and... |
| 14:44.12 | DocScrutinizer05 | no way |
| 14:44.43 | Pali | "<DocScrutinizer05> yes, since that's a sane thing to do, since the hardware never chabges, so why not hardcode it?" because internal kernel i2c numbering has nothing with it |
| 14:45.06 | Pali | same as for network devices in network subsystem |
| 14:45.12 | DocScrutinizer05 | if that would be true, who cares about kernel anyway? |
| 14:45.33 | DocScrutinizer05 | fsck DT! |
| 14:45.47 | Pali | we, becase we have closed nokia apps which we would like to run |
| 14:45.58 | DocScrutinizer05 | aha |
| 14:46.00 | Pali | and we cannot fix those nokia closed apps |
| 14:46.05 | DocScrutinizer05 | aha |
| 14:46.18 | DocScrutinizer05 | and that causes kenel to change device names how? |
| 14:46.33 | DocScrutinizer05 | DT == 100% cruft |
| 14:47.01 | Pali | what caused changing internal kernel numbers? DT conversion... |
| 14:47.09 | DocScrutinizer05 | DT == 100% cruft |
| 14:47.54 | Pali | it would be same, if you change DT code back to board code |
| 14:48.14 | Pali | DT is more easier to describe HW asn that board code... |
| 14:48.49 | DocScrutinizer05 | yeah, of course¡ that's why we got wrong I2C names now |
| 14:48.51 | Pali | and before deleting board code from kernel permanently, we were asked to check and *report* regressions |
| 14:49.01 | Pali | so to minimalize problems |
| 14:49.15 | Pali | and one is also i2c numbering... |
| 14:49.33 | Pali | note that legacy board code for n900 was not removed yet! |
| 14:49.42 | DocScrutinizer05 | "lemme introduce some DT cruft that does nothing to improve the system. Please check for regressions!" |
| 14:50.04 | Pali | nope, it improve this ARM mess situation |
| 14:50.18 | DocScrutinizer05 | aha, yeah I see that clearly |
| 14:50.19 | Pali | legacy board code is one big mess in ARM |
| 14:50.26 | DocScrutinizer05 | it worked |
| 14:50.35 | Pali | did you see it? |
| 14:50.50 | DocScrutinizer05 | why would I even look at it? |
| 14:51.11 | Pali | to understand that board is is really worse then DT |
| 14:53.03 | DocScrutinizer05 | you won't convince a dog about quality of dogfood by showing him the printing on label |
| 14:53.12 | DocScrutinizer05 | it worked |
| 14:53.25 | DocScrutinizer05 | so again, why would I look at it? |
| 14:54.03 | DocScrutinizer05 | to understand why kernel devels feel like messing around with a new concept that THEY think THEY can understand more easily? |
| 14:54.06 | Pali | DocScrutinizer05: it worked but was not easy to extend that code |
| 14:54.25 | Pali | and do not rememember that we still have subsystems (like camera) which is not supported by upstream kernel yet |
| 14:54.34 | Pali | and one reason is that big mess in board code |
| 14:54.47 | Pali | DT is not new concept |
| 14:54.54 | DocScrutinizer05 | no, reason is the mess in DT |
| 14:54.55 | Pali | its very old and now stable and used |
| 14:55.05 | freemangordon | Pali: "do not remember" == "do not forget"? |
| 14:55.37 | Pali | freemangordon: what? |
| 14:55.49 | freemangordon | (16,54,24) Pali: and do not rememember that we still have subsystems (like camera) which is not supported by upstream kernel yet |
| 14:56.11 | Pali | right, forget :D |
| 14:56.25 | freemangordon | :) |
| 14:56.25 | DocScrutinizer05 | anyway, futile discussion |
| 14:57.18 | DocScrutinizer05 | I think embedded best uses "momolithic" kernel, not general purpose kernel that also could run on a IBM3500 |
| 14:57.42 | DocScrutinizer05 | thus hardcoded I2C is exactly the thing I'd prefer |
| 14:57.57 | freemangordon | DocScrutinizer05: noone says the must be only one kernel that fits them all |
| 14:57.58 | DocScrutinizer05 | while DT is 100% useless |
| 14:58.04 | freemangordon | *there |
| 14:58.32 | DocScrutinizer05 | bbl |
| 14:58.44 | freemangordon | omap2plus config (for example) is not for production )and that is even admitted by the kernel devs) |
| 15:10.16 | DocScrutinizer05 | freemangordon: pali: please note http://projects.goldelico.com/p/neo900/issues/678/ |
| 15:10.58 | *** join/#neo900 norly (~norly@enpas.org) |
| 15:12.51 | DocScrutinizer05 | thanks for your contributions which are appreciated and helped speeding up stuff |
| 15:12.57 | DocScrutinizer05 | :-) |
| 15:13.02 | Pali | u-boot needs CONFIG_ONENAND |
| 15:13.07 | DocScrutinizer05 | yes |
| 15:13.19 | Pali | kernel: needs to modify DT |
| 15:13.24 | DocScrutinizer05 | yes |
| 15:13.36 | Pali | and also u-boot (to specify 1GB and not 512M) |
| 15:13.51 | Pali | because u-boot pass memory ATAG to kernel |
| 15:14.03 | DocScrutinizer05 | for DT I hope for patches from your side, to offload some development workload from Nikolaus |
| 15:14.12 | DocScrutinizer05 | for uBoot same |
| 15:14.42 | DocScrutinizer05 | NB we're not using maemo kernel here |
| 15:15.04 | Pali | that board is omap3-beagle or omap3-beagle-xm-ab or omap3-beagle-xm? |
| 15:15.30 | DocScrutinizer05 | Pali: you received that mail digest I forwarded to you? |
| 15:15.42 | Pali | yes, I recevided one looong email |
| 15:16.18 | DocScrutinizer05 | that was backlog |
| 15:16.35 | DocScrutinizer05 | further new mails will come in piecemeal |
| 15:17.32 | Pali | one long email = email with lot of parts (and each part has mimetype message/rfc822) |
| 15:17.36 | DocScrutinizer05 | the board is a beagleboard-xM |
| 15:18.11 | Pali | needs to edit memory in linux kernel: arch/arm/boot/dts/omap3-beagle-xm.dts |
| 15:18.14 | DocScrutinizer05 | (mimetype) is this an inconvenient format for you? |
| 15:18.33 | Pali | for me its ok :-) |
| 15:18.41 | DocScrutinizer05 | good |
| 15:19.33 | Pali | also adding content-disposition: inline for text parts is good |
| 15:19.34 | DocScrutinizer05 | would you like to join the ML? |
| 15:20.30 | DocScrutinizer05 | it's sort of low traffic volume usually, so please don't spam it with too much stuff for Nik to keep up with |
| 15:21.26 | DocScrutinizer05 | other than that there's no sekrit sauce on the ML, just as name says: internal-devel |
| 15:39.18 | *** join/#neo900 hbib (~user@xdsl-87-79-219-57.netcologne.de) |
| 15:41.27 | *** join/#neo900 norly (~norly@enpas.org) |
| 15:45.26 | *** join/#neo900 hbib (~user@xdsl-87-79-219-57.netcologne.de) |
| 15:46.26 | *** part/#neo900 hbib (~user@xdsl-87-79-219-57.netcologne.de) |
| 15:50.06 | freemangordon | Pali: patch sent |
| 15:50.50 | Pali | got it |
| 15:51.48 | *** join/#neo900 norly (~norly@enpas.org) |
| 16:09.21 | *** join/#neo900 hbib (~user@xdsl-87-79-219-57.netcologne.de) |
| 16:10.13 | *** part/#neo900 hbib (~user@xdsl-87-79-219-57.netcologne.de) |
| 16:30.34 | *** join/#neo900 nicksydney (~quassel@61.155.dsl.syd.iprimus.net.au) |
| 18:13.03 | *** join/#neo900 modem (~modem@fsf/member/modem) |
| 19:12.28 | *** join/#neo900 sparetire (~sparetire@unaffiliated/sparetire) |
| 19:39.53 | *** join/#neo900 webmeister (webmeister@unaffiliated/webmeister) |
| 19:41.39 | *** join/#neo900 b1101 (~b@fsf/member/b1101) |
| 23:20.51 | *** join/#neo900 norly (~norly@enpas.org) |
