| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit 7351d3a5dbf42ba3299af71db3296be447bc1516 added an index variable
as part of fixing checkpatch warnings, presumably as a tool to make some
long lines shorter, however it only set that index in the case of there
being no gaps in eccpos for the fragment being read. Which means the
later step of filling ecccode from oob_poi will use the wrong indexing
into eccpos in that case.
This patch restores the behaviour that existed prior to that change.
Signed-off-by: Ron Lee <ron@debian.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Mention to CONFIG_MTD_ECC_BCH in the warning message can be confusing as this
doesn't match the exact name of the configuration option.
This warning showed up once to me when I was starting to set up BCH. After
checking my .config file, it took a moment before realizing it is
CONFIG_MTD_NAND_ECC_BCH instead of CONFIG_MTD_ECC_BCH.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Add the "page" argument for the read_subpage hook. With this argument,
the implementation of this hook could prints out more accurate information
for debugging.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
The nand_get_flash_type parameter "busw" input value is not used by any
branch, and it is updated before use it in the function, so remove it,
define the "busw" as an internal variable.
Signed-off-by: Cai Zhiyong <caizhiyong@huawei.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Check the chip->jedec_version, and print out the right information
for JEDEC compliant NAND.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
This patch adds the parsing code for the JEDEC compliant NAND.
Since we need the 0x40 as the column address, this patch also
makes the NAND_CMD_PARAM to use the 8-bit address only.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
read_buf is called in place of write_buf in the
nand_write_page_raw_syndrome function.
Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Use a repeated read_byte() instead of read_buf(), since for x16 buswidth
devices, we need to avoid the upper I/O[16:9] bits. See the following
commit for reference:
commit 05f7835975dad6b3b517f9e23415985e648fb875
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu Dec 5 22:22:04 2013 +0100
mtd: nand: don't use {read,write}_buf for 8-bit transfers
Now, I think that all barriers to probing ONFI on x16 devices are
removed, so remove the check from nand_flash_detect_onfi().
Tested on 8-bit ONFI NAND (Micron MT29F32G08CBADAWP).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-By: Pekon Gupta <pekon@ti.com>
|
|
The NAND command helpers tend to automatically shift the column address
for x16 bus devices, since most commands expect a word address, not a
byte address. The Read ID command, however, expects an 8-bit address
(i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
0x20).
This fixes the column address for a few drivers which imitate the
nand_base defaults. Note that I don't touch sh_flctl.c, since it already
handles this problem slightly differently (note its comment "READID is
always performed using an 8-bit bus").
I have not tested this patch, as I only have x8 parts up for testing at
this point. Hopefully that can change soon...
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-By: Pekon Gupta <pekon@ti.com>
|
|
The patch converts the arrays to buffer pointers for nand_buffers{}.
The cafe_nand.c is the only NAND_OWN_BUFFERS user which allocates
nand_buffers{} itself.
This patch disables the DMA for nand_scan_ident, and restores the DMA
status after we finish the nand_scan_ident. This way, we can get page
size and OOB size and use them to allocate cafe->dmabuf.
Since the cafe_nand.c uses the NAND_ECC_HW_SYNDROME ECC mode, we do not
allocate the buffers for @ecccalc and @ecccode.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
A flash may support N read retry voltage threshold modes, numbered 0
through N-1 (where mode 0 represents the initial state). However,
nand_do_read_ops() tries to use mode 0 through N.
This off-by-one error shows up, for instance, when using nanddump, and
we have cycled through available modes:
nand: setting READ RETRY mode 0
nand: setting READ RETRY mode 1
nand: setting READ RETRY mode 2
nand: setting READ RETRY mode 3
nand: setting READ RETRY mode 4
nand: setting READ RETRY mode 5
nand: setting READ RETRY mode 6
nand: setting READ RETRY mode 7
nand: setting READ RETRY mode 8
libmtd: error!: cannot read 8192 bytes from mtd0 (eraseblock 20, offset 0)
error 22 (Invalid argument)
nanddump: error!: mtd_read
Tested on Micron MT29F64G08CBCBBH1, with 8 retry modes.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com>
|
|
Assume that:
tmp = ((extid >> 2) & 0x04) | (extid & 0x03));
From the K9LCG08U0B's datasheet, we know that:
the oob size is 640 when tmp is 6;
the oob size is 1024 when tmp is 7;
Signed-off-by: Huang Shijie <b32955@freescale.com>
[Brian: fixed compile issue]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
According to the Open NAND Flash Interface Specification (ONFI) Revision
3.1 "Parameters are always transferred on the lower 8-bits of the data
bus." for the Get Features and Set Features commands.
So using read_buf and write_buf is wrong for 16-bit wide nand chips as
they use I/O[15:0]. The Get Features command is easily fixed using 4
times the read_byte callback. For Set Features implement a new
overwritable callback "write_byte". Still I expect the default to work
just fine for all controllers and making it overwriteable was just done
for symmetry.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[Brian: fixed warning]
Tested-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Micron provides READ RETRY support via the ONFI vendor-specific
parameter block (to indicate how many read-retry modes are available)
and the ONFI {GET,SET}_FEATURES commands with a vendor-specific feature
address (to support reading/switching the current read-retry mode).
The recommended sequence is as follows:
1. Perform PAGE_READ operation
2. If no ECC error, we are done
3. Run SET_FEATURES with feature address 89h, mode 1
4. Retry PAGE_READ operation
5. If ECC error and there are remaining supported modes, increment the
mode and return to step 3. Otherwise, this is a true ECC error.
6. Run SET_FEATURES with feature address 89h, mode 0, to return to the
default state.
This patch implements the chip->setup_read_retry() callback for
Micron and fills in the chip->read_retries.
Tested on Micron MT29F32G08CBADA, which supports 8 read-retry modes.
The Micron vendor-specific table was checked against the datasheets for
the following Micron NAND:
Needs retry Cell-type Part number Vendor revision Byte 180
----------- --------- ---------------- --------------- ------------
No SLC MT29F16G08ABABA 1 Reserved (0)
No MLC MT29F32G08CBABA 1 Reserved (0)
No SLC MT29F1G08AACWP 1 0
Yes MLC MT29F32G08CBADA 1 08h
Yes MLC MT29F64G08CBABA 2 08h
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com>
|
|
Modern MLC (and even SLC?) NAND can experience a large number of
bitflips (beyond the recommended correctability capacity) due to drifts
in the voltage threshold (Vt). These bitflips can cause ECC errors to
occur well within the expected lifetime of the flash. To account for
this, some manufacturers provide a mechanism for shifting the Vt
threshold after a corrupted read.
The generic pattern seems to be that a particular flash has N read retry
modes (where N = 0, traditionally), and after an ECC failure, the host
should reconfigure the flash to use the next available mode, then retry
the read operation. This process repeats until all bitfips can be
corrected or until the host has tried all available retry modes.
This patch adds the infrastructure support for a
vendor-specific/flash-specific callback, used for setting the read-retry
mode (i.e., voltage threshold).
For now, this patch always returns the flash to mode 0 (the default
mode) after a successful read-retry, according to the flowchart found in
Micron's datasheets. This may need to change in the future if it is
determined that eventually, mode 0 is insufficient for the majority of
the flash cells (and so for performance reasons, we should leave the
flash in mode 1, 2, etc.).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com>
|
|
ECC failures can be tracked at the page level, not the do_read_ops level
(i.e., a potentially multi-page transaction).
This helps prepare for READ RETRY support.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com>
|
|
This patch assigned the type->name to mtd->name when mtd->name is
NULL in function "find_full_id_nand".
mtd->name is NULL may cause some problem.
Signed-off-by: Cai Zhiyong <caizhiyong@huawei.com>
Acked-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Add a nice "nand:" prefix to all pr_xxx() messages. This allows
to get rid of the "NAND" words in messages, given the context
is already given by the prefix.
Remove the __func__ report from messages where it's not needed and refactor
the device detection messages to show itself in several lines.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
There are too many "chip->ecc" in the nand_scan_tail() which makes the eyes
sore.
This patch uses a local variable "ecc" to replace the "chip->ecc" to
make the code more graceful.
Do the code change with "s/chip->ecc\./ecc->/g" in the nand_scan_tail,
and also change some lines by hand.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Some bright specification writers decided to write this in the ONFI spec
(from ONFI 3.0, Section 3.1):
"The number of blocks and number of pages per block is not required to
be a power of two. In the case where one of these values is not a
power of two, the corresponding address shall be rounded to an
integral number of bits such that it addresses a range up to the
subsequent power of two value. The host shall not access upper
addresses in a range that is shown as not supported."
This breaks every assumption MTD makes about NAND block/chip-size
dimensions -- they *must* be a power of two!
And of course, an enterprising manufacturer has made use of this lovely
freedom. Exhibit A: Micron MT29F32G08CBADAWP
"- Plane size: 2 planes x 1064 blocks per plane
- Device size: 32Gb: 2128 blockss [sic]"
This quickly hits a BUG() in nand_base.c, since the extra dimensions
overflow so we think it's a second chip (on my single-chip setup):
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0x44 (Micron MT29F32G08CBADAWP), 4256MiB, page size: 8192, OOB size: 744
------------[ cut here ]------------
kernel BUG at drivers/mtd/nand/nand_base.c:203!
Internal error: Oops - BUG: 0 [#1] SMP ARM
[... trim ...]
[<c02cf3e4>] (nand_select_chip+0x18/0x2c) from [<c02d25c0>] (nand_do_read_ops+0x90/0x424)
[<c02d25c0>] (nand_do_read_ops+0x90/0x424) from [<c02d2dd8>] (nand_read+0x54/0x78)
[<c02d2dd8>] (nand_read+0x54/0x78) from [<c02ad2c8>] (mtd_read+0x84/0xbc)
[<c02ad2c8>] (mtd_read+0x84/0xbc) from [<c02d4b28>] (scan_read.clone.4+0x4c/0x64)
[<c02d4b28>] (scan_read.clone.4+0x4c/0x64) from [<c02d4c88>] (search_bbt+0x148/0x290)
[<c02d4c88>] (search_bbt+0x148/0x290) from [<c02d4ea4>] (nand_scan_bbt+0xd4/0x5c0)
[... trim ...]
---[ end trace 0c9363860d865ff2 ]---
So to fix this, just truncate these dimensions down to the greatest
power-of-2 dimension that is less than or equal to the specified
dimension.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: <stable@vger.kernel.org>
|
|
Current code sets the mtd->type with MTD_NANDFLASH for both
SLC and MLC. So the jffs2 may supports the MLC nand, but in actually,
the jffs2 should not support the MLC.
This patch uses the nand_is_slc() to check the nand cell type,
and set the mtd->type with the right nand type.
After this patch, the jffs2 only supports the SLC nand.
The side-effect of this patch:
Before this patch, the ioctl(MEMGETINFO) can only return with the
MTD_NANDFLASH; but after this patch, the ioctl(MEMGETINFO) will
return with the MTD_NANDFLASH for SLC, and MTD_MLCNANDFLASH for MLC.
So the user applictions(such as mtd-utils) should also changes a little
for this.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Print out the cell information for nand chip.
(Since the message is too long, this patch also splits the log
with two separate pr_info())
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
The current code does not set the SLC/MLC information for onfi nand.
(This makes that the kernel treats all the onfi nand as SLC nand.)
This patch fills the cell information for ONFI nands.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
The legacy ID NAND are all SLC.
This patch sets 1 to the @bits_per_cell for the legacy ID NAND,
which means they are all SLC.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
The @cellinfo fields contains unused information, such as write caching,
internal chip numbering, etc. But we only use it to check the SLC or MLC.
This patch tries to make it more clear and simple, renames the @cellinfo
to @bits_per_cell.
In order to avoiding the bisect issue, this patch also does the following
changes:
(0) add a macro NAND_CI_CELLTYPE_SHIFT to avoid the hardcode.
(1) add a helper to parse out the cell type : nand_get_bits_per_cell()
(2) parse out the cell type for extended-ID chips and the full-id nand chips.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Add a helper to check if a nand chip is SLC or MLC.
This helper makes the code more readable.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
If the ONFI extended parameter page gives codeword_size == 0, the
extended ECC information is corrupt and should not be used. Currently,
we (correctly) avoid using the information, but we don't report the
error to the caller, so the caller doesn't know that we didn't
initialize ecc_strength_ds and ecc_step_ds. Now the caller can warn the
user that it does not have sufficient information.
This also removes the false and useless "ONFI extended param page
detected" debug message (it was printed even on the aforementioned
corruption, and for the success case, we don't really want a print).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com>
|
|
The ONFI detection routine is too verbose in some cases and not verbose
enough in others. This patch refactors it to print only when there are
significant warnings/errors.
Probing in 16-bit mode:
It is unnecessary to print until after the READID (address 20h)
command. READID *has* to work properly in whatever bus width
configuration we are in, or else no identification mode works. So we
can silence some useless warnings on systems which come up in 16-bit
mode and do not even respond with an O-N-F-I string.
Valid parameter page:
Nobody needs to see this. Do we inform the user every time other
hardware responds properly? Instead, add an error message if *no*
uncorrupted parameter pages are found.
ONFI ECC:
Most drivers don't yet use the reported minimum ECC values, so it
shouldn't yet be a fatal condition if the extended parameter page is
incorrect. But we should at least give a warning for the corner cases
that we don't expect.
ONFI flash detected:
Nobody needs to see this. This is the expected case, that we detect
ONFI properly, or else it wasn't ONFI-compliant and is detected by
some other routine.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Huang Shijie <b32955@freescale.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
This fixes a memory leak in the ONFI support code for detecting the
required ECC levels from this commit:
commit 6dcbe0cdd83fb5f77be4f44c9e06c535281c375a
Author: Huang Shijie <b32955@freescale.com>
Date: Wed May 22 10:28:27 2013 +0800
mtd: get the ECC info from the Extended Parameter Page
In the success case, we never freed the 'ep' buffer.
Also, this fixes an oversight in the same commit where we (harmlessly)
freed the NULL pointer.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
First, the function argument is 'offset' not 'column'.
Second, the 'data_buf' name is inconsistent with the rest of this file.
Just use 'buf'.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Gupta, Pekon <pekon@ti.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
We may do some ONFI get/set features operations before we call the
nand_scan_tail().
So move the default ONFI nand hooks into nand_set_defaults().
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Set the ecc step size for master/slave mtd_info{}.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
There are static checkers which complain when we declare variables as
64 bit bitfields but only use the lower 32 bits because of shift
wrapping. In this case "len" is declared as u64 as opposed to unsigned
long or something which might be 32 bits.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Parse out the ECC information for the full-id nand chips.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
The current code uses the hardcode to detect the 16-bit bus width.
Use the onfi_feature() to replace it.
Signed-off-by: Huang Shijie <b32955@freescale.com>
[Brian: small fixup]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Since the ONFI 2.1, the onfi spec adds the Extended Parameter Page
to store the ECC info.
The onfi spec tells us that if the nand chip's recommended ECC codeword
size is not 512 bytes, then the @ecc_bits is 0xff. The host _SHOULD_ then
read the Extended ECC information that is part of the extended parameter
page to retrieve the ECC requirements for this device.
This patch implement the reading of the Extended Parameter Page, and parses
the sections for ECC type, and get the ECC info from the ECC section.
Tested this patch with Micron MT29F64G08CBABAWP.
Acked-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Huang Shijie <b32955@freescale.com>
Reviewed-and-tested-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
From the ONFI spec, we can just get the ECC info from the @ecc_bits field of
the parameter page.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Reviewed-and-tested-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
nand_base.c shouldn't have to know the implementation details of
nand_bbt's in-memory BBT. Specifically, nand_base shouldn't perform the
bit masking and shifting to isolate a BBT entry.
Instead, just move some of the BBT code into a new nand_markbad_bbt()
interface. This interface allows external users (i.e., nand_base) to
mark a single block as bad in the BBT. Then nand_bbt will take care of
modifying the in-memory BBT and updating the flash-based BBT (if
applicable).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
The chip->block_markbad pointer should really only be responsible for
writing a bad block marker for new bad blocks. It should not take care
of BBT-related functionality, nor should it handle bookkeeping of bad
block stats.
This patch refactors the 3 users of the block_markbad interface (plus
the default nand_base implementation) so that the common code is kept in
nand_block_markbad_lowlevel(). It removes some inconsistencies between
the various implementations and should allow for more centralized
improvements in the future.
Because gpmi-nand no longer needs the nand_update_bbt() function, let's
stop exporting it as well.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com> (for gpmi-nand parts)
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Toshiba NAND datasheets have not been very forthcoming on OOB size
information; they do not provide any bitfields in the ID string for
spare area. In their 24nm technology flash, however, Toshiba migrated
their NAND to have 32 bytes spare per 512 bytes of page area (up from
the traditional 16 bytes), as they now require 8-bit ECC or higher.
I have discussed this issue directly with Toshiba representatives, and
they acknowledge this problem. They recommend detecting these flash
based on their technology node as follows:
For 24nm Toshiba SLC raw NAND (not BENAND -- Built-in Ecc NAND), there
are 32 bytes of spare area for every 512 bytes of in-band data area.
We can implement this rule with the following snippet of a device ID
decode table, which applies to all their 43nm, 32nm, and 24nm SLC NAND
(this table is not fully in the NAND datasheets, but it was provided
directly by Toshiba representatives):
- ID byte 5, bit[7]:
1 -> BENAND
0 -> raw SLC
- ID byte 6, bits[2:0]:
100b -> 43nm
101b -> 32nm
110b -> 24nm
111b -> Reserved
I'm also working with Toshiba on including this bitfield description for
their 5th and 6th ID bytes in their public data sheets.
I will provide the 8-byte ID strings from the two 24nm Toshiba samples I
have; their first 6 bytes match the documentation I received from
Toshiba:
24nm SLC 1Gbit TC58NVG0S3HTA00
0x98 0xf1 0x80 0x15 0x72 0x16 0x08 0x00
24nm SLC 2Gbit TC58NVG1S3HTA00
0x98 0xda 0x90 0x15 0x76 0x16 0x08 0x00
I have also tested for regressions with:
43nm SLC 4Gbit TC58NVG2S3ETA00
0x98 0xdc 0x90 0x15 0x76 0x14 0x03 0x10
32nm SLC 8Gbit TC58NVG3SOFA00
0x98 0xd3 0x90 0x26 0x76 0x15 0x02 0x08
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
The code for NAND_BUSWIDTH_AUTO is broken. According to Alexander:
"I have a problem with attach NAND UBI in 16 bit mode.
NAND works fine if I specify NAND_BUSWIDTH_16 option, but not
working with NAND_BUSWIDTH_AUTO option. In second case NAND
chip is identifyed with ONFI."
See his report for the rest of the details:
http://lists.infradead.org/pipermail/linux-mtd/2013-July/047515.html
Anyway, the problem is that nand_set_defaults() is called twice, we
intend it to reset the chip functions to their x16 buswidth verions
if the buswidth changed from x8 to x16; however, nand_set_defaults()
does exactly nothing if called a second time.
Fix this by hacking nand_set_defaults() to reset the buswidth-dependent
functions if they were set to the x8 version the first time. Note that
this does not do anything to reset from x16 to x8, but that's not the
supported use case for NAND_BUSWIDTH_AUTO anyway.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reported-by: Alexander Shiyan <shc_work@mail.ru>
Tested-by: Alexander Shiyan <shc_work@mail.ru>
Cc: Matthieu Castet <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org> # v3.8+
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Spansion's S34MLx chips support ONFI but not the GET/SET FEATURES calls.
Signed-off-by: David Mosberger <dmosberger@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
This patch replaces the usage of loops in the nand_base code with
io{read,write}{8,16}_rep calls instead.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
This patch adds support for subpage (partial-page) writes when using
hardware based ECC schemes.
Advantages:
(1) reduces storage overhead when using file-systems like UBIFS, which
store LEB header at page-size granularity.
(2) allows independent subpage writes, thereby increasing NAND storage
efficiency for non-page aligned data.
+ updated cafe_nand and lpc32xx_mlc NAND drivers for change in
chip->write_page interface.
Signed-off-by: Gupta, Pekon <pekon@ti.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
When we meet a full-id nand type whose @id_len is not zero, we can use
the find_full_id_nand() to parse out the necessary information for a
nand chip.
If we meet a non full-id nand type, we can handle it in the legacy way.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Reviewed-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
Variable "onfi_version" is already set to zero before nand_flash_detect_onfi()
call, so additional cleaning is not necessary.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
NAND command, passed to cmd_ctrl(), is masked with 0xff. This patch
removes this since masking is not necessary and masking is not performed
in other places for same call.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
NAND flashes with 256 bytes NAND pages are so old that probably do not exist
any more. Let's remove few related pieces of code and forget about them
forever. The assumption will be that 512 bytes NAND page size is the minimum
possible.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
The 'id' is a bit confusing name because NAND IDs are multi-byte. Re-name
it to 'dev_id' to make it clear that this is the "device ID" part (the second
byte).
While on it, clean-up the commentary for 'struct nand_flash_dev'.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
|
We have this unused macro, let's use it and justify its existence.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
