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

["Michael Walle" <mwalle@kernel.org>]

Hi,

On Thu Mar 19, 2026 at 3:11 PM CET, Vladimir Oltean wrote:
> Reviewed-by: Vladimir Oltean <olteanv@gmail.com>

Thanks!

> 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.

Yes, I've noticed that too. But we have our own repo of the RCWs for
our boards. But yeah, we've basically copied NXPs values. So the
60MHz speed is still lurking there. But instead of the 75MHz, 60MHz
seems to at least work (and nobody noticed).

> I can take additional RCW patches if you're willing to send them.

As said above, we have our own repo that isn't a fork of NXPs.

> 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.

I've seen that, but haven't looked further why there is that option.
Probably, to keep any custom clksel value ;)

-michael