[alsa-devel] [PATCH 0/6] Yet another experiments with LPE audio

Takashi Iwai tiwai at suse.de
Fri Feb 10 12:26:59 CET 2017


On Fri, 10 Feb 2017 09:06:14 +0100,
Ughreja, Rakesh A wrote:
> 
> >> >By using a generic dmix code with semaphore, this performance problem
> >> >is resolved.  So, S16/S32 supports are OK in the end.
> >> >
> >> >But this leads to another question wrt the kernel driver code:
> >> >why the driver allocates / maps with uncached page, not with write-
> >> >combined?  Pierre, Jerome, any clue?
> >> >
> >>
> >> In CHT and BYT the organization of the hardware fabric is such that
> >> the HDMI DMA transactions are not snooped and so it will fetch
> >> data only from DDR. In most non-atom platforms it is snooped, and so
> >> fabric will return data from cache if it is updated.
> >>
> >> In the past we faced problem where the DMA was fetching some
> >> old data because cache was not flushed into DDR. That's where
> >> we marked the pages as uncached.
> >
> >Thanks, that's my expectation.  The similar hacks are applied to some
> >audio platforms like AMD HDMI HD-audio.  But my question is about the
> >write-combined (WC) pages.  There are four modes about page caching:
> >write-back (WB), writhe-through (WT), write-combined (WC) and uncached
> >(UC).
> >
> >Usually WC is enough to work as uncached like the use case above, not
> >necessary to disable the whole cache via UC.  WC worked fine for
> >HD-audio, at least.  For LPE audio, is UC really stated as mandatory
> >requirement?
> >
> 
> No, as such there is no guidelines from HW guys.
> Technically WC would work as well. 
> 
> Question I have is, when we use the smaller period size with say 2 periods
> with WC, how do we ensure that the last write has been propagated to the
> main memory. Last write size may be smaller than the WC cache size.

A good question.  I vaguely remembered that it's rather cache align
size, but I might be wrong here.  It needs more check.

In anyway, WC cache can't help for dmix problem, as the dmix x86
implementation requires the read from the buffer, where the read on WC
page ends up with the total flushing.  So this can be postponed.


thanks,

Takashi


More information about the Alsa-devel mailing list