* [PATCH] drivers/mtd/chips/cfi_cmdset_0001.c: correct block lock timeout
@ 2009-03-24 18:14 Andrew Klossner
2009-03-25 16:27 ` Anders Grafström
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Klossner @ 2009-03-24 18:14 UTC (permalink / raw)
To: linux-mtd
The time parameters to WAIT_TIMEOUT are in units of microseconds, so
one second must be expressed as 1000000 not 1000000/HZ.
The Intel Strataflash part with which this patch was tested takes 0.7
seconds to lock/unlock, so one second does indeed seem to be a good
timeout value.
Signed-off-by: Andrew Klossner <andrew@cesa.opbu.xerox.com>
---
diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index f5ab6fa..97f3c71 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -2041,7 +2041,7 @@ static int __xipram do_xxlock_oneblock(struct map_info *map, struct flchip *chip
* If Instant Individual Block Locking supported then no need
* to delay.
*/
- udelay = (!extp || !(extp->FeatureSupport & (1 << 5))) ? 1000000/HZ : 0;
+ udelay = (!extp || !(extp->FeatureSupport & (1 << 5))) ? 1000000 : 0;
ret = WAIT_TIMEOUT(map, chip, adr, udelay, udelay * 100);
if (ret) {
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] drivers/mtd/chips/cfi_cmdset_0001.c: correct block lock timeout
2009-03-24 18:14 [PATCH] drivers/mtd/chips/cfi_cmdset_0001.c: correct block lock timeout Andrew Klossner
@ 2009-03-25 16:27 ` Anders Grafström
0 siblings, 0 replies; 2+ messages in thread
From: Anders Grafström @ 2009-03-25 16:27 UTC (permalink / raw)
To: Andrew Klossner; +Cc: linux-mtd
Andrew Klossner wrote:
> The time parameters to WAIT_TIMEOUT are in units of microseconds, so
> one second must be expressed as 1000000 not 1000000/HZ.
>
> The Intel Strataflash part with which this patch was tested takes 0.7
> seconds to lock/unlock, so one second does indeed seem to be a good
> timeout value.
>
> Signed-off-by: Andrew Klossner <andrew@cesa.opbu.xerox.com>
> ---
> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
> index f5ab6fa..97f3c71 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
> @@ -2041,7 +2041,7 @@ static int __xipram do_xxlock_oneblock(struct map_info *map, struct flchip *chip
> * If Instant Individual Block Locking supported then no need
> * to delay.
> */
> - udelay = (!extp || !(extp->FeatureSupport & (1 << 5))) ? 1000000/HZ : 0;
> + udelay = (!extp || !(extp->FeatureSupport & (1 << 5))) ? 1000000 : 0;
>
> ret = WAIT_TIMEOUT(map, chip, adr, udelay, udelay * 100);
> if (ret) {
If I'm not mistaken, this will change the minimum sleep time to half a second
for set lock-bit operations as well (for !XIP). Aren't those in the usec range?
The last argument to WAIT_TIMEOUT(), udelay_max, is the actual timeout.
It should have been 'udelay * HZ', i.e. it would have worked for HZ=100 but not for HZ=1000.
(The J5 datasheet says 7 seconds max clear lock-bit time, so times 10 might even be in place.)
diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index b234ab9..d2e4fdf 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -2069,7 +2069,7 @@ static int __xipram do_xxlock_oneblock(struct map_info *map, struct flchip *chip
*/
udelay = (!extp || !(extp->FeatureSupport & (1 << 5))) ? 1000000/HZ : 0;
- ret = WAIT_TIMEOUT(map, chip, adr, udelay, udelay * 100);
+ ret = WAIT_TIMEOUT(map, chip, adr, udelay, udelay * HZ * 10);
if (ret) {
map_write(map, CMD(0x70), adr);
chip->state = FL_STATUS;
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-03-25 16:28 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-24 18:14 [PATCH] drivers/mtd/chips/cfi_cmdset_0001.c: correct block lock timeout Andrew Klossner
2009-03-25 16:27 ` Anders Grafström
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).