linux-toradex.git/drivers/base/regmap/regmap-i2c.c, branch v5.17

regmap-i2c: Set regmap max raw r/w from quirks

2021-05-14T12:25:03+00:00

Set regmap raw read/write from i2c quirks max read/write
so regmap_raw_read/write can split the access into chunks

Signed-off-by: Lucas Tanure 
Link: https://lore.kernel.org/r/20210512135222.223203-1-tanureal@opensource.cirrus.com
Signed-off-by: Mark Brown

regmap-i2c: add 16-bit width registers support

2020-04-24T13:32:07+00:00

This allows to access data with 16-bit width of registers
via i2c SMBus block functions.

The multi-command sequence of the reading function is not safe
and may read the wrong data from other address if other commands
are sent in-between the SMBus commands in the read function.

Read performance:
   32768 bytes (33 kB, 32 KiB) copied, 11.4869 s, 2.9 kB/s
Write performance(with 1-byte page):
   32768 bytes (33 kB, 32 KiB) copied, 129.591 s, 0.3 kB/s

The implementation is inspired by below commit
https://patchwork.ozlabs.org/patch/545292/

v2: add more descriptions about the issue that maybe introduced
    by this commit

Signed-off-by: AceLan Kao 
Link: https://lore.kernel.org/r/20200424123358.144850-1-acelan.kao@canonical.com
Signed-off-by: Mark Brown

regmap-i2c: constify regmap_bus structures

2020-01-06T20:46:44+00:00

regmap_bus structures are not changed anywhere. Mark them const.

Signed-off-by: Michał Mirosław 
Link: https://lore.kernel.org/r/85e4141348db00ecf1f2bc5c2ff6ba3de75e8ff4.1578134920.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown

regmap: add proper SPDX identifiers on files that did not have them.

2019-04-25T19:22:15+00:00

There were a few files in the regmap code that did not have SPDX
identifiers on them, so fix that up.  At the same time, remove the "free
form" text that specified the license of the file, as that is impossible
for any tool to properly parse.

Also, as Mark loves // comment markers, convert all of the headers to be
the same to make things look consistent :)

Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Mark Brown

regmap-i2c: Off by one in regmap_i2c_smbus_i2c_read/write()

2018-02-08T15:36:35+00:00

The commit message says that we are allowed to read and write up to 32
bytes but the code only allows us to write 31 bytes.  In other words,
the ">=" should be changed to ">".  But this is already checked in
regmap_raw_read()/write() so we can just remove the if statemetents.

Fixes: 29332534e2b6 ("regmap-i2c: Add smbus i2c block support")
Signed-off-by: Dan Carpenter 
Signed-off-by: Mark Brown

regmap-i2c: Use i2c block command only if register value width is 8 bit

2016-06-22T12:50:51+00:00

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 
Signed-off-by: Mark Brown

Merge remote-tracking branches 'regmap/topic/lockdep' and 'regmap/topic/seq-delay' into regmap-next

2015-09-04T16:22:10+00:00

regmap-i2c: Add smbus i2c block support

2015-08-30T09:19:23+00:00

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 
Signed-off-by: Mark Brown

regmap: Move documentation to regmap.h

2015-08-11T16:21:44+00:00

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 
Signed-off-by: Mark Brown

regmap: Use different lockdep class for each regmap init call

2015-08-07T13:50:59+00:00

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 
Signed-off-by: Mark Brown