<tmlind>
looks like the te stuff is broken, but if the patch above makes the tearing disappear we know where the problem is
<Wizzup>
freemangordon: can you tell me how to check?
<Wizzup>
freemangordon: I hit is several times a day and only solution is usbnet + reboot or force reboot with buttons
<freemangordon>
tmlind: I am almost sure my patch that sets the relevant bits in TE regs is needed
<freemangordon>
Wizzup: mount debugfs
<freemangordon>
sec to check the path
<tmlind>
freemangordon: no luck making te run for more than two mins at most so far.. but with the patch above, curiously i'm seeing vt_te not empty all the time with some load generated with dd if=/dev/urandom of=/dev/null
<freemangordon>
tmlind: yeah, ok, will test the patch
<tmlind>
freemangordon: it could be framedone irq is ok to use as that's for the flip while dsi is still not done
<tmlind>
freemangordon: in that case the patch above does not help at all for tearing :)
<tmlind>
need to go now to visit some friends, ttyl
<freemangordon>
I don;t think it is, as there is a note in TRM that transfer from DSI to panel still continues on framedone IRQ
<freemangordon>
ok
<freemangordon>
Wizzup: /sys/kernel/debug/dma_buf
<Wizzup>
ok
<freemangordon>
check in bufinfo there if there is some non-signaled fence
<freemangordon>
if that's the case, then we have some issue in PVR driver
<freemangordon>
if everything is signaled, then I think fence patch is unrealated
<freemangordon>
*unrelated
<Wizzup>
I was thinking this might be the problem because ERESTARTSYS in combination with DRM_IOCTL_MODE_SETPROPERTY in google resulted in some hits for dma fance waiting
<Wizzup>
well this is definitely a recent problem
<freemangordon>
yeah
<freemangordon>
but lets see first if we have non-signaled fence
<Wizzup>
thinking of making a script to turn on/off dpms
<freemangordon>
hmm?
<freemangordon>
how's that related?
<Wizzup>
X gets stuck in dpms
<Wizzup>
if you recall that trace I shared before
<Wizzup>
the drmIoctl keeps getting -ERESTARTSYS in ioctl in libdrm on DRM_IOCTL_MODE_SETPROPERTY
<Wizzup>
so it tries again, as it should
<Wizzup>
but it never ever succeeds
<Wizzup>
and this just keeps on going
<Wizzup>
I think I also shared X backtrace and dmesg debug with drm.debug=0xff
<freemangordon>
Wizzup: ok, but I don't understand what use this script will have? like wokraround or what?
<Wizzup>
freemangordon: reproduce it quickly
<freemangordon>
ah
<Wizzup>
freemangordon: now it usually happens when I am outside walking or in a store
<Wizzup>
and it's annoying because then I can't use my phone for hour
<Wizzup>
s
<freemangordon>
but, if it is fence issue, you need drawing ops
<freemangordon>
can't you reset it?
<Wizzup>
sure, but then I can't get you the trace ;)
<Wizzup>
s/trace/data/
<freemangordon>
ah :)
inky_ has quit [Ping timeout: 250 seconds]
inky_ has joined #maemo-leste
inky_ has quit [Read error: Connection reset by peer]
inky_ has joined #maemo-leste
<Wizzup>
telepathy-qt is quite complex ... very little documentation