<drewfustini>
Anyone else with a Google Workspace email address (e.g. my @baylibre.com) having trouble with getting excessive bounce warnings from linux-riscv? It's been happening every couple weeks for me.
<bjoto>
conchuod: Hmm, PW NIPA hasn't picked up v16 of andyc's Vector work. Stuck?
<conchuod>
bjoto: I think it didn't finish whatever it was looking at yesterday, so had to redo that.
<conchuod>
Bjoto: At the current resource level, it takes several hours to do a 20 that ends up touching headers a bunch, so just ran out of time to get that done in parallel with testing fixes too
bauruine has joined #riscv
<conchuod>
I'd it doesn't get picked up today, I'll trigger it manually;(
MaxGanzII has quit [Remote host closed the connection]
<conchuod>
Esmil: are you happy with Hal's audio clock explanation?
<conchuod>
arnd: cool, thanks. I'll go have a poke i suppose!
sh1r4s3 has joined #riscv
enoq has joined #riscv
<prabhakarlad>
arnd: thank you, Ill give it a go after rebasing my previous series on top of this.
<arnd>
the arm32 portion of it turned out to be the hardest, and I suspect that rmk will object to some parts of it, because it reverts a cleanup he did in 2009
Molorius has joined #riscv
<arnd>
I did it so we can skip any particular architecture in case my changes turn out controversial
<arnd>
it's interesting how we handle 'invalidate' differently across architectures: arm32, arm64 and powerpc explicitly turn it into witeback+invalidate for partical cachelines, everyone else just invalidates it all without writeback
Molorius has quit [Ping timeout: 265 seconds]
<arnd>
riscv, csky, m68k arm64, and parisc always do the writeback before DMA_FROM_DEVICE, which also avoids this problem
Xyz has joined #riscv
Xyz has quit [Read error: Connection reset by peer]
jmdaemon has quit [Ping timeout: 240 seconds]
Molorius has joined #riscv
Molorius has quit [Ping timeout: 268 seconds]
<prabhakarlad>
arnd: previously for rz/five i had to skip the arch_dma_prep_coherent() callback. I will get to your patches later tonight but just wanted to check with you on this with your changes will should that work now seamlessly on risc-v for all platforms?
<prabhakarlad>
conchuod: for you non coherent platform do make use of arch_dma_prep_coherent() callback?
<prabhakarlad>
s/you/your
<prabhakarlad>
s/do/do you
ldevulder has quit [Ping timeout: 252 seconds]
brazuca has quit [Quit: Client closed]
Xyz has joined #riscv
Andre_Z has joined #riscv
Stat_headcrabed has joined #riscv
<arnd>
prabhakarlad: my patches only touch the bits for the streaming mapping API, so whatever you had for the coherent mapping API has not changed
<arnd>
prabhakarlad: it's possible that what you need here is CPU specific, but I don't know why architectures are actually different here
<arnd>
It's supposed to work like
<arnd>
- driver calls dma_alloc_coherent()
<arnd>
- kernel allocates normal memory, amps it as uncached to a new address but leaves the existing mapping
<arnd>
- arch_dma_prep_coherent() is called on the original mapping to flush any remaining cached copies back to the physical mapping
wiagn has joined #riscv
Stat_headcrabed has quit [Ping timeout: 264 seconds]
wiagn is now known as Stat_headcrabed
<arnd>
prabhakarlad: what happens if you don't skip it?
Molorius has joined #riscv
<conchuod>
prabhakarlad: I don't remember having to do any specific handling of it.
<prabhakarlad>
arnd: Ok thanks for pointer maybe ill add a CPU specific check. Previously when I tested it, if this callback wasn't skipped the DMA operation wasnt working (so basically high speed devices using dma weren't working)
<conchuod>
Were are mostly interested in the streaming API, fwiw
Xyz has quit [Ping timeout: 246 seconds]
<prabhakarlad>
conchuod: thanks for checking, so atm its just rz/five.
<conchuod>
I ended up liking how that looked a lot better, with the cache driver providing the, albeit identical, implementation for the individual ops
ldevulder has joined #riscv
joev has quit [Ping timeout: 276 seconds]
joev has joined #riscv
<prabhakarlad>
conchuod: "do everything" callback was the one which skipped the prep callback for me on rz/five.
<prabhakarlad>
maybe for now ill add the cpu check as per Arnd's suggestion and see how that will come up in v7.
<conchuod>
Well there's your answer about whether I skip it so!
<arnd>
prabhakarlad: if you add a CPU check, you should really have an explanation about why your CPU is different from the others when handing uncached memory