Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Boris Brezillon <boris.brezillon@xxxxxxxxxxx>]

Hi Frieder,

On Thu, 8 Nov 2018 08:15:55 +0000
Schrempf Frieder <frieder.schrempf@xxxxxxxxxx> wrote:

> Hi Boris, hi Yogesh,
> 
> On 31.10.18 15:31, Boris Brezillon wrote:
> > On Wed, 31 Oct 2018 13:54:29 +0000
> > Schrempf Frieder <frieder.schrempf@xxxxxxxxxx> wrote:
> >   
> >> Hi Boris,
> >>
> >> On 31.10.18 14:40, Boris Brezillon wrote:  
> >>> Hi Frieder, Yogesh,
> >>>
> >>> On Thu,  5 Jul 2018 13:14:56 +0200
> >>> Frieder Schrempf <frieder.schrempf@xxxxxxxxx> wrote:
> >>>      
> >>>> Now that the SPI memory interface was introduced by Boris [1], it is
> >>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
> >>>> to use them for different type of SPI memory chips.
> >>>>
> >>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
> >>>> and a ->name field to struct spi_mem.
> >>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> >>>> drivers to provide a custom naming scheme for the flash chip.
> >>>> This is needed to avoid breaking compatibility of mtdparts when switching
> >>>> from the old to the new driver.
> >>>>
> >>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> >>>> framework. Together with m25p80.c it can be used to interface SPI
> >>>> NOR flashes just as the old driver did. For this to work properly a few
> >>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
> >>>>
> >>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
> >>>> the old driver.
> >>>>
> >>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> >>>> Patch 12 adjusts the MAINTAINERS file.
> >>>>
> >>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> >>>> The read performance of the new driver is almost the same or even better
> >>>> than the old driver, depending on the block size.
> >>>> The write performance is a bit slower on average (~10-15%).
> >>>>
> >>>> The new driver was also tested with the SPI NAND framework [2] and a
> >>>> Winbond W25M02GV flash.
> >>>>
> >>>> If someone has a board that uses both chips selects and/or both busses,
> >>>> it would be really nice to have the driver be tested on such a setup.  
> >>>
> >>> Any progress on this front? Yogesh, can you please remind us the
> >>> remaining issues? I'd really like to make some progress, otherwise the
> >>> conversion to spi-mem will take ages.  
> >>
> >> I definitely want to continue this. I just did not have the time to work
> >> on it.
> >>
> >> I think the only remaining blocking issues is the one that Yogesh
> >> reported while testing with two chips on the same bus.  
> > 
> > Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
> > and push it somewhere so that Yogesh can test it (again). Yogesh, can we
> > please make some progress on this? If you really have a bug, that'd be
> > great to have a serious investigation on what is causing this bug. The
> > explanation we had so far were not really helpful in understanding the
> > problem.  
> 
> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes 
> and cosmetic changes.
> 
> There is still the hack to avoid AHB buffer invalidation delay (not sure 
> if we should keep it for now)

IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay.
Maybe you can try that.

> and we still need to figure out the 
> reported problems with two chips on one bus.
> 
> As Yogesh is the only one how has a hardware setup for this, maybe you 
> can retry and provide some debugging info?
> 
> Unfortunately I'll probably do not have time to switch to the dirmap API 
> now, so I'd rather do that as a second step, as it probably won't solve 
> our problems either.

Totally agree with that.

Thanks for sending a v4.

Boris