Re: [PATCH 1/3] TI QSPI: Fix fclk frequency

[Tony Lindgren <tony@xxxxxxxxxxx>]

* Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> [191210 21:46]:
> Tony,
> 
> On Tue, Dec 10, 2019 at 10:02 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> >
> > * Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> [191210 19:22]:
> > > On Tue, Dec 10, 2019 at 6:03 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> > > > Well can test again with the patch below to see if that is
> > > > enough to make it work :)
> > >
> > > This patch works OK! The correct clock is in use by the driver. The
> > > hwmod warning shows up at boot:
> > > [    0.103567] omap_hwmod: qspi: no dt node
> > > [    0.103599] ------------[ cut here ]------------
> > > [    0.103639] WARNING: CPU: 0 PID: 1 at
> > > arch/arm/mach-omap2/omap_hwmod.c:2414 _init.constprop.29+0x198/0x4a0
> > > [    0.103654] omap_hwmod: qspi: doesn't have mpu register target base
> >
> > OK good to hear. That warning will go away when the legacy platform
> > data is removed. So the patch needs to initially still keep the
> > "ti,hwmods" property until we remove the legacy platform data.
> Can the patch be submitted like it is now? If so I am preparing a v2 series.

I just posted these two patches with you in Cc:

ARM: OMAP2+: Drop legacy platform data for am4 qspi
ARM: dts: Configure interconnect target module for am4 qspi

I'll be adding these two into omap-for-v5.6/dt in few days
if no comments. It seems the driver changes can be sent
separately from the dts changes.

> > > Glad to help to get to the final solution, please let me know how I
> > > can help on that.
> >
> > Well is this needed as a fix or can it wait for the v5.6 merge window?
> It can wait since this is an improvement, not a bugfix. Does that sound good?

OK sounds good to me.

> > If it's needed as a fix, some kind of description for the issue
> > fixed is needed. Any ideas there?
> >
> > We know the right clock is not found by the driver, but I'm now
> > wondering if this ever worked or has there been some bootloader
> > dependency?
> The motivation is to optimize the SPI transfer speed, especially for
> the SPI flash devices.
> With the current code if a 48MHz SPI clock is required, the effective
> clock will be at a 16MHz frequency.
> There is no bootloader dependency afaik, U-Boot uses a macro that
> defines the fixed 48MHz of the PER clock.

Oh OK, makes sense now. So wrong clock rate, thanks for explaining.

Regards,

Tony