Hello Jagan, Am 24.09.2013 20:38, schrieb Jagannadha Sutradharudu Teki: > This patch series is a combination of > "sf: Add common probe support" > "sf: Add support for extended/quad read and write commands" > http://www.mail-archive.com/u-boot@lists.denx.de/msg121668.html > http://u-boot.10912.n7.nabble.com/PATCH-v2-00-10-sf-Add-support-for-extended-quad-read-and-write-commands-td160964.html > > This patch series adds common probe support for all flash vendors except > ramtron. > > spi_flash_probe is a new addition where all flash driver > probing is combined into a common file, this means spi_flash_probe.c > adds a new probing style common to all flashes. > > > Apart from common probing, this series also adds support for > extended read commands and quad read/write commands. > > http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/150148 > http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/167026 > > There is a bit discussion going on for supporting this: > http://u-boot.10912.n7.nabble.com/PATCH-00-12-cmd-sf-Add-support-for-read-and-write-instructions-td143749.html > > Concept: > Initially I tried to add individual sf write/read commands to respective > flash read/write commands, but later some discussion to mainline about this > and > changed the implementation. > > As Michal and me were trying to change this as like the > "implementation will discover the fastest command by taking the supported > commands from flash and a controller. Controller supported commands will > always been a priority." > > Means I have added rd_cmd and wr_cmd params on spi_flash_id_params table. > So the flash user may fill these with flash supported commands, and also spi > controller > use is also have rd_cmd and wr_cmd from spi.h, so the spi user will fill > these with > controller supported commands. and the resultent command is calculated based > fastest > commands by taking inputs from spi and flash, but spi(controller) has always > a priority. > > Supported commands: > - CMD_READ_ARRAY_SLOW > - CMD_READ_ARRAY_FAST > - CMD_READ_DUAL_OUTPUT_FAST > - CMD_READ_DUAL_IO_FAST > - CMD_READ_QUAD_OUTPUT_FAST > - CMD_PAGE_PROGRAM > - CMD_QUAD_PAGE_PROGRAM I miss an important detail in this series, regarding dual/quad-io support: How is the spi controller is informed about the transfer details? I see only setting the cmds according the features of flash and controller, but no additional indication to the spi controller, that this is then a dual- or quad-io transfer.How the spi controller should know about this??? By decoding the cmd itself again? But the data should be a transparent byte stream to the controller! Otherwise you need a table of commands for decoding also inside the controller driver, which I consider a bad idea, as you need to update them (in each driver) for new cmds added to the serial-flash driver!
In the linux kernel, the solution in the spi layer was to add new elements to the transfer structure (struct spi_transfer -> bitwidth), which can be set for each part of a message. In u-boot we have the spi_xfer function, which has a "flags" parameter we could use for this. As long as the details for this (including a spi controller driver, which can handle dual/quad-io transfers) are not fixed, I would suggest to leave the patches regarding the extended cmds out of the series of sf-cleanup (which really looks good!) and fix the issues until the next merge window! > Testing repo branch: > ------------------- > $ git clone git://git.denx.de/u-boot-spi.git > $ cd u-boot-spi > $ git checkout -b master-next-test origin/master-next-test > > REQUEST FOR ALL SPI CODE CONTRIBUTORS/USERS, PLEASE TEST THESE CHANGES > W.R.T YOUR HW IF POSSIBLE. > > Please let me know for any issues/concerns/questions. > > -- > Thanks, > Jagan. Best Regards, Thomas _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot