From: nishanth menon Sent: Tuesday, January 08, 2008 4:54 AM
> I checked this issue on a 2420, looks like for some reason,
> the explicit call to unlock seems to put the device in some
> status state, the following patch seems to work.. but the
> real "fix" could be in cfi
> driver."drivers/mtd/chips/cfi_cmdset_0001.c"
> cfi_intelext_unlock I think.. maybe you need to ask the mtd list.
>
> ---
> MTD:ARM: Work around for a possible unlock issue in
> cfi_cmdset unlock func On calling unlock, the driver should
> ideally put the device back in readable state, instead it
> might be in status mode workaround this by forcing a dummy
> read op after a unlock
>
> ---
> drivers/mtd/maps/omap_nor.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/maps/omap_nor.c
> b/drivers/mtd/maps/omap_nor.c index d72cc11..9f58dd1 100644
> --- a/drivers/mtd/maps/omap_nor.c
> +++ b/drivers/mtd/maps/omap_nor.c
> @@ -111,6 +111,14 @@ static int __devinit
> omapflash_probe(struct platform_device *pdev)
> /* Unlock the flash device. */
> if (info->mtd->unlock)
> info->mtd->unlock(info->mtd, 0, info->mtd->size);
> + /* HACK by a forcing a dummy read To reset the
> partition to readable
> + * TODO: a real fix is by fixing unlock function
> + */
> + if (info->mtd->read) {
> + u_char val;
> + size_t len = sizeof(val);
> + info->mtd->read(info->mtd, 0,len,&len, &val);
> + }
>
> #ifdef CONFIG_MTD_PARTITIONS
> err = parse_mtd_partitions(info->mtd, part_probes,
> &info->parts, 0);
>
This patch looks reasonable, just one byte from the first sector is marked read array and the remaining sectors/partions are still unlocked. I tested this patch on 3430, the WDT reset works fine.
Regards
Iqbal
-
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
