ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
stikonas has quit [Ping timeout: 244 seconds]
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
vagrantc has quit [Quit: leaving]
vagrantc has joined #linux-rockchip
vagrantc has quit [Client Quit]
amazingfate has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 258 seconds]
s1b1 has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #linux-rockchip
loki_val has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
stikonas has quit [Ping timeout: 258 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
mps has quit [Ping timeout: 276 seconds]
mps has joined #linux-rockchip
amazingfate_ has joined #linux-rockchip
amazingfate has quit [Ping timeout: 240 seconds]
kevery has quit [Ping timeout: 255 seconds]
indy_ has joined #linux-rockchip
indy has quit [Ping timeout: 248 seconds]
indy_ has quit [Ping timeout: 240 seconds]
indy has joined #linux-rockchip
warpme___ has joined #linux-rockchip
f476 has quit [Ping timeout: 258 seconds]
f476 has joined #linux-rockchip
kevery has joined #linux-rockchip
psydroid4 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
amazingfate has joined #linux-rockchip
amazingfate_ has quit [Ping timeout: 255 seconds]
psydroid4 has quit [Read error: Connection reset by peer]
psydroid2 has joined #linux-rockchip
vagrantc has joined #linux-rockchip
s1b1 has joined #linux-rockchip
<macromorgan> so I'm wanting to change the "simple-audio-card,name" from "Analog" to something else, possibly "Analog RK817" to match the Quartz64a board. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts?h=v5.18#n170
<macromorgan> does anyone have an issue with that or thoughts? The reason is that I need to specify a less-than-generic name in order to use alsa ucm rules
<diederik> Open an issue in the alsa-ucm-conf repo (on GH)? (https://lore.kernel.org/all/f7efde11-067d-8822-45fa-7cdbe2d17d93@perex.cz/) They probably could provide some useful input (unlike me)
f476 has quit [Ping timeout: 258 seconds]
<LinuxHackerman[m> Hi folks. I'm running mainline linux on a gru-bob chromebook (rk3399), and the screen just turned black. dmesg says:
<LinuxHackerman[m> Does anyone know if there's a way to recover from this?
f476 has joined #linux-rockchip
<macc24> ouch
<macc24> hmm
<macc24> -5 is -EIO
<macc24> input output error
<macc24> ugh my kevin is unavailable for testing
<macc24> hanetzer: do you have a bob?
<hanetzer> nah, just a kevin
<LinuxHackerman[m> I guess I'll just throw the gru patches from cadmium at my kernel and see if it makes everything better
<macc24> those patches are not really related
<LinuxHackerman[m> aww
<macc24> they are in cadmium sources to fix/workaround issue with kevin panel not refreshing randomly
<macc24> idk can't remember
<LinuxHackerman[m> ok
<LinuxHackerman[m> what's the thing to use on a gru nowadays firmware-wise? I'm using coreboot with u-boot as payload, but maybe that isn't the most sensible option?
stikonas has joined #linux-rockchip
<macc24> alpernebbi worked on that
<macc24> i currently just use stock boot firmware
lurchi__ is now known as lurchi_
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
lurchi_ is now known as lurchi__
<alpernebbi> LinuxHackerman[m: I use coreboot with u-boot payload as well, I got display stuff etc merged in by u-boot 2022.04 so you might want to refresh your build :D
<LinuxHackerman[m> oh nice
<LinuxHackerman[m> trying that just now, but it's not detecting the eMMC anymore...
<LinuxHackerman[m> wait no that was with 2021.10, just about to try 2022.04
<LinuxHackerman[m> Wow! It does work!
<LinuxHackerman[m> It's beautiful 🤩
<LinuxHackerman[m> and the eMMC regression from 2021.10 is fixed too, so it boots!
<LinuxHackerman[m> thanks for doing that alpernebbi!
<alpernebbi> np, glad things work on gru-bob as well :D
<LinuxHackerman[m> Hm. Now does anyone have suspend working on a gru of some description? I'm on mainline 5.17.9 right now and it just wakes up again instantly when I try to suspend
<LinuxHackerman[m> (which I guess is somewhat nice, because previously it would go to sleep and never wake up)
<LinuxHackerman[m> hm, same behaviour with both s2idle and deep sleep
<LinuxHackerman[m> oh but it no longer reboots :(
<LinuxHackerman[m> only cold boot seems to work
<alpernebbi> suspend seems to work on my gru-kevin
<LinuxHackerman[m> hm ok
<LinuxHackerman[m> what about rebooting?
<alpernebbi> yep, reboots fine as well
<LinuxHackerman[m> hm. For me it doesn't seem to get to u-boot on reboot
<LinuxHackerman[m> and then nothing
<mps> suspend and reboot works also on my gru-kevin
<LinuxHackerman[m> mps: what firmware are you using?
<LinuxHackerman[m> and which version of coreboot do you use alpernebbi ?
<mps> I use only u-boot from alpernebbi repo
<alpernebbi> LinuxHackerman[m: https://github.com/alpernebbi/u-boot/releases
<LinuxHackerman[m> so with SPL?
<alpernebbi> I have binaries for kevin/bob with u-boot-only/u-boot-with-coreboot
<LinuxHackerman[m> oh, can u-boot load itself without SPL on gru? Or is u-boot-only with SPL?
<alpernebbi> with SPL yes
<alpernebbi> I've been considering it part of u-boot, so...
<LinuxHackerman[m> fair enough :)
<LinuxHackerman[m> I guess I'll give your binaries a try, see if they work better
<LinuxHackerman[m> I'm guessing it won't make a difference for suspend, but hopefully they can reboot!
<alpernebbi> maybe it's something with the google tpm chip, idk
<LinuxHackerman[m> well it's rebooting fine with your u-boot spl build
<LinuxHackerman[m> I'll try with your coreboot build as well
<alpernebbi> u-boot spl build gets stuck at power off though
<LinuxHackerman[m> ok, your coreboot build behaves the same as mine, doesn't reboot
<LinuxHackerman[m> interesting
<LinuxHackerman[m> oh wait! It seems I was just too impatient
<LinuxHackerman[m> it hangs there for 15 seconds or something
<alpernebbi> hmmmmmmmmmm
<LinuxHackerman[m> ah, timeout
<LinuxHackerman[m> and it continues as usual
<LinuxHackerman[m> ... and this time it rebooted fine (with my build again)!?
<LinuxHackerman[m> need to go out briefly, I'll be back later
<alpernebbi> I'll probably go to sleep
<alpernebbi> but tpm is different between gru-kevin and gru-bob
<alpernebbi> it might need something special that isn't being done
<LinuxHackerman[m> So given that the reboot problem isn't that much of a problem... Does anyone know how I can get Linux to tell me what woke it back up from suspend?
Rathann has joined #linux-rockchip
psydroid2 has quit [Ping timeout: 240 seconds]
amazingfate_ has joined #linux-rockchip
amazingfate has quit [Ping timeout: 244 seconds]
<smaeul> you can try `cat /sys/power/pm_wakeup_irq` or /sys/kernel/debug/wakeup_sources, or you can compare /proc/interrupts before and after suspend
<smaeul> those first two files will only be updated if the IRQ that caused wakeup was one that Linux _expected_ to be the wakeup source