Re: [PATCH 2/2] mtd: nand: omap: Synchronize access to the ECC engine

From: Roger Quadros
Date: Thu Oct 02 2014 - 03:13:25 EST


On 10/01/2014 05:59 PM, Rostislav Lisovy wrote:
> The AM335x Technical Reference Manual (spruh73j.pdf) says
> "Because the ECC engine includes only one accumulation context,
> it can be allocated to only one chip-select at a time ... "
> (7.1.3.3.12.3). Since the commit 97a288ba2cfa ("ARM: omap2+:
> gpmc-nand: Use dynamic platform_device_alloc()") gpmc-nand
> driver supports multiple NAND flash devices connected to
> the single controller. Use spinlocks to restrict access
> to the ECC engine for single read/write operation at a time.
>
> Tested with custom AM335x board using 2x NAND flash chips.
>
> Signed-off-by: Rostislav Lisovy <lisovy@xxxxxxxxx>
> ---
> drivers/mtd/nand/omap2.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 24d5c6a..8761a5b 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -24,6 +24,7 @@
> #include <linux/slab.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/spinlock.h>
>
> #include <linux/mtd/nand_bch.h>
> #include <linux/platform_data/elm.h>
> @@ -146,6 +147,7 @@ static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
> static u_char bch4_vector[] = {0x00, 0x6b, 0x31, 0xdd, 0x41, 0xbc, 0x10};
> #endif
>
> +static DEFINE_SPINLOCK(omap_eccengine_lock);
>
> struct omap_nand_info {
> struct nand_hw_control controller;
> @@ -1518,6 +1520,7 @@ static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> uint8_t *ecc_calc = chip->buffers->ecccalc;
> uint32_t *eccpos = chip->ecc.layout->eccpos;
>
> + spin_lock(&omap_eccengine_lock);
> /* Enable GPMC ecc engine */
> chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
>
> @@ -1526,6 +1529,7 @@ static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>
> /* Update ecc vector from GPMC result registers */
> chip->ecc.calculate(mtd, buf, &ecc_calc[0]);
> + spin_unlock(&omap_eccengine_lock);
>
> for (i = 0; i < chip->ecc.total; i++)
> chip->oob_poi[eccpos[i]] = ecc_calc[i];
> @@ -1561,6 +1565,7 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> int stat;
> unsigned int max_bitflips = 0;
>
> + spin_lock(&omap_eccengine_lock);
> /* Enable GPMC ecc engine */
> chip->ecc.hwctl(mtd, NAND_ECC_READ);
>
> @@ -1573,6 +1578,7 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>
> /* Calculate ecc bytes */
> chip->ecc.calculate(mtd, buf, ecc_calc);
> + spin_unlock(&omap_eccengine_lock);
>
> memcpy(ecc_code, &chip->oob_poi[eccpos[0]], chip->ecc.total);
>
>
The access to the BCH/ELM engine is still not serialized for ecc->read_subpage and ecc->write_subpage() in case of
OMAP_ECC_BCH4_CODE_HW
OMAP_ECC_BCH8_CODE_HW
OMAP_ECC_BCH16_CODE_HW

What about serializing access to BCH engine for read/write_page() and read/write_subpage() in case of
OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW

and finally we should also serialize access to ECC engine for read/write_page() and read/write_subpage() in case of
OMAP_ECC_HAM1_CODE_HW

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/