From: Andrew Dyer <amdyer@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] PATCH for drivers/cfi_flash.c
Date: Sat, 28 May 2005 17:15:33 -0500 [thread overview]
Message-ID: <c166aa9f0505281515495cf1c5@mail.gmail.com> (raw)
In-Reply-To: <427B28D2.9010704@orkun.us>
On 5/6/05, Tolunay Orkun <listmember@orkun.us> wrote:
> This patch is prepared against current CVS:
>
> * Patch by Tolunay Orkun, 06 May 2005:
> Fixes for drivers/cfi_flash.c:
> - Fix wrong timeout value usage in flash_status_check()
I tried this part of this patch out and aggravated some problems in
the cfi_flash code.
Several of the timeout parameters in the CFI query structure return units of
microseconds. I use an AMD 29LV160 part. In the CFI parser code these
microsecond values are converted to milliseconds by integer division. For
the 29LV160 this leaves some of the timeout parameters in the info structure
at zero.
Using these zero values, the code in flash_status_check() will sometimes read
busy once, the timer count happens to roll over, get read, and a timeout is
registered if tout is zero.
I can see a few ways to fix this:
1) adjust the info values after the scaling to millisecond values
2) force a one tick delay no matter what in flash_status_check()
3) modify the code to report everything in microseconds and use udelay
4) use set_timer() to make sure there is a full timer tick
Any opinions about the best way to fix this? Or is it fixed in someones patch
already?
===================================================================
> RCS file: /cvsroot/u-boot/u-boot/drivers/cfi_flash.c,v
> retrieving revision 1.17
> diff -p -u -r1.17 cfi_flash.c
> --- drivers/cfi_flash.c 13 Apr 2005 10:02:47 -0000 1.17
> +++ drivers/cfi_flash.c 6 May 2005 07:06:04 -0000
> @@ -676,7 +676,7 @@ static int flash_status_check (flash_inf
> /* Wait for command completion */
> start = get_timer (0);
> while (flash_is_busy (info, sector)) {
> - if (get_timer (start) > info->erase_blk_tout * CFG_HZ) {
> + if (get_timer (start) > tout * CFG_HZ) {
> printf ("Flash %s timeout at address %lx data %lx\n",
> prompt, info->start[sector],
> flash_read_long (info, sector, 0));
--
Hardware, n.:
The parts of a computer system that can be kicked.
next prev parent reply other threads:[~2005-05-28 22:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-06 8:20 [U-Boot-Users] PATCH for drivers/cfi_flash.c Tolunay Orkun
2005-05-28 22:15 ` Andrew Dyer [this message]
2005-05-30 8:23 ` Wolfgang Denk
2005-05-31 16:14 ` Tolunay Orkun
2005-05-31 20:06 ` Wolfgang Denk
2005-05-31 16:02 ` Tolunay Orkun
2005-05-31 20:05 ` Wolfgang Denk
2005-05-31 20:54 ` Tolunay Orkun
2005-06-01 7:24 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2005-06-01 7:03 Peter Pearse
2005-07-03 0:50 Tolunay Orkun
2006-02-28 16:33 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c166aa9f0505281515495cf1c5@mail.gmail.com \
--to=amdyer@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox