[PATCH] ppc64: Thermal control for SMU based machiens

[Benjamin Herrenschmidt]

On Mon, 2005-11-07 at 05:49 +0100, Christoph Hellwig wrote:
> On Mon, Nov 07, 2005 at 02:30:28PM +1100, Benjamin Herrenschmidt wrote:
> > This adds a new thermal control framework for PowerMac, along with the
> > implementation for PowerMac8,1, PowerMac8,2 (iMac G5 rev 1 and 2), and
> > PowerMac9,1 (latest single CPU desktop). In the future, I expect to move
> > the older G5 thermal control to the new framework as well.
> 
> the core code doesn't seem to be mac-specific, could you please move
> it to common code?  Especially the userland callout should be shared
> with existing drivers on sparc64 and ia64.  I don't request you to move
> those over yet, I'll work with the maintainer to get there later.
>
> What about creating drivers/windfarm/ and move all the files there?

I'd like to massage it a bit more before going to common code. I want to
port the old thermal control, and maybe a bit smarter overtemp code as
well. For now, I'd rather keep it there...

I need it in now (users are complaining enough about their machines
wanting to be vacuum cleaners) and I have no time this week before the
patch gates close to do the other changes I have in mind, so I put that
as a target for after 2.6.15.

> > +struct wf_sensor_ops {
> > +	int			(*get_value)(struct wf_sensor *sr, s32 *val);
> > +	void			(*release)(struct wf_sensor *sr);
> > +        struct module           *owner;
> 
> tabs instead of spaces here :)

oops... oh well...fixing :)

> > +#include <linux/config.h>
> 
> not needed anymore, latest mainline includes the CONFIG_ symbols
> automatically.

Good to know

> > +#include <linux/smp_lock.h>
> 
> not needed.

Yah, remaining of some older bits.

> 
> > +int wf_register_client(struct notifier_block *nb)
> > +{
> > +	int rc;
> > +	struct wf_control *ct;
> > +	struct wf_sensor *sr;
> > +
> > +	down(&wf_lock);
> > +	rc = notifier_chain_register(&wf_client_list, nb);
> > +	if (rc != 0)
> > +		goto bail;
> > +	wf_client_count++;
> > +	list_for_each_entry(ct, &wf_controls, link)
> > +		wf_notify(WF_EVENT_NEW_CONTROL, ct);
> > +	list_for_each_entry(sr, &wf_sensors, link)
> > +		wf_notify(WF_EVENT_NEW_SENSOR, sr);
> > +	if (wf_client_count == 1)
> > +		wf_start_thread();
> > + bail:
> > +	up(&wf_lock);
> > +	return rc;
> > +}
> 
> shouldn't clients get proper methods instead of the notifier_block mess?

It was easier that way for a first implementation. That's what I'm
thinking about "massaging it a bit more" :) There are some lifetime
issues with clients I want to address as well so yes, I think the
notifier will go :) The initial intent of the notifier however was to be
able to have smarter mecanisms like "meta" sensors that catch sensor
creations and create their own sensor (like a power sensor that catch
the voltage and current sensors and exposes a combo power sensor) though
I ended up not doing it that way. I also wanted a way to broadcast
things like overtemp conditions system wide.

But then, there is no limit on what a client can be. That is, the main
"controller" for a given machine is a client, but anything else could be
as well...

> > Index: linux-work/drivers/macintosh/windfarm_smu_controls.c
> > ===================================================================
> > --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> > +++ linux-work/drivers/macintosh/windfarm_smu_controls.c	2005-11-07 13:30:46.000000000 +1100
> > @@ -0,0 +1,274 @@
> 
> no copyright notices?

Will fix.

New patch on the way...

Thanks,
Ben.