regmap provides a couple of ways to validate the register range used.
a) maxim allowed register, b) writable/readable register tables,
c) callback function that can be provided by the driver to validate
a register. regmap framework should verify if registers
are writeable before every write operation. However this doesn't
seems to happen in every situation.
The method `_regmap_raw_write_impl` is only using the `writeable_reg`
callback to verify if register is writeable, ignoring the other two.
This can lead to undefined behaviour since this allows to write to
registers that could be declared un-writeable by using any other
option.
Change `_regmap_raw_write_impl` to use the `regmap_writeable` method
to verify if registers are writable before the write operation.
Signed-off-by: Nandor Han <nandor.han@vaisala.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Improve the speed of the loop jumping to the next
available register
Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
On one hand commit 28644c809f ("regmap: Add the rbtree cache support")
added 'regcache_rbtree_node' as packed structure, while on the other hand
commit e977145aea ("[RBTREE] Add explicit alignment to sizeof(long)
for struct rb_node.") declared struct 'rb_node' as aligned.
Solve the ambiguity of placing aligned structure in a packed one by
removing the packed attribute from struct. This seems to be the behavior
of gcc anyway.
This removes the following warning (W=1):
drivers/base/regmap/regcache-rbtree.c:36:1: warning: alignment 1 of 'struct regcache_rbtree_node' is less than 4 [-Wpacked-not-aligned]
Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is bunch of devices with multiple logical blocks which
can generate interrupts. It's not a rare case that the interrupt
reason registers are arranged so that there is own status/ack/mask
register for each logical block. In some devices there is also a
'main interrupt register(s)' which can indicate what sub blocks
have interrupts pending.
When such a device is connected via slow bus like i2c the main
part of interrupt handling latency can be caused by bus accesses.
On systems where it is expected that only one (or few) sub blocks
have active interrupts we can reduce the latency by only reading
the main register and those sub registers which have active
interrupts. Support this with regmap-irq for simple cases where
main register does not require acking or masking.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If client have not provided the mask base register then do not
write into the mask register.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Jinyoung Park <jinyoungp@nvidia.com>
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: Mark Zhang <markz@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Do not return error if irq-type setting is requested for
controlloer which does not support this. This is how
regmap-irq has previously handled the undupported type
settings and existing drivers seem to be upset if failure
is now reported.
Fixes: 1c2928e3e3 ("regmap: regmap-irq/gpio-max77620: add level-irq support")
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some interrupt controllers whose interrupts are acked on read will set
the status bits for masked interrupts without changing the state of
the IRQ line.
Some chips have an additional "feature" where if those set bits are
not cleared before unmasking their respective interrupts, the IRQ
line will change the state and we'll interpret this as an interrupt
although it actually fired when it was masked.
Add a new field to the irq chip struct that tells the regmap irq chip
code to always clear the status registers before actually changing the
irq mask values.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add level active IRQ support to regmap-irq irqchip. Change breaks
existing regmap-irq type setting. Convert the existing drivers which
use regmap-irq with trigger type setting (gpio-max77620) to work
with this new approach. So we do not magically support level-active
IRQs on gpio-max77620 - but add support to the regmap-irq for chips
which support them =)
We do not support distinguishing situation where HW supports rising
and falling edge detection but not both. Separating this would require
inventing yet another flags for IRQ types.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The common code should not set IRQ type. Read HW defaults to the
cache at startup instead of forcing type to EDGE_BOTH. If
default setting is needed this should be done via normal
mechanisms or by chip specific code if normal mechanisms are not
suitable for some reason. Common regmap-irq code should not have
defaults hard-coded but keep the HW/boot defaults untouched.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some interrupt controllers use separate bits for controlling rising
and falling edge interrupts in the mask register i.e. they have one
interrupt for rising edge and one for falling.
We already handle the case where we have a single interrupt in the
mask register and a separate type configuration register.
Add a new switch to regmap_irq_chip which tells the framework to use
the mask_base address for configuring the edge of the interrupts that
define type_falling/rising_mask values.
For such interrupts we never update the type_base bits. For interrupts
that don't define type masks or their regmap irq chip doesn't set the
type_in_mask to true everything stays the same.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the checking of the LOG_DEVICE into a function to reduce the
number of #ifdefs and ensure more of the code gets compiled/checked,
and make it easier to change this for internal debugging purposes
(such as checking >1 device).
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regmap API had a noinc_read function added for instances where devices
supported returning data from an internal FIFO in a single read.
This commit adds the noinc_write variant to allow writing to a non
incrementing register, this is used in devices such as the sx1301 for
loading firmware.
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Split regmap_config.use_single_rw into use_single_read and
use_single_write. This change enables drivers of devices which only
support bulk operations in one direction to use the regmap_bulk_*()
functions for both directions and have their bulk operation split into
single operations only when necessary.
Update all struct regmap_config instances where use_single_rw==true to
instead set both use_single_read and use_single_write. No attempt was
made to evaluate whether it is possible to set only one of
use_single_read or use_single_write.
Signed-off-by: David Frey <dpfrey@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some devices have individual registers that don't autoincrement the
register address during bulk reads but instead repeatedly read the same
value, for example for monitoring GPIOs or ADCs. Add support for these.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAltsE8YTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0DeLB/sHEWAdyUCz9dO9pDdpi6WfpnKXuCCd
ZFnx8VXBvzVLRCZYGXuMOUEzBQU2lTr2KPFDmE1k4FclyiWaI+hRIJ0s/x8FAl51
EFDoR4TM7t2n2aY0sPQCZKnoAhdQ9YPxlA9JjDUE57h0KoC76Dh8OB44dlAlxUAY
PUjkv64/7AtvkBX7UZPQxckaPOLKM00P/hXwCB9MZCkjqnSWkUGgNCWPgKn9j2yL
jiUQO0Wo9u8RkvYvndHPkh4NzgeH1sUFUdNys/Fopu6C2miIYBNKzvEo2OXhelHf
k5rsoMQXYdiPdy4vRbeaWFetyEeBjxKIAQHKD0WJviFPw8j+ET+2GNjx
=p0Mu
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAltsFCwTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0NcxB/wMqH+78D7GdJfMkxMKhCHFUxozfCe9
cgWgZ7+vlWpIwEGvM65FHMrFyc5ZrS3/vD6Hy8lqpsqGBVv6wS6Z0lsoOyj/QvTl
T8USWKvQnvtzlPY5lRZL0xuGiaGGtpGa0eaLKH2lY7uvoge0oHz8VV6ar5y7eA1S
1INBpgTdHJgCQLZoc1pFNOcZ0EMFl6ZAygIWJTpqIwoQlvPEgtCQ4wjPlMUKrevP
psJWd9obyM6+02mYFVMAlYpcMSoZ/MjPeMb7VGhLGwA1BA6dNcbiIeS7GCeH2r/i
/vxvarsEm38MfLBIyORW06onHyRhVwXdLoD1jblmvYtRlfW5ANjr5g/O
=mbi1
-----END PGP SIGNATURE-----
Merge tag 'regmap-noinc-read' into regmap-4.19
regmap: Support non-incrementing registers
Some devices have individual registers that don't autoincrement the
register address during bulk reads but instead repeatedly read the same
value, for example for monitoring GPIOs or ADCs. Add support for these.
The regmap API usually assumes that bulk read operations will read a
range of registers but some I2C/SPI devices have certain registers for
which a such a read operation will return data from an internal FIFO
instead. Add an explicit API to support bulk read without range semantics.
Some linux drivers use regmap_bulk_read or regmap_raw_read for such
registers, for example mpu6050 or bmi150 from IIO. This only happens to
work because when caching is disabled a single regmap read op will map
to a single bus read op (as desired). This breaks if caching is enabled and
reg+1 happens to be a cacheable register.
Without regmap support refactoring a driver to enable regmap caching
requires separate I2C and SPI paths. This is exactly what regmap is
supposed to help avoid.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.
Fixes: bcf7eac3d9 ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is an I2C subset.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAltPUrMTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0KODB/oDV+4c82VIUopoaXxK8PbBqDMn5n2r
EKyb1D/GFiT54x2666arRT1NymL/uk6/nK1hryd/4HE5zB1lUQnu/Z7HCHgF4N+/
iWHtAgFUSZtNlMTRT6DW/tcsNDGnH9vjNJUhOLH9Y21h3Q4BpOo5HQVR8ynN4TDh
2inSy5qgADyrosxRpW5mp0Nt0tpFTfvYOHoRaLTbQUbBnpb/MmqcTzkYHcVNqA8V
7+e9/SOVU0XXHQD5k28F7eB84Mk+TXQrZQ181RwNOKUf3je86Im6WfrFqKHqKP5N
UAq28AjsjRiBs1qwOYK0ytWR8gQvs39cZmdud507R1mLWEO4/++TruRt
=wkUm
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAltPUyETHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0CJsB/oD+83KWX8V1Q4HhaO3e6BN2SPYphQr
jbImC9QUSRl/65+0ek6VjqLu4znY/LARRjNThN0l01wvWv7+h71DJBSKL67zK9en
h4Lr8ZoewBQ408YaC5zl7ilFXgRBMhfCanDWWHv8jAv1rk9VQU8q9uNGo518e0Ks
2Gg/zTmQYp7dNMHsVO4AEr3UQye1yZdGdP1q1yk3nbNgZbDq4xWWZWl1p4Iy+QG3
e4SY+OYenQC/+pafUQOzPoiG3I/f8RAQG9SAtne+gtIyF85+Q8mVizuU89GdtH3O
rKcaiNk/FpSbcBxAXEGb0qNy6PW6gnAbSznrOdc7MEj2V5E3KfoR7oVO
=VO/+
-----END PGP SIGNATURE-----
Merge tag 'regmap-sccb' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into regmap-4.19
regmap: Add support for SCCB
This is an I2C subset.
This adds Serial Camera Control Bus (SCCB) support for regmap API that
is intended to be used by some of Omnivision sensor drivers.
The ov772x and ov9650 drivers are going to use this SCCB regmap API.
The ov772x driver was previously only worked with the i2c controller
drivers that support I2C_FUNC_PROTOCOL_MANGLING, because the ov772x
device doesn't support repeated starts. After commit 0b964d183c
("media: ov772x: allow i2c controllers without
I2C_FUNC_PROTOCOL_MANGLING"), reading ov772x register is replaced with
issuing two separated i2c messages in order to avoid repeated start.
Using this SCCB regmap hides the implementation detail.
The ov9650 driver also issues two separated i2c messages to read the
registers as the device doesn't support repeated start. So it can
make use of this SCCB regmap.
Cc: Mark Brown <broonie@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SLIMbus supports upto 16 bytes in value management messages,
so add support to read/writes upto 16 bytes.
This also removes redundant single register reg_read/reg_write.
Also useful for paged register access on SLIMbus interfaced codecs.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
As per SLIMBus specs Value Elements and Information Elements
address map ranges from 0x000 - 0xFFF.
So allow register addresses up to 16 bits
Fixes: 7d6f7fb053 ("regmap: add SLIMbus support")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Capability to attach an existing clk to a MMIO regmap was
introduced in 4.17rc1.
However, when using attached clk, regmap does not do the clk_get.
Therefore it should not do the clk_put when freeing the MMIO
regmap context.
There does not appear to be any users of attached clocks yet
so this would be a good time to make this change before anything
depends on the existing behaviour.
Signed-off-by: James Kelly <jamespeterkelly@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently when debugfs_create_dir() fails we receive a warning message
that provides no indication as to what was the directory entry that
failed to be created.
Improve the warning message by printing the directory name that failed
in order to help debugging.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Free map->debugfs_name when debugfs_create_dir() failed to avoid memory
leak.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When allocating dummy names we need to store a pointer to the string we
allocate so that we don't leak it on free.
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 9b947a13e7 ("regmap: use debugfs even when no device")
allows the usage of regmap debugfs even when there is no device
associated, which causes several warnings like this:
(NULL device *): Failed to create debugfs directory
This happens when the debugfs file name is 'dummy'.
The first dummy debugfs creation works fine, but subsequent creations
fail as they have all the same name.
Disambiguate the 'dummy' debugfs file name by adding a suffix entry,
so that the names become dummy0, dummy1, dummy2, etc.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap_init_mmio_clk allows to specify a clock that needs to be enabled
while accessing the registers.
However, that clock is retrieved through its clock ID, which means it will
lookup that clock based on the current device that registers the regmap,
and, in the DT case, will only look in that device OF node.
This might be problematic if the clock to enable is stored in another node.
Let's add a function that allows to attach a clock that has already been
retrieved to a regmap in order to fix this.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The handling for the first two cases in regmap_bulk_write is
essentially identical. The first case is just a better implementation of
the second, supporting 8 byte registers and doing the locking manually to
avoid bouncing the lock for each register. Drop some redundant code by
removing the second of these cases and allowing both situations to be
handled by the same code.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Raw writes may need to be split into small chunks if max_raw_write is
set. Tidy up the code implementing this, the new code is slightly
clearer, slightly shorter and slightly more efficient.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently regmap_bulk_write will split a write into chunks before
calling regmap_raw_write if max_raw_write is set. It is more logical
for this handling to be inside regmap_raw_write itself, as this
removes the need to keep re-implementing the chunking code, which
would be the same for all users of regmap_raw_write.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In the case were the bulk transaction is split up into smaller chunks
data is passed directly to regmap_raw_write. However regmap_bulk_write
uses data in host endian and regmap_raw_write expects data in device
endian. As such if the host and device differ in endian the wrong data
will be written to the device. Correct this issue using a similar
approach to the single raw write case below it, duplicate the data
into a new buffer and use parse_inplace to format the data correctly.
Fixes: adaac45975 ("regmap: Introduce max_raw_read/write for regmap_bulk_read/write")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This registers regmaps with debugfs even when they do not have an
associated device. For example, this is common for syscon regmaps.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This fixes a possible NULL pointer dereference oops in
regmap_name_read_file() when the regmap does not have a device
associated with it. For example syscon regmaps retrieved with
syscon_regmap_lookup_by_compatible() don't have a device.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bulk reads may potentially read a lot of registers and regmap_read will
take and release the regmap lock for each register. Avoid bouncing
the lock so frequently by holding the lock locally and calling
_regmap_read instead. This also has the nice side-effect that all the
reads will be done atomically so no other threads can sneak a write in
during the regmap_bulk_read.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Raw reads may need to be split into small chunks if max_raw_read is
set. Tidy up the code implementing this, the new code is slightly
clearer, slightly shorter and slightly more efficient.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently regmap_bulk_read will split a read into chunks before
calling regmap_raw_read if max_raw_read is set. It is more logical for
this handling to be inside regmap_raw_read itself, as this removes the
need to keep re-implementing the chunking code, which would be the
same for all users of regmap_raw_read.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Han Nandor