public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Jean Delvare <jdelvare@suse.de>
Cc: "Pali Rohár" <pali.rohar@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: Dell Latitude E6440 & i8k
Date: Sat, 17 May 2014 15:18:54 -0700	[thread overview]
Message-ID: <5377E04E.2070505@roeck-us.net> (raw)
In-Reply-To: <20140517230940.25c36f07@endymion.delvare>

On 05/17/2014 02:09 PM, Jean Delvare wrote:
> On Sat, 17 May 2014 08:25:38 -0700, Guenter Roeck wrote:
>> On 05/16/2014 12:11 PM, Jean Delvare wrote:
>>> Load the i8k driver with fan_mult=1.
>>
>> Would it make sense to change the default multiplier to 1 ?
>> Lots of people have problems with it, and trying to figure out
>> affected machines one by one would be an all but impossible task.
>
> That would cause a regression on many (presumably older) machines. I
> doubt this is acceptable. One option would be to use the ACPI year to
> change the default, if indeed all new machines need fan_mult=1. I don't
> know if this is the case.
>
> One this I had in mind was auto-detecting the scaling factor. AFAIK
> only 30 and 1 are possible values, so any value above ~300 would imply
> scaling factor of 1 (30 would make it > 9000 RPM which is unrealistic.)
> But I don't know if we can actually do that, as such a simple heuristic
> could easily fail is the fan is stopped (30 * 0 == 1 * 0) or if the
> returned raw speed is temporarily unreliable for whatever reason.
>
Sounds like an idea. We could make the cutoff higher, such as 500 or
even 1000. I am not much concerned about 0 rpm - the code could simply check
the returned rpm and adjust the scaling factor to 1 if the reading is too
high. Since 30*0 is still 0, there is no problem if the fan is stopped.

> I have to admit that working on a reverse engineered driver for
> hardware I don't even have isn't quite at the top of my to-do list.
>

;-). We have several of those systems, so there is at least some interest
on my side. If I have time, I'll play around with it. The driver does need
major cleanup, though, so that may take a while.

Guenter


  reply	other threads:[~2014-05-17 22:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-16 18:37 Dell Latitude E6440 & i8k Pali Rohár
2014-05-16 19:11 ` Jean Delvare
2014-05-16 19:23   ` Pali Rohár
2014-05-17  9:44     ` Jean Delvare
2014-05-17 15:34     ` Guenter Roeck
2014-05-17 23:01       ` Pali Rohár
2014-05-18  8:23         ` Jean Delvare
2014-05-17 15:25   ` Guenter Roeck
2014-05-17 21:09     ` Jean Delvare
2014-05-17 22:18       ` Guenter Roeck [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-05-17 22:54 Pali Rohár

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=5377E04E.2070505@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=jdelvare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pali.rohar@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