From: Vinod Koul <vinod.koul@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"R, Dharageswari" <dharageswari.r@intel.com>,
Patches Audio <patches.audio@intel.com>,
"Shah, Hardik T" <hardik.t.shah@intel.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"Ughreja, Rakesh A" <rakesh.a.ughreja@intel.com>,
"Girdwood, Liam R" <liam.r.girdwood@intel.com>,
"Kp, Jeeja" <jeeja.kp@intel.com>
Subject: Re: [PATCH v2 09/11] ASoC: Intel: Skylake: Fix DMA position reporting for capture stream
Date: Mon, 27 Mar 2017 15:59:54 +0530 [thread overview]
Message-ID: <20170327102954.GM9308@localhost> (raw)
In-Reply-To: <85DFEED57DC57344B2483EF7BF8CB60552D1C563@BGSMSX104.gar.corp.intel.com>
On Sat, Mar 25, 2017 at 02:21:13AM +0530, Ughreja, Rakesh A wrote:
> >> >Are these workarounds needed for the legacy driver?
> >> >If yes, which chips require it?
> >> >
> >>
> >> Yes, these are needed in legacy driver as well.
> >> From SKL and BXT onwards, it is needed.
> >
> >OK, thanks for confirmation.
> >
> >Now, from what I read in the above, is the workaround required *only*
> >after the interrupt is generated? 20us delay isn't so cheap, and we
> >tend to inquire PCM positions often. If the workaround is needed only
> >after the PCM period elapse, we can set some flag in the irq handler
> >and apply the workaround only when necessary.
> >
>
> Yes, Takashi the workaround is required only in the period elapsed
> interrupt. In some cases the DMA Position updates are delayed and so
> when the period elapsed interrupt occurs the wait_for_avail thinks that
> one period worth of data is not available and so returns only on the
> next period elapsed interrupt. This creates problem for 2 periods
> playback/capture streams.
>
> So even in the period elapsed interrupt the wait is required only if the
> position is less than the period boundary.
Hi Takashi,
So we need this for 2 periods when the device is in irq mode. Not for other
cases. ie SKL_PLUS..
But have you seen any user reports on this till now.
--
~Vinod
next prev parent reply other threads:[~2017-03-27 10:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 17:40 [PATCH v2 00/11] ASoC: Intel: Skylake: More driver updates jeeja.kp
2017-03-24 17:40 ` [PATCH v2 01/11] ALSA: hda: Fix LLCH register read jeeja.kp
2017-03-24 18:37 ` Takashi Iwai
2017-03-24 17:40 ` [PATCH v2 02/11] ASoC: Intel: Skylake: Use the sig_bits to define dai bps capability jeeja.kp
2017-03-24 17:40 ` [PATCH v2 03/11] ASoC: hdac_hdmi: Update sig_bits based on converter capability jeeja.kp
2017-03-24 17:40 ` [PATCH v2 04/11] ASoC: Intel: Skylake: Add 16-bit constraint to FE bxt_rt298 machine jeeja.kp
2017-03-24 17:40 ` [PATCH v2 05/11] ASoC: Intel: Skylake: Don't unload module when in use jeeja.kp
2017-03-24 17:40 ` [PATCH v2 06/11] ASoC: Intel: Skylake: Remove redundant vmixer handler jeeja.kp
2017-03-24 17:40 ` [PATCH v2 07/11] ASoC: Intel: Skylake: remove hard coded ACPI path jeeja.kp
2017-03-24 17:40 ` [PATCH v2 08/11] ASoC: Intel: Skylake: Rearrangement of code to cleanup SKL SST library jeeja.kp
2017-03-24 17:40 ` [PATCH v2 09/11] ASoC: Intel: Skylake: Fix DMA position reporting for capture stream jeeja.kp
2017-03-24 18:38 ` Takashi Iwai
2017-03-24 18:43 ` Ughreja, Rakesh A
2017-03-24 18:49 ` Takashi Iwai
2017-03-24 20:51 ` Ughreja, Rakesh A
2017-03-27 10:29 ` Vinod Koul [this message]
2017-03-27 13:12 ` Takashi Iwai
2017-03-28 8:45 ` Vinod Koul
2017-03-29 11:54 ` Applied "ASoC: Intel: Skylake: Fix DMA position reporting for capture stream" to the asoc tree Mark Brown
2017-03-24 17:40 ` [PATCH v2 10/11] ASoC: Intel: Skylake: Fix module state after unbind and delete jeeja.kp
2017-03-24 17:40 ` [PATCH v2 11/11] ASoC: Intel: Skylake: Add support for deferred DSP module bind jeeja.kp
2017-03-27 10:31 ` [PATCH v2 00/11] ASoC: Intel: Skylake: More driver updates Vinod Koul
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=20170327102954.GM9308@localhost \
--to=vinod.koul@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dharageswari.r@intel.com \
--cc=hardik.t.shah@intel.com \
--cc=jeeja.kp@intel.com \
--cc=liam.r.girdwood@intel.com \
--cc=patches.audio@intel.com \
--cc=rakesh.a.ughreja@intel.com \
--cc=tiwai@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).