13:30 <macc24> mmind00: with parts of "drm/rockchip: RK356x VOP2 support" series merged, is there anything missing for mipi-dsi display on rk356x aside iommu patches mentioned in it?

13:31 <mmind00> macc24: for the rk3568-dsi, I don't think that there is anything missing - should be just a compatible and some grf bits I guess ;-)

13:31 <macc24> mmind00: "grf bits"?

13:32 <mmind00> macc24: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#n1560 these things ;-)

13:33 <macc24> ah

13:33 <mmind00> macc24: the iommu thingy I guess is the one from robmur01 which I tested and merged yesterday

13:34 <macc24> mmind00: my rk3566 board that i'll port to mainline kernel is going to arrive soon™, hoping to get display running on it

13:34 <macc24> i've also got a new rk3399 device port in works, only touchscreen and sound not working/not tested

13:35 <mmind00> macc24: in any case, I plan to look at the rest of the series (vop2 part) this week as well, so I guess only the hdmi-rate-thingy will stay where it is for now

13:36 <robmur01> yup, if you can build the v10/v11 VOP2 patches without error, you've already got my IOMMU-related changes ;)

13:36 <macc24> mmind00: okay, btw into what tree you merged those patches into? can't find them at https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git

13:36 <mmind00> robmur01: :-D ... also I very distinctively remember doing "dim apply-branch ..." for the iommu one yesterday

13:37 <mmind00> macc24: drm/rockchip patches go through the drm-misc tree

13:37 <mmind00> macc24: https://cgit.freedesktop.org/drm/drm-misc/log/

13:37 <robmur01> indeed, that was waiting in my inbox this morning, thanks!

13:38 <macc24> mmind00: okay, thanks!

13:39 <mmind00> macc24: in any case, all the merged parts should come together in linux-next tomorrow or so

13:49 <CounterPillow> mmind00: re the timing table patch that breaks your rock64, I looked at the script that generated that table and it is suspect (aside from just the python2 usage). It doesn't use arbitrary precision types for its math. I'll try to switch everything to decimal.Decimal() and see if the output is different

13:49 <mriesch> macc24: i believe for mipi dsi on rk356x the rk3568-video-phy driver is required (in addition to what mmind00 pointed out)

13:51 <macc24> mriesch: would that be required on rk3566 too?

13:52 <mriesch> that'd be my guess, yes

13:52 <CounterPillow> afaik yes, the two chips are nearly identical

13:52 <mmind00> macc24: very likely, as rk3566 + rk3568 are mostly the same

13:52 <CounterPillow> aside from CAN, USB 3.0 OTG, and PCIe 3

13:53 <macc24> okay

13:55 <mriesch> macc24: which board and panel are you aiming at?

13:56 <macc24> mriesch: anbernic rg503, samsung ams-whatever, it's ps vita 1000 panel

13:58 <mriesch> ah nice.. is the rg503 supported by mainline?

13:58 <macc24> nope

13:59 <macc24> it barely released and the furthest anyone got was a uart shell... with a dts that i wrote

14:01 <mriesch> i see.. well fwiw sascha has pushed some commits here: https://git.pengutronix.de/cgit/sha/linux/log/?h=rockchip-vop2-mipi but this branch targets the rk3568-evb1

14:02 <macc24> thanks

14:04 <CounterPillow> Speaking of which, I tried looking into edp but gave up because rockchipdrm quietly dying whenever it didn't like something did not make for a very chungus wholesome debugging experience

14:04 <robmur01> CounterPillow: I doubt Rock64 issues are that subtle - I'd assume that mmind00's monitor has a preferred mode with a clock rate that makes the RK3328 phy sad, and is no longer being filtered out by dw_hdmi's rate table

14:05 <CounterPillow> I see :(

14:06 <CounterPillow> I'll clean up the script anyway and throw it in a gist or something

15:29 <amazingfate> hello, I'm trying to make linux-next kernel running on my rk3568 board, but my cpu and gpu can't get clk from scmi, and I have a log in dmesg: "arm-scmi firmware:scmi: SCMI protocol 20 not implemented". I find one commit is related: https://lore.kernel.org/all/20220330150551.2573938-6-cristian.marussi@arm.com/. Anyone knows about this issue?

15:35 <mriesch> amazingfate: is CONFIG_ARM_SCMI_PROTOCOL enabled in your config?

15:37 <amazingfate> mriesch, yes, it is enabled

15:39 <mriesch> amazingfate: what about COMMON_CLK_SCMI ?

15:46 <amazingfate> mriesch, that is also enabled

15:46 <amazingfate> I copied the kernel config from 5.17.x, and kernel 5.17.x works

15:46 <macc24> amazingfate: git bisect?

15:50 <amazingfate> there are a lot of scmi related code merged these days: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/firmware/arm_scmi?h=next-20220503

15:50 <amazingfate> But I don't know which commit causes this issue

15:51 <CounterPillow> that's what git bisect finds out :)

15:53 <amazingfate> ok, I will try sometimes to find it out

16:23 <robmur01> amazingfate: that suggests your firmware didn't actually advertise support for the clock protocol

16:30 <robmur01> First thing I'd try is enabling all the debug messages in the SCMI core and seeing how many protocols it's finding - quite possibly firmware is reporting something bogus that was masked by the hard-coded limit before