<Wizzup>
dsc_: managed to get a n900 for you for cheap
<Wizzup>
will send it next week
<mighty17[m]>
<uvos> "anyhow on d4 we have 6 errors in..." <- https://paste.debian.net/1221662/ here's my full_log, can you tell what the errors in d4 are?
sunshavi_ has quit [Remote host closed the connection]
sunshavi has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 252 seconds]
Daanct12 has joined #maemo-leste
Daaanct12 has quit [Ping timeout: 256 seconds]
Daanct12 is now known as Danct12
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: got dronbl banned _again_.
<Wizzup>
uff
<uvos>
banning shared, rotating and nat'd ips is pretty silliy
<uvos>
so you might be set for sdr and then have the clock at 2x
<uvos>
while the pannel wants ddr at 1x
<uvos>
that might kinda work
<uvos>
sometimes
<uvos>
but is wrong ofc
<uvos>
mighty17[m]: just becasue the board source saies that dosent mean its true
<mighty17[m]>
uvos: yeah that'd kinda make sense, as i use `56888889/2` and display works fine (altho at 30Hz)
<uvos>
mighty17[m]: on d4 the kernel drivers do sometimes just use other values
<uvos>
check the regs
<mighty17[m]>
on downstream? how so
<uvos>
rwmem?
<mighty17[m]>
that'll give clk?
<uvos>
sure if you look at the trm and find the right register it will give you anything
<uvos>
clk rate mismatch: 170666667 != 56888889 <= these arnt 2x away from eatch other
<mighty17[m]>
`clock-frequency = <28444445>;`
asriel_dreemurr is now known as asriel
<uvos>
yeah well why dont you flow the oops backtrace backwards to figure out where it comes up with the 170666667 number
<mighty17[m]>
well yeah thats the only option
inky_ has joined #maemo-leste
<freemangordon>
YAY! Tomi accepted the patch :)
<freemangordon>
vrfb comes next ;)
<bencoh>
:)
<freemangordon>
but I'll really appreciate if someone take on the tearing/6ms issue
xmn has joined #maemo-leste
<tmlind>
freemangordon: hey that's good news :) tomi usually ends up testing what he merges one way or another, so it will likely get some proper attention
<tmlind>
of course the possible security issues involved there also help to get some attention
<tmlind>
freemangordon: how about sprinkle some trace_printk() to track down where the 6ms delay comes from?
<freemangordon>
tmlind: yeah (merges)
<freemangordon>
tmlind: it is not that I don't have ideas how to tackle that, the point is that I want to focus on VRFB and then to return to adressbook
<freemangordon>
I've already wasted too much time on sgx. well wasted time, but still
<freemangordon>
tmlind: BTW, do we have some omapdrm patch in your tree that is not upstream?
<uvos>
freemangordon: i mean if you leave it lieing around ill do it eventually, rn im playing around with mz617 - but still
<uvos>
its not killing us is it ;)
<freemangordon>
yes, but is frustrating
<freemangordon>
and obviously we have some deeper issue with omap/drm
<tmlind>
yup
<uvos>
yeah we do
<freemangordon>
I *think* 6ms delay comes from FB pin()
<tmlind>
freemangordon: i think the only remaining patch we carry is really the vblank patch, the others are just hacks
<freemangordon>
do you plan to send it for upstreaming? or it has issues?
<uvos>
speaking of which - bit of a devuan problem, i setup a devuan rootfs for mz617 and i can use the default runlevel just fine and also modprobe whatever i need & mknode it. eveything seams to work fine
<freemangordon>
but?
<uvos>
but if i start udev the serial console dissconects, the device is still running & fine otherwise
<freemangordon>
:)
<uvos>
cant seam to find why udev would do that
<tmlind>
freemangordon: i did send the vblank already about a year ago, but was promised a promptly review only :)
<freemangordon>
and still no review?
<tmlind>
heh no, i should resend it
<freemangordon>
I can at least add Tested-by:
<freemangordon>
please do
<Wizzup>
uvos: huh, that's odd
<tmlind>
ok will do when i get a chance
<freemangordon>
thanks!
<uvos>
Wizzup: yeah frustrating, becuase the display dosent work so i cant look at anything after udev starts, the only way i know the system is still up & fine is because i wrote a script that dose sleep 30; touch /survived
<uvos>
so not sure how to debug even (maybe get usbnet up or something and then start udev)
<tmlind>
uvos: i think there was some issue loading usb modules in ealier kernels with mz617.. what kernel version?
<uvos>
5.16-rc3
<uvos>
+ your dts
<tmlind>
uvos: hmm let me see, that sounds familiar, i had an issue where loading the usb or phy would kill the uart..
<tmlind>
uvos: ah right, now i remember.. get rid of the emif nodes in the dts!
<uvos>
tmlind: thanks ill try that!
<tmlind>
uvos: ok let's hope it helps
<freemangordon>
tmlind: BTW, what are those 'hacks'?
<tmlind>
freemangordon: the latest incarnation of trying to flush to avoid the tearing
<freemangordon>
ah
<freemangordon>
I still think this is not kernel's job :)
<tmlind>
yeah ok
<freemangordon>
but yeah
<tmlind>
then there's the fix for making paging work
<freemangordon>
hmm, what is this?
<tmlind>
maybe that's not needed at all after your patch?
<freemangordon>
which patch is that, I can look at it to see if needed
<tmlind>
a similar fix should be done at least one more location, but that does not affect anything afaik
<freemangordon>
tmlind: the point is - maybe at some point we'll have to send mail to Tomi or Laurent re tearing issue, I want to be sure this tearing is not caused by something we did. That's why I am asking.
<tmlind>
yeah
<tmlind>
the tearing is hard on normal panels as the next refresh will hide it
<freemangordon>
not really
<tmlind>
i mean it's hard to see on normal panels
<freemangordon>
I see it on hdmi
<uvos>
its harder to se hdmi
<tmlind>
ok
<uvos>
but i would not call it hard
<freemangordon>
yeah, harder
<tmlind>
do you see it only after slowing down sgx?
<freemangordon>
no
<uvos>
no
<freemangordon>
the one that was caused when sgx is slowed down is another one
<tmlind>
maybe the tearing and the 6ms issue are related?
<freemangordon>
I fixed it in DDX
<freemangordon>
tmlind: could be
<freemangordon>
maybe we just don;t understand how that 'flush' happens
<tmlind>
heh yeah :)
<freemangordon>
maybe panel shall be somehow 'prepared' first
<freemangordon>
I mean - do you know if it has 'shadow framebuffer memory' in it?
<tmlind>
freemangordon: but yeah if you can test if we need at all path drm/omap: Fix shmem write-combined buffer handling
<freemangordon>
lemme see that
<tmlind>
ok
<tmlind>
so i have two fixes to send to tomi it seems, maybe only one
<uvos>
freemangordon: shadow framebuffer memory?
<freemangordon>
tmlind: so, on my question - is there any memory in th epanel itself?
<uvos>
the pannel has its own ram
<freemangordon>
my question, yes
<uvos>
but thats totaly transperant to the kernel afaik
<tmlind>
yup
<freemangordon>
but, it seems we write in that memory while it is being read from
<tmlind>
that's the command mode lcd right?
<uvos>
no
<freemangordon>
that's why the tearing
<uvos>
becuase then on hdmi there would be no tearing
<freemangordon>
uvos: how could you explain it then?
<tmlind>
right
<uvos>
we must be uploding the frame with tearing allready
<freemangordon>
hmm
<tmlind>
agree
<freemangordon>
right
<tmlind>
the command mode lcd we only refresh with delayed work
<freemangordon>
yeah
<tmlind>
afaik that is not blocking anything for 6ms, but i could be wrong
<freemangordon>
ok, maybe I can try to dump frames to see what is in there
<freemangordon>
I mean - the ones that come from h-d
<tmlind>
best to test the tearing and 6ms issue on hdmi to leave out the command mode lcd issues..
<freemangordon>
tmlind: I think pin()-ing the framebuffer is what takes 6ms
<freemangordon>
to me it is easier to test on command mode
<tmlind>
do we really do pin/unpin for each frame?
<freemangordon>
because noone urges me to do the next flip
<freemangordon>
I think so
<freemangordon>
every flip ends up with drmModeRmFB()
<freemangordon>
and starts with drmModeAddFB()
<tmlind>
seems heavy, but what do i know
<freemangordon>
didn;t verify it though
<freemangordon>
yeah
<Wizzup>
osso-abook should be in -devel (latest)
<Wizzup>
fyi
<freemangordon>
thanks!
<freemangordon>
tmlind: drmModeAddFB() takes less than 1ms
<tmlind>
what about drmModeRmFB() then?
<freemangordon>
it takes even less :)
<freemangordon>
mhm
<tmlind>
but total from drmModeAddFB() to drmModeRmFB() is 6ms?
<freemangordon>
drmmode_page_flip() is where both drmModeAddFB() and drmModePageFlip() are called
<freemangordon>
sgxFlipPrepare() waits for gpu ops to complete
<freemangordon>
and happens just before drmModePageFlip()
<freemangordon>
OMAPDRI2SwapDispatch() is called after exit from drmmode_page_flip()
<freemangordon>
ttyl
<tmlind>
ok
<tmlind>
later
l_bratch has quit [Quit: Leaving]
l_bratch has joined #maemo-leste
<uvos>
tmlind: yeah the emif was it
<uvos>
tmlind: not sure how/why emif would disconnect uart
<uvos>
without locking up the whole system that is
mardy has quit [Quit: WeeChat 2.8]
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #maemo-leste
<uvos>
Wizzup: remember how this works from us debuging xt860: DT: clk_lane=1 clk_pos=0 d1_lane=2 d1_pos=0 d2_lane=3 d2_pos=0 d3_lane=4 d3_pos=0 d4_lane=5 d4_pos=0