All of lore.kernel.org
 help / color / mirror / Atom feed
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: [lm-sensors] [PATCH] applesmc: Bump max wait and rearrange udelay
Date: Mon, 17 Sep 2012 18:49:54 +0000	[thread overview]
Message-ID: <20120917184954.GA349@polaris.bitmath.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1209171356340.3412@ubuntu>

On Mon, Sep 17, 2012 at 02:06:05PM -0400, Parag Warudkar wrote:
> 
> 
> On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> 
> > The current patch does exactly the same sleeps, the only difference is
> > that the test is also done before the first sleep. Thus, the increased
> > delay, if any, comes from the sleep range.
> My understanding is that the original patch resulted in trying a 
> max udelay(16). The new one does usleep_range(16, 32). That's a minimum 16 
> max 32 - so the fact that it stops read failures means the added delay is 
> present and does help.

So the question is, does this patch work equally well for you?

Henrik

diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index 2827088..8bf9011 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -56,7 +56,7 @@
 /* wait up to 32 ms for a status change. */
 #define APPLESMC_MIN_WAIT      0x0010
 #define APPLESMC_RETRY_WAIT    0x0100
-#define APPLESMC_MAX_WAIT      0x8000
+#define APPLESMC_MAX_WAIT      0x10000
 
 #define APPLESMC_READ_CMD      0x10
 #define APPLESMC_WRITE_CMD     0x11

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

WARNING: multiple messages have this Message-ID (diff)
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 20:49:54 +0200	[thread overview]
Message-ID: <20120917184954.GA349@polaris.bitmath.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1209171356340.3412@ubuntu>

On Mon, Sep 17, 2012 at 02:06:05PM -0400, Parag Warudkar wrote:
> 
> 
> On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> 
> > The current patch does exactly the same sleeps, the only difference is
> > that the test is also done before the first sleep. Thus, the increased
> > delay, if any, comes from the sleep range.
> My understanding is that the original patch resulted in trying a 
> max udelay(16). The new one does usleep_range(16, 32). That's a minimum 16 
> max 32 - so the fact that it stops read failures means the added delay is 
> present and does help.

So the question is, does this patch work equally well for you?

Henrik

diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index 2827088..8bf9011 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -56,7 +56,7 @@
 /* wait up to 32 ms for a status change. */
 #define APPLESMC_MIN_WAIT      0x0010
 #define APPLESMC_RETRY_WAIT    0x0100
-#define APPLESMC_MAX_WAIT      0x8000
+#define APPLESMC_MAX_WAIT      0x10000
 
 #define APPLESMC_READ_CMD      0x10
 #define APPLESMC_WRITE_CMD     0x11

  reply	other threads:[~2012-09-17 18:49 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-15 22:42 [lm-sensors] [PATCH] applesmc: Bump max wait and rearrange udelay Parag Warudkar
2012-09-15 22:42 ` Parag Warudkar
2012-09-15 22:58 ` [lm-sensors] " Guenter Roeck
2012-09-15 22:58   ` Guenter Roeck
2012-09-15 23:35   ` [lm-sensors] " Parag Warudkar
2012-09-15 23:35     ` Parag Warudkar
2012-09-15 23:38     ` [lm-sensors] " Parag Warudkar
2012-09-15 23:38       ` Parag Warudkar
2012-09-16  3:29     ` [lm-sensors] " Parag Warudkar
2012-09-16  3:29       ` Parag Warudkar
2012-09-16  4:31       ` [lm-sensors] " Guenter Roeck
2012-09-16  4:31         ` Guenter Roeck
2012-09-16  9:35         ` [lm-sensors] " Henrik Rydberg
2012-09-16  9:35           ` Henrik Rydberg
2012-09-16 21:22           ` [lm-sensors] " Parag Warudkar
2012-09-16 21:22             ` Parag Warudkar
2012-09-16 22:00             ` [lm-sensors] " Guenter Roeck
2012-09-16 22:00               ` Guenter Roeck
2012-09-16 22:30             ` [lm-sensors] " Henrik Rydberg
2012-09-16 22:30               ` Henrik Rydberg
2012-09-17  0:11               ` [lm-sensors] " Parag Warudkar
2012-09-17  0:11                 ` Parag Warudkar
2012-09-17 16:27                 ` [lm-sensors] " Henrik Rydberg
2012-09-17 16:27                   ` Henrik Rydberg
2012-09-17 16:37                   ` [lm-sensors] " Guenter Roeck
2012-09-17 16:37                     ` Guenter Roeck
2012-09-17 20:14                     ` [lm-sensors] " Henrik Rydberg
2012-09-17 20:14                       ` Henrik Rydberg
2012-09-17 22:03                       ` [lm-sensors] " Guenter Roeck
2012-09-17 22:03                         ` Guenter Roeck
2012-09-17 18:06                   ` [lm-sensors] " Parag Warudkar
2012-09-17 18:06                     ` Parag Warudkar
2012-09-17 18:49                     ` Henrik Rydberg [this message]
2012-09-17 18:49                       ` Henrik Rydberg
2012-09-17 18:54                       ` [lm-sensors] " Parag Warudkar
2012-09-17 18:54                         ` Parag Warudkar
2012-09-17 19:14                         ` [lm-sensors] " Henrik Rydberg
2012-09-17 19:14                           ` Henrik Rydberg
2012-09-17 19:46                           ` [lm-sensors] " Henrik Rydberg
2012-09-17 19:46                             ` Henrik Rydberg
2012-09-17 18:22                   ` [lm-sensors] " Parag Warudkar
2012-09-17 18:22                     ` Parag Warudkar
2012-09-17 21:38 ` [lm-sensors] " 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=20120917184954.GA349@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.