Hi Simon,
On Sat, 3 Oct 2026 at 06:41, Simon Glass <[email protected]> wrote:
> Please can you override just max_hz here?
Yes, v2 will override only max_hz and keep the mode from the DT.
> Their flashes are now probed at that speed and stay there, since
> slave->max_hz keeps it, rather than running at spi-max-frequency as
> they do today.
Checking this led me through the history:
- 96907c0fe50a and b0cc1b846fcb ("dm: spi: Read default speed and mode
values from DT", 2016 and 2019): a device with a DT node gets the DT
values; the second says "even if speed and mode are requested" and
names SPL boot and the splash screen. The SF_DEFAULT_SPEED help says
the same.
- e2e95e5e2542 ("spi: Update speed/mode on change", 2021): after the
probe, _spi_get_bus_and_cs() calls spi_set_speed_mode() with the
requested speed but does not update bus_data->speed.
- 3feea0ba196a ("spi: spi_flash_probe_bus_cs() rely on DT for spi speed
and mode", 2022): callers that want the DT values use
spi_flash_probe_bus_cs(); sf probe uses spi_flash_probe() only when a
speed or mode is given.
On sandbox at a6ab6a66146, spi_flash_probe(0, 0, 1000000, 0) on
spi.bin@0 (40 MHz in the DT) leaves the controller at 1 MHz after the
probe, after spi_claim_bus() and after spi_flash_read(), while
slave->max_hz and bus_data->speed stay at 40 MHz: the claim compares
against the stale cache and does not reprogram the bus. rk_spi behaves
the same, as its set_speed() takes effect on the next transfer. So
these callers already run at the requested speed after the probe; only
the ID read happens at spi-max-frequency. It also makes a sentence in
my v1 commit message wrong ("the next claim of the bus goes back to
that frequency").
> Just to check: should a requested speed above spi-max-frequency be
> honoured here, rather than capped at it?
I don't think this choice is mine to make; it is about what the SPI
uclass should promise. The options I see:
A. Keep the v1 scope and override only max_hz for the probe, so the
probe runs at the speed the callers already get after it, uncapped
as today.
B. Honour the speed only for an explicit request from the shell
(sf probe with a speed), where whoever is debugging answers for the
value, and keep the DT speed for everyone else. That also needs the
path from e2e95e5e2542 to stop overriding the DT speed for them,
which is a separate fix.
Which would you prefer? I will also add the checks you suggested to
the test, on spi.bin@1, whose DT node sets spi-cpol and spi-cpha, so
lost mode bits show up.
Regards,
Igor
