| uvos | sgx ideling problem follows sdcard | 00:06 |
|---|---|---|
| uvos | hmm | 00:06 |
| Wizzup | some app that uses 3d? | 00:09 |
| uvos | i just synced up pstree between the devices it dident help | 00:17 |
| Wizzup | kernel idenfical? | 00:19 |
| uvos | 5.15.0-1+2m7.6 | 00:20 |
| uvos | yeah | 00:20 |
| Wizzup | rsync -avn shows diff? | 00:22 |
| Wizzup | (presumbly a lot) | 00:22 |
| Wizzup | maybe + --delete | 00:23 |
| uvos | yeah i dont think thats helpfull | 00:23 |
| Wizzup | ok | 00:23 |
| uvos | one image is clean | 00:23 |
| uvos | the other has a huge tone of pacakges installed | 00:23 |
| Wizzup | mhm | 00:24 |
| Wizzup | so ssi bug is between 5.7 and 5.8 | 00:24 |
| Wizzup | wait... now I need to check what I just asid | 00:24 |
| Wizzup | lol | 00:24 |
| Wizzup | sorry 5.8 and 5.9 | 00:25 |
| Wizzup | I'll bisect it before I go to bed | 00:25 |
| uvos | ahhh | 00:31 |
| uvos | i had video-omap in debug mode | 00:32 |
| uvos | apperantly that dosent let sgx sleep | 00:32 |
| Wizzup | heh | 00:32 |
| uvos | (thats a bit wierd tho as it only adds prints afaik) | 00:32 |
| Wizzup | huh v5.9 is ok | 00:35 |
| Wizzup | but v5.9.y was not | 00:35 |
| Wizzup | ok | 00:35 |
| uvos | that should make the bisect very short | 00:35 |
| Wizzup | 10 steps | 00:36 |
| Wizzup | not really | 00:36 |
| Wizzup | it's a binary search, so even a large range doesn't matter | 00:36 |
| Wizzup | it's the zooming in on a specific commit that takes a whilr | 00:37 |
| Wizzup | I do full rebuilds every time to be sure | 00:37 |
| uvos | it stil groes with the amount of commits | 00:37 |
| Wizzup | maybe I shouldn't | 00:37 |
| Wizzup | sure, logarithmically | 00:37 |
| Wizzup | I mean it doesn't matter | 00:37 |
| Wizzup | but the other ones took 11 commits, and that was a major version | 00:37 |
| Wizzup | usually when I get down to the last few steps I feel it's better to just look at the log | 00:38 |
| uvos | ok | 00:38 |
| Wizzup | but then I realise I'm tired and it's better to just do the mindless thing :P | 00:38 |
| uvos | hmm so it enters ret now | 00:39 |
| uvos | but that dident really do anything for the power consumption | 00:39 |
| uvos | still 200mw ish | 00:39 |
| Wizzup | follows sd card? | 00:39 |
| uvos | yeah | 00:39 |
| uvos | lets see what powertop sais | 00:39 |
| Wizzup | probably that it would really like to have CONFIG_TIMER_STATS | 00:40 |
| Wizzup | :D | 00:40 |
| uvos | no doubt | 00:40 |
| uvos | ok its nvm its 140 now, was just the modem calming down | 00:40 |
| Wizzup | that sounds like a lot still | 00:41 |
| uvos | its just a couple of minutes after boot | 00:41 |
| Wizzup | ok | 00:41 |
| uvos | thats "normal" for mine | 00:42 |
| Wizzup | I think mine is 90mW with modem off | 00:42 |
| uvos | it also dosent go abelow 100 anymore for me | 00:42 |
| Wizzup | well I have the n900 off mode regressions reverted | 00:42 |
| Wizzup | at least CONFIG_COMPACT probably impacts d4 too | 00:42 |
| uvos | the bionic still dose 60-70mw | 00:43 |
| uvos | i have never seen the d4 go that low | 00:43 |
| uvos | still need to debug that one | 00:43 |
| uvos | starting by unloading all the modules that are different maybe | 00:43 |
| uvos | that and the 2800mAh battery makes the bionic idle absolutly forever | 00:45 |
| Wizzup | yeah, that's neat | 00:49 |
| Wizzup | uvos: btw I will from now on refer to this wlcore reset as the microwave bug | 00:55 |
| uvos | yes, and newspost will hopefully contain: fixed device rebooting when placed into a microwave. | 00:56 |
| Wizzup | repeatedly | 00:57 |
| uvos | right | 00:57 |
| Wizzup | maybe we can sneak that info a kernel commit msg somehow | 00:58 |
| uvos | i hope so :P | 01:04 |
| uvos | anyhow ttyl | 01:04 |
| * uvos zzzz | 01:04 | |
| Wizzup | ttyl | 01:05 |
| Wizzup | tmo doesn't work for me at home, blergh | 01:34 |
| Wizzup | yeah ok reverting f959dcd6ddfd29235030e8026471ac1b022ad2b0 makes the modem work | 02:37 |
| Wizzup | looks like the right fix will be either setting the dma mask, or more likely, make sure it doesn't try the dma path when it shouldn't - there's a dma_capable that checks if the dma_mask is NULL, and if it is, it returns false (not dma capable) | 02:38 |
| Wizzup | it looks more likely to me that this path was taken | 02:38 |
| Wizzup | it's an old sim, so it's denied, but hey, it works: | 02:46 |
| Wizzup | $ mdbus2 -s org.ofono /n900_2 org.ofono.NetworkRegistration.GetProperties | 02:46 |
| Wizzup | ({'Status': <'denied'>, 'Mode': <'auto'>, 'LocationAreaCode': <uint16 6150>, 'CellId': <uint32 11277755>, 'Technology': <'hspa'>, 'Name': <''>},) | 02:46 |
| Wizzup | oh rip the cellid is there, oh well | 02:46 |
| * Wizzup zzz | 02:46 | |
| freemangordon | Wizzup: great! | 10:34 |
| Wizzup | freemangordon: yeah now we need just need a proper fix | 12:01 |
| * Wizzup has like 10 patches to submit now | 12:01 | |
| Wizzup | better get on it | 12:01 |
| sicelo | what pkg provides /usr/sbin/hildon-menu-generate ? | 12:01 |
| sicelo | it's missing on my droid 4 now (possibly after trying to install the new mesa/ddk last week). | 12:02 |
| parazyd | sicelo: hildon-desktop | 12:04 |
| sicelo | thanks. yes. just figured it out. it's installing already :-) | 12:04 |
| Wizzup | sicelo: remind me did you figure out how to make rgb led work or audio probe on recent n900? | 12:06 |
| sicelo | i know why it doesn't. i also made it work, but i'm not 100% sure it's the correct/clean way. audio i never looked at | 12:06 |
| sicelo | Wizzup: RGB LED patch that i submitted to upstream: https://paste.debian.net/1223109/ | 12:08 |
| sicelo | pavel, who's the maintainer for LED subsystem, was willing to accept it. but around that time, someone else in the ML submitted a patch affecting exactly this line, setting it to LOW :p | 12:10 |
| Wizzup | ok, so maybe we poke pavel | 12:11 |
| Wizzup | did you cc linux-omap on that patch | 12:11 |
| Wizzup | or, where can I find the mails? | 12:12 |
| sicelo | https://www.spinics.net/lists/linux-leds/msg19029.html | 12:13 |
| Wizzup | ty | 12:14 |
| sicelo | dts also needs to be updated (because it's way out of date with current binding documentation), https://paste.debian.net/1223110/ | 12:14 |
| sicelo | if you want to test it, i would suggest starting with just the dts patch. see if it doesn't work with just that alone, before patching the driver | 12:15 |
| sicelo | there's possibility that dts by itself may suffice | 12:16 |
| Wizzup | ok | 12:16 |
| Wizzup | I wonder if the modem ever used dma or if it was always pio | 12:16 |
| sicelo | Wizzup: since you're bisecting, maybe you can find out what really changed with the LED. iirc by 5.9 it wasn't working anymore, although on pmOS' 5.7 it does | 12:19 |
| sicelo | mmm, interacting with Leste seems slower now than before. hope i didn't break anything | 12:21 |
| Wizzup | sicelo: hnggg I've done 4 or 5 bisects now and I was kind of hoping to be done with it | 12:26 |
| Wizzup | I mean I could if it's the easiest path to getting it fixed, but I'd rather not | 12:26 |
| Wizzup | totally unrelated, but does someone recall how to pass through the n900 modem over usb? | 12:27 |
| sicelo | yeah, i understand. i was just curious as to what could have really changed, since the driver itself didn't change between those kernel versions, iirc. | 12:27 |
| Wizzup | iirc there was some special gadget for it, right? | 12:27 |
| Wizzup | sicelo: yeah apart from the omap3 thermal stuff all the other things that broke were completely unrelated and non-obvious from commit logs and diffs | 12:28 |
| Wizzup | sicelo: wrt I guess that if the fix is non obvious then I can try a bisect since I'm set up for it now and I have all the required fixes for all the different versions to even boot etc, which will cost me more time say a few weeks from now | 12:30 |
| Wizzup | wrt the bisect I guess* | 12:30 |
| Wizzup | sicelo: so I am seeing this: | 12:41 |
| Wizzup | [ 26.682403] lp5523x: probe of 2-0032 failed with error -22 | 12:41 |
| Wizzup | nevermind, that's in your message as well | 12:41 |
| Wizzup | sry | 12:41 |
| Wizzup | sicelo: did you see 9b663b34c94a78f39fa2c7a8271b1f828b546e16 / 7749510c459c10c431d746a4749e7c9cf2899156 | 12:46 |
| Wizzup | probably we just need this | 12:46 |
| Wizzup | also I guess a5d3d1adc95f4ac5968b7a77ee95a3abbbb96f49 is the 'other variant' on the commit you mentioned | 12:46 |
| Wizzup | sicelo: lp5523:kb* are all white leds, no? | 12:48 |
| Wizzup | ok it's a multi faceted problem I think, I think I have fix | 13:00 |
| sicelo | kb* all white, yes. my dts patch has white for those | 13:01 |
| * sicelo checks those patches | 13:01 | |
| Wizzup | just a sec | 13:02 |
| Wizzup | I think the multiclass was also missing from config | 13:02 |
| Wizzup | err multicolor | 13:02 |
| Wizzup | CONFIG_LEDS_CLASS_MULTICOLOR that is | 13:02 |
| Wizzup | hrm, still fails to probe | 13:06 |
| sicelo | LEDS_CLASS_MULTICOLOR is not needed for N900, if i understand the meaning of that config correctly. "This class is not intended for single color LEDs." ... although it looks like one LED, ours is 3 LED from kernel POV | 13:07 |
| Wizzup | hm | 13:08 |
| Wizzup | I got confused by the config change in 92a81562e695 | 13:08 |
| Wizzup | + depends on LEDS_CLASS_MULTICOLOR || !LEDS_CLASS_MULTICOLOR | 13:08 |
| Wizzup | that's kinda .. weird | 13:08 |
| Wizzup | ah, I did not pick up on your function changes | 13:08 |
| sicelo | :-) | 13:11 |
| sicelo | i was honestly taken aback when a5d3d1adc95f4ac5968b7a77ee95a3abbbb96f49 or similar appeared. the lp55* datasheet says it needs active high. tbh, i think the GPIOD_ASIS is more correct, assuming the state/direction should come from dts. n900 already specifies "enable-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */" ... so theoretically this whole thing should be working without any patching | 13:13 |
| Wizzup | let me take a look at that after this | 13:15 |
| Wizzup | if the dts change works, will you submit it to the dts ml or shall I? fine either way, I just want it all submitted | 13:15 |
| Wizzup | it looks like just your dts change is not enough | 13:16 |
| sicelo | ok. it wasn't enough for me too back then (but i was hoping by now it would be) :-) | 13:17 |
| Wizzup | so you're suggesting I take the HIGH change and see if it works? | 13:17 |
| sicelo | yes | 13:17 |
| sicelo | it will work, definitely :-) | 13:18 |
| Wizzup | also, if this gpio descriptor thing really messes things up then I am not surprised audio doesn't work | 13:18 |
| Wizzup | and isp1707 as well | 13:19 |
| Wizzup | although the isp one might be related to my blacklist | 13:19 |
| Wizzup | well one thing at a time | 13:19 |
| sicelo | right. so it means the real fix is in something that handles general gpio then, not specifically lp55xx or other affected subsystems | 13:20 |
| Wizzup | it looks like the gpio change was on purpose, per a5d3d1adc95f4ac5968b7a77ee95a3abbbb96f49 | 13:20 |
| sicelo | i think that was a 'hack' ... like my own lp55xx change possibly is | 13:21 |
| sicelo | also, that a5d3d1adc95f4ac5968 came AFTER rgb already wasn't working for us | 13:22 |
| Wizzup | too bad he doesn't mention a commit hash | 13:22 |
| sicelo | my mail was in april, and that's only after i had found a hack/fix. the issue had been there for much longer than that (plus it took me a long time to figure out - kernel noob here) | 13:23 |
| Wizzup | it's not like I know a lot more about kernel :) | 13:23 |
| Wizzup | but yeah | 13:23 |
| Wizzup | hmm | 13:23 |
| Wizzup | let's see if I can find these "Convert to use GPIO descriptors" commits | 13:23 |
| Wizzup | -22 is what, einval? | 13:24 |
| Wizzup | yeah | 13:25 |
| sicelo | yup | 13:25 |
| Wizzup | ac219bf3c9bdf9200767e8c98a56ad42c75e5cd5 is leds: lp55xx: Convert to use GPIO descriptors | 13:26 |
| sicelo | hehe, you do know more than myself. anyway, looks like the Convert to use GPIO descriptors came from linusw | 13:26 |
| sicelo | ah, you got it | 13:26 |
| Wizzup | sicelo: I wonder if each led@ entry needs a 'reg' entry somehow | 13:38 |
| Wizzup | per lp55xx_parse_common_child | 13:38 |
| sicelo | there is, in my dts patch | 13:38 |
| Wizzup | how did I miss that :( | 13:39 |
| sicelo | :-) | 13:39 |
| sicelo | actually i can say with some certainty that this dts patch is correct. i held back submitting it at that time because i wanted to find proper fix for the led itself, but LED people took a very long time to respond (april to august). by then i had little spare time. maybe i should do it right away | 13:42 |
| Wizzup | give me a sec just to confirm it works | 13:42 |
| Wizzup | sicelo: please take a moment and confirm that your patch works, I can't get this to work somehow | 13:44 |
| Wizzup | maybe I missed something else, idk | 13:44 |
| Wizzup | I still get -EINVAL | 13:45 |
| sicelo | you have dts patch + lp55xx patch? | 13:45 |
| Wizzup | why would I get einval with the HIGH->LOW change though | 13:46 |
| Wizzup | I'll do that now, but I do not have high hopes | 13:46 |
| sicelo | you need both :-) | 13:46 |
| Wizzup | ok | 13:46 |
| Wizzup | I'll make a coffee while this boots | 13:47 |
| sicelo | i also don't have a very good explanation for the HIGH->LOW thing. because of a5d3d1adc95f4ac5968, i can say that adjusting it inside the driver is probably a hack | 13:50 |
| Wizzup | sicelo: yes that works | 13:54 |
| Wizzup | let me commit it to our n900 wip branch at least | 13:54 |
| Wizzup | sicelo: I wonder why enable-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */ is not used from dts | 13:57 |
| Wizzup | shouldn't it? | 13:57 |
| sicelo | precisely my question! i still think GPIOD_ASIS is correct in the driver, because dts should tell it we need HIGH. as for why it doesn't work ... beats me | 13:58 |
| Wizzup | ok | 13:58 |
| Wizzup | i pushed the wip patch here https://github.com/maemo-leste/droid4-linux/commits/wip/n900/maemo-5.15 | 13:58 |
| sicelo | you'll see i mentioned it here, https://www.spinics.net/lists/linux-leds/msg18183.html | 13:59 |
| Wizzup | yeah | 13:59 |
| Wizzup | I guess I've been doing this for too many days in a day and need to go outside ;) | 13:59 |
| sicelo | you've done really great work for the N900 in last few days. i appreciate it | 14:01 |
| sicelo | where's "Conversations"? i would like to install it on the Droid 4 | 14:03 |
| Wizzup | should be in beowulf-devel | 14:03 |
| Wizzup | apt install conversations | 14:04 |
| sicelo | ah, i see, it's in core | 14:04 |
| Wizzup | yeah | 14:04 |
| Wizzup | sicelo: wondering if ac219bf3c9bdf9200767e8c98a56ad42c75e5cd5 requires 'enable' not 'enable-gpios' or 'enable-gpio' | 14:04 |
| sicelo | mmmm, i think the dts binding docs say it differently | 14:05 |
| Wizzup | per https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib.c#L3845 | 14:06 |
| sicelo | please try 'enable' though ... i don't recall if i tried it | 14:06 |
| Wizzup | hm: https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib-of.c#L492 | 14:06 |
| Wizzup | /* Try GPIO property "foo-gpios" and "foo-gpio" */ | 14:06 |
| sicelo | so maybe lp55xx should have enable-gpios instead of just enable :-) | 14:08 |
| sicelo | that makes a lot of sense to me | 14:08 |
| Wizzup | well it has that in your patch | 14:08 |
| Wizzup | but that didn't work, I think? | 14:09 |
| Wizzup | with just enable I get this: | 14:09 |
| Wizzup | [ 27.733764] lp5523x 2-0032: device detection err: -121 | 14:09 |
| Wizzup | [ 27.759643] omap-sham 480c3000.sham: will run requests pump with realtime priority | 14:09 |
| Wizzup | [ 27.811279] lp5523x: probe of 2-0032 failed with error -121 | 14:09 |
| sicelo | no. my patch hardcodes HIGH. the other guy hardcodes LOW. but i think ASIS gets what's in DTS ... except possibly in this case, the dts property doesn't get read by the driver since driver looks for 'enable' instaed of enable-gpios. | 14:10 |
| sicelo | i also did get the -121 when HIGH was not hardcoded | 14:10 |
| Wizzup | let me double check my assertions | 14:10 |
| Wizzup | so the driver does this: | 14:11 |
| Wizzup | pdata->enable_gpiod = devm_gpiod_get_optional(dev, "enable", | 14:11 |
| Wizzup | GPIOD_ASIS); | 14:11 |
| Wizzup | //GPIOD_OUT_HIGH); | 14:11 |
| Wizzup | (either with ASIS or HIGH) | 14:11 |
| Wizzup | agreed? | 14:11 |
| sicelo | yes | 14:11 |
| Wizzup | (or LOW) | 14:11 |
| Wizzup | ok so that ends up in the link I sent | 14:11 |
| Wizzup | which tries "%s-%s" | 14:11 |
| Wizzup | which is "enable-gpios" | 14:11 |
| Wizzup | and "enable-gpio" | 14:11 |
| Wizzup | so I think the driver does the right thing wrt the name at least if we have "enable-gpios" | 14:12 |
| sicelo | ok | 14:12 |
| sicelo | so i don't know why ASIS doesn't work | 14:13 |
| Wizzup | omg just grepping for this in dmesg is scary: | 14:13 |
| Wizzup | dmesg|grep of_get_named_gpiod_flags | 14:13 |
| Wizzup | at least with | grep "can't" added | 14:13 |
| Wizzup | [ 26.930053] of_get_named_gpiod_flags: can't parse 'enable-gpios' property of node '/ocp@68000000/i2c@48072000/lp5523@32[0]' | 14:14 |
| sicelo | heh, i think i know what you see :-P | 14:14 |
| Wizzup | [ 27.140014] of_get_named_gpiod_flags: can't parse 'enable-gpio' property of node '/ocp@68000000/i2c@48072000/lp5523@32[0]' | 14:14 |
| Wizzup | voila | 14:14 |
| Wizzup | but that is with my "enable" | 14:14 |
| Wizzup | so let's revert that and see what happens | 14:14 |
| Wizzup | just for the record https://dpaste.com/7D4REVWNS | 14:14 |
| sicelo | i think it'll be exactly the same. | 14:15 |
| sicelo | from my mail, i got -22 when dts was still unpatched. after patching it to be in line with current binding docs, i started getting -121. only way i could find to make it work was the hack of hardcoding HIGH. | 14:16 |
| Wizzup | ok | 14:16 |
| Wizzup | let me reproduce that first | 14:16 |
| Wizzup | then I'll add a printk to driver to print what it parses | 14:16 |
| sicelo | hehe, https://dpaste.com/7D4REVWNS yes, i saw this too. that's when i realized that our precious N900 needs a lot of dts work | 14:17 |
| Wizzup | the ssi one annoys me | 14:17 |
| Wizzup | maybe that is why the dma doesn't work or something | 14:18 |
| Wizzup | well, unlikely actually | 14:18 |
| Wizzup | one thing at a time anyway | 14:18 |
| sicelo | when i stopped working on the n900, i was trying to also get the flash LED working. iirc it's also some gpio issue | 14:18 |
| Wizzup | you'll have to remind me once this works with the ASIS commit | 14:19 |
| Wizzup | s/commit/change/ | 14:19 |
| Wizzup | or file a bug on GH :p | 14:19 |
| sicelo | remind you about the LED flash? i don't remember much now ... i just looked at it very briefly. | 14:19 |
| Wizzup | yeah, now I get this: | 14:19 |
| Wizzup | [ 27.111755] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/ocp@68000000/i2c@48072000/lp5523@32[0]' - status (0) | 14:19 |
| Wizzup | [ 27.697570] lp5523x 2-0032: device detection err: -121 | 14:19 |
| Wizzup | sicelo: I mean that it's broken | 14:19 |
| Wizzup | [ 27.702880] lp5523x: probe of 2-0032 failed with error -121 | 14:19 |
| Wizzup | I don't think we have a use for it on leste yet (no camera) | 14:20 |
| Wizzup | so I am not too worried about it atm | 14:20 |
| sicelo | yeah, agreed | 14:20 |
| sicelo | but i wanted to use it as a torch :p | 14:20 |
| sicelo | not urgent need though | 14:20 |
| sicelo | you fixed the ssi one, didn't you? | 14:21 |
| sicelo | or you think it's a hack? | 14:21 |
| Wizzup | https://stackoverflow.com/questions/47393813/linux-gpiod-get-and-gpiod-asis | 14:24 |
| Wizzup | sicelo: not sure, it depends on if dma ever worked with ssi | 14:24 |
| sicelo | alright | 14:25 |
| Wizzup | ok, so there are a few questions to answer: | 14:28 |
| Wizzup | (1) what value actually gets parsed | 14:28 |
| Wizzup | (2) does lp55xx_init_device actually use the right value, and how is it different if you specify HIGH directly | 14:29 |
| Wizzup | I will do that after a break | 14:29 |
| sicelo | agreed | 14:29 |
| sicelo | is Droid 4 known to be a bit sluggish with the new mesa/ddk/kernel? | 14:49 |
| sicelo | it's not as slow as when we didn't have acceleration, but noticeably slower than it was on ddk 1.9. or i have a broken install? any hints on what to check? | 14:50 |
| sicelo | my battery is 700mAh now :( | 14:51 |
| Wizzup | it should be as fast | 14:52 |
| Wizzup | are you on -experimental? | 14:52 |
| sicelo | yes, experimental is enabled | 14:55 |
| Wizzup | apt dist-upgrade? | 15:02 |
| Wizzup | so asis says: | 15:04 |
| Wizzup | * GPIOD_ASIS or 0 to not initialize the GPIO at all. The direction must be set later with one of the dedicated functions. | 15:04 |
| Wizzup | and I don't think I see the direction being set anywhere | 15:04 |
| sicelo | hence forcing it works | 15:06 |
| Wizzup | yes | 15:07 |
| Wizzup | but the driver doesn't call gpiod_direction_output | 15:07 |
| Wizzup | and I think it should | 15:07 |
| sicelo | agreed. that'd possibly remove the need for HIGH/LOW hacks | 15:08 |
| Wizzup | I think the value for that call should be 0 | 15:09 |
| Wizzup | since that's also the first thing _init sets | 15:09 |
| Wizzup | works :) | 15:09 |
| Wizzup | (with ASIS) | 15:10 |
| sicelo | lovely. what's the fix? :-) | 15:10 |
| Wizzup | let me jsut check the sysfs nodes first | 15:11 |
| Wizzup | I saw no errors in dmesg | 15:11 |
| Wizzup | but basically this: | 15:11 |
| Wizzup | @@ -439,6 +439,8 @@ int lp55xx_init_device(struct lp55xx_chip *chip) | 15:11 |
| Wizzup | return -EINVAL; | 15:11 |
| Wizzup | if (pdata->enable_gpiod) { | 15:11 |
| Wizzup | + gpiod_direction_output(pdata->enable_gpiod, 0); | 15:11 |
| Wizzup | + | 15:11 |
| Wizzup | gpiod_set_consumer_name(pdata->enable_gpiod, "LP55xx enable"); | 15:11 |
| Wizzup | and revert the LOW commit | 15:11 |
| sicelo | i think this is THE fix indeed :-) | 15:11 |
| sicelo | no ugly hardcoding | 15:11 |
| Wizzup | I'll mail pavel momentarily and submit a patch later - do you want to do the dts part of it? | 15:12 |
| Wizzup | np if not, just lmk | 15:12 |
| sicelo | thanks! | 15:12 |
| sicelo | i can do the dts. sure. it looks correct to you too? | 15:13 |
| Wizzup | I think so, maybe we should test the leds from sysfs just in case | 15:16 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commits/wip/n900/maemo-5.15 | 15:16 |
| sicelo | i'll wait for your tests. from my testing all was well | 15:16 |
| sicelo | but it's been a while ... i won't be surprised if something else is up now | 15:17 |
| Wizzup | we'll need to mark both commits with the right fixes: as well | 15:17 |
| Wizzup | so let's send them in tandem' | 15:17 |
| sicelo | or, send both of them. it's perfectly fine ;) | 15:19 |
| Wizzup | it's your work, don't want to take credit | 15:19 |
| Wizzup | maybe I could send it with you as author | 15:19 |
| Wizzup | I don't know much about the bureaucracy around patch submission | 15:20 |
| Wizzup | sometimes I do, but then I try to forget again :P | 15:20 |
| sicelo | :) | 15:20 |
| * Wizzup brushes off git send-email | 15:20 | |
| sicelo | i also don't really know, hehe. i recall reading about it a bit back then, but can't recall off the top of my head either | 15:21 |
| sicelo | let me send it then. will do it in a couple of hours | 15:21 |
| Wizzup | I'm fine with sending it -- oh ok :P | 15:21 |
| Wizzup | btw for the ssi parse problem, it parses fine | 15:23 |
| Wizzup | it just tries gpios before gpio | 15:23 |
| Wizzup | so we just need to add an s there to get rid of the meaningless warning | 15:23 |
| Wizzup | sicelo: you agree that kb1 is rightmost keyboard led? | 15:24 |
| Wizzup | if so, it all works | 15:24 |
| Wizzup | I'll get the fixes: stuff in the above git tree | 15:27 |
| Wizzup | jfyi I dropped you a pm about your email, I think the patches are ready | 15:36 |
| sicelo | cool. please go ahead :-) | 15:42 |
| Wizzup | ok | 15:47 |
| Wizzup | I'm going to send them all at once so it'll be another day or two maybe | 15:47 |
| Wizzup | btw, maybe this is why audio doesn't probe: | 15:54 |
| Wizzup | [ 28.327880] omap_i2c 48072000.i2c: controller timed out | 15:54 |
| Wizzup | so maybe 89f845a6dcd38a2b83b995cb6a8c7ef3e5abfd3a | 15:55 |
| Wizzup | nah probably not.. | 15:56 |
| Wizzup | freemangordon: looks like in 2013 you saw same error as we see now with n900 audio | 16:03 |
| Wizzup | https://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2013-12-01.log.html | 16:03 |
| Wizzup | search for "rx51-audio rx51-audio: snd_soc_register_card failed (-517)" | 16:03 |
| Wizzup | I'm pretty sure the i2c timeout is the problem here | 16:10 |
| Wizzup | actually that would be weird.. | 16:14 |
| Wizzup | since leds are on the same bus | 16:14 |
| sicelo | there have been some recent commits touching tlv320aic31xx. i hope those aren't going to affect us. at least a quick look showed that we have TLV320AIC3X. fingers crossed that they don't affect each other negatively, otherwise more fun ahead :p | 16:20 |
| Wizzup | yeah a lot of commits | 16:20 |
| Wizzup | still the bus timeout is a bit scary | 16:20 |
| Wizzup | looks like at least 5.7 works | 16:27 |
| freemangordon | Wizzup: I remember something holding i2c buss down | 16:30 |
| freemangordon | *bus | 16:30 |
| freemangordon | fmtx? | 16:30 |
| freemangordon | not really sure, it was a while ago | 16:31 |
| Wizzup | phew | 16:33 |
| Wizzup | I think I might better just clean up existing patches first | 16:33 |
| Wizzup | I guess one final bisect... | 16:41 |
| Wizzup | freemangordon: btw whenever you think you're ready with n900 sgx we can move that kernel to devel | 17:23 |
| Wizzup | with all my fixes it's fine/stable as long as we don't enable off mode from userspace | 17:24 |
| Wizzup | there's just the X crash atm | 17:24 |
| Wizzup | brb | 17:24 |
| _uvos_ | rotation dosent work right? but it dosent in stable either | 18:58 |
| Wizzup | right | 18:58 |
| _uvos_ | the question is what happens when you try to rotate | 18:58 |
| Wizzup | I can try after I finish this audio bisect | 18:58 |
| Wizzup | audio on n900 is broken by a96d2ba2d8248d5e8170f2f44f98d4a33329b08a | 20:42 |
| sicelo | hehe, so indeed TLV320AIC stuff ... while you're at that, please check the very recent tlv320aic31xx commits then, if you have a chance. i think they're from last week or so. i doubt they'll affect us, but since it's same device family, who knows | 20:48 |
| Wizzup | it's kinda lame | 20:48 |
| Wizzup | I think the fix is just a defconfig change | 20:48 |
| Wizzup | and I thought I checked for it but the device names are not human friendly | 20:48 |
| Wizzup | CONFIG_SND_SOC_TLV320AIC23_I2C vs CONFIG_SND_SOC_TLV320AIC3X_I2C | 20:48 |
| uvos | Wizzup: while your at it maybe you want to bisect why hdmi audio stopped working between 5.8 and i think 5.10 :P | 20:49 |
| Wizzup | ;_; | 20:49 |
| Wizzup | uvos: I'm doing this because I have a serial and it's hard to do it on the n900 without serial | 20:54 |
| Wizzup | I expect some support for the d4 ;-) | 20:54 |
| uvos | :P | 20:54 |
| uvos | fine | 20:54 |
| sicelo | Wizzup: n900 is aic3x, not the aic23 | 20:55 |
| sicelo | or you mean that they all use AIC23 config now? | 20:57 |
| Wizzup | the one the n900 uses is not in omap2plus_defconfig because a96d2ba2d8248d5e8170f2f44f98d4a33329b08a changes the config name | 20:57 |
| Wizzup | and I thought I checked for it before the bisect but I got misread | 20:58 |
| Wizzup | but I misread | 20:58 |
| Wizzup | well the module loads now | 21:06 |
| Wizzup | I get an audio card but now I need to figure out what 10000 mixers to set again :) | 21:06 |
| sicelo | the famous sound card | 21:11 |
| Wizzup | lol | 21:12 |
| Wizzup | uvos: we can drop "drm/omap: get fbdev working for manually updated display" right? | 21:36 |
| uvos | no | 21:38 |
| uvos | that patch dose work | 21:38 |
| uvos | but it has problems with caching | 21:39 |
| uvos | that cause missed pixels | 21:39 |
| uvos | thus its not in mainline | 21:39 |
| uvos | but its also the only way the fbdev interface works at all on mapphones | 21:39 |
| Wizzup | I mean do we need fbdev still? | 21:41 |
| uvos | i have not flipped charge mode over | 21:41 |
| uvos | i have to test it on every device | 21:41 |
| uvos | also fbkeyboard | 21:41 |
| uvos | also why would we want the interface to be broken? | 21:41 |
| Wizzup | ok, let's keep it | 21:42 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commits/wip/n900/maemo-5.15-cleaned-up | 21:45 |
| Wizzup | this ought to just work | 21:46 |
| Wizzup | sicelo: ^^ | 21:46 |
| Wizzup | and it gives audio btw | 21:55 |
| Wizzup | MartijnBraam[m]: did pmos find a new maintainer for n900 ? | 23:10 |
| MartijnBraam[m] | hmm | 23:10 |
| MartijnBraam[m] | https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2708 | 23:10 |
| MartijnBraam[m] | danct touched it last :D | 23:11 |
| MartijnBraam[m] | saw the kernel tweet, very nice | 23:11 |
| Wizzup | I seemed to recall you were looking for a maintainer | 23:12 |
| Wizzup | maybe I missed that | 23:12 |
| Wizzup | yeah I'm trying to upstream all the patches now | 23:12 |
| MartijnBraam[m] | yeah because currently I'm co-maintainer and the other maintainer is not active, and I'm having too much stuff to maintain :P | 23:14 |
| MartijnBraam[m] | a few people responded that they'd maintain it but nobody did it so far | 23:14 |
| Wizzup | ok | 23:15 |
| sicelo | i am going to pick it up, but not in time for the upcoming release | 23:15 |
| Wizzup | I'll poke you when more stuff is merged | 23:15 |
| MartijnBraam[m] | sicelo: oh it's not for the upcoming release, but it needs maintainership at all :) | 23:15 |
| MartijnBraam[m] | awesome Wizzup | 23:15 |
| sicelo | yes, i definitely will pick it up. | 23:15 |
| uvos | would be neat if someone also updated the d4 a bit | 23:16 |
| uvos | it still uses kernel 3.0.8 with libhybris on pmos | 23:16 |
| uvos | outch :P | 23:16 |
| sicelo | actually i want to do them together, and work with mighty17[m] to use same kernel on all three | 23:17 |
| uvos | that would be great :) | 23:17 |
| tk | so it sounds like maemo-leste is going to be viable on the N900 soon-ish? | 23:27 |
| tk | I should fix my N900 | 23:27 |
| uvos | no | 23:29 |
| uvos | or well | 23:29 |
| uvos | depends on what the bar for viable is for you | 23:29 |
| uvos | n900 gets usable 3d accleration and ok battery life soon | 23:30 |
| uvos | but call audio remains unsolved and our guis for calls and sms etc are not finished | 23:30 |
| Wizzup | there is some support for call audio, but it needs more work for sure | 23:36 |
| Wizzup | we hope to at least have a usable sms ui at the end of january, calls maybe around that time too, that's tbd | 23:36 |
| Wizzup | sicelo: sent led patches, let's see if people complain | 23:36 |
| Wizzup | also sent the wifi patch half an hour ago | 23:38 |
| Wizzup | not sure if they will take it, but let's see | 23:38 |
| tk | by soon I mean N900 timescales soon | 23:40 |
| tk | in like a year | 23:40 |
| uvos | oh sure | 23:40 |
| uvos | both mapphones and n900 should be viable by then | 23:40 |
| tk | mapphones? | 23:40 |
| uvos | motorola droid 4, droid bionic, droid 3 | 23:41 |
| tk | i see | 23:41 |
| uvos | they are a bit ahead in the usability department on lesta atm, the changes to the n900 are it finaly catching up :) | 23:42 |
| uvos | so these and n900 should be viable at the same time | 23:42 |
| tk | cool | 23:42 |
| tk | that's very nice | 23:42 |
| tk | what's the web browsing situation looking like? | 23:42 |
| tk | is there something light enough which can still load some pages? | 23:43 |
| uvos | on maphones its fine really | 23:43 |
| uvos | they work on with firefox and there is also qtwebrowser | 23:43 |
| tk | I spent years being quite fine with the N900's default browser with javascript disabled | 23:43 |
| uvos | the main problem with n900 | 23:43 |
| uvos | is its ram | 23:43 |
| uvos | its very litte for a modern layout engine with bloated modern sites | 23:43 |
| tk | yes | 23:44 |
| tk | so something like the droid 4 would be more viable in terms of a phone with a keyboard running maemo? | 23:44 |
| uvos | i dont see this changing and a very restrictive browser like netsurf and not using big heavy sites will allways be what is needed for n900 | 23:44 |
| uvos | tk: i think n900 can be viable too | 23:44 |
| Wizzup | yeah, something like netsurf or the other minimal no-js browsers should work on the n900 | 23:45 |
| uvos | but yeah the mapphones offer mutch better expierance performance wise ofc | 23:45 |
| Wizzup | we're aiming for the n900 to still work with our core stuff | 23:45 |
| tk | cool | 23:45 |
| tk | an unrelated question, anyone know where to get decent N900 batteries? | 23:45 |
| uvos | polarcell | 23:45 |
| tk | hmm, okay, I found that brand too | 23:45 |
| tk | although then I stopped finding it | 23:46 |
| uvos | thos are pretty good really | 23:46 |
| tk | okay, found them again | 23:49 |
| tk | does leste have a donation page or something? | 23:52 |
| uvos | no we dont | 23:52 |
| uvos | and we lack an organization to accept donations | 23:53 |
| uvos | i gues you would donate to one of us personally but i dont think any of us currently accept donations | 23:53 |
| uvos | *s/would/could | 23:53 |
| tk | if you're ever in the UK near london, I'll buy anyone here a beer. | 23:54 |
| Wizzup | hehe :-) | 23:54 |
| tk | (at the very least) | 23:54 |
| Wizzup | We do plan to set up an organisation, I'm waiting for some advice, but perhaps we should just move forward asap | 23:54 |
| Wizzup | tmlind: sent out initial rfc for droid 3 | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!