01:02 <lvrp16> robmur01: good to know. Thanks a bunch.

10:27 <morax> hi, i got raw-nand dump from px30/rk3326. is there any tools which can covert it to normal raw data?

10:30 <morax> i found FTL/NFC date layout at kernel/uboot source, i found rkflash and rknand; and i found some leak(?) rknand

10:30 <morax> source from rk2918, but i think no help, i think they do this in hardware, am i wrong?

10:55 <mps> which kernel options/drivers needs to be enabled to get hardware video decoder on rk3399 soc

13:54 <CounterPillow> mps: CONFIG_VIDEO_HANTRO, CONFIG_VIDEO_HANTRO_ROCKCHIP, CONFIG_VIDEO_ROCKCHIP_VDEC

14:01 <mps> CounterPillow: thank you

15:44 <mps> CounterPillow: it doesn't work at all on rk3399 samsung one plus chromebook. I've got blank display at boot

15:44 <mps> and nothing is printed on it

15:44 <CounterPillow> ok? unrelated to you turning those options on though.

15:45 <mps> I have no idea, same kernel without these options works fine

15:47 <mps> will try again with one-by-one change

15:48 <CounterPillow> if anything you should hook up uart and get serial output if you can

15:52 <mps> I didn't found any method to hook serial device to this chromebook

15:53 <mps> it would be useful

15:57 <mps> CounterPillow: sorry, my bad. it boots. I changed something else unintentionally

18:49 <warpme> guys: i don't know full mechanics between dw-hdmi-phy and vop in rk - so i need some help. Im hacking with 3528 & i backported 3528 dw-hdmi support to mainline (6.4). Issue i have is wrong video modes i'm getting in mainline: forcing 1920x1080@60 gives on my tv some errors like 240p 768Hz. I compared relevant clocks in clocks_summary between: box android and my mainline code. They are the same. I done test with: bsp

18:49 <warpme> phy-rockchip-inno-hdmi-phy.c transplanted to mainline and results are the same. All looks to me that issue is not in my backported dw-hdmi code - but rather in my backport vop2 code which wrongly drives dw-hdmi. Is it possible that wrong vop2 code drives dw-hdmi driver to video mode with errant timings?

19:05 <robmur01> if the clock tree isn't quite right in the clock driver, and changing a VOP clock affects some parent clock shared with HDMI behind its back, then yes.

19:07 <robmur01> not to mention that IIRC inno-hdmi-phy's own internal clock code isn't super-robust to begin with, so there's probably plenty of room for that to go wrong by itself

19:09 <robmur01> (although my experience on 3328 is more of it refusing to play at all, giving no output and vblank timeout errors from the VOP)

19:16 <warpme> robmur01 : i done following test: connect tv, boot android and mainline 6.4. In both cases videomode was the same. Then I compared relevant clocks and both: android and mainline has the same relevant clocks (i mean clocks defined in hdmi, phyhdmi and vop)

19:17 <warpme> are vop clocks dependent on videomodes?

19:18 <robmur01> possibly, not sure (especially not when it comes to VOP2)

19:19 <robmur01> and when you say "compare clocks", do you mean by dumping the raw CRU registers, or just the debugfs view of what the clock driver *thinks* they *should* be? ;)

19:26 <warpme> robmur01 : unfortunately 2nd case (debugfs). clk driver i'm using is also backport from bsp. It gives me working cpu dvfs, sd, eth, usb - so i'm optimistically assuming hdmi/vop2 also should get correct clocks (visual comparison of android an mainjline clk_summary gives almost 100% on par)

19:32 <robmur01> remember when we had a similar thing with CEC? I just don't trust clock drivers by default now :D

20:03 <Kwiboo> hdmi should hopefully improve a little bit on rk3328 for 6.7 now that my 3+ year old inno-hdmi-phy series has been merged into linux-phy tree ;), https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/log/drivers/phy/rockchip?h=next

20:04 <Kwiboo> warpme: bsp kernel have a vop3 variant that is used for rk3528, did you port that also?

20:15 <warpme> Kwiboo : i added very initial & minimal vop3 support - basically just to get dw-hdmi driver loading as without vop dw-hdmi not loads/operates at all. My idea was to: get dw-hdmi semi-working then work on vop3 then polish dw-hdmi then "polish" (if my limited skills will allow) vop3.

20:22 <warpme> i wouldn't say my vop3 support is even minimally now - but i was thinking (& this looks like false assumption now): no correctly working vop3 should not impact low level dw-hdmi mode setting. I was thinking: if dw-hdmi code is ok - then video mode setting at crtc level should work - despite vop3 is not working yet....