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 19:14:16 +0000	[thread overview]
Message-ID: <20120917191416.GA598@polaris.bitmath.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1209171446390.1963@ubuntu>

On Mon, Sep 17, 2012 at 02:54:25PM -0400, Parag Warudkar wrote:
> 
> 
> On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> 
> > So the question is, does this patch work equally well for you?
> > 
> > 
> > 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
> > 
> 
> That was something that I tried originally and it still resulted in 
> failures - albeit lesser in number.

Good, just wanted to touch base here, so we know what we are doing.

> I had to bump it to 0x20000 (effective wait of 65536) with the original 
> loop termination logic and  udelay() in order to get it to reduce to 
> zero.
> 
> Note that with usleep_range - each sleep is potentially more than the 
> minimum - that's may be why 32ms works with usleep_range but not with 
> udelay which is precise.

Yes, so if you also change APPLESMC_MIN_WAIT to 0x0020, what happens?

> So bottomline, I suspect we will need to bump to 0x20000 if you want to 
> keep the current loop termination and udelay().

That is just crazy, since your code works with a 32ms maximum.

Thanks,
Henrik

_______________________________________________
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 21:14:16 +0200	[thread overview]
Message-ID: <20120917191416.GA598@polaris.bitmath.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1209171446390.1963@ubuntu>

On Mon, Sep 17, 2012 at 02:54:25PM -0400, Parag Warudkar wrote:
> 
> 
> On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> 
> > So the question is, does this patch work equally well for you?
> > 
> > 
> > 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
> > 
> 
> That was something that I tried originally and it still resulted in 
> failures - albeit lesser in number.

Good, just wanted to touch base here, so we know what we are doing.

> I had to bump it to 0x20000 (effective wait of 65536) with the original 
> loop termination logic and  udelay() in order to get it to reduce to 
> zero.
> 
> Note that with usleep_range - each sleep is potentially more than the 
> minimum - that's may be why 32ms works with usleep_range but not with 
> udelay which is precise.

Yes, so if you also change APPLESMC_MIN_WAIT to 0x0020, what happens?

> So bottomline, I suspect we will need to bump to 0x20000 if you want to 
> keep the current loop termination and udelay().

That is just crazy, since your code works with a 32ms maximum.

Thanks,
Henrik

  reply	other threads:[~2012-09-17 19:14 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                     ` [lm-sensors] " Henrik Rydberg
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                         ` Henrik Rydberg [this message]
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=20120917191416.GA598@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.