All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Jonas Karlman <jonas@kwiboo.se>,
	Code Kipper <codekipper@gmail.com>,
	Linux-ALSA <alsa-devel@alsa-project.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	"Andrea Venturi (pers)" <be17068@iperbole.bo.it>,
	linux-sunxi <linux-sunxi@googlegroups.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [alsa-devel] [PATCH v3 1/9] ASoC: sun4i-i2s: Adjust regmap settings
Date: Wed, 9 Jan 2019 18:49:31 +0000	[thread overview]
Message-ID: <20190109184931.GK10405@sirena.org.uk> (raw)
In-Reply-To: <CAGb2v66q9NfgRGW=o-m2vYKyP=AJT9rx2A32iiwdGKuiGxWjYw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Sun, Dec 23, 2018 at 11:16:31AM +0800, Chen-Yu Tsai wrote:

> This sounds like the flush is happening after DMA transfers and/or I2S
> operations have started, disrupting the order of the audio samples. I
> think that might be the case since the regcache is synced sequentially,
> and the FIFO control register is after the enable bits. That would imply
> that the device is taken out of runtime suspend after the .start_capture
> or .start_playback callbacks. Not sure if that's the case, but that would
> mean the bus clocks are still off at this point, and bypassing the cache
> and updating the bits is basically moot.

I would expect that the device needs to be resumed from suspend before
we start actually trying to transfer audio - there is stuff in the ASoC
core which is supposed to have appropriate gets but it's possible
something is going wrong there.

> I think there's something else happening here, but we need to figure it
> out instead of papering over it with something that "just works" but
> we don't know why it works.

I agree.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
	"Andrea Venturi (pers)" <be17068@iperbole.bo.it>,
	Jonas Karlman <jonas@kwiboo.se>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Code Kipper <codekipper@gmail.com>,
	linux-sunxi <linux-sunxi@googlegroups.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 1/9] ASoC: sun4i-i2s: Adjust regmap settings
Date: Wed, 9 Jan 2019 18:49:31 +0000	[thread overview]
Message-ID: <20190109184931.GK10405@sirena.org.uk> (raw)
In-Reply-To: <CAGb2v66q9NfgRGW=o-m2vYKyP=AJT9rx2A32iiwdGKuiGxWjYw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1054 bytes --]

On Sun, Dec 23, 2018 at 11:16:31AM +0800, Chen-Yu Tsai wrote:

> This sounds like the flush is happening after DMA transfers and/or I2S
> operations have started, disrupting the order of the audio samples. I
> think that might be the case since the regcache is synced sequentially,
> and the FIFO control register is after the enable bits. That would imply
> that the device is taken out of runtime suspend after the .start_capture
> or .start_playback callbacks. Not sure if that's the case, but that would
> mean the bus clocks are still off at this point, and bypassing the cache
> and updating the bits is basically moot.

I would expect that the device needs to be resumed from suspend before
we start actually trying to transfer audio - there is stuff in the ASoC
core which is supposed to have appropriate gets but it's possible
something is going wrong there.

> I think there's something else happening here, but we need to figure it
> out instead of papering over it with something that "just works" but
> we don't know why it works.

I agree.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
	"Andrea Venturi \(pers\)" <be17068@iperbole.bo.it>,
	Jonas Karlman <jonas@kwiboo.se>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Code Kipper <codekipper@gmail.com>,
	linux-sunxi <linux-sunxi@googlegroups.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [alsa-devel] [PATCH v3 1/9] ASoC: sun4i-i2s: Adjust regmap settings
Date: Wed, 9 Jan 2019 18:49:31 +0000	[thread overview]
Message-ID: <20190109184931.GK10405@sirena.org.uk> (raw)
In-Reply-To: <CAGb2v66q9NfgRGW=o-m2vYKyP=AJT9rx2A32iiwdGKuiGxWjYw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1054 bytes --]

On Sun, Dec 23, 2018 at 11:16:31AM +0800, Chen-Yu Tsai wrote:

> This sounds like the flush is happening after DMA transfers and/or I2S
> operations have started, disrupting the order of the audio samples. I
> think that might be the case since the regcache is synced sequentially,
> and the FIFO control register is after the enable bits. That would imply
> that the device is taken out of runtime suspend after the .start_capture
> or .start_playback callbacks. Not sure if that's the case, but that would
> mean the bus clocks are still off at this point, and bypassing the cache
> and updating the bits is basically moot.

I would expect that the device needs to be resumed from suspend before
we start actually trying to transfer audio - there is stuff in the ASoC
core which is supposed to have appropriate gets but it's possible
something is going wrong there.

> I think there's something else happening here, but we need to figure it
> out instead of papering over it with something that "just works" but
> we don't know why it works.

I agree.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-09 18:49 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21 15:21 [PATCH v3 0/9] ASoC: sun4i-i2s: Updates to the driver codekipper
2018-12-21 15:21 ` codekipper
2018-12-21 15:21 ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 15:21 ` [PATCH v3 1/9] ASoC: sun4i-i2s: Adjust regmap settings codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 16:44   ` Chen-Yu Tsai
2018-12-21 16:44     ` Chen-Yu Tsai
2018-12-21 16:44     ` Chen-Yu Tsai
2018-12-22 22:12     ` [alsa-devel] " Jonas Karlman
2018-12-22 22:12       ` Jonas Karlman
2018-12-22 22:12       ` Jonas Karlman
2018-12-23  3:16       ` [alsa-devel] " Chen-Yu Tsai
2018-12-23  3:16         ` Chen-Yu Tsai
2018-12-23  3:16         ` Chen-Yu Tsai
2019-01-09 18:49         ` Mark Brown [this message]
2019-01-09 18:49           ` Mark Brown
2019-01-09 18:49           ` Mark Brown
2019-01-09 18:46     ` Mark Brown
2019-01-09 18:46       ` Mark Brown
2019-01-09 18:46       ` Mark Brown
2018-12-21 15:21 ` [PATCH v3 2/9] ASoC: sun4i-i2s: Add regmap field to sign extend sample codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 17:06   ` Chen-Yu Tsai
2018-12-21 17:06     ` Chen-Yu Tsai
2018-12-21 17:06     ` Chen-Yu Tsai
2018-12-21 15:21 ` [PATCH v3 3/9] ASoc: sun4i-i2s: Add 20, 24 and 32 bit support codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 16:48   ` Chen-Yu Tsai
2018-12-21 16:48     ` Chen-Yu Tsai
2018-12-21 16:48     ` Chen-Yu Tsai
2018-12-21 17:15     ` Chen-Yu Tsai
2018-12-21 17:15       ` Chen-Yu Tsai
2018-12-21 17:15       ` Chen-Yu Tsai
2018-12-21 15:21 ` [PATCH v3 4/9] ASoC: sun4i-i2s: Fix offset mask codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 16:54   ` Chen-Yu Tsai
2018-12-21 16:54     ` Chen-Yu Tsai
2018-12-21 16:54     ` Chen-Yu Tsai
2019-01-09 18:50     ` Mark Brown
2019-01-09 18:50       ` Mark Brown
2019-01-09 18:50       ` Mark Brown
2018-12-21 15:21 ` [PATCH v3 5/9] ASoC: sun4i-i2s: Correct divider calculations codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 15:21 ` [PATCH v3 6/9] ASoC: sun4i-i2s: Add multi-lane functionality codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 15:21 ` [PATCH v3 7/9] ASoC: sun4i-i2s: Do not divide clocks when slave codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 15:21 ` [PATCH v3 8/9] ASoC: sun4i-i2s: Add set_tdm_slot functionality codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w
2018-12-21 15:21 ` [PATCH v3 9/9] ASoC: sun4i-i2s: Add multichannel functionality codekipper
2018-12-21 15:21   ` codekipper
2018-12-21 15:21   ` codekipper-Re5JQEeQqe8AvxtiuMwx3w

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=20190109184931.GK10405@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=be17068@iperbole.bo.it \
    --cc=codekipper@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=wens@csie.org \
    /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.