linux-stable.git/drivers/mtd/chips, branch linux-3.8.y Linux kernel stable tree mtd: fix recovery after failed write-buffer operation in cfi_cmdset_0002.c 2012-12-03T14:36:52+00:00 Harald Nordgard-Hansen hhansen@pvv.org 2012-11-23T22:11:03+00:00 070c32223ae8a724a190ea769104ea41567e3673 When working on a problem with some flash chips that lock up during write-buffer operations, I think there may be a bug in the linux handling of chips using cfi_cmdset_0002.c. The datasheets I have found for a number of these chips all specify that when aborting a write-buffer command, it is not enough to use the standard reset. Rather a "write-to-buffer-reset command" is needed. This command is quite similar for all chips, the main variance seem to be if the final 0xF0 can go to any address or must go to addr_unlock1. The bug is then in the recovery handling when timing out at the end of do_write_buffer, where using the normal reset command is not sufficient. Without this change, if the write-buffer command fails then any following operations on the flash also fail. Signed-off-by: Harald Nordgard-Hansen <hhansen@pvv.org> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 
When working on a problem with some flash chips that lock up during
write-buffer operations, I think there may be a bug in the linux
handling of chips using cfi_cmdset_0002.c.

The datasheets I have found for a number of these chips all specify that
when aborting a write-buffer command, it is not enough to use the
standard reset.  Rather a "write-to-buffer-reset command" is needed.
This command is quite similar for all chips, the main variance seem to
be if the final 0xF0 can go to any address or must go to addr_unlock1.

The bug is then in the recovery handling when timing out at the end of
do_write_buffer, where using the normal reset command is not sufficient.

Without this change, if the write-buffer command fails then any
following operations on the flash also fail.

Signed-off-by: Harald Nordgard-Hansen <hhansen@pvv.org>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
mtd: cfi_cmdset_0001: Fix problem with unlocking timeout 2012-09-29T14:29:08+00:00 Stefan Roese sr@denx.de 2012-08-28T09:34:13+00:00 7be1f6b9a1ae3476a424380b52aad7c14c3273ab Unlocking may take up to 1.4 seconds on some Intel flashes. So lets use a max. of 1.5 seconds (1500ms) as timeout. See "Clear Block Lock-Bits Time" on page 40 in "3 Volt Intel StrataFlash Memory" 28F128J3,28F640J3,28F320J3 manual from February 2003 This patch also fixes some other problems with this timeout: - Don't use HZ in timeout "calculation"! While testing we noticed that an unlocking timeout occured with HZ=1000 and didn't occur with HZ=300. This was because the timeout parameter was calculated differently depending on the HZ value. Now a fixed value of 1500ms is used. - The last parameter of WAIT_TIMEOUT (defined to inval_cache_and_wait_for_operation) has to be passed in micro-seconds. So multiply the ms value with 1000 and not 100 to calculate this value. - Use variable name "mdelay" instead of misleading "udelay". Signed-off-by: Stefan Roese <sr@denx.de> Tested-by: Stephan Gatzka <stephan@gatzka.org> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
Unlocking may take up to 1.4 seconds on some Intel flashes. So
lets use a max. of 1.5 seconds (1500ms) as timeout.

See "Clear Block Lock-Bits Time" on page 40 in
"3 Volt Intel StrataFlash Memory" 28F128J3,28F640J3,28F320J3 manual
from February 2003

This patch also fixes some other problems with this timeout:

- Don't use HZ in timeout "calculation"!
  While testing we noticed that an unlocking timeout occured with
  HZ=1000 and didn't occur with HZ=300. This was because the
  timeout parameter was calculated differently depending on the
  HZ value. Now a fixed value of 1500ms is used.

- The last parameter of WAIT_TIMEOUT (defined to
  inval_cache_and_wait_for_operation) has to be passed in
  micro-seconds. So multiply the ms value with 1000 and not 100
  to calculate this value.

- Use variable name "mdelay" instead of misleading "udelay".

Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Stephan Gatzka <stephan@gatzka.org>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: cfi_cmdset_0002: Micron M29EW bugfixes as per TN-13-07 2012-07-16T20:37:15+00:00 Gerlando Falauto gerlando.falauto@keymile.com 2012-07-03T07:09:47+00:00 420962884379bd434a7f643d0936281b2ab4b30c Fix the following issues with Micron's (formerly Numonyx) M29EW NOR flash chips, as documented on TN-13-07: - Correcting Erase Suspend Hang Ups (page 20) - Resolving the Delay After Resume Issue (page 22) Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
Fix the following issues with Micron's (formerly Numonyx)
M29EW NOR flash chips, as documented on TN-13-07:
- Correcting Erase Suspend Hang Ups (page 20)
- Resolving the Delay After Resume Issue (page 22)

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: chips: reorganize Kconfig help on swapping 2012-07-06T17:17:07+00:00 Paul Bolle pebolle@tiscali.nl 2012-06-19T11:52:42+00:00 2e61c3a57747150a583b2fb54bddb5dba09aa2cf The Kconfig help on "Flash cmd/query data swapping" still mentions LART_ENDIAN_BYTE. That option used to be relevant for setting CONFIG_MTD_CFI_LART_BIT_SWAP. That option and macro got both removed in v2.4.11-pre4. So, although LART endianness sounds intriguing, that part of the help text can be removed. And, while we're touching this choice, move the help text up one level. Currently it's available under the "NO" option, while it's relevant for all three options. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
The Kconfig help on "Flash cmd/query data swapping" still mentions
LART_ENDIAN_BYTE. That option used to be relevant for setting
CONFIG_MTD_CFI_LART_BIT_SWAP. That option and macro got both removed in
v2.4.11-pre4. So, although LART endianness sounds intriguing, that part
of the help text can be removed.

And, while we're touching this choice, move the help text up one level.
Currently it's available under the "NO" option, while it's relevant for
all three options.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: cfi_cmdset_0002: Slight cleanup of fixup messages 2012-05-14T04:34:36+00:00 David Woodhouse David.Woodhouse@intel.com 2012-05-14T04:34:24+00:00 5df41de5870e2184e75a8cb133ca81888006f097 These should be semicolons, not commas. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
These should be semicolons, not commas.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: add fixup for S29NS512P NOR flash. 2012-05-14T04:33:05+00:00 Javier Martin javier.martin@vista-silicon.com 2012-05-11T10:15:41+00:00 43dc03c7ba644620283523b7ae62da94bb81fdbb Spansion S29NS512P flash uses a 16bit transfer to report number of sectors instead of two 8bit accesses as CFI specifies. Artem: remove warning message which said that we are applying the fixup - no need to scary the user unnecessarily. Signed-off-by: Javier Martin <javier.martin@vista-silicon.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
Spansion S29NS512P flash uses a 16bit transfer to report number
of sectors instead of two 8bit accesses as CFI specifies.

Artem: remove warning message which said that we are applying the
fixup - no need to scary the user unnecessarily.

Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Merge tag 'for-linus-3.4' of git://git.infradead.org/mtd-2.6 2012-03-31T00:31:56+00:00 Linus Torvalds torvalds@linux-foundation.org 2012-03-31T00:31:56+00:00 623ff7739e7c00fa3d55dbfd42a492a68298fd7a Pull MTD changes from David Woodhouse: - Artem's cleanup of the MTD API continues apace. - Fixes and improvements for ST FSMC and SuperH FLCTL NAND, amongst others. - More work on DiskOnChip G3, new driver for DiskOnChip G4. - Clean up debug/warning printks in JFFS2 to use pr_<level>. Fix up various trivial conflicts, largely due to changes in calling conventions for things like dmaengine_prep_slave_sg() (new inline wrapper to hide new parameter, clashing with rewrite of previously last parameter that used to be an 'append' flag, and is now a bitmap of 'unsigned long flags'). (Also some header file fallout - like so many merges this merge window - and silly conflicts with sparse fixes) * tag 'for-linus-3.4' of git://git.infradead.org/mtd-2.6: (120 commits) mtd: docg3 add protection against concurrency mtd: docg3 refactor cascade floors structure mtd: docg3 increase write/erase timeout mtd: docg3 fix inbound calculations mtd: nand: gpmi: fix function annotations mtd: phram: fix section mismatch for phram_setup mtd: unify initialization of erase_info->fail_addr mtd: support ONFI multi lun NAND mtd: sm_ftl: fix typo in major number. mtd: add device-tree support to spear_smi mtd: spear_smi: Remove default partition information from driver mtd: Add device-tree support to fsmc_nand mtd: fix section mismatch for doc_probe_device mtd: nand/fsmc: Remove sparse warnings and errors mtd: nand/fsmc: Add DMA support mtd: nand/fsmc: Access the NAND device word by word whenever possible mtd: nand/fsmc: Use dev_err to report error scenario mtd: nand/fsmc: Use devm routines mtd: nand/fsmc: Modify fsmc driver to accept nand timing parameters via platform mtd: fsmc_nand: add pm callbacks to support hibernation ... 
Pull MTD changes from David Woodhouse:
 - Artem's cleanup of the MTD API continues apace.
 - Fixes and improvements for ST FSMC and SuperH FLCTL NAND, amongst
   others.
 - More work on DiskOnChip G3, new driver for DiskOnChip G4.
 - Clean up debug/warning printks in JFFS2 to use pr_<level>.

Fix up various trivial conflicts, largely due to changes in calling
conventions for things like dmaengine_prep_slave_sg() (new inline
wrapper to hide new parameter, clashing with rewrite of previously last
parameter that used to be an 'append' flag, and is now a bitmap of
'unsigned long flags').

(Also some header file fallout - like so many merges this merge window -
and silly conflicts with sparse fixes)

* tag 'for-linus-3.4' of git://git.infradead.org/mtd-2.6: (120 commits)
  mtd: docg3 add protection against concurrency
  mtd: docg3 refactor cascade floors structure
  mtd: docg3 increase write/erase timeout
  mtd: docg3 fix inbound calculations
  mtd: nand: gpmi: fix function annotations
  mtd: phram: fix section mismatch for phram_setup
  mtd: unify initialization of erase_info->fail_addr
  mtd: support ONFI multi lun NAND
  mtd: sm_ftl: fix typo in major number.
  mtd: add device-tree support to spear_smi
  mtd: spear_smi: Remove default partition information from driver
  mtd: Add device-tree support to fsmc_nand
  mtd: fix section mismatch for doc_probe_device
  mtd: nand/fsmc: Remove sparse warnings and errors
  mtd: nand/fsmc: Add DMA support
  mtd: nand/fsmc: Access the NAND device word by word whenever possible
  mtd: nand/fsmc: Use dev_err to report error scenario
  mtd: nand/fsmc: Use devm routines
  mtd: nand/fsmc: Modify fsmc driver to accept nand timing parameters via platform
  mtd: fsmc_nand: add pm callbacks to support hibernation
  ...
mtd: chips: cfi_cmdset_0002: Match ENABLE_VPP()/DISABLE_VPP() calls 2012-03-26T23:52:23+00:00 Paul Parsons lost.distance@yahoo.com 2012-03-07T14:11:16+00:00 e7d9377e0440c25805dcc5b0af189a87beb69f5e This patch is part of a set which fixes unnecessary flash erase and write errors resulting from the MTD CFI driver turning off vpp while an erase is in progress. This patch ensures that only those flash operations which call ENABLE_VPP() can then call DISABLE_VPP(). Other operations should never call DISABLE_VPP(). Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
This patch is part of a set which fixes unnecessary flash erase and write errors
resulting from the MTD CFI driver turning off vpp while an erase is in progress.
This patch ensures that only those flash operations which call ENABLE_VPP() can
then call DISABLE_VPP(). Other operations should never call DISABLE_VPP().

Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: chips: cfi_cmdset_0001: Match ENABLE_VPP()/DISABLE_VPP() calls 2012-03-26T23:50:36+00:00 Paul Parsons lost.distance@yahoo.com 2012-03-07T14:10:33+00:00 85e5b2f2986310f2f75069c360669f6ce8e2ceb9 This patch is part of a set which fixes unnecessary flash erase and write errors resulting from the MTD CFI driver turning off vpp while an erase is in progress. This patch ensures that only those flash operations which call ENABLE_VPP() can then call DISABLE_VPP(). Other operations should never call DISABLE_VPP(). Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
This patch is part of a set which fixes unnecessary flash erase and write errors
resulting from the MTD CFI driver turning off vpp while an erase is in progress.
This patch ensures that only those flash operations which call ENABLE_VPP() can
then call DISABLE_VPP(). Other operations should never call DISABLE_VPP().

Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: fix 'Flash device refused suspend due to active operation' message 2012-03-26T23:36:40+00:00 Russell King rmk+kernel@arm.linux.org.uk 2012-02-15T11:48:34+00:00 342d3a93e2b191b0ada07ba7c48380181c9214e8 While debugging on SA11x0, the following message was observed: "Flash device refused suspend due to active operation (state 20)" Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
While debugging on SA11x0, the following message was observed:

"Flash device refused suspend due to active operation (state 20)"

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>