[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201029175943.GE5042@sirena.org.uk>
Date: Thu, 29 Oct 2020 17:59:43 +0000
From: Mark Brown <broonie@...nel.org>
To: Ezequiel Garcia <ezequiel@...labora.com>
Cc: Robin Murphy <robin.murphy@....com>,
Adrian Ratiu <adrian.ratiu@...labora.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Fruehberger Peter <Peter.Fruehberger@...bosch.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
kuhanh.murugasen.krishnan@...el.com,
Daniel Vetter <daniel@...ll.ch>, kernel@...labora.com,
linux-media@...r.kernel.org
Subject: Re: [PATCH 00/18] Add Hantro regmap and VC8000 h264 decode support
On Thu, Oct 29, 2020 at 01:27:08PM -0300, Ezequiel Garcia wrote:
> On Thu, 2020-10-29 at 14:15 +0000, Robin Murphy wrote:
> > Or maybe the regmap API itself deserves extending with a "deferred"
> > operating mode where updates to the cached state can be separated from
> > committing that state to the underlying hardware.
> > ...which, after a brief code search out of curiosity, apparently already
> > exists in the form of regcache_cache_only()/regcache_sync(), so there's
> > probably no need to reinvent it :)
> To be fair, and despite it could seem an anti-pattern, this particular
> wheel is so tiny and trivial, that I'm starting to seriously consider
> reinventing it.
> I've been thinking long about this but just can't seem to see exactly
> what benefit we're getting from using MMIO regmaps here,
> as opposed to just a simple macro with an index, a mask, and an offset.
As a rule of thumb if you're not using a cache or fitting into some
other higher level framework stuff that uses regmap then I wouldn't
bother for MMIO devices.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists