System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
Pali has quit [Ping timeout: 240 seconds]
zhxt has joined #maemo-leste
xmn has quit [Remote host closed the connection]
xmn has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
zhxt has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 268 seconds]
<freemangordon> ok, I have a fix for the so-called "HildonPannableArea bug", but I still don't know why it works
<freemangordon> the bug is actually in GtkRange or in gdk_event_request_motions()
<freemangordon> uvos: it is 7871e095605332ce1cfb15e19a06f36b05604d0b that breaks it
<freemangordon> ok, this is the clue:
<freemangordon> (gdb) p range->event_window
<freemangordon> $8 = 0x55555577aa20 [GdkWindow]
<freemangordon> (gdb) p event->window
<freemangordon> $9 = 0x55555577a5a0 [GdkWindow]
alex1216 has joined #maemo-leste
Pali has joined #maemo-leste
Wikiwide_ has quit [Ping timeout: 256 seconds]
<freemangordon> uvos: I think GtkRange is broken even without hildon, but don;t have a way to test it
Wikiwide_ has joined #maemo-leste
_inky has quit [Ping timeout: 240 seconds]
<Wizzup> good find
<freemangordon> Wizzup: do you know how to build gtk or I shall ping parazyd?
<freemangordon> WTF? why my gtk tree differs from leset?
<freemangordon> *leste
<Wizzup> freemangordon: do you mean on the ci?
<Wizzup> I can help you with it
<freemangordon> yes
<freemangordon> but hold on till I find why I cannot push
<freemangordon> ah, I have to force-push
<Wizzup> did you check the changes that you forcep ushed to
<freemangordon> yeah
<Wizzup> ok
<freemangordon> it is one patch only I pushed few days ago (GtkRange one) I updated today
<freemangordon> with the fix
<freemangordon> maybe I should have split that to 2, but is too late already :)
inky_ has joined #maemo-leste
<Wizzup> git branch is it in?
<Wizzup> what branch
<freemangordon> maemo/beowulf-devel
inky has quit [Ping timeout: 245 seconds]
<freemangordon> Wizzup: it is ready
<freemangordon> I guess I shall only build it, as the changes are in debian/patches dir only
<freemangordon> no need to tag or something, no?
<freemangordon> Wizzup: hmm, what about changelog?
<Wizzup> freemangordon: better to do changelog
<Wizzup> maybe just go for 2:2.24.32-4
<freemangordon> not sure, that's why better wait for parazyd :)
<Wizzup> no need to wait
<Wizzup> I know you can do this np
<freemangordon> Wizzup: look at the changelog
<Wizzup> what about it?
<Wizzup> do you want me to do it?
<freemangordon> we have gtk+2.0 (2:2.24.32-3) version twice
<freemangordon> and that's on purpose
<Wizzup> no, we don't
<Wizzup> we have epoch
<Wizzup> or whatever the thing at the start is
<freemangordon> oh, right
<Wizzup> pretty sure the -3 and the end can safely be increased to -4 with no affects on anything else
<Wizzup> effects* even
<freemangordon> not sure, becaue this is upstream version
<freemangordon> not ours
<freemangordon> upstream == debian
<freemangordon> so, I think it is better to add entries to the current last changelog entry and rebuild
<freemangordon> the new version will become 2:2.24.32-3+2m7.10 or something
<freemangordon> current is 2:2.24.32-3+2m7.9
<freemangordon> Wizzup: please do it as you think is right
alex1216 has quit [Quit: WeeChat 2.3]
alex1216 has joined #maemo-leste
<Wizzup> ok
<Wizzup> freemangordon: fine as well, we'll still add a version in the repo I think
<Wizzup> freemangordon: then just issue a buiild
<freemangordon> Wizzup: are you going to do it?
<freemangordon> ah, you already did :)
<freemangordon> hmm, you didn;t do changelog it seems
<freemangordon> Wizzup: how often is -devel pulled in -stable?
<Wizzup> freemangordon: whenever we decide to, and it can be done perpackage
<Wizzup> it's basically a rebuild anyway
<Wizzup> freemangordon: yeah I'd need to force push changelog, can do that though
<freemangordon> why force-push?
<Wizzup> oh, right, doesn't need to be
<freemangordon> just add some lines to the current
<Wizzup> want me to do it?
<freemangordon> no, I will
<freemangordon> do we have an issure for that GtkRange bug?
<freemangordon> *issue
<freemangordon> done
<Wizzup> freemangordon: let me check
<freemangordon> ok
<freemangordon> will close it
<lel> freemangordon closed an issue: https://github.com/maemo-leste/bugtracker/issues/582 (Gtk2 sliders are broken)
inky_ has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
<Wizzup> btw, what do you think we should do wrt bandgap
inky_ has quit [Ping timeout: 240 seconds]
<freemangordon> did you try tmlind's patch?
<Wizzup> freemangordon: I will do that now, but it doesn't relate to the oops and I've heard folks here say that bandgap on the n900 is just broken
<Wizzup> but I guess it would be good to see if it idles even if we don't want to use it
<freemangordon> Wizzup: bandgap being broken in fremantle kernel doesn;t mean the driver shall oops, no?
<freemangordon> and "broken" means you can;t rely on it to measure battery temp
<Wizzup> freemangordon: sure, but what I mean is that iiuc it's not even active on fremantle
<Wizzup> freemangordon: we read the bandgap register and it wasn't active
<freemangordon> which kernel?
<freemangordon> KP or omap1?
<Wizzup> 2.6.28.10-sssu3
<Wizzup> cssu*
<freemangordon> IIRC, it is not active because: 1. it is not kept active continuously and 2. noone reads it
<freemangordon> hmm, I don;t remember if bandgap driver is active in cssu kernel
<Wizzup> there was some talk about it just a few days ago
<Wizzup> I just wanted to check what we're thinking of doing, mostly
<bencoh> freemangordon: I can probably check, if you know how to
<bencoh> I have a kp53 at hand
<freemangordon> me too
<Wizzup> n900 is stable on 5.15 for me now without off mode enabled
<freemangordon> devmem I guess
<bencoh> ah :)
<Wizzup> (the only bug is X11 segfaults)
<Wizzup> off mode enabled though, there's more to fix for sure
<freemangordon> Wizzup: I think it is good to have bandgap on n900, even if we don;t use it
<Wizzup> why?
<freemangordon> the oops we see most-probably is not bandgap's driver fault
<bencoh> oh btw, regarding powertop and measuring wakeup events ... you should use powertop with html output
<Wizzup> bencoh: what does that add?
<freemangordon> also, it is possible that back then (fremantle) bandgap driver was buggy thus nokia gave up on it
<freemangordon> they were saying thumb2 and 720p are impossible too ;)
<bencoh> Wizzup: I don't know understand how/when powertop samples events when using the interactive view
<freemangordon> Wizzup: do you have a link to the discussion?
<Wizzup> no, it was like in the last few days
<Wizzup> maybe just search for pali since he was active then
<Wizzup> (in the logs I mean)
<bencoh> (yeah, thumb2, usb host mode, 720p, overclocking, ...)
<freemangordon> Wizzup: hmm, I took a part in sam discussion
<freemangordon> *some
<freemangordon> did I miss something important?
<freemangordon> Wizzup: re x11 segfault - hopefully starting tomorrow I will have time to do the needed omapdmr patch
<freemangordon> it shouldn't take me more than 3-4 days
<freemangordon> I hope
louipc has joined #maemo-leste
<louipc> wuzzzup
<freemangordon> bencoh: do you know if bandgap is visible in sysfs?
<freemangordon> on KP that is
<bencoh> no idea, got a name to look for?
<freemangordon> me neither, going to try to find it
<bencoh> hm, no /sys/class/thermal
<bencoh> that's a good start
<Wizzup> freemangordon: ok
<bencoh> (year 2009 is waiting on the other line ...)
<freemangordon> :)
<Wizzup> louipc: hi
<louipc> Wizzup: hehe nice name
<Wizzup> had it for 20 years by now I think
<Wizzup> freemangordon: there is also an ocassional segfault on the d4 for me (once every couple days, shall I keep gdb attached to get you a bt)
<louipc> wouldnt it be cool to be able to run random programs from dubious sources and not have it affect your system at all security wise?
<Wizzup> is this some flatpak plug? :p
<louipc> even programs with unknown exploits
<louipc> no im just curious
<bencoh> freemangordon: /sys/class/power_supply/rx51-battery/temp ?
<louipc> if this would be like an 'ultimate' perhaps unattainable goal security-wise
<Wizzup> louipc: I mean there are a lot of things you can do but it'll likely never be entirely 100%
<freemangordon> bencoh: no
<louipc> as far as i know flatpak is fundamentally flawed
<freemangordon> /sys/class/hwmon
<louipc> Wizzup: yea its a constant cat-mouse game
<freemangordon> Wizzup: bandgap seems to be enabled on KP
<Wizzup> did you use the same command to read it?
<louipc> but i'm thinking would this kinda be something that people would like to move towards in the pursuit of security
<freemangordon> it is exported in sysfs
<Wizzup> freemangordon: ok, but is it active and in use
<Wizzup> iirc I used devmem to read the reg and it was 0000
<louipc> lemme know if im goin offtopic
<bencoh> freemangordon: I didn't see much in hwmon
<louipc> im mainly here because there was chat about debian vs android security model
<Wizzup> louipc: not so much, it's just that we probably don't have much to contribute, there's the full-virt approach and there's load of different rbacs and namespaces work, but a kernel exploit will still just kill that
<bencoh> louipc: do you mean, from a pure software point of you?
<freemangordon> /sys/devices/platform/omap34xx_temp
<Wizzup> louipc: if it was up to me the first things we'd integrate would be some rbac (apparmor probably) and later look at perhaps using containers (just namespaces) for some things
<louipc> well android is increasingly integrating hardware as part of the security model too
<Wizzup> freemangordon: want me to check on non-kp?
<freemangordon> /sys/devices/platform/omap34xx_temp # cat temp1_input
<freemangordon> 20
<louipc> with titan m chip, and such
<Wizzup> freemangordon: and you're sure this is bandgap btw?
<freemangordon> Wizzup: I guess it gets enabled only when you read it
<bencoh> freemangordon: nice catch. 20 here as well
<freemangordon> omap34xx_temp?
<bencoh> yeah
<freemangordon> sure it is
<louipc> Wizzup: cool. good to hear that its a consideration
<bencoh> but if we both read 20 ... sounds bogus :>
<Wizzup> freemangordon: that is also present on my kernel
<Wizzup> it reports 13 degrees
<louipc> but i understand the limited dev resources
<buZz> louipc: containers/namespaces is literally what i suggested, apt install firejail
<Wizzup> which is very inaccurate fwiw
<Wizzup> louipc: yeah we want the phone aspect working well first :)
<freemangordon> lemme check int the KP source what omap34xx_temp
<freemangordon> is
<louipc> buZz: right. its not well integrated tho. and firejail has its flaws too
<louipc> android sandboxing is not an 'addon'
<louipc> its part of the system inherently
<buZz> android sandboxing has flaws too
<buZz> you just dont hear about them as often as they're often quickly safeguarded into a TLA's arsenal
<buZz> louipc: its literally a kernel feature
<Wizzup> firejail looks interesting
<louipc> as a 1st class feature they get get flaws will get dwindled down much faster
<Wizzup> buZz: want to lead the efforts to integrating this and apparmor in leste? ;)
<buZz> gladly not :D
<dsc_> louipc: hi :)
<Wizzup> freemangordon: I can confirm that the gtk fix works
<louipc> consider this
<Wizzup> freemangordon: thanks
<louipc> dsc_: wuddup.
<freemangordon> :)
<louipc> dsc_: u maemo dev? :D
<dsc_> I think so?
<dsc_> :P
<louipc> sweet
<buZz> lol @ that website
<buZz> > You can contact me on various platforms, including Reddit, Matrix and Telegram.
<louipc> anyway thanks for your perspective Wizzup.. and buZz too ;)
<buZz> lol
<Wizzup> louipc: if it was up to me I'd want to use the grsec rbac but that's not available anymore unfortunately
<dsc_> louipc: I'm working on the `conversations` app (uses telepathy as backend) for SMS, IRC, XMPP, Telegram
<bencoh> (RIP opensource grsec </3 :'( )
<louipc> theres the kernel self protection project
<bencoh> compared to grsec, it's some kind of joke :(
<louipc> hehe ye
<freemangordon> hmm, I don;t have kp sources around anymore?!? The fuck, I am one of its maintainers :(
<bencoh> freemangordon: :D
<freemangordon> :)
<freemangordon> yeah
<bencoh> louipc: that thing is no longer up to date
<bencoh> well, I think he stopped updating it at least
<louipc> bencoh: just select the correct branch
<bencoh> ah, nevermind
<bencoh> yeah
<bencoh> they only dropped the grsec porting effort I guess then
<louipc> dsc_: nioce mang
<louipc> grsec ppl are a bit nasty i hear
<Wizzup> oh, didn't know folks still maintain it
<Wizzup> that is off topic and no they're not
<louipc> ok sorry :p
<bencoh> :)
<Wizzup> also just my opinion, but yeah
<freemangordon> hmm, I forgot how to clone from vce.maemo.org :(
<freemangordon> *vcs
<bencoh> freemangordon: just clone the address I gave you iirc
<bencoh> if you just want to fetch
<freemangordon> yueah, will try
<bencoh> watch out for the debian patches there
<bencoh> (I freaking hate that thing)
<freemangordon> sure, patches must be applied
<freemangordon> ugh, I need apt-get source actually
<louipc> im running linux-hardened everyday no probs
<bencoh> freemangordon: let's say it's easier yeah
<bencoh> not mandatory though
<freemangordon> it is, as I need .orig source anyway
<bencoh> ?
<freemangordon> however, downloading
<freemangordon> on vcs there is only /debian
<bencoh> hmm, lemme check, I might be wrong
<bencoh> right
<freemangordon> source downloaded and patches applied, lets see
<freemangordon> to me this is bandgap driver https://pastebin.com/QDhZGrmc
<freemangordon> Wizzup: IIUC reading 0x48002524 should return 0000, unless we are in A/d conversion cycle
<freemangordon> hmm, actually it should contain the last measurement in the last 6 bits
<freemangordon> Wizzup: so, if you disable bandgap in CONFIG, device enters OFF mode with no issues?
<Wizzup> freemangordon: so
<Wizzup> I do not know the relation between bandgap and CONFIG_OMAP3_THERMAL
<Wizzup> first of all OMAP3_THERMAL was causing it to basically never enter OFF mode
<Wizzup> secondly I have to disable cpu_thermal and bandgap in dts to not make the device reset in OFF mode with (for example) mmc access
<Wizzup> I do not know if these separate problems interact
* bencoh headscratches
<Wizzup> I do know that afaik we were seeing the oopses/resets also with OMAP3_THERMAL enablec
<Wizzup> (and also with it disabled)
<Wizzup> freemangordon: so 'with no issues' is vague: yes it enters off mode, but there are issues until we also disable cpu_thermal and bandgap in dts
<Wizzup> with those gone, the device idles stable with no modules loaded (others can interact)
<freemangordon> CONFIG_OMAP3_THERMAL should be bandgap driver
<freemangordon> we may have oopses because bandgap driver has fclk
<freemangordon> fclk being disabled when CONTROL.CONTROL_TEMP_SENSOR is being accesses might cause oops we see
<freemangordon> also, it can generate TSHUT signal for thermal shutdown
<freemangordon> that's gpio 127, iiuc
<freemangordon> there is an interesting note on p. 3341 in regards to TSHUT generating an interrupt
zhxt has joined #maemo-leste
zhxt has quit [Ping timeout: 256 seconds]
zhxt has joined #maemo-leste
sunshavi_ has joined #maemo-leste
sunshavi has quit [Ping timeout: 250 seconds]
zhxt has quit [Remote host closed the connection]
inky_ has joined #maemo-leste
<Wizzup> freemangordon: ok @ it being bandgap
zhxt has joined #maemo-leste
_inky has joined #maemo-leste
sunshavi_ has left #maemo-leste [ERC 5.4 (IRC client for GNU Emacs 28.0.90)]
sunshavi_ has joined #maemo-leste
_inky has quit [Ping timeout: 240 seconds]
<freemangordon> Wizzup: shall I first look at that issue before omapdrm?
<freemangordon> this should be pretty easy to identify
<bencoh> I'm about to say something stupid (maybe), but err ... afaiu, no code can run while in OFF mode
<bencoh> ah, nevermind, it's non-relevant
<freemangordon> sure, but IIRC there comes an interrupt while we are in OFF mode
<bencoh> and?
<freemangordon> l3_app_irq
<bencoh> once you try to read a register, you're already not in OFF mode
<bencoh> meaning that if some clock is missing, it should be enabled
<bencoh> (clk_enable(), whatever)
<freemangordon> but, if clocks of that particular IP is not running you get oops
<freemangordon> yes, exactly
<bencoh> (or some restore sequence in the idle exit code)
<bencoh> so you mean entering OFF mode disables that specific clock ?
<bencoh> and it is never restored?
<freemangordon> could be
<bencoh> :)
<freemangordon> because the context seems to be saved/restored
<bencoh> iiuc part of the context is saved/restored by hardware, but I don't know how much of it, btw
<bencoh> OMAP343X_CONTROL_TEMP_SENSOR interesting
<freemangordon> me neither, but now I am looking at thermal driver, to see how is power/clocks controlled
<freemangordon> yes, this is 0x48002524
<bencoh> no I mean, interesting that it is saved/restored as well
<freemangordon> sure, why not?
<freemangordon> why do you think it should not be saved/restored?
<bencoh> oh, I just didn't expect it, that's all. but if it's flushed during idle, it definitely should :)
<bencoh> hm, arm_pm_idle() is the default arm idle handler right?
<freemangordon> no idea
<bencoh> looks like it is
<Wizzup> freemangordon: I'd prefer the omapdrm stuff tbh, we have more off mode stuyff to do anyway
<Wizzup> but whatever you want to work on :p
<bencoh> unrelated, but has the latest droid4 kernel hit -devel?
<Wizzup> yeah
<bencoh> can I install only kernel from -devel, or is something expected to break?
<Wizzup> that will break
<bencoh> alright
<Wizzup> why would you only get kernel?
<bencoh> to toy with powersaving
<Wizzup> you would miss out on the important bits: xf86-video-omap and new sgx userspace
<Wizzup> I use -devel daily and it's stable imho
<bencoh> oh
<bencoh> well, maybe I'll just move to -devel then
<Wizzup> hm.... I need to triple check if new mesa is in -devel
<Wizzup> just a second
<freemangordon> bencoh: could you have a look in TRM and tell me if you understand the difference between CONTCONV = 1 and CONTCONV = 0
<bencoh> I still need to find out what's wrong with usb, so using this device for serious dev stuff is kind of a pain :(
<bencoh> freemangordon: lemme check
<bencoh> freemangordon: omap3 right?
<freemangordon> 7.4.6.2.1 that is
<freemangordon> yes
<Wizzup> bencoh: maybe just add -experimental and not -devel
<bencoh> oh, I dont have the omap3 TRM on that host, fun
<Wizzup> sounds more dangerious but it isn't really
<bencoh> Wizzup: :D
<Wizzup> btw, this would be for droid4 pm stuff right, not n900?
<freemangordon> ah, it seems you should not assert SoC to start another a/d cycle
<freemangordon> Wizzup: BTW, do you still see "eocz timed out waiting high" ?
<bencoh> freemangordon: basically with CONTCONV==1 ADC keeps converting and writing to CONTROL_TEMP_SENSOR
<freemangordon> yeah
<freemangordon> I wonder how do you stop that :)
<freemangordon> anyway
<bencoh> probably by clearing CONTCONV
<freemangordon> mhm
<Wizzup> freemangordon: oh, uh, when should I check for this exactly (what enabled), and do you mean on n900?
<bencoh> I'm not super happy with lacking Samsung/Exynos documentations, but heck, TI/OMAP documentation is unreadable
<bencoh> I get this impression every single time I open one of those TRMs ...
<freemangordon> Wizzup: in dmesg
<bencoh> their SoCs are a mess :(
<freemangordon> we were seeing that on d4 iirc
<freemangordon> do you see that on n900?
<freemangordon> Wizzup: also, it seems tshut gpio is not defined for omap3
<freemangordon> in dts that is
<freemangordon> tmlind: ping
<sicelo> Wizzup: xf86-video-omap ... what's the correct package name? pvr-omap4-xf86? or xserver-xorg-video-omap?
<bencoh> CONTROL_TEMP_SENSOR returns 0x0 on kp53 here btw, is that expected?
<freemangordon> no idea
<freemangordon> but driver seems to work
<bencoh> ah, now it shows 0x2e
<bencoh> (I devmem'ed it in a loop and cat'ed the temp1_input sysfs at the same time)
<freemangordon> mhm
<freemangordon> makes sense
<bencoh> 0x2E != 20, but whatever
<freemangordon> oh, no
<bencoh> no idea what they do there
<freemangordon> this is adc reading
<bencoh> it's reprocessed?
<freemangordon> there is a table, look in the TRM
<bencoh> ah :)
<bencoh> oh right
<bencoh> yay, 46 == 19.4
<Wizzup> sicelo: look at git repo of xf86-video-omap debian/control
<sicelo> thanks. will do
<bencoh> (ie 0x2E -> 19.4)
<bencoh> looks like it works then
<freemangordon> try to find omap34xx_adc_to_temp over the inet
<freemangordon> this is what is used in KP
<bencoh> I'll check in my kp tree
<freemangordon> umm
<freemangordon> in upstream, sorry :)
<bencoh> ah
<freemangordon> in kp it is adc_to_temp
<bencoh> yeah there is a nice LUT
<freemangordon> mhm
<freemangordon> hmm:
<freemangordon> .bgap_dtemp_mask = 0x7f,
<freemangordon> this is rather 3f
<bencoh> I suppose core_l4_clkdm is the default clock domain?
<sicelo> Wizzup: not to derail convo - but looks like there's some unexpected dependency issues with xserver-xorg-video-omap (which comes from xf86-video-omap) ... installing it forces removal of sgx-um-ti443x and installs ti343x instead. anyway, maybe something for later. i'm more interested in this bandgap stuff :-)
<bencoh> freemangordon: yeah it should be 0x3f
<Wizzup> sicelo: I think that depends on the -meta file
<Wizzup> if you are asking for n900, I didn't fix those yet
<sicelo> i'm on d4. that's why i find it odd
<Wizzup> for droid4 it should work with dist-upgrade and -experimental
<freemangordon> and I guess this leads to wrong temp being calculated
* bencoh nods
<freemangordon> not only that, but this could potentially lead to writing to EOCZ, which is RO bit
<bencoh> freemangordon: although I'm not sure EOCZ is high when they try to read it
<bencoh> well, I dunno how the mainline driver does it, but I didn't see CONTCONV==1 on kp53
<bencoh> (when dumping regs)
<freemangordon> it is in single conv mode
<bencoh> then they probably don't read the temp register before EOCZ returns to 0
<freemangordon> right
<bencoh> so it shouldn't affect it
<bencoh> (but you're right that it's wrong)
<freemangordon> mhm
<freemangordon> what worries me more is that tshut gpio is ignored
<freemangordon> I think that potentially may lead to what Wizzup is seeing
<freemangordon> because it seems gpios have issues in OFF mode
<bencoh> fucking firefox preventing me from opening non-https files -_- wtf
<bencoh> getlost mozilla
<bencoh> freemangordon: what is tshut gpio?
<bencoh> camera shut?
<bencoh> (I guess not, but ...)
<freemangordon> thermal shutdown
<bencoh> I don't see it in schems
<bencoh> is it a real gpio, or an internal interrupt?
<freemangordon> it is internal
<freemangordon> gpio 127
<bencoh> hmm
xmn has joined #maemo-leste
<freemangordon> bencoh: search for gpio_127
<bencoh> I only see it in omap3-pandora and a few non-omap3 boards ... lemme update my tree
<freemangordon> I don;t see it at all
<freemangordon> ah, the search is for TRM
<bencoh> afaiu tshut != gpio_127
<bencoh> tshut is an input-only internal signal
<freemangordon> hmm, my bad, 7f is ok
<bencoh> how so?
<bencoh> ah, 0:6
<bencoh> huhu
<freemangordon> yeah :)
<bencoh> tbf I made the same mistake when checking the regs manually :)
<freemangordon> so, what do you mean about gpio 127?
<freemangordon> it *is* gpio 127 if connected to a ball
<freemangordon> look at p. 3341
<bencoh> it took me some time to understand that gpio_127 can either be gpio_127 (external gpio) or TSHUT
<bencoh> (see the GPIO Integration Overview figure)
<freemangordon> mhm
<bencoh> no wonder it doesn't show up in schems then
zhxt has quit [Remote host closed the connection]
<freemangordon> do you see any threshold for tshut activation?
<bencoh> I see 160C
<bencoh> but that sounds high (wrong?)
<bencoh> see 7.4.6.2 Temperature Sensor
_inky has joined #maemo-leste
<bencoh> freemangordon: do we get "invalid gpio for tshut" at boot?
<freemangordon> no idea
<freemangordon> only Wizzup knows
<bencoh> ohwell, actually, nevermind .... omap3-thermal-data.c doesn't features TI_BANDGAP_FEATURE_TSHUT
<freemangordon> mhm
<freemangordon> which is weird
<bencoh> so the driver doesn't even try
<freemangordon> yes
<bencoh> either they didn't deem it necessary, or they missed omap3 when adding support for omap4/omap5
<freemangordon> thats strange, given that 3630 even has control over whether to enable or not TSHUT functionality
<bencoh> yeah
<freemangordon> (I am looking at 3630 TRM)
<bencoh> well, maybe they got lazy :>
<freemangordon> mhm
<freemangordon> So, maybe what happens is:
<freemangordon> 1. omap3 bangap driver doesn't attach irq routine for TSHUT interrupt(gpio)
<freemangordon> nice theory, but doesn;t explain why there is no oops with bangap driver disabled :)
<freemangordon> 2. in OFF mode gpios go crazy
<freemangordon> 4. we have unhandled irq
<freemangordon> 3. TSHUT is generated because of 2
<freemangordon> so, I think the highest prio is to see what happens with GPIOs in OFF mode
* freemangordon is afk
<freemangordon> ttyl
zhxt has joined #maemo-leste
<Wizzup> 18:04 < bencoh> freemangordon: do we get "invalid gpio for tshut" at boot?
<Wizzup> 18:05 < freemangordon> only Wizzup knows
<Wizzup> 18:05 < freemangordon> no idea
<Wizzup> ?
<bencoh> Wizzup: the answer is probably no, but the question was whether we get that error at boot (dmesg)
<bencoh> (on n900)
<freemangordon> Wizzup: also, there is some SiErr it seems, look at sprz278f.pdf
<bencoh> (the omap4 devicetrees probably define the gpio/interrupt, btw)
<freemangordon> 3.1.1.186
<bencoh> ohright
<Wizzup> yeah that's also a comment in kernel:
<Wizzup> * Note * http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory * 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used"
<bencoh> I was reading the omap34xx TRM btw, I just realized n900 is ... omap35xx right?
<freemangordon> no
<freemangordon> it is 3430
<bencoh> ah alright
<bencoh> the errata is 35xx then
<freemangordon> hmm?
<freemangordon> 3430 is HS version
<bencoh> sprz278f.pdf mentions 3530
<bencoh> oh
<bencoh> nevermind )
<bencoh> :)
<bencoh> freemangordon: I wouldn't be surprised if the tshut "omission" was related to that erradata
<bencoh> since on omap3 gpio_127 is mmc_whatever mode4
<bencoh> control_padconf_mmc1_dat4 / mmc1_dat5 / gpio_127
<bencoh> oh, erm ... mmc1 is in use on n900 right?
<bencoh> if so, then tshut cannot be used no matter what :)
<bencoh> the workaround in the errata is quite hilarious :'(
<bencoh> but we probably shouldn't be affected since our mmc IS in use
<bencoh> (unless it gets disabled from one of the pm_runtime handlers)
<Wizzup> sicelo: did -experimental work
<Wizzup> sicelo: if it didn't can you share the output of apt dist-upgrade
<bencoh> Wizzup: what's the recommended way to upgrade leste these days btw? HAM? apt-get in a screen/tmux? disabling some mce/dsme flag?
<Wizzup> I don't think leste usually restarts during an upgrade, but it does happen sometimes
<Wizzup> I just run 'apt-get update' and 'apt-get dist-upgrade'
<Wizzup> from osso-xterm
<bencoh> Wizzup: it hapenned to me last time :>
<bencoh> (actually it didn't even manage to poweroff iirc, I had to force-reboot :>)
<Wizzup> I don't have a specific recommendation, but you can touch the /etc/no_lg_reboots file or something
<Wizzup> (check name)
<bencoh> alright
<bencoh> thx
alex1216 has quit [Ping timeout: 268 seconds]
System_Error has quit [Ping timeout: 276 seconds]
_inky has quit [Ping timeout: 256 seconds]
inky_ has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
uvos has joined #maemo-leste
alex1216 has joined #maemo-leste
alex1216 has quit [Ping timeout: 240 seconds]
alex1216 has joined #maemo-leste
sunshavi_ has quit [Ping timeout: 260 seconds]
sunshavi_ has joined #maemo-leste
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 260 seconds]
_inky has joined #maemo-leste
mardy has quit [Quit: WeeChat 2.8]
alex1216 has quit [Quit: WeeChat 2.3]
System_Error has joined #maemo-leste
TonyStone has quit [Remote host closed the connection]
TonyStone has joined #maemo-leste