diff options
author | Stephan Gerhold <stephan@gerhold.net> | 2023-05-18 15:04:25 +0200 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2023-05-30 13:43:31 +0100 |
commit | 0c331fd1dccfba657129380ee084b95c1cedfbef (patch) | |
tree | e1dc2b020ecad5732bc2c5ce2a047c1b1d2cafbe /Documentation/s390/vfio-ap.rst | |
parent | 4be47a5d59cbc9396a6ffd327913eb4c8d67a32f (diff) | |
download | linux-0c331fd1dccfba657129380ee084b95c1cedfbef.tar.gz linux-0c331fd1dccfba657129380ee084b95c1cedfbef.tar.bz2 linux-0c331fd1dccfba657129380ee084b95c1cedfbef.zip |
spi: qup: Request DMA before enabling clocks
It is usually better to request all necessary resources (clocks,
regulators, ...) before starting to make use of them. That way they do
not change state in case one of the resources is not available yet and
probe deferral (-EPROBE_DEFER) is necessary. This is particularly
important for DMA channels and IOMMUs which are not enforced by
fw_devlink yet (unless you use fw_devlink.strict=1).
spi-qup does this in the wrong order, the clocks are enabled and
disabled again when the DMA channels are not available yet.
This causes issues in some cases: On most SoCs one of the SPI QUP
clocks is shared with the UART controller. When using earlycon UART is
actively used during boot but might not have probed yet, usually for
the same reason (waiting for the DMA controller). In this case, the
brief enable/disable cycle ends up gating the clock and further UART
console output will halt the system completely.
Avoid this by requesting the DMA channels before changing the clock
state.
Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230518-spi-qup-clk-defer-v1-1-f49fc9ca4e02@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'Documentation/s390/vfio-ap.rst')
0 files changed, 0 insertions, 0 deletions