cyrozap has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
cyrozap has joined #linux-rockchip
SystemError has joined #linux-rockchip
SystemError has quit [Remote host closed the connection]
SystemError has joined #linux-rockchip
<Kwiboo>
qschulz: hehe, I can relate, did not really understand how I missed that much for rk3399, for other SoCs I tried to look up in TRM and how mainline and vendor drivers described the gpio banks
<qschulz>
it probably has some ramifications in drivers though... so I don't know yet what we should be doing exactly here :/
<qschulz>
especially since I assume changing the number of GPIOs is going to break sysfs
<qschulz>
(though admittedly one should have migrated to using libgpiod)
<qschulz>
(which is probably still impacted by "in-bank" numbering, however we want to handle it)
<qschulz>
e.g. maybe we should make every bank a multiple of 8, and each letter of each bank always have 8 GPIOs but mark the ones that do not exist as unrouted or something
<qschulz>
because even though we have less pins than anticipated, they seem to have the same expected layout
<qschulz>
(i.e. gpiox_n0 always start at bit0 in a register that follows gpiox_m0)
<qschulz>
with obviously some quirks like gpio0/1 being on PMU GRF and the rest on the "normal" GRF for the others (don't remember which SoC)
<Kwiboo>
yeah, it is a bit of a mess and a too drastic change may break abi, to my knowledge the normal gpio bank controllers support 32 pins, however some of the pins may not be routed
erg_ has quit [Read error: Connection reset by peer]
erg_ has joined #linux-rockchip
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #linux-rockchip
erg_ has quit [Read error: Connection reset by peer]
erg_ has joined #linux-rockchip
mripard has quit [Quit: mripard]
erg__ has joined #linux-rockchip
erg_ has quit [Ping timeout: 265 seconds]
warpme_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vagrantc has joined #linux-rockchip
Livio has joined #linux-rockchip
psydroid has joined #linux-rockchip
naoki has joined #linux-rockchip
<naoki>
hmm
<naoki>
good zzz...
<Kwiboo>
naoki: I did a quick test on a rock-3a and linux detected that sd-card was removed, but not re-inserted
<Kwiboo>
my understanding is that rk3582/rk3583 is just like rk3588s but with a few ip cores disabled, the question is how to describe this in DT, a new soc compatible?
<naoki>
as far as I can see, it's just a variant of rk3588(s)
<dsimic>
I think we need new SoC compatibles anyway
<dsimic>
which U-Boot may actually use to know when to apply the DT fixups
<dsimic>
I don't think we should bothr with the downstream DTs
<dsimic>
s/bothr/bother/
<Kwiboo>
maybe latest linux-5.10-gen-rkr8 and/or linux-6.1-stan-rkr3 sdk have some updated rkbin blobs?, I have only seen linux and u-boot leaked for those
<naoki>
I'm not sure vendor u-boot works with mainline DT ;)