diff options
author | Artem Bityutskiy <artem.bityutskiy@linux.intel.com> | 2013-03-04 16:26:56 +0200 |
---|---|---|
committer | David Woodhouse <David.Woodhouse@intel.com> | 2013-04-05 12:04:22 +0100 |
commit | 8e12b474f9a2349bcaebda65bdc38e8398ff408e (patch) | |
tree | 75a435b77c734f93465354cfa501587150f8fd4d /arch | |
parent | 8dbfae1ef04311ba19d6b6c9a4d8fdddbb90ab0f (diff) | |
download | blackbird-obmc-linux-8e12b474f9a2349bcaebda65bdc38e8398ff408e.tar.gz blackbird-obmc-linux-8e12b474f9a2349bcaebda65bdc38e8398ff408e.zip |
mtd: nand: provision full ID support
Up until now we identified NAND chips by the 'device ID' part of the full chip
ID array, which is the second full ID array byte. However, the newest flashes
use the same device ID for chips with identical page and eraseblock sizes, but
different OOB sizes. And unfortunately, it is not clear if there is a
"standard" way to fetch the OOB size from chip's full ID array. Here is an
example:
Toshiba TC58NVG2S0F: 0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08
Toshiba TC58NVG3S0F: 0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08
The first one is a 512MiB NAND chip with 4KiB NAND pages, 256KiB eraseblock
size and 224 bytes OOB. The second one is a 1GiB NAND chip with the same page
and eraseblock sizes, but with 232 bytes OOB.
This means that we have to store full ID in our NAND flashes table in order to
distinguish between these 2.
This patch adds the 'id[8]' field to the 'struct nand_flash_dev' structure, and
it makes it to be a part of anonymous union, where the second member is a
structure containing the 'mfr_id' and 'dev_id' bytes. The union makes sure that
'mfr_id' refers the same RAM address as 'id[0]' and 'dev_id' refers the same
RAM address as 'id[1]'. The only motivation for the union is an assumption that
'type->dev_id' is more readable than 'type->id[1]'.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions