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

[Schrempf Frieder <frieder.schrempf@xxxxxxxxxx>]

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) 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.

Thanks,
Frieder