linux-rockchip.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Adrian Ratiu <adrian.ratiu@collabora.com>
Cc: Fruehberger Peter <Peter.Fruehberger@de.bosch.com>,
	kernel@collabora.com, Philipp Zabel <p.zabel@pengutronix.de>,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	kuhanh.murugasen.krishnan@intel.com,
	Daniel Vetter <daniel@ffwll.ch>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 07/18] regmap: mmio: add config option to allow relaxed MMIO accesses
Date: Wed, 14 Oct 2020 13:12:49 +0100	[thread overview]
Message-ID: <20201014121249.GA4580@sirena.org.uk> (raw)
In-Reply-To: <87o8l581ql.fsf@collabora.com>


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

On Wed, Oct 14, 2020 at 02:51:14PM +0300, Adrian Ratiu wrote:
> On Tue, 13 Oct 2020, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Oct 12, 2020 at 11:59:46PM +0300, Adrian Ratiu wrote:

> > > -	writeb(val, ctx->regs + reg); +	if (ctx->relaxed_mmio) +
> > > writeb_relaxed(val, ctx->regs + reg); +	else + writeb(val, ctx->regs
> > > + reg);

> > There is no point in doing a conditional operation on every I/O, it'd be
> > better to register a different set of ops when doing relaxed I/O.

> Indeed I have considered adding new functions but went with this solution
> because it's easier for the users to only have to define a "relaxed" config
> then test the regmap ctx as above.

It seems like you've taken this in a direction other than what  I was
thinking of here - defining separate ops doesn't mean we have to do
anything which has any impact on the interface seen by users.  The
regmap config is supplied at registration time, it's just as available
then as it is when doing I/O.

> Thinking a bit more about it, yes, it makes more sense to have dedicated
> ops: this way users don't have to be explicit about adding membarriers and
> can combine relaxed and non-relaxed more easily, so it's also a better API
> trade-off in addition to avoiding the conditional. Thanks!

I'm not sure what you're proposing here - it does seem useful to be able
to combine relaxed and non-relaxed I/O but that seems like it'd break
down the abstraction for regmap since tht's not really a concept other
buses are going to have?  Unless we provide an operation to switch by
setting flags or somethin possibly and integrate it with the cache
perhaps.  Could you be a bit more specific about what you were thinking
of here please?

> Question: Do you want me to split this patch from the series and send it
> separately just for the regmap subsystem to be easier to review / apply?

Sure.

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

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

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2020-10-14 12:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12 20:59 [PATCH 00/18] Add Hantro regmap and VC8000 h264 decode support Adrian Ratiu
2020-10-12 20:59 ` [PATCH 01/18] media: hantro: document all int reg bits up to vc8000 Adrian Ratiu
2020-10-12 20:59 ` [PATCH 02/18] media: hantro: make consistent use of decimal register notation Adrian Ratiu
2020-10-12 20:59 ` [PATCH 03/18] media: hantro: make G1_REG_SOFT_RESET Rockchip specific Adrian Ratiu
2020-10-12 20:59 ` [PATCH 04/18] media: hantro: add reset controller support Adrian Ratiu
2020-10-13  8:11   ` Philipp Zabel
2020-10-12 20:59 ` [PATCH 05/18] media: hantro: prepare clocks before variant inits are run Adrian Ratiu
2020-10-12 20:59 ` [PATCH 06/18] media: hantro: imx8mq: simplify ctrlblk reset logic Adrian Ratiu
2020-10-12 20:59 ` [PATCH 07/18] regmap: mmio: add config option to allow relaxed MMIO accesses Adrian Ratiu
2020-10-13 10:26   ` Mark Brown
2020-10-14 11:51     ` Adrian Ratiu
2020-10-14 12:12       ` Mark Brown [this message]
2020-10-14 13:00         ` Adrian Ratiu
2020-10-12 20:59 ` [PATCH 08/18] media: hantro: add initial MMIO regmap infrastructure Adrian Ratiu
2020-10-12 20:59 ` [PATCH 09/18] media: hantro: default regmap to relaxed MMIO Adrian Ratiu
2020-10-12 20:59 ` [PATCH 10/18] media: hantro: convert G1 h264 decoder to regmap fields Adrian Ratiu
2020-10-12 20:59 ` [PATCH 11/18] media: hantro: convert G1 postproc to regmap Adrian Ratiu
2020-10-12 20:59 ` [PATCH 12/18] media: hantro: add VC8000D h264 decoding Adrian Ratiu
2020-10-12 20:59 ` [PATCH 13/18] media: hantro: add VC8000D postproc support Adrian Ratiu
2020-10-12 20:59 ` [PATCH 14/18] media: hantro: make PP enablement logic a bit smarter Adrian Ratiu
2020-10-12 20:59 ` [PATCH 15/18] media: hantro: add user-selectable, platform-selectable H264 High10 Adrian Ratiu
2020-10-12 20:59 ` [PATCH 16/18] media: hantro: rename h264_dec as it's not G1 specific anymore Adrian Ratiu
2020-10-12 20:59 ` [PATCH 17/18] media: hantro: add dump registers debug option before decode start Adrian Ratiu
2020-10-12 20:59 ` [PATCH 18/18] media: hantro: document encoder reg fields Adrian Ratiu
2020-10-12 23:39 ` [PATCH 00/18] Add Hantro regmap and VC8000 h264 decode support Jonas Karlman
2020-10-13  6:48   ` Adrian Ratiu
2020-10-29 12:38   ` Ezequiel Garcia
2020-10-29 16:21     ` Jonas Karlman
2020-11-03 15:27       ` Ezequiel Garcia
2020-10-29 13:07 ` Ezequiel Garcia
2020-10-29 14:15   ` Robin Murphy
2020-10-29 14:48     ` Mark Brown
2020-10-29 16:27     ` Ezequiel Garcia
2020-10-29 17:59       ` Mark Brown

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=20201014121249.GA4580@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Peter.Fruehberger@de.bosch.com \
    --cc=adrian.ratiu@collabora.com \
    --cc=daniel@ffwll.ch \
    --cc=ezequiel@collabora.com \
    --cc=kernel@collabora.com \
    --cc=kuhanh.murugasen.krishnan@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mchehab@kernel.org \
    --cc=p.zabel@pengutronix.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).