<ElBarto>
robmur01: that I know and I understand why using a gpio is prefered
<ElBarto>
robmur01: but there seems to be some weirness that lead to commit 10f595eedc22
<ElBarto>
robmur01: it seems that the internal cdetect wasn't usable on the nanopi4 and this lead to using a gpio
<ElBarto>
robmur01: I'm having a similar problem (granted on FreeBSD) where I cannot see any card as soon as I switch the cd pin to gpio function
<ElBarto>
robmur01: so I'm wondering if there is some register somewhere (like in grf) that needs tweaking if you want to use gpio or the internal cdetect
JohnDoe_71Rus has quit [Ping timeout: 248 seconds]
mrueg has joined #linux-rockchip
return0__ has joined #linux-rockchip
return0e has quit [Ping timeout: 245 seconds]
Kelsar_ is now known as Kelsar
indy_ is now known as indy
mrueg has quit [Read error: Connection reset by peer]
mrueg has joined #linux-rockchip
vagrantc has joined #linux-rockchip
ganbold has quit [Quit: Leaving...]
tuxd3v has joined #linux-rockchip
drrty has joined #linux-rockchip
drrty has quit [Remote host closed the connection]
drrty has joined #linux-rockchip
cyrozap has joined #linux-rockchip
vicencb has joined #linux-rockchip
mearon_ is now known as mearon
vicencb has quit [Read error: Connection reset by peer]
vicencb has joined #linux-rockchip
lopsided98_ has quit [Remote host closed the connection]
lopsided98 has joined #linux-rockchip
robmur01_ has joined #linux-rockchip
<robmur01_>
ElBarto: no weirdness as such, more just that I wrote that commit up before I'd fully figured things out
<ElBarto>
robmur01_: oh you're the one that made this commit ?
<ElBarto>
robmur01_: so did you find out why you couldn't have it working using the internal cdetect register ?
<robmur01_>
also sorry for conflating things yesterday - the I/O supply/floaty-pin thing was actually on 3288; on 3399 it's even simpler
stikonas has quit [Remote host closed the connection]
<robmur01_>
the MMC controller doesn't generate its native interrupt because the entire thing is shut off by an internal power domain
<robmur01_>
the downstream kernel/DTB simply never powers it down when idle, so didn't show the issue
<robmur01_>
as for the GPIO function for the same pin, as far as I'm aware it's no different from any other GPIO
<robmur01_>
other than IIRC that bank might be 1.8v only so probably doesn't have the IOVSEL faff
<ElBarto>
ok so that means that we have a bug somewhere in FreeBSD (which is what I've tried to track down for a while now)
<ElBarto>
I mean if there is no weird GRF register to setup if you use gpio or internal cd
stikonas has joined #linux-rockchip
<robmur01_>
other than the expected pinmux stuff to configure the GPIO input, not that I've seen
<ElBarto>
I know handle the io-domain stuff and set the IO_VSEL bit accordingly but it doesn't change a thing for me
<ElBarto>
maybe I still have a bug in my pinmux driver because as soon as I configure the cd pin as gpio I have a response timeout for CMD8 on the sd bus
<ElBarto>
anyway, thanks for your time, I'll dig more :)
<robmur01_>
oh BTW, which board?
<ElBarto>
rockpro64 with a custom dts
<ElBarto>
ganbold@freebsd (he's sometimes here) reported my the issue on the nanopc-t4
<ElBarto>
and I tried the same config on my rockpro64
<robmur01_>
Ok, so no wacky chromebook wiring, phew :)
<ElBarto>
nope, I don't have any chromebook, are they weird ?
<robmur01_>
and I can certainly vouch for nanopc-t4 working OK with linux :D
<ElBarto>
eheh :)
<robmur01_>
yeah, chromebooks wire CD to some other GPIO entirely to keep users far, far away from the automatic JTAG switching shenanigans
stikonas has quit [Remote host closed the connection]
<ElBarto>
ahah
<ElBarto>
ok I see
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]