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

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

On Sat, Dec 22, 2018 at 12:44:07AM +0800, Chen-Yu Tsai wrote:
> On Fri, Dec 21, 2018 at 11:21 PM <codekipper@gmail.com> wrote:

> > +       regcache_cache_bypass(i2s->regmap, true);
> >         regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> >                            SUN4I_I2S_FIFO_CTRL_FLUSH_RX,
> >                            SUN4I_I2S_FIFO_CTRL_FLUSH_RX);
> > +       regcache_cache_bypass(i2s->regmap, false);

> IIRC the flush cache bit is self-clearing. So you likely want to mark
> this register as volatile. If it is marked as volatile, then all access
> to that register bypasses the cache, so the regcache_cache_bypass calls
> are unneeded.

Yes, that should be the case.

> However, looking at the code, the write would seem to be ignored if the
> regmap is in the cache_only state. We only set this when the bus clock
> is disabled. Under such a condition, bypassing the cache and forcing a
> write would be unwise, as the system either drops the write, or stalls
> altogether.

Right, access to a cache only register while the device is in cache only
mode is not a great idea - the usual reason we're in cache only mode is
that the device is in a state where I/O isn't going to work.  One thing
that can work for this if you need the register to be cached (but is a
bit gross) is to do a write setting the self clearing bit then another
immediately after resetting it back to the cleared state.  That works OK
for cases where the bit is a strobe and never retains state, though if
the device isn't operational then needing to write to the register might
indicate a bigger picture logic error (or it could be that the register
map mixes random things into one register).

[-- 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>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	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:46:04 +0000	[thread overview]
Message-ID: <20190109184604.GJ10405@sirena.org.uk> (raw)
In-Reply-To: <CAGb2v66-JmONW9AYqoSmifrEj+nstREdsbkcy9ECwnJ47zxARA@mail.gmail.com>


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

On Sat, Dec 22, 2018 at 12:44:07AM +0800, Chen-Yu Tsai wrote:
> On Fri, Dec 21, 2018 at 11:21 PM <codekipper@gmail.com> wrote:

> > +       regcache_cache_bypass(i2s->regmap, true);
> >         regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> >                            SUN4I_I2S_FIFO_CTRL_FLUSH_RX,
> >                            SUN4I_I2S_FIFO_CTRL_FLUSH_RX);
> > +       regcache_cache_bypass(i2s->regmap, false);

> IIRC the flush cache bit is self-clearing. So you likely want to mark
> this register as volatile. If it is marked as volatile, then all access
> to that register bypasses the cache, so the regcache_cache_bypass calls
> are unneeded.

Yes, that should be the case.

> However, looking at the code, the write would seem to be ignored if the
> regmap is in the cache_only state. We only set this when the bus clock
> is disabled. Under such a condition, bypassing the cache and forcing a
> write would be unwise, as the system either drops the write, or stalls
> altogether.

Right, access to a cache only register while the device is in cache only
mode is not a great idea - the usual reason we're in cache only mode is
that the device is in a state where I/O isn't going to work.  One thing
that can work for this if you need the register to be cached (but is a
bit gross) is to do a write setting the self clearing bit then another
immediately after resetting it back to the cleared state.  That works OK
for cases where the bit is a strobe and never retains state, though if
the device isn't operational then needing to write to the register might
indicate a bigger picture logic error (or it could be that the register
map mixes random things into one register).

[-- 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

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>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	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:46:04 +0000	[thread overview]
Message-ID: <20190109184604.GJ10405@sirena.org.uk> (raw)
In-Reply-To: <CAGb2v66-JmONW9AYqoSmifrEj+nstREdsbkcy9ECwnJ47zxARA@mail.gmail.com>


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

On Sat, Dec 22, 2018 at 12:44:07AM +0800, Chen-Yu Tsai wrote:
> On Fri, Dec 21, 2018 at 11:21 PM <codekipper@gmail.com> wrote:

> > +       regcache_cache_bypass(i2s->regmap, true);
> >         regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> >                            SUN4I_I2S_FIFO_CTRL_FLUSH_RX,
> >                            SUN4I_I2S_FIFO_CTRL_FLUSH_RX);
> > +       regcache_cache_bypass(i2s->regmap, false);

> IIRC the flush cache bit is self-clearing. So you likely want to mark
> this register as volatile. If it is marked as volatile, then all access
> to that register bypasses the cache, so the regcache_cache_bypass calls
> are unneeded.

Yes, that should be the case.

> However, looking at the code, the write would seem to be ignored if the
> regmap is in the cache_only state. We only set this when the bus clock
> is disabled. Under such a condition, bypassing the cache and forcing a
> write would be unwise, as the system either drops the write, or stalls
> altogether.

Right, access to a cache only register while the device is in cache only
mode is not a great idea - the usual reason we're in cache only mode is
that the device is in a state where I/O isn't going to work.  One thing
that can work for this if you need the register to be cached (but is a
bit gross) is to do a write setting the self clearing bit then another
immediately after resetting it back to the cleared state.  That works OK
for cases where the bit is a strobe and never retains state, though if
the device isn't operational then needing to write to the register might
indicate a bigger picture logic error (or it could be that the register
map mixes random things into one register).

[-- 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

  parent reply	other threads:[~2019-01-09 18:46 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
2019-01-09 18:49           ` Mark Brown
2019-01-09 18:49           ` Mark Brown
2019-01-09 18:46     ` Mark Brown [this message]
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=20190109184604.GJ10405@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=be17068@iperbole.bo.it \
    --cc=codekipper@gmail.com \
    --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.