From 41bbe4dd49a3825e024e874ee19c6527860a3f16 Mon Sep 17 00:00:00 2001 From: pekon gupta Date: Fri, 11 Apr 2014 12:55:30 +0530 Subject: mtd: nand: omap_elm: use bch_type instead of nibble count to differentiate between BCH4/BCH8/BCH16 ELM hardware engine support ECC error detection for multiple ECC strengths like +------+------------------------+ |Type | ECC syndrome length | +------+------------------------+ |BCH4 | 6.5 bytes = 13 nibbles | |BCH8 | 13 byte = 26 nibbles | |BCH16 | 26 bytes = 52 nibbles | +------+------------------------+ Current implementation of omap_elm driver uses ECC syndrom length (in 'nibbles') to differentiate between BCH4/BCH8/BCH16. This patch replaces it with 'bch_type' Signed-off-by: Pekon Gupta Reviewed-by: Stefan Roese --- include/linux/mtd/omap_elm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include/linux') diff --git a/include/linux/mtd/omap_elm.h b/include/linux/mtd/omap_elm.h index 45454ea..a6e9591 100644 --- a/include/linux/mtd/omap_elm.h +++ b/include/linux/mtd/omap_elm.h @@ -68,7 +68,7 @@ struct elm { struct location error_location[8]; /* 0x800 */ }; -int elm_check_error(u8 *syndrome, u32 nibbles, u32 *error_count, +int elm_check_error(u8 *syndrome, enum bch_level bch_type, u32 *error_count, u32 *error_locations); int elm_config(enum bch_level level); void elm_reset(void); -- cgit v1.1 From 0439d752c5ad6cb95b1c8e1f922d74eee73d79a9 Mon Sep 17 00:00:00 2001 From: pekon gupta Date: Fri, 11 Apr 2014 12:55:31 +0530 Subject: mtd: nand: omap_elm: use macros for register definitions This patch adds macros for following parameters of ELM Hardware engine - ELM_MAX_CHANNELS: ELM can process 8 data streams simultaneously - ELM_MAX_ERRORS: ELM can detect upto 16 ECC error when using BCH16 scheme Signed-off-by: Pekon Gupta Reviewed-by: Stefan Roese --- include/linux/mtd/omap_elm.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'include/linux') diff --git a/include/linux/mtd/omap_elm.h b/include/linux/mtd/omap_elm.h index a6e9591..b8096b0 100644 --- a/include/linux/mtd/omap_elm.h +++ b/include/linux/mtd/omap_elm.h @@ -24,6 +24,9 @@ #define ELM_LOCATION_STATUS_ECC_CORRECTABLE_MASK (0x100) #define ELM_LOCATION_STATUS_ECC_NB_ERRORS_MASK (0x1F) +#define ELM_MAX_CHANNELS 8 +#define ELM_MAX_ERROR_COUNT 16 + #ifndef __ASSEMBLY__ enum bch_level { @@ -43,7 +46,7 @@ struct syndrome { struct location { u32 location_status; /* 0x800 */ u8 res1[124]; /* 0x804 */ - u32 error_location_x[16]; /* 0x880.... */ + u32 error_location_x[ELM_MAX_ERROR_COUNT]; /* 0x880, 0x980, .. */ u8 res2[64]; /* 0x8c0 */ }; @@ -63,9 +66,9 @@ struct elm { u8 res2[92]; /* 0x024 */ u32 page_ctrl; /* 0x080 */ u8 res3[892]; /* 0x084 */ - struct syndrome syndrome_fragments[8]; /* 0x400 */ + struct syndrome syndrome_fragments[ELM_MAX_CHANNELS]; /* 0x400,0x420 */ u8 res4[512]; /* 0x600 */ - struct location error_location[8]; /* 0x800 */ + struct location error_location[ELM_MAX_CHANNELS]; /* 0x800,0x900 ... */ }; int elm_check_error(u8 *syndrome, enum bch_level bch_type, u32 *error_count, -- cgit v1.1 From 27ce9e4290b168a1241699d411678959aaf9649b Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 6 May 2014 00:46:17 +0530 Subject: mtd: nand: force NAND_CMD_READID onto 8-bit bus As per following Sections in ONFI Spec, NAND_CMD_READID should use only lower 8-bit for transfering command, address and data even on x16 NAND device. *Section: Target Initialization" "The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus. The host shall not issue commands that use a word data width on x16 devices until the host determines the device supports a 16-bit data bus width in the parameter page." *Section: Bus Width Requirements* "When the host supports a 16-bit bus width, only data is transferred at the 16-bit width. All address and command line transfers shall use only the lower 8-bits of the data bus. During command transfers, the host may place any value on the upper 8-bits of the data bus. During address transfers, the host shall set the upper 8-bits of the data bus to 00h." Thus porting following commit from linux-kernel to ensure that column address is not altered to align to x16 bus when issuing NAND_CMD_READID command. commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7 mtd: nand: force NAND_CMD_READID onto 8-bit bus Author: Brian Norris (preserving authorship) 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. Signed-off-by: Pekon Gupta --- include/linux/mtd/nand.h | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'include/linux') diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 0546565..4be8858 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -719,4 +719,14 @@ static inline int onfi_get_sync_timing_mode(struct nand_chip *chip) } #endif +/** + * Check if the opcode's address should be sent only on the lower 8 bits + * @command: opcode to check + */ +static inline int nand_opcode_8bits(unsigned int command) +{ + return command == NAND_CMD_READID; +} + + #endif /* __LINUX_MTD_NAND_H */ -- cgit v1.1 From 6e1899e633c2ac3f6da7101d4990361c6ff2a9d2 Mon Sep 17 00:00:00 2001 From: David Mosberger Date: Tue, 6 May 2014 00:46:18 +0530 Subject: mtd: nand: fix GET/SET_FEATURES address on 16-bit devices As per following Sections in ONFI Spec, GET_FEATURES and SET_FEATURES also need byte-addressing on 16-bit devices. *Section: Target Initialization" "The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus. The host shall not issue commands that use a word data width on x16 devices until the host determines the device supports a 16-bit data bus width in the parameter page." *Section: Bus Width Requirements* "When the host supports a 16-bit bus width, only data is transferred at the 16-bit width. All address and command line transfers shall use only the lower 8-bits of the data bus. During command transfers, the host may place any value on the upper 8-bits of the data bus. During address transfers, the host shall set the upper 8-bits of the data bus to 00h." So porting following commit from linux kernel commit e34fcb07a6d57411de6e15a47724fbe92c5caa42 Author: David Mosberger (preserving authorship) mtd: nand: fix GET/SET_FEATURES address on 16-bit devices Signed-off-by: Pekon Gupta --- include/linux/mtd/nand.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'include/linux') diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 4be8858..991bd8e 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -725,7 +725,16 @@ static inline int onfi_get_sync_timing_mode(struct nand_chip *chip) */ static inline int nand_opcode_8bits(unsigned int command) { - return command == NAND_CMD_READID; + switch (command) { + case NAND_CMD_READID: + case NAND_CMD_PARAM: + case NAND_CMD_GET_FEATURES: + case NAND_CMD_SET_FEATURES: + return 1; + default: + break; + } + return 0; } -- cgit v1.1 From 8d13a730dea1b5b4d32b31b5584cb8fdea27a248 Mon Sep 17 00:00:00 2001 From: pekon gupta Date: Mon, 2 Jun 2014 17:14:41 +0530 Subject: mtd: nand: omap_gpmc: use macro for register definitions GPMC can support simultaneous processing of 8 512Byte data chunks, in parallel Signed-off-by: Pekon Gupta --- include/linux/mtd/omap_gpmc.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'include/linux') diff --git a/include/linux/mtd/omap_gpmc.h b/include/linux/mtd/omap_gpmc.h index 22f6573..d55fe32 100644 --- a/include/linux/mtd/omap_gpmc.h +++ b/include/linux/mtd/omap_gpmc.h @@ -11,6 +11,7 @@ #define GPMC_BUF_EMPTY 0 #define GPMC_BUF_FULL 1 +#define GPMC_MAX_SECTORS 8 enum omap_ecc { /* 1-bit ECC calculation by Software, Error detection by Software */ @@ -75,7 +76,7 @@ struct gpmc { u8 res7[12]; /* 0x224 */ u32 testmomde_ctrl; /* 0x230 */ u8 res8[12]; /* 0x234 */ - struct bch_res_0_3 bch_result_0_3[2]; /* 0x240 */ + struct bch_res_0_3 bch_result_0_3[GPMC_MAX_SECTORS]; /* 0x240,0x250, */ }; /* Used for board specific gpmc initialization */ -- cgit v1.1 From 46840f66caf564866d191886d2bd86742f982010 Mon Sep 17 00:00:00 2001 From: pekon gupta Date: Mon, 2 Jun 2014 17:14:42 +0530 Subject: mtd: nand: omap: add support for BCH16_ECC - NAND driver updates This patch add support for BCH16_ECC to omap_gpmc driver. *need to BCH16 ECC scheme* With newer SLC Flash technologies and MLC NAND, and large densities, pagesizes Flash devices have become more suspectible to bit-flips. Thus stronger ECC schemes are required for protecting the data. But stronger ECC schemes have come with larger-sized ECC syndromes which require more space in OOB/Spare. This puts constrains like; (a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data. (b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B. Due to (b) this scheme can only be used with NAND devices which have enough OOB to satisfy following equation: OOBsize per page >= 26 * (page-size / 512) Signed-off-by: Pekon Gupta --- include/linux/mtd/omap_gpmc.h | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'include/linux') diff --git a/include/linux/mtd/omap_gpmc.h b/include/linux/mtd/omap_gpmc.h index d55fe32..9a86582 100644 --- a/include/linux/mtd/omap_gpmc.h +++ b/include/linux/mtd/omap_gpmc.h @@ -27,6 +27,8 @@ enum omap_ecc { OMAP_ECC_BCH8_CODE_HW_DETECTION_SW, /* 8-bit ECC calculation by GPMC, Error detection by ELM */ OMAP_ECC_BCH8_CODE_HW, + /* 16-bit ECC calculation by GPMC, Error detection by ELM */ + OMAP_ECC_BCH16_CODE_HW, }; struct gpmc_cs { @@ -47,6 +49,10 @@ struct bch_res_0_3 { u32 bch_result_x[4]; }; +struct bch_res_4_6 { + u32 bch_result_x[3]; +}; + struct gpmc { u8 res1[0x10]; u32 sysconfig; /* 0x10 */ @@ -77,6 +83,8 @@ struct gpmc { u32 testmomde_ctrl; /* 0x230 */ u8 res8[12]; /* 0x234 */ struct bch_res_0_3 bch_result_0_3[GPMC_MAX_SECTORS]; /* 0x240,0x250, */ + u8 res9[16 * 4]; /* 0x2C0 - 0x2FF */ + struct bch_res_4_6 bch_result_4_6[GPMC_MAX_SECTORS]; /* 0x300,0x310, */ }; /* Used for board specific gpmc initialization */ -- cgit v1.1