* [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support
@ 2013-09-24 18:19 Jagannadha Sutradharudu Teki
2013-09-24 19:32 ` thomas.langer at lantiq.com
2013-09-26 23:05 ` Simon Glass
0 siblings, 2 replies; 8+ messages in thread
From: Jagannadha Sutradharudu Teki @ 2013-09-24 18:19 UTC (permalink / raw)
To: u-boot
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 at 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
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.
Jagannadha Sutradharudu Teki (36):
sf: Divide spi_flash into multiple parts
sf: probe: Add new spi_flash_probe support
sf: probe: Add support for M25P* flash parts
sf: probe: Add support for EN25Q* flash parts
sf: probe: Add support for GD25* flash parts
sf: probe: Add support for MX25L* flash parts
sf: probe: Add support for W25* flash parts
sf: probe: Add support for S25FL* flash parts
sf: probe: Add support for SST25* flash parts
sf: probe: Add support for AT45DB* flash parts
sf: probe: Give proper spacing on flash table params
sf: probe: Add support for SST_WP
sf: probe: Add support to clear flash BP# bits
sf: probe: Add support for erase sector selection flag
sf: probe: Add support for flag status polling
sf: probe: Move BAR config to spi_flash_validate_ids
sf: Add proper comment style on spi_flash structure
sf: ramtron: Add support for separate flash driver
sf: Remove unneeded flash drivers files
sf: probe: Add support for EN25Q64
sf: probe: Add support for S25FL256S_256K
sf: probe: Add support for S25FL512S_256K
sf: probe: Use print_size arg as page_size
sf: probe: Print erase_size while printing flash details
sf: probe: Simply the BAR configuration logic
sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write
sf: probe: Add support for MX25L25635F
sf: probe: Add support for MX25L51235F
sf: Remove spi_flash_do_alloc references
doc: SPI: Add status.txt for tracking SPI subsys status
sf: Add extended read commands support
sf: Add quad read/write commands support
sf: ops: Add configuration register writing support
sf: Set quad enable bit support
sf: spi_flash cleanups
spi: spi cleanups
doc/SPI/status.txt | 28 ++
drivers/mtd/spi/Makefile | 15 +-
drivers/mtd/spi/atmel.c | 544 ---------------------------------
drivers/mtd/spi/eon.c | 60 ----
drivers/mtd/spi/gigadevice.c | 65 ----
drivers/mtd/spi/macronix.c | 98 ------
drivers/mtd/spi/ramtron.c | 123 +++++++-
drivers/mtd/spi/spansion.c | 141 ---------
drivers/mtd/spi/spi_flash.c | 571 +----------------------------------
drivers/mtd/spi/spi_flash_internal.h | 151 ++++-----
drivers/mtd/spi/spi_flash_ops.c | 451 +++++++++++++++++++++++++++
drivers/mtd/spi/spi_flash_probe.c | 400 ++++++++++++++++++++++++
drivers/mtd/spi/sst.c | 238 ---------------
drivers/mtd/spi/stmicro.c | 202 -------------
drivers/mtd/spi/winbond.c | 141 ---------
drivers/spi/spi.c | 3 +
include/configs/top9000.h | 1 -
include/spi.h | 99 +++---
include/spi_flash.h | 119 ++++----
19 files changed, 1205 insertions(+), 2245 deletions(-)
create mode 100644 doc/SPI/status.txt
delete mode 100644 drivers/mtd/spi/atmel.c
delete mode 100644 drivers/mtd/spi/eon.c
delete mode 100644 drivers/mtd/spi/gigadevice.c
delete mode 100644 drivers/mtd/spi/macronix.c
delete mode 100644 drivers/mtd/spi/spansion.c
create mode 100644 drivers/mtd/spi/spi_flash_ops.c
create mode 100644 drivers/mtd/spi/spi_flash_probe.c
delete mode 100644 drivers/mtd/spi/sst.c
delete mode 100644 drivers/mtd/spi/stmicro.c
delete mode 100644 drivers/mtd/spi/winbond.c
--
1.8.3
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support
2013-09-24 18:19 [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support Jagannadha Sutradharudu Teki
@ 2013-09-24 19:32 ` thomas.langer at lantiq.com
2013-09-25 9:19 ` Jagan Teki
2013-09-26 23:05 ` Simon Glass
1 sibling, 1 reply; 8+ messages in thread
From: thomas.langer at lantiq.com @ 2013-09-24 19:32 UTC (permalink / raw)
To: u-boot
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 at 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support
2013-09-24 19:32 ` thomas.langer at lantiq.com
@ 2013-09-25 9:19 ` Jagan Teki
2013-09-25 11:13 ` thomas.langer at lantiq.com
0 siblings, 1 reply; 8+ messages in thread
From: Jagan Teki @ 2013-09-25 9:19 UTC (permalink / raw)
To: u-boot
Thanks for your comments, see below
On Wed, Sep 25, 2013 at 1:02 AM, <thomas.langer@lantiq.com> wrote:
> 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 at 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???
This 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 controller driver should have a code to support whether I am
supporting this
new extended read/write or quad command.
And this support will discover the fastest command by comparing the
commands from flash and spi.
flash anyway we added in params list and controller the respective
controller will initialize spi slave in the driver itself .
qspi->slave.rd_cmd = READ_CMD_FULL;
qspi->slave.wr_cmd = PAGE_PROGRAM | QUAD_PAGE_PROGRAM;
Please refer https://github.com/Xilinx/u-boot-xlnx/blob/master-next/drivers/spi/zynq_qspi.c
spi_flash layer should send any commands based on the respective
supported, but it is
supported by respective spi controller that should controller driver must aware.
This is more generic solution as we discussed so-many months ago.
http://u-boot.10912.n7.nabble.com/PATCH-00-12-cmd-sf-Add-support-for-read-and-write-instructions-td143749.html
We tried to discover the supported commands runtime from respective
flashes, but ie. going to be a huge
code to decode all these. Instead filling params, like sectors and
idcodes should be an code driven task as per as
u-boot code is concern.
> 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!
I am planning to push this series, as we started this since long months back.
We discussed many threads, and tested this approach on read hw as well.
Please let me know for any thoughts.
>
>> 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
--
Thanks,
Jagan.
--------
Jagannadha Sutradharudu Teki,
E: jagannadh.teki at gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support
2013-09-25 9:19 ` Jagan Teki
@ 2013-09-25 11:13 ` thomas.langer at lantiq.com
2013-09-25 11:30 ` Jagan Teki
0 siblings, 1 reply; 8+ messages in thread
From: thomas.langer at lantiq.com @ 2013-09-25 11:13 UTC (permalink / raw)
To: u-boot
Hello Jagan,
Jagan Teki wrote on?2013-09-25:
> Thanks for your comments, see below
>
> On Wed, Sep 25, 2013 at 1:02 AM, <thomas.langer@lantiq.com> wrote:
>> 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 at 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???
>
> This 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 controller driver should have a code to support whether I am
> supporting this
> new extended read/write or quad command.
>
> And this support will discover the fastest command by comparing the
> commands from flash and spi.
> flash anyway we added in params list and controller the respective
> controller will initialize spi slave in the driver itself .
>
> qspi->slave.rd_cmd = READ_CMD_FULL;
> qspi->slave.wr_cmd = PAGE_PROGRAM | QUAD_PAGE_PROGRAM;
>
> Please refer https://github.com/Xilinx/u-boot-xlnx/blob/master-
> next/drivers/spi/zynq_qspi.c
I had a look at this code. And found exactly, what I expected:
A huge table with flash opcodes!
Why does a spi controller need to know these details?
Because of information about, which part of a message needs single/dual or quad
transfers?
If we would do it this way, each spi controller needs to implement similar things!
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support
2013-09-25 11:13 ` thomas.langer at lantiq.com
@ 2013-09-25 11:30 ` Jagan Teki
0 siblings, 0 replies; 8+ messages in thread
From: Jagan Teki @ 2013-09-25 11:30 UTC (permalink / raw)
To: u-boot
On Wed, Sep 25, 2013 at 4:43 PM, <thomas.langer@lantiq.com> wrote:
> Hello Jagan,
>
> Jagan Teki wrote on 2013-09-25:
>
>> Thanks for your comments, see below
>>
>> On Wed, Sep 25, 2013 at 1:02 AM, <thomas.langer@lantiq.com> wrote:
>>> 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 at 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???
>>
>> This 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 controller driver should have a code to support whether I am
>> supporting this
>> new extended read/write or quad command.
>>
>> And this support will discover the fastest command by comparing the
>> commands from flash and spi.
>> flash anyway we added in params list and controller the respective
>> controller will initialize spi slave in the driver itself .
>>
>> qspi->slave.rd_cmd = READ_CMD_FULL;
>> qspi->slave.wr_cmd = PAGE_PROGRAM | QUAD_PAGE_PROGRAM;
>>
>> Please refer https://github.com/Xilinx/u-boot-xlnx/blob/master-
>> next/drivers/spi/zynq_qspi.c
>
> I had a look at this code. And found exactly, what I expected:
> A huge table with flash opcodes!
> Why does a spi controller need to know these details?
> Because of information about, which part of a message needs single/dual or quad
> transfers?
> If we would do it this way, each spi controller needs to implement similar things!
I am unable to understand your point here!.
There is no changes w.r.t to respective controller driver for this
support except if the specific driver support
then fill the supported commands.
discovering the fastest command and send spi_xfer is a job of spi_flash.
>
> From my point of view, this information should come from the serial flash driver!
> There you know details of manufacturer, supported opcodes and so on.
> And there you can decide, if you switch a flash to a "full quad" mode,
> that the same opcode now needs to be send on 4 lines!
> In the controller driver you don't know these details!
>
>>
>> spi_flash layer should send any commands based on the respective
>> supported, but it is supported by respective spi controller that should
>> controller driver must aware.
>>
>> This is more generic solution as we discussed so-many months ago.
>> http://u-boot.10912.n7.nabble.com/PATCH-00-12-cmd-sf-Add-support-for-
>> read-and-write-instructions-td143749.html
>
> Yes, I agree that this a huge step forward!
> But I think, we still have not reached a state which everyone can accept.
>
>>
>> We tried to discover the supported commands runtime from respective
>> flashes, but ie. going to be a huge
>> code to decode all these. Instead filling params, like sectors and
>> idcodes should be an code driven task as per as
>> u-boot code is concern.
>
> As I already said, this is very specific to your controller!
>
>>
>>> 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!
>>
>> I am planning to push this series, as we started this since long months back.
>> We discussed many threads, and tested this approach on read hw as well.
>>
>> Please let me know for any thoughts.
>
> I already said: Please leave some room for more discussions on the extended / quad read topic!
> And don't let the rest of the improvements be delayed by this!
>
>>
>>>
>>>> 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 at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
> Best Regards,
> Thomas
>
>
--
Thanks,
Jagan.
--------
Jagannadha Sutradharudu Teki,
E: jagannadh.teki at gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support
2013-09-24 18:19 [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support Jagannadha Sutradharudu Teki
2013-09-24 19:32 ` thomas.langer at lantiq.com
@ 2013-09-26 23:05 ` Simon Glass
2013-09-27 13:00 ` Tom Rini
1 sibling, 1 reply; 8+ messages in thread
From: Simon Glass @ 2013-09-26 23:05 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On Tue, Sep 24, 2013 at 12:19 PM, Jagannadha Sutradharudu Teki
<jagannadha.sutradharudu-teki@xilinx.com> wrote:
> 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 at 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
>
> 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.
>
> Jagannadha Sutradharudu Teki (36):
> sf: Divide spi_flash into multiple parts
> sf: probe: Add new spi_flash_probe support
> sf: probe: Add support for M25P* flash parts
> sf: probe: Add support for EN25Q* flash parts
> sf: probe: Add support for GD25* flash parts
> sf: probe: Add support for MX25L* flash parts
> sf: probe: Add support for W25* flash parts
> sf: probe: Add support for S25FL* flash parts
> sf: probe: Add support for SST25* flash parts
> sf: probe: Add support for AT45DB* flash parts
> sf: probe: Give proper spacing on flash table params
> sf: probe: Add support for SST_WP
> sf: probe: Add support to clear flash BP# bits
> sf: probe: Add support for erase sector selection flag
> sf: probe: Add support for flag status polling
> sf: probe: Move BAR config to spi_flash_validate_ids
> sf: Add proper comment style on spi_flash structure
> sf: ramtron: Add support for separate flash driver
> sf: Remove unneeded flash drivers files
> sf: probe: Add support for EN25Q64
> sf: probe: Add support for S25FL256S_256K
> sf: probe: Add support for S25FL512S_256K
> sf: probe: Use print_size arg as page_size
> sf: probe: Print erase_size while printing flash details
> sf: probe: Simply the BAR configuration logic
> sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write
> sf: probe: Add support for MX25L25635F
> sf: probe: Add support for MX25L51235F
> sf: Remove spi_flash_do_alloc references
> doc: SPI: Add status.txt for tracking SPI subsys status
> sf: Add extended read commands support
> sf: Add quad read/write commands support
> sf: ops: Add configuration register writing support
> sf: Set quad enable bit support
> sf: spi_flash cleanups
> spi: spi cleanups
>
> doc/SPI/status.txt | 28 ++
> drivers/mtd/spi/Makefile | 15 +-
> drivers/mtd/spi/atmel.c | 544 ---------------------------------
> drivers/mtd/spi/eon.c | 60 ----
> drivers/mtd/spi/gigadevice.c | 65 ----
> drivers/mtd/spi/macronix.c | 98 ------
> drivers/mtd/spi/ramtron.c | 123 +++++++-
> drivers/mtd/spi/spansion.c | 141 ---------
> drivers/mtd/spi/spi_flash.c | 571 +----------------------------------
> drivers/mtd/spi/spi_flash_internal.h | 151 ++++-----
> drivers/mtd/spi/spi_flash_ops.c | 451 +++++++++++++++++++++++++++
> drivers/mtd/spi/spi_flash_probe.c | 400 ++++++++++++++++++++++++
> drivers/mtd/spi/sst.c | 238 ---------------
> drivers/mtd/spi/stmicro.c | 202 -------------
> drivers/mtd/spi/winbond.c | 141 ---------
> drivers/spi/spi.c | 3 +
> include/configs/top9000.h | 1 -
> include/spi.h | 99 +++---
> include/spi_flash.h | 119 ++++----
> 19 files changed, 1205 insertions(+), 2245 deletions(-)
> create mode 100644 doc/SPI/status.txt
> delete mode 100644 drivers/mtd/spi/atmel.c
> delete mode 100644 drivers/mtd/spi/eon.c
> delete mode 100644 drivers/mtd/spi/gigadevice.c
> delete mode 100644 drivers/mtd/spi/macronix.c
> delete mode 100644 drivers/mtd/spi/spansion.c
> create mode 100644 drivers/mtd/spi/spi_flash_ops.c
> create mode 100644 drivers/mtd/spi/spi_flash_probe.c
> delete mode 100644 drivers/mtd/spi/sst.c
> delete mode 100644 drivers/mtd/spi/stmicro.c
> delete mode 100644 drivers/mtd/spi/winbond.c
>
> --
> 1.8.3
>
>
This series seems to add 700 bytes to code size. It isn't a huge
amount if the benefits are worth it, but is it necessary?
(try-spi=b35a52: b/) u> ./tools/buildman/buildman -b try-spi snow -sS --step 0
Summary of 2 commits for 1 boards (1 thread, 32 jobs per thread)
01: Sound: MAX98095: Support I2S0 channel
37: spi: spi cleanups
arm: (for 1/1 boards) all +702.0 bss +12.0 rodata +314.0 text +376.0
(try-spi=b35a52: b/) u>
(try-spi=b35a52: b/) u> ./tools/buildman/buildman -b try-spi snow -sS
...
19: sf: ramtron: Add support for separate flash driver
arm: (for 1/1 boards) all +423.0 bss +48.0 rodata +447.0 text -72.0
20: sf: Remove unneeded flash drivers files
arm: (for 1/1 boards) all -191.0 bss -16.0 rodata -175.0
21: sf: probe: Add support for EN25Q64
22: sf: probe: Add support for S25FL256S_256K
arm: (for 1/1 boards) bss -8.0 text +8.0
23: sf: probe: Add support for S25FL512S_256K
24: sf: probe: Use print_size arg as page_size
25: sf: probe: Print erase_size while printing flash details
arm: (for 1/1 boards) all +70.0 bss +24.0 rodata +14.0 text +32.0
26: sf: probe: Simply the BAR configuration logic
27: sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write
28: sf: probe: Add support for MX25L25635F
29: sf: probe: Add support for MX25L51235F
30: sf: Remove spi_flash_do_alloc references
31: doc: SPI: Add status.txt for tracking SPI subsys status
32: sf: Add extended read commands support
arm: (for 1/1 boards) all +136.0 bss +8.0 rodata +16.0 text +112.0
33: sf: Add quad read/write commands support
arm: (for 1/1 boards) all +72.0 bss -36.0 rodata +12.0 text +96.0
34: sf: ops: Add configuration register writing support
arm: + snow
35: sf: Set quad enable bit support
arm: snow
arm: (for 1/1 boards) all +192.0 bss -8.0 text +200.0
36: sf: spi_flash cleanups
37: spi: spi cleanups
Regards,
Simon
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support
2013-09-26 23:05 ` Simon Glass
@ 2013-09-27 13:00 ` Tom Rini
2013-09-27 13:39 ` Jagan Teki
0 siblings, 1 reply; 8+ messages in thread
From: Tom Rini @ 2013-09-27 13:00 UTC (permalink / raw)
To: u-boot
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/26/2013 07:05 PM, Simon Glass wrote:
> Hi Jagan,
>
> On Tue, Sep 24, 2013 at 12:19 PM, Jagannadha Sutradharudu Teki
> <jagannadha.sutradharudu-teki@xilinx.com> wrote:
>> 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 at 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
>>
>> 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.
>>
>> Jagannadha Sutradharudu Teki (36):
>> sf: Divide spi_flash into multiple parts
>> sf: probe: Add new spi_flash_probe support
>> sf: probe: Add support for M25P* flash parts
>> sf: probe: Add support for EN25Q* flash parts
>> sf: probe: Add support for GD25* flash parts
>> sf: probe: Add support for MX25L* flash parts
>> sf: probe: Add support for W25* flash parts
>> sf: probe: Add support for S25FL* flash parts
>> sf: probe: Add support for SST25* flash parts
>> sf: probe: Add support for AT45DB* flash parts
>> sf: probe: Give proper spacing on flash table params
>> sf: probe: Add support for SST_WP
>> sf: probe: Add support to clear flash BP# bits
>> sf: probe: Add support for erase sector selection flag
>> sf: probe: Add support for flag status polling
>> sf: probe: Move BAR config to spi_flash_validate_ids
>> sf: Add proper comment style on spi_flash structure
>> sf: ramtron: Add support for separate flash driver
>> sf: Remove unneeded flash drivers files
>> sf: probe: Add support for EN25Q64
>> sf: probe: Add support for S25FL256S_256K
>> sf: probe: Add support for S25FL512S_256K
>> sf: probe: Use print_size arg as page_size
>> sf: probe: Print erase_size while printing flash details
>> sf: probe: Simply the BAR configuration logic
>> sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write
>> sf: probe: Add support for MX25L25635F
>> sf: probe: Add support for MX25L51235F
>> sf: Remove spi_flash_do_alloc references
>> doc: SPI: Add status.txt for tracking SPI subsys status
>> sf: Add extended read commands support
>> sf: Add quad read/write commands support
>> sf: ops: Add configuration register writing support
>> sf: Set quad enable bit support
>> sf: spi_flash cleanups
>> spi: spi cleanups
>>
>> doc/SPI/status.txt | 28 ++
>> drivers/mtd/spi/Makefile | 15 +-
>> drivers/mtd/spi/atmel.c | 544 ---------------------------------
>> drivers/mtd/spi/eon.c | 60 ----
>> drivers/mtd/spi/gigadevice.c | 65 ----
>> drivers/mtd/spi/macronix.c | 98 ------
>> drivers/mtd/spi/ramtron.c | 123 +++++++-
>> drivers/mtd/spi/spansion.c | 141 ---------
>> drivers/mtd/spi/spi_flash.c | 571 +----------------------------------
>> drivers/mtd/spi/spi_flash_internal.h | 151 ++++-----
>> drivers/mtd/spi/spi_flash_ops.c | 451 +++++++++++++++++++++++++++
>> drivers/mtd/spi/spi_flash_probe.c | 400 ++++++++++++++++++++++++
>> drivers/mtd/spi/sst.c | 238 ---------------
>> drivers/mtd/spi/stmicro.c | 202 -------------
>> drivers/mtd/spi/winbond.c | 141 ---------
>> drivers/spi/spi.c | 3 +
>> include/configs/top9000.h | 1 -
>> include/spi.h | 99 +++---
>> include/spi_flash.h | 119 ++++----
>> 19 files changed, 1205 insertions(+), 2245 deletions(-)
>> create mode 100644 doc/SPI/status.txt
>> delete mode 100644 drivers/mtd/spi/atmel.c
>> delete mode 100644 drivers/mtd/spi/eon.c
>> delete mode 100644 drivers/mtd/spi/gigadevice.c
>> delete mode 100644 drivers/mtd/spi/macronix.c
>> delete mode 100644 drivers/mtd/spi/spansion.c
>> create mode 100644 drivers/mtd/spi/spi_flash_ops.c
>> create mode 100644 drivers/mtd/spi/spi_flash_probe.c
>> delete mode 100644 drivers/mtd/spi/sst.c
>> delete mode 100644 drivers/mtd/spi/stmicro.c
>> delete mode 100644 drivers/mtd/spi/winbond.c
>>
>> --
>> 1.8.3
>>
>>
>
> This series seems to add 700 bytes to code size. It isn't a huge
> amount if the benefits are worth it, but is it necessary?
>
> (try-spi=b35a52: b/) u> ./tools/buildman/buildman -b try-spi snow -sS --step 0
> Summary of 2 commits for 1 boards (1 thread, 32 jobs per thread)
> 01: Sound: MAX98095: Support I2S0 channel
> 37: spi: spi cleanups
> arm: (for 1/1 boards) all +702.0 bss +12.0 rodata +314.0 text +376.0
> (try-spi=b35a52: b/) u>
>
> (try-spi=b35a52: b/) u> ./tools/buildman/buildman -b try-spi snow -sS
> ...
> 19: sf: ramtron: Add support for separate flash driver
> arm: (for 1/1 boards) all +423.0 bss +48.0 rodata +447.0 text -72.0
> 20: sf: Remove unneeded flash drivers files
> arm: (for 1/1 boards) all -191.0 bss -16.0 rodata -175.0
> 21: sf: probe: Add support for EN25Q64
> 22: sf: probe: Add support for S25FL256S_256K
> arm: (for 1/1 boards) bss -8.0 text +8.0
> 23: sf: probe: Add support for S25FL512S_256K
> 24: sf: probe: Use print_size arg as page_size
> 25: sf: probe: Print erase_size while printing flash details
> arm: (for 1/1 boards) all +70.0 bss +24.0 rodata +14.0 text +32.0
> 26: sf: probe: Simply the BAR configuration logic
> 27: sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write
> 28: sf: probe: Add support for MX25L25635F
> 29: sf: probe: Add support for MX25L51235F
> 30: sf: Remove spi_flash_do_alloc references
> 31: doc: SPI: Add status.txt for tracking SPI subsys status
> 32: sf: Add extended read commands support
> arm: (for 1/1 boards) all +136.0 bss +8.0 rodata +16.0 text +112.0
> 33: sf: Add quad read/write commands support
> arm: (for 1/1 boards) all +72.0 bss -36.0 rodata +12.0 text +96.0
> 34: sf: ops: Add configuration register writing support
> arm: + snow
> 35: sf: Set quad enable bit support
> arm: snow
> arm: (for 1/1 boards) all +192.0 bss -8.0 text +200.0
> 36: sf: spi_flash cleanups
> 37: spi: spi cleanups
Can we please see about doing something with the size change when quad
isn't enabled?
- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSRYF2AAoJENk4IS6UOR1WHRwQAIXKeiNoAztea+v/jwbxq6cy
xibh16nH+4gcIHF3NTu5vDQoNx75wEVUfyAKt1tvM0EY0CIonQVVQL8ywxj6pZWI
RSlwXGnZKKtEMmV1KsVDOptm3KvKw/IVyP4F0k3hlvrZUbXFgjdl97F73ny5jn26
5NM4/sUGB0ncsxbzGd31uGQiLzpg/TSgLKzXUzYZ8XozKVZt3cdTpgkGVM8v6XB/
I1GYxMAjC+qtPLaiBXvkAoI+2XxcgQ5UDGmIgyEZG2Tzma5Pwt8lGalOJcmHJ16X
ijgnY/0vB3/rlQ6GA/TLvRrp0hcJIchZxpwH2z5aclp7J0dQWhHD63ZpLKxt0V9H
RhapHdF52iy4ux9VBcyXvNN4An1MXBzkwB/8ZETnaDrWsi22EHgFzhCHlDrCtlyn
ZcmcI37KXNBsviUq9xn1GvSId7PqxjcAUEaKAlTXI17zBkh/AZQzZRVg09as7m+O
EfVggXkMw5wqHlF0MpkdkfIPovU7zOn3UkXouC2J/89eJxUqNOjDB7pei0/kfSzh
iHnoM6M7o07nyX5/EUxQs58QAucveqIatjfqizIA28PqplMhgD6W7NSg57svnYoU
ELgw8BSmzMpzcBpFgk1gfK7rROeVILwGoDU1bpAjGWSyBcYidHRy3AuwYHWCFF8n
0JIstTIB8SLONQMtVE1T
=g0eB
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support
2013-09-27 13:00 ` Tom Rini
@ 2013-09-27 13:39 ` Jagan Teki
0 siblings, 0 replies; 8+ messages in thread
From: Jagan Teki @ 2013-09-27 13:39 UTC (permalink / raw)
To: u-boot
Yes, I will skip quad changes as of now and send the next level patch series.
On Fri, Sep 27, 2013 at 6:30 PM, Tom Rini <trini@ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/26/2013 07:05 PM, Simon Glass wrote:
>> Hi Jagan,
>>
>> On Tue, Sep 24, 2013 at 12:19 PM, Jagannadha Sutradharudu Teki
>> <jagannadha.sutradharudu-teki@xilinx.com> wrote:
>>> 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 at 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
>>>
>>> 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.
>>>
>>> Jagannadha Sutradharudu Teki (36):
>>> sf: Divide spi_flash into multiple parts
>>> sf: probe: Add new spi_flash_probe support
>>> sf: probe: Add support for M25P* flash parts
>>> sf: probe: Add support for EN25Q* flash parts
>>> sf: probe: Add support for GD25* flash parts
>>> sf: probe: Add support for MX25L* flash parts
>>> sf: probe: Add support for W25* flash parts
>>> sf: probe: Add support for S25FL* flash parts
>>> sf: probe: Add support for SST25* flash parts
>>> sf: probe: Add support for AT45DB* flash parts
>>> sf: probe: Give proper spacing on flash table params
>>> sf: probe: Add support for SST_WP
>>> sf: probe: Add support to clear flash BP# bits
>>> sf: probe: Add support for erase sector selection flag
>>> sf: probe: Add support for flag status polling
>>> sf: probe: Move BAR config to spi_flash_validate_ids
>>> sf: Add proper comment style on spi_flash structure
>>> sf: ramtron: Add support for separate flash driver
>>> sf: Remove unneeded flash drivers files
>>> sf: probe: Add support for EN25Q64
>>> sf: probe: Add support for S25FL256S_256K
>>> sf: probe: Add support for S25FL512S_256K
>>> sf: probe: Use print_size arg as page_size
>>> sf: probe: Print erase_size while printing flash details
>>> sf: probe: Simply the BAR configuration logic
>>> sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write
>>> sf: probe: Add support for MX25L25635F
>>> sf: probe: Add support for MX25L51235F
>>> sf: Remove spi_flash_do_alloc references
>>> doc: SPI: Add status.txt for tracking SPI subsys status
>>> sf: Add extended read commands support
>>> sf: Add quad read/write commands support
>>> sf: ops: Add configuration register writing support
>>> sf: Set quad enable bit support
>>> sf: spi_flash cleanups
>>> spi: spi cleanups
>>>
>>> doc/SPI/status.txt | 28 ++
>>> drivers/mtd/spi/Makefile | 15 +-
>>> drivers/mtd/spi/atmel.c | 544 ---------------------------------
>>> drivers/mtd/spi/eon.c | 60 ----
>>> drivers/mtd/spi/gigadevice.c | 65 ----
>>> drivers/mtd/spi/macronix.c | 98 ------
>>> drivers/mtd/spi/ramtron.c | 123 +++++++-
>>> drivers/mtd/spi/spansion.c | 141 ---------
>>> drivers/mtd/spi/spi_flash.c | 571 +----------------------------------
>>> drivers/mtd/spi/spi_flash_internal.h | 151 ++++-----
>>> drivers/mtd/spi/spi_flash_ops.c | 451 +++++++++++++++++++++++++++
>>> drivers/mtd/spi/spi_flash_probe.c | 400 ++++++++++++++++++++++++
>>> drivers/mtd/spi/sst.c | 238 ---------------
>>> drivers/mtd/spi/stmicro.c | 202 -------------
>>> drivers/mtd/spi/winbond.c | 141 ---------
>>> drivers/spi/spi.c | 3 +
>>> include/configs/top9000.h | 1 -
>>> include/spi.h | 99 +++---
>>> include/spi_flash.h | 119 ++++----
>>> 19 files changed, 1205 insertions(+), 2245 deletions(-)
>>> create mode 100644 doc/SPI/status.txt
>>> delete mode 100644 drivers/mtd/spi/atmel.c
>>> delete mode 100644 drivers/mtd/spi/eon.c
>>> delete mode 100644 drivers/mtd/spi/gigadevice.c
>>> delete mode 100644 drivers/mtd/spi/macronix.c
>>> delete mode 100644 drivers/mtd/spi/spansion.c
>>> create mode 100644 drivers/mtd/spi/spi_flash_ops.c
>>> create mode 100644 drivers/mtd/spi/spi_flash_probe.c
>>> delete mode 100644 drivers/mtd/spi/sst.c
>>> delete mode 100644 drivers/mtd/spi/stmicro.c
>>> delete mode 100644 drivers/mtd/spi/winbond.c
>>>
>>> --
>>> 1.8.3
>>>
>>>
>>
>> This series seems to add 700 bytes to code size. It isn't a huge
>> amount if the benefits are worth it, but is it necessary?
>>
>> (try-spi=b35a52: b/) u> ./tools/buildman/buildman -b try-spi snow -sS --step 0
>> Summary of 2 commits for 1 boards (1 thread, 32 jobs per thread)
>> 01: Sound: MAX98095: Support I2S0 channel
>> 37: spi: spi cleanups
>> arm: (for 1/1 boards) all +702.0 bss +12.0 rodata +314.0 text +376.0
>> (try-spi=b35a52: b/) u>
>>
>> (try-spi=b35a52: b/) u> ./tools/buildman/buildman -b try-spi snow -sS
>> ...
>> 19: sf: ramtron: Add support for separate flash driver
>> arm: (for 1/1 boards) all +423.0 bss +48.0 rodata +447.0 text -72.0
>> 20: sf: Remove unneeded flash drivers files
>> arm: (for 1/1 boards) all -191.0 bss -16.0 rodata -175.0
>> 21: sf: probe: Add support for EN25Q64
>> 22: sf: probe: Add support for S25FL256S_256K
>> arm: (for 1/1 boards) bss -8.0 text +8.0
>> 23: sf: probe: Add support for S25FL512S_256K
>> 24: sf: probe: Use print_size arg as page_size
>> 25: sf: probe: Print erase_size while printing flash details
>> arm: (for 1/1 boards) all +70.0 bss +24.0 rodata +14.0 text +32.0
>> 26: sf: probe: Simply the BAR configuration logic
>> 27: sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write
>> 28: sf: probe: Add support for MX25L25635F
>> 29: sf: probe: Add support for MX25L51235F
>> 30: sf: Remove spi_flash_do_alloc references
>> 31: doc: SPI: Add status.txt for tracking SPI subsys status
>> 32: sf: Add extended read commands support
>> arm: (for 1/1 boards) all +136.0 bss +8.0 rodata +16.0 text +112.0
>> 33: sf: Add quad read/write commands support
>> arm: (for 1/1 boards) all +72.0 bss -36.0 rodata +12.0 text +96.0
>> 34: sf: ops: Add configuration register writing support
>> arm: + snow
>> 35: sf: Set quad enable bit support
>> arm: snow
>> arm: (for 1/1 boards) all +192.0 bss -8.0 text +200.0
>> 36: sf: spi_flash cleanups
>> 37: spi: spi cleanups
>
> Can we please see about doing something with the size change when quad
> isn't enabled?
>
> - --
> Tom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSRYF2AAoJENk4IS6UOR1WHRwQAIXKeiNoAztea+v/jwbxq6cy
> xibh16nH+4gcIHF3NTu5vDQoNx75wEVUfyAKt1tvM0EY0CIonQVVQL8ywxj6pZWI
> RSlwXGnZKKtEMmV1KsVDOptm3KvKw/IVyP4F0k3hlvrZUbXFgjdl97F73ny5jn26
> 5NM4/sUGB0ncsxbzGd31uGQiLzpg/TSgLKzXUzYZ8XozKVZt3cdTpgkGVM8v6XB/
> I1GYxMAjC+qtPLaiBXvkAoI+2XxcgQ5UDGmIgyEZG2Tzma5Pwt8lGalOJcmHJ16X
> ijgnY/0vB3/rlQ6GA/TLvRrp0hcJIchZxpwH2z5aclp7J0dQWhHD63ZpLKxt0V9H
> RhapHdF52iy4ux9VBcyXvNN4An1MXBzkwB/8ZETnaDrWsi22EHgFzhCHlDrCtlyn
> ZcmcI37KXNBsviUq9xn1GvSId7PqxjcAUEaKAlTXI17zBkh/AZQzZRVg09as7m+O
> EfVggXkMw5wqHlF0MpkdkfIPovU7zOn3UkXouC2J/89eJxUqNOjDB7pei0/kfSzh
> iHnoM6M7o07nyX5/EUxQs58QAucveqIatjfqizIA28PqplMhgD6W7NSg57svnYoU
> ELgw8BSmzMpzcBpFgk1gfK7rROeVILwGoDU1bpAjGWSyBcYidHRy3AuwYHWCFF8n
> 0JIstTIB8SLONQMtVE1T
> =g0eB
> -----END PGP SIGNATURE-----
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
--
Thanks,
Jagan.
--------
Jagannadha Sutradharudu Teki,
E: jagannadh.teki at gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-09-27 13:39 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-24 18:19 [U-Boot] [PATCH v4 00/36] sf: Add common probe and extended/quad read/write cmds support Jagannadha Sutradharudu Teki
2013-09-24 19:32 ` thomas.langer at lantiq.com
2013-09-25 9:19 ` Jagan Teki
2013-09-25 11:13 ` thomas.langer at lantiq.com
2013-09-25 11:30 ` Jagan Teki
2013-09-26 23:05 ` Simon Glass
2013-09-27 13:00 ` Tom Rini
2013-09-27 13:39 ` Jagan Teki
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.