From: Parag Warudkar <parag.lkml@gmail.com>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: Parag Warudkar <parag.lkml@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org,
khali@linux-fr.org
Subject: Re: [PATCH] applesmc: Bump max wait and rearrange udelay
Date: Sun, 16 Sep 2012 20:11:29 -0400 (EDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1209161957490.2808@ubuntu> (raw)
In-Reply-To: <20120916223003.GA2160@polaris.bitmath.org>
On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> What exact model is this?
MacBookPro6,1 - 2010 17" MBP.
>
> In addition to Guenter's comments, it is not clear what part of this
> patch makes things work for you. Is it a) the doubling of the wait
> time, or b) the zero initial wait? Or c) just randomly a little bit
> better?
I have addressed Guenter's comments in the revised patch below - I've
minimized the deviation from the original code - only thing additional is
usleep_range which I believe is a good thing to do.
>
> If a), that is very valuable information, and the patch can be
> simplified further. If b), just crank up the wait time and be done
> with it. If c), well, then we don't have a case for a patch.
>
I initially experimented with different max wait values and came to the
conclusion that 0x20000 was good enough to reduce the errors to zero. But
then Guenter pointed out that the original loop terminated too early -
that means it only waited 16 ms instead of 32. I then corrected the loop
termination but kept the original 32ms max wait and used usleep_range()
instead of udelay() - testing with this gave me no errors whereas earlier
the errors were readily reproducible and significant in quanity.
So I guess actually sleeping for 32ms along with the upward variability
introduced by usleep_range() is helping with the fix.
> Also, it is not enough to test this on one machine, for fairly obvious
> reasons. I don't mind testing on a couple of machines close by (MBA3,1
> MBP10,1), once the comments have been addressed. However, a machine
> from around 2008 should be tested as well, since they behave
> differently.
Since we are keeping the changes minimal and using the same 32 ms max wait
as originally intended I think this patch can only make things better. It
sure does make things better on my machine but it will not hurt to test it
on other models.
Parag
Signed-off-by: Parag Warudkar <parag.lkml@gmail.com>
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index 2827088..a168a8f 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -169,12 +169,13 @@ static int wait_read(void)
{
u8 status;
int us;
- for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- udelay(us);
+ for (us = APPLESMC_MIN_WAIT; us <= APPLESMC_MAX_WAIT; us <<= 1) {
status = inb(APPLESMC_CMD_PORT);
/* read: wait for smc to settle */
if (status & 0x01)
return 0;
+ if (us < APPLESMC_MAX_WAIT)
+ usleep_range(us, us << 1);
}
pr_warn("wait_read() fail: 0x%02x\n", status);
@@ -192,7 +193,7 @@ static int send_byte(u8 cmd, u16 port)
outb(cmd, port);
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- udelay(us);
+ usleep_range(us, us << 1);
status = inb(APPLESMC_CMD_PORT);
/* write: wait for smc to settle */
if (status & 0x02)
@@ -204,7 +205,7 @@ static int send_byte(u8 cmd, u16 port)
if (us << 1 == APPLESMC_MAX_WAIT)
break;
/* busy: long wait and resend */
- udelay(APPLESMC_RETRY_WAIT);
+ usleep_range(APPLESMC_RETRY_WAIT, APPLESMC_RETRY_WAIT << 1);
outb(cmd, port);
}
next prev parent reply other threads:[~2012-09-17 0:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-15 22:42 Parag Warudkar
2012-09-15 22:58 ` Guenter Roeck
2012-09-15 23:35 ` Parag Warudkar
2012-09-15 23:38 ` Parag Warudkar
2012-09-16 3:29 ` Parag Warudkar
2012-09-16 4:31 ` Guenter Roeck
2012-09-16 9:35 ` Henrik Rydberg
2012-09-16 21:22 ` Parag Warudkar
2012-09-16 22:00 ` Guenter Roeck
2012-09-16 22:30 ` Henrik Rydberg
2012-09-17 0:11 ` Parag Warudkar [this message]
2012-09-17 16:27 ` Henrik Rydberg
2012-09-17 16:37 ` Guenter Roeck
2012-09-17 20:14 ` Henrik Rydberg
2012-09-17 22:03 ` Guenter Roeck
2012-09-17 18:06 ` Parag Warudkar
2012-09-17 18:49 ` Henrik Rydberg
2012-09-17 18:54 ` Parag Warudkar
2012-09-17 19:14 ` Henrik Rydberg
2012-09-17 19:46 ` Henrik Rydberg
2012-09-17 18:22 ` Parag Warudkar
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=alpine.DEB.2.02.1209161957490.2808@ubuntu \
--to=parag.lkml@gmail.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=rydberg@euromail.se \
/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
Powered by JetHome