Create special function regmap_attach_dev
which can be called separately out of regmap_init.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

regmap_bulk_write() should decay to performing individual writes
if we're using a "no-bus" regmap. Unfortunately, it returns an
error because there is no map->bus pointer. Fix it.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@linaro.org>

regmap_bulk_read() should decay to performing individual reads if
we're using a "no-bus" regmap. Unfortunately, it returns an
error because there is no map->bus pointer. Fix it.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@linaro.org>

This patch give a warning when calling regmap_register_patch with
parameter num_regs <= 0.

When the num_regs parameter is zero and krealloc doesn't fail,
then the code would return an uninitialized value. However,
calling this function with num_regs == 0, would be a waste as it
essentially does nothing.

Signed-off-by: Cai Zhiyong <caizhiyong@huawei.com>
Reviewed-by: Geyslan G. Bem <geyslan@gmail.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Signed-off-by: Courtney Cavin <courtney.cavin@sonymobile.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

fix a trivial copy'n'paste error in the regmap kerneldoc, s/write/read/
for the regmap_read(), regmap_raw_read() and regmap_bulk_read() routines

Signed-off-by: Gerhard Sittig <gsi@denx.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Extend the interface for async I/O by allowing the value buffer to be
omitted and sending the value as part of the register buffer, minimising
the number of separate hardware operations required.

Signed-off-by: Mark Brown <broonie@linaro.org>

New API regmap_multi_reg_write() is defined that allows a set of reg,val
pairs to be written to a I2C client device as one block transfer from the
point of view of a single I2C master system.

A simple demonstration implementation is included that just splits the
block write request into a sequence of single register writes.

The implementation will be modified later to support those I2C clients
that implement the alternative non-standard MULTIWRITE block write mode
so to achieve a single I2C transfer that will be atomic even in multiple
I2C master systems.

Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: David Dajun Chen <david.chen@diasemi.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Try to speed up patch application a little using async I/O.

Signed-off-by: Mark Brown <broonie@linaro.org>

When regmap_bulk_write() is called with the map->use_single_rw flag set
an immediate mutex deadlock happens because regmap_raw_write() is called
after obtaining the mutex and regmap_raw_write() itself then tries to
obtain the mutex as well.

It is obvious that no one other than myself tried it with a real device.
I did, but only for the purposes of an experiment and demonstration.

But even if this situation will never ever happen with a real device, it
is a bug and therefore should be fixed.

Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Make it easier for drivers to include single register writes in
asynchronous sequences by providing async versions of the write
and update bits operations. The update bits operations are only
likely to be effective when used with devices that have caches
but this is common enough to be useful.

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>

Since it is quite common for single register raw or async writes to be
generated by rbtree cache syncs or firmware downloads and essentially all
hardware will be faster with only a single transfer optimise this case by
copying single values into the internal scratch buffer before sending.

Signed-off-by: Mark Brown <broonie@linaro.org>

Rather than allocating and deallocating the structures used to manage async
transfers each time we do one keep the structures around as long as the
regmap is around. This should provide a small performance improvement.

Signed-off-by: Mark Brown <broonie@linaro.org>

Current Linux kernel is supporting regmap_field method
and it is very useful feature.
It needs one regmap_filed for one register access.

OTOH, there is multi port device which
has many same registers in the market.
The difference for each register access is
only its address offset.

Current API needs many regmap_field for such device,
but it is not good.
This patch adds new regmap_fileds API which can care
about multi port/offset access via regmap.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Current regmap_field is supporting read/write functions.
This patch adds new update_bits function for it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

It may be useful to register multiple patches with regmap, for example
one that depends on the device revision and one that depends on the system
configuration. Add support for doing this, appending any new patches to
the existing patches.

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>

I see no reason why a virtual range shouldn't be allowed to cover its
own data window if the page selection register is in the same place
on every page.
For chips which use paged access for all of their registers, but only
when connected via I2C, and which can access the whole register space
directly when connected via SPI, this allows to avoid acrobatics with
the register ranges by simply mapping the I2C ranges over the data
window beginning at 0x0, and then using linear access for the SPI
variant.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Fix the following sparse warnings:

drivers/base/regmap/regmap.c:305:13: warning: context imbalance in 'regmap_lock_spinlock' - wrong count at exit
drivers/base/regmap/regmap.c:314:13: warning: context imbalance in 'regmap_unlock_spinlock' - unexpected unlock

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Commit f8bd822c ("regmap: cache: Factor out block sync") made
regcache_rbtree_sync() call regmap_async_complete(), which in turn does
not check for map->bus before dereferencing it.

This causes a NULL pointer dereference on bus-less maps.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Cc: stable@vger.kernel.org [v3.10 only]
Signed-off-by: Mark Brown <broonie@linaro.org>

It is common to access regmap registers at bit level, using
regmap_update_bits or regmap_read functions, however the end user has to
take care of a mask or shifting. This becomes overhead when such use
cases are high. Having a common function to do this is much convenient
and less error prone.

The idea of regmap_field is simple, regmap_field gives a logical
structure to bits of the regmap register, and the driver can use this
logical entity without the knowledge of the bit positions and masks all
over the code. This way code looks much neat and it need not handle the
masks, shifts every time it access the those entities.

With this new regmap_field_read/write apis the end user can setup a
regmap field using regmap_field_init and use the return regmap_field to
read write the register field without worrying about the masks or
shifts.

Also this apis will be useful for drivers which are based on regmaps,
like some clocks or pinctrls which can work on the regmap_fields
directly without having to worry about bit positions.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Currently all register maps with a cache need to provide a volatile
callback since the default is to assume all registers are volatile.
This is not sensible if we have a cache so change the default to be
fully cached if a cache is provided.

Signed-off-by: Mark Brown <broonie@linaro.org>

regmap-mmio uses a spinlock with spin_lock() and spin_unlock() for locking.
To be able to use the regmap API from different contexts (atomic vs non-atomic),
without the risk of race conditions, we need to use spin_lock_irqsave() and
spin_lock_irqrestore() instead. A new field, the spinlock_flags field, is added
to regmap struct to store the flags between regmap_{,un}lock_spinlock(). The
spinlock_flags field itself is also protected by the spinlock.

Thanks to Stephen Warren for the suggestion of this particular solution.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Allow drivers to use an access table as part of their implementation.

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 8a819ff8 "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>

Let's only write once...

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>

Don't grind to a screaming halt, just generate a warning.

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 8a819ff8 "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>

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

This fixes below build error when CONFIG_REGMAP=y && CONFIG_REGMAP_SPI=m

ERROR: "regmap_async_complete_cb" [drivers/base/regmap/regmap-spi.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Signed-off-by: Axel Lin <axel.lin@ingics.com>
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>