Hello Stefan,
On 2/27/2012 3:56 PM, Stefan Roese wrote:
On Friday 24 February 2012 13:23:06 Amit Virdi wrote:
Curently the code makes wrong assumption that the Transfer finished flag
shall be set within the stipulated time. However, there may occur a
scenario in which the TFF flag is not set. Return error in that case.
Signed-off-by: Vipin Kumar<vipin.ku...@st.com>
Signed-off-by: Amit Virdi<amit.vi...@st.com>
---
drivers/mtd/st_smi.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/st_smi.c b/drivers/mtd/st_smi.c
index 82f1fe1..ec19b0d 100644
--- a/drivers/mtd/st_smi.c
+++ b/drivers/mtd/st_smi.c
@@ -58,13 +58,15 @@ static struct flash_dev flash_ids[] = {
*
* Wait until TFF is set in status register
*/
-static void smi_wait_xfer_finish(int timeout)
+static int smi_wait_xfer_finish(int timeout)
{
- while (timeout--) {
+ do {
if (readl(&smicntl->smi_sr)& TFF)
- break;
+ return 0;
udelay(1000);
- }
+ } while (timeout--);
+
+ return -1;
Somewhat unrelated to the patch topic, but I don't really like this kind of
timeout loops. Since it always adds at least 1ms delay after initial failing
test. Better use something like this:
static int smi_wait_xfer_finish(int timeout)
{
ulong start = get_timer(0);
while (get_timer(start)< timeout) {
if (readl(&smicntl->smi_sr)& TFF)
return 0;
/* Try again after 100usec */
udelay(100);
}
return -1;
}
You could tune this udelay(100) down more or even remove it completely.
But such a change could be done in a addon cleanup patch, changing all timeout
loops this way. I suggest you take a look at my version, here these loops are
changes. In the designware networking driver as well, iirc.
Thanks for pointing out. In a separate cleanup patch, I shall be
changing all the timeout loops for smi driver. I'll check other ST
drivers too and change the timer implementation there too.
Regards
Amit Virdi
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
