In the regcache_default_sync, if a register isn't writeable, then
_regmap_write will return an error and the rest of the sync will be
aborted. Avoid this by checking if a register is writeable before
trying to sync it.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
The default sync operation was still assuming a stride of one, fix it
to respect the reg_stride set in the map.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently, we check the registers in the patch are aligned to the
register stride everytime we sync the cache and the first time the patch
is written out is unchecked.
This patch checks the register patch when we first register it so the
first writes are no longer unchecked and then doesn't check on
subsequent syncs as the patch will be unchanged.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
regcache_sync_block_raw_flush takes the address of the base register
and the address of one past the last register to write to. "count" is
the number of registers in the range, not the number of bytes, it
should be (end addr - start addr) / stride. Without accounting for
strides greater than one, registers past the end might be synced or
the writeable_reg callback at the beginning of _regmap_raw_write will
fail and nothing will be written.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Try to speed up I/O a little by not synchronising until we are finished
scheduling writes. A brief survey of existing users suggests we have none
that would currently benefit from an async cache sync.
Signed-off-by: Mark Brown <broonie@linaro.org>
Rather than passing a flag around through the entire call stack store it
in the regmap struct and read it when required. This minimises the
visibility of the feature through the API, minimising the code updates
needed to use it more widely.
Signed-off-by: Mark Brown <broonie@linaro.org>
With devices which have a dense and small register map but placed at a large
offset the global cache_present bitmap imposes a huge memory overhead. Making
the cache_present per rbtree node avoids the issue and easily reduces the memory
footprint by a factor of ten. For devices with a more sparse map or without a
large base register offset the memory usage might increase slightly by a few
bytes, but not significantly. E.g. for a device which has ~50 registers at
offset 0x4000 the memory footprint of the register cache goes down form 2496
bytes to 175 bytes.
Moving the bitmap to a per node basis means that the handling of the bitmap is
now cache implementation specific and can no longer be managed by the core. The
regcache_sync_block() function is extended by a additional parameter so that the
cache implementation can tell the core which registers in the block are set and
which are not. The parameter is optional and if NULL the core assumes that all
registers are set. The rbtree cache also needs to implement its own drop
callback instead of relying on the core to handle this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
The regmap_writeable() check should not be done in
regcache_write() because this prevents read-only
registers to be cached. After a read on a read-only
register its value will not be stored in the cache
and the next time someone will try to read it the
value will be read from the bus instead of the
cache.
Instead the regmap_writeable() check should be done
in _regmap_write() to prevent callers from writing
to read-only registers.
Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
regcache_sync_block_raw_flush() expects the address of the register after last
register that needs to be synced as its parameter. But the last call to
regcache_sync_block_raw_flush() in regcache_sync_block_raw() passes the address
of the last register in the block. This effectively always skips over the last
register in a block, even if it needs to be synced. In order to fix it increase
the address by one register.
The issue was introduced in commit 75a5f89 ("regmap: cache: Write consecutive
registers in a single block write").
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
This can be used for cache types for which syncing values one by one is
equally efficient as syncing a range, such as the flat cache.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
The parameter passed to the regmap lock/unlock callbacks needs to be
map->lock_arg, regcache passes just map. This works fine in the case that no
custom locking callbacks are used, since in this case map->lock_arg equals map,
but will break when custom locking callbacks are used. The issue was introduced
in commit 0d4529c5 ("regmap: make lock/unlock functions customizable") and is
fixed by this patch.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Allow drivers to discard parts of the register cache, for example if part
of the hardware has been reset.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Fix format specifier in dev_dbg and suppress the following warning
drivers/base/regmap/regcache.c: In function
‘regcache_sync_block_raw_flush’:
drivers/base/regmap/regcache.c:593:2: warning: format ‘%d’ expects
argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat]
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regcache_sync_block_raw is used only in this file. Hence make it static.
Silences the following warning:
drivers/base/regmap/regcache.c:608:5: warning:
symbol 'regcache_sync_block_raw' was not declared. Should it be static?
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When syncing blocks of data using raw writes combine the writes into a
single block write, saving us bus overhead for setup, addressing and
teardown.
Currently the block write is done unconditionally as it is expected that
hardware which has a register format which can support raw writes will
support auto incrementing writes, this decision may need to be revised in
future.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
The idea of holding blocks of registers in device format is shared between
at least rbtree and lzo cache formats so split out the loop that does the
sync from the rbtree code so optimisations on it can be reused.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
The idea of maintaining a bitmap of present registers is something that
can usefully be used by other cache types that maintain blocks of cached
registers so move the code out of the rbtree cache and into the generic
regcache code.
Refactor the interface slightly as we go to wrap the set bit and enlarge
bitmap operations (since we never do one without the other) and make it
more robust for reads of uncached registers by bounds checking before we
look at the bitmap.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Provide a helper to do the size based index into a block of registers and
use it when reading a value.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It's more idiomatic to pass the map structure around and this means we
can use other bits of information from the map.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
While for I2C and SPI devices the overhead of using rbtree for devices with
only one block of registers is negligible the same isn't always going to
be true for MMIO devices where the I/O costs are very much lower. Cater
for these devices by adding a simple flat array type for them where the
lookups are simple array accesses, taking us right back to the original
ASoC cache implementation.
Thanks to Magnus Damm for the discussion which prompted this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
