<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/base/regmap/internal.h, branch v6.12.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-12-14T19:03:40+00:00</updated>
<entry>
<title>regmap: maple: Provide lockdep (sub)class for maple tree's internal lock</title>
<updated>2024-12-14T19:03:40+00:00</updated>
<author>
<name>Cristian Ciocaltea</name>
<email>cristian.ciocaltea@collabora.com</email>
</author>
<published>2024-10-31T16:37:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0380da1da737d68b16dd6bd2914e6bb802a11632'/>
<id>urn:sha1:0380da1da737d68b16dd6bd2914e6bb802a11632</id>
<content type='text'>
[ Upstream commit 1ed9b927e7dd8b8cff13052efe212a8ff72ec51d ]

In some cases when using the maple tree register cache, the lockdep
validator might complain about invalid deadlocks:

[7.131886]  Possible interrupt unsafe locking scenario:

[7.131890]        CPU0                    CPU1
[7.131893]        ----                    ----
[7.131896]   lock(&amp;mt-&gt;ma_lock);
[7.131904]                                local_irq_disable();
[7.131907]                                lock(rockchip_drm_vop2:3114:(&amp;vop2_regmap_config)-&gt;lock);
[7.131916]                                lock(&amp;mt-&gt;ma_lock);
[7.131925]   &lt;Interrupt&gt;
[7.131928]     lock(rockchip_drm_vop2:3114:(&amp;vop2_regmap_config)-&gt;lock);
[7.131936]
                *** DEADLOCK ***

[7.131939] no locks held by swapper/0/0.
[7.131944]
               the shortest dependencies between 2nd lock and 1st lock:
[7.131950]  -&gt; (&amp;mt-&gt;ma_lock){+.+.}-{2:2} {
[7.131966]     HARDIRQ-ON-W at:
[7.131973]                       lock_acquire+0x200/0x330
[7.131986]                       _raw_spin_lock+0x50/0x70
[7.131998]                       regcache_maple_write+0x68/0xe0
[7.132010]                       regcache_write+0x6c/0x90
[7.132019]                       _regmap_read+0x19c/0x1d0
[7.132029]                       _regmap_update_bits+0xc0/0x148
[7.132038]                       regmap_update_bits_base+0x6c/0xa8
[7.132048]                       rk8xx_probe+0x22c/0x3d8
[7.132057]                       rk8xx_spi_probe+0x74/0x88
[7.132065]                       spi_probe+0xa8/0xe0

[...]

[7.132675]   }
[7.132678]   ... key      at: [&lt;ffff800082943c20&gt;] __key.0+0x0/0x10
[7.132691]   ... acquired at:
[7.132695]    _raw_spin_lock+0x50/0x70
[7.132704]    regcache_maple_write+0x68/0xe0
[7.132714]    regcache_write+0x6c/0x90
[7.132724]    _regmap_read+0x19c/0x1d0
[7.132732]    _regmap_update_bits+0xc0/0x148
[7.132741]    regmap_field_update_bits_base+0x74/0xb8
[7.132751]    vop2_plane_atomic_update+0x480/0x14d8 [rockchipdrm]
[7.132820]    drm_atomic_helper_commit_planes+0x1a0/0x320 [drm_kms_helper]

[...]

[7.135112] -&gt; (rockchip_drm_vop2:3114:(&amp;vop2_regmap_config)-&gt;lock){-...}-{2:2} {
[7.135130]    IN-HARDIRQ-W at:
[7.135136]                     lock_acquire+0x200/0x330
[7.135147]                     _raw_spin_lock_irqsave+0x6c/0x98
[7.135157]                     regmap_lock_spinlock+0x20/0x40
[7.135166]                     regmap_read+0x44/0x90
[7.135175]                     vop2_isr+0x90/0x290 [rockchipdrm]
[7.135225]                     __handle_irq_event_percpu+0x124/0x2d0

In the example above, the validator seems to get the scope of
dependencies wrong, since the regmap instance used in rk8xx-spi driver
has nothing to do with the instance from vop2.

Improve validation by sharing the regmap's lockdep class with the maple
tree's internal lock, while also providing a subclass for the latter.

Signed-off-by: Cristian Ciocaltea &lt;cristian.ciocaltea@collabora.com&gt;
Link: https://patch.msgid.link/20241031-regmap-maple-lockdep-fix-v2-1-06a3710f3623@collabora.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: kunit: Create a struct device for the regmap</title>
<updated>2024-04-08T15:38:07+00:00</updated>
<author>
<name>Richard Fitzgerald</name>
<email>rf@opensource.cirrus.com</email>
</author>
<published>2024-04-08T14:45:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b7982f14315e0f6910e13b22ed38a47144a83ec'/>
<id>urn:sha1:7b7982f14315e0f6910e13b22ed38a47144a83ec</id>
<content type='text'>
Use kunit_device_register() to create a real struct device for the
regmap instead of leaving it at NULL.

The main reason for this is that it allows context data to be passed
into the readable_reg/writable_reg/volatile_reg functions by attaching
it to the struct device with dev_set_drvdata().

The gen_regmap() and gen_raw_regmap() functions are updated to take a
struct kunit * argument.

A new struct regmap_test_priv has been created to hold the struct device
created by kunit_device_register(). This allows the struct to be
extended in the future to hold more private data for the test suite.

Signed-off-by: Richard Fitzgerald &lt;rf@opensource.cirrus.com&gt;
Link: https://msgid.link/r/20240408144600.230848-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: rework -&gt;max_register handling</title>
<updated>2024-02-05T14:32:35+00:00</updated>
<author>
<name>Jan Dakinevich</name>
<email>jan.dakinevich@salutedevices.com</email>
</author>
<published>2024-01-26T20:08:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0ec74ad3c157bd4bcbcc8b294777733687e8cd2a'/>
<id>urn:sha1:0ec74ad3c157bd4bcbcc8b294777733687e8cd2a</id>
<content type='text'>
When regmap consists of single register, 'regmap' subsystem is unable to
understand whether -&gt;max_register is set or not, because in both cases it
is equal to zero. It leads to that the logic based on value of
-&gt;max_register doesn't work. For example using of REGCACHE_FLAT fails.

This patch introduces an extra parameter to regmap config, indicating
that zero value in -&gt;max_register is authentic.

Signed-off-by: Jan Dakinevich &lt;jan.dakinevich@salutedevices.com&gt;
Link: https://lore.kernel.org/r/20240126200836.1829995-1-jan.dakinevich@salutedevices.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: ram: support noinc semantics</title>
<updated>2023-11-13T01:26:17+00:00</updated>
<author>
<name>Ben Wolsieffer</name>
<email>ben.wolsieffer@hefring.com</email>
</author>
<published>2023-11-02T20:30:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02e3564a344064aca49f147e8a4eecbe5d3459fc'/>
<id>urn:sha1:02e3564a344064aca49f147e8a4eecbe5d3459fc</id>
<content type='text'>
Support noinc semantics in RAM backed regmaps, for testing purposes. Add
a new callback that selects registers which should have noinc behavior.
Bulk writes to a noinc register will cause the last value in the buffer
to be assigned to the register, while bulk reads will copy the same
value repeatedly into the buffer.

This patch only adds support to regmap-raw-ram, since regmap-ram does
not support bulk operations.

Signed-off-by: Ben Wolsieffer &lt;ben.wolsieffer@hefring.com&gt;
Link: https://lore.kernel.org/r/20231102203039.3069305-1-ben.wolsieffer@hefring.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: Add debugfs file for forcing field writes</title>
<updated>2023-06-13T12:15:04+00:00</updated>
<author>
<name>Waqar Hameed</name>
<email>waqar.hameed@axis.com</email>
</author>
<published>2023-06-13T11:42:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b629c698eae745eb51b6d92395e2eee44bbf5f49'/>
<id>urn:sha1:b629c698eae745eb51b6d92395e2eee44bbf5f49</id>
<content type='text'>
`_regmap_update_bits()` checks if the current register value differs
from the new value, and only writes to the register if they differ. When
testing hardware drivers, it might be desirable to always force a
register write, for example when writing to a `regmap_field`. This
enables and simplifies testing and verification of the hardware
interaction. For example, when using a hardware mock/simulation model,
one can then more easily verify that the driver makes the correct
expected register writes during certain events.

Add a bool variable `force_write_field` and a corresponding debugfs
entry to enable this. Since this feature could interfere with driver
operation, guard it with a macro.

Signed-off-by: Waqar Hameed &lt;waqar.hameed@axis.com&gt;
Link: https://lore.kernel.org/r/pnd1qifa7sj.fsf@axis.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: Provide basic test coverage for raw I/O</title>
<updated>2023-06-12T17:14:53+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2023-06-12T17:14:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ecfb8ce26d02ec136b4e1ae8c5a77d22d335057b'/>
<id>urn:sha1:ecfb8ce26d02ec136b4e1ae8c5a77d22d335057b</id>
<content type='text'>
Merge series from Mark Brown &lt;broonie@kernel.org&gt;:

Our existing coverage only deals with buses that provide single register
read and write operations, extend it to cover raw buses using a similar
approach with a RAM backed register map that the tests can inspect to
check operations.  This coverage could be more complete but provides a
good start.
</content>
</entry>
<entry>
<title>regmap: Don't check for changes in regcache_set_val()</title>
<updated>2023-06-12T13:51:07+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2023-06-10T14:05:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d32758acbd4eee8ce95b705a6760526b4d26c2aa'/>
<id>urn:sha1:d32758acbd4eee8ce95b705a6760526b4d26c2aa</id>
<content type='text'>
The only user of regcache_set_val() ignores the return value so we may as
well not bother checking if the value we are trying to set is the same as
the value already stored.

Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Link: https://lore.kernel.org/r/20230609-regcache-set-val-no-ret-v1-1-9a6932760cf8@kernel.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: maple: Implement block sync for the maple tree cache</title>
<updated>2023-06-12T13:51:06+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2023-06-11T12:06:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bfa0b38c148379c8a8c52e23bbdcb086414fb354'/>
<id>urn:sha1:bfa0b38c148379c8a8c52e23bbdcb086414fb354</id>
<content type='text'>
For register maps where we can write multiple values in a single bus
operation it is generally much faster to do so. Improve the performance of
maple tree cache syncs on such devices by identifying blocks of adjacent
registers that need to be written out and combining them into a single
operation.

Combining writes does mean that we need to allocate a scratch buffer and
format the data into it but it is expected that for most cases where caches
are in use the cost of I/O will be much greater than the cost of doing the
allocation and format.

Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Link: https://lore.kernel.org/r/20230609-regcache-maple-sync-raw-v1-1-8ddeb4e2b9ab@kernel.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: Provide a ram backed regmap with raw support</title>
<updated>2023-06-12T13:47:54+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2023-06-11T13:25:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=65dd2f671875b1d97b6fa9bcf7677f5e1c55f776'/>
<id>urn:sha1:65dd2f671875b1d97b6fa9bcf7677f5e1c55f776</id>
<content type='text'>
Provide a simple, 16 bit only, RAM backed regmap which supports raw I/O for
use in testing.

Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Link: https://lore.kernel.org/r/20230610-regcache-raw-kunit-v1-1-583112cd28ac@kernel.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: allow upshifting register addresses before performing operations</title>
<updated>2023-04-07T16:28:19+00:00</updated>
<author>
<name>Maxime Chevallier</name>
<email>maxime.chevallier@bootlin.com</email>
</author>
<published>2023-04-07T15:26:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4a670ac3e75e517c96cbd01ef870dbd598c3ce71'/>
<id>urn:sha1:4a670ac3e75e517c96cbd01ef870dbd598c3ce71</id>
<content type='text'>
Similar to the existing reg_downshift mechanism, that is used to
translate register addresses on busses that have a smaller address
stride, it's also possible to want to upshift register addresses.

Such a case was encountered when network PHYs and PCS that usually sit
on a MDIO bus (16-bits register with a stride of 1) are integrated
directly as memory-mapped devices. Here, the same register layout
defined in 802.3 is used, but the register now have a larger stride.

Introduce a mechanism to also allow upshifting register addresses.
Re-purpose reg_downshift into a more generic, signed reg_shift, whose
sign indicates the direction of the shift. To avoid confusion, also
introduce macros to explicitly indicate if we want to downshift or
upshift.

For bisectability, change any use of reg_downshift to use reg_shift.

Signed-off-by: Maxime Chevallier &lt;maxime.chevallier@bootlin.com&gt;
Tested-by: Colin Foster &lt;colin.foster@in-advantage.com&gt;
Link: https://lore.kernel.org/r/20230407152604.105467-1-maxime.chevallier@bootlin.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
</feed>
