mmind00 changed the topic of #linux-rockchip to: Rockchip development discussion | public log at https://libera.irclog.whitequark.org/linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
hexdump0815 has quit [Ping timeout: 265 seconds]
hexdump0815 has joined #linux-rockchip
Perflosopher038 has quit [Quit: The Lounge - https://thelounge.chat]
Perflosopher0387 has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
xha has quit [Quit: WeeChat 4.5.2]
ldevulder has joined #linux-rockchip
<qschulz> a3f: /chosen/bootsource should contain the full path to the node, so not sure why /soc/aliases would help with that?
<qschulz> and if we're talking a mapping from "what the bootrom returns as MMC1" and "what the path in the DT is for MMC1 based on /soc/aliases" we'll have a bad time, since I assume /soc/aliases is like /aliases and may not actually always represent the same controller on the board
<qschulz> e.g. we could have a board say mmc1 is sdmmc and another saying it's sdhci. This information is irrelevant to the mapping of which MMC controller was used by the BootROM to load the first stage?
eballetbo has joined #linux-rockchip
<Kwiboo> mmind00: I am working on pm domain for RK3528 and would like to avoid having to define a power domain as always-on, do you see any issue with allowing to define power-domains for gpio, i2c, saradc devices? see top commits from https://github.com/Kwiboo/linux-rockchip/commits/next-20250509-rk3528-gpu-pmdomain/
<Kwiboo> there is also one issue that I do not know how to handle properly: there is one clock related to ddrphy in the RK3528_PD_RKVDEC domain, without this domain enabled trying to read scmi_clk_ddr will result in a system reset/reboot :-/
<Kwiboo> my initial thought is just to skip declaring it in DT and push the issue until we have a rkvdec2 driver ready, or to declare it always-on
<mmind00> Kwiboo: the first thing to show is the strange association (VPU/VO for gpios and uarts), but that is part of the soc makeup I guess
<mmind00> Kwiboo: technically I don't have a problem with defining domains for those .... they are connected to the devices afterall
raster has joined #linux-rockchip
<Kwiboo> mmind00: agree, the clocks and domains are all over the place on rk3528, I was very supprised when I disabled the rkvenc domain and could not enable/disable regulators using gpio4 without a SError, not what I was expected
<Kwiboo> vendor kernel just flag all power domains as always-on, and the gpu power-domain is the only one that can be fully powered down, the reset just support putting into idle
<Kwiboo> I will prepare a proper series for this later
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
franoosh has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery has joined #linux-rockchip
kevery1 has quit [Ping timeout: 245 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
System_Error has quit [Remote host closed the connection]
kevery1 has joined #linux-rockchip
System_Error has joined #linux-rockchip
kevery has quit [Ping timeout: 272 seconds]
kevery1 is now known as kevery
ldevulder has quit [Ping timeout: 252 seconds]
dsimic has quit [Ping timeout: 265 seconds]
dsimic has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
<CounterPillow> Sounds like a delightful SoC, I was already despairing with the RK3576 non-idempotent PD toggles :D
stikonas has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
stikonas has quit [Read error: Connection reset by peer]
_whitelogger has joined #linux-rockchip
stikonas_ is now known as stikonas
valpackett has quit [Ping timeout: 276 seconds]
eballetbo has quit [Quit: Connection closed for inactivity]
franoosh has quit [Remote host closed the connection]
user21 has joined #linux-rockchip
<user21> working on getting NPU working for the rock 5b+ board under armbian https://www.armbian.com/rock-5b-plus
<user21> basically the right device tree to get the NPU working, this is based on the user space driver here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29698
<CounterPillow> armbian doesn't even have the tomeu rocket driver in the kernel though, does it?
<user21> no but there is a patch and I got it applied to the 6.14.5 kernel
<user21> but that patch has the device tree for quartzpro64
<user21> I'm still learning the kernel development and don't understand yet this commit https://gitlab.freedesktop.org/tomeu/linux/-/commit/a764c58bd0a1e87efab547bf46315f356adcbbf8
<user21> oh wow
<CounterPillow> should be quite similar for 5bp
<user21> so there is some effort for 5b already ?
<CounterPillow> yes
<user21> wow nice, that is literally where I spend last 3 weeks on, got it all merged and compiled user + kernel on 6.14.5
<user21> the device tree was missing, reached out to Tomeu as well for questions
<user21> nice
<user21> was the plan to merge this into mainline any time soon ? I was looking at 6.12 minimum, but the latest kernel the better