<ashley>
dropping off a quick suggestions regarding the Leste wiki in case if there's interest - I've a MediaWiki 1.35 compatible version of the wiki.maemo.org skin, meant (obviously ;-) for that wiki once I figure out how to migrate it to a supported version of MW (tips, tricks, etc. are all welcome; I know my way around MW but the maemo.org infra scares the hell out of me...); if y'all wanna use it on the Leste wiki for a more consistent-ish look&feel or create
<ashley>
a fork based on it, it's available at https://git.legoktm.com/ashley/mediawiki-skins-Maemo ; installation is as simple as git clone'ing the folder as "Maemo" into the wiki's skins/ folder and adding wfLoadSkin( 'Maemo' ); to the wiki's LocalSettings.php file (which is usually located in the wiki root but maaaaaay be elsewhere depending on how MW was installed? I've no clue how the packaged versions work)
<ashley>
s/suggestions/suggestion/g
<Wizzup>
that would be pretty cool!
<Wizzup>
parazyd mostly manages that infra, I think, but it would be pretty cool to try!
<ashley>
:D awesome! please feel free to poke me about MW-related things, happy to help out :)
<Wizzup>
*nod*
<Wizzup>
one thing to check will be to see how it works with the status thingies we have for the devices
<Wizzup>
in general I think we're looking for someone to give the wiki a bit more love, it feels chaotic to me
<Wizzup>
but that's probably I am chaotic so it's a reflection of some of my contributions
<Wizzup>
:P
inky_ has joined #maemo-leste
<ashley>
heh, it happens ;P but what's insanely cool is that we have cool people like yourself still working on the great mobile OS of all time! I mean, Fremantle was released *quite* a while ago and the Nokia N900 is somewhat ancient in terms of computing devices and especially mobile phones, yet it has outlived - and no doubt will continue to outlive!- many an Android device
<Wizzup>
yup, it's quite fun. :-)
* Wizzup
zzz
Pali has quit [Ping timeout: 250 seconds]
_whitelogger has joined #maemo-leste
Wikiwide has quit [Read error: Connection reset by peer]
Wikiwide__ has joined #maemo-leste
Wikiwide__ is now known as Wikiwide_
zhxt has joined #maemo-leste
zhxt has quit [Ping timeout: 250 seconds]
zhxt has joined #maemo-leste
cockroach has quit [Quit: leaving]
sunshavi has quit [Ping timeout: 256 seconds]
<mighty17[m]>
<sicelo> "actually i want to do them..." <- Yeah but we'd have to package tmlind's fork, openpvrsgx releases rc kernels only :(
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
xmn has quit [Ping timeout: 256 seconds]
<sicelo>
mighty17[m]: as far as pmos maintainership goes, I'll focus my energies on just mainline kernel (no sgx)
mardy has joined #maemo-leste
<mighty17[m]>
<sicelo> "mighty17: as far as pmos..." <- so there is probably no need for a "same kernel", we all can just use mainline and add the dts as a patch
<sicelo>
Yes, that's mostly what I meant. What days patch btw?
<sicelo>
s/days/DTS/
<mighty17[m]>
oh right, n900 already in mainline 😅
<sicelo>
Yes, it's been there ever since DTS was a thing. And the DTS shows its age by now, e.g. our RGB led definitions fell short of current documentation. Anyway, we're catching up
<mighty17[m]>
yeah so either they go to mainline or we add it as a patch in pmos
<sicelo>
"they" is? :-)
<mighty17[m]>
they as in the updated dts for n90
<sicelo>
LEDs? fixmaking their way to mainline already. Not much point holding any private patches for anything omap (except sgx, naturally)
zhxt has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
_inky has quit [Ping timeout: 250 seconds]
inky_ has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
Pali has joined #maemo-leste
alex1216 has joined #maemo-leste
Wikiwide_ has quit [Ping timeout: 256 seconds]
alex1216 has quit [Ping timeout: 240 seconds]
alex1216 has joined #maemo-leste
alex1216 has quit [Read error: Connection reset by peer]
<Wizzup>
looks like the thermal disable might fix the oops in sleep mode, although it looks like there are more issues to resolve when many drivers/modules are loaded
<Wizzup>
(booted to recovery mode, with a ton of modules loaded)
alex1216 has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: neat
sunshavi has joined #maemo-leste
<uvos>
Wizzup: i really hope we can make the n900 enter off at some point in the full system even with large entry cost/errata
<Wizzup>
right
<Wizzup>
it doesn't hit RET yet in our full system
<Wizzup>
but we'll get there
<Wizzup>
at least it looks like with Tony's thermal suggestion and ssi_protocol not loaded, it doesn't crash
elastic_1 has joined #maemo-leste
elastic_dog has quit [Quit: elastic_dog]
<Wizzup>
with wlan0 off and modem not loaded I am no longer seeing any blockers though
<uvos>
great
<uvos>
in emergency mode
<Wizzup>
no, system
<Wizzup>
with X and stuff
<Wizzup>
no RET increase though
<Wizzup>
I mean that is with some modules disabled, btw
<uvos>
right i ment in emergency mode the additional timers blocking off in the kernel modules
<Wizzup>
in particular gpio_keys needs work in power saving mode
<Wizzup>
let me clarify
<Wizzup>
RET:271 was in emergency mode, the one you added, with just nokia modem removed
<uvos>
ok and in system mode with some modules unloaded nothings blocking
<Wizzup>
my statement now about wlan off and modem not loaded and not seeing any blockers is with X and h-d etc loaded
<Wizzup>
yes
<uvos>
but the high cost is
<Wizzup>
likely
<uvos>
ok
<dsc_>
`Tony's Thermal Suggestion` sounds like a hip cocktail bar in the center of town
<uvos>
:D
<Wizzup>
dsc_: we'll stash that with the Microwave Bug
<Wizzup>
omap-dma-engine seems to cause most of the wakeups now it seems
<Wizzup>
I think we'll have to pull out ftrace to make sense of this
<uvos>
that could be any user tho
<uvos>
it has lots
<Wizzup>
yeah
<Wizzup>
uvos: so I think the d3 idles really well, but it's reporting in upower is way off because of the battery stuff
<Wizzup>
I guess that's mostly good news
<uvos>
yeah possible
<Wizzup>
I mean it left it on overnight with wifi on and the capacity looks like it barely decreased :)
<uvos>
maybe it also lacks the unkown power bug d4 has, like bionic
alex1216 has quit [Ping timeout: 240 seconds]
alex1216 has joined #maemo-leste
<Wizzup>
mhm
<tmlind>
Wizzup: good to hear it worked, i'm guessing it's the bandgap that needs to be disabled
<tmlind>
Wizzup: there must be some other thermal sensor in use on n900, maybe on one of the pmics if no separate lm75 or similar
<Wizzup>
ok, I'll try that momentarily (bandgap)
<tmlind>
uvos: so is the android power consumption also worse on d4 compared to bionic?
<tmlind>
uvos: maybe the difference relates to the power supply configuration and we need to somehow idle the power supplies on d4?
<uvos>
tmlind: good question
<uvos>
the problem with bionic is atm you cant have android also installed
<tmlind>
oh right
<uvos>
i could fix that
<uvos>
i have to work on clownboot a bit for d3 soon
<tmlind>
ok
<uvos>
tmlind: yeah maybe
<uvos>
tmlind: or its the sensors
<tmlind>
uvos: yeah maybe
<uvos>
tmlind: i have not found the time to test both with no sensors yet
<tmlind>
uvos: me neither..
<Wizzup>
time, the holy grail
<uvos>
tmlind: dont worry about this (the power problem) ill take it ;)
<tmlind>
uvos: all yours :)
<Wizzup>
uvos: OFF mode on omap4 when? :)
<uvos>
heh
<uvos>
not _that_ problem :P
<tmlind>
Wizzup: i'm guessing your pm bisecting will bring down also d4 idle consumption quite a bit
<Wizzup>
I thought so too, but I don't think it made that much of a difference besides the compact patch
xmn has joined #maemo-leste
alex1216 has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 250 seconds]
alex1216 has joined #maemo-leste
<Wizzup>
tmlind: so if the bandgap works, shall I submit a patch and mark it as 'fixes' for auto enable off mode patch?
<Wizzup>
I'm pretty sure a lot more will not be happy with omap mode enabled by default (ssi_protocol being one of them, gpio_keys another), but we can work on fixing those
<Wizzup>
and we can just carry a revert for now on our tree
<tmlind>
Wizzup: sure yeah that's a fix, but the fix must also explain what is used on n900 for thermal shutdown if bandgap is not in use
<Wizzup>
ok, so some research might be necessary
<Wizzup>
now where do I find a fremantle phone to analyse ... *pulls out phone from pocket*
<tmlind>
yeah sorry looks like i no longer remember what was used on n900, too many devices
<Wizzup>
:)
<tmlind>
Wizzup: looks like there's twl adc <&twl_madc 0> in the dts configured for battery temperature, not sure if that can trigger a thermal shutdown though, maybe there is also something hardware based
<Wizzup>
ok
cockroach has joined #maemo-leste
alex1216 has quit [Ping timeout: 240 seconds]
<Wizzup>
so there is this with all three the nodes from my email disabled:
<Wizzup>
tmlind: I don't know that, is that something in the hw or in the driver/dts?
* Wizzup
googles
<tmlind>
Wizzup: it would be in the bq2700 docs with a line wired for shutdown
<Wizzup>
ok
<Wizzup>
Pali or freemangordon might also know
<tmlind>
so what's the fremantle /sys/devices/virtual/thermal/thermal_zone0/temp value?
<tmlind>
maybe that is really using the bandgap sensor with some better code than what the mainline kernel has?
<Pali>
tmlind: Hi! What is the issue?
<tmlind>
Pali
<tmlind>
hi
<sicelo>
Nothing has *thermal* in /sys on Fremantle
<tmlind>
so we want to disable n900 mainline kernel bandgap sensor as it seems buggy on omap3 and needs to be polled for a long time to get any decent values, it ruins the pm
<Wizzup>
fremantle has /sys/devices/platform/omap34xx_temp/temp1_input{._raw}
alex1216 has quit [Client Quit]
_inky has quit [Ping timeout: 265 seconds]
<sicelo>
And rx51-battery/temp, and bq27200-0/temp too
<Pali>
IIRC fremantle driver omap34xx_temp is what is thermal zone in mainline kernel, and this show temperature reported by omap3 soc
<Pali>
bq27200 temp is what reports bq27200 battery chip
<Pali>
and rx51-battery/temp is temperature reported by battery itself via dedicated (3rd?) pin connected to madc
<Pali>
madc itself reports raw values which are not converted to corrects units; rx51-battery should do it correctly
<Pali>
and about omap34xx_temp, I remember that pavelm was hacking this driver to provide better values... I'm not sure if all patches are in upstream kernel.
<Wizzup>
with /sys/devices/virtual/thermal/thermal_zone0/temp still reporting the correct values, then maybe fremantle does not use bandgap?
<tmlind>
Pali: for omap3 the bandgap driver in mainline pols the registers for quite a while each time to get a sane value :(
<Pali>
"Just be careful when you try to make thermal policy like decisions based on this sensor."
<Pali>
"I guess we won't do that, certainly not anytime soon."
<tmlind>
right, that sounds not reliable
<tmlind>
Wizzup: care to dump out the bandgap register value on fremantle when not reading the temperature? maybe it's configured for thermal shutdown alert only and the value is only read via sysfs if ever?
<Wizzup>
I don't know how to read that register :(
<tmlind>
you can use rwmem or busybox devmem or similar
<tmlind>
the regs to read are:
<tmlind>
0x48004a08 CM_FCLKEN3_CORE
<tmlind>
this would tell if the bandgap device is clocked at all
<Pali>
beware that kernel has CONFIG_* options for protecting access to /dev/mem which makes access to registers from userspace processes not posible
<tmlind>
uh
<Pali>
but I guess that fremantle kernel is old enough when these CONFIG_* options were not exist or were turned off
<Pali>
when debugging I'm dumping registers from U-Boot, command is: md <addr> 1
<tmlind>
yeh but that's not the kernel value though..
<tmlind>
the other register we want to read from fremantle is the bandgap device register that should be 0x48002524
<tmlind>
yup that's the CONTROL_TEMP_SENSOR register
<tmlind>
maybe somebody can build a custom fremantle kernel with two printks added? :)
<tmlind>
the values at late_initcall time should do
<Wizzup>
I can try later today with rwmem and/or devmem in case it works
<tmlind>
ok
<tmlind>
also, for 4430 i had to change the bandgap to use continuous mode, maybe the same also works for omap34xx and omap36xx.. see commit 735c35352aa6 ("thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430")
<tmlind>
but first we really should check the fremantle configured values for the registers above
<tmlind>
anyways, bbl
<Wizzup>
ttyl
linmob has quit [Ping timeout: 250 seconds]
linmob has joined #maemo-leste
<uvos>
so somethign is wrong with the way we stop glx from working, it breaks sdl2
<uvos>
so sdl2 tries glx and detects that it works on pvr and advertises opengl and then errors out when it fails
<uvos>
otherwise it would try egl next
<Wizzup>
hm
<uvos>
i can disable opengl
<uvos>
and then it dosent try glx and goes to egl
<uvos>
and everything works (supertux2 with 30 fps :P)
<uvos>
interestingly
<uvos>
supertux2 with gles2 also segfaults on exit with:
<uvos>
PVR:(Error): UCH_CodeHeapDestroy: In heap 0x8f74a0 there are still at least 25 memory leaks [0, ]
<uvos>
PVR:(Error): PVRSRVDestroyDeviceMemContext: allocations still exist in the memory context to be destroyed [0, ]
<uvos>
PVR:(Error): Likely Cause: client drivers not freeing allocations before destroying devmemcontext [0, ].
<uvos>
dosent look like something the mainline kernel would print
<uvos>
ok it just hanged again
<uvos>
and yes this is after reset
<uvos>
looks like its mbmloader or mbm that prints this
<uvos>
anyhow looks like stx2 is very good at making it hang fast
<uvos>
<10 minutes
<uvos>
but im not sure how to get any information from the hang
<uvos>
tmlind: ^^^ ideas>
<uvos>
?
_inky has quit [Ping timeout: 252 seconds]
<Wizzup>
does it happen when droid-pm doesn't run?
<uvos>
no
<Wizzup>
ashley: re: the theme, I am not sure if it makes sense to load from static.maemo.org, should we self-host maybe?
<uvos>
for the reccord, i think the wiki.maemo.org is ugly - not that it really matters what it looks like to me.
<Wizzup>
uvos: we can mod the theme some too
<Wizzup>
I think it is nice to have some custom theme
<bencoh>
+1
<uvos>
Wizzup: i agree
<uvos>
Wizzup: also ugly is overstating it a bit maybe i think the default looks nicer
<uvos>
Wizzup: maybe it should integrate with the github.io page (or vice versa)
<tmlind>
uvos: yeah that's something from the bootloader, the device should continue booting after that.. but i've noticed enabling pm or modem or sgx in the kernel makes the boot not continue somehow
<bencoh>
Wizzup: congratz (OFF mode on n900)
<Wizzup>
bencoh: there's more work to do tbh, but at least we can hit it in some special cases
<bencoh>
what's missing?
<bencoh>
(kernel-wise)
<uvos>
main problem is that off mode (and ret) on omap3 has a massive entry cost so events have to be really low, there still seam to be kernel events that fire too often
<uvos>
and userspace will probubly also be a problem
<uvos>
the d4 can idle some with 100hz of timers fiering the n900 cant
<bencoh>
what kind of kernel events do we get, apart from external events (proximity / modem) ?
<uvos>
timers
<bencoh>
with blank screen, sgx/touchscreen/lcd should be idling right?
<uvos>
yeah
<bencoh>
timers for what?
<uvos>
we dont know
<bencoh>
ah, alright
<uvos>
the high entry cost on n900 is probubly a blessing is diguise tho
<uvos>
it makes all the little problems that exist and do add up very obvious
<bencoh>
haha, yeah
<bencoh>
well, you could just change the the idle latency to some high value anyway to debug :)
<tmlind>
uvos: maybe try your stx2 test with lower sgx frequency
<Wizzup>
anyway, it's available under user preferences
_inky has quit [Read error: Connection reset by peer]
<bencoh>
user preferences allow changing SGX freq? that's ... interesting ... original even :)
<Wizzup>
bencoh: no, skin/theme
<bencoh>
ah
<bencoh>
nevermind :]
inky has quit [Ping timeout: 256 seconds]
<ashley>
Wizzup: re:Maemo.org wiki skin, indeed, that part of the codebase is untested :D because obviously "localhost" is not "maemo.org" and so far I've tested it only on localhost but it works nicely there ;)
<Wizzup>
ashley: I added 'if false'
<ashley>
:D
<Wizzup>
ashley: it's avail as a theme atm on leste.maemo.org
<Wizzup>
if you have an account, log in and go to preferences
<Wizzup>
you can select 'maemo' there
<ashley>
neat, cheers! (I don't, but I'll make one soon ;)
<Wizzup>
I think the double nav bars are not good UX unless we do it everywhere (maemo-leste.github.io, pkgweb, maedevu.maemo.org)
<Wizzup>
but I tried to make it kinda work
<ashley>
(also I'd copy-paste my mandatory "skin != theme != template" rant if I had it readily available, but suffice to say that in a MediaWiki context they all mean different things :P alas, themes are still an extension -- https://www.mediawiki.org/wiki/Extension:Theme -- as there wasn't enough WMF buy-in to have it added to the core MW software...)
<Wizzup>
ah, ok, I should say skin then
<ashley>
*nod* :) mind you, people mix them up all the time and frankly it's quite reasonable because different software has different names for the same thing ("look and feel of the software/website") and the concept of themes in MediaWiki isn't that well-known (despite that the original concept was launched by a commercial wiki hosting company some ~15+ years ago and the extension has been around for like 12-14 years, too!)
inky has joined #maemo-leste
_inky has joined #maemo-leste
_inky has quit [Max SendQ exceeded]
_inky has joined #maemo-leste
_inky has quit [Read error: Connection reset by peer]
pere has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
akossh has joined #maemo-leste
<uvos>
tmlind: running it at half the normal rate
<uvos>
seams to have prolonged the time untill it hangs
<uvos>
but not made it not hang
<uvos>
its also very slow
uvos has quit [Read error: Connection reset by peer]
uvos__ has joined #maemo-leste
mardy has quit [Quit: WeeChat 2.8]
pere has joined #maemo-leste
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 268 seconds]
<Wizzup>
uvos__: I think the d4 idles better with the 5.15 with compact disabled, do you see that too?
<Wizzup>
I regularly see '2 days' in status applet now
<freemangordon>
phew, finally sent updated glib patch
<Wizzup>
:)
akossh has quit [Quit: Leaving.]
<freemangordon>
ugh, we'll have to fork desktop-file-utils :(
xmn has joined #maemo-leste
_inky has quit [Ping timeout: 268 seconds]
<uvos__>
Wizzup: did you rebuild the leste kernel in expieramental without compact?
<uvos__>
othwise no i havent even tried it
<Wizzup>
uvos__: yes
<Wizzup>
I need to build it again for n900 audio and led, but otherwise it's up to date
<uvos__>
then i have noticed nothing
<uvos__>
i have desktop command execution widget display the log of droid4-pm status