13:43 <yann> I'm working on getting kernel 5.10 run on a custom rk3399 board that's currently working with 4.4-rk. The video drivers appear to work fine (now that I picked a couple of patches from Vicente Bergas for QHD support), Xorg starts and xrandr reports realistic output, but the screen still reports no signal. Any hint about what I could be overlooking ?

18:14 <westernsemico> yann, which "display"? if it's displayport or HDMI, make sure /lib/firmware/rockchip/dtpx.bin exists; you should see a kernel message mentioning "dtpx.bin" when it gets loaded. Also make sure the module dw_hdmi is loaded (or the equivalent is compiled in statically).

18:14 <stikonas> westernsemico: HDMI doesn't need any firmware, does it?

18:15 <stikonas> westernsemico: I run rockpro64 fully blobless

18:15 <westernsemico> stikonas, yes, it does. There is a microcontroller inside the SoC displayport core. In fact, that is the only piece of non-free firmware needed for the entire chip on rk3399.

18:16 <westernsemico> rk3399 is blobless if you are willing to give up HDMI and DisplayPort. For a laptop that's certainly feasible.

18:16 <stikonas> westernsemico: I don't think I have any blobs, where is that blob located?

18:16 <westernsemico> Also you can do HDMI at up to 1080p without the firmware. It's just the higher resolutions which require later versions of HDMI/DP, which in turn require the microcontroller to negotiate things.

18:17 <westernsemico> stikonas, same place as all other firmware: /lib/firmware, unless you compiled your kernel to look somewhere else.

18:17 <stikonas> ok, yeah, that might explain why it only works for me up to 1080p...

18:17 <stikonas> westernsemico: I am on linux-libre kernel, so nothing there

18:17 <stikonas> but ok, that might explain why I needed 1080p screen...

18:17 <yann> westernsemico: it's HDMI

18:19 <westernsemico> stikonas, if you add /lib/firmware/dtpx.bin you might discover that higher resolutions suddenly "just work". I load that firmware on my rk3399-gru-kevin laptop when I need to give presentations. The built-in 2500x1600 panel is LVDS so it works without firmware. Really wish somebody else would sell a HiDPI rk3399 laptop. I had to stockpile a bunch of gru-kevins now that they're out of

18:19 <westernsemico> production.

18:19 <robmur01> HDMI works at 1920x1200 for me - that's above 1080p :P (and I did have to hack in a 154MHz pixel clock)

18:19 <westernsemico> yann, you'll also need dw_hdmi.ko

18:20 <yann> westernsemico: it's loaded, together with rockchipdrm

18:20 <westernsemico> yann, try using the kernel config from here as a starting point: https://github.com/eballetbo/linux/tree/topic/chromeos/somewhat-stable-5.10

18:20 <westernsemico> eballetbo is the supreme grandmaster ninja of rk3399

18:21 <yann> I have no log about loading dptx.bin, but then it may be because it's HDMI, right ?

18:22 <westernsemico> yann, the DP and HDMI support are somewhat intertwined/entangled. You definitely need dtpx.bin for either one.

18:22 <yann> possibly I need to add more dp-related stuff to the dts, then

18:23 <westernsemico> the SoC supports DP natively. For HDMI you need an adapter, but those are often included on the mainboard by the vendor. For HDMI-over-USBC often the USB-C chip has the appropriate circuitry built in. Anyways when displaying over HDMI a lot of parts of the chip will think they are using displayport. So don't be confused if you see lots of references to "displayport" when using HDMI.

18:24 <westernsemico> yann, did you remove anything?

18:24 <westernsemico> robmur01, sorry, you're right, 1920x1200 is the cutoff. Anything above that needs firmware.

18:25 <robmur01> Adapter? Wut? The SoC has the same native DesignWare HDMI controller/phy as half the market :/

18:25 <yann> since the original dts was so full of cruft, and starting without a clue of what dts changes might be required when going from 4.4-rk to 5.10-vanilla, I went the way of starting with nothing and picking bits one by one

18:26 <westernsemico> robmur01 does the SoC actually have HDMI pins? Not including the USB-C extcon.

18:27 <yann> that is, I started with mostly just including rk3399.dtsi and the PMU stuff

18:27 <robmur01> I was going to say yes instinctively, but after checking the datasheet, yes.

18:28 <westernsemico> yann, probably better to work from the other direction, leave in most of the stuff and remove the cruft bit by bit.

18:30 <yann> I'll dig the direction of bring the DP stuff back tomorrow, I'm a bit off-hours right now, real life is calling :) thx for the hints!

18:30 <robmur01> my board has the HDMI brought straight out on HDMI, and the DP muxed between type C and an eDP connector (the former of which doesn't work with mainline because of the type-c phy mess, and the latter of which I don't have, or particularly want, the special panel for)

18:32 <robmur01> now AFAIK the HDMI does have an HDCP block which mainline has never even gone near, and I guess might be needed for some of the HDMI 2.0 stuff

18:34 <westernsemico> robmur01, yes, you're right, HDMI PHY is on AK/AL[17:19]. The "HDMI only over DP" is a rk3399-gru-kevin-specific thing.

18:36 <westernsemico> I suspect that HDCP is a big part of the reason why there is a microcontroller in the DP/HDMI core in the first place. But unfortunately the dtpx.bin firmware is required for higher resolutions whether you're using HDCP or not.

23:07 <samueldr> hi, somewhat a cross-post from another channel:

23:07 <samueldr> is it likely that the CCD hardware on a chromebook "scarlet" tablet interferes with the ability to act as a gadget?

23:08 <samueldr> it's an OP1, basically a binned RK3399 with different bootrom AFAIUI

23:08 <samueldr> this is compared to an RK3399 device where the equivalent setup works (pbp)

23:08 <samueldr> gadget here means a usb gadget