<sicelo>
here's updated MR ... it builds up on the previous commit
<sicelo>
freemangordon: please also review
<sicelo>
i've tested this extensively on my Leste N900, and seems to work with 95% reliability.
<sicelo>
it's not 100% because there's definitely something wrong somewhere ... maybe hardware? or ke-recv? The time it takes charger chip to refresh its internal registers keeps increasing somewhat, especially when connected to a PC. seems much more reliable on a charger or power bank.
<sicelo>
i set the delay to 9s in the MR. i'm stable on 8s actually, but hoping one more sec will improve the detection a bit more. 7s didn't help much when connecting to a PC. might have worked fine from power bank but i didn't have access to one at the time
<sicelo>
will send it upstream for further review in a couple of days (hope arno11 will have given it a go too)
pere has joined #maemo-leste
ceene has quit [Remote host closed the connection]
uvos__ has quit [Ping timeout: 252 seconds]
uvos__ has joined #maemo-leste
DFP has quit [Quit: Leaving]
akossh has joined #maemo-leste
<Wizzup>
ugh hildon-thumbnailer packaging is kind of a mess
uvos has joined #maemo-leste
<uvos>
Wizzup: the audio problem on pasteur is simply down to the fact that pasteur variants have no modem audio
<uvos>
naturally the setup of the cpu<->modem and cpcap<->modem dais fails
<Wizzup>
uvos: ok, so we need to modify the dts for that?
<Wizzup>
that makes sense btw
<uvos>
yeah we need to move all the modem audio related stuff from motorola-mapphone-common to motorola-mapphone-handset
<uvos>
am working on it
<Wizzup>
check :)
<uvos>
actually mz616 might have modem audio
<uvos>
since it shares a modem setup with xt910
<uvos>
but i cant test that theory
<uvos>
Wizzup: btw
<uvos>
fbcon=rotate:1 needs to go in boot.cfg on mz617
<uvos>
thats just silly
<Wizzup>
when you say that's just silly, do you mean it's not important but good to do?
<uvos>
it needs to be removed
<uvos>
someone copy pasted that from d4
<uvos>
but mz61x is native landscape
<uvos>
so we are makeing it portrait
<uvos>
ok
<uvos>
dts changes made
<uvos>
i have audio
<uvos>
but only via the headphones
<uvos>
the speakers are probubly to large to drive directly from cpcap so they added an external amp that needs to be enabled
<uvos>
what do you know the mz617 signal map has a gpio the d4s dosent
<uvos>
external_amp_en 191
<uvos>
sounds very suspicous
<Wizzup>
ah needs to go, yes
<Wizzup>
uvos: sweet @ headphones!
<Wizzup>
uvos: suspicious as in likely the right value? :D
<uvos>
almost cerntenly thats the right gpio yeah
<uvos>
im just struggeling here to remember how the gpio numbers from the stock kernel corrspond to the gpios on the mainline kernel
<Wizzup>
I have some vague memory but it's probably more helpful if I don't help :D
<Wizzup>
as in it's probably not helpful enough
<uvos>
yeah i got that far allready
<uvos>
its &gpio5 31
<tmlind>
uvos: only am3 gpio banks start at 0 i recall, so should be &gpio6 31 on mapphones
<tmlind>
nice if you get the audio working, ttyl
<Wizzup>
uvos: btw with the headphones, do you also hit ret?
<uvos>
Wizzup: nope
<uvos>
not related
<Wizzup>
ok, too bad :D
<uvos>
yeah it works
<Wizzup>
sweet :)
<uvos>
but i have yet to figure out how to make dapm do what i want (again)
<uvos>
so i just pinned the amp on
<uvos>
unfortionatly it has an annoying buzz when cpcap is inactive but the amp is enabled
<uvos>
so i need to figure this out
<Wizzup>
hmm
akossh has quit [Quit: Leaving.]
<uvos>
in snd/soc/codecs/cpcap.c function cpcap_input_right_mux_put_enum i have no idea how to associate the parameters with cpcap_spkr_l_mux_enum and so on
<uvos>
really all we need to do there is set the amp gpio high when the mux is set to output to speaker on either channel
<uvos>
but snd/soc is complicated as usual
<inky>
> you could just use the esp32 with hw wifi for evertthing and be better off