This patch merges regmap_field_update_bits() into macro
by using regmap_field_update_bits_base().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch merges regmap_field_write() into macro
by using regmap_field_update_bits_base().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch adds new regmap_field_update_bits_base() which is using
regmap_update_bits_base().
Current regmap_field_xxx() can be merged into it by macro.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Current regmap has many similar update functions like below,
but the difference is very few.
	regmap_update_bits()
	regmap_update_bits_async()
	regmap_update_bits_check()
	regmap_update_bits_check_async()
Furthermore, we can add *force* write option too in the future.

This patch merges regmap_update_bits_check_async() into macro
by using regmap_update_bits_base().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Current regmap has many similar update functions like below,
but the difference is very few.
	regmap_update_bits()
	regmap_update_bits_async()
	regmap_update_bits_check()
	regmap_update_bits_check_async()
Furthermore, we can add *force* write option too in the future.

This patch merges regmap_update_bits_check() into macro
by using regmap_update_bits_base().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Current regmap has many similar update functions like below,
but the difference is very few.
	regmap_update_bits()
	regmap_update_bits_async()
	regmap_update_bits_check()
	regmap_update_bits_check_async()
Furthermore, we can add *force* write option too in the future.

This patch merges regmap_update_bits_async() into macro
by using regmap_update_bits_base().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Current regmap has many similar update functions like below,
but the difference is very few.
	regmap_update_bits()
	regmap_update_bits_async()
	regmap_update_bits_check()
	regmap_update_bits_check_async()
Furthermore, we can add *force* write option too in the future.

This patch merges regmap_update_bits() into macro
by using regmap_update_bits_base().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Current regmap has many similar update functions like below,
but the difference is very few.
	regmap_update_bits()
	regmap_update_bits_async()
	regmap_update_bits_check()
	regmap_update_bits_check_async()
Furthermore, we can add *force* write option too in the future.

This patch adds new regmap_update_bits_base() which is feature
merged function. Above functions can be merged into it by macro.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The stride value should always equal to 2^n, so we can use bit
rotation instead of % to improve the performance.
Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This new code is unreachable.  Presumably there was supposed to be a
case statement there similar to the earlier code.

Fixes: afcc00b9 ('regmap: add 64-bit mode support')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We should cast these to 64bit so that we don't truncate away the high
bits.

Fixes: afcc00b9 ('regmap: add 64-bit mode support')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The variable 'u64 *u64' should be only visible on 64-BIT platform.
Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Since the mmio has support the 64-bit has been supported for the
64-bit platform, so should the regmap core too.
Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This commit allows installing a custom reg_update_bits function for cases where
the hardware provides a mechanism to set or clear register bits without a
read/modify/write cycle. Such is the case with the Microchip ENCX24J600.

If a custom reg_update_bits function is provided, it will only be used against
volatile registers.
Signed-off-by: NJon Ringle <jringle@gridpoint.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This reverts commit 7741c373.

This commit allows installing a custom reg_update_bits function for cases where
the hardware provides a mechanism to set or clear register bits without a
read/modify/write cycle. Such is the case with the Microchip ENCX24J600.
Signed-off-by: NJon Ringle <jringle@gridpoint.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If a regmap is using fast_io, allocate the scratch buffer in
regmap_bulk_write() with GFP_ATOMIC instead of GFP_KERNEL.
Otherwise we may schedule while atomic.
Reported-by: NAbhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

__regmap_init() may receive a NULL `struct regmap_bus *bus' pointer,
for example, from snd_hdac_regmap_init(), and it make sure that it
does not NULL deference `bus`, except around ->max_raw_read and
->max_raw_write initialisation. Add missing check.
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When doing a bulk read from a device which lacks raw I/O support we fall
back to doing register at a time reads but we still use the raw
formatters in order to render the data into the word size used by the
device (since bulk reads still operate on the device word size rather
than unsigned ints).  This means that devices without raw formatting
such as those that provide reg_read() are not supported.  Provide
handling for them by copying the values read into native endian values
of the appropriate size.
Signed-off-by: NMark Brown <broonie@kernel.org>

Check in regmap_raw_read() and regmap_raw_write() for correct maximum
sizes of the operations. Return -E2BIG if this size is not supported
because it is too big.

Also this patch causes an uninitialized variable warning so it
initializes ret (although not necessary).
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add functions to access the maximum size we can read/write using
regmap_raw_read/write().

This helps drivers that need to know how much they can write with the
raw functions without problems. There are some devices (e.g. bmc150)
that have fifos as registers which need to be read in specific chunks
otherwise samples are dropped.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

There are some buses which have a limit on the maximum number of bytes
that can be send/received. An example for this is
I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of more
than 32 bytes. The regmap_bulk operations should still be able to
utilize the full 32 bytes in this case.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

There is no multi_write support available if we cannot use raw_write.
This is the case if bus->write is not implemented.

This patch adds a condition that we need bus and bus->write so that
can_multi_write is true.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

use_single_rw currently reflects the capabilities of the connected
device. The capabilities of the bus are currently missing for this
variable.

As there are read only and write only buses we need seperate values for
use_single_rw to also reflect tha capabilities of the bus.

This patch splits use_single_rw into use_single_read and
use_single_write. The initialization is changed to check the
configuration for use_single_rw and to check the capabilities of the
used bus.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The regmap config does not prohibit val_bytes that are not powers of
two. But the current code of regmap_bulk_write for use_single_rw does
limit the possible val_bytes to 1, 2 and 4.

This patch fixes the behaviour to allow bus writes with non-standard
val_bytes sizes.

Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Return -ENOTSUPP if map->bus->read is not implemented and we do not use
the cache. This code path would directly use bus->read would run into an
NULL pointer for the read function.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

This function is missing a check if map->bus->write is implemented. If
it is not implemented arbitrary raw writes are not possible.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

There are two typos in drivers/base/regmap/regmap.c, and they may
introduce some noise when checking new patches.
Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

These values are defined as unsigned int in the struct and are assigned
to int values.

This patch fixes the type to be unsigned int instead.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Init functions defined in regmap*.c files are now prefixed with
__, take lockdep key and class parameters, and should not be
called directly: move the documentation to regmap.h, where the
macros are defined.
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Lockdep validator complains about recursive locking and deadlock
when two different regmap instances are called in a nested order.
That happens anytime a regmap read/write call needs to access
another regmap.

This is because, for performance reason, lockdep groups all locks
initialized by the same mutex_init() in the same lock class.
Therefore all regmap mutexes are in the same lock class, leading
to lockdep "nested locking" warnings if a regmap accesses another
regmap.

In general, it is impossible to establish in advance the hierarchy
of regmaps, so we make sure that each regmap init call initializes
its own static lock_class_key. This is done by wrapping all
regmap_init calls into macros.

This also allows us to give meaningful names to the lock_class_key.
For example, in rt5677 case, we have in /proc/lockdep_chains:
irq_context: 0
[ffffffc0018d2198] &dev->mutex
[ffffffc0018d2198] &dev->mutex
[ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock
[ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock
[ffffffc001b95448] &(&base->lock)->rlock

The above would have resulted in a lockdep recursive warning
previously. This is not the case anymore as the lockdep validator
now clearly identifies the 2 regmaps as separate.
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add an optional delay_us field in reg_sequence to allow the client to
specify a delay (in microseconds) to be applied after any given write
in a sequence of writes.

We treat a delay in a sequence the same way we treat a page change as
they are logically similar in that you can coalesce all write before
a delay (in the same way you can coalesce all writes before a page
change is needed)
Signed-off-by: NNariman Poushin <nariman@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Separate the functionality using sequences of register writes from the
functions that take register defaults. This change renames the arguments
in order to support the extension of reg_sequence to take an optional
delay to be applied after any given register in a sequence is written.
This avoids adding an int to all register defaults, which could
substantially increase memory usage for regmaps with large default tables.

This also updates all the clients of multi_reg_write/register_patch.
Signed-off-by: NNariman Poushin <nariman@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Zero length reads make no sense in a regmap context and are likely to
trigger bugs further down the stack so insert an error check, also
silencing compiler warnings about use of ret in cases where we iterate
per register.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently regmap requires that a reg_read callback is supplied, otherwise a
warning is emitted each time regmap_read() is called. This means a device
or bus without readback support needs to supply dummy reg_read callback.
Apart from that regmap_read() will still work fine if a cache is used.

Remove the warning and let regmap_readable() return false if not reg_read
callback is supplied. This means a device no longer has to supply a dummy
callback if it does not support readback and it also doesn't have to have a
readable_reg callback that always returns false since this is now implicit.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

regmap_fields_force_write() is similar to regmap_fields_write(),
but regmap_fields_force_write() write data to register even though
it is same value.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

regmap_write_bits() is similar to regmap_update_bits(),
but regmap_write_bits() write data to register even though
it is same value.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Sometimes we want to write data even though it doesn't change value.
Then, force_write option on _regmap_update_bits() helps this purpose.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The way the mask is generated in regmap_field_init() is wrong.
Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift
overflow while calculating the mask field.

On some 32 bits architectures, such as x86, the generated mask is 0,
instead of the expected 0xffffffff.

This patch uses GENMASK() to fix the problem, as this macro is already safe
regarding shift overflow.
Signed-off-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

In big endian mode regmap_bulk_read gives incorrect data
for byte reads.

This is because memcpy of a single byte from an address
after full word read gives different results when
endianness differs. ie. we get little-end in LE and big-end in BE.
Signed-off-by: NArun Chandran <achandran@mvista.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org