Message-ID: <20130218135012.GB16622@pd.tnic>
Date:	Mon, 18 Feb 2013 14:50:12 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Peter Feuerer <peter@...e.net>
Cc:	Alexander Lam <azl@...rew.cmu.edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andreas Mohr <andi@...as.de>
Subject: Re: thermal governor: does it actually work??

On Sun, Feb 17, 2013 at 04:41:57PM +0100, Peter Feuerer wrote:
> Don't think so, I think this was already in since 2.6.<something> and
> I assume with this patch applied, acerhdf works from at least this
> 2.6.<something> up to new 3.8 and will still work in the future.

Well, it can't be because there wouldn't be breakage otherwise, right?
I've been running 3.5 on the atom for a long time and it was ok but 3.8
is showing the issue. So something *has* changed.

> As far as I understand the code (and
> Documentation/thermal/cpu-cooling-api.txt), the thermal api finds the
> appropriate trip point and then set's the fan to the corresponding
> state, defined by the thermal/fan driver.

Right, but the low level driver defines what to do at each trip point.

> This is nice thing, if you can completely control the speed of the
> fan, because you have then a good fan speed to temperature
> regulation. But we do only have a two point regulation (on and off),
> that's why we have to handle our thresholds within the trip=1 on our
> own to not get an all the time on-off-toggling of the fan.

Ok.

> I think this is how the developer of thermal_sys intended drivers to
> work. But he forgot about two-point regulators (most probably because
> there's no one besides acerhdf)

Fair enough.

> I don't understand what you mean by "in our case it doesn't do
> anything", acerhdf is reporting the trip temperatures correctly, when
> get_trip_temp is called.

Well, we have the thermal_sys.c deal which is at the top-level, then
there's the governor, i.e. step_wise.c in our case. The actual thing
doing the work is ->set_cur_state in acerhdf.c And you've added logic
there too:

> >>+           if ((cur_state == ACERHDF_FAN_OFF) &&
> >>+               (cur_temp > fanon))
> >>                    acerhdf_change_fanstate(ACERHDF_FAN_AUTO);

which I was expecting the thermal layer to do for us and acerhdf to do
only the switching like the cpufreq drivers to, for example. Btw, if we
did this, acerhdf would be even simpler.

But, as you say above, I guess the two-point scheme of acerhdf doesn't
have a governor that fits. So maybe the correct solution is to have an
"on_off" stupid governor which gets used by acerhdf and does simply call
into acerhdf to switch on the fan to auto above a specified trip point.

It could be a lot of overhead for nothing in the end, though.

> You are right, we should at least add the THERMAL_TRIP_CRITICAL, so
> that we handle this, but I think we can ignore THERMAL_TRIP_HOT, as
> it is not really serving anything of value in our case.
> 
> 
> >
> >> 	return 0;
> >>@@ -409,6 +413,10 @@ static int acerhdf_get_trip_temp(struct thermal_zone_device *thermal, int trip,
> >> 				 unsigned long *temp)
> >> {
> >> 	if (trip == 0)
> >>+		*temp = 0;
> >>+	if (trip == 1)
> >>+		*temp = fanoff;
> >>+	if (trip == 2)
> >> 		*temp = fanon;
> >
> >Maybe the critical and hot types need to go here? I.e., 3 and 4?
> 
> Yes, crit has to go there.

Right, I'll wait for that version of the patch to test. :)

Thanks.

-- 
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