<Wizzup>
yeah ok reverting f959dcd6ddfd29235030e8026471ac1b022ad2b0 makes the modem work
<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)
<Wizzup>
it looks more likely to me that this path was taken
<Wizzup>
it's an old sim, so it's denied, but hey, it works:
<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
<sicelo>
dts also needs to be updated (because it's way out of date with current binding documentation), https://paste.debian.net/1223110/
<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
<sicelo>
there's possibility that dts by itself may suffice
<Wizzup>
ok
<Wizzup>
I wonder if the modem ever used dma or if it was always pio
<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
<sicelo>
mmm, interacting with Leste seems slower now than before. hope i didn't break anything
<Wizzup>
sicelo: hnggg I've done 4 or 5 bisects now and I was kind of hoping to be done with it
<Wizzup>
I mean I could if it's the easiest path to getting it fixed, but I'd rather not
<Wizzup>
totally unrelated, but does someone recall how to pass through the n900 modem over usb?
<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.
<Wizzup>
iirc there was some special gadget for it, right?
<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
<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
<Wizzup>
wrt the bisect I guess*
<Wizzup>
sicelo: so I am seeing this:
<Wizzup>
[ 26.682403] lp5523x: probe of 2-0032 failed with error -22
<Wizzup>
nevermind, that's in your message as well
<Wizzup>
sry
_inky has quit [Ping timeout: 252 seconds]
inky has joined #maemo-leste
<Wizzup>
sicelo: did you see 9b663b34c94a78f39fa2c7a8271b1f828b546e16 / 7749510c459c10c431d746a4749e7c9cf2899156
<Wizzup>
probably we just need this
<Wizzup>
also I guess a5d3d1adc95f4ac5968b7a77ee95a3abbbb96f49 is the 'other variant' on the commit you mentioned
inky_ has quit [Ping timeout: 250 seconds]
<Wizzup>
sicelo: lp5523:kb* are all white leds, no?
<Wizzup>
ok it's a multi faceted problem I think, I think I have fix
<sicelo>
kb* all white, yes. my dts patch has white for those
* sicelo
checks those patches
<Wizzup>
just a sec
<Wizzup>
I think the multiclass was also missing from config
<Wizzup>
err multicolor
<Wizzup>
CONFIG_LEDS_CLASS_MULTICOLOR that is
<Wizzup>
hrm, still fails to probe
<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
<Wizzup>
hm
<Wizzup>
I got confused by the config change in 92a81562e695
<Wizzup>
+ depends on LEDS_CLASS_MULTICOLOR || !LEDS_CLASS_MULTICOLOR
<Wizzup>
that's kinda .. weird
<Wizzup>
ah, I did not pick up on your function changes
<sicelo>
:-)
<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
<Wizzup>
let me take a look at that after this
<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
<Wizzup>
it looks like just your dts change is not enough
<sicelo>
ok. it wasn't enough for me too back then (but i was hoping by now it would be) :-)
Daanct12 has joined #maemo-leste
<Wizzup>
so you're suggesting I take the HIGH change and see if it works?
<sicelo>
yes
<sicelo>
it will work, definitely :-)
<Wizzup>
also, if this gpio descriptor thing really messes things up then I am not surprised audio doesn't work
<Wizzup>
and isp1707 as well
<Wizzup>
although the isp one might be related to my blacklist
<Wizzup>
well one thing at a time
<sicelo>
right. so it means the real fix is in something that handles general gpio then, not specifically lp55xx or other affected subsystems
Danct12 has quit [Ping timeout: 256 seconds]
<Wizzup>
it looks like the gpio change was on purpose, per a5d3d1adc95f4ac5968b7a77ee95a3abbbb96f49
<sicelo>
i think that was a 'hack' ... like my own lp55xx change possibly is
<sicelo>
also, that a5d3d1adc95f4ac5968 came AFTER rgb already wasn't working for us
<Wizzup>
too bad he doesn't mention a commit hash
<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)
<Wizzup>
it's not like I know a lot more about kernel :)
<Wizzup>
but yeah
<Wizzup>
hmm
<Wizzup>
let's see if I can find these "Convert to use GPIO descriptors" commits
<Wizzup>
-22 is what, einval?
<Wizzup>
yeah
<sicelo>
yup
<Wizzup>
ac219bf3c9bdf9200767e8c98a56ad42c75e5cd5 is leds: lp55xx: Convert to use GPIO descriptors
<sicelo>
hehe, you do know more than myself. anyway, looks like the Convert to use GPIO descriptors came from linusw
<sicelo>
ah, you got it
<Wizzup>
sicelo: I wonder if each led@ entry needs a 'reg' entry somehow
<Wizzup>
per lp55xx_parse_common_child
<sicelo>
there is, in my dts patch
<Wizzup>
how did I miss that :(
<sicelo>
:-)
<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
<Wizzup>
give me a sec just to confirm it works
<Wizzup>
sicelo: please take a moment and confirm that your patch works, I can't get this to work somehow
<Wizzup>
maybe I missed something else, idk
<Wizzup>
I still get -EINVAL
<sicelo>
you have dts patch + lp55xx patch?
<Wizzup>
why would I get einval with the HIGH->LOW change though
<Wizzup>
I'll do that now, but I do not have high hopes
<sicelo>
you need both :-)
<Wizzup>
ok
<Wizzup>
I'll make a coffee while this boots
<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
<Wizzup>
sicelo: yes that works
<Wizzup>
let me commit it to our n900 wip branch at least
<Wizzup>
sicelo: I wonder why enable-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */ is not used from dts
<Wizzup>
shouldn't it?
<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
<Wizzup>
[ 27.759643] omap-sham 480c3000.sham: will run requests pump with realtime priority
<Wizzup>
[ 27.811279] lp5523x: probe of 2-0032 failed with error -121
<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.
Daanct12 is now known as Danct12
<sicelo>
i also did get the -121 when HIGH was not hardcoded
<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.
<Wizzup>
ok
<Wizzup>
let me reproduce that first
<Wizzup>
then I'll add a printk to driver to print what it parses
<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
<Wizzup>
the ssi one annoys me
<Wizzup>
maybe that is why the dma doesn't work or something
<Wizzup>
well, unlikely actually
<Wizzup>
one thing at a time anyway
<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
<Wizzup>
you'll have to remind me once this works with the ASIS commit
<Wizzup>
s/commit/change/
<Wizzup>
or file a bug on GH :p
<sicelo>
remind you about the LED flash? i don't remember much now ... i just looked at it very briefly.
<Wizzup>
yeah, now I get this:
<Wizzup>
[ 27.111755] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/ocp@68000000/i2c@48072000/lp5523@32[0]' - status (0)
<Wizzup>
sicelo: not sure, it depends on if dma ever worked with ssi
<sicelo>
alright
<Wizzup>
ok, so there are a few questions to answer:
<Wizzup>
(1) what value actually gets parsed
<Wizzup>
(2) does lp55xx_init_device actually use the right value, and how is it different if you specify HIGH directly
<Wizzup>
I will do that after a break
<sicelo>
agreed
<sicelo>
is Droid 4 known to be a bit sluggish with the new mesa/ddk/kernel?
<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?
<sicelo>
my battery is 700mAh now :(
<Wizzup>
it should be as fast
<Wizzup>
are you on -experimental?
<sicelo>
yes, experimental is enabled
<Wizzup>
apt dist-upgrade?
<Wizzup>
so asis says:
<Wizzup>
* GPIOD_ASIS or 0 to not initialize the GPIO at all. The direction must be set later with one of the dedicated functions.
<Wizzup>
and I don't think I see the direction being set anywhere
<sicelo>
hence forcing it works
<Wizzup>
yes
<Wizzup>
but the driver doesn't call gpiod_direction_output
<Wizzup>
and I think it should
<sicelo>
agreed. that'd possibly remove the need for HIGH/LOW hacks
<Wizzup>
I think the value for that call should be 0
<Wizzup>
since that's also the first thing _init sets
<Wizzup>
works :)
<Wizzup>
(with ASIS)
<sicelo>
lovely. what's the fix? :-)
<Wizzup>
let me jsut check the sysfs nodes first
<Wizzup>
I saw no errors in dmesg
<Wizzup>
but basically this:
<Wizzup>
return -EINVAL;
<Wizzup>
@@ -439,6 +439,8 @@ int lp55xx_init_device(struct lp55xx_chip *chip)
<Wizzup>
search for "rx51-audio rx51-audio: snd_soc_register_card failed (-517)"
<Wizzup>
I'm pretty sure the i2c timeout is the problem here
<Wizzup>
actually that would be weird..
<Wizzup>
since leds are on the same bus
<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
<Wizzup>
yeah a lot of commits
<Wizzup>
still the bus timeout is a bit scary
<Wizzup>
looks like at least 5.7 works
<freemangordon>
Wizzup: I remember something holding i2c buss down
<freemangordon>
*bus
<freemangordon>
fmtx?
<freemangordon>
not really sure, it was a while ago
<Wizzup>
phew
<Wizzup>
I think I might better just clean up existing patches first
<Wizzup>
I guess one final bisect...
inky has quit [Remote host closed the connection]
<Wizzup>
freemangordon: btw whenever you think you're ready with n900 sgx we can move that kernel to devel
<Wizzup>
with all my fixes it's fine/stable as long as we don't enable off mode from userspace
<Wizzup>
there's just the X crash atm
<Wizzup>
brb
pere has quit [Ping timeout: 252 seconds]
_uvos_ has joined #maemo-leste
<_uvos_>
rotation dosent work right? but it dosent in stable either
<Wizzup>
right
<_uvos_>
the question is what happens when you try to rotate
<Wizzup>
I can try after I finish this audio bisect
_inky has joined #maemo-leste
_uvos_ has quit [Ping timeout: 268 seconds]
_uvos_ has joined #maemo-leste
pere has joined #maemo-leste
_uvos_ has quit [Ping timeout: 256 seconds]
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #maemo-leste
_inky has quit [Ping timeout: 256 seconds]
uvos has joined #maemo-leste
_inky has joined #maemo-leste
<Wizzup>
audio on n900 is broken by a96d2ba2d8248d5e8170f2f44f98d4a33329b08a
<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
<Wizzup>
it's kinda lame
<Wizzup>
I think the fix is just a defconfig change
<Wizzup>
and I thought I checked for it but the device names are not human friendly
<Wizzup>
CONFIG_SND_SOC_TLV320AIC23_I2C vs CONFIG_SND_SOC_TLV320AIC3X_I2C
<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
<Wizzup>
;_;
<Wizzup>
uvos: I'm doing this because I have a serial and it's hard to do it on the n900 without serial
<Wizzup>
I expect some support for the d4 ;-)
<uvos>
:P
<uvos>
fine
<sicelo>
Wizzup: n900 is aic3x, not the aic23
<sicelo>
or you mean that they all use AIC23 config now?
<Wizzup>
the one the n900 uses is not in omap2plus_defconfig because a96d2ba2d8248d5e8170f2f44f98d4a33329b08a changes the config name
<Wizzup>
and I thought I checked for it before the bisect but I got misread
<Wizzup>
but I misread
<Wizzup>
well the module loads now
<Wizzup>
I get an audio card but now I need to figure out what 10000 mixers to set again :)
<sicelo>
the famous sound card
<Wizzup>
lol
<Wizzup>
uvos: we can drop "drm/omap: get fbdev working for manually updated display" right?
<uvos>
no
<uvos>
that patch dose work
<uvos>
but it has problems with caching
<uvos>
that cause missed pixels
<uvos>
thus its not in mainline
<uvos>
but its also the only way the fbdev interface works at all on mapphones
<Wizzup>
I mean do we need fbdev still?
<uvos>
i have not flipped charge mode over
<uvos>
i have to test it on every device
<uvos>
also fbkeyboard
<uvos>
also why would we want the interface to be broken?
<Wizzup>
I seemed to recall you were looking for a maintainer
<Wizzup>
maybe I missed that
<Wizzup>
yeah I'm trying to upstream all the patches now
<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
<MartijnBraam[m]>
a few people responded that they'd maintain it but nobody did it so far
<Wizzup>
ok
<sicelo>
i am going to pick it up, but not in time for the upcoming release
<Wizzup>
I'll poke you when more stuff is merged
<MartijnBraam[m]>
sicelo: oh it's not for the upcoming release, but it needs maintainership at all :)
<MartijnBraam[m]>
awesome Wizzup
<sicelo>
yes, i definitely will pick it up.
<uvos>
would be neat if someone also updated the d4 a bit
<uvos>
it still uses kernel 3.0.8 with libhybris on pmos
<uvos>
outch :P
<sicelo>
actually i want to do them together, and work with mighty17[m] to use same kernel on all three
<uvos>
that would be great :)
tk has joined #maemo-leste
<tk>
so it sounds like maemo-leste is going to be viable on the N900 soon-ish?
<tk>
I should fix my N900
<uvos>
no
<uvos>
or well
<uvos>
depends on what the bar for viable is for you
<uvos>
n900 gets usable 3d accleration and ok battery life soon
<uvos>
but call audio remains unsolved and our guis for calls and sms etc are not finished
<Wizzup>
there is some support for call audio, but it needs more work for sure
<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
<Wizzup>
sicelo: sent led patches, let's see if people complain
<Wizzup>
also sent the wifi patch half an hour ago
<Wizzup>
not sure if they will take it, but let's see
<tk>
by soon I mean N900 timescales soon
<tk>
in like a year
<uvos>
oh sure
<uvos>
both mapphones and n900 should be viable by then
<tk>
mapphones?
<uvos>
motorola droid 4, droid bionic, droid 3
<tk>
i see
<uvos>
they are a bit ahead in the usability department on lesta atm, the changes to the n900 are it finaly catching up :)
<uvos>
so these and n900 should be viable at the same time
<tk>
cool
<tk>
that's very nice
<tk>
what's the web browsing situation looking like?
<tk>
is there something light enough which can still load some pages?
<uvos>
on maphones its fine really
<uvos>
they work on with firefox and there is also qtwebrowser
<tk>
I spent years being quite fine with the N900's default browser with javascript disabled
<uvos>
the main problem with n900
<uvos>
is its ram
<uvos>
its very litte for a modern layout engine with bloated modern sites
<tk>
yes
<tk>
so something like the droid 4 would be more viable in terms of a phone with a keyboard running maemo?
<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
<uvos>
tk: i think n900 can be viable too
<Wizzup>
yeah, something like netsurf or the other minimal no-js browsers should work on the n900
<uvos>
but yeah the mapphones offer mutch better expierance performance wise ofc
<Wizzup>
we're aiming for the n900 to still work with our core stuff
<tk>
cool
<tk>
an unrelated question, anyone know where to get decent N900 batteries?
<uvos>
polarcell
<tk>
hmm, okay, I found that brand too
<tk>
although then I stopped finding it
<uvos>
thos are pretty good really
<tk>
okay, found them again
linmob has quit [Remote host closed the connection]
linmob has joined #maemo-leste
<tk>
does leste have a donation page or something?
<uvos>
no we dont
<uvos>
and we lack an organization to accept donations
<uvos>
i gues you would donate to one of us personally but i dont think any of us currently accept donations
<uvos>
*s/would/could
<tk>
if you're ever in the UK near london, I'll buy anyone here a beer.
<Wizzup>
hehe :-)
<tk>
(at the very least)
<Wizzup>
We do plan to set up an organisation, I'm waiting for some advice, but perhaps we should just move forward asap
<Wizzup>
tmlind: sent out initial rfc for droid 3
<Wizzup>
tk: we'll post a news update (and tweet) when we post our news update (hopefully in a week), at which point I hope that we have a 5.15 kernel for the n900 in a ready to use image
<Wizzup>
there's more work to be done in power management, in particular, when the device actually idles properly, there is some oops, which is annoying, so we'll have to fix that
<tk>
sixwheeledbeast: yeah, I found it, thanks :P
<Wizzup>
how we'll fix that, I don't know yet, I'm hoping that tmlind will pull out some magic :-D
<uvos>
Wizzup: "omap4-droid3-xt862.dts deletes ramoops node in motorola-mapphone-common.dtsi"
<uvos>
uh you merged this against mainline right?
<uvos>
pstore for mapphones isent in mainline
<Wizzup>
uvos: oh, I see, well, it's a rfc patch
<uvos>
yeah
<uvos>
just remember that tmlinds -pending branch is not mainline
<Wizzup>
mhm
<uvos>
i have made that mistake once or twice :P
<Wizzup>
btw I forgot to CC you guys on the wifi patch, but I sent that out too