[PATCH 3/3] armv7: ls102xa: fix SPI flash clock

[Vladimir Oltean]

On Wed, Mar 18, 2026 at 03:29:17PM +0100, Michael Walle wrote:
> Commit bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")
> broke the SPI boot on the LS1021ATSN board (ls1021atsn_qspi_defconfig)
> at least.
> 
> The commit message reads
>    Update SCFG_QSPI_CLKSEL value : 0xC -> 0x5
>    which means ClusterPLL/16
> 
> The original submitted patch had the following description:
>    Value 0xC is reserved. Replace it with correct value 0x5 which
>    is ClusterPLL/16
> 
> Unfortunatly, the little information which was there, was stripped even
> further. Why is 0x5 the "correct" value? In fact, it seems that the
> upper bit is just ignored and thus the value 0xC translates to 0x4 which
> is ClusterPLL/20. This, will result in a SPI clock of 60MHz (if the PLL
> is clocked at 1.2GHz). But even that is too much for the (default) 03h
> read opcode (max 50MHz). Set the value to ClusterPLL/24 which is 50MHz.
> 
> Link: https://lore.kernel.org/r/1568804284-25162-1-git-send-email-kuldeep.singh@nxp.com/
> Fixes: bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")
> Signed-off-by: Michael Walle <mwalle at kernel.org>
> 
> ---
> If someone still wants to have a faster clock frequency, because they
> are using the fast read opcode or so, I'd suggest to actually implement
> the .set_speed op in the driver.
> ---

Reviewed-by: Vladimir Oltean <olteanv at gmail.com>

I think we have a problem in the RCW as well.
https://github.com/nxp-qoriq/rcw/blob/devel/ls1021atsn/SSR_PNS_30/rcw_1200_qspiboot.rcw#L8
Those values should be interpreted as bit reversed (so 0x00000803 is
0xC0100000, i.e. the same value as U-Boot used to write prior to commit
bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")).

They are reversed because we write to SCFG_QSPI_CFG prior to writing to
SCFG_SCFGREVCR. In fact the documentation says about the SCFG bit
reverse register "This register must be written 0xFFFF_FFFF as a part of
initialization sequence before writing to any other SCFG register."

So it seems the QSPI clock frequency might be already out of range
before U-Boot brings it in range with your patch still.

I can take additional RCW patches if you're willing to send them.
Plus, I see since commit ba89878d7029 ("armv7: ls102xa: make QSPI clock
selection optional during SoC init") that SYS_FSL_QSPI_SKIP_CLKSEL is an
option too, maybe that's of interest.