_regmap_raw_write() contains code to call regcache_write() to write
values to the cache. That code calls memcpy() to copy the value data to
the start of the work_buf. However, at least when _regmap_raw_write() is
called from _regmap_bus_raw_write(), the value data is in the work_buf,
and this memcpy() operation may over-write part of that value data,
depending on the value of reg_bytes + pad_bytes. At least when using
reg_bytes==1 and pad_bytes==0, corruption of the value data does occur.
To solve this, remove the memcpy() operation, and modify the subsequent
.parse_val() call to parse the original value buffer directly.
At least in the case of 8-bit register address and 16-bit values, and
writes of single registers at a time, this memcpy-then-parse combination
used to cancel each-other out; for a work-buffer containing xx 89 03,
the memcpy changed it to 89 03 03, and the parse_val changed it back to
89 89 03, thus leaving the value uncorrupted. This appears completely
accidental though. Since commit 8a819ff "regmap: core: Split out in
place value parsing", .parse_val only returns the parsed value, and does
not modify the buffer, and hence does not (accidentally) undo the
corruption caused by memcpy(). This caused bogus values to get written
to HW, thus preventing e.g. audio playback on systems with a WM8903
CODEC. This patch fixes that.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This reverts commit bc8ce4 (regmap: don't corrupt work buffer in
_regmap_raw_write()) since it turns out that it can cause issues when
taken in isolation from the other changes in -next that lead to its
discovery. On the basis that nobody noticed the problems for quite some
time without that subsequent work let's drop it from v3.9.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Mainly useful internally but exported since this is a public API that's
being checked for.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This allows the cache to sync values directly to the device when stored
in native format and also allows asynchronous I/O.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
_regmap_raw_write() contains code to call regcache_write() to write
values to the cache. That code calls memcpy() to copy the value data to
the start of the work_buf. However, at least when _regmap_raw_write() is
called from _regmap_bus_raw_write(), the value data is in the work_buf,
and this memcpy() operation may over-write part of that value data,
depending on the value of reg_bytes + pad_bytes. At least when using
reg_bytes==1 and pad_bytes==0, corruption of the value data does occur.
To solve this, remove the memcpy() operation, and modify the subsequent
.parse_val() call to parse the original value buffer directly.
At least in the case of 8-bit register address and 16-bit values, and
writes of single registers at a time, this memcpy-then-parse combination
used to cancel each-other out; for a work-buffer containing xx 89 03,
the memcpy changed it to 89 03 03, and the parse_val changed it back to
89 89 03, thus leaving the value uncorrupted. This appears completely
accidental though. Since commit 8a819ff "regmap: core: Split out in
place value parsing", .parse_val only returns the parsed value, and does
not modify the buffer, and hence does not (accidentally) undo the
corruption caused by memcpy(). This caused bogus values to get written
to HW, thus preventing e.g. audio playback on systems with a WM8903
CODEC. This patch fixes that.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
In the rbtree code we are exposing statistics relating to the
number of nodes/registers of the rbtree cache for each of the
devices. Ensure that `map->debugfs' has been initialized before
we attempt to initialize the debugfs entry for the rbtree cache.
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
Currently the value parsing operations both return the parsed value and
modify the passed buffer. This precludes their use in places like the cache
code so split out the in place modification into a new parse_inplace()
operation.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Trace when we start and complete async writes, and when we start and
finish blocking for their completion. This is useful for performance
analysis of the resulting I/O patterns.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This fixes:
drivers/base/regmap/regmap.c: In function 'regmap_async_complete_cb':
drivers/base/regmap/regmap.c:1656:3: error: 'TASK_NORMAL' undeclared (first use in this function)
drivers/base/regmap/regmap.c:1656:3: note: each undeclared identifier is reported only once for each function it appears in
drivers/base/regmap/regmap.c: In function 'regmap_async_complete':
drivers/base/regmap/regmap.c:1688:2: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function)
drivers/base/regmap/regmap.c:1688:2: error: implicit declaration of function 'schedule'
An alternative might be to adjust linux/wait.h to include linux/sched.h,
but since that hasn't been done before, I assume we're consciously
avoiding doing that.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some use cases like firmware download can transfer a lot of data in quick
succession. With high speed buses these use cases can benefit from having
multiple transfers scheduled at once since this allows the bus to minimise
the delay between transfers.
Support this by adding regmap_raw_write_async(), allowing raw transfers to
be scheduled, and regmap_async_complete() to wait for them to finish.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This commit adds provision for "no-bus" usage of the regmap API. In
this configuration user can provide API with two callbacks 'reg_read'
and 'reg_write' which are to be called when reads and writes to one of
device's registers is performed. This is useful for devices that
expose registers but whose register access sequence does not fit the 'bus'
abstraction.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This commit is a preparatory commit to provide "no-bus" configuration
option for regmap API. It adds necessary plumbing needed to have the
ability to provide user define register write function.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This commit is a preparatory commit to provide "no-bus" configuration
option for regmap API. It adds necessary plumbing needed to have the
ability to provide user define register read function.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Since regmap already has support for formatting 24 bit wide values, so adding
support for 24 bit wide registers is pretty much straight forward.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Many of the regmap enabled drivers implementing one or more of the
readable, writeable, volatile and precious methods use the same code
pattern:
return ((reg >= X && reg <= Y) || (reg >= W && reg <= Z) || ...)
Switch to a data driven approach, using tables to describe
readable/writeable/volatile and precious registers ranges instead.
The table based check can still be overridden by passing the usual function
pointers via struct regmap_config.
Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This seems to be the most common way of reporting register numbers, it's
certainly what we do for trace.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
val_bytes is of 'size_t', so it should be printed as '%zu'.
Fixes the following build warning on x86:
drivers/base/regmap/regmap.c:872:4: warning: format '%d' expects argument of type 'int', but argument 5 has type 'size_t' [-Wformat]
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It is sometimes convenient for a regmap user to override the standard
regmap lock/unlock functions with custom functions.
For instance this can be useful in case an already existing spinlock
or mutex has to be used for locking a set of registers instead of the
internal regmap spinlock/mutex.
Note that the fast_io field of struct regmap_bus is ignored in case
custom locking functions are used.
Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Building regmap.o triggers this GCC warning:
drivers/base/regmap/regmap.c: In function ‘regmap_raw_read’:
drivers/base/regmap/regmap.c:1172:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Long story short: Jakub Jelinek pointed out that there is a type
mismatch between 'num' in regmap_volatile_range() and 'val_count' in
regmap_raw_read(). And indeed, converting 'num' to the type of
'val_count' (ie, size_t) makes this warning go away.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If a block write covers a paged memory region and crosses a window
boundary then rather than failing the write split the transfer up
into multiple writes, making the whole process more transparent for
drivers.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The range code was written to check for return codes less than zero as
errors but throughout the rest of the API return codes not equal to zero
are errors. Change all these checks to match the house style.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If a register range is named then provide a debugfs file showing the
contents of the range separately.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Rather than just returning a single error code for every possible thing we
can notice print an error message saying what the problem was. This makes
it very much easier to figure out what's wrong and fix it.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This makes things consistent with the rest of the API and is actually what
the documentation says. We don't currently have any in tree users so low
cost.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When bus->fast_io is set, the locking here is done with spinlocks.
This is currently true for the regmap-mmio bus implementation.
While holding a spinlock we can't go to sleep, various operations
like removing the debugfs entries or re-initializing the cache will
sleep, therefore, shift the locking up to the user.
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Sometimes for failures during very early init the trace infrastructure
isn't available early enough to be used. For this sort of problem
defining LOG_DEVICE will add printks for basic register I/O on a specific
device, allowing trace to be extracted when the trace system doesn't come
up early enough to work with.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
After page update, orginal work_buf has to be restored regardless of
the result.
Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Devices with register paging or indirectly accessed registers can configure
register mapping to map those on virtual address range. During access to
virtually mapped register range, indirect addressing is processed
automatically, in following steps:
1. selector for page or indirect register is updated (when needed);
2. register in data window is accessed.
Configuration should provide minimum and maximum register for virtual range,
details of selector field for page selection, minimum and maximum register of
data window for indirect access.
Virtual range registers are managed by cache as well as direct access
registers. In order to make indirect access more efficient, selector register
should be declared as non-volatile, if possible.
struct regmap_config is extended with the following:
struct regmap_range_cfg *ranges;
unsigned int n_ranges;
[Also reordered debugfs init to later on since the cleanup code was
conflicting with the new cleanup code for ranges anyway -- broonie]
Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Locks are moved to regmap_update_bits(), which allows to reenter internal
function _regmap_update_bits() from inside of regmap read/write routines.
Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The word to be transmitted/received via regmap is composed by the following
parts:
config->reg_bits
config->val_bits
config->pad_bits
,so the total size should be calculated by summing up the number of bits of
each element and using a DIV_ROUND_UP to return the number of bytes.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If debugfs isn't cleaned up, stale files will be left in the filesystem
which will cause an OOPS when accessed the first time, and hang the
accessing application when accessed again, presumably due to some lock
being left held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Add a field to struct regmap_bus that allows bus drivers to request that
register addresses and values be formatted with a specific endianness.
The default endianness is unchanged from current operation: Big.
Implement native endian formatting/parsing for 16- and 32-bit values.
This will be enough to support regmap-mmio.c.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This is a last minute bug fix that was only just noticed since the code
path that's being exercised here is one that is fairly rarely used. The
changelog for the change itself is extremely clear and the code itself
is obvious to inspection so should be pretty safe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJPqoQhAAoJEBus8iNuMP3dj1kP/0Z1yIk1ME0KzSy42/qbGKsp
+2mrAASkh7DbbWU2hSmwTpEgAAiY2ws0A/Uyj/Al4f/gJW6bZvlxK4mbf1i+P1LG
ab3ohhUOqexHVaIKMTnYKhnHWuzU25mnf2vW8IOr6jccu6h7X4orDmw1uEPVgsbs
P7fThQa0BPRkiLIUWGmg0oMY6IXJlzsStDK2Npw47EypY4FZCZucJgXkmYZLt0Nk
mhLPsznD5GqHNSmCqrUI3j/s3R0sd/Xc63pvznBU9D8RAbSRgi2vGL8UenEtIQgt
bVXOKe5H8ZzXYNYpzpGeJm3dTE2pZWmT1hfRSf0kBOkLhEpt/Oy9WBj1kfoTg9n9
fNH6OJYn12uG0qQomiAT96Qm3qrslF5y9S64ZyHT6BAkJT87wnEqTmaQkoAevDEr
hldzT+dTPAk2Pspge8m910+kQA72YyE1z6/PikvkEepYDFrqffZcBFWqjW8aQjGj
/5r7F5fLC7zJku0FjYUMRYDgYc9z0lk6tDt8QL7E7j+55ntrhYR8IuTQA7g2asal
yeQSTqa/NkJcch+aULgyOU0W9U1z2i04mdGI74iJnf3DSGGmvJ95IYLJA4tfnIOw
63xo2BhmHVGyRqTN5l7o5Zlgf5FdcUt+5EBLudSqqZynB/tMZNgb0PEzfIRFBuRq
GSIm5dwIqKgtymCEOUmp
=xcal
-----END PGP SIGNATURE-----
Merge tag 'regmap-3.4' into regmap-stride
regmap: Last minute bug fix for 3.4
This is a last minute bug fix that was only just noticed since the code
path that's being exercised here is one that is fairly rarely used. The
changelog for the change itself is extremely clear and the code itself
is obvious to inspection so should be pretty safe.
Conflicts:
drivers/base/regmap/regmap.c (overlap between the fix and stride code)
The function regmap_bulk_read() calls the regmap_read() for
each register if set of register has volatile and cache is
enabled. In this case, last few register read makes the memory
corruption if the register size is not the size of unsigned int.
The regam_read() takes argument as unsigned int for returning
value and it update the value as
*val = map->format.parse_val(map->work_buf);
This causes complete 4 bytes (size of unsigned int) to get written.
Now if client pass the memory pointer for value which is equal to the
required size of register count in regmap_bulk_read() then last few
register read actually update the memory beyond passed pointer size.
Avoid this by using local variable for read and then do memcpy()
for actual byte copy to passed pointer based on register size.
I allocated one pointer ptr and take first 16 bytes dump of that
pointer then call regmap_bulk_read() with pointer which is just
on top of this allocated pointer and register count of 128. Here
register size is 1 byte.
The memory trace of last 5 register read are as follows:
[ 5.438589] regmap_bulk_read after regamp_read() for register 122
[ 5.447421] 0xef993c20 0xef993c00 0x00000000 0x00000001
[ 5.467535] regmap_bulk_read after regamp_read() for register 123
[ 5.476374] 0xef993c20 0xef993c00 0x00000000 0x00000001
[ 5.496425] regmap_bulk_read after regamp_read() for register 124
[ 5.505260] 0xef993c20 0xef993c00 0x00000000 0x00000001
[ 5.525372] regmap_bulk_read after regamp_read() for register 125
[ 5.534205] 0xef993c00 0xef993c00 0x00000000 0x00000001
[ 5.554258] regmap_bulk_read after regamp_read() for register 126
[ 5.563100] 0xef990000 0xef993c00 0x00000000 0x00000001
[ 5.554258] regmap_bulk_read after regamp_read() for register 127
[ 5.587108] 0xef000000 0xef993c00 0x00000000 0x00000001
Here it is observed that the memory content at first word started changing
on last 3 regmap_read() and so corruption happened.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Use devres to implement dev_get_regmap(). This should mean that in almost
all cases devices wishing to take advantage of framework features based on
regmap shouldn't need to explicitly pass the regmap into the framework.
This simplifies device setup a bit.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Set the use_single_rw flag for devices that use format_write() since
format_write() doesn't support any form of block operation.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some devices does not support bulk read and write operations, for them
we have series of single write and read operations.
Signed-off-by: Anthony Olech <Anthony.Olech@diasemi.com>
Signed-off-by: Ashish Jangam <ashish.jangam@kpitcummins.com>
[Fixed coding style, don't check use_single_rw before assign --broonie ]
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If we don't have a cached value for a register and we can cache it then
when we do a read a value we should add it to the cache to save rereading
it later on. Do this for single register reads, for block reads the code
would be a little more complex and this covers most practical usage.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regmap_config.reg_stride is introduced. All extant register addresses
are a multiple of this value. Users of serial-oriented regmap busses will
typically set this to 1. Users of the MMIO regmap bus will typically set
this based on the value size of their registers, in bytes, so 4 for a
32-bit register.
Throughout the regmap code, actual register addresses are used. Wherever
the register address is used to index some array of values, the address
is divided by the stride to determine the index, or vice-versa. Error-
checking is added to all entry-points for register address data to ensure
that register addresses actually satisfy the specified stride. The MMIO
bus ensures that the specified stride is large enough for the register
size.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some devices have multiple separate register regions. Logically, one
regmap would be created per region. One issue that prevents this is that
each instance will attempt to create the same debugfs files. Avoid this
by allowing regmaps to be named, and use the name to construct the
debugfs directory name.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
val_len should be a multiple of val_bytes. If it's not, error out early.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some bus types have very fast IO. For these, acquiring a mutex for every
IO operation is a significant overhead. Allow busses to indicate their IO
is fast, and enhance regmap to use a spinlock for those busses.
[Currently limited to native endian registers -- broonie]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The only context needed by I2C and SPI bus definitions is the device
itself; this can be converted to an i2c_client or spi_device in order
to perform IO on the device. However, other bus types may need more
context in order to perform IO. Enable this by having regmap_init accept
a bus_context parameter, and pass this to all bus callbacks. The
existing callbacks simply pass the struct device here. Future bus types
may pass something else.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This change combines any padding bits into the register address bits when
determining register format handlers to use the next byte-divisible
register size.
A reg_shift member is introduced to the regmap struct to enable fixup
of the reg format.
Format handlers now take an extra parameter specifying the number of
bits to shift the value by.
Signed-off-by: Marc Reilly <marc@cpdesign.com.au>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Add support for devices with 24 data bits.
Signed-off-by: Marc Reilly <marc@cpdesign.com.au>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
[Fix for breakage which will be introduced during the merge window via
header reworks in another tree, the regmap tree does include device.h
but Paul's tree breaks that. Reworded subject to reflect -- broonie]
regmap.s uses devres_alloc() and others that are prototyped in device.h.
Include that to solve the following:
drivers/base/regmap/regmap.c: In function 'devm_regmap_init':
drivers/base/regmap/regmap.c:331:2: error: implicit declaration of function 'devres_alloc' [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap.c:338:3: error: implicit declaration of function 'devres_add' [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap.c:340:3: error: implicit declaration of function 'devres_free' [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap.c: In function '_regmap_raw_write':
drivers/base/regmap/regmap.c:421:5: error: implicit declaration of function 'dev_err' [-Werror=implicit-function-declaration]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Remove unused module.h and/or replace with export.h
as required.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Fall back to a register by register read to do so; most likely we'll be
cache only so the overhead will be low.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Generic infrastructure based on top of regmap may want to operate on
blocks of data and therefore find it useful to find the size of the
register values. Provide an accessor operation for this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The bulk_write() supports the data transfer to multi
register which takes the data into cpu_endianness format
and does formatting of data to device format before
sending to device.
The transfer can be completed in single transfer or multiple
transfer based on data formatting.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Adding support for caching of data into the
non-volatile register from the call of reg_raw_write().
This will allow the larger block of data write into multiple
register without worrying whether register is cached or not
through reg_raw_write().
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Save error handling and unwinding code in drivers by providing managed
versions of the regmap init functions, simplifying usage.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Using .format_write means, we have a custom function to write to the
chip, but not to read back. Also, mark registers as "not precious" and
"not volatile" which is implicit because we cannot read them. Make those
functions use 'regmap_readable' to reuse the checks done there.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
For the upcoming 2/6-format, we don't see debugfs output otherwise,
since the current division results in 0. I'd think 10/14 is broken
currently, too.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Most of the data exposed via debugfs is for or from the cache so reset
all the debugfs configuration to make sure everything is up to date with
the latest configuration, especially if we're changing cache type.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Device manufacturers frequently provide register sequences, usually not
fully documented, to be run at startup in order to provide better defaults
for devices (for example, improving performance in the light of silicon
evaluation). Support such updates by allowing drivers to register update
sets with the core. These updates will be written to the device immediately
and will also be rewritten when the cache is synced.
The assumption is that the reason for resyncing the cache will always be
that the device has been powered off. If this turns out to not be the case
then a separate operation can be provided.
Currently the implementation only allows a single set of updates to be
specified for a device, this could be extended in future.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When we reinitialise the cache make sure that we reset the cache access
flags, ensuring that the reinitialised cache is in the default state
which is what callers would and do expect given the function name.
This is particularly likely to cause issues in systems where there was no
cache previously as those systems have cache bypass enabled, as for the
wm8994 driver where this was noticed.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some devices, especially those with high speed control interfaces, require
padding between the register and the data. Support this in the regmap API
by providing a pad_bits configuration parameter.
Only devices with integer byte counts are supported.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Sometimes the register map information may change in ways that drivers can
discover at runtime. For example, new revisions of a device may add new
registers. Support runtime discovery by drivers by allowing the register
cache to be reinitialised with a new function regmap_reinit_cache() which
discards the existing cache and creates a new one.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some users of regmap_update_bits() would like to be able to tell their
users if they actually did an update so provide a variant which also
returns a flag indicating if an update took place. We could return a
tristate in the return value of regmap_update_bits() but this makes the
API more cumbersome to use and doesn't fit with the general zero for
success idiom we have.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If the new register value is identical to the original one then suppress
the write to the hardware in regmap_update_bits(), saving some I/O cost.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This patch adds support for 10 bits register, 14 bits value type register
formating. This is for example used by the Analog Devices AD5380.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
For some register format types we do not provide a parse_val so we can not do a
hardware read. But a cached read is still possible, so try to read from the
cache first, before checking whether a hardware read is possible. Otherwise the
cache becomes pretty useless for these register types.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Move the initialization regcache related fields of the regmap struct to
regcache_init. This allows us to keep regmap and regcache code better
separated.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The regmap_init documentation states that it will either return a pointer to a
valid regmap structure or a ERR_PTR in case of an error. Currently it returns a
NULL pointer in case no bus or no config was given. Since NULL is not a
ERR_PTR a caller might assume that it is a pointer to a valid regmap structure,
so return a ERR_PTR(-EINVAL) instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If regcache initialization fails regmap_init will currently exit without
freeing work_buf.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Commit 10a08d9f ("regmap: Support some block operations on cached devices")
allowed raw read operations without throwing a warning when using caches if
all registers are volatile. This patch does the same for raw write operations.
This is for example useful when loading a firmware in a predefined volatile
region on a chip where we otherwise want registers to be cached.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Mark Brown