On Wed, 08 Aug 2018 13:07:06 +0200, Hans Hu(SH-RD) wrote: > > > > > > >Then the next step would be to fake sg-buffer from this > > > > > >straight buffer. Revert the above, and modify sgbuf.c to the following: > > > > > >- Allocate a large continuous buffer > > > > > >- Assign each page in this large buffer > > > > > > > > > > >If this still works, it's not about vmap, but it just means > > > > > >that the physically ordered pages do matter -- implicitly > > > > > >showing that the snooping behavior isn't properly turned on / off on the controller. > > > > > > > > > > To fake SG-buffer, I did this test: restore all the codes to the original, then added some codes in snd_malloc_sgbuf_pages() like below, the result is badly niose. > > > > > > > > >Not really what I meant. Rather something like below (totally untested). > > > > > > > > [Hans :] I know what you mean now and complete code like below, but the result is still noise. > > > > > > >OK, so indeed the vmapped address does seem matter. Interesting. > > > >What kind of user access does produce the noise? Does it via aplay mmap mode, too? > > > > > > >In anyway, if the vmap is a problem, it might be worked around a patch like below (again totally untested and not sure whether it's correct). > > > > > > [Hans :] As I know, In the hardware layer HDAC’s stream have two data transport path : non-snoop & snoop; In the software layer ALSA-Driver have two data transport path : mmap & not mmap(test shows, it is dependent on wav's format or mmap_flag in aplay.c). When hardware at non-snoop mode, without hardware module's help, software must mark the mem to uncacheable type: when mmap used, the mark action happened at pcm_mmap_prepare(), the not-mmap mode's mark action happened at __mark_pages_wc(). And when at not-mmap mode, the vmapped address directly used in snd_pcm_lib_write_transfer() -> copy_from_user(). > > > > > > >Well, that's usually no problem regarding that cache coherency. > > >At least it hasn't been any issue with Intel and AMD CPUs. > > >Does the problem happen with Intel CPU instead of VIA? > > > > [Hans :] I don't have enough Intel/AMD machine here, up to now, only find one Intel's : HW: mother board is Dell 042P49, HDA controller is 8086:1c20, codec is cx20641. > > >And the same issue is seen on that machine? > > [Hans :] Yes OK, then let's fix it properly. I managed to add the non-cached type buffer allocations in the memalloc.c, so that we can reduce lots of codes in each driver side. The patches are pushed to topic/memalloc-uc branch of my sound git tree. Please give it a try and report back whether it works for you. Since such a change in the core code would affect many drivers, I'll postpone this for 4.20, in anyway. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
