Hi, On 26.04.19 06:58, Vignesh Raghavendra wrote: > > > On 25/04/19 5:20 PM, Rajat Srivastava wrote: >> >> >>> -----Original Message----- >>> From: Vignesh Raghavendra <vigne...@ti.com> >>> Sent: Wednesday, April 24, 2019 10:17 PM >>> To: Rajat Srivastava <rajat.srivast...@nxp.com>; u-boot@lists.denx.de; >>> ja...@openedev.com >>> Cc: Ashish Kumar <ashish.ku...@nxp.com> >>> Subject: [EXT] Re: [PATCH 2/2] fsl_qspi: Improve QSPI driver to incorporate >>> 4 >>> byte commands >>> >>> Caution: EXT Email >>> >>> On 24-Apr-19 6:10 PM, Rajat Srivastava wrote: >>>> Signed-off-by: Ashish Kumar <ashish.ku...@nxp.com> >>>> Signed-off-by: Rajat Srivastava <rajat.srivast...@nxp.com> >>> >>> Commit message is missing. >> >> I'll add proper commit message in the next patch version. >> >>> But from $patch subject, I infer that $patch is >>> adding new feature and not actually fixing something broken? >> >> Earlier the framework was designed to work for only 3-byte opcodes but our >> controller supports flashes of size greater than 16 MB. As a workaround, >> FSL QSPI driver used to explicitly send 4-byte opcodes for 3-byte opcodes >> sent by >> framework to the flash. Also there used to exist a temporary patch for >> framework >> which never got accepted In upstream. >> Now the new framework supports 4-byte opcodes and FSL QSPI driver needs >> correction. I am not introducing any new feature. I am just fixing the driver >> to suit the current framework. >> > > With SPL_FLASH_BAR set fsl_qspi driver should never see 4 byte opcodes > and should work like it did before. I guess you are disabling SPI_FLASH_BAR? > > Please add all details to the commit message and I recommend you to move > the driver over to spi-mem as soon as possible. Else you would have to > keep handling new opcodes in your driver as and when spi-nor-core changes. > > Regards > Vignesh > >> Please let me know your feedback. >> >> Regards >> Rajat >> >>> If so, you should move the driver over to use spi-mem APIs instead of adding >>> more features and hard coding more flash specific commands in the driver. >>> This makes driver duplicate more of spi-nor core code. I discourage adding >>> new features w/o moving driver over to spi-mem. IMHO, converting the >>> driver would not be a huge effort. And I believe its already done in kernel.
I started moving the driver to spi-mem, by porting the kernel driver over to U-Boot. I still have some Kconfig dependency problem for the LS2081 platform (CONFIG_SPI_MEM is not enabled implicitly), that needs to be solved, otherwise it should be more or less ready. For anyone who wants to check/test the current state, look here: [1] Regards, Frieder [1]: https://github.com/fschrempf/u-boot/commits/fsl_qspi_spimem_port _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
