<LjL>
hi people, new here, haven't used my N900 in a long time... is Leste in a state where it would be relatively usable with no major missing things on the N900? if not could i dual-boot it easily with classic Maemo? is the N900 even being targeted as viable anymore?
xmn has quit [Quit: ZZZzzz…]
* enyc
meows LjL
* LjL
meows back
* joerg
chases 5 dozen white mice towards enyc and LjL
LjL has quit [Quit: Scappò via con la paura di arrugginire. Il giornale di ieri lo dà morto arrugginito. I becchini ne raccolgono spesso fra la gente che si lascia piovere addosso.]
LjL has joined #maemo-leste
<tmlind>
freemangordon: so looks like we're missing the power domain handling for omap3, here's an initial patch for it muru.com/linux/n900/omap3-prm-gfx.patch
<tmlind>
that get's modprobe of the pvr module working with no reverts for me, but there are other pvr kernel module related problems remaining
<tmlind>
it seems that the pvr module does internal powerdown for omap3/sgx530_125 and behaves somehow in a different way compared to omap4
<tmlind>
or something like that, need to figure that out when i get a chance
<tmlind>
so pvrsrvinit will still fail for omap3 after the power domain patch
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
<tmlind>
looks like somehow on omap3 PVRSRVSetDevicePowerStateKM fails to properly power up the device, the module is clocked as i can read the regs when enabling the module via sysfs manually
<tmlind>
oh well need to continue tonight
<freemangordon>
tmlind: hmm, ok, maybe it counts on something being powered-up automatically.
mardy has joined #maemo-leste
Twig has joined #maemo-leste
pere has quit [Ping timeout: 268 seconds]
joerg has quit [*.net *.split]
LjL has quit [*.net *.split]
freemangordon has quit [*.net *.split]
peetah has quit [*.net *.split]
Daanct12 has quit [*.net *.split]
tmlind has quit [*.net *.split]
pere has joined #maemo-leste
joerg has joined #maemo-leste
freemangordon has joined #maemo-leste
LjL has joined #maemo-leste
Daanct12 has joined #maemo-leste
peetah has joined #maemo-leste
tmlind has joined #maemo-leste
freemangordon has quit [Quit: Leaving.]
freemangordon has joined #maemo-leste
<freemangordon>
tmlind: yeah, with this patch pvrsrvctl --init --no-module hangs the device
<uvos>
LjL: "is Leste in a state where it would be relatively usable with no major missing things on the N900?" no absoulty not there are no working phone calls on n900 and lots of other stuff is also still missing
<uvos>
LjL: "is the N900 even being targeted as viable anymore?" yes it is, but our other 3 main supported devices are in a better state atm (particularly power managment is totaly broken on n900, there are sever bugs with the pvr driver and there is no routing for the n900s complex audio setup), but there is promesing work goning on right now on all of those problems so n900 should hopefully catch up soon
<uvos>
also you need to temper your expectations with n900 wrt performance, its not going to run modern desktop applications like browsers anymore due to the limited ram.
zhxt has joined #maemo-leste
<Wizzup>
LjL: dual-booting is easy though
<Wizzup>
I think once we get working phone call audio (+ audo integration) and sms I will personally switch though
<Wizzup>
dogfood all the way :)
_inky has quit [Ping timeout: 265 seconds]
<uvos>
btw Wizzup is there a way to force the n900 to allways show the uboot menu
* sicelo
notes that reminding people that the N900 is underpowered for browsers is such a common theme here ...
<Wizzup>
hehe
<parazyd>
uvos, Wizzup: You need write permissions on the repo?
<Wizzup>
no, the question is how to add uvos to jenkins for that repo
<Wizzup>
(profilesx)
<parazyd>
We just add it to the bot's ACL
<Wizzup>
oh, so not in jenkins itself?
<Wizzup>
either way I don't know where it's stored
<parazyd>
Done
<parazyd>
Wizzup: Will pm
<parazyd>
We have a separation here
<parazyd>
I see uvos prefers IRC, so I added him to the IRC ACL
<parazyd>
Otherwise there's also the option to add to Jenkins' ACL, but then one has to use the Web UI to trigger builds.
<uvos>
"I see uvos prefers IRC, so I added him to the IRC ACL" heh thats a self fufilling Prophecy you only gave me IRC permissions to my other packages, ofc i use irc :P
<uvos>
not that i mind
<Wizzup>
I think that's another way of saying "the jenkins web ui is cumbersome to use" :)
<Wizzup>
also to configure accounts
<uvos>
yeah its fine :)
pere has quit [Ping timeout: 265 seconds]
<parazyd>
Yeah it sucks
<parazyd>
We also have python cli scripts to interface with it internally
<uvos>
not sure why those are particulary important
<uvos>
but ok
<uvos>
would also want to change this to not depend on /home/user
<freemangordon>
because - OS is intended to be used on mobile devices, being able to restore to factory setting and to clear user data was there before even flashlight capability
<uvos>
anyhow i renamed the cp applet
<uvos>
parazyd: would you move profilesx to core and add it to the metapackages at your leisure
<uvos>
as it looks like its going to be our default profile applet for a while
inky_ has joined #maemo-leste
_inky has quit [Ping timeout: 250 seconds]
<freemangordon>
tmlind: who controls CM_xxx_SGX and PM_xxx_SGX regs and are we sure those have correct values? how could I verify?
<freemangordon>
I think I maybe should edit the driver to call EnableSGXClocks() on exit from probe and then verify if allregisters look ok
<freemangordon>
shall I verify other registers but PRCM?
<tmlind>
freemangordon: the clocks should be ok, but the rate may need to be configured. the clocks are claimed by drivers/bus/ti-sysc.c and managed by runtime pm
<tmlind>
the clock rate and parent clock can be configured with assigned-clock-parents etc in the dts like we did for droid4
<freemangordon>
but wrong rate should not lead to bus error but bad performance, no?
<tmlind>
too high clock rate would cause crashes for sure
<freemangordon>
tmlind: also, I checked the rate (when it was working) and it was ok, 110666 or somesuch
<freemangordon>
I compared with fremantle
<tmlind>
ok
<tmlind>
what is the source clock supposed to be
<freemangordon>
the clock parent was same in either cases
<freemangordon>
not sure, but I cam check
<freemangordon>
*can
<freemangordon>
shall I?
<tmlind>
sure makes sense, the clock rate can be found in /sys/kernel/debug/clk or something like that
<freemangordon>
yeah
<freemangordon>
that's where I look
<freemangordon>
:)
<tmlind>
ok, then checking the fremantle source clock can be done by dumping regs
<freemangordon>
I am on kernel-power
<freemangordon>
which exports clock tree in /sys/kernel/debug
<freemangordon>
that's why I said that I compared the clocks and they are same
<freemangordon>
tmlind: on fremantle there is no core_d3_ck
<freemangordon>
or maybe it is just not important, as soon as the rate is fine
<freemangordon>
also,
<freemangordon>
if we do not play with PM, it works fine
<tmlind>
yeah weird
<tmlind>
the same clocks are enabled even without pm so those should be fine then
<uvos>
just check the clock resigers after the hang over jtag?
<uvos>
the pins on the back of the n900 have jtag right?
<freemangordon>
maybe, but I dont; have the equipment to do that
<tmlind>
well i force enabled sgx module via /sys and can read the regs just fine before prvsrvinit
<uvos>
sure but the dirver might be messing with the clock regs in an unexpected way after prvsrvinit
<freemangordon>
pvrsvrinit does the same as pvrsvrctl?
<uvos>
i have no idea what the point of pvrsrv is even
<uvos>
freemangordon: yes
<uvos>
it proububly uploads fw?
<tmlind>
it should not even know about the clock regs.. but maybe there's some pvr internal gate or multiplier
<freemangordon>
uvos: the driver does not touch clock regs, besides calling pm_xxx functions
<uvos>
tmlind: it knows for sure
<freemangordon>
uvos: not really
<uvos>
i know the userspace knows the clock and decides behavior based on it
<freemangordon>
clocks are controlled by linux
<uvos>
no here me out
<uvos>
on ddk1.9 and the android blobs
<tmlind>
uvos: i don't think we have the pvr freq scaling enabled in the driver
<freemangordon>
even of remantle, where you have freq scaling, it is done by the driver
<freemangordon>
it gathers performance data based on load that's reported by uKernel
<uvos>
so on d4 on the older blobs (icl android) there is wierd behavior where the driver changes the frequency based on load and the display refeshing
<freemangordon>
and decides to change opp
<uvos>
but only if its set to exactly 307Mhz
<uvos>
if you set it to something else in linux
<uvos>
all this activity stops
<uvos>
this code has to be _somewhere_
<uvos>
i faild to find it
<freemangordon>
yes, in the driver :)
<uvos>
ok
<uvos>
then i missed it while looking
<tmlind>
i guess it must be there buried into the 60k lines of ifdefs..
<freemangordon>
yeah
<freemangordon>
I can show it where it is in fremantle driver
<freemangordon>
it is not that different to what we use though
<tmlind>
well the clock rate we can read in a loop from the regs while prvsrvinit is running
<uvos>
well at the time i was concerned that pvrsrv uploads some fw and that sgx dose clock managment on device
<uvos>
like modern desktop gpus
<tmlind>
the driver certainly has all kinds of ioctl controls in place
<freemangordon>
no, sgx does what it has been told, at least for sgx530, AFAIK
<tmlind>
would not be surprised if there's write to any reg ioctl there too
<freemangordon>
could be
<freemangordon>
but still the oops we get is a simple "resume from suspend" path
<freemangordon>
which behaves in exactly the same way with SUPPORT_ACTIVE_POWER_MANAGEMENT disabled, besides enabling/disabling clocks, IIUC
<freemangordon>
tmlind: is it possible that there is some period after clocks being enabled but the PLL is still not stable?
<freemangordon>
or some other timeout needed to stabilize the clocks?
<tmlind>
sure it takes a while to lock, but the pll should be enabled and we just mult/div/gate it
<freemangordon>
yeah
dgamer69 has joined #maemo-leste
<freemangordon>
what about those prcm regs? reset one?
<freemangordon>
is it possible that for some reason SGX is hold in reset?
<freemangordon>
and how to verify?
<uvos>
irrc there is a reset reg for sgx in omap4
<uvos>
so just look at the omap3 datasheet and read it?
<freemangordon>
I think it is the same for omap3, reading through TRM as we speeck to find it
<freemangordon>
*speak
<freemangordon>
hmm, what about PM_PWSTCTRL_SGX
<freemangordon>
0x4830 6BE0 that is
_inky has joined #maemo-leste
<tmlind>
i don't think there's a rstctrl for sgx on omap3, if it was in reset no register access at all would work
<tmlind>
freemangordon: the patch i posted this morning manages PM_PWSTCTRL_SGX
dgamer69 has left #maemo-leste [#maemo-leste]
<tmlind>
hmm i guess i should check the 34xx trm for that reg though, that's from the dm3730 trm
<freemangordon>
I think it is the same
<freemangordon>
from 3430: PM_PWSTCTRL_SGX 0x4830 6BE0
<freemangordon>
PM_PWSTST_SGX 0x4830 6BE4
<tmlind>
looks like the available modules are a bit different
<tmlind>
sorry available modes i mean
<freemangordon>
POWERSTATE bits?
<tmlind>
yeah but we don't care about the inactive mode
<freemangordon>
hmm, in TRM I look at INACTIVE is defined for PM_PWSTST_SGX
<freemangordon>
the readonly POWERSTATEST
<freemangordon>
so I am not sure what you mean in terms of PM_PWSTCTRL_SGX/POWERSTATE
<tmlind>
oh right, i was looking at the wrong reg..
<tmlind>
no statechange bit there it seems
<freemangordon>
hmm, what do you mean?
<freemangordon>
you have INTRANSITION
<freemangordon>
hmm, seems we have /sys/kernel/debug/pm_genpd/prm_gfx with current_state 'off-0'
<tmlind>
some prm have bit 4 for statechange, i doubt that matters in this case as the regs are readable
<tmlind>
/sys/kernel/debug/pm_genpd/prm_gfx
<freemangordon>
does sysc (or whoever controls prcm state) waits for INTRANSITION to become zero?
<tmlind>
yeah the prm driver does
<tmlind>
might be worth checking the /sys/kernel/debug/pm_genpd/prm_gfx state that it shows the real reg value and not the idle state value..
<freemangordon>
usingdevmem?
<freemangordon>
by using devmem?
<tmlind>
yeah
<freemangordon>
I have to find it first :)
<freemangordon>
ok, not now, but tomorrow I will do a couple of experiments, unless you provide a fix by then :)
<freemangordon>
like, recording the reg values with and without SUPPORT_ACTIVE_POWER_MANAGEMENT
<freemangordon>
besides PRCM regs, what else shall I look at?
<tmlind>
checking the values without SUPPORT_ACTIVE_POWER_MANAGEMENT seems like a good idea
<freemangordon>
ok
<tmlind>
the other things to look for are silly typos :)
<freemangordon>
where? :)
<freemangordon>
in the kernel source? :p
<tmlind>
dts, the patch i posted this morning, pvr changes affecting pm_runtime..
<freemangordon>
hmm, pvrsrvctl *DID NOT* crash this time
<freemangordon>
with your patch that is
<tmlind>
weird
<freemangordon>
however, kmscube did
<freemangordon>
yes
<freemangordon>
but, I disabled off mode
<tmlind>
that sounds still like too high clock rate..
<freemangordon>
this is controlled by tds, no?
<freemangordon>
*dts
<tmlind>
maybe we have some cpuidle race with the PM_PWSTCTRL_SGX register access
<tmlind>
yeah the rate seems just fine though
<freemangordon>
yeah, rate seems fine
<tmlind>
how about add some load to keep system from idling? like dd if=/dev/zero of=/dev/null &
<freemangordon>
also, keep in mind we have issues where maybe half of the time device cannot boot
<freemangordon>
ok, I can try that
<freemangordon>
not now though, have to run
<freemangordon>
also, I plan to weak the driver to try to leave the cloaks running after probe has finished
<freemangordon>
to see what is the actual state
<freemangordon>
anyway, ttyl
<tmlind>
ok ttyl
mardy has quit [Quit: WeeChat 2.8]
<tmlind>
freemangordon: so if omap3 or 34xx sgx ocp registers are broken like they seem based on what i noticed, maybe we should not enable SYS_USING_INTERRUPTS as that enables SGX_OCP_REGS_ENABLED, and seems SUPPORT_ACTIVE_POWER_MANAGEMENT depends on these..
<tmlind>
there's also SGX_OCP_NO_INT_BYPASS option that might be for 36xx if the ocp reg got fixed or something
<tmlind>
anyways, ttyl
<freemangordon>
SYS_USING_INTERRUPTS interrupts alone (without SUPPORT_ACTIVE_POWER_MANAGEMENT) works perfectly fine
<freemangordon>
glmark score I posted yesterday was with SYS_USING_INTERRUPTS enabled
<freemangordon>
tmlind: ^^^
<tmlind>
ok, i guess they are also increasing in proc then..
<freemangordon>
can't parse, sorry, could you rephrase
<freemangordon>
you mean interrupt counter?
<tmlind>
uvos: adding SGX_OCP_NO_INT_BYPASS might enable some runtime gating as it tinkers with the sgx sysconfig reg
<tmlind>
freemangordon: yeah so i'd assume fremantle has the sgx interrupts increasing? :)
<freemangordon>
yes, so is 1.17 with SYS_USING_INTERRUPTS enabled