RE: [PATCH 13/13] Thermal: Platform layer changes to provide thermal data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 二, 2012-08-21 at 03:28 -0600, R, Durgadoss wrote:
> Hi Rui,
> 
> > 
> > On 二, 2012-08-21 at 00:41 -0600, R, Durgadoss wrote:
> > > Hi Rui,
> > >
> > > > > > -----Original Message-----
> > > > > > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-
> > > > > > owner@xxxxxxxxxxxxxxx] On Behalf Of Eduardo Valentin
> > > > > > Sent: Tuesday, August 21, 2012 11:10 AM
> > > > > > To: R, Durgadoss
> > > > > > Cc: lenb@xxxxxxxxxx; Zhang, Rui; rjw@xxxxxxx; linux-
> > acpi@xxxxxxxxxxxxxxx;
> > > > > > linux-pm@xxxxxxxxxxxxxxx; eduardo.valentin@xxxxxx;
> > > > > > amit.kachhap@xxxxxxxxxx; wni@xxxxxxxxxx
> > > > > > Subject: Re: [PATCH 13/13] Thermal: Platform layer changes to
> > provide
> > > > > > thermal data
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > On Thu, Aug 09, 2012 at 06:16:05PM +0530, Durgadoss R wrote:
> > > > > > > This patch shows how can we add platform specific thermal data
> > > > > > > required by the thermal framework. This is just an example
> > > > > > > patch, and _not_ for merge.
> > > > > > >
> > > > > > > Signed-off-by: Durgadoss R <durgadoss.r@xxxxxxxxx>
> > > > > > > ---
> > > > > > >  arch/x86/platform/mrst/mrst.c |   42
> > > > > > +++++++++++++++++++++++++++++++++++++++++
> > > > > > >  1 file changed, 42 insertions(+)
> > > > > > >
> > > > > > > diff --git a/arch/x86/platform/mrst/mrst.c
> > > > > > b/arch/x86/platform/mrst/mrst.c
> > > > > > > index fd41a92..0440db5 100644
> > > > > > > --- a/arch/x86/platform/mrst/mrst.c
> > > > > > > +++ b/arch/x86/platform/mrst/mrst.c
> > > > > > > @@ -30,6 +30,7 @@
> > > > > > >  #include <linux/mfd/intel_msic.h>
> > > > > > >  #include <linux/gpio.h>
> > > > > > >  #include <linux/i2c/tc35876x.h>
> > > > > > > +#include <linux/thermal.h>
> > > > > > >
> > > > > > >  #include <asm/setup.h>
> > > > > > >  #include <asm/mpspec_def.h>
> > > > > > > @@ -78,6 +79,30 @@ struct sfi_rtc_table_entry
> > > > > > sfi_mrtc_array[SFI_MRTC_MAX];
> > > > > > >  EXPORT_SYMBOL_GPL(sfi_mrtc_array);
> > > > > > >  int sfi_mrtc_num;
> > > > > > >
> > > > > > > +#define MRST_THERMAL_ZONES	3
> > > > > > > +struct thermal_zone_params tzp[MRST_THERMAL_ZONES] = {
> > > > > > > +	{ .thermal_zone_name = "CPU",
> > > > > > > +	.throttle_policy = THERMAL_FAIR_SHARE,
> > > > > > > +	.num_cdevs = 2,
> > > > > > > +	.cdevs_name = {"CPU", "Battery"},
> > > > > > > +	.trip_mask = {0x0F, 0x08},
> > > > > > > +	.weights = {80, 20}, },
> > > > > > > +
> > > > > > > +	{ .thermal_zone_name = "Battery",
> > > > > > > +	.throttle_policy = THERMAL_FAIR_SHARE,
> > > > > > > +	.num_cdevs = 1,
> > > > > > > +	.cdevs_name = {"Battery"},
> > > > > > > +	.trip_mask = {0x0F},
> > > > > > > +	.weights = {100}, },
> > > > > > > +
> > > > > > > +	{ .thermal_zone_name = "Skin",
> > > > > > > +	.throttle_policy = THERMAL_FAIR_SHARE,
> > > > > > > +	.num_cdevs = 2,
> > > > > > > +	.cdevs_name = {"Display", "Battery"},
> > > > > > > +	.trip_mask = {0x0F, 0x0F},
> > > > > > > +	.weights = {50, 50}, }
> > > > > >
> > > > > > Please consider the comment I sent on your data definition and also
> > the
> > > > > > comment I made on this patch on your RFC series.
> > > > >
> > > > > Yes.. I don't know why/how I missed it.
> > > > > Also, saw the same comment on one of the other patches also.
> > > > >
> > > > > Will surely fix this thing in v2.
> > > > >
> > > > > BTW, any suggestion for the 'name' of that structure ? :-)
> > > >
> > > > hmmm,
> > > > do we still have thermal_zone_platforms in patch v2?
> > > > I do not think we need this if we only bind devices via .bind()
> > > > callback.
> > >
> > > We can bind devices via .bind call back, and that will take some load
> > > off the framework code. But even then, we would need this structure
> > > right ?
> > why?
> > I'd prefer introduce something like this,
> > struct thermal_bind_params {
> > 	int trip;
> > 	unsigned long upper;
> > 	unsinged long lower;
> > 	int weight;
> > 	int sample_period;
> > }
> 
> Yes, this can work with little bit change like below:
> 
> struct thermal_zone_params {
> 	const char *zone_name;
> 	int num_cdevs;
> 	struct thermal_bind_params[num_cdevs];
no, not num_cdevs.

Say CPU is used for both passive trip point 1 and passive trip point 2,
it has different lower/upper limit and weight.
and we need two thermal_bind_params here.

> }; 
> 
> Where struct thermal_bind_params will be like this:
> 	{
> 	.cdev_name = "CPU"
and the cooling device name must be unique in this case, which I do not
think it is reasonable.
because cooling devices are registered from different drivers, we do not
have a rule that followed by all these drivers.
> 	.trip_mask = 0x0F
> 	.weight = 70
> 	.lower = 2
> 	.upper = 4
> 	.sample_period = 1000 (1 ms)
> 	};
> 
if we want a way to register a couple of binding information to thermal
framework together with the thermal zone, I'd prefer something like
this,

struct thermal_zone_params {
 	struct thermal_zone_device *tz;
	int count;
 	struct thermal_bind_params *bindings;
}
struct thermal_bind_params {
	.id = 1;
	.match = platform_match_callback();
	.cdev = NULL;
	.weight = 70
	...
}

and in thermal_zone_device_register, we can have the code like this:

list_for_each_entry(cdev, &thermal_cdev_list, node) {
	for (i = 0; i < tz->params->count, i++) {
		if (tz->params->bindings[i].cdev)
			continue;
		/* check if this is the binding for this device */
		if (tz->params->bindings[i].match(tz, cdev, i))
			continue;
		tz->params->bindings[i]->cdev = cdev;
		thermal_zone_bind_cooling_device(tz, cdev, &tz->params->binding[i]);
	}
}

and we can have similar code in thermal_cdev_register().

you can do whatever in your platform_match_callback(), either strcmp or
checking devdata, or anything else.

thanks,
rui

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux