<Wizzup>
hm, we have NO_HZ=y, but there is also HZ=100
<Wizzup>
tmlind_: I am looking at your pm work on atmel_mxt_ts.c and it looks like that only uses i2c
<Wizzup>
tsc200x-core.c supports both spi and i2c it looks like
_inky has quit [Quit: Leaving.]
<Wizzup>
so I guess I need to add an abstraction for that
<Wizzup>
for my purposes (tsc2005) I could get away with just to_spi_device for now, but to actually submit it upstream it looks like I need that abstraction
inky has joined #maemo-leste
<Wizzup>
at least, as I understand it, this should be some bus device, rather than any device object (i.e. input device)
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
<Wizzup>
tmlind_: hmm tsc2005 doesn't use IRQF_NO_AUTOEN / enable_irq / disable_irq, I wonder if that attributes to the blocking
<Wizzup>
something else that I find interesting is that it looks like when booted to leste, none of the spi ever idle, for example spi1 usually idles when ts is not loaded
<Wizzup>
but on leste they are still loaded
ruleh has quit [Quit: Client closed]
<Wizzup>
honestly the wierdest thing I think is that the tsc2005 somehow causes the ST_I2C1 blocker, when it uses spi
<Wizzup>
maybe my parsing of the bits is wrong somehow
<_uvos_>
so, just like last time, playing audio files via smplayer/mpd, seams like the fastest way to cause a reboot
<_uvos_>
i have had reboots with the screen on and offp
<Wizzup>
mhm
<_uvos_>
pstore contains nothin or only non-usefull dmesg
<Wizzup>
what was the solution last time?
<Wizzup>
_uvos_: btw I got tsc2005 driver changed to the point that I am sure it knows when to suspend/disable (when no files are open) and it sending the STOP command to the touch controller
<Wizzup>
but I don't think it stops blocking
<Wizzup>
I was thinking if that could be because the irq is still enabled, or perhaps (less likely) because the regular is still enabled?
_uvos_ has quit [Ping timeout: 268 seconds]
<Wizzup>
rip
_uvos_ has joined #maemo-leste
vectis has quit [Ping timeout: 268 seconds]
<Wizzup>
_uvos_: not sure if you're avail but you see my msg before you timed out?
<_uvos_>
just read it in the txt file
<_uvos_>
so irq maybe yeah depending on the irq source
<_uvos_>
dont have the trm here but i dont think omap gpio interrupts block sleep.
<Wizzup>
ok
<Wizzup>
I'll mail my rfc patch since I think it's useful anyway and think about a better way of testing this, if I load just the ts modules the input dev doesn't know up, even if I mknod it, so I'm going to ponder on what's up with that
<Wizzup>
some progress at least
_uvos_ has quit [Ping timeout: 256 seconds]
inky_ has quit [Ping timeout: 240 seconds]
inky_ has joined #maemo-leste
Danct12 has quit [Quit: Quitting]
pere has quit [Ping timeout: 245 seconds]
Danct12 has joined #maemo-leste
<Wizzup>
omap3_isp also blocks
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 240 seconds]
<Wizzup>
could be because audio never fully probes
<Wizzup>
uvos, I wonder if the reset I am seeing on the n900 is also what's causing trouble for the droid perhaps
<Wizzup>
got another reset on the n900 just now - after it booted
ruleh has quit [Ping timeout: 256 seconds]
ruleh has joined #maemo-leste
<Wizzup>
I think blocking omap3_isp helps idling but then I just hit the idle panic pretty much immediately lol