[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130224125917.GD19609@pd.tnic>
Date: Sun, 24 Feb 2013 13:59:17 +0100
From: Borislav Petkov <bp@...e.de>
To: Peter Feuerer <peter@...e.net>
Cc: LKML <linux-kernel@...r.kernel.org>,
Zhang Rui <rui.zhang@...el.com>,
Durgadoss R <durgadoss.r@...el.com>,
Borislav Petkov <bp@...e.de>, Andreas Mohr <andi@...as.de>,
Alexander Lam <azl@...rew.cmu.edu>
Subject: Re: [PATCH] acerhdf: Fix fan activation with new thermal governor
On Sun, Feb 24, 2013 at 01:09:52PM +0100, Borislav Petkov wrote:
> On Sun, Feb 24, 2013 at 12:42:55PM +0100, Peter Feuerer wrote:
> > Hi Boris,
> >
> > thanks for your best wishes in the last mail, I'm feeling little better now.
>
> Nice :)
>
> > Please test my last patch with the 4 trip points ;) - even if you
> > don't really like it, it is working great! - And to be honest, I still
> > prefer this solution!
>
> Right, but 4 trip points for this simple driver is a bit of a overkill,
> don't you think? If we want to be really accurate, we'd only need two,
> think of three temperature intervals here:
>
> 0 - temp <= fanon
> 1 - fanon =< temp < crit
> 2 - temp >= crit
>
> I need to go stare at it a bit more.
Oh, and then there's thermal_cdev_update which calls down
->set_cur_state, i.e. acerhdf_set_cur_state() handing us down a state
which we're supposed to take into consideration but we completely ignore
and no our own thing.
And, AFAICT, when this thing gets called, we need to set the fan to
either AUTO or OFF, based on the state it's giving us from above, no?
Because with acerhdf_get_max_state() we tell it that we have two states,
0 and 1.
Hmm.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists