<dsimic>
the former is be correct, despite the latter still working
<dsimic>
naoki: ^^^
<dsimic>
s/is be/is/
<naoki>
dsimic: I see, thanks
<dsimic>
anytime :)
<naoki>
I remember there is vendor u-boot which supports rk3582...but dts is very different between vendor kernel and mainline kernel, I'm not sure vendor u-boot + mainline kernel on rk3582
<naoki>
works
System_Error has quit [Remote host closed the connection]
hexdump0815 has quit [Ping timeout: 276 seconds]
<dsimic>
perhaps Kwiboo tested that already
hexdump0815 has joined #linux-rockchip
System_Error has joined #linux-rockchip
ungeskriptet has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
ungeskriptet has joined #linux-rockchip
<naoki>
btw is anyone working ROCK 5B+? I'm thinking to get it
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
raster has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
Stat_headcrabbed has joined #linux-rockchip
<mmind00>
naoki: ideally you'd just create a shareable dtsi ... rock-5a _and_ rock-5c look pretty similar, so ideally would do similar to how other boards do it (see orangepi-5 and orangepi-5b for example)
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
warpme has joined #linux-rockchip
valpackett has quit [Remote host closed the connection]
<Kwiboo>
main question to resolve for rk3582 will be if we follow vendor u-boot policy for rk3582 or just disable the cores that are marked bad in OTP
<Kwiboo>
e.g. do we disable both cores in a big-core cluster even when only one of them is marked faulty, or force disable one of the big-core clusters when not cpu cores is marked faulty
valpackett has quit [Remote host closed the connection]
valpackett has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 272 seconds]
kevery1 is now known as kevery
valpackett has quit [Remote host closed the connection]
valpackett has joined #linux-rockchip
valpackett has quit [Remote host closed the connection]
valpackett has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
stikonas_ has quit [Quit: Konversation terminated!]
valpackett has quit [Remote host closed the connection]
valpackett has joined #linux-rockchip
valpackett has quit [Remote host closed the connection]
valpackett has joined #linux-rockchip
<dsimic>
Kwiboo: hmm, that's a good question
<dsimic>
perhaps it would be better to follow the vendor U-Boot policy and forcedly disable the entire clusters, but split the logic into two commits, so it's also possible to test the "follow the OTP strictly" policy
serdarth has quit [Read error: Connection reset by peer]
serdarth has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
<naoki>
mmind00: I'll check it
<mriesch>
naoki: my rock 5b+ has arrived but i haven't had the time to play with it
<mriesch>
i did make a diff between the downstream dts files and i guess a common dtsi is in order. but this is where i stopped :-)
<naoki>
mriesch: I need to wait ~2 week to get 5B+...
<naoki>
I have some things to do in 2 weeks :D
<mriesch>
naoki: have you been involved in the development of the 5b+ and/or its device tree?
<naoki>
mriesch: no, I never read downstream dts and schematic yet
<mriesch>
ah ok
naoki has quit [Quit: naoki]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
raster has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
dsimic has quit [Ping timeout: 244 seconds]
dsimic has joined #linux-rockchip
xha has quit [Quit: WeeChat 4.4.2]
xha has joined #linux-rockchip
raster has quit [Ping timeout: 252 seconds]
raster has joined #linux-rockchip
helene has quit [Remote host closed the connection]
helene has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
franoosh has joined #linux-rockchip
franoosh has quit [Remote host closed the connection]
linkmauve has left #linux-rockchip [Error from remote client]
<Kwiboo>
Linux seem to be happy just setting status=fail for the cpu nodes, however irq-gic-v3 driver should probably not WARN_ON for status=fail cores
<naoki>
Kwiboo: why it disable clusters and cores? I guess disable clusters is enough
<naoki>
Kwiboo: and, if both clusters are fine, disable cluster2
<Kwiboo>
the cluster handling code in Linux did not seem to support setting status=disabled on a cluster node when I tested last time, so some special care is needed, maybe setting status=fail will work
<Kwiboo>
yeah, it is not fully following all policy as vendor u-boot, some more parts is needed
<naoki>
I see
<naoki>
I'll try it, but my 5C lite is also "one big core mark as bad", I guess I got same result ;)
<naoki>
my E52C is "only gpu mark as bad"
<Kwiboo>
setting status=fail seem to work for cpu cores, however using status=disabled on cpu cores does not make the core be skipped in of_get_next_cpu_node() / for_each_of_cpu_node()
<Kwiboo>
cool, my tested 5C Lite has "bad-state: cpu core 4" and also have another one with only "bad-state: rkvdec core 1"
<Kwiboo>
if I remember correctly I also have a CM5 Lite that only had a bad rkvenc core
<Kwiboo>
did a quick test using "if (!of_device_is_available(cpu_node)) continue;" in gic_populate_ppi_partitions() and with that there was no need to update the "affinity" prop to avoid the WARN_ON splat
Stat_headcrabbed has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
stikonas has quit [Ping timeout: 252 seconds]
System_Error has quit [Remote host closed the connection]