[PATCH v1] spi: add STM32F7 QSPI controller driver

[Oleksij Rempel]

On Tue, Apr 01, 2025 at 10:53:44AM +0200, Ahmad Fatoum wrote:
> Hello Oleksij,
> 
> On 3/31/25 14:29, Oleksij Rempel wrote:
> > From: Ahmad Fatoum <a.fatoum at pengutronix.de>
> > 
> > Introduce support for the STM32F7 QSPI controller, compatible with
> > "st,stm32f469-qspi".
> > 
> > Validated on STM32MP133-based MECT1S r1 board, which includes an
> > F7-compatible QSPI peripheral
> > 
> > Signed-off-by: Ahmad Fatoum <a.fatoum at pengutronix.de>
> > Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> > ---
> 
> [snip]
> 
> > +static int stm32_qspi_get_mode(u8 buswidth)
> 
> Is this ever called with a buswidth > 1? I think the spi_mem core in
> barebox never uses higher buswidths. Given that you are adding QSPI
> support, you will surely want to see quad buswidth actually working,
> right? :D

Sure :) I get it - every maintainer dreams of getting the most out of
each patch, and full QSPI support with quad buswidth would definitely be
nice to have.

But with this patch, we're going from “doesn't work at all” to “works,
just not at full speed yet.” That’s already a big step forward,
especially for bring-up and flashing use cases.

If we judged everything in Barebox by full performance, we’d probably
have to drop most of the networking drivers too - since Barebox usually
isn’t about maxing out throughput anyway ;)

So yes, proper quad support would be great - but for now, this patch
gets us something working, and that’s a solid starting point.

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |