01:26 <naoki> otg port should not be host mode for ums and rockusb?

03:23 <naoki> Kwiboo: how do you think disabling non-working xhci as a workaround

04:07 <naoki> it's not good idea... :(

04:27 <naoki> oh, about ROCK 5B, lower USB3 port is driven by TYPEC1 controller, but it works as HOST mode only (I don't know why). since board rev. v1.46, lower USB3 port can be used as OTG/PERIPHERAL mode.

04:29 <naoki> but I think it's better to use same dts, i.e. lower USB3 port is HOST. Type-C (power) port is OTG port both old/new revision

04:30 <naoki> ^this is no relation to "USB host port(USB30_2) is not working on ROCK 5A/5B" issue

08:08 <qschulz> naoki: you could also patch the device tree if you can detect the board revision from HW and force it to host mode for old versions?

08:29 <Kwiboo> naoki: thanks, I will take a look and will try to send a new version of ROCK 3B series this weekend, if the board can work in dual role I think it should be marked as such, linux should have working dual-role if I am not mistaken

08:31 <Kwiboo> and for u-boot such port will work in peripheral mode and can then be used for ums and rockusb

08:37 <Kwiboo> will first try to finalize and get a 4k@60hz series out for rk3228/rk3328/rk3399/rk356x :-), https://github.com/Kwiboo/linux-rockchip/commits/next-20240531-rk-dw-hdmi/ should enable support for 4k@60hz on those socs

08:38 <CounterPillow> \o/

08:41 <diederik> \o/

08:41 <qschulz> ~o~

08:49 <Kwiboo> one thing I am not sure how to best handle is an issue on rk3399, where hdmi port typically gets paired with vopl and kernel kms client is not smart enough to try next crtc, result in no display for console

08:51 <Kwiboo> https://github.com/Kwiboo/linux-rockchip/compare/e9e882755a3c...b5b45eaceccc/ <<-- is one way, redefine ports to make vopb into crtc-0

08:54 <Kwiboo> another way could be to have board DTs /delete-node/ the vopl <-> hdmi endpoints defined in soc dtsi, for libreelec we just removed the vopl <-> hdmi connection entirely at soc dtsi

08:58 <mmind00> Kwiboo: though dt is not a config space ;-)

09:00 <CounterPillow> yeah which crtc kms console uses seems more like something people would want to put in their kernel command line?

09:02 <mmind00> also more generally, matching connections between hdmi <-> crtc to reach best utilization is a task for the drm subsystem, not some dt hacks

09:04 <naoki> there is an alias thing for ordering in dt...

09:04 <mmind00> also for rk3399 there is even more so the PLL issue for hdmi frequencies ... ChromeOS hacked up the clock tree so reserve one PLL for this, because while hdmi needs special frequencies, rk3399 doesn't have a dedicated PLL for this

09:09 <CounterPillow> I feel like I keep hearing of clock tree related hacks for rockchip things a lot, e.g. for rk356x we had to do some PLL shenanigans for DSI displays and video in general needing one clock set to critical. Is the upstream Linux clock framework just too primitive to model these complex sort of requirements?

09:10 <CounterPillow> (I sometimes wish there was a community-run project board to track reoccurring issues like this)

09:52 <naoki> https://github.com/RadxaNaoki/u-boot/commit/ae32afdfbbaf03abde89571fb1f6e748cb753409#diff-338acb1fb156e58ae338f5b9f20ef0ee704171cd067f7811dc5f567ea75e30b8R51-R52 <- braindead solution

09:52 <naoki> I forgot what I wanted to do...

10:04 <Kwiboo> mmind00: agree, I am not too happy with changing DT ports prop, will move the resolve order to code instead before sending patches

10:05 <qschulz> Kwiboo: https://source.denx.de/u-boot/u-boot/-/commit/12e07033c77d52a99682778e078ef63be619052d are you sure about ARMV8_SET_SMPEN in there?

10:06 <qschulz> Kwiboo: a35 isn't impacted by the limitation fixed by ARMV8_SET_SMPEN, at least it's not amongst the ones that are listed in the kconfig option help text

10:06 <qschulz> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_type=heads#L20-L36

10:09 <Kwiboo> mmind00: for rk3399 pll issue there is still same behavior/limitation as exists, driver does best effort to limit and set ref pll also dclk rate is fixup, at least 4k@60hz seem to work with current clock tree

10:10 <Kwiboo> for libreelec we also change / reserver vpll with a special pll rate table to get best use of hdmi on rk3399 (and rk3288)

10:13 <Kwiboo> qschulz: same bit was defined for a35 in https://developer.arm.com/documentation/100236/0100/register-descriptions/aarch64-system-registers/cpu-extended-control-register--el1?lang=en so I just added it for rk3308 even if it is not affected

10:19 <naoki> omg. I flashed spi.bin for 5a on 5b...

10:21 <qschulz> Kwiboo: ok, let's just play it safe I guess then :) thanks for the pointer

10:29 <robmur01> qschulz: if the patch adding that option existed downstream before its upstream merge date, then it quite possibly predates A35 entirely ;)

10:43 <robmur01> however I'd hope that on a sensible platform that particular thing is already taken care of: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/+/refs/heads/master/lib/cpus/aarch64/cortex_a35.S#45

10:45 <qschulz> robmur01: too late for SPL :)

10:56 <robmur01> heh, hence my qualification of "sensible"

16:55 <qschulz> Kwiboo: FYI, I think we could use an event in U-Boot that gets triggered before and after setting the regulator voltage, and we catch the event in the io-domain driver to adapt it properly

16:55 <qschulz> the benefit is that someone changing the regulator value after the io-domain is bound will work just fine now

16:55 <qschulz> and it would match the Linux kernel driver closer than what we currently have :)