From: "Henrik Rydberg" <rydberg@euromail.se>
To: Parag Warudkar <parag.lkml@gmail.com>
Cc: 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: Mon, 17 Sep 2012 00:30:03 +0200 [thread overview]
Message-ID: <20120916223003.GA2160@polaris.bitmath.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1209161712070.14838@ubuntu>
Hi Parag,
> > On Sat, Sep 15, 2012 at 09:31:16PM -0700, Guenter Roeck wrote:
> > > That looks terribly complicated. Better keep the loop, and just replace
> > > udelay(us);
> > > with something like
> > > usleep_range(us, us << 1);
> > >
> > > Alternatively, just use a constant such as
> > > usleep_range(us, us + APPLESMC_MIN_WAIT);
> >
> Well I don't think there is anything terribly complicated there - but I
> tried to make it simpler. Below patch seems to work better for me for my
> normal workload - I got no failures or other oddities with the default
> 32ms timeout. I haven't tried very hard to get to the corner cases which
> earlier required a higher timeout.
What exact model is this?
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?
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.
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.
> Henrik - if the below patch still results in failures we can
> revisit the long wait cases. For now I am satisfied that there aren't any
> normal case failures like before.
Well, I am satisfied once I know the patch will work on all supported
models.
Thanks.
Henrik
next prev parent reply other threads:[~2012-09-16 22:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-15 22:42 [PATCH] applesmc: Bump max wait and rearrange udelay 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 [this message]
2012-09-17 0:11 ` Parag Warudkar
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=20120916223003.GA2160@polaris.bitmath.org \
--to=rydberg@euromail.se \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=parag.lkml@gmail.com \
/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