Re: [PATCH 0/6] Yet another experiments with LPE audio

[Takashi Iwai <tiwai@suse.de>]

On Fri, 10 Feb 2017 04:01:21 +0100,
Ughreja, Rakesh A wrote:
> 
> 
> 
> >-----Original Message-----
> >From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-
> >project.org] On Behalf Of Takashi Iwai
> >Sent: Friday, February 10, 2017 12:59 AM
> >To: alsa-devel@alsa-project.org
> >Cc: Ian W MORRISON <ianwmorrison@gmail.com>; Pierre-Louis Bossart
> ><pierre-louis.bossart@linux.intel.com>; Anand, Jerome
> ><jerome.anand@intel.com>
> >Subject: Re: [alsa-devel] [PATCH 0/6] Yet another experiments with LPE audio
> >
> >On Tue, 07 Feb 2017 16:44:12 +0100,
> >Takashi Iwai wrote:
> >>
> >> On Tue, 07 Feb 2017 14:11:16 +0100,
> >> Takashi Iwai wrote:
> >> >
> >> > Another day, another patchset.  Here I put a largish cleanup patch to
> >> > just shuffle the code, in addition to the new S16 and S32 formats
> >> > support and the support for a single period with no period wakeup as
> >> > we've discussed in the previous thread.  One patch to remove BATCH
> >> > flag is same and kept in the middle of this series.
> >> >
> >> > I guess I can merge the first three patches now.
> >>
> >> It turned out that S16 and S32 causes xrun with dmix by some reason.
> >> Still investigating, but we can postpone these, too.
> >
> >And this gave some interesting result.  At first I thought this being
> >a bug in the kernel driver.  Then I found out that this is no kernel
> >driver bug but some performance problem of dmix code, appearing only
> >when accessing uncached pages on Cherrytrail.  (The same issue may
> >happen likely on other Atom platforms, but need to check.)
> >
> >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?


thanks,

Takashi