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

[Schrempf Frieder <frieder.schrempf@xxxxxxxxxx>]

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.

Han and I have both successfully tested with two chips, but on separate 
buses.

Regards,
Frieder
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/