<freemangordon>
because we want daemon started before h-d, IIUC
<arno11>
if it starts after, that's ok too
<freemangordon>
up to you
<arno11>
i think i must try both
<freemangordon>
but then you won;t hear any sound if a call comes
<freemangordon>
also, with dsmetool you can set nice value
<freemangordon>
see /usr/sbin/dsmetool -h
<freemangordon>
hmm...
<arno11>
ok
<arno11>
why no sound ?
<freemangordon>
because daemon is still not running :)
<freemangordon>
I wonder if we can teach dsme to alter scheduling priority as well
<arno11>
interesting indeed
<freemangordon>
instead of doing whatever sudoers hacks we were planning
<freemangordon>
but that will not fix the issue with PA process
<freemangordon>
as it is not dsmetool started
<freemangordon>
have to run, wish you luck :)
<arno11>
thanks :) i'll try a bit later and let you know (kids time for me)
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
uvos__: so I will double check if I am setting the freq correct, by logging to system, and then also try the latest 6.6 kernel with dts forward ported
<Wizzup>
freemangordon: I don't know @ .d or .post
<sicelo>
no need to reboot device on cmt_pulse crash
<freemangordon>
sicelo: that was just a theory :)
<freemangordon>
but we shall restart it
<freemangordon>
also, what will happen if ofono gets restarted?
<sicelo>
it should be able to keep running. there's nothing it needs in ofono besides knowing when ofono's AudioSettings interface changes to Active status
<Wizzup>
sicelo: not reboot, but restart
mdz has joined #maemo-leste
mdz has quit [Ping timeout: 268 seconds]
brosame has quit [Ping timeout: 268 seconds]
<Wizzup>
11:45 < freemangordon> I wonder if we can teach dsme to alter scheduling priority as well
<Wizzup>
you could just ship a script start-cmt-pulse.sh that does all this
<Wizzup>
and then dsme just runs this script
<Wizzup>
I think
<Wizzup>
tmlind: so uvos has been trying to help me figure out why the droid3 seems to reset (frequently) under load, I just wanted to check if you had some additional ideas
<Wizzup>
currently I'm making sure that on the first kexec call the freq is set to max (1ghz), and I think this is already the case, but just in case I will verify
<Wizzup>
then next I made cpcap register dump at each of the frequencies in android, and also one on leste, to see if there are any regs that are wrong
<Wizzup>
but I am having a hard time interpreting *what* these cpcap regs are, there is a clear diff between the freqs on android
<Wizzup>
I suppose I can make a few more dumps on android in the frequencies and see if there are regs that change in between say 300Mhz attempt 1 and 2, so that I can eliminate further certain regs that don't matter
<Wizzup>
but other than this I am kind of stuck
<Wizzup>
I suppose I could prevent say pvr from loading in case the gpu clock speed is also too high
<Wizzup>
What seems to happen is that the device just hangs, watchdog realises this and then resets:
<Wizzup>
uvos__: I confirmed that the frequency is 1000000 at the time of kexec
<Wizzup>
/system/logs/maemo-freq.txt contains:
<Wizzup>
1000000
arno11 has joined #maemo-leste
<arno11>
freemangordon: sicelo: Wizzup: ok, we have calls on N900 OOTB :)
<arno11>
it works, adding xsession/dsme stuff in libcmtspeechdata
<sicelo>
great. tyvm
<sicelo>
do we have the sphone landscape thing in place ootb too?
<arno11>
nope, still need to modify sphone.ini by hand
<Wizzup>
can't we set a gconf key?
<arno11>
don't no but probably
<arno11>
and BTW we don't need chrt stuff for cmt_pulse, we just need it for sphone and PA
<sicelo>
maybe that should go in as well (landscape thing). would be unfortunate to find your screen dead
<arno11>
true
<Wizzup>
if there is sphone.ini.d or a gconf key we can manage it with leste-config-n900
xmn has joined #maemo-leste
<Wizzup>
I updated hildon-meta, leste-config and mapphone-kexecboot-config with support for xt910 and xt912 and I split out the config and meta packages for them in case we need to diverge at some point
<Wizzup>
there is /usr/share/sphone/sphone.ini.d
<Wizzup>
arno11: what change to do you make to sphone.ini, can you share?
<Wizzup>
then I will update leste-config-n900 now
<arno11>
i was looking for the same thing :) ok let me few sec
<arno11>
you just need to add LandscapeCall=1
<arno11>
in Gui
<Wizzup>
so
<Wizzup>
[Gui]
<arno11>
yes
<Wizzup>
LandscapeCall=1
<arno11>
yes
<Wizzup>
ok one sec
<arno11>
cool :)
<Wizzup>
building new leste-config
<arno11>
:)
<Wizzup>
in a few minutes, please apt update and apt upgrade, assuming you're on leste-devel, and then check /usr/share/sphone/sphone.ini.d/landscape-call.ini
<Wizzup>
and then you can remove your change to /usr/share/sphone/sphone.ini and then see if it still works?
<arno11>
ok, yes ofc
<Wizzup>
ready to update
<Wizzup>
uvos__: static const struct dsic_panel_data razr_xt9xx_data's width_mm and height_mm doesn't match the xt910-xt912.dtsi width-mm and height-mm
<Wizzup>
I doubt this makes a difference (will check, probably just for dpi)
<Wizzup>
yeah looks like it
<sicelo>
arno11: you made PR for libcmtspeechdata? so Wizzup can rebuild that while he's here :-)
<Wizzup>
sicelo: I'm almost always here :D
<sicelo>
😃 I'll also love to test (in about 3 hours). would be nice to just apt get
<Wizzup>
uvos__: dispc_timing_hsw from the xt912dts does seem to match the hsync-len <2> in mainline dts
<arno11>
sicelo: Wizzup: i can make a PR + sphone.ini test in 30-45 min (kids around so not so easy for me)
<sicelo>
ah, no rush :-)
<Wizzup>
tmlind: it looks like panel-dsi-cm had a commit from you to support x_offset (drm/panel: panel-dsi-cm: Add update window offset), but I don't see that actually being used anywhere in the subsequent commit that adds support for xt910
<Wizzup>
tmlind: nevermind I am wrong, it is used
<Wizzup>
uvos__: so page 2085 of the omap4430 trm starts to list the dss regs, is this what you meant?
brosame has joined #maemo-leste
<Wizzup>
uvos__: rwmem just always gives me bus error on mainline, even on addrs that apparently worked for folks here according to the irc log
<arno11>
Wizzup: i did a dist-upgrade with very last stuff and now N900 refuses to shutdown but reboot instead...in less than 25 sec !!
<Wizzup>
okay, I give up for now, I'm going to use my time in a more effective way than this driver stuff
<Wizzup>
arno11: I don't think I changed anything special
<arno11>
maybe last fmg stuff with weird shutdown
<arno11>
anyway we are not far to solve the slow shutdown imo
<arno11>
wow and sphone crashes with immediate reboot (ofc not related with previous reboot)
<arno11>
Wizzup: so ATM i'm not able to test sphone.ini stuff
<Wizzup>
maybe it is not happy with the config file
<Wizzup>
i'll try it on my n900
<arno11>
i'll remove sphone.ini.d to see if sphone continue to crash
<arno11>
ok
<Wizzup>
yes please do try that
<arno11>
yup
<arno11>
sphone.ini.d seems to be the problem, currently rebooting to test
<arno11>
yes sphone is not happy with the config file indeed
<arno11>
and the fast reboot was due to sphone.ini.d as well
<arno11>
i'll make the PR for cmt_pulse now (it works fine)
<sicelo>
LandscapeCall=1 ... shouldn't that be LandscapeCalls maybe? (plural)?
<sicelo>
otherwise, i don't see why it would crash sphone, or cause reboots
<Wizzup>
I will check the src and debug if it crashes for me
Langoor has quit [Remote host closed the connection]
<arno11>
sicelo: oh yes
<arno11>
you're right
<arno11>
LandscapeCalls=1
<Wizzup>
let's hope it doesn't crash because of this
<sicelo>
i doubt the crash is due to it. in fact, it's not :-)
<Wizzup>
how do you know?
Langoor has joined #maemo-leste
<Wizzup>
so sphone does not crash for me
<Wizzup>
regardless of the key name
<Wizzup>
sphone: sphone-conf: Could not open config overide dir /home/user/.config/sphone/
<Wizzup>
sphone: sphone-conf: found conf file 0: sphone.ini
<Wizzup>
sphone: sphone-conf: found conf file 1: landscape-call.ini
<Wizzup>
arno11: so the "&" is not necessary when you use dsme
<Wizzup>
I'll adjust the dsme flags a bit
<arno11>
ok
<arno11>
rebooting to test call
<arno11>
with sphone.ini.d
<arno11>
Wizzup: wow it works (call) then the phone crashes
<arno11>
working fine without sphone.ini.d, weird
<arno11>
Wizzup: i have to go, let me know when libcmtspeechdata is ready for upgrade
<arno11>
ttyl
arno11 has left #maemo-leste [#maemo-leste]
sch has joined #maemo-leste
arno11 has joined #maemo-leste
tsesani has joined #maemo-leste
<tsesani>
I posted to the mailing list about building raspi4 images but no response. Also have been chatting in gemini://bbs.geminispace.org/s/maemo. I also released 2005 2006 2007 original code at https://github.com/tsesani/Maemo
uvos has joined #maemo-leste
<uvos>
Wizzup: no idea whats wrong with rwram, but the kernel people where discussing adding more restricitons to /dev/mem
<Wizzup>
tsesani: I did not see that email, I will respond when I get back
<uvos>
so probubly that
<uvos>
Wizzup: for the cpcap regs
<tsesani>
Running in virtual machine on Devuan 5 OK with X core every once in awhile. Nice work to all.
<uvos>
diff the state between the mainline kernel and the android kernel at the same oop
<uvos>
theres a cpcap header with the register names, they are fairly inteligable
<uvos>
use those to narrow different registers down
<uvos>
really we are most interested in regulators being different
<uvos>
bionic has some chaneges in what regs are used for what and we just assumed d3 is the same
<uvos>
so thats a good first step
<uvos>
maybe check sgx clock too, could be that we are running it to fast
<uvos>
we clocked sgx up on the mapphones relative to spec because motorola also did that on d4/bionic
<uvos>
but maybe they dident on d3
<uvos>
beyond that spme perifferals are different too between d3 and bionic
<uvos>
so maybe some periferal driver is missbehavig
<uvos>
might make sense to create a dts with everything non essental removed and see if its still unstable
tsesani has left #maemo-leste [#maemo-leste]
<uvos>
beyond that the d3 omap runns mutch older microcode that might have some additional errata fixed later, but this gets really outside of my capabilites
tsesani has joined #maemo-leste
tsesani has left #maemo-leste [#maemo-leste]
<uvos>
havent had a time to look at the dumps but oh and you might have to redo them
<uvos>
becasue we forgot to also fix the sgx opp
<uvos>
android is mutch more argessive with power manageing the sgx so its probubly in a lower power state
<Wizzup>
do you know how to fix the sgx opp?
tsesani has joined #maemo-leste
tsesani has left #maemo-leste [#maemo-leste]
uvos__ has quit [Remote host closed the connection]
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
20:28 < uvos> becasue we forgot to also fix the sgx opp
<Wizzup>
do we also need to do this before kexec?
tsesani has joined #maemo-leste
tsesani has left #maemo-leste [#maemo-leste]
pere has quit [Ping timeout: 260 seconds]
<Wizzup>
ah now I see the email on the ML
arno11 has joined #maemo-leste
<uvos>
no
<Wizzup>
uvos: regarding setting it high before kexec? I figured
<Wizzup>
still not sure how to set the sgx opp in android for the comparison test though
<Wizzup>
regarding rwmem, so I was trying to get the dss regs on mainline on the razr, and I just kept gettinb bus error
<Wizzup>
/dev/mem did exist
<Wizzup>
it also triggeed a kernel oops every time
<Wizzup>
uvos: regarding razr, I also tried some futile things like setting hsync-active to 1, same for vsync-active, didn't help
<Wizzup>
I guess I will go back to 6.1 on razr for now so I can read the dss regs
<Wizzup>
uvos: heh no, so I also get the bus error on 6.1 on razr, but not on the d4
<Wizzup>
facinating
<Wizzup>
hm..
<Wizzup>
no, ok
<Wizzup>
so the bus error happens when screen is off
<Wizzup>
I guess that makes sense
<uvos>
not sure about sgx oop in android
<uvos>
maybe just load it
<uvos>
i think i ran glmark on d4 when doing this for it
<Wizzup>
doing it for bionic?
<uvos>
no d4
<Wizzup>
and then wher do you read the clock?
<uvos>
i was figureing out why mainline sgx was underperforming
<uvos>
anyhow on d3 this might be harder
<uvos>
since d4 can run android 7, which is still essentally mostly compatable with modern android applications
<uvos>
2.3 is decidedly not
<uvos>
so you would have to find something compiled agains the period correct sdk for it to run
<Wizzup>
can we just clock it way lower in the dts and see if that is stable?
<Wizzup>
I mean honestly I agree with your earlier statement that a more minimal dts with (maybe) a lot of things set to 'safe' would be a good way to test stability
<Wizzup>
like maybe even a dts that just doesn't exceed 300Mhz and has some much lower sgx clock even
pere has joined #maemo-leste
<uvos>
we set the opp low already
<uvos>
this dident help
<uvos>
so i dont see why doing it in the dts would do anything
<Wizzup>
I don't remember doing this, but seems like your memory is better
<uvos>
well i did it myself
<uvos>
that was like first thing
<Wizzup>
on droid3? ok
<uvos>
yes
<uvos>
anyhow yes minimal dts would be good
<Wizzup>
I'm wondering if there is just some things we've missed/forgot, like not setting freq to 1000Mhz before kexec
<uvos>
theres not mutch to forget really
<uvos>
since its just ctrl-c ctrl-v the bionic
<uvos>
the bionic (in difference to d4) dosent seam to care about the opp at boot either it seams
<uvos>
since it was apaeranlty always missing
<Wizzup>
I mean clearly there is a problem since it is not ctrl-c ctrl-v :D
<Wizzup>
I understand it is for the most part
<Wizzup>
can't we read the allowed clocks from the kernel for the device, or the devtree for the device?
<Wizzup>
for say sgx
<Wizzup>
I just feel like maybe we took a shortcut too many or something
<Wizzup>
okay, so to recap, I will get 6.6 on it just for the heck of it and because it is easier to then make changes
<Wizzup>
does sgx clock show up in cpcap regs?
<Wizzup>
or I guess in some regulator like you said
<Wizzup>
hrm this xt912 lets me flash 4.1.2 fine but I am having trouble flashing older fw
<Wizzup>
uvos: ok so I'm looking at razr dss regs atm because I'm a little frustrated with the d3 stuff (might try again tomorrow), and in leste I can now read the regs, but on android rwmem won't work:
<Wizzup>
root@cdma_spyder:/data/maemo # ./rwmem
<Wizzup>
FATAL: kernel too old
<Wizzup>
Aborted
<Wizzup>
I guess maybe busybox devmem can be used
<Wizzup>
nope, that gives bus errors even with the screen on