On Mon, 16 Sep 2024 09:37:07 +0200, Christoph Hellwig wrote: > > On Mon, Sep 16, 2024 at 09:30:11AM +0200, Takashi Iwai wrote: > > On Mon, 16 Sep 2024 09:24:42 +0200, > > Christoph Hellwig wrote: > > > > > > On Mon, Sep 16, 2024 at 09:16:58AM +0200, Takashi Iwai wrote: > > > > Yes, all those are really ugly hacks and have been already removed for > > > > 6.12. Let's hope everything works as expected with it. > > > > > > The code currently in linux-next will not work as explained in my > > > previous mail, because it tries to side step the DMA API and abuses > > > get_dma_ops in an unsupported way. > > > > Those should have been removed since the last week. > > Could you check the today's linux-next tree? > > Ok, looks like the Thursday updates fix the dma_get_ops abuse. > > They introduce new bugs at least for architectures with virtuall > indexed caches by combining vmap and dma mappings without > mainintaining the cache coherency using the proper helpers. Yes, but it should be OK, as those functions are applied only for x86. Others should use noncontig DMA instead, if any. > What confuses my about this is the need to set the DMAable memory > to write combinable. How does that improve things over the default > writeback cached memory on x86? We could trivially add support for > WC mappings for cache coherent DMA, but someone needs to explain > how that actually makes sense first. It's required for a few sound hardware including some HD-audio controllers like old AMD graphics chips, at least. Most of other hardware work in PCI snooping with the default wb pages but those chips lead to either stuttering or silence. It seems that Windows uses wc or uc pages, hence they aren't designed to work in other way. thanks, Takashi
