lkml.org 
[lkml]   [2022]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] regmap: support regmap_field_write() on non-readable fields
On Tue, Jul 19, 2022 at 03:13:11PM +0200, Krzysztof Kozlowski wrote:
> On 19/07/2022 14:54, Charles Keepax wrote:

> > I think this will break other valid use-cases, regmap_readable (I
> > believe) returns if the register is physically readable, however
> > it should still be possible to use update bits if the register is
> > in the cache even if it can't physically be read. So really you
> > need to fall into this path if it is readable or in the cache.

> But what type of real use case this would be trying to solve? Either
> register is readable or not. The presence of cache is just optimization
> and does not change the fact that we cannot read from register thus no
> need to go via updates.

The original reason for creating the cache code was to simulate
readability on devices that have no read support at all (think 7x9
format I2C devices) so we can have things like helpers to map bitfields
directly to subsystems (like ASoC uses extensively). The fact that it
also improves performance when the hardware does support reads is nice
too of course.

> > Which does I guess also raise the question if your problem would
> > be better solved with caching the register?

> And how the value would appear in the cache? Since register cannot be
> read, I expect the cache to be filled on first update. First update
> would be read+write, so we are stuck again.

This is one reason we allow cache defaults to be specified (it was the
original reason, we later started using them to optimise out I/O during
resyncs).
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2022-07-19 16:16    [W:0.063 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site