From: Takashi Iwai <tiwai@suse.de>
To: "Ughreja, Rakesh A" <rakesh.a.ughreja@intel.com>
Cc: Ian W MORRISON <ianwmorrison@gmail.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
"Anand, Jerome" <jerome.anand@intel.com>
Subject: Re: [PATCH 0/6] Yet another experiments with LPE audio
Date: Fri, 10 Feb 2017 12:26:59 +0100 [thread overview]
Message-ID: <s5hefz670cc.wl-tiwai@suse.de> (raw)
In-Reply-To: <85DFEED57DC57344B2483EF7BF8CB60552CD7498@BGSMSX104.gar.corp.intel.com>
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
prev parent reply other threads:[~2017-02-10 11:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 13:11 [PATCH 0/6] Yet another experiments with LPE audio Takashi Iwai
2017-02-07 13:11 ` [PATCH 1/6] ALSA: x86: Rearrange defines Takashi Iwai
2017-02-07 13:11 ` [PATCH 2/6] ALSA: x86: Support S32 format Takashi Iwai
2017-02-07 13:11 ` [PATCH 3/6] ALSA: x86: Support S16 format Takashi Iwai
2017-02-07 16:48 ` Pierre-Louis Bossart
2017-02-07 17:09 ` Takashi Iwai
2017-02-07 18:43 ` Pierre-Louis Bossart
2017-02-07 13:11 ` [PATCH 4/6] ALSA: x86: Don't pass SNDRV_PCM_INFO_BATCH flag Takashi Iwai
2017-02-07 13:11 ` [PATCH 5/6] ALSA: x86: Allow single period PCM operation Takashi Iwai
2017-02-07 13:11 ` [PATCH 6/6] ALSA: x86: Allow no-period-wakeup setup Takashi Iwai
2017-02-07 15:44 ` [PATCH 0/6] Yet another experiments with LPE audio Takashi Iwai
2017-02-09 19:29 ` Takashi Iwai
2017-02-10 3:01 ` Ughreja, Rakesh A
2017-02-10 7:19 ` Takashi Iwai
2017-02-10 8:06 ` Ughreja, Rakesh A
2017-02-10 11:26 ` Takashi Iwai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hefz670cc.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=ianwmorrison@gmail.com \
--cc=jerome.anand@intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rakesh.a.ughreja@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.