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

[Schrempf Frieder <frieder.schrempf@xxxxxxxxxx>]

Hi Yogesh,

On 31.10.18 17:03, Yogesh Narayan Gaur wrote:
> Hi Frieder,
> 
>> -----Original Message-----
>> From: Boris Brezillon [mailto:boris.brezillon@xxxxxxxxxxx]
>> Sent: Wednesday, October 31, 2018 8:01 PM
>> To: Schrempf Frieder <frieder.schrempf@xxxxxxxxxx>
>> Cc: linux-mtd@xxxxxxxxxxxxxxxxxxx; linux-spi@xxxxxxxxxxxxxxx;
>> dwmw2@xxxxxxxxxxxxx; computersforpeace@xxxxxxxxx;
>> marek.vasut@xxxxxxxxx; richard@xxxxxx; miquel.raynal@xxxxxxxxxxx;
>> broonie@xxxxxxxxxx; David Wolfe <david.wolfe@xxxxxxx>; Fabio Estevam
>> <fabio.estevam@xxxxxxx>; Prabhakar Kushwaha
>> <prabhakar.kushwaha@xxxxxxx>; Yogesh Narayan Gaur
>> <yogeshnarayan.gaur@xxxxxxx>; Han Xu <han.xu@xxxxxxx>;
>> shawnguo@xxxxxxxxxx
>> Subject: Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework
>>
>> 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).
> In next version, please take care of the comments being raised by Boris in NXP FlexSPI controller driver patch series. E.g.
> 1. Redefine all mask fields and use BIT(X) for single bit set/unset.
> 2. Remove function pointer hooks for ->read/->write function.
> 3. Remove dependency from 'endianess' property from DTS node.
> 4. Usage of readl_poll_timeout() instead of busy looping.

Thanks for reminding me. I have these on my list.

Thanks,
Frieder

> 
> --
> Regards
> Yogesh Gaur
> 
>   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.