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

[Boris Brezillon <boris.brezillon@xxxxxxxxxxx>]

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.