Re: [PATCH v2 1/2] mtd: spi-nor: macronix: add support for Macronix octaflash

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Pratyush,

On Tue, Feb 23, 2021 at 4:25 PM Pratyush Yadav <p.yadav@ti.com> wrote:
> On 23/02/21 01:36PM, Mark Brown wrote:
> > On Tue, Feb 23, 2021 at 02:13:44PM +0100, Miquel Raynal wrote:
> > > Pratyush Yadav <p.yadav@ti.com> wrote on Fri, 5 Feb 2021 19:04:04 +0530:
> >
> > > > [0] Since SPI NOR has no way of knowing what speed the controller is
> > > > running at, assume the fastest speed the flash can run at.
> >
> > > Ok, I am not entirely clear about what is available/not available from
> > > the SPI core.
> >
> > > If this is true then I guess we can't do better with the current code
> > > base and this can be improved in the future if needed. So I'm fine with
> > > the current implementation.
> >
> > For normal SPI operations you can set the speed (really, top speed) on a
> > per transfer basis.
>
> To select the optimal number of dummy cycles we need to know what speed
> the controller is running at, not the other way around. The flash would
> always set the top speed to its maximum (say 200 MHz). But if the
> controller is only capable of running at 50 MHz, you will end up wasting
> dummy cycles. I don't see any API to communicate speed from controller
> to flash.

spi_transfer.effective_speed_hz?

If the driver has filled this in (after the first transfer), you can optimize
dummy cycles before doing the next transfer.  Note that effective_speed_hz
might not always be the same, if e.g. the SPI controller shares its parent
clock with another component.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds