[EXT] Re: [Patch v4 0/7] Transition of fsl qspi driver to spi-mem framework

Schrempf Frieder frieder.schrempf at kontron.de
Mon Jan 27 10:47:20 CET 2020


Hi,

On 27.01.20 10:20, Kuldeep Singh wrote:
> Hi Jagan,
> 
>> -----Original Message-----
>> From: Jagan Teki <jagan at amarulasolutions.com>
>> Sent: Monday, January 27, 2020 12:50 PM
>> To: Kuldeep Singh <kuldeep.singh at nxp.com>
>> Cc: U-Boot-Denx <u-boot at lists.denx.de>; Priyanka Jain
>> <priyanka.jain at nxp.com>; Ashish Kumar <ashish.kumar at nxp.com>; Stefan
>> Roese <sr at denx.de>; Schrempf Frieder <frieder.schrempf at kontron.de>;
>> Vignesh R <vigneshr at ti.com>
>> Subject: [EXT] Re: [Patch v4 0/7] Transition of fsl qspi driver to spi-mem
>> framework
>>
>> Caution: EXT Email
>>
>> Hi Kuldeep,
>>
>> On Mon, Jan 13, 2020 at 12:57 PM Kuldeep Singh <kuldeep.singh at nxp.com>
>> wrote:
>>>
>>> This entire patch series migrate freescale qspi driver to spi-mem
>>> framework.
>>>
>>> v4 version of series include removal of buildman failure on LS2080AQDS
>>> build which was observed in cleanup patches. Also, more clear commit
>>> message of patch 5.
>>>
>>> v3 version of series includes correction of copyright in qspi driver
>>> and also move SPI_FLASH_SPANSION from header to defconfigs in same
>> patch.
>>>
>>> v2 version of series includes changes in qspi driver to have 1k size
>>> instead of complete flash size so as to make driver independent of
>>> flash size. This also makes it align with linux version of driver.
>>> Also added support for imx platforms to set TDH bits correctly. There
>>> are other minor changes in commit messages.
>>>
>>> Dependency on patches[1][2]. These patches are required to resolve
>>> booting crash observed in LS1012ARDB. One crash was related to pfe
>>> driver as it was accessing flash memory directly and other was based on
>> environment.
>>> [1]
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>>
>> hwork.ozlabs.org%2Fpatch%2F1219462%2F&data=02%7C01%7Ckuldeep.s
>> ingh
>>> %40nxp.com%7C94b5e5528efc47df25ea08d7a2f94efd%7C686ea1d3bc2b4c6
>> fa92cd9
>>>
>> 9c5c301635%7C0%7C0%7C637157063972042137&sdata=DZFAEmt0sA4c
>> cCPmu%2F
>>> cArl99B02G2KmiAUYou1RXXBI%3D&reserved=0
>>> [2]
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>>
>> hwork.ozlabs.org%2Fpatch%2F1208299%2F&data=02%7C01%7Ckuldeep.s
>> ingh
>>> %40nxp.com%7C94b5e5528efc47df25ea08d7a2f94efd%7C686ea1d3bc2b4c6
>> fa92cd9
>>>
>> 9c5c301635%7C0%7C0%7C637157063972042137&sdata=3qr7QKERZgk8
>> V83QbYMM
>>> Nb4xM4rUaqm2v3lZ5gzsGAQ%3D&reserved=0
>>>
>>> Patch 1 adds new qspi driver incorporating spi-mem framework and also
>>> removal of old driver which was based on spi-nor. The driver is a
>>> ported version of linux qspi driver. Initial port was done by Frieder.
>>> Now, no more direct memory access to spi-nor memory is possible i.e
>>> accessing flash memory using absolute address is not possible.
>>>
>>> Patch 2 removes unused qspi config options.
>>>
>>> Patch 3 moves FSL_QSPI to defconfig instead of defining it in header files.
>>>
>>> Patch 4 removes unused num-cs property from imx platforms.
>>>
>>> Patch 5 enables SPI_FLASH_SPANSION in ls1012a defconfig as FSL_QSPI is
>>> already enabled.
>>>
>>> Patch 6 enables SPI_FLASH_SPANSION in defconfigs of LS1046a boards
>>> instead of defining in header files.
>>>
>>> Patch 7 updates the device-tree properties treewide for layerscape
>>> boards by aligning with linux device-tree properties.
>>>
>>> Frieder Schrempf (1):
>>>    imx: imx6sx: Remove unused 'num-cs' property
>>>
>>> Kuldeep Singh (6):
>>>    spi: Transform the FSL QuadSPI driver to use the SPI MEM API
>>>    treewide: Remove unused FSL QSPI config options
>>>    configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
>>>    configs: ls1012a: Enable CONFIG_SPI_FLASH_SPANSION in defconfigs
>>>    configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
>>>    treewide: Update fsl qspi node dt properties as per spi-mem driver
>>
>> Seems like defconfig changes of these were depends on net changes isn't it? if
>> yes, we need to wait for them to merge first.
> 
> Actually, net change is required to resolve the booting crash on LS1012ARDB  with this driver.
> This series can be applied even without net pfe patch.

It could be applied without and as you sad it would break the boot for 
LS1012ARDB.

Therefore no, I don't think we should apply patches that knowingly break 
things, just because changes elsewhere are not merged yet.

So can the maintainers (Joe, Jagan, ...) please figure out how to get 
[1] merged so we don't block this patch any longer?

Thanks,
Frieder

[1]: https://patchwork.ozlabs.org/patch/1222025/


More information about the U-Boot mailing list