| uvos | so imanaged to boot devuan on mz617 depolying lest on | 00:09 |
|---|---|---|
| uvos | this thing is going to be fun | 00:09 |
| uvos | we have to create a small 600 mb ish image that we flash to preinstall that copyies itself over to userdata and then downloads the rest of the packages | 00:10 |
| Wizzup | uvos: hm... making a small image isn't a big problem if we make it interactive I guess | 00:15 |
| uvos | now i want one of these :P | 00:26 |
| uvos | https://www.ebay.com/itm/174740269983?_trkparms=amclksrc%3DITM%26aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D20180816085401%26meid%3Db821bd2503c94b92b81814b632a7b0f4%26pid%3D100970%26rk%3D1%26rkt%3D10%26sd%3D174740269983%26itm%3D174740269983%26pmt%3D0%26noa%3D1%26pg%3D2380057%26brand%3DMotorola&_trksid=p2380057.c100970.m5481&_trkparms=pageci%3Affb68de1-52fd-11ec-92a4-6e6689b06521%7Cparentrq%3A7851696517d0a74485204c06ffe69a06%7Ciid% | 00:26 |
| uvos | 3A1 | 00:26 |
| uvos | aperantly the link is to long | 00:26 |
| uvos | https://www.ebay.com/itm/174740269983 | 00:27 |
| Wizzup | uvos: yeah neat | 01:47 |
| parazyd | sicelo: How much do you know about libsharing in fremantle? | 12:19 |
| mighty17[m] | <uvos> ""[14:51] <mighty17> uvos..." <- https://paste.debian.net/1221661/ | 15:03 |
| Wizzup | dsc_: managed to get a n900 for you for cheap | 15:06 |
| Wizzup | will send it next week | 15:06 |
| 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? | 15:11 |
| uvos | Wizzup: got dronbl banned _again_. | 17:06 |
| Wizzup | uff | 17:07 |
| uvos | banning shared, rotating and nat'd ips is pretty silliy | 17:08 |
| Wizzup | mhm | 17:08 |
| Wizzup | probably helps in the short term | 17:08 |
| uvos | anyways: mighty17[m]: http://uvos.xyz/maserati/os_idle_uc_audit_details.txt | 17:10 |
| uvos | we acctually just have 5 now (since swtiching to ddk1.17 a sgx related error vanished) | 17:11 |
| mighty17[m] | hm I have an error with TIMER10 which is related to my pwm backlight (which is gptimer) | 17:12 |
| mighty17[m] | i know my pwm value `pwms = <&pwm10 0 5000000 0>;` is wrong ie 5000000 should be smth else but idk how to find it | 17:12 |
| uvos | that oops is very descriptive no? | 17:12 |
| uvos | just go into dss_set_fck_rate and follow backwards to check why it thinks that the rate should be 56888889 | 17:13 |
| uvos | probubly something you did in dts | 17:13 |
| uvos | or some driver thinks this is a device limit | 17:13 |
| mighty17[m] | uvos: because 56888889 is the correct rate | 17:13 |
| mighty17[m] | But then display goes haywire | 17:14 |
| uvos | how do you know its the correct rate? | 17:14 |
| uvos | why not compear the registers on android with those on mainline | 17:14 |
| uvos | btw dsi can do double signaling | 17:15 |
| mighty17[m] | uvos: https://github.com/Unlegacy-Android/android_kernel_ti_omap4/blob/3.0/common/arch/arm/mach-omap2/board-espresso-display.c#L65 | 17:15 |
| uvos | (ie on leading and falling eadge) | 17:15 |
| uvos | so you might be set for sdr and then have the clock at 2x | 17:16 |
| uvos | while the pannel wants ddr at 1x | 17:16 |
| uvos | that might kinda work | 17:16 |
| uvos | sometimes | 17:16 |
| uvos | but is wrong ofc | 17:16 |
| uvos | mighty17[m]: just becasue the board source saies that dosent mean its true | 17:17 |
| mighty17[m] | uvos: yeah that'd kinda make sense, as i use `56888889/2` and display works fine (altho at 30Hz) | 17:17 |
| uvos | mighty17[m]: on d4 the kernel drivers do sometimes just use other values | 17:17 |
| uvos | check the regs | 17:17 |
| mighty17[m] | on downstream? how so | 17:17 |
| uvos | rwmem? | 17:17 |
| mighty17[m] | that'll give clk? | 17:19 |
| uvos | sure if you look at the trm and find the right register it will give you anything | 17:19 |
| uvos | clk rate mismatch: 170666667 != 56888889 <= these arnt 2x away from eatch other | 17:20 |
| mighty17[m] | `clock-frequency = <28444445>;` | 17:20 |
| uvos | yeah well why dont you flow the oops backtrace backwards to figure out where it comes up with the 170666667 number | 17:22 |
| mighty17[m] | well yeah thats the only option | 17:23 |
| freemangordon | YAY! Tomi accepted the patch :) | 17:30 |
| freemangordon | vrfb comes next ;) | 17:30 |
| bencoh | :) | 17:31 |
| freemangordon | but I'll really appreciate if someone take on the tearing/6ms issue | 17:31 |
| 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 | 17:59 |
| tmlind | of course the possible security issues involved there also help to get some attention | 17:59 |
| tmlind | freemangordon: how about sprinkle some trace_printk() to track down where the 6ms delay comes from? | 18:00 |
| freemangordon | tmlind: yeah (merges) | 18:03 |
| 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 | 18:04 |
| freemangordon | I've already wasted too much time on sgx. well wasted time, but still | 18:04 |
| freemangordon | tmlind: BTW, do we have some omapdrm patch in your tree that is not upstream? | 18:05 |
| uvos | freemangordon: i mean if you leave it lieing around ill do it eventually, rn im playing around with mz617 - but still | 18:05 |
| uvos | its not killing us is it ;) | 18:05 |
| freemangordon | yes, but is frustrating | 18:06 |
| freemangordon | and obviously we have some deeper issue with omap/drm | 18:06 |
| tmlind | yup | 18:06 |
| uvos | yeah we do | 18:06 |
| freemangordon | I *think* 6ms delay comes from FB pin() | 18:07 |
| tmlind | freemangordon: i think the only remaining patch we carry is really the vblank patch, the others are just hacks | 18:07 |
| freemangordon | do you plan to send it for upstreaming? or it has issues? | 18:07 |
| 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 | 18:08 |
| freemangordon | but? | 18:08 |
| uvos | but if i start udev the serial console dissconects, the device is still running & fine otherwise | 18:09 |
| freemangordon | :) | 18:09 |
| uvos | cant seam to find why udev would do that | 18:09 |
| tmlind | freemangordon: i did send the vblank already about a year ago, but was promised a promptly review only :) | 18:09 |
| freemangordon | and still no review? | 18:09 |
| tmlind | heh no, i should resend it | 18:09 |
| freemangordon | I can at least add Tested-by: | 18:09 |
| freemangordon | please do | 18:10 |
| Wizzup | uvos: huh, that's odd | 18:10 |
| tmlind | ok will do when i get a chance | 18:10 |
| freemangordon | thanks! | 18:10 |
| 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 | 18:11 |
| uvos | so not sure how to debug even (maybe get usbnet up or something and then start udev) | 18:12 |
| tmlind | uvos: i think there was some issue loading usb modules in ealier kernels with mz617.. what kernel version? | 18:12 |
| uvos | 5.16-rc3 | 18:12 |
| uvos | + your dts | 18:12 |
| tmlind | uvos: hmm let me see, that sounds familiar, i had an issue where loading the usb or phy would kill the uart.. | 18:13 |
| tmlind | uvos: ah right, now i remember.. get rid of the emif nodes in the dts! | 18:14 |
| uvos | tmlind: thanks ill try that! | 18:15 |
| tmlind | uvos: ok let's hope it helps | 18:15 |
| freemangordon | tmlind: BTW, what are those 'hacks'? | 18:25 |
| tmlind | freemangordon: the latest incarnation of trying to flush to avoid the tearing | 18:25 |
| freemangordon | ah | 18:26 |
| freemangordon | I still think this is not kernel's job :) | 18:26 |
| tmlind | yeah ok | 18:26 |
| freemangordon | but yeah | 18:26 |
| tmlind | then there's the fix for making paging work | 18:26 |
| freemangordon | hmm, what is this? | 18:27 |
| tmlind | maybe that's not needed at all after your patch? | 18:27 |
| freemangordon | which patch is that, I can look at it to see if needed | 18:27 |
| tmlind | drm/omap: Fix shmem write-combined buffer handling | 18:28 |
| tmlind | a similar fix should be done at least one more location, but that does not affect anything afaik | 18:28 |
| 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. | 18:29 |
| tmlind | yeah | 18:29 |
| tmlind | the tearing is hard on normal panels as the next refresh will hide it | 18:30 |
| freemangordon | not really | 18:30 |
| tmlind | i mean it's hard to see on normal panels | 18:30 |
| freemangordon | I see it on hdmi | 18:31 |
| uvos | its harder to se hdmi | 18:31 |
| tmlind | ok | 18:31 |
| uvos | but i would not call it hard | 18:31 |
| freemangordon | yeah, harder | 18:31 |
| tmlind | do you see it only after slowing down sgx? | 18:31 |
| freemangordon | no | 18:31 |
| uvos | no | 18:31 |
| freemangordon | the one that was caused when sgx is slowed down is another one | 18:31 |
| tmlind | maybe the tearing and the 6ms issue are related? | 18:32 |
| freemangordon | I fixed it in DDX | 18:32 |
| freemangordon | tmlind: could be | 18:32 |
| freemangordon | maybe we just don;t understand how that 'flush' happens | 18:32 |
| tmlind | heh yeah :) | 18:32 |
| freemangordon | maybe panel shall be somehow 'prepared' first | 18:32 |
| freemangordon | I mean - do you know if it has 'shadow framebuffer memory' in it? | 18:33 |
| tmlind | freemangordon: but yeah if you can test if we need at all path drm/omap: Fix shmem write-combined buffer handling | 18:33 |
| freemangordon | lemme see that | 18:33 |
| tmlind | ok | 18:33 |
| tmlind | so i have two fixes to send to tomi it seems, maybe only one | 18:33 |
| uvos | freemangordon: shadow framebuffer memory? | 18:34 |
| freemangordon | tmlind: so, on my question - is there any memory in th epanel itself? | 18:34 |
| uvos | the pannel has its own ram | 18:34 |
| freemangordon | my question, yes | 18:34 |
| uvos | but thats totaly transperant to the kernel afaik | 18:34 |
| tmlind | yup | 18:34 |
| freemangordon | but, it seems we write in that memory while it is being read from | 18:34 |
| tmlind | that's the command mode lcd right? | 18:35 |
| uvos | no | 18:35 |
| freemangordon | that's why the tearing | 18:35 |
| uvos | becuase then on hdmi there would be no tearing | 18:35 |
| freemangordon | uvos: how could you explain it then? | 18:35 |
| tmlind | right | 18:35 |
| uvos | we must be uploding the frame with tearing allready | 18:35 |
| freemangordon | hmm | 18:35 |
| tmlind | agree | 18:35 |
| freemangordon | right | 18:35 |
| tmlind | the command mode lcd we only refresh with delayed work | 18:35 |
| freemangordon | yeah | 18:35 |
| tmlind | afaik that is not blocking anything for 6ms, but i could be wrong | 18:36 |
| freemangordon | ok, maybe I can try to dump frames to see what is in there | 18:36 |
| freemangordon | I mean - the ones that come from h-d | 18:36 |
| tmlind | best to test the tearing and 6ms issue on hdmi to leave out the command mode lcd issues.. | 18:36 |
| freemangordon | tmlind: I think pin()-ing the framebuffer is what takes 6ms | 18:37 |
| freemangordon | to me it is easier to test on command mode | 18:37 |
| tmlind | do we really do pin/unpin for each frame? | 18:37 |
| freemangordon | because noone urges me to do the next flip | 18:37 |
| freemangordon | I think so | 18:37 |
| freemangordon | every flip ends up with drmModeRmFB() | 18:38 |
| freemangordon | and starts with drmModeAddFB() | 18:39 |
| tmlind | seems heavy, but what do i know | 18:39 |
| freemangordon | didn;t verify it though | 18:39 |
| freemangordon | yeah | 18:39 |
| Wizzup | osso-abook should be in -devel (latest) | 18:39 |
| Wizzup | fyi | 18:39 |
| freemangordon | thanks! | 18:40 |
| freemangordon | tmlind: drmModeAddFB() takes less than 1ms | 18:41 |
| tmlind | what about drmModeRmFB() then? | 18:42 |
| freemangordon | it takes even less :) | 18:44 |
| freemangordon | mhm | 18:47 |
| tmlind | but total from drmModeAddFB() to drmModeRmFB() is 6ms? | 18:50 |
| freemangordon | no | 18:50 |
| freemangordon | tmlind: https://pastebin.com/RExGh683 | 18:51 |
| freemangordon | drmmode_page_flip() is where both drmModeAddFB() and drmModePageFlip() are called | 18:52 |
| freemangordon | sgxFlipPrepare() waits for gpu ops to complete | 18:52 |
| freemangordon | and happens just before drmModePageFlip() | 18:53 |
| freemangordon | OMAPDRI2SwapDispatch() is called after exit from drmmode_page_flip() | 18:53 |
| freemangordon | ttyl | 18:53 |
| tmlind | ok | 18:54 |
| tmlind | later | 18:55 |
| uvos | tmlind: yeah the emif was it | 20:44 |
| uvos | tmlind: not sure how/why emif would disconnect uart | 20:45 |
| uvos | without locking up the whole system that is | 20:45 |
| 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 | 22:03 |
| Wizzup | let me try to remember... | 22:04 |
| uvos | DT: clk_lane=1 clk_pos=0 d1_lane=2 d1_pos=0 d2_lane=3 d2_pos=0 d3_lane=0 d3_pos=0 d4_lane=0 d4_pos=0 | 22:04 |
| uvos | first is mz617 | 22:04 |
| uvos | last is d4 | 22:04 |
| uvos | tmlind: ^^^ clerly the dsi lanes are different | 22:04 |
| uvos | so irrc the lanes here are diff-pairs | 22:05 |
| uvos | and xt860 just had the diff-pair polarity flipped | 22:05 |
| uvos | ie every other line was exchanged | 22:05 |
| Wizzup | ok I see the difference | 22:06 |
| Wizzup | //CLK+, CLK-, DATA0+, DATA0-, DATA1+, DATA1-, ... | 22:07 |
| Wizzup | // clk+ = 1, data1_pos = 1 | 22:07 |
| Wizzup | lanes = <1 0 3 2 5 4>; | 22:07 |
| Wizzup | I had this as notes from the d3 | 22:07 |
| Wizzup | that is as opposed to lanes = <0 1 2 3 4 5>; | 22:07 |
| Wizzup | (from mapphone common) | 22:07 |
| Wizzup | ideally we'd dig up the DT line from d3 - do you have it around? | 22:08 |
| uvos | so mz617 goes <0 1 2 3 4 5 6 7 8 9> and has 2x the data lanes | 22:10 |
| uvos | am i reading this right? | 22:10 |
| Wizzup | hmm | 22:10 |
| uvos | xt860: DT: clk_lane=1 clk_pos=1 d1_lane=2 d1_pos=1 d2_lane= 3 d2_pos= 1 | 22:10 |
| Wizzup | we should dig up the irc logs, sec | 22:11 |
| Wizzup | uvos: https://dpaste.com/8GK3ZR8WS | 22:12 |
| Wizzup | uvos: yes I suppose that could work | 22:14 |
| uvos | hmm no thats not it - or something else is wrong aswell | 22:36 |
| uvos | pretty sure <0 1 2 3 4 5 6 7 8 9> is right actually - but we have a problem with the bridge too | 22:37 |
| uvos | maybe i should try not touching the bridge and pretending we have a dsi pannel and hope the android kernel set everything up allready | 22:37 |
| uvos | DSI: omapdss DSI: failed to send nop between frames: -22 | 22:53 |
| uvos | no i gues the chip gets reset | 22:53 |
| uvos | :\ | 22:53 |
| uvos | hmm | 22:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!