15:40 <macromorgan> iahn: Check your clock assignments and the clock frequency. Look at all those rk3566-anbernic-* boards for reference in arch/arm64/boot/dts/rockchip in mainline.

15:41 <macromorgan> On each of them I use the VP1 port for the DSI controller, I assign the PLL_VPLL as the parent clock, and I have to be very selective of what frequency I set for PLL_VPLL to make it as close to a whole fraction of the requested pixel clock as possible.

16:10 <macromorgan> Kwiboo: did you get a chance to check out those memory hole patches? My computer died last week and took my OS with it, so I'm starting over with no IRC history...

16:10 <qschulz> https://libera.irclog.whitequark.org/linux-rockchip

16:33 <ianh> macromorgan: thanks - will do. i've been referencing the mainline dts's

16:35 <ianh> i built a rockchip android image for it and strangely, the boot splash displays correctly (briefly) but then nothing else draws, with a "Error: Cluster-Win0 is invisible" in vop2_plane_atomic_check

16:36 <ianh> that's sort of orthogonal though since Radxa's android SDK is built off a combination of the Rockchip Android SDK and Radxa's own BSP stuff - either way, definitely not mainline linux

16:39 <ianh> it looks like it's panicking after a while in vop2_crtc_disable_vblank; i'll go back and take a look at the clock settings for the VOP

20:01 <macromorgan> hmm

20:01 <macromorgan> as an aside, do you have your android image published? I'm really really interested in making an AOSP "proof of concept" for those devices...

20:29 <ianh> oh, no i don't, but it's nothing special. i just followed Radxa's instructions and built an Android 11 image using their fork of the rockchip android11 sdk and then went in and edited the dts lol.

21:35 <ianh> i finally figured out what was right in front of my face, the DSI panel is a proprietary one with its own init sequence and what-not, not just a dumb display. and the compatible string says it's compatible with "simple-panel-dsi" but it turns out that's the rockchip simple-panel-dsi driver.

21:36 <ianh> the rockchip simple-panel-dsi is what it's compatible with. it's one of the Radxa 10FHD 10.1 DSI LCD + Goodix GT9xx touch controller ones; but i have no way of knowing what model the actual panel is

21:37 <ianh> so unless the panel is some rebadged one that has DSI panel support in Linux and i just need to supply a different compatible and write a different overlay...i think i may be shit out of luck :-/

21:44 <ianh> i would imagine all the business logic that rockchip moved "out" into the DTS in their panel-simple-dsi is implemented per panel driver in linux. which is a bummer because i have no idea what the panel actually is let alone documentation on it; seems like a dead end unfortunately.

21:44 <ianh> e.g. init sequences, prepare delays, etc.

22:08 <macromorgan> do you have a device tree for it?

22:09 <macromorgan> If you decompile the devicetree you can extract all the necessary information from it (that's where all those init sequences came from for each of those handhelds I worked on)

22:11 <ianh> yeah, i have an overlay for it including the init / exit sequences - the issue is that i think i would have to write an entire new panel driver to support it. not sure how tricky that would be

22:11 <CounterPillow> Not hard

22:12 <ianh> oh ok!

22:12 <CounterPillow> Take one of the existing ones, swap in the new panel init sequence, make sure everything else checks out

22:13 <ianh> oh shit ok! yeah the rockchip simple-panel-dsi driver is loooong and i didn't want to go through the whole thing. let me see if i can find a similar dsi panel and see what the driver looks like

23:24 <ianh> hmmmm so the rockchip dsi driver exposes "prepare-delay-ms", "init-delay-ms" etc properties. in my case mine are 120ms for both. im guessing that "prepare" is before the first commands and "init-delay" is after...so i probably throw in a msleep(120) before and after firing my init sequence?