Some irq controllers have writeonly/multipurpose register layouts. In
those cases we read invalid data back. Here we add the option
mask_writeonly as masking option.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The change makes possible to use regmap-irq interface within drivers
of simple interrupt controllers, which don't have an option to handle
different interrupt types and thus have one cell interrupt controllers
described in device tree bindings.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 2cbbb579bc ("regmap: Add the LZO cache support") added support
for LZO compression in regcache, but there were never any users added
afterwards. Since LZO support itself has its own size, it currently is
rather a deoptimization.
So make it optional by introducing a symbol that can be selected by
drivers wanting to make use of it.
Saves e.g. ~46 kB on MIPS (size of LZO support + regcache LZO code).
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Most of the kernel-doc comments in regmap don't actually generate
correctly. This patch fixes up a few common issues, corrects some typos
and adds some missing argument descriptions.
The most common issues being using a : after the function name which
causes the short description to not render correctly and not separating
the long and short descriptions of the function. There are quite a few
instances of arguments not being described or given the wrong name as
well.
This patch doesn't fixup functions/structures that are currently missing
descriptions.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 2cbbb579bc ("regmap: Add the LZO cache support") introduced
'blksize' in regcache_lzo_read() and regcache_lzo_write(), that is
set but not used. Compiling with W=1 gives the following warnings,
fix them.
drivers/base/regmap/regcache-lzo.c: In function ‘regcache_lzo_read’:
drivers/base/regmap/regcache-lzo.c:239:9: warning: variable ‘blksize’ set but not used [-Wunused-but-set-variable]
size_t blksize, tmp_dst_len;
^
drivers/base/regmap/regcache-lzo.c: In function ‘regcache_lzo_write’:
drivers/base/regmap/regcache-lzo.c:278:9: warning: variable ‘blksize’ set but not used [-Wunused-but-set-variable]
size_t blksize, tmp_dst_len;
^
These are harmless warnings and are only being fixed to reduce the
noise with W=1 in the kernel.
Fixes: 2cbbb579bc ("regmap: Add the LZO cache support")
Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
A fix for an issue with double locking that was introduced earlier this
release. I'd missed in review that we were already in a locked region
when trying to drop part of the cache.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJX5XcsAAoJECTWi3JdVIfQSfEH/iGoQHxcIyPeTBOk8XUIkmkJ
XgaQmZfj2RNKPbCug8KDhDks9qDL/w0/2DG00Trv6pVSFHyBKfX6AQEh0GgmYBJF
trsL1ai/F1dlUbrQaOGMkfUPSF3DvYRsM4/kJOxSruVYsK5PUk2zXEw9kPmquB57
K7IRru5KNDyH5p08h6jbm6po+0QhyaFnCi4iX5kqrvqPFWeP15KHfd+vuRNlWYt0
rf069yqHfZvPXDl6Alw+wdYskxDHT+hvmlWjIGVm1JwAmsx9V2QCDwrhBKG9aZW/
z+mdSKBSJ+RBIp7ucI8sSBm3JsxeSz4+teTe2DRZeGLJmnrZ6756xSNR0pphoAM=
=yYvs
-----END PGP SIGNATURE-----
Merge tag 'regmap-fix-v4.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fix from Mark Brown:
"A fix for an issue with double locking that was introduced earlier
this release. I'd missed in review that we were already in a locked
region when trying to drop part of the cache"
* tag 'regmap-fix-v4.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: fix deadlock on _regmap_raw_write() error path
Commit 815806e39b ("regmap: drop cache if the bus transfer error")
added a call to regcache_drop_region() to error path in
_regmap_raw_write(). However that path runs with regmap lock taken,
and regcache_drop_region() tries to re-take it, causing a deadlock.
Fix that by calling map->cache_ops->drop() directly.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This with the longer read and write masks allow supporting more
exotic devices. For example a little endian SPI device:
static const struct regmap_config foo_regmap_config = {
.reg_bits = 16,
.reg_stride = 4,
.val_bits = 16,
.write_flag_mask = 0x8000,
.reg_format_endian = REGMAP_ENDIAN_LITTLE,
.val_format_endian = REGMAP_ENDIAN_LITTLE,
...
};
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We currently only support masking the top bit for read and write
flags. Let's make the mask unsigned long and mask the bytes based
on the configured register length to make things more generic.
This allows using regmap for more exotic combinations like SPI
devices that need little endian addressing.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap_write
->_regmap_raw_write
-->regcache_write first and than use map->bus->write to wirte i2c or spi
But if the i2c or spi transfer failed, But the cache is updated, So if I use
regmap_read will get the cache data which is not the real register value.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for dumping write only device registers in debugfs. This is
useful for audio codecs that have write only registers (like WM8731).
The logic that decides if a value can be printed is moved to
regmap_printable() function to allow for easier future updates.
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a function to check if a regmap register is cached. This will be used
in debugfs to dump the cached values of write only registers.
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When searching for a suitable node that should be used for inserting a new
register, which does not fall within the range of any existing node, we not
only looks for nodes which are directly adjacent to the new register, but
for nodes within a certain proximity. This is done to avoid creating lots
of small nodes with just a few registers spacing in between, which would
increase memory usage as well as tree traversal time.
This means there might be multiple node candidates which fall within the
proximity range of the new register. If we choose the first node we
encounter, under certain register insertion patterns it is possible to end
up with overlapping ranges. This will break order in the rbtree and can
cause the cached register value to become corrupted.
E.g. take the simplified example where the proximity range is 2 and the
register insertion sequence is 1, 4, 2, 3, 5.
* Insert of register 1 creates a new node, this is the root of the rbtree
* Insert of register 4 creates a new node, which is inserted to the right
of the root.
* Insert of register 2 gets inserted to the first node
* Insert of register 3 gets inserted to the first node
* Insert of register 5 also gets inserted into the first node since
this is the first node encountered and it is within the proximity range.
Now there are two overlapping nodes.
To avoid this always choose the node that is closest to the new register.
This will ensure that nodes will not overlap. The tree traversal is still
done as a binary search, we just don't stop at the first node found. So the
complexity of the algorithm stays within the same order.
Ideally if a new register is in the range of two adjacent blocks those
blocks should be merged, but that is a much more invasive change and left
for later.
The issue was initially introduced in commit 472fdec738 ("regmap: rbtree:
Reduce number of nodes, take 2"), but became much more exposed by commit
6399aea629 ("regmap: rbtree: When adding a reg do a bsearch for target
node") which changed the order in which nodes are looked-up.
Fixes: 6399aea629 ("regmap: rbtree: When adding a reg do a bsearch for target node")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
In 3245d460 (regmap: cache: Fall back to register by register read for
cache defaults) non-readable registers are skipped when initializing
reg_defaults, but are still included in num_reg_defaults. So there can
be uninitialized entries at the end of reg_defaults, which can cause
problems when the register cache initializes from the full array.
Fixed it by excluding non-readable registers from the count as well.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When doing a bulk writes 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.
This complements commit d5b98eb124 ("regmap: Support bulk reads for
devices without raw formatting").
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Chips with 16-bit registers don't usually work well with I2C block
commands. For example, neither the LM75 datasheet nor the TMP102 datasheet
mentions block command support, and in fact it does not work for any of
those chips. Also, it is not clear how the block command would handle
16-bit SMBus operations in the fist place, since the data format associated
with those commands is either little endian or big endian, which requires
some kind of conversion to or from host byte order.
Only use i2c block commands if both register and value width is 8 bit.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Regmap irq implements the generic interrupt service routine which
is common for most of devices. Some devices, like MAX77620, MAX20024
needs the special handling before and after servicing the interrupt
as generic. For the example, MAX77620 programming guidelines for
interrupt servicing says:
1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting
GLBLM.
2. Read IRQTOP and service the interrupt accordingly.
3. Once all interrupts has been checked and serviced, the interrupt
service routine un-masks the hardware interrupt line by clearing
GLBLM.
The step (2) is implemented in regmap irq as generic routine. For
step (1) and (3), add callbacks from regmap irq to client driver
to handle chip specific configurations.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Specifically for the case of reads that use the Extended Register
Read Long command, a multi-byte read operation is broken up into
8-byte chunks. However the call to spmi_ext_register_readl() is
incorrectly passing 'val_size', which if greater than 8 will
always fail. The argument should instead be 'len'.
Fixes: c9afbb05a9 ("regmap: spmi: support base and extended register spaces")
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Otherwise the DT parsing will default to big endian if nothing is
specified.
Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since we changed to do formatting in the bus we now skip all the format
parsing that the core does for its data marshalling code. This means
that we skip the DT parsing it does which breaks some systems, we need
to add an explict call in the MMIO code to do this.
Reported-by: Alexander Stein <alexander.stein@systec-electronic.com>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
internal.h is using dev_name() but doesn't include device.h which
defines it. Add an explicit include to avoid build problems due to
this.
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If max_register is unset, regcache_flat_get_index will return 0 and only
memory for 1 unsigned int will be allocated, resulting in writing out
of bounds.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Setting the flag 'cache_bypass' will bypass the cache not the hardware.
Fix this comment here.
Fixes: 0eef6b0415 ("regmap: Fix doc comment")
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently when selecting value endianness we check the register
endiannes, not the value endianness.
Reported-by: Alexander Stein <alexander.stein@systec-electronic.com>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add device managed APIs for regmap_add_irq_chip() and
regmap_del_irq_chip() so that it can be managed by
device framework for freeing it.
This helps on following:
1. Maintaining the sequence of resource allocation and deallocation
regmap_add_irq_chip(&d);
devm_requested_threaded_irq(virq)
On free path:
regmap_del_irq_chip(d);
and then removing the irq registration.
On this case, regmap irq is deleted before the irq is free.
This force to use normal irq registration.
By using devm apis, the sequence can be maintain properly:
devm_regmap_add_irq_chip(&d);
devm_requested_threaded_irq(virq);
and resource deallocation will be done in reverse order
by device framework.
2. No need to delete the regmap_irq_chip in error path or remove
callback and hence there is less code on this path.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 23b92e4cf5fd ("regmap: remove regmap_write_bits()")
removed regmap_write_bits(), but MFD driver was using it.
So, commit e30fccd6771d ("regmap: Keep regmap_write_bits()")
turns out it, but it is using original style.
This patch uses regmap_update_bits_base() for regmap_write_bits()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When nested interrupts are handled with regmap irq framework, we need to
mark the interrupts to be resend for pending interrupts on enable_irq.
Else the events might be lost for nested irqs.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch merges regmap_fields_update_bits() into macro
by using regmap_field_update_bits_base().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch merges regmap_fields_write() into macro
by using regmap_fields_update_bits_base().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds new regmap_fields_update_bits_base() which is using
regmap_update_bits_base().
Current regmap_fields_xxx() can be merged into it by macro.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch merges regmap_field_update_bits() into macro
by using regmap_field_update_bits_base().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch merges regmap_field_write() into macro
by using regmap_field_update_bits_base().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Here we introduce regcache_flat_get_index(), which using register
stride order and bit rotation, will save some memory spaces for
flat cache. Though this will also lost some access performance,
since the bit rotation is used to get the index of the cache array,
and this could be ingored for memory I/O accessing.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Here introduces regcache_get_index_by_order() for regmap cache,
which uses the register stride order and bit rotation, to improve
the performance.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the register stride should always equal to 2^N, and bit rotation is
much faster than multiplication and division. So introducing the stride
order and using bit rotation to get the offset of the register from the
index to improve the performance.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add device managed APIs for regmap_add_irq_chip() and
regmap_del_irq_chip() so that it can be managed by
device framework for freeing it.
This helps on following:
1. Maintaining the sequence of resource allocation and deallocation
regmap_add_irq_chip(&d);
devm_requested_threaded_irq(virq)
On free path:
regmap_del_irq_chip(d);
and then removing the irq registration.
On this case, regmap irq is deleted before the irq is free.
This force to use normal irq registration.
By using devm apis, the sequence can be maintain properly:
devm_regmap_add_irq_chip(&d);
devm_requested_threaded_irq(virq);
and resource deallocation will be done in reverse order
by device framework.
2. No need to delete the regmap_irq_chip in error path or remove
callback and hence there is less code on this path.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It is require to dispose all virtual irq of hwirq on chip
created on given irq domain before removing this irq domain.
Hence dispose all mapped irqs before deleting the irq domains
in regmap_del_irq_chip();
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 29bb45f25f (regmap-mmio: Use native endianness for read/write)
attempted to fix some long standing bugs in the MMIO implementation for
big endian systems caused by duplicate byte swapping in both regmap and
readl()/writel() which affected MIPS systems as when they are in big
endian mode they flip the endianness of all registers in the system, not
just the CPU. MIPS systems had worked around this by declaring regmap
using IPs as little endian which is inaccurate, unfortunately the issue
had not been reported.
Sadly the fix makes things worse rather than better. By changing the
behaviour to match the documentation it caused behaviour changes for
other IPs which broke them and by using the __raw I/O accessors to avoid
the endianness swapping in readl()/writel() it removed some memory
ordering guarantees and could potentially generate unvirtualisable
instructions on some architectures.
Unfortunately sorting out all this mess in any half way sensible fashion
was far too invasive to go in during an -rc cycle so instead let's go
back to the old broken behaviour for v4.5, the better fixes are already
queued for v4.6. This does mean that we keep the broken MIPS DTs for
another release but that seems the least bad way of handling the
situation.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
If we are unable to read the cache defaults for a regmap then fall back
on attempting to read them word by word. This is going to be painfully
slow for large regmaps but might be adequate for smaller ones.
Signed-off-by: Mark Brown <broonie@kernel.org>
[maciej: Use cache_bypass around read and skipping of unreadable regs]
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regmaps without raw I/O access can't implement raw I/O operations,
return an error if someone tries to do that rather than crashing.
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently regmap-mmio uses the __raw accessors to read and write from
memory. This is not safe as these interact poorly with spinlocks and
are not guaranteed to generate emulated instructions on at least ARM
where regmap is commonly used. The APIs that are provided all provide
some byte swapping so this is difficult to do with the current
regmap-mmio implementation which attempts to use the regmap core byte
swapping.
We can fix this by modernising the MMIO implementation to use
reg_read() and reg_write() operations which were added after the API was
implemented and pass simple unsigned integers through to the bus, making
use of the formatting provided by the I/O accessors using a similar
pattern to that used by the core. This will be less efficient for block
I/O operations since we now enable and disable any required clocks per
register but it is not clear that any users of regmap-mmio actually use
block I/O and there is room to optimise later.
This removes support for big endian I/O on 64 bit registers since no I/O
accessors are provided, no current users were found and support can be
added easily once they are available.
In addition make the default endianness little endian. This was the
behaviour prior to 29bb45f25f (regmap-mmio: Use native endianness
for read/write) and is the behaviour desired by most existing users, the
users have been audited and those that need native endianness converted
to request it explicitly. Previously native was documented as the
default but due to the byte swapping in the accessors this was not
correctly implemented.
Fixes: 29bb45f25f (regmap-mmio: Use native endianness for read/write)
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently the binding document says that if no endianness is configured
we use native endian but this is not in fact true for all binding types
and we do have some devices that really want native endianness such as
Broadcom MIPS SoCs where switching the endianness of the CPU also
switches the endianness of external IPs.
Provide an explicit option for this.
Signed-off-by: Mark Brown <broonie@kernel.org>
regcache_hw_init() uses regmap_raw_read() to initialize cache
when reg_defaults_raw isn't provided.
The last parameter to regmap_raw_read() is buffer size in bytes,
however regcache_hw_init() called it with number of registers
to read instead, which cause problem if they aren't one byte
wide in cache.
This wasn't triggered by any of current in-tree drivers
since they either have one-byte registers or provide
reg_defaults_raw explicitly.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Mark Brown <broonie@kernel.org>
Unlike the registers file we don't have any substantial performance
concerns rendering the entire file (it involves no device accesses) so
just use seq_printf() to simplify the code.
Signed-off-by: Mark Brown <broonie@kernel.org>
Some of devices supports the trigger level for interrupt
like rising/falling edge specially for GPIOs. The interrupt
support of such devices may have uses the generic regmap irq
framework for implementation.
Add support to configure the trigger type device interrupt
register via regmap-irq framework. The regmap-irq framework
configures the trigger register only if the details of trigger
type registers are provided.
[Fixed use of terery operator for legibility -- broonie]
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark 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: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If the register defaults are provided by the driver without the
number by mistake, it should just return an error with one promotion.
This should be as early as possible, then there is no need to verify
the register defaults' stride and the other code followed.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If there is no cache used for the drivers, the register defaults
or the register defaults raw are not need any more. This patch
will check this and print a warning.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark 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: afcc00b91f ('regmap: add 64-bit mode support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We should cast these to 64bit so that we don't truncate away the high
bits.
Fixes: afcc00b91f ('regmap: add 64-bit mode support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the mmio has support the 64-bit has been supported for the
64-bit platform, so should the regcache core too.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There will be some warning like the following when checking new
patches near this code:
"WARNING: Missing a blank line after declarations"
This patch will suppress this warning.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The variable 'u64 *u64' should be only visible on 64-BIT platform.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark 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: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Splite the minimal stride parsing into one signal function.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace kmalloc with specialized function kmalloc_array when the size
is a multiplication of : number * size
Signed-off-by: lixiubo <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace kzalloc with specialized function kcalloc when the size is
a multiplication of : number * sizeof
Signed-off-by: lixiubo <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A binary search is much more efficient rather than iterating
over the rbtree in ascending order which the current code is
doing.
During initialisation the reg defaults are written to the
cache in a large chunk and these are always sorted in the
ascending order so for this situation ideally we should have
iterated the rbtree in descending order.
But at runtime the drivers may write into the cache in any
random order so this patch selects to use a bsearch to give
an optimal runtime performance and also at initialisation
time when reg defaults are written the performance of binary
search would be much better than iterating in ascending order
which the current code was doing.
Signed-off-by: Nikesh Oswal <Nikesh.Oswal@wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regmap API has an endianness setting for formatting reads and writes.
This can be set by the usual DT "little-endian" and "big-endian" properties.
To work properly the associated regmap_bus needs to read/write in native
endian.
The "syscon" DT device binding creates an mmio-based regmap_bus which
performs all reads/writes as little-endian. These values are then converted
again by regmap, which means that all of the MIPS BCM boards (which are
big-endian) have been declared as "little-endian" to get regmap to convert
them back to big-endian.
Modify regmap-mmio to use the native-endian functions __raw_read*() and
__raw_write*() instead of the little-endian functions read*() and
write*().
Modify the big-endian MIPS BCM boards to use what will now be the correct
endianness instead of pretending that the devices are little-endian.
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Mark Brown <broonie@kernel.org>
Here's the "big" driver core updates for 4.4-rc1. Primarily a bunch of
debugfs updates, with a smattering of minor driver core fixes and
updates as well.
All have been in linux-next for a long time.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlY6ePQACgkQMUfUDdst+ymNTgCgpP0CZw57GpwF/Hp2L/lMkVeo
Kx8AoKhEi4iqD5fdCQS9qTfomB+2/M6g
=g7ZO
-----END PGP SIGNATURE-----
Merge tag 'driver-core-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here's the "big" driver core updates for 4.4-rc1. Primarily a bunch
of debugfs updates, with a smattering of minor driver core fixes and
updates as well.
All have been in linux-next for a long time"
* tag 'driver-core-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
debugfs: Add debugfs_create_ulong()
of: to support binding numa node to specified device in devicetree
debugfs: Add read-only/write-only bool file ops
debugfs: Add read-only/write-only size_t file ops
debugfs: Add read-only/write-only x64 file ops
debugfs: Consolidate file mode checks in debugfs_create_*()
Revert "mm: Check if section present during memory block (un)registering"
driver-core: platform: Provide helpers for multi-driver modules
mm: Check if section present during memory block (un)registering
devres: fix a for loop bounds check
CMA: fix CONFIG_CMA_SIZE_MBYTES overflow in 64bit
base/platform: assert that dev_pm_domain callbacks are called unconditionally
sysfs: correctly handle short reads on PREALLOC attrs.
base: soc: siplify ida usage
kobject: move EXPORT_SYMBOL() macros next to corresponding definitions
kobject: explain what kobject's sd field is
debugfs: document that debugfs_remove*() accepts NULL and error values
debugfs: Pass bool pointer to debugfs_create_bool()
ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
Some buses provide a native _update_bits() operation which for uncached
registers is faster than doing a read/modify/write cycle as it is a
single bus transaction. Add support for implementing this to regmap.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWE+cLAAoJECTWi3JdVIfQaCcH/3m85peX2dlE7KhI6gL9N76h
v4w7phygbkQqdD3v9bbbiRavkOMrrBCVNZ28uXIO/52LulrK9pzxRVTuhqdyVasO
CIWfAYinlxWJA0BnJ1E2toqXkym9PEILCixfPyYEI5iZTX3w3rosSdup9MzYTxZZ
N3Vux2bjgCiXp9hYbajITFQ9QRNXzn3hlI/Jl0/x9SkodkzCLJurMq5JAaFE+mhO
1W2S+ERvb0M5bHuyr1Bhf3Bzb8uMFTl1QK3vxRkSI9UVe3MSpQP9SZeN+ye7p7U0
hDlike9FxyLTMMnIe9XnsNEtBZmxNuAb7meF50Bi7xzItRGOIlDxB/Ak55uD4I8=
=hCDC
-----END PGP SIGNATURE-----
Merge tag 'regmap-offload-update-bits' into regmap-next
regmap: Allow buses to provide a custom update_bits() operation
Some buses provide a native _update_bits() operation which for uncached
registers is faster than doing a read/modify/write cycle as it is a
single bus transaction. Add support for implementing this to regmap.
# gpg: Signature made Tue 06 Oct 2015 16:21:47 BST using RSA key ID 5D5487D0
# gpg: Oops: keyid_from_fingerprint: no pubkey
# gpg: Oops: keyid_from_fingerprint: no pubkey
# gpg: key 00000000 occurs more than once in the trustdb
# gpg: key 16005C11: no public key for trusted key - skipped
# gpg: key 16005C11 marked as ultimately trusted
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
This branch adds an interface for supporting devices which have separate
mask and unmask registers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJV+ptkAAoJECTWi3JdVIfQeIoH/3e1rQhIJFwO+iOV8A/vWSyk
P+NlBqPRCH77NofBfmilRHSTzI7bhuW5IDaD9mMvTcXID8j9p0HvJxJPVsrWtr8X
p7MaBYjNUitIUyO1coBDQ9YIh+gtVn5GaSzmfa5o+B0g8wpAKoqqE2BG08jR8yvH
oKp+Z/RZsIpjIgTLPLvoNX6WsjkOKMH5GB7uBAv5epmDarCJsi8gb+vs8OFoITdN
lBm0PSRD77nMn1a37n0FHa79yf/pszma0ep/mU662Ym+52BtSQM/UloNheoYQZ4Z
D7cgQjeXCJo57p1sXW6L26o1LhHRy1ovtr47nV+EXa7z0u1oY5EEwxOdUzXKiCA=
=+gx/
-----END PGP SIGNATURE-----
Merge tag 'regmap-irq-unmask' into regmap-next
regmap: Support for split mask and unmask interrupt registers
This branch adds an interface for supporting devices which have separate
mask and unmask registers.
# gpg: Signature made Thu 17 Sep 2015 11:52:20 BST using RSA key ID 5D5487D0
# gpg: Oops: keyid_from_fingerprint: no pubkey
# gpg: Oops: keyid_from_fingerprint: no pubkey
# gpg: key 00000000 occurs more than once in the trustdb
# gpg: key 16005C11: no public key for trusted key - skipped
# gpg: key 16005C11 marked as ultimately trusted
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.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: Jon Ringle <jringle@gridpoint.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument,
when all it needs is a boolean pointer.
It would be better to update this API to make it accept 'bool *'
instead, as that will make it more consistent and often more convenient.
Over that bool takes just a byte.
That required updates to all user sites as well, in the same commit
updating the API. regmap core was also using
debugfs_{read|write}_file_bool(), directly and variable types were
updated for that to be bool as well.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
By printing the newline character to entry, we can avoid accounting
for it manually in several places.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since we know the length of entry and that there's room enough in the
output buffer, using memcpy instead of snprintf is simpler and
cheaper.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Calling strlen() no less than three times on entry is silly. Since
we're formatting into a buffer with plenty of room, there's no chance
of truncation, so snprintf() has actually returned the value we want,
meaning we don't even have to call strlen once.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Now we no longer use the scratch buffer for register length calculation
there is no need for callers to supply one.
Signed-off-by: Mark Brown <broonie@kernel.org>
The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.
Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.
Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
An user will be CSR SiRFSoC ARM chips.
Signed-off-by: Guo Zeng <Guo.Zeng@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some chips have separate unmask registers from mask registers for
some consideration of concurrency SMP write performance. And this
patch adds a flag for it.
An user will be CSR SiRFSoC ARM chips.
Signed-off-by: Guo Zeng <Guo.Zeng@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
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: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark 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: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Mark 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: Mark Brown <broonie@kernel.org>
This allows to read/write up to 32 bytes of data and is to be prefered
if supported before the register read/write smbus support.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark 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: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark 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: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Mark 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: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
IS_ENABLED should only be used for CONFIG_* symbols.
I have done a small test:
#define REGMAP_ALLOW_WRITE_DEBUGFS
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
#define REGMAP_ALLOW_WRITE_DEBUGFS 0
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
#define REGMAP_ALLOW_WRITE_DEBUGFS 1
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 1.
#define REGMAP_ALLOW_WRITE_DEBUGFS 2
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
So fix the misuse of IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) and switch to
use #if defined(REGMAP_ALLOW_WRITE_DEBUGFS) instead.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When inserting a new register into a block, the present bit map size is
increased using krealloc. krealloc does not clear the additionally
allocated memory, leaving it filled with random values. Result is that
some registers are considered cached even though this is not the case.
Fix the problem by clearing the additionally allocated memory. Also, if
the bitmap size does not increase, do not reallocate the bitmap at all
to reduce overhead.
Fixes: 3f4ff561bc ("regmap: rbtree: Make cache_present bitmap per node")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Allow the user to write the cache_only and cache_bypass settings.
This can be useful for debugging.
Since this can lead to the hardware getting out-of-sync with the
cache, at least for the period that the cache state is forced, the
kernel is tainted and the action is recorded in the kernel log.
When disabling cache_only through debugfs a cache sync will be performed.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark 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: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
Signed-off-by: Mark 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: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
Signed-off-by: Mark 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: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Mark 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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark 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: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mark 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: Arun Chandran <achandran@mvista.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:
IRQF_VALID -> !IRQ_NOREQUEST
IRQF_PROBE -> !IRQ_NOPROBE
IRQF_NOAUTOEN -> IRQ_NOAUTOEN
For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Delete jump to a label on the next line, when that label is not
used elsewhere.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r@
identifier l;
@@
-if (...) goto l;
-l:
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch introduces regmap_get_reg_stride() function which would
be used by the infrastructures like nvmem framework built on top of
regmap. Mostly this function would be used for sanity checks on inputs
within such infrastructure.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like nvmem framework built on top of
regmap.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Existing regmap users call regcache_mark_dirty() as part of the
suspend/resume sequence, to tell regcache that non-default values need to
be resynced post-resume. Add an internal "no_sync_defaults" regmap flag
to remember this state, so that regcache_sync() can differentiate between
these two cases:
1) HW was reset, so any cache values that match map->reg_defaults can be
safely skipped. On some chips there are a lot of registers in the
reg_defaults list, so this optimization speeds things up quite a bit.
2) HW was not reset (maybe it was just clock-gated), so if we cached
any writes, they should be sent to the hardware regardless of whether
they match the HW default. Currently this will write out all values in
the regcache, since we don't maintain per-register dirty bits.
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
We're going to add another "does this register need syncing?" check, so
rather than repeating it in three places, we'll separate all of the
relevant logic into a helper function.
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The irq_domain_ops are not modified by the driver and the irqdomain core
code accepts pointer to a const data.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Just one patch for regmap this time around, a change from Steven Rostedt
to prettify the way we're making the regmap internal header available to
the trace events (it turns out that the trace subsystem doesn't actually
need to be in trace/events).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVK6+IAAoJECTWi3JdVIfQ+LoH/jIF6jq8oFna+T7uBa0cMw3p
vLm8N+j4ONLTVuEX0pd4+n13st2P4Epj6fVKJHFCPED/omdBMNWpGTn0ewX7AKCx
7jgjURmhv/WXWfLUzmlBHtM3Z4A/G2gEU1JFXFvCkbzsJwiqxjhElGuUoI+NWxyP
pW0nOABgPbIfhd0/MKvtNiBd63EXNEQilDrBPepp8UlhBR2DXQL9xdNBB4kbMMSk
5gjDmTIig16ORODvxgb9kK1DCaRQ265p3sa0O0fNJxfjpLmmXqBX3PXWNeCmOD4D
OMWh0QbhipdUO+VKMBRaWYxnIfAJnY9z408W9LgjhHcBLDsfiI+RPhCHG9+qatE=
=TkKs
-----END PGP SIGNATURE-----
Merge tag 'regmap-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap update from Mark Brown:
"Just one patch for regmap this time around, a change from Steven
Rostedt to prettify the way we're making the regmap internal header
available to the trace events (it turns out that the trace subsystem
doesn't actually need to be in trace/events)"
* tag 'regmap-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: Move tracing header into drivers/base/regmap
This patch fixes a bad interaction between the support that was added
for having regmaps without devices for early system controller
initialization and the trace support. There's a very good analysis of
the actual issue in the commit message for the change.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVEGNEAAoJECTWi3JdVIfQO+oH/1E2Ho6+X0lIG1mAIC27fae+
XwxtVvUOjCMSPOJ2gg+++YSKc7KIgkxt/VHpw2VllgklYDz32hHloaX/NCfIFaAt
jqTcE+PEeNJgjiZ0qa9zidMeT+BakhsYYl1gwA+0NYVH6AQuwXhhlKdq5+0MmySB
QMCVmWcB/XdvIW5t1nGleahTxqaIRyFXGk1q4dArKjlWSolKrLJr1QHXVvgJBDWN
BTVuzI5WCzzCc1W4FHO6X91PQCEdc7eJxrCXGIuZ53nZlLx3YbhdKxHifibaxU4e
7pRFH1e5FI2jEYjcfDsYi71A+OuexXGHmq1Trm2uPaSIFsCTz32QzieyTD2Lfp8=
=eX90
-----END PGP SIGNATURE-----
Merge tag 'regmap-fix-v4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fix from Mark Brown:
"This patch fixes a bad interaction between the support that was added
for having regmaps without devices for early system controller
initialization and the trace support.
There's a very good analysis of the actual issue in the commit message
for the change"
* tag 'regmap-fix-v4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: introduce regmap_name to fix syscon regmap trace events
The tracing events for regmap are confined to the regmap subsystem. It
also requires accessing an internal header. Instead of including the
internal header from a generic file location, move the tracing file
into the regmap directory.
Also rename the regmap tracing header to trace.h, as it is redundant to
keep the regmap.h name when it is in the regmap directory.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown