<bjdooks>
hmm, whatever andes are doing to build uboot is causing (gcc?) to fail to build stack frames
oaken-source has joined #riscv
<bjdooks>
anyone understand how the -msave-restore works on riscv, and if so can stack frame support be added
<bjdooks>
or in fact if it is something uboot is actually using? i can't see to see anywhere it would get enabled
junaid_ has quit [Ping timeout: 268 seconds]
jacklsw has quit [Quit: Back to the real world]
junaid_ has joined #riscv
junaid__ has joined #riscv
random-jellyfish has joined #riscv
junaid__ has quit [Quit: leaving]
MaxGanzII has joined #riscv
Kedleston has quit [Read error: Connection reset by peer]
Kedleston has joined #riscv
Andre_Z has joined #riscv
PobodysNerfect has quit [Quit: Gone to sleep. ZZZzzz…]
PobodysNerfect has joined #riscv
elastic_dog has quit [Ping timeout: 265 seconds]
elastic_dog has joined #riscv
Tenkawa has joined #riscv
drmpeg has quit [Remote host closed the connection]
drmpeg has joined #riscv
Stat_headcrabed has joined #riscv
pedja has joined #riscv
BootLayer has quit [Quit: Leaving]
jay321 has joined #riscv
Armand has joined #riscv
<arnd>
prabhakar: sorry for not having gotten back to the dma-mapping series yet. I still want to finish this, but you may need to decouple the riscv bits first. Since I took out the function pointers from the series, I don't think there is a direct dependency any more.
<arnd>
you could take the riscv specific patches from my series as the base for your work though
<arnd>
just to ensure that the semantics you use match up with what I had in my series for the common version
Tenkawa has quit [Quit: Was I really ever here?]
junaid_ has quit [Remote host closed the connection]
<palmer>
arnd, prabhakar: FWIW, I'm fine with taking this sort of stuff into Linux -- sure it's ugly, but it's real HW so whatever
<arnd>
which approach was the last version? My feeling is that the least ugly variant is the one where we have function pointers for specific nonstandard CPU cores, with an fallback to the standard zicbom version and a __likely/__unlikely annotation to make that the predicted branch.
<palmer>
IIUC that's what Prabhakar's latest version was
flatmush has joined #riscv
<arnd>
ok, good. I think that should address any concerns about performance of the normal path, while also containing the complexity as much as possible, certainly less complex than using nested asm alternatives
<palmer>
OK, LMK if you want me to do anything -- Christoph is very much not in agreement
<palmer>
ya, but Christoph is smart so I'd like to at least understand what's up
<conchuod>
Last time it sounded like he abhorred the non-standard hardware
<palmer>
ya, I think everyone does
<palmer>
I think he's not in IRC? maybe we should just talk more on LMKL?
<arnd>
but the series he replied to still had the ALTERNATIVE_3 asm patching, which I think is just making it worse
<palmer>
ya, looks like it's all inline still. I must have been thinking of a different think
<palmer>
so I think if we add some sort of ALTERNATIVE_INLINE_OR_CALL, and then just hook up the non-standard flushing logic in C (for both Andes and T-Head) that'll be cleaner
<palmer>
not sure that changes the core "we don't want vendor stuff in Linux" argument, though?
<conchuod>
Correct me if I am wrong, but we went back the alternatives stuff arnd because Hellwig asked for it
<arnd>
but if he's going to nak it either way, I don't see how that helps
<palmer>
IIRC that was all function pointers, though? so with the patching we'd have the standard stuff inline and then a call for the non-standard stuff
<Stat_headcrabed>
Due to PMIC lacking enough power rails, SD shares vqmmc with other on-board peripherals at 3.3V, and that is the highest speed for SD spec on 3.3V
<mps>
Tenkawa: what kernel you use on visionfive v2
<Tenkawa>
6.3.6
<Stat_headcrabed>
But for emmc, there's a dedicated power rail for its vqmmc, and makes it possible to using 1.8V for higher speed(Needs correct regulator config in dts)
<mps>
from which url?
<Tenkawa>
mps: I'd have to go dig u p the bookmark.. its aurel32's