linux-toradex.git/include/linux/regmap.h, branch v6.16-rc6 Linux kernel for Apalis and Colibri modules regmap: irq: Add support for chips without separate IRQ status 2025-05-22T12:11:50+00:00 Mathieu Dubois-Briand mathieu.dubois-briand@bootlin.com 2025-05-22T12:06:20+00:00 1c12fbdf40e17df2efc24bf2009a0c3bfa75bfa7 Some GPIO chips allow to rise an IRQ on GPIO level changes but do not provide an IRQ status for each separate line: only the current gpio level can be retrieved. Add support for these chips, emulating IRQ status by comparing GPIO levels with the levels during the previous interrupt. Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250522-mdb-max7360-support-v9-5-74fc03517e41@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Some GPIO chips allow to rise an IRQ on GPIO level changes but do not
provide an IRQ status for each separate line: only the current gpio
level can be retrieved.

Add support for these chips, emulating IRQ status by comparing GPIO
levels with the levels during the previous interrupt.

Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250522-mdb-max7360-support-v9-5-74fc03517e41@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regcache: Add support for sorting defaults arrays 2025-02-27T13:09:11+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2025-02-17T14:01:56+00:00 fd80df352ba1884ce2b62dd8d9495582308101b7 The defaults array in regcache must be sorted into ascending register address order, because binary search is used to locate values in the array. Add a helper to sort the register defaults array which can be useful for systems that dynamically create a defaults array based on external information. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The defaults array in regcache must be sorted into ascending register
address order, because binary search is used to locate values in
the array. Add a helper to sort the register defaults array which
can be useful for systems that dynamically create a defaults array
based on external information.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250217140159.2288784-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Expand SoundWire MBQ register map support 2025-01-07T23:28:07+00:00 Mark Brown broonie@kernel.org 2025-01-07T23:28:07+00:00 d406b354df909155ff0122acf80f3bc7410fa27e Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>: The current SDCA MBQ (Multi-Byte Quantities) register map only supports 16-bit types, add support for more sizes and then update the rt722 driver to use the new support. We also add support for the deferring feature of MBQs to allow hardware to indicate it is not currently ready to service a read/write. Afraid I don't have hardware to test the rt722 change so it is only build tested, but I thought it good to include a change to demonstrate the new features in use. 
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:

The current SDCA MBQ (Multi-Byte Quantities) register map only
supports 16-bit types, add support for more sizes and then update
the rt722 driver to use the new support. We also add support for
the deferring feature of MBQs to allow hardware to indicate it is
not currently ready to service a read/write.

Afraid I don't have hardware to test the rt722 change so it is
only build tested, but I thought it good to include a change to
demonstrate the new features in use.
regmap: sdw-mbq: Add support for SDCA deferred controls 2025-01-07T20:21:00+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2025-01-07T15:44:06+00:00 5bc493bf0c37c157bf2eb364e55a1c6f8bc43a69 The SDCA specification allows for controls to be deferred. In the case of a deferred control the device will return COMMAND_IGNORED to the 8-bit operation that would cause the value to commit. Which is the final 8-bits on a write, or the first 8-bits on a read. In the case of receiving a defer, the regmap will poll the SDCA function busy bit, after which the transaction will be retried, returning an error if the function busy does not clear within a chip specific timeout. Since this is common SDCA functionality which is the 99% use-case for MBQs it makes sense to incorporate this functionality into the register map. If no MBQ configuration is specified, the behaviour will default to the existing behaviour. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-5-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org> 
The SDCA specification allows for controls to be deferred. In the case
of a deferred control the device will return COMMAND_IGNORED to the
8-bit operation that would cause the value to commit. Which is the
final 8-bits on a write, or the first 8-bits on a read. In the case of
receiving a defer, the regmap will poll the SDCA function busy bit,
after which the transaction will be retried, returning an error if the
function busy does not clear within a chip specific timeout. Since
this is common SDCA functionality which is the 99% use-case for MBQs
it makes sense to incorporate this functionality into the register
map. If no MBQ configuration is specified, the behaviour will default
to the existing behaviour.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250107154408.814455-5-ckeepax@opensource.cirrus.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap: sdw-mbq: Add support for further MBQ register sizes 2025-01-07T20:20:59+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2025-01-07T15:44:05+00:00 fdd9ef3dce98e035d21c17fac587cb6e3c7706fd SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org> 
SoundWire MBQ register maps typically contain a variety of register
sizes, which doesn't map ideally to the regmap abstraction which
expects register maps to have a consistent size. Currently the MBQ
register map only allows 16-bit registers to be defined, however
this leads to complex CODEC driver implementations with an 8-bit
register map and a 16-bit MBQ, every control will then have a custom
get and put handler that allows them to access different register
maps. Further more 32-bit MBQ quantities are not currently supported.

Add support for additional MBQ sizes and to avoid the complexity
of multiple register maps treat the val_size as a maximum size for
the register map. Within the regmap use an ancillary callback to
determine how many bytes to actually read/write to the hardware for
a specific register. In the case that no callback is defined the
behaviour defaults back to the existing behaviour of a fixed size
register map.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap: regmap_multi_reg_read(): make register list const 2024-12-11T14:24:09+00:00 Richard Fitzgerald rf@opensource.cirrus.com 2024-12-11T13:35:58+00:00 eb708cd631a8dca17ff004ccc39bbeb096c1db22 Mark the list of registers passed into regmap_multi_reg_read() as a pointer to const. This allows the caller to define the register list as const data. This requires making the same change to _regmap_bulk_read(), which is called by regmap_multi_reg_read(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20241211133558.884669-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Mark the list of registers passed into regmap_multi_reg_read() as a
pointer to const. This allows the caller to define the register list
as const data.

This requires making the same change to _regmap_bulk_read(), which is
called by regmap_multi_reg_read().

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241211133558.884669-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge tag 'regmap-v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap 2024-11-20T20:09:47+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-11-20T20:09:47+00:00 37c7d3538af469c2ac8d2d379f699e71aa3c6f37 Pull regmap updates from Mark Brown: "The main thing for regmap this time around is some improvements of the lockdep annotations which stop some false positives. We also have one new helper for setting a bitmask to the same value, and several test improvements" * tag 'regmap-v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: provide regmap_assign_bits() regmap: irq: Set lockdep class for hierarchical IRQ domains regmap: maple: Provide lockdep (sub)class for maple tree's internal lock regmap: kunit: Fix repeated test param regcache: Improve documentation of available cache types regmap: Specifically test writing 0 as a value to sparse caches regmap-irq: Consistently use memset32() in regmap_irq_thread() 
Pull regmap updates from Mark Brown:
 "The main thing for regmap this time around is some improvements of the
  lockdep annotations which stop some false positives. We also have one
  new helper for setting a bitmask to the same value, and several test
  improvements"

* tag 'regmap-v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: provide regmap_assign_bits()
  regmap: irq: Set lockdep class for hierarchical IRQ domains
  regmap: maple: Provide lockdep (sub)class for maple tree's internal lock
  regmap: kunit: Fix repeated test param
  regcache: Improve documentation of available cache types
  regmap: Specifically test writing 0 as a value to sparse caches
  regmap-irq: Consistently use memset32() in regmap_irq_thread()
regmap: provide regmap_assign_bits() 2024-11-08T15:39:31+00:00 Bartosz Golaszewski brgl@bgdev.pl 2024-11-08T14:07:37+00:00 d1f4390dd28ba110f232615dc4610ac1bb2f39f2 Add another bits helper to regmap API: this one sets given bits if value is true and clears them if it's false. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patch.msgid.link/20241108-assign-bits-v1-1-382790562d99@ideasonboard.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Add another bits helper to regmap API: this one sets given bits if value
is true and clears them if it's false.

Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patch.msgid.link/20241108-assign-bits-v1-1-382790562d99@ideasonboard.com
Signed-off-by: Mark Brown <broonie@kernel.org>
iopoll/regmap/phy/snd: Fix comment referencing outdated timer documentation 2024-10-15T22:36:47+00:00 Anna-Maria Behnsen anna-maria@linutronix.de 2024-10-14T08:22:29+00:00 89124747f096fc0fe44be0162c7b4fb3271739e8 Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h copied all the same outdated documentation about sleep/delay function limitations. In those comments, the generic (and still outdated) timer documentation file is referenced. As proper function descriptions for used delay and sleep functions are in place, simply update the descriptions to reference to them. While at it fix missing colon after "Returns" in function description and move return value description to the end of the function description. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> # for phy.h Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de 
Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h
copied all the same outdated documentation about sleep/delay function
limitations. In those comments, the generic (and still outdated) timer
documentation file is referenced.

As proper function descriptions for used delay and sleep functions are in
place, simply update the descriptions to reference to them. While at it fix
missing colon after "Returns" in function description and move return value
description to the end of the function description.

Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch> # for phy.h
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de
regcache: Improve documentation of available cache types 2024-09-29T23:11:10+00:00 Mark Brown broonie@kernel.org 2024-09-24T10:08:08+00:00 caf78b0465053c23aa6211b9815dd5433766627d There is some user confusion about which cache types to choose when which is not helped by the lack of any central documentation providing an overview of what's available. Provide a short overview in the API header to try to help reduce this. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20240924-regcache-document-types-v1-1-e157054e1215@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> 
There is some user confusion about which cache types to choose when which
is not helped by the lack of any central documentation providing an
overview of what's available. Provide a short overview in the API header to
try to help reduce this.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20240924-regcache-document-types-v1-1-e157054e1215@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>