Skip to content

[pull] master from torvalds:master #1948

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jun 20, 2025
Merged

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 20, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

thierryreding and others added 4 commits June 13, 2025 17:30
The DMA memory for this driver is allocated using dma_alloc_coherent(),
which ends up mapping the allocated memory as uncached. Performing the
various dma_sync_*() operations on this memory causes issues during SPI
flashing:

[    7.818017] pc : dcache_inval_poc+0x40/0x58
[    7.822128] lr : arch_sync_dma_for_cpu+0x2c/0x4c
[    7.826854] sp : ffff80008193bcf0
[    7.830267] x29: ffff80008193bcf0 x28: ffffa3fe5ff1e908 x27: ffffa3fe627bb130
[    7.837528] x26: ffff000086952180 x25: ffff00008015c8ac x24: ffff000086c9b480
[    7.844878] x23: ffff00008015c800 x22: 0000000000000002 x21: 0000000000010000
[    7.852229] x20: 0000000106dae000 x19: ffff000080112410 x18: 0000000000000001
[    7.859580] x17: ffff000080159400 x16: ffffa3fe607a9bd8 x15: ffff0000eac1b180
[    7.866753] x14: 000000000000000c x13: 0000000000000001 x12: 000000000000025a
[    7.874104] x11: 0000000000000000 x10: 7f73e96357f6a07f x9 : db1fc8072a7f5e3a
[    7.881365] x8 : ffff000086c9c588 x7 : ffffa3fe607a9bd8 x6 : ffff80008193bc28
[    7.888630] x5 : 000000000000ffff x4 : 0000000000000009 x3 : 000000000000003f
[    7.895892] x2 : 0000000000000040 x1 : ffff000086dbe000 x0 : ffff000086db0000
[    7.903155] Call trace:
[    7.905606]  dcache_inval_poc+0x40/0x58 (P)
[    7.909804]  iommu_dma_sync_single_for_cpu+0xb4/0xb8
[    7.914617]  __dma_sync_single_for_cpu+0x158/0x194
[    7.919428]  __this_module+0x5b020/0x5baf8 [spi_tegra210_quad]
[    7.925291]  irq_thread_fn+0x2c/0xc0
[    7.928966]  irq_thread+0x16c/0x318
[    7.932467]  kthread+0x12c/0x214

Fix this by removing all calls to the dma_sync_*() functions. This isn't
ideal because DMA is used only for relatively large (> 64 words or 256
bytes) and using uncached memory for this might be slow. Reworking this
to use cached memory for faster access and reintroducing the cache
maintenance calls is probably worth a follow-up patch.

Reported-by: Brad Griffis <[email protected]>
Fixes: 017f1b0 ("spi: tegra210-quad: Add support for internal DMA")
Signed-off-by: Thierry Reding <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
The datasheets for all the fan53555 variants (and clones using the same
interface) define so called soft start times, from enabling the regulator
until at least some percentage of the output (i.e. 92% for the rk860x
types) are available.

The regulator framework supports this with the enable_time property
but currently the fan53555 driver does not define enable_times for any
variant.

I ran into a problem with this while testing the new driver for the
Rockchip NPUs (rocket), which does runtime-pm including disabling and
enabling a rk8602 as needed. When reenabling the regulator while running
a load, fatal hangs could be observed while enabling the associated
power-domain, which the regulator supplies.

Experimentally setting the regulator to always-on, made the issue
disappear, leading to the missing delay to let power stabilize.
And as expected, setting the enable-time to a non-zero value
according to the datasheet also resolved the regulator-issue.

The datasheets in nearly all cases only specify "typical" values,
except for the fan53555 type 08. There both a typical and maximum
value are listed - 40uS apart.

For all typical values I've added 100uS to be on the safe side.
Individual details for the relevant regulators below:

- fan53526:
  The datasheet for all variants lists a typical value of 150uS, so
  make that 250uS with safety margin.
- fan53555:
  types 08 and 18 (unsupported) are given a typical enable time of 135uS
  but also a maximum of 175uS so use that value. All the other types only
  have a typical time in the datasheet of 300uS, so give a bit margin by
  setting it to 400uS.
- rk8600 + rk8602:
  Datasheet reports a typical value of 260us, so use 360uS to be safe.
- syr82x + syr83x:
  All datasheets report typical soft-start values of 300uS for these
  regulators, so use 400uS.
- tcs452x:
  Datasheet sadly does not report a soft-start time, so I've not set
  an enable-time

Signed-off-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
…inux/kernel/git/broonie/regulator

Pull regulator fix from Mark Brown:
 "One patch here from Heiko which fixes stability issues on some
  Rockchip platforms by implementing soft start support and providing
  startup time information for their regulators"

* tag 'regulator-fix-v6.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: fan53555: add enable_time support and soft-start times
…ernel/git/broonie/spi

Pull spi fix from Mark Brown:
 "One fix here from Thierry, fixing crashes caused by attempting to do
  cache sync operations on uncached memory on Tegra platforms"

* tag 'spi-fix-v6.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: tegra210-qspi: Remove cache operations
@pull pull bot added the ⤵️ pull label Jun 20, 2025
@pull pull bot merged commit 41687a5 into AwesomeGitHubRepos:master Jun 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants