RE: [PATCH] Syntactic and factual errors in the API document

[R, Durgadoss]

>-Original Message-
>From: Andy Champ [mailto:andyc...@amazon.com]
>Sent: Tuesday, March 22, 2016 6:07 PM
>To: edubez...@gmail.com
>Cc: cor...@lwn.net; javi.mer...@arm.com; R, Durgadoss <durgados...@intel.com>;
>leo@linaro.org; kapileshwar.si...@arm.com; w...@nvidia.com; 
>linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; andyc...@amazon.com
>Subject: [PATCH] Syntactic and factual errors in the API document
>
>There are several places where the English in the document is syntactically
>invalid, or unclear. There are also one or two factual errors.
>

Please add linux-pm list also,

Looks good to me,

Reviewed-by: Durgadoss R <durgados...@intel.com>

Thanks,
Durga

>---
> Documentation/thermal/sysfs-api.txt | 44 ++---
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
>diff --git a/Documentation/thermal/sysfs-api.txt 
>b/Documentation/thermal/sysfs-api.txt
>index 8c745c8..5bc73ef 100644
>--- a/Documentation/thermal/sysfs-api.txt
>+++ b/Documentation/thermal/sysfs-api.txt
>@@ -69,8 +69,8 @@ temperature) and throttle appropriate devices.
> 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
>
> This interface function removes the thermal zone device.
>-It deletes the corresponding entry form /sys/class/thermal folder and
>-unbind all the thermal cooling devices it uses.
>+It deletes the corresponding entry from /sys/class/thermal folder and
>+unbinds all the thermal cooling devices it uses.
>
> 1.2 thermal cooling device interface
> 1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char 
> *name,
>@@ -78,32 +78,32 @@ temperature) and throttle appropriate devices.
>
> This interface function adds a new thermal cooling device 
> (fan/processor/...)
> to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind 
> itself
>-to all the thermal zone devices register at the same time.
>+to all the thermal zone devices registered at the same time.
> name: the cooling device name.
> devdata: device private data.
> ops: thermal cooling devices call-backs.
>   .get_max_state: get the Maximum throttle state of the cooling device.
>-  .get_cur_state: get the Current throttle state of the cooling device.
>+  .get_cur_state: get the Currently requested throttle state of the 
>cooling device.
>   .set_cur_state: set the Current throttle state of the cooling device.
>
> 1.2.2 void thermal_cooling_device_unregister(struct thermal_cooling_device 
> *cdev)
>
>-This interface function remove the thermal cooling device.
>-It deletes the corresponding entry form /sys/class/thermal folder and
>-unbind itself from all the thermal zone devices using it.
>+This interface function removes the thermal cooling device.
>+It deletes the corresponding entry from /sys/class/thermal folder and
>+unbinds itself from all the thermal zone devices using it.
>
> 1.3 interface for binding a thermal zone device with a thermal cooling device
> 1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz,
>   int trip, struct thermal_cooling_device *cdev,
>   unsigned long upper, unsigned long lower, unsigned int weight);
>
>-This interface function bind a thermal cooling device to the certain trip
>+This interface function binds a thermal cooling device to a particular 
>trip
> point of a thermal zone device.
> This function is usually called in the thermal zone device .bind callback.
> tz: the thermal zone device
> cdev: thermal cooling device
>-trip: indicates which trip point the cooling devices is associated with
>-in this thermal zone.
>+trip: indicates which trip point in this thermal zone the cooling device
>+  is associated with.
> upper:the Maximum cooling state for this trip point.
>   THERMAL_NO_LIMIT means no upper limit,
> and the cooling device can be in max_state.
>@@ -116,13 +116,13 @@ temperature) and throttle appropriate devices.
> 1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz,
>   int trip, struct thermal_cooling_device *cdev);
>
>-This interface function unbind a thermal cooling device from the certain
>+This interface function unbinds a thermal cooling device from a particular
> trip point of a thermal zone device. This function is usually called in
> the thermal zone device .unbind callback.
> tz: the thermal zone device
> cdev: thermal cooling device
>-trip: indicates which trip point the cooling devices is associated with
>-in this thermal zone.
>+trip: indicates which t

RE: [PATCH] Syntactic and factual errors in the API document

[R, Durgadoss]

>-Original Message-
>From: Andy Champ [mailto:andyc...@amazon.com]
>Sent: Tuesday, March 22, 2016 6:07 PM
>To: edubez...@gmail.com
>Cc: cor...@lwn.net; javi.mer...@arm.com; R, Durgadoss ;
>leo@linaro.org; kapileshwar.si...@arm.com; w...@nvidia.com; 
>linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; andyc...@amazon.com
>Subject: [PATCH] Syntactic and factual errors in the API document
>
>There are several places where the English in the document is syntactically
>invalid, or unclear. There are also one or two factual errors.
>

Please add linux-pm list also,

Looks good to me,

Reviewed-by: Durgadoss R 

Thanks,
Durga

>---
> Documentation/thermal/sysfs-api.txt | 44 ++---
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
>diff --git a/Documentation/thermal/sysfs-api.txt 
>b/Documentation/thermal/sysfs-api.txt
>index 8c745c8..5bc73ef 100644
>--- a/Documentation/thermal/sysfs-api.txt
>+++ b/Documentation/thermal/sysfs-api.txt
>@@ -69,8 +69,8 @@ temperature) and throttle appropriate devices.
> 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
>
> This interface function removes the thermal zone device.
>-It deletes the corresponding entry form /sys/class/thermal folder and
>-unbind all the thermal cooling devices it uses.
>+It deletes the corresponding entry from /sys/class/thermal folder and
>+unbinds all the thermal cooling devices it uses.
>
> 1.2 thermal cooling device interface
> 1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char 
> *name,
>@@ -78,32 +78,32 @@ temperature) and throttle appropriate devices.
>
> This interface function adds a new thermal cooling device 
> (fan/processor/...)
> to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind 
> itself
>-to all the thermal zone devices register at the same time.
>+to all the thermal zone devices registered at the same time.
> name: the cooling device name.
> devdata: device private data.
> ops: thermal cooling devices call-backs.
>   .get_max_state: get the Maximum throttle state of the cooling device.
>-  .get_cur_state: get the Current throttle state of the cooling device.
>+  .get_cur_state: get the Currently requested throttle state of the 
>cooling device.
>   .set_cur_state: set the Current throttle state of the cooling device.
>
> 1.2.2 void thermal_cooling_device_unregister(struct thermal_cooling_device 
> *cdev)
>
>-This interface function remove the thermal cooling device.
>-It deletes the corresponding entry form /sys/class/thermal folder and
>-unbind itself from all the thermal zone devices using it.
>+This interface function removes the thermal cooling device.
>+It deletes the corresponding entry from /sys/class/thermal folder and
>+unbinds itself from all the thermal zone devices using it.
>
> 1.3 interface for binding a thermal zone device with a thermal cooling device
> 1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz,
>   int trip, struct thermal_cooling_device *cdev,
>   unsigned long upper, unsigned long lower, unsigned int weight);
>
>-This interface function bind a thermal cooling device to the certain trip
>+This interface function binds a thermal cooling device to a particular 
>trip
> point of a thermal zone device.
> This function is usually called in the thermal zone device .bind callback.
> tz: the thermal zone device
> cdev: thermal cooling device
>-trip: indicates which trip point the cooling devices is associated with
>-in this thermal zone.
>+trip: indicates which trip point in this thermal zone the cooling device
>+  is associated with.
> upper:the Maximum cooling state for this trip point.
>   THERMAL_NO_LIMIT means no upper limit,
> and the cooling device can be in max_state.
>@@ -116,13 +116,13 @@ temperature) and throttle appropriate devices.
> 1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz,
>   int trip, struct thermal_cooling_device *cdev);
>
>-This interface function unbind a thermal cooling device from the certain
>+This interface function unbinds a thermal cooling device from a particular
> trip point of a thermal zone device. This function is usually called in
> the thermal zone device .unbind callback.
> tz: the thermal zone device
> cdev: thermal cooling device
>-trip: indicates which trip point the cooling devices is associated with
>-in this thermal zone.
>+trip: indicates which trip point in this thermal zone the cooling device
>+

RE: [PATCH 1/2] Thermal:Fix memory leak if occur goto unregister

[R, Durgadoss]

>-Original Message-
>From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
>ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
>Sent: Monday, October 20, 2014 6:04 PM
>To: Yao Dongdong
>Cc: Zhang, Rui; linux...@vger.kernel.org; LKML
>Subject: Re: [PATCH 1/2] Thermal:Fix memory leak if occur goto unregister
>
>Hello,
>
>On Mon, Oct 20, 2014 at 04:27:36PM +0800, Yao Dongdong wrote:
>> Signed-off-by:yaodongd...@huawei.com
>
>Acked-by: Eduardo Valentin 
>
>Rui, would you take care of this?
>

If I remember it right, this 'tz' is freed in the thermal_release()
function, during device_unregister().

It is similar in all other functions in thermal_core.c

So, Yao, Did you really test this patch ?
And did not see any crashes ?

Thanks,
Durga

>>
>> ---
>>  drivers/thermal/thermal_core.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index 71b0ec0..5b7d466 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -1574,6 +1574,7 @@ struct thermal_zone_device
>*thermal_zone_device_register(const char *type,
>>  unregister:
>> release_idr(_tz_idr, _idr_lock, tz->id);
>> device_unregister(>device);
>> +   kfree(tz);
>> return ERR_PTR(result);
>>  }
>>  EXPORT_SYMBOL_GPL(thermal_zone_device_register);
>> --
>> 1.8.0.1
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/2] Thermal:Fix memory leak if occur goto unregister

[R, Durgadoss]

-Original Message-
From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
Sent: Monday, October 20, 2014 6:04 PM
To: Yao Dongdong
Cc: Zhang, Rui; linux...@vger.kernel.org; LKML
Subject: Re: [PATCH 1/2] Thermal:Fix memory leak if occur goto unregister

Hello,

On Mon, Oct 20, 2014 at 04:27:36PM +0800, Yao Dongdong wrote:
 Signed-off-by:yaodongd...@huawei.com

Acked-by: Eduardo Valentin edubez...@gmail.com

Rui, would you take care of this?


If I remember it right, this 'tz' is freed in the thermal_release()
function, during device_unregister().

It is similar in all other functions in thermal_core.c

So, Yao, Did you really test this patch ?
And did not see any crashes ?

Thanks,
Durga


 ---
  drivers/thermal/thermal_core.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
 index 71b0ec0..5b7d466 100644
 --- a/drivers/thermal/thermal_core.c
 +++ b/drivers/thermal/thermal_core.c
 @@ -1574,6 +1574,7 @@ struct thermal_zone_device
*thermal_zone_device_register(const char *type,
  unregister:
 release_idr(thermal_tz_idr, thermal_idr_lock, tz-id);
 device_unregister(tz-device);
 +   kfree(tz);
 return ERR_PTR(result);
  }
  EXPORT_SYMBOL_GPL(thermal_zone_device_register);
 --
 1.8.0.1


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 1/4] powercap/rapl: further relax energy counter checks

[R, Durgadoss]

> -Original Message-
> From: David E. Box [mailto:david.e@linux.intel.com]
> Sent: Wednesday, April 30, 2014 4:03 AM
> To: david.e@linux.intel.com; jacob.jun@linux.intel.com; linux-
> p...@vger.kernel.org; Wysocki, Rafael J; linux-kernel@vger.kernel.org;
> h...@linux.intel.com
> Cc: a...@linux.intel.com; R, Durgadoss; Accardi, Kristen C
> Subject: [PATCH v2 1/4] powercap/rapl: further relax energy counter checks
> 
> From: Jacob Pan 
> 
> Energy counters may roll slowly for some RAPL domains, checking all
> of them can be time consuming and takes unpredictable amount of time.
> Therefore, we relax the sanity check by only checking availability of the
> MSRs and non-zero value of the energy status counters. It has been shown
> sufficient for all the platforms tested to filter out inactive domains.
> 

Acked-by: Durgadoss R 

Thanks,
Durga

> Signed-off-by: Jacob Pan 
> ---
>  drivers/powercap/intel_rapl.c |   29 +
>  1 file changed, 9 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index d9a0770..1c987d2 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -1124,8 +1124,7 @@ err_cleanup_package:
>  static int rapl_check_domain(int cpu, int domain)
>  {
>   unsigned msr;
> - u64 val1, val2 = 0;
> - int retry = 0;
> + u64 val = 0;
> 
>   switch (domain) {
>   case RAPL_DOMAIN_PACKAGE:
> @@ -1144,26 +1143,13 @@ static int rapl_check_domain(int cpu, int domain)
>   pr_err("invalid domain id %d\n", domain);
>   return -EINVAL;
>   }
> - if (rdmsrl_safe_on_cpu(cpu, msr, ))
> - return -ENODEV;
> -
> - /* PP1/uncore/graphics domain may not be active at the time of
> -  * driver loading. So skip further checks.
> + /* make sure domain counters are available and contains non-zero
> +  * values, otherwise skip it.
>*/
> - if (domain == RAPL_DOMAIN_PP1)
> - return 0;
> - /* energy counters roll slowly on some domains */
> - while (++retry < 10) {
> - usleep_range(1, 15000);
> - rdmsrl_safe_on_cpu(cpu, msr, );
> - if ((val1 & ENERGY_STATUS_MASK) != (val2 &
> ENERGY_STATUS_MASK))
> - return 0;
> - }
> - /* if energy counter does not change, report as bad domain */
> - pr_info("domain %s energy ctr %llu:%llu not working, skip\n",
> - rapl_domain_names[domain], val1, val2);
> + if (rdmsrl_safe_on_cpu(cpu, msr, ) || !val)
> + return -ENODEV;
> 
> - return -ENODEV;
> + return 0;
>  }
> 
>  /* Detect active and valid domains for the given CPU, caller must
> @@ -1180,6 +1166,9 @@ static int rapl_detect_domains(struct rapl_package *rp,
> int cpu)
>   /* use physical package id to read counters */
>   if (!rapl_check_domain(cpu, i))
>   rp->domain_map |= 1 << i;
> + else
> + pr_warn("RAPL domain %s detection failed\n",
> + rapl_domain_names[i]);
>   }
>   rp->nr_domains = bitmap_weight(>domain_map,
>   RAPL_DOMAIN_MAX);
>   if (!rp->nr_domains) {
> --
> 1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 5/5] powercap/rapl: change floor frequency for vallewview

[R, Durgadoss]

> -Original Message-
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Tuesday, April 29, 2014 6:33 PM
> To: R, Durgadoss
> Cc: Linux PM; Wysocki, Rafael J; LKML; David E. Box; Alan Cox; Accardi, 
> Kristen C
> Subject: Re: [PATCH 5/5] powercap/rapl: change floor frequency for vallewview
> 
> On Tue, 29 Apr 2014 02:45:22 +
> "R, Durgadoss"  wrote:
> 
> > Hi Jacob,
> >
> > > -Original Message-
> > > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > > Sent: Monday, April 28, 2014 7:35 PM
> > > To: Linux PM; Wysocki, Rafael J; LKML
> > > Cc: David E. Box; Alan Cox; R, Durgadoss; Accardi, Kristen C; Jacob
> > > Pan Subject: [PATCH 5/5] powercap/rapl: change floor frequency for
> > > vallewview
> > >
> > > RAPL power limit reduce power by limiting CPU P-state and
> > > other techniques. On Valleyview, RAPL power limit cannot
> > > go to LFM (low frequency mode) if we don't set the floor
> > > frequency via IOSF mailbox.
> > >
> > > This patch enables setting of floor frquency such that
> > > RAPL power limit is more effective.
> > >
> > > Signed-off-by: Jacob Pan 
> > > ---
> > >  drivers/powercap/intel_rapl.c | 27 +++
> > >  1 file changed, 19 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/powercap/intel_rapl.c
> > > b/drivers/powercap/intel_rapl.c index b1cda6f..13e4776 100644
> > > --- a/drivers/powercap/intel_rapl.c
> > > +++ b/drivers/powercap/intel_rapl.c
> > > @@ -32,6 +32,7 @@
> > >
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  /* bitmasks for RAPL MSRs, used by primitive access functions */
> > >  #define ENERGY_STATUS_MASK  0x
> > > @@ -336,11 +337,17 @@ static int find_nr_power_limit(struct
> > > rapl_domain *rd) return i;
> > >  }
> > >
> > > +#define VLV_CPU_POWER_BUDGET_CTL (0x2)
> > > +static const struct x86_cpu_id valleyview_id[] = {
> > > + { X86_VENDOR_INTEL, 6, 0x37},
> > > + {}
> > > +};
> >
> > There are other platforms that have this FloorFreq register as well.
> > And those addresses are not '0x02'. So, we need to have a cpu_id based
> > table to define the address of the floor freq register as well.
> > [This is not specific to valleyview.]
> >
> Sounds like I need to add an abstraction to capture this. So far, there
> are only two exceptions so i was hesitate to do so. Thanks for the
> input.

Yes, We at least have few platforms that need this.

> > Also, is there a plan to expose this floor freq ratio through Sysfs
> > for runtime configuration. ? May be through a standard thermal
> > cooling device interface ?
> >
> why would that be necessary? who will use it? floor freq only affects
> RAPL, AFAIK. In Linux there is no guaranteed freq anyway. My original
> patch to enable RAPL as cooling device was abandoned in favor of
> powercap framework, I am not sure if we should go back.

There are user space thermal controls which change RAPL Power limits
according to platform's thermal condition as you might be aware.

The floor frequency is not used only to transition to LFM ratio. We can
transition to any frequency ratio by adjusting this floor frequency
(at least on VLV and couple more platforms)

Hence while changing RAPL Power Limits, there is a need to adjust
this also, to specify which ratio is our Floor (basically we will not
go below that). That's why we need an interface for modifying this
at run time (along with Power Limits).

Thanks,
Durga

> > > +
> > >  static int set_domain_enable(struct powercap_zone *power_zone,
> > > bool mode) {
> > >   struct rapl_domain *rd =
> > > power_zone_to_rapl_domain(power_zone); int nr_powerlimit;
> > > -
> > > + u32 mdata = 0;
> > >   if (rd->state & DOMAIN_STATE_BIOS_LOCKED)
> > >   return -EACCES;
> > >   get_online_cpus();
> > > @@ -350,7 +357,16 @@ static int set_domain_enable(struct
> > > powercap_zone *power_zone, bool mode)
> > >   /* always enable clamp such that p-state can go below OS
> > > requested
> > >* range. power capping priority over guranteed frequency.
> > >*/
> > > - rapl_write_data_raw(rd, PL1_CLAMP, mode);
> > > + if (x86_match_cpu(valleyview_id)) {
> > > + iosf_mbi_read(BT_MBI_UNIT_PMC, BT_MBI_PMC_READ,
> > > + VLV_CPU_POWER_BUDGET_CTL, );
> > > +   

RE: [PATCH 5/5] powercap/rapl: change floor frequency for vallewview

[R, Durgadoss]

 -Original Message-
 From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
 Sent: Tuesday, April 29, 2014 6:33 PM
 To: R, Durgadoss
 Cc: Linux PM; Wysocki, Rafael J; LKML; David E. Box; Alan Cox; Accardi, 
 Kristen C
 Subject: Re: [PATCH 5/5] powercap/rapl: change floor frequency for vallewview
 
 On Tue, 29 Apr 2014 02:45:22 +
 R, Durgadoss durgados...@intel.com wrote:
 
  Hi Jacob,
 
   -Original Message-
   From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
   Sent: Monday, April 28, 2014 7:35 PM
   To: Linux PM; Wysocki, Rafael J; LKML
   Cc: David E. Box; Alan Cox; R, Durgadoss; Accardi, Kristen C; Jacob
   Pan Subject: [PATCH 5/5] powercap/rapl: change floor frequency for
   vallewview
  
   RAPL power limit reduce power by limiting CPU P-state and
   other techniques. On Valleyview, RAPL power limit cannot
   go to LFM (low frequency mode) if we don't set the floor
   frequency via IOSF mailbox.
  
   This patch enables setting of floor frquency such that
   RAPL power limit is more effective.
  
   Signed-off-by: Jacob Pan jacob.jun@linux.intel.com
   ---
drivers/powercap/intel_rapl.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
  
   diff --git a/drivers/powercap/intel_rapl.c
   b/drivers/powercap/intel_rapl.c index b1cda6f..13e4776 100644
   --- a/drivers/powercap/intel_rapl.c
   +++ b/drivers/powercap/intel_rapl.c
   @@ -32,6 +32,7 @@
  
#include asm/processor.h
#include asm/cpu_device_id.h
   +#include asm/iosf_mbi.h
  
/* bitmasks for RAPL MSRs, used by primitive access functions */
#define ENERGY_STATUS_MASK  0x
   @@ -336,11 +337,17 @@ static int find_nr_power_limit(struct
   rapl_domain *rd) return i;
}
  
   +#define VLV_CPU_POWER_BUDGET_CTL (0x2)
   +static const struct x86_cpu_id valleyview_id[] = {
   + { X86_VENDOR_INTEL, 6, 0x37},
   + {}
   +};
 
  There are other platforms that have this FloorFreq register as well.
  And those addresses are not '0x02'. So, we need to have a cpu_id based
  table to define the address of the floor freq register as well.
  [This is not specific to valleyview.]
 
 Sounds like I need to add an abstraction to capture this. So far, there
 are only two exceptions so i was hesitate to do so. Thanks for the
 input.

Yes, We at least have few platforms that need this.

  Also, is there a plan to expose this floor freq ratio through Sysfs
  for runtime configuration. ? May be through a standard thermal
  cooling device interface ?
 
 why would that be necessary? who will use it? floor freq only affects
 RAPL, AFAIK. In Linux there is no guaranteed freq anyway. My original
 patch to enable RAPL as cooling device was abandoned in favor of
 powercap framework, I am not sure if we should go back.

There are user space thermal controls which change RAPL Power limits
according to platform's thermal condition as you might be aware.

The floor frequency is not used only to transition to LFM ratio. We can
transition to any frequency ratio by adjusting this floor frequency
(at least on VLV and couple more platforms)

Hence while changing RAPL Power Limits, there is a need to adjust
this also, to specify which ratio is our Floor (basically we will not
go below that). That's why we need an interface for modifying this
at run time (along with Power Limits).

Thanks,
Durga

   +
static int set_domain_enable(struct powercap_zone *power_zone,
   bool mode) {
 struct rapl_domain *rd =
   power_zone_to_rapl_domain(power_zone); int nr_powerlimit;
   -
   + u32 mdata = 0;
 if (rd-state  DOMAIN_STATE_BIOS_LOCKED)
 return -EACCES;
 get_online_cpus();
   @@ -350,7 +357,16 @@ static int set_domain_enable(struct
   powercap_zone *power_zone, bool mode)
 /* always enable clamp such that p-state can go below OS
   requested
  * range. power capping priority over guranteed frequency.
  */
   - rapl_write_data_raw(rd, PL1_CLAMP, mode);
   + if (x86_match_cpu(valleyview_id)) {
   + iosf_mbi_read(BT_MBI_UNIT_PMC, BT_MBI_PMC_READ,
   + VLV_CPU_POWER_BUDGET_CTL, mdata);
   + mdata = ~(0x7f  8);
   + mdata |= 1  8;
   + iosf_mbi_write(BT_MBI_UNIT_PMC, BT_MBI_PMC_WRITE,
   + VLV_CPU_POWER_BUDGET_CTL, mdata);
   + } else
   + rapl_write_data_raw(rd, PL1_CLAMP, mode);
   +
 /* some domains have pl2 */
 if (nr_powerlimit  1) {
 rapl_write_data_raw(rd, PL2_ENABLE, mode);
   @@ -833,11 +849,6 @@ static int rapl_write_data_raw(struct
   rapl_domain *rd, return 0;
}
  
   -static const struct x86_cpu_id energy_unit_quirk_ids[] = {
   - { X86_VENDOR_INTEL, 6, 0x37},/* Valleyview */
   - {}
   -};
 
  Same thing here. There are other Atom platforms that need this
  conversion quirk. So, please keep the table as is.
 
  Thanks,
  Durga
 
   -
static int rapl_check_unit(struct rapl_package *rp, int cpu)
{
 u64 msr_val;
   @@ -859,7 +870,7 @@ static int

RE: [PATCH v2 1/4] powercap/rapl: further relax energy counter checks

[R, Durgadoss]

 -Original Message-
 From: David E. Box [mailto:david.e@linux.intel.com]
 Sent: Wednesday, April 30, 2014 4:03 AM
 To: david.e@linux.intel.com; jacob.jun@linux.intel.com; linux-
 p...@vger.kernel.org; Wysocki, Rafael J; linux-kernel@vger.kernel.org;
 h...@linux.intel.com
 Cc: a...@linux.intel.com; R, Durgadoss; Accardi, Kristen C
 Subject: [PATCH v2 1/4] powercap/rapl: further relax energy counter checks
 
 From: Jacob Pan jacob.jun@linux.intel.com
 
 Energy counters may roll slowly for some RAPL domains, checking all
 of them can be time consuming and takes unpredictable amount of time.
 Therefore, we relax the sanity check by only checking availability of the
 MSRs and non-zero value of the energy status counters. It has been shown
 sufficient for all the platforms tested to filter out inactive domains.
 

Acked-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

 Signed-off-by: Jacob Pan jacob.jun@linux.intel.com
 ---
  drivers/powercap/intel_rapl.c |   29 +
  1 file changed, 9 insertions(+), 20 deletions(-)
 
 diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
 index d9a0770..1c987d2 100644
 --- a/drivers/powercap/intel_rapl.c
 +++ b/drivers/powercap/intel_rapl.c
 @@ -1124,8 +1124,7 @@ err_cleanup_package:
  static int rapl_check_domain(int cpu, int domain)
  {
   unsigned msr;
 - u64 val1, val2 = 0;
 - int retry = 0;
 + u64 val = 0;
 
   switch (domain) {
   case RAPL_DOMAIN_PACKAGE:
 @@ -1144,26 +1143,13 @@ static int rapl_check_domain(int cpu, int domain)
   pr_err(invalid domain id %d\n, domain);
   return -EINVAL;
   }
 - if (rdmsrl_safe_on_cpu(cpu, msr, val1))
 - return -ENODEV;
 -
 - /* PP1/uncore/graphics domain may not be active at the time of
 -  * driver loading. So skip further checks.
 + /* make sure domain counters are available and contains non-zero
 +  * values, otherwise skip it.
*/
 - if (domain == RAPL_DOMAIN_PP1)
 - return 0;
 - /* energy counters roll slowly on some domains */
 - while (++retry  10) {
 - usleep_range(1, 15000);
 - rdmsrl_safe_on_cpu(cpu, msr, val2);
 - if ((val1  ENERGY_STATUS_MASK) != (val2 
 ENERGY_STATUS_MASK))
 - return 0;
 - }
 - /* if energy counter does not change, report as bad domain */
 - pr_info(domain %s energy ctr %llu:%llu not working, skip\n,
 - rapl_domain_names[domain], val1, val2);
 + if (rdmsrl_safe_on_cpu(cpu, msr, val) || !val)
 + return -ENODEV;
 
 - return -ENODEV;
 + return 0;
  }
 
  /* Detect active and valid domains for the given CPU, caller must
 @@ -1180,6 +1166,9 @@ static int rapl_detect_domains(struct rapl_package *rp,
 int cpu)
   /* use physical package id to read counters */
   if (!rapl_check_domain(cpu, i))
   rp-domain_map |= 1  i;
 + else
 + pr_warn(RAPL domain %s detection failed\n,
 + rapl_domain_names[i]);
   }
   rp-nr_domains = bitmap_weight(rp-domain_map,
   RAPL_DOMAIN_MAX);
   if (!rp-nr_domains) {
 --
 1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 5/5] powercap/rapl: change floor frequency for vallewview

[R, Durgadoss]

Hi Jacob,

> -Original Message-
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Monday, April 28, 2014 7:35 PM
> To: Linux PM; Wysocki, Rafael J; LKML
> Cc: David E. Box; Alan Cox; R, Durgadoss; Accardi, Kristen C; Jacob Pan
> Subject: [PATCH 5/5] powercap/rapl: change floor frequency for vallewview
> 
> RAPL power limit reduce power by limiting CPU P-state and
> other techniques. On Valleyview, RAPL power limit cannot
> go to LFM (low frequency mode) if we don't set the floor
> frequency via IOSF mailbox.
> 
> This patch enables setting of floor frquency such that
> RAPL power limit is more effective.
> 
> Signed-off-by: Jacob Pan 
> ---
>  drivers/powercap/intel_rapl.c | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index b1cda6f..13e4776 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -32,6 +32,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  /* bitmasks for RAPL MSRs, used by primitive access functions */
>  #define ENERGY_STATUS_MASK  0x
> @@ -336,11 +337,17 @@ static int find_nr_power_limit(struct rapl_domain *rd)
>   return i;
>  }
> 
> +#define VLV_CPU_POWER_BUDGET_CTL (0x2)
> +static const struct x86_cpu_id valleyview_id[] = {
> + { X86_VENDOR_INTEL, 6, 0x37},
> + {}
> +};

There are other platforms that have this FloorFreq register as well.
And those addresses are not '0x02'. So, we need to have a cpu_id based
table to define the address of the floor freq register as well.
[This is not specific to valleyview.]

Also, is there a plan to expose this floor freq ratio through Sysfs for
runtime configuration. ? May be through a standard thermal cooling device
interface ?

> +
>  static int set_domain_enable(struct powercap_zone *power_zone, bool mode)
>  {
>   struct rapl_domain *rd = power_zone_to_rapl_domain(power_zone);
>   int nr_powerlimit;
> -
> + u32 mdata = 0;
>   if (rd->state & DOMAIN_STATE_BIOS_LOCKED)
>   return -EACCES;
>   get_online_cpus();
> @@ -350,7 +357,16 @@ static int set_domain_enable(struct powercap_zone
> *power_zone, bool mode)
>   /* always enable clamp such that p-state can go below OS requested
>* range. power capping priority over guranteed frequency.
>*/
> - rapl_write_data_raw(rd, PL1_CLAMP, mode);
> + if (x86_match_cpu(valleyview_id)) {
> + iosf_mbi_read(BT_MBI_UNIT_PMC, BT_MBI_PMC_READ,
> + VLV_CPU_POWER_BUDGET_CTL, );
> + mdata &= ~(0x7f << 8);
> + mdata |= 1 << 8;
> + iosf_mbi_write(BT_MBI_UNIT_PMC, BT_MBI_PMC_WRITE,
> + VLV_CPU_POWER_BUDGET_CTL, mdata);
> + } else
> + rapl_write_data_raw(rd, PL1_CLAMP, mode);
> +
>   /* some domains have pl2 */
>   if (nr_powerlimit > 1) {
>   rapl_write_data_raw(rd, PL2_ENABLE, mode);
> @@ -833,11 +849,6 @@ static int rapl_write_data_raw(struct rapl_domain *rd,
>   return 0;
>  }
> 
> -static const struct x86_cpu_id energy_unit_quirk_ids[] = {
> - { X86_VENDOR_INTEL, 6, 0x37},/* Valleyview */
> - {}
> -};

Same thing here. There are other Atom platforms that need this
conversion quirk. So, please keep the table as is.

Thanks,
Durga

> -
>  static int rapl_check_unit(struct rapl_package *rp, int cpu)
>  {
>   u64 msr_val;
> @@ -859,7 +870,7 @@ static int rapl_check_unit(struct rapl_package *rp, int 
> cpu)
>*/
>   value = (msr_val & ENERGY_UNIT_MASK) >> ENERGY_UNIT_OFFSET;
>   /* some CPUs have different way to calculate energy unit */
> - if (x86_match_cpu(energy_unit_quirk_ids))
> + if (x86_match_cpu(valleyview_id))
>   rp->energy_unit_divisor = 100 / (1 << value);
>   else
>   rp->energy_unit_divisor = 1 << value;
> --
> 1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 5/5] powercap/rapl: change floor frequency for vallewview

[R, Durgadoss]

Hi Jacob,

 -Original Message-
 From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
 Sent: Monday, April 28, 2014 7:35 PM
 To: Linux PM; Wysocki, Rafael J; LKML
 Cc: David E. Box; Alan Cox; R, Durgadoss; Accardi, Kristen C; Jacob Pan
 Subject: [PATCH 5/5] powercap/rapl: change floor frequency for vallewview
 
 RAPL power limit reduce power by limiting CPU P-state and
 other techniques. On Valleyview, RAPL power limit cannot
 go to LFM (low frequency mode) if we don't set the floor
 frequency via IOSF mailbox.
 
 This patch enables setting of floor frquency such that
 RAPL power limit is more effective.
 
 Signed-off-by: Jacob Pan jacob.jun@linux.intel.com
 ---
  drivers/powercap/intel_rapl.c | 27 +++
  1 file changed, 19 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
 index b1cda6f..13e4776 100644
 --- a/drivers/powercap/intel_rapl.c
 +++ b/drivers/powercap/intel_rapl.c
 @@ -32,6 +32,7 @@
 
  #include asm/processor.h
  #include asm/cpu_device_id.h
 +#include asm/iosf_mbi.h
 
  /* bitmasks for RAPL MSRs, used by primitive access functions */
  #define ENERGY_STATUS_MASK  0x
 @@ -336,11 +337,17 @@ static int find_nr_power_limit(struct rapl_domain *rd)
   return i;
  }
 
 +#define VLV_CPU_POWER_BUDGET_CTL (0x2)
 +static const struct x86_cpu_id valleyview_id[] = {
 + { X86_VENDOR_INTEL, 6, 0x37},
 + {}
 +};

There are other platforms that have this FloorFreq register as well.
And those addresses are not '0x02'. So, we need to have a cpu_id based
table to define the address of the floor freq register as well.
[This is not specific to valleyview.]

Also, is there a plan to expose this floor freq ratio through Sysfs for
runtime configuration. ? May be through a standard thermal cooling device
interface ?

 +
  static int set_domain_enable(struct powercap_zone *power_zone, bool mode)
  {
   struct rapl_domain *rd = power_zone_to_rapl_domain(power_zone);
   int nr_powerlimit;
 -
 + u32 mdata = 0;
   if (rd-state  DOMAIN_STATE_BIOS_LOCKED)
   return -EACCES;
   get_online_cpus();
 @@ -350,7 +357,16 @@ static int set_domain_enable(struct powercap_zone
 *power_zone, bool mode)
   /* always enable clamp such that p-state can go below OS requested
* range. power capping priority over guranteed frequency.
*/
 - rapl_write_data_raw(rd, PL1_CLAMP, mode);
 + if (x86_match_cpu(valleyview_id)) {
 + iosf_mbi_read(BT_MBI_UNIT_PMC, BT_MBI_PMC_READ,
 + VLV_CPU_POWER_BUDGET_CTL, mdata);
 + mdata = ~(0x7f  8);
 + mdata |= 1  8;
 + iosf_mbi_write(BT_MBI_UNIT_PMC, BT_MBI_PMC_WRITE,
 + VLV_CPU_POWER_BUDGET_CTL, mdata);
 + } else
 + rapl_write_data_raw(rd, PL1_CLAMP, mode);
 +
   /* some domains have pl2 */
   if (nr_powerlimit  1) {
   rapl_write_data_raw(rd, PL2_ENABLE, mode);
 @@ -833,11 +849,6 @@ static int rapl_write_data_raw(struct rapl_domain *rd,
   return 0;
  }
 
 -static const struct x86_cpu_id energy_unit_quirk_ids[] = {
 - { X86_VENDOR_INTEL, 6, 0x37},/* Valleyview */
 - {}
 -};

Same thing here. There are other Atom platforms that need this
conversion quirk. So, please keep the table as is.

Thanks,
Durga

 -
  static int rapl_check_unit(struct rapl_package *rp, int cpu)
  {
   u64 msr_val;
 @@ -859,7 +870,7 @@ static int rapl_check_unit(struct rapl_package *rp, int 
 cpu)
*/
   value = (msr_val  ENERGY_UNIT_MASK)  ENERGY_UNIT_OFFSET;
   /* some CPUs have different way to calculate energy unit */
 - if (x86_match_cpu(energy_unit_quirk_ids))
 + if (x86_match_cpu(valleyview_id))
   rp-energy_unit_divisor = 100 / (1  value);
   else
   rp-energy_unit_divisor = 1  value;
 --
 1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Srinivas Pandruvada
> Sent: Thursday, October 31, 2013 7:03 AM
> To: R, Durgadoss; Zhang, Rui
> Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
> Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor
> 
> You might want to use new DEVICE_ATTR_RO and DEVICE_ATTR_RW in this
> series. GKH wanted this changes in my powercap patchset.

I am working on my next version. Will take care of this in appropriate places.
Thank you for pointing this out.

Thanks,
Durga

> 
> Thanks,
> Srinivas
> 
> On 10/15/2013 06:12 AM, R, Durgadoss wrote:
> >> -Original Message-
> >> From: Zhang, Rui
> >> Sent: Tuesday, October 15, 2013 4:33 PM
> >> To: R, Durgadoss
> >> Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
> >> ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
> >> Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor
> >>
> >> On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
> >>> This patch adds a trip point related sysfs nodes
> >>> for each sensor under a zone in /sys/class/thermal/zoneX/.
> >>> The nodes will be named, sensorX_trip_activeY,
> >>> sensorX_trip_passiveY, sensorX_trip_hot, sensorX_trip_critical
> >>> for active, passive, hot and critical trip points
> >>> respectively for sensorX.
> >>>
> >>> Signed-off-by: Durgadoss R 
> >>> ---
> >>>   drivers/thermal/thermal_core.c |  344
> >> +++-
> >>>   include/linux/thermal.h|   40 -
> >>>   2 files changed, 379 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> >>> index 3c4ef62..d6e29f6 100644
> >>> --- a/drivers/thermal/thermal_core.c
> >>> +++ b/drivers/thermal/thermal_core.c
> >>> @@ -494,6 +494,60 @@ static void thermal_zone_device_check(struct
> >> work_struct *work)
> >>>   thermal_zone_device_update(tz);
> >>>   }
> >>>
> >>> +static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char
> >> *name)
> >>> +{
> >>> + int i, indx = -EINVAL;
> >>> +
> >>> + /* Protect against tz->sensors[i] being unregistered */
> >>> + mutex_lock(_list_lock);
> >>> +
> >>> + for (i = 0; i < tz->sensor_indx; i++) {
> >>> + if (!strnicmp(name, kobject_name(>sensors[i]-
> >>> device.kobj),
> >>> + THERMAL_NAME_LENGTH)) {
> >>> + indx = i;
> >>> + break;
> >>> + }
> >>> + }
> >>> +
> >>> + mutex_unlock(_list_lock);
> >>> + return indx;
> >>> +}
> >>> +
> >>> +static void __remove_trip_attr(struct thermal_zone *tz, int indx)
> >>> +{
> >>> + int i;
> >>> + struct thermal_trip_attr *attr = tz->trip_attr[indx];
> >>> + struct thermal_trip_point *trip = tz->sensor_trip[indx];
> >>> +
> >>> + if (!attr || !trip)
> >>> + return;
> >>> +
> >>> + if (trip->crit != THERMAL_TRIPS_NONE)
> >>> + device_remove_file(>device, >crit_attr.attr);
> >>> +
> >>> + if (trip->hot != THERMAL_TRIPS_NONE)
> >>> + device_remove_file(>device, >hot_attr.attr);
> >>> +
> >>> + if (trip->num_passive_trips > 0) {
> >>> + for (i = 0; i < trip->num_passive_trips; i++) {
> >>> + device_remove_file(>device,
> >>> + >passive_attrs[i].attr);
> >>> + }
> >>> + kfree(attr->passive_attrs);
> >>> + }
> >>> +
> >>> + if (trip->num_active_trips > 0) {
> >>> + for (i = 0; i < trip->num_active_trips; i++) {
> >>> + device_remove_file(>device,
> >>> + >active_attrs[i].attr);
> >>> + }
> >>> + kfree(attr->active_attrs);
> >>> + }
> >>> +
> >>>

RE: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Srinivas Pandruvada
 Sent: Thursday, October 31, 2013 7:03 AM
 To: R, Durgadoss; Zhang, Rui
 Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
 ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
 Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor
 
 You might want to use new DEVICE_ATTR_RO and DEVICE_ATTR_RW in this
 series. GKH wanted this changes in my powercap patchset.

I am working on my next version. Will take care of this in appropriate places.
Thank you for pointing this out.

Thanks,
Durga

 
 Thanks,
 Srinivas
 
 On 10/15/2013 06:12 AM, R, Durgadoss wrote:
  -Original Message-
  From: Zhang, Rui
  Sent: Tuesday, October 15, 2013 4:33 PM
  To: R, Durgadoss
  Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
  ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
  Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor
 
  On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
  This patch adds a trip point related sysfs nodes
  for each sensor under a zone in /sys/class/thermal/zoneX/.
  The nodes will be named, sensorX_trip_activeY,
  sensorX_trip_passiveY, sensorX_trip_hot, sensorX_trip_critical
  for active, passive, hot and critical trip points
  respectively for sensorX.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
drivers/thermal/thermal_core.c |  344
  +++-
include/linux/thermal.h|   40 -
2 files changed, 379 insertions(+), 5 deletions(-)
 
  diff --git a/drivers/thermal/thermal_core.c
 b/drivers/thermal/thermal_core.c
  index 3c4ef62..d6e29f6 100644
  --- a/drivers/thermal/thermal_core.c
  +++ b/drivers/thermal/thermal_core.c
  @@ -494,6 +494,60 @@ static void thermal_zone_device_check(struct
  work_struct *work)
thermal_zone_device_update(tz);
}
 
  +static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char
  *name)
  +{
  + int i, indx = -EINVAL;
  +
  + /* Protect against tz-sensors[i] being unregistered */
  + mutex_lock(sensor_list_lock);
  +
  + for (i = 0; i  tz-sensor_indx; i++) {
  + if (!strnicmp(name, kobject_name(tz-sensors[i]-
  device.kobj),
  + THERMAL_NAME_LENGTH)) {
  + indx = i;
  + break;
  + }
  + }
  +
  + mutex_unlock(sensor_list_lock);
  + return indx;
  +}
  +
  +static void __remove_trip_attr(struct thermal_zone *tz, int indx)
  +{
  + int i;
  + struct thermal_trip_attr *attr = tz-trip_attr[indx];
  + struct thermal_trip_point *trip = tz-sensor_trip[indx];
  +
  + if (!attr || !trip)
  + return;
  +
  + if (trip-crit != THERMAL_TRIPS_NONE)
  + device_remove_file(tz-device, attr-crit_attr.attr);
  +
  + if (trip-hot != THERMAL_TRIPS_NONE)
  + device_remove_file(tz-device, attr-hot_attr.attr);
  +
  + if (trip-num_passive_trips  0) {
  + for (i = 0; i  trip-num_passive_trips; i++) {
  + device_remove_file(tz-device,
  + attr-passive_attrs[i].attr);
  + }
  + kfree(attr-passive_attrs);
  + }
  +
  + if (trip-num_active_trips  0) {
  + for (i = 0; i  trip-num_active_trips; i++) {
  + device_remove_file(tz-device,
  + attr-active_attrs[i].attr);
  + }
  + kfree(attr-active_attrs);
  + }
  +
  + kfree(tz-trip_attr[indx]);
  + tz-trip_attr[indx] = NULL;
  +}
  +
static void remove_sensor_from_zone(struct thermal_zone *tz,
struct thermal_sensor *ts)
{
  @@ -503,13 +557,19 @@ static void remove_sensor_from_zone(struct
  thermal_zone *tz,
if (indx  0)
return;
 
  - sysfs_remove_link(tz-device.kobj, kobject_name(ts-device.kobj));
  -
mutex_lock(tz-lock);
 
  + /* Remove trip point attributes associated with this sensor */
  + __remove_trip_attr(tz, indx);
  +
  + sysfs_remove_link(tz-device.kobj, kobject_name(ts-device.kobj));
  +
/* Shift the entries in the tz-sensors array */
  - for (j = indx; j  MAX_SENSORS_PER_ZONE - 1; j++)
  + for (j = indx; j  MAX_SENSORS_PER_ZONE - 1; j++) {
tz-sensors[j] = tz-sensors[j + 1];
  + tz-sensor_trip[j] = tz-sensor_trip[j + 1];
  + tz-trip_attr[j] = tz-trip_attr[j + 1];
  + }
 
tz-sensor_indx--;
mutex_unlock(tz-lock);
  @@ -952,6 +1012,111 @@ emul_temp_store(struct device *dev, struct
  device_attribute *attr,
static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
#endif/*CONFIG_THERMAL_EMULATION*/
 
  +static ssize_t
  +active_trip_show(struct device *dev, struct device_attribute *attr, char
 *buf)
  +{
  + int i, j, val;
  + char kobj_name[THERMAL_NAME_LENGTH];
  + struct

RE: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor

[R, Durgadoss]

> -Original Message-
> From: Zhang, Rui
> Sent: Tuesday, October 15, 2013 4:33 PM
> To: R, Durgadoss
> Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
> Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor
> 
> On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
> > This patch adds a trip point related sysfs nodes
> > for each sensor under a zone in /sys/class/thermal/zoneX/.
> > The nodes will be named, sensorX_trip_activeY,
> > sensorX_trip_passiveY, sensorX_trip_hot, sensorX_trip_critical
> > for active, passive, hot and critical trip points
> > respectively for sensorX.
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >  drivers/thermal/thermal_core.c |  344
> +++-
> >  include/linux/thermal.h|   40 -
> >  2 files changed, 379 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> > index 3c4ef62..d6e29f6 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -494,6 +494,60 @@ static void thermal_zone_device_check(struct
> work_struct *work)
> > thermal_zone_device_update(tz);
> >  }
> >
> > +static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char
> *name)
> > +{
> > +   int i, indx = -EINVAL;
> > +
> > +   /* Protect against tz->sensors[i] being unregistered */
> > +   mutex_lock(_list_lock);
> > +
> > +   for (i = 0; i < tz->sensor_indx; i++) {
> > +   if (!strnicmp(name, kobject_name(>sensors[i]-
> >device.kobj),
> > +   THERMAL_NAME_LENGTH)) {
> > +   indx = i;
> > +   break;
> > +   }
> > +   }
> > +
> > +   mutex_unlock(_list_lock);
> > +   return indx;
> > +}
> > +
> > +static void __remove_trip_attr(struct thermal_zone *tz, int indx)
> > +{
> > +   int i;
> > +   struct thermal_trip_attr *attr = tz->trip_attr[indx];
> > +   struct thermal_trip_point *trip = tz->sensor_trip[indx];
> > +
> > +   if (!attr || !trip)
> > +   return;
> > +
> > +   if (trip->crit != THERMAL_TRIPS_NONE)
> > +   device_remove_file(>device, >crit_attr.attr);
> > +
> > +   if (trip->hot != THERMAL_TRIPS_NONE)
> > +   device_remove_file(>device, >hot_attr.attr);
> > +
> > +   if (trip->num_passive_trips > 0) {
> > +   for (i = 0; i < trip->num_passive_trips; i++) {
> > +   device_remove_file(>device,
> > +   >passive_attrs[i].attr);
> > +   }
> > +   kfree(attr->passive_attrs);
> > +   }
> > +
> > +   if (trip->num_active_trips > 0) {
> > +   for (i = 0; i < trip->num_active_trips; i++) {
> > +   device_remove_file(>device,
> > +   >active_attrs[i].attr);
> > +   }
> > +   kfree(attr->active_attrs);
> > +   }
> > +
> > +   kfree(tz->trip_attr[indx]);
> > +   tz->trip_attr[indx] = NULL;
> > +}
> > +
> >  static void remove_sensor_from_zone(struct thermal_zone *tz,
> > struct thermal_sensor *ts)
> >  {
> > @@ -503,13 +557,19 @@ static void remove_sensor_from_zone(struct
> thermal_zone *tz,
> > if (indx < 0)
> > return;
> >
> > -   sysfs_remove_link(>device.kobj, kobject_name(>device.kobj));
> > -
> > mutex_lock(>lock);
> >
> > +   /* Remove trip point attributes associated with this sensor */
> > +   __remove_trip_attr(tz, indx);
> > +
> > +   sysfs_remove_link(>device.kobj, kobject_name(>device.kobj));
> > +
> > /* Shift the entries in the tz->sensors array */
> > -   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
> > +   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++) {
> > tz->sensors[j] = tz->sensors[j + 1];
> > +   tz->sensor_trip[j] = tz->sensor_trip[j + 1];
> > +   tz->trip_attr[j] = tz->trip_attr[j + 1];
> > +   }
> >
> > tz->sensor_indx--;
> > mutex_unlock(>lock);
> > @@ -952,6 +1012,111 @@ emul_temp_store(struct device *dev, struct
> device_attribute *attr,
> >  static DEVICE_ATTR(emul_temp, S

RE: [PATCHv4 3/9] Thermal: Create zone level APIs

[R, Durgadoss]

Hi rui,

> -Original Message-
> From: Zhang, Rui
> Sent: Tuesday, October 15, 2013 3:53 PM
> To: R, Durgadoss
> Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
> Subject: Re: [PATCHv4 3/9] Thermal: Create zone level APIs
> 
> On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
> > This patch adds a new thermal_zone structure to
> > thermal.h. Also, adds zone level APIs to the thermal
> > framework.
> >
> > A thermal zone is a hot spot on the platform, which
> > can have one or more sensors and cooling devices attached
> > to it. These sensors can be mapped to a set of cooling
> > devices, which when throttled, can help to bring down
> > the temperature of the hot spot.
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >  drivers/thermal/thermal_core.c |  267
> +++-
> >  include/linux/thermal.h|   23 
> >  2 files changed, 289 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> > index 8c46567..a053b60 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -44,19 +44,48 @@ MODULE_DESCRIPTION("Generic thermal management
> sysfs support");
> >  MODULE_LICENSE("GPL v2");
> >
> >  static DEFINE_IDR(thermal_tz_idr);
> > +static DEFINE_IDR(thermal_zone_idr);
> >  static DEFINE_IDR(thermal_cdev_idr);
> >  static DEFINE_IDR(thermal_sensor_idr);
> >  static DEFINE_MUTEX(thermal_idr_lock);
> >
> >  static LIST_HEAD(thermal_tz_list);
> >  static LIST_HEAD(thermal_sensor_list);
> > +static LIST_HEAD(thermal_zone_list);
> >  static LIST_HEAD(thermal_cdev_list);
> >  static LIST_HEAD(thermal_governor_list);
> >
> >  static DEFINE_MUTEX(thermal_list_lock);
> >  static DEFINE_MUTEX(sensor_list_lock);
> > +static DEFINE_MUTEX(zone_list_lock);
> >  static DEFINE_MUTEX(thermal_governor_lock);
> >
> > +#define for_each_thermal_sensor(pos) \
> > +   list_for_each_entry(pos, _sensor_list, node)
> > +
> > +#define for_each_thermal_zone(pos) \
> > +   list_for_each_entry(pos, _zone_list, node)
> > +
> > +#define GET_INDEX(tz, ptr, type)   \
> > +({ \
> > +   int i, ret = -EINVAL;   \
> > +   do {\
> > +   if (!tz || !ptr)\
> > +   break;  \
> > +   mutex_lock(>lock);  \
> > +   mutex_lock(##_list_lock);  \
> > +   for (i = 0; i < tz->type##_indx; i++) { \
> > +   if (tz->type##s[i] == ptr) {\
> > +   ret = i;\
> > +   break;  \
> > +   }   \
> > +   }   \
> > +   mutex_unlock(##_list_lock);\
> > +   mutex_unlock(>lock);\
> > +   } while (0);\
> > +   ret;\
> > +})
> > +
> >  static struct thermal_governor *__find_governor(const char *name)
> >  {
> > struct thermal_governor *pos;
> > @@ -461,15 +490,47 @@ static void thermal_zone_device_check(struct
> work_struct *work)
> > thermal_zone_device_update(tz);
> >  }
> >
> > +static void remove_sensor_from_zone(struct thermal_zone *tz,
> > +   struct thermal_sensor *ts)
> > +{
> > +   int j, indx;
> > +
> > +   indx = GET_INDEX(tz, ts, sensor);
> > +   if (indx < 0)
> > +   return;
> > +
> > +   sysfs_remove_link(>device.kobj, kobject_name(>device.kobj));
> > +
> > +   mutex_lock(>lock);
> > +
> > +   /* Shift the entries in the tz->sensors array */
> > +   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
> > +   tz->sensors[j] = tz->sensors[j + 1];
> > +
> > +   tz->sensor_indx--;
> > +   mutex_unlock(>lock);
> > +}
> > +
> >  /* sys I/F for thermal zone */
> >
> >  #define to_thermal_zone(_dev) \
> > container_of(_dev, struct thermal_zone_device, device)
> >
> > +#define to_zone(_dev) \
> > +   container_of(_dev, struct thermal_zone, device)
> &

RE: [PATCHv4 3/9] Thermal: Create zone level APIs

[R, Durgadoss]

Hi rui,

 -Original Message-
 From: Zhang, Rui
 Sent: Tuesday, October 15, 2013 3:53 PM
 To: R, Durgadoss
 Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
 ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
 Subject: Re: [PATCHv4 3/9] Thermal: Create zone level APIs
 
 On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
  This patch adds a new thermal_zone structure to
  thermal.h. Also, adds zone level APIs to the thermal
  framework.
 
  A thermal zone is a hot spot on the platform, which
  can have one or more sensors and cooling devices attached
  to it. These sensors can be mapped to a set of cooling
  devices, which when throttled, can help to bring down
  the temperature of the hot spot.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
   drivers/thermal/thermal_core.c |  267
 +++-
   include/linux/thermal.h|   23 
   2 files changed, 289 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
  index 8c46567..a053b60 100644
  --- a/drivers/thermal/thermal_core.c
  +++ b/drivers/thermal/thermal_core.c
  @@ -44,19 +44,48 @@ MODULE_DESCRIPTION(Generic thermal management
 sysfs support);
   MODULE_LICENSE(GPL v2);
 
   static DEFINE_IDR(thermal_tz_idr);
  +static DEFINE_IDR(thermal_zone_idr);
   static DEFINE_IDR(thermal_cdev_idr);
   static DEFINE_IDR(thermal_sensor_idr);
   static DEFINE_MUTEX(thermal_idr_lock);
 
   static LIST_HEAD(thermal_tz_list);
   static LIST_HEAD(thermal_sensor_list);
  +static LIST_HEAD(thermal_zone_list);
   static LIST_HEAD(thermal_cdev_list);
   static LIST_HEAD(thermal_governor_list);
 
   static DEFINE_MUTEX(thermal_list_lock);
   static DEFINE_MUTEX(sensor_list_lock);
  +static DEFINE_MUTEX(zone_list_lock);
   static DEFINE_MUTEX(thermal_governor_lock);
 
  +#define for_each_thermal_sensor(pos) \
  +   list_for_each_entry(pos, thermal_sensor_list, node)
  +
  +#define for_each_thermal_zone(pos) \
  +   list_for_each_entry(pos, thermal_zone_list, node)
  +
  +#define GET_INDEX(tz, ptr, type)   \
  +({ \
  +   int i, ret = -EINVAL;   \
  +   do {\
  +   if (!tz || !ptr)\
  +   break;  \
  +   mutex_lock(tz-lock);  \
  +   mutex_lock(type##_list_lock);  \
  +   for (i = 0; i  tz-type##_indx; i++) { \
  +   if (tz-type##s[i] == ptr) {\
  +   ret = i;\
  +   break;  \
  +   }   \
  +   }   \
  +   mutex_unlock(type##_list_lock);\
  +   mutex_unlock(tz-lock);\
  +   } while (0);\
  +   ret;\
  +})
  +
   static struct thermal_governor *__find_governor(const char *name)
   {
  struct thermal_governor *pos;
  @@ -461,15 +490,47 @@ static void thermal_zone_device_check(struct
 work_struct *work)
  thermal_zone_device_update(tz);
   }
 
  +static void remove_sensor_from_zone(struct thermal_zone *tz,
  +   struct thermal_sensor *ts)
  +{
  +   int j, indx;
  +
  +   indx = GET_INDEX(tz, ts, sensor);
  +   if (indx  0)
  +   return;
  +
  +   sysfs_remove_link(tz-device.kobj, kobject_name(ts-device.kobj));
  +
  +   mutex_lock(tz-lock);
  +
  +   /* Shift the entries in the tz-sensors array */
  +   for (j = indx; j  MAX_SENSORS_PER_ZONE - 1; j++)
  +   tz-sensors[j] = tz-sensors[j + 1];
  +
  +   tz-sensor_indx--;
  +   mutex_unlock(tz-lock);
  +}
  +
   /* sys I/F for thermal zone */
 
   #define to_thermal_zone(_dev) \
  container_of(_dev, struct thermal_zone_device, device)
 
  +#define to_zone(_dev) \
  +   container_of(_dev, struct thermal_zone, device)
  +
   #define to_thermal_sensor(_dev) \
  container_of(_dev, struct thermal_sensor, device)
 
   static ssize_t
  +zone_name_show(struct device *dev, struct device_attribute *attr, char
 *buf)
  +{
  +   struct thermal_zone *tz = to_zone(dev);
  +
  +   return sprintf(buf, %s\n, tz-name);
  +}
  +
  +static ssize_t
   sensor_name_show(struct device *dev, struct device_attribute *attr, char
 *buf)
   {
  struct thermal_sensor *ts = to_thermal_sensor(dev);
  @@ -876,6 +937,8 @@ static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR,
 policy_show, policy_store);
   static DEVICE_ATTR(sensor_name, 0444, sensor_name_show, NULL);
   static DEVICE_ATTR(temp_input, 0444, sensor_temp_show, NULL);
 
  +static DEVICE_ATTR(zone_name, 0444, zone_name_show, NULL);
  +
   /* sys I/F for cooling device */
   #define to_cooling_device(_dev)\
  container_of(_dev, struct

RE: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor

[R, Durgadoss]

 -Original Message-
 From: Zhang, Rui
 Sent: Tuesday, October 15, 2013 4:33 PM
 To: R, Durgadoss
 Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
 ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
 Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor
 
 On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
  This patch adds a trip point related sysfs nodes
  for each sensor under a zone in /sys/class/thermal/zoneX/.
  The nodes will be named, sensorX_trip_activeY,
  sensorX_trip_passiveY, sensorX_trip_hot, sensorX_trip_critical
  for active, passive, hot and critical trip points
  respectively for sensorX.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
   drivers/thermal/thermal_core.c |  344
 +++-
   include/linux/thermal.h|   40 -
   2 files changed, 379 insertions(+), 5 deletions(-)
 
  diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
  index 3c4ef62..d6e29f6 100644
  --- a/drivers/thermal/thermal_core.c
  +++ b/drivers/thermal/thermal_core.c
  @@ -494,6 +494,60 @@ static void thermal_zone_device_check(struct
 work_struct *work)
  thermal_zone_device_update(tz);
   }
 
  +static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char
 *name)
  +{
  +   int i, indx = -EINVAL;
  +
  +   /* Protect against tz-sensors[i] being unregistered */
  +   mutex_lock(sensor_list_lock);
  +
  +   for (i = 0; i  tz-sensor_indx; i++) {
  +   if (!strnicmp(name, kobject_name(tz-sensors[i]-
 device.kobj),
  +   THERMAL_NAME_LENGTH)) {
  +   indx = i;
  +   break;
  +   }
  +   }
  +
  +   mutex_unlock(sensor_list_lock);
  +   return indx;
  +}
  +
  +static void __remove_trip_attr(struct thermal_zone *tz, int indx)
  +{
  +   int i;
  +   struct thermal_trip_attr *attr = tz-trip_attr[indx];
  +   struct thermal_trip_point *trip = tz-sensor_trip[indx];
  +
  +   if (!attr || !trip)
  +   return;
  +
  +   if (trip-crit != THERMAL_TRIPS_NONE)
  +   device_remove_file(tz-device, attr-crit_attr.attr);
  +
  +   if (trip-hot != THERMAL_TRIPS_NONE)
  +   device_remove_file(tz-device, attr-hot_attr.attr);
  +
  +   if (trip-num_passive_trips  0) {
  +   for (i = 0; i  trip-num_passive_trips; i++) {
  +   device_remove_file(tz-device,
  +   attr-passive_attrs[i].attr);
  +   }
  +   kfree(attr-passive_attrs);
  +   }
  +
  +   if (trip-num_active_trips  0) {
  +   for (i = 0; i  trip-num_active_trips; i++) {
  +   device_remove_file(tz-device,
  +   attr-active_attrs[i].attr);
  +   }
  +   kfree(attr-active_attrs);
  +   }
  +
  +   kfree(tz-trip_attr[indx]);
  +   tz-trip_attr[indx] = NULL;
  +}
  +
   static void remove_sensor_from_zone(struct thermal_zone *tz,
  struct thermal_sensor *ts)
   {
  @@ -503,13 +557,19 @@ static void remove_sensor_from_zone(struct
 thermal_zone *tz,
  if (indx  0)
  return;
 
  -   sysfs_remove_link(tz-device.kobj, kobject_name(ts-device.kobj));
  -
  mutex_lock(tz-lock);
 
  +   /* Remove trip point attributes associated with this sensor */
  +   __remove_trip_attr(tz, indx);
  +
  +   sysfs_remove_link(tz-device.kobj, kobject_name(ts-device.kobj));
  +
  /* Shift the entries in the tz-sensors array */
  -   for (j = indx; j  MAX_SENSORS_PER_ZONE - 1; j++)
  +   for (j = indx; j  MAX_SENSORS_PER_ZONE - 1; j++) {
  tz-sensors[j] = tz-sensors[j + 1];
  +   tz-sensor_trip[j] = tz-sensor_trip[j + 1];
  +   tz-trip_attr[j] = tz-trip_attr[j + 1];
  +   }
 
  tz-sensor_indx--;
  mutex_unlock(tz-lock);
  @@ -952,6 +1012,111 @@ emul_temp_store(struct device *dev, struct
 device_attribute *attr,
   static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
   #endif/*CONFIG_THERMAL_EMULATION*/
 
  +static ssize_t
  +active_trip_show(struct device *dev, struct device_attribute *attr, char 
  *buf)
  +{
  +   int i, j, val;
  +   char kobj_name[THERMAL_NAME_LENGTH];
  +   struct thermal_zone *tz = to_zone(dev);
  +
  +   if (!sscanf(attr-attr.name, sensor%d_trip_active%d, i, j))
  +   return -EINVAL;
  +
  +   snprintf(kobj_name, THERMAL_NAME_LENGTH, sensor%d, i);
  +
  +   mutex_lock(tz-lock);
  +
  +   i = get_sensor_indx_by_kobj(tz, kobj_name);
  +   if (i  0) {
  +   mutex_unlock(tz-lock);
  +   return i;
  +   }
  +
  +   val = tz-sensor_trip[i]-active_trips[j];
  +   mutex_unlock(tz-lock);
  +
  +   return sprintf(buf, %d\n, val);
  +}
  +
  +static ssize_t
  +passive_trip_show(struct device *dev, struct device_attribute *attr, char
 *buf)
  +{
  +   int i, j, val;
  +   char kobj_name[THERMAL_NAME_LENGTH];
  +   struct thermal_zone *tz = to_zone(dev

RE: [PATCHv4 2/9] Thermal: Create sensor level APIs

[R, Durgadoss]

Hi Rui,

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Zhang Rui
> Sent: Monday, October 14, 2013 2:56 PM
> To: R, Durgadoss
> Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
> Subject: Re: [PATCHv4 2/9] Thermal: Create sensor level APIs
> 
> On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
> > This patch creates sensor level APIs, in the
> > generic thermal framework.
> >
> > A Thermal sensor is a piece of hardware that can report
> > temperature of the spot in which it is placed. A thermal
> > sensor driver reads the temperature from this sensor
> > and reports it out. This kind of driver can be in
> > any subsystem. If the sensor needs to participate
> > in platform thermal management, the corresponding
> > driver can use the APIs introduced in this patch, to
> > register(or unregister) with the thermal framework.
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >  drivers/thermal/thermal_core.c |  284
> 
> >  include/linux/thermal.h|   29 
> >  2 files changed, 313 insertions(+)
> >
> > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> > index 8c5131d..8c46567 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -45,13 +45,16 @@ MODULE_LICENSE("GPL v2");
> >
> >  static DEFINE_IDR(thermal_tz_idr);
> >  static DEFINE_IDR(thermal_cdev_idr);
> > +static DEFINE_IDR(thermal_sensor_idr);
> >  static DEFINE_MUTEX(thermal_idr_lock);
> >
> >  static LIST_HEAD(thermal_tz_list);
> > +static LIST_HEAD(thermal_sensor_list);
> >  static LIST_HEAD(thermal_cdev_list);
> >  static LIST_HEAD(thermal_governor_list);
> >
> >  static DEFINE_MUTEX(thermal_list_lock);
> > +static DEFINE_MUTEX(sensor_list_lock);
> >  static DEFINE_MUTEX(thermal_governor_lock);
> >
> >  static struct thermal_governor *__find_governor(const char *name)
> > @@ -463,6 +466,103 @@ static void thermal_zone_device_check(struct
> work_struct *work)
> >  #define to_thermal_zone(_dev) \
> > container_of(_dev, struct thermal_zone_device, device)
> >
> > +#define to_thermal_sensor(_dev) \
> > +   container_of(_dev, struct thermal_sensor, device)
> > +
> > +static ssize_t
> > +sensor_name_show(struct device *dev, struct device_attribute *attr, char
> *buf)
> > +{
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   return sprintf(buf, "%s\n", ts->name);
> > +}
> > +
> > +static ssize_t
> > +sensor_temp_show(struct device *dev, struct device_attribute *attr, char
> *buf)
> > +{
> > +   int ret;
> > +   long val;
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   ret = ts->ops->get_temp(ts, );
> > +
> > +   return ret ? ret : sprintf(buf, "%ld\n", val);
> > +}
> > +
> > +static ssize_t
> > +hyst_show(struct device *dev, struct device_attribute *attr, char *buf)
> > +{
> > +   int indx, ret;
> > +   long val;
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   if (!sscanf(attr->attr.name, "threshold%d_hyst", ))
> > +   return -EINVAL;
> > +
> > +   ret = ts->ops->get_hyst(ts, indx, );
> > +
> > +   return ret ? ret : sprintf(buf, "%ld\n", val);
> > +}
> > +
> > +static ssize_t
> > +hyst_store(struct device *dev, struct device_attribute *attr,
> > +  const char *buf, size_t count)
> > +{
> > +   int indx, ret;
> > +   long val;
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   if (!ts->ops->set_hyst)
> > +   return -EPERM;
> > +
> > +   if (!sscanf(attr->attr.name, "threshold%d_hyst", ))
> > +   return -EINVAL;
> > +
> > +   if (kstrtol(buf, 10, ))
> > +   return -EINVAL;
> > +
> > +   ret = ts->ops->set_hyst(ts, indx, val);
> > +
> > +   return ret ? ret : count;
> > +}
> > +
> > +static ssize_t
> > +threshold_show(struct device *dev, struct device_attribute *attr, char 
> > *buf)
> > +{
> > +   int indx, ret;
> > +   long val;
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   if (!sscanf(attr->attr.na

RE: [PATCHv4 2/9] Thermal: Create sensor level APIs

[R, Durgadoss]

Hi Rui,

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Zhang Rui
 Sent: Monday, October 14, 2013 2:56 PM
 To: R, Durgadoss
 Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
 ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
 Subject: Re: [PATCHv4 2/9] Thermal: Create sensor level APIs
 
 On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
  This patch creates sensor level APIs, in the
  generic thermal framework.
 
  A Thermal sensor is a piece of hardware that can report
  temperature of the spot in which it is placed. A thermal
  sensor driver reads the temperature from this sensor
  and reports it out. This kind of driver can be in
  any subsystem. If the sensor needs to participate
  in platform thermal management, the corresponding
  driver can use the APIs introduced in this patch, to
  register(or unregister) with the thermal framework.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
   drivers/thermal/thermal_core.c |  284
 
   include/linux/thermal.h|   29 
   2 files changed, 313 insertions(+)
 
  diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
  index 8c5131d..8c46567 100644
  --- a/drivers/thermal/thermal_core.c
  +++ b/drivers/thermal/thermal_core.c
  @@ -45,13 +45,16 @@ MODULE_LICENSE(GPL v2);
 
   static DEFINE_IDR(thermal_tz_idr);
   static DEFINE_IDR(thermal_cdev_idr);
  +static DEFINE_IDR(thermal_sensor_idr);
   static DEFINE_MUTEX(thermal_idr_lock);
 
   static LIST_HEAD(thermal_tz_list);
  +static LIST_HEAD(thermal_sensor_list);
   static LIST_HEAD(thermal_cdev_list);
   static LIST_HEAD(thermal_governor_list);
 
   static DEFINE_MUTEX(thermal_list_lock);
  +static DEFINE_MUTEX(sensor_list_lock);
   static DEFINE_MUTEX(thermal_governor_lock);
 
   static struct thermal_governor *__find_governor(const char *name)
  @@ -463,6 +466,103 @@ static void thermal_zone_device_check(struct
 work_struct *work)
   #define to_thermal_zone(_dev) \
  container_of(_dev, struct thermal_zone_device, device)
 
  +#define to_thermal_sensor(_dev) \
  +   container_of(_dev, struct thermal_sensor, device)
  +
  +static ssize_t
  +sensor_name_show(struct device *dev, struct device_attribute *attr, char
 *buf)
  +{
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   return sprintf(buf, %s\n, ts-name);
  +}
  +
  +static ssize_t
  +sensor_temp_show(struct device *dev, struct device_attribute *attr, char
 *buf)
  +{
  +   int ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   ret = ts-ops-get_temp(ts, val);
  +
  +   return ret ? ret : sprintf(buf, %ld\n, val);
  +}
  +
  +static ssize_t
  +hyst_show(struct device *dev, struct device_attribute *attr, char *buf)
  +{
  +   int indx, ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   if (!sscanf(attr-attr.name, threshold%d_hyst, indx))
  +   return -EINVAL;
  +
  +   ret = ts-ops-get_hyst(ts, indx, val);
  +
  +   return ret ? ret : sprintf(buf, %ld\n, val);
  +}
  +
  +static ssize_t
  +hyst_store(struct device *dev, struct device_attribute *attr,
  +  const char *buf, size_t count)
  +{
  +   int indx, ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   if (!ts-ops-set_hyst)
  +   return -EPERM;
  +
  +   if (!sscanf(attr-attr.name, threshold%d_hyst, indx))
  +   return -EINVAL;
  +
  +   if (kstrtol(buf, 10, val))
  +   return -EINVAL;
  +
  +   ret = ts-ops-set_hyst(ts, indx, val);
  +
  +   return ret ? ret : count;
  +}
  +
  +static ssize_t
  +threshold_show(struct device *dev, struct device_attribute *attr, char 
  *buf)
  +{
  +   int indx, ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   if (!sscanf(attr-attr.name, threshold%d, indx))
  +   return -EINVAL;
  +
  +   ret = ts-ops-get_threshold(ts, indx, val);
  +
  +   return ret ? ret : sprintf(buf, %ld\n, val);
  +}
  +
  +static ssize_t
  +threshold_store(struct device *dev, struct device_attribute *attr,
  +  const char *buf, size_t count)
  +{
  +   int indx, ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   if (!ts-ops-set_threshold)
  +   return -EPERM;
  +
  +   if (!sscanf(attr-attr.name, threshold%d, indx))
  +   return -EINVAL;
  +
  +   if (kstrtol(buf, 10, val))
  +   return -EINVAL;
  +
  +   ret = ts-ops-set_threshold(ts, indx, val);
  +
  +   return ret ? ret : count;
  +}
  +
   static ssize_t
   type_show(struct device *dev, struct device_attribute *attr, char *buf)
   {
  @@ -772,6 +872,10 @@ static DEVICE_ATTR(mode, 0644, mode_show,
 mode_store);
   static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show,
 passive_store);
   static DEVICE_ATTR(policy, S_IRUGO

RE: [PATCHv3 0/8] Thermal Framework Enhancements

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Friday, August 30, 2013 6:04 PM
> To: R, Durgadoss
> Cc: Eduardo Valentin; Zhang, Rui; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCHv3 0/8] Thermal Framework Enhancements
> 
> On 30-08-2013 05:20, R, Durgadoss wrote:
> > Hi Eduardo,
> >
> >> -Original Message-
> >> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> >> Sent: Friday, August 30, 2013 1:08 AM
> >> To: R, Durgadoss
> >> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> >> Subject: Re: [PATCHv3 0/8] Thermal Framework Enhancements
> >>
> >> Durga,
> >>
> >> On 05-02-2013 06:46, Durgadoss R wrote:
> >>> This patch set is a v3 of the previous versions submitted here:
> >>> [v2]: http://lwn.net/Articles/531720/
> >>> [v1]: https://lkml.org/lkml/2012/12/18/108
> >>> [RFC]:https://patchwork.kernel.org/patch/1758921/
> >>>
> >>
> >> Long time this work is not moving forward. While writing the device tree
> >
> > I am trying my best to get to this,
> > Will try to refresh in a couple of weeks.
> >
> >> parser, I thought of using your work as baseline to see how the multiple
> >> sensor per zone would look like (also in DT).
> >>
> >> But while checking your code again, I realized that you are actually
> >> creating a new API, that is probably why you named it sysfs-api2. While
> >> I understand the motivation (they are pretty different), I believe this
> >> is not a good thing to do. I would suggest making so that we have a
> >> single API.
> >
> > As in the sensor APIs ? or the zone level APIs ?
> > The sensor level APIs are anyway new; the zone level ones
> > we have to work out a way for them.
> >
> > Is this what you are referring to ? Could you confirm/explain a bit more ?
> 
> OK. Let's assume that maybe I didn't quite get your proposal then. Let
> me step back and ask you what is the relation between existing
> thermal_zone_device and thermal_zone? Would existing drivers be

The existing thermal_zone_device would be a new thermal zone
with one sensor in it.

> complaint with new API?

Okay got it. This is what myself & Rui discussed a while ago to address
this.

When these patches are merged, they will co-exist for some time.
Rui had an idea to write a wrapper on top of these, which will
make the existing drivers complaint with new API. 
This wrapper can be a Kconfig option, to select on what we need;
new/existing APIs.

Thanks,
Durga

> >
> >>
> >>> This patch set is based on Rui's -next tree, and is
> >>> tested on a Core-i5 and an Atom netbook.
> >>>
> >>> Changes since v2:
> >>>  * Reworked the map sysfs attributes in patch [5/8]
> >>>  * Dropped configuration for maximum sensors and
> >>>cooling devices, through Kconfig.
> >>>  * Added __remove_trip_attr method
> >>>  * Renamed __clean_map_entry to __remove_map_entry
> >>>for consistency in naming.
> >>> Changes Since v1:
> >>>  * Removed kobject creation for thermal_trip and thermal_map
> >>>nodes as per Greg-KH's comments.
> >>>  * Added ABI Documentation under 'testing'.
> >>>  * Modified the GET_INDEX macro to be more linux-like, thanks
> >>>to Joe Perches.
> >>>  * Added get_[sensor/cdev]_by_name APIs to thermal.h
> >>>
> >>> This series contains 8 patches:
> >>> Patch 1/8: Creates new sensor level APIs
> >>> Patch 2/8: Creates new zone level APIs. The existing tzd structure is
> >>>kept as such for clarity and compatibility purposes.
> >>> Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
> >>>existing tcd structure need not be modified.
> >>> Patch 4/8: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
> >>>  under /sys/class/thermal/zoneY/. This exposes various trip
> >>>points for sensorX present in zoneY.
> >>> Patch 5/8: Adds mapY_* sysfs node. These attributes represent
> >>>the binding relationship between a sensor and a cdev,
> >>>within a zone.
> >>> Patch 6/8: Creates Documentation for the

RE: [PATCHv3 0/8] Thermal Framework Enhancements

[R, Durgadoss]

Hi Eduardo,

> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> Sent: Friday, August 30, 2013 1:08 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCHv3 0/8] Thermal Framework Enhancements
> 
> Durga,
> 
> On 05-02-2013 06:46, Durgadoss R wrote:
> > This patch set is a v3 of the previous versions submitted here:
> > [v2]: http://lwn.net/Articles/531720/
> > [v1]: https://lkml.org/lkml/2012/12/18/108
> > [RFC]:https://patchwork.kernel.org/patch/1758921/
> >
> 
> Long time this work is not moving forward. While writing the device tree

I am trying my best to get to this,
Will try to refresh in a couple of weeks.

> parser, I thought of using your work as baseline to see how the multiple
> sensor per zone would look like (also in DT).
> 
> But while checking your code again, I realized that you are actually
> creating a new API, that is probably why you named it sysfs-api2. While
> I understand the motivation (they are pretty different), I believe this
> is not a good thing to do. I would suggest making so that we have a
> single API.

As in the sensor APIs ? or the zone level APIs ?
The sensor level APIs are anyway new; the zone level ones
we have to work out a way for them.

Is this what you are referring to ? Could you confirm/explain a bit more ?

Thanks,
Durga

> 
> > This patch set is based on Rui's -next tree, and is
> > tested on a Core-i5 and an Atom netbook.
> >
> > Changes since v2:
> >  * Reworked the map sysfs attributes in patch [5/8]
> >  * Dropped configuration for maximum sensors and
> >cooling devices, through Kconfig.
> >  * Added __remove_trip_attr method
> >  * Renamed __clean_map_entry to __remove_map_entry
> >for consistency in naming.
> > Changes Since v1:
> >  * Removed kobject creation for thermal_trip and thermal_map
> >nodes as per Greg-KH's comments.
> >  * Added ABI Documentation under 'testing'.
> >  * Modified the GET_INDEX macro to be more linux-like, thanks
> >to Joe Perches.
> >  * Added get_[sensor/cdev]_by_name APIs to thermal.h
> >
> > This series contains 8 patches:
> > Patch 1/8: Creates new sensor level APIs
> > Patch 2/8: Creates new zone level APIs. The existing tzd structure is
> >kept as such for clarity and compatibility purposes.
> > Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
> >existing tcd structure need not be modified.
> > Patch 4/8: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
> >under /sys/class/thermal/zoneY/. This exposes various trip
> >points for sensorX present in zoneY.
> > Patch 5/8: Adds mapY_* sysfs node. These attributes represent
> >the binding relationship between a sensor and a cdev,
> >within a zone.
> > Patch 6/8: Creates Documentation for the new APIs. A new file is
> >created for clarity. Final goal is to merge with the existing
> >file or refactor the files, as whatever seems appropriate.
> > Patch 7/8: Add ABI documentation for sysfs interfaces introduced in this 
> > patch.
> > Patch 8/8: A dummy driver that can be used for testing. This is not for 
> > merge.
> >
> > Durgadoss R (8):
> >   Thermal: Create sensor level APIs
> >   Thermal: Create zone level APIs
> >   Thermal: Add APIs to bind cdev to new zone structure
> >   Thermal: Add trip point sysfs nodes for sensor
> >   Thermal: Create Thermal map sysfs attributes for a zone
> >   Thermal: Add Documentation to new APIs
> >   Thermal: Add ABI Documentation for sysfs interfaces
> >   Thermal: Dummy driver used for testing
> >
> >  Documentation/ABI/testing/sysfs-class-thermal |  137 
> >  Documentation/thermal/sysfs-api2.txt  |  247 ++
> >  drivers/thermal/Kconfig   |5 +
> >  drivers/thermal/Makefile  |2 +
> >  drivers/thermal/thermal_sys.c |  994 
> > +
> >  drivers/thermal/thermal_test.c|  324 
> >  include/linux/thermal.h   |  123 ++-
> >  7 files changed, 1831 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
> >  create mode 100644 Documentation/thermal/sysfs-api2.txt
> >  create mode 100644 drivers/thermal/thermal_test.c
> >
> 
> 
> --
> You have got to be excited about what you are doing. (L. Lamport)
> 
> Eduardo Valentin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv3 0/8] Thermal Framework Enhancements

[R, Durgadoss]

Hi Eduardo,

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Friday, August 30, 2013 1:08 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCHv3 0/8] Thermal Framework Enhancements
 
 Durga,
 
 On 05-02-2013 06:46, Durgadoss R wrote:
  This patch set is a v3 of the previous versions submitted here:
  [v2]: http://lwn.net/Articles/531720/
  [v1]: https://lkml.org/lkml/2012/12/18/108
  [RFC]:https://patchwork.kernel.org/patch/1758921/
 
 
 Long time this work is not moving forward. While writing the device tree

I am trying my best to get to this,
Will try to refresh in a couple of weeks.

 parser, I thought of using your work as baseline to see how the multiple
 sensor per zone would look like (also in DT).
 
 But while checking your code again, I realized that you are actually
 creating a new API, that is probably why you named it sysfs-api2. While
 I understand the motivation (they are pretty different), I believe this
 is not a good thing to do. I would suggest making so that we have a
 single API.

As in the sensor APIs ? or the zone level APIs ?
The sensor level APIs are anyway new; the zone level ones
we have to work out a way for them.

Is this what you are referring to ? Could you confirm/explain a bit more ?

Thanks,
Durga

 
  This patch set is based on Rui's -next tree, and is
  tested on a Core-i5 and an Atom netbook.
 
  Changes since v2:
   * Reworked the map sysfs attributes in patch [5/8]
   * Dropped configuration for maximum sensors and
 cooling devices, through Kconfig.
   * Added __remove_trip_attr method
   * Renamed __clean_map_entry to __remove_map_entry
 for consistency in naming.
  Changes Since v1:
   * Removed kobject creation for thermal_trip and thermal_map
 nodes as per Greg-KH's comments.
   * Added ABI Documentation under 'testing'.
   * Modified the GET_INDEX macro to be more linux-like, thanks
 to Joe Perches.
   * Added get_[sensor/cdev]_by_name APIs to thermal.h
 
  This series contains 8 patches:
  Patch 1/8: Creates new sensor level APIs
  Patch 2/8: Creates new zone level APIs. The existing tzd structure is
 kept as such for clarity and compatibility purposes.
  Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
 existing tcd structure need not be modified.
  Patch 4/8: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
 under /sys/class/thermal/zoneY/. This exposes various trip
 points for sensorX present in zoneY.
  Patch 5/8: Adds mapY_* sysfs node. These attributes represent
 the binding relationship between a sensor and a cdev,
 within a zone.
  Patch 6/8: Creates Documentation for the new APIs. A new file is
 created for clarity. Final goal is to merge with the existing
 file or refactor the files, as whatever seems appropriate.
  Patch 7/8: Add ABI documentation for sysfs interfaces introduced in this 
  patch.
  Patch 8/8: A dummy driver that can be used for testing. This is not for 
  merge.
 
  Durgadoss R (8):
Thermal: Create sensor level APIs
Thermal: Create zone level APIs
Thermal: Add APIs to bind cdev to new zone structure
Thermal: Add trip point sysfs nodes for sensor
Thermal: Create Thermal map sysfs attributes for a zone
Thermal: Add Documentation to new APIs
Thermal: Add ABI Documentation for sysfs interfaces
Thermal: Dummy driver used for testing
 
   Documentation/ABI/testing/sysfs-class-thermal |  137 
   Documentation/thermal/sysfs-api2.txt  |  247 ++
   drivers/thermal/Kconfig   |5 +
   drivers/thermal/Makefile  |2 +
   drivers/thermal/thermal_sys.c |  994 
  +
   drivers/thermal/thermal_test.c|  324 
   include/linux/thermal.h   |  123 ++-
   7 files changed, 1831 insertions(+), 1 deletion(-)
   create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
   create mode 100644 Documentation/thermal/sysfs-api2.txt
   create mode 100644 drivers/thermal/thermal_test.c
 
 
 
 --
 You have got to be excited about what you are doing. (L. Lamport)
 
 Eduardo Valentin

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv3 0/8] Thermal Framework Enhancements

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
 Sent: Friday, August 30, 2013 6:04 PM
 To: R, Durgadoss
 Cc: Eduardo Valentin; Zhang, Rui; linux...@vger.kernel.org; linux-
 ker...@vger.kernel.org; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCHv3 0/8] Thermal Framework Enhancements
 
 On 30-08-2013 05:20, R, Durgadoss wrote:
  Hi Eduardo,
 
  -Original Message-
  From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
  Sent: Friday, August 30, 2013 1:08 AM
  To: R, Durgadoss
  Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
  eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
  Subject: Re: [PATCHv3 0/8] Thermal Framework Enhancements
 
  Durga,
 
  On 05-02-2013 06:46, Durgadoss R wrote:
  This patch set is a v3 of the previous versions submitted here:
  [v2]: http://lwn.net/Articles/531720/
  [v1]: https://lkml.org/lkml/2012/12/18/108
  [RFC]:https://patchwork.kernel.org/patch/1758921/
 
 
  Long time this work is not moving forward. While writing the device tree
 
  I am trying my best to get to this,
  Will try to refresh in a couple of weeks.
 
  parser, I thought of using your work as baseline to see how the multiple
  sensor per zone would look like (also in DT).
 
  But while checking your code again, I realized that you are actually
  creating a new API, that is probably why you named it sysfs-api2. While
  I understand the motivation (they are pretty different), I believe this
  is not a good thing to do. I would suggest making so that we have a
  single API.
 
  As in the sensor APIs ? or the zone level APIs ?
  The sensor level APIs are anyway new; the zone level ones
  we have to work out a way for them.
 
  Is this what you are referring to ? Could you confirm/explain a bit more ?
 
 OK. Let's assume that maybe I didn't quite get your proposal then. Let
 me step back and ask you what is the relation between existing
 thermal_zone_device and thermal_zone? Would existing drivers be

The existing thermal_zone_device would be a new thermal zone
with one sensor in it.

 complaint with new API?

Okay got it. This is what myself  Rui discussed a while ago to address
this.

When these patches are merged, they will co-exist for some time.
Rui had an idea to write a wrapper on top of these, which will
make the existing drivers complaint with new API. 
This wrapper can be a Kconfig option, to select on what we need;
new/existing APIs.

Thanks,
Durga

 
 
  This patch set is based on Rui's -next tree, and is
  tested on a Core-i5 and an Atom netbook.
 
  Changes since v2:
   * Reworked the map sysfs attributes in patch [5/8]
   * Dropped configuration for maximum sensors and
 cooling devices, through Kconfig.
   * Added __remove_trip_attr method
   * Renamed __clean_map_entry to __remove_map_entry
 for consistency in naming.
  Changes Since v1:
   * Removed kobject creation for thermal_trip and thermal_map
 nodes as per Greg-KH's comments.
   * Added ABI Documentation under 'testing'.
   * Modified the GET_INDEX macro to be more linux-like, thanks
 to Joe Perches.
   * Added get_[sensor/cdev]_by_name APIs to thermal.h
 
  This series contains 8 patches:
  Patch 1/8: Creates new sensor level APIs
  Patch 2/8: Creates new zone level APIs. The existing tzd structure is
 kept as such for clarity and compatibility purposes.
  Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
 existing tcd structure need not be modified.
  Patch 4/8: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
   under /sys/class/thermal/zoneY/. This exposes various trip
 points for sensorX present in zoneY.
  Patch 5/8: Adds mapY_* sysfs node. These attributes represent
 the binding relationship between a sensor and a cdev,
 within a zone.
  Patch 6/8: Creates Documentation for the new APIs. A new file is
 created for clarity. Final goal is to merge with the existing
 file or refactor the files, as whatever seems appropriate.
  Patch 7/8: Add ABI documentation for sysfs interfaces introduced in this
 patch.
  Patch 8/8: A dummy driver that can be used for testing. This is not for 
  merge.
 
  Durgadoss R (8):
Thermal: Create sensor level APIs
Thermal: Create zone level APIs
Thermal: Add APIs to bind cdev to new zone structure
Thermal: Add trip point sysfs nodes for sensor
Thermal: Create Thermal map sysfs attributes for a zone
Thermal: Add Documentation to new APIs
Thermal: Add ABI Documentation for sysfs interfaces
Thermal: Dummy driver used for testing
 
   Documentation/ABI/testing/sysfs-class-thermal |  137 
   Documentation/thermal/sysfs-api2.txt  |  247 ++
   drivers/thermal/Kconfig   |5 +
   drivers/thermal/Makefile  |2 +
   drivers/thermal

RE: [lm-sensors] [RESEND PATCH V1 2/9] thermal: hwmon: move hwmon support to single file

[R, Durgadoss]

> -Original Message-
> From: lm-sensors-boun...@lm-sensors.org [mailto:lm-sensors-bounces@lm-
> sensors.org] On Behalf Of Eduardo Valentin
> Sent: Wednesday, July 17, 2013 8:47 PM
> To: devicetree-disc...@lists.ozlabs.org
> Cc: w...@nvidia.com; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> lm-sens...@lm-sensors.org; Eduardo Valentin; Zhang, Rui;
> l.st...@pengutronix.de
> Subject: [lm-sensors] [RESEND PATCH V1 2/9] thermal: hwmon: move hwmon
> support to single file
> 
> In order to improve code organization, this patch
> moves the hwmon sysfs support to a file named
> thermal_hwmon. This helps to add extra support
> for hwmon without scrambling the code.
> 
> In order to do this move, the hwmon list head is now
> using its own locking. Before, the list used
> the global thermal locking. Also, some minor changes
> in the code were required, as recommended by checkpatch.pl.
> 
> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 

Went through the patch, looks fine. Nice clean up Eduardo!!

Acked-by: Durgadoss R 

Thanks,
Durga

> ---
>  drivers/thermal/Kconfig |   9 ++
>  drivers/thermal/Makefile|   3 +
>  drivers/thermal/thermal_core.c  | 255 +
>  drivers/thermal/thermal_hwmon.c | 269
> 
>  drivers/thermal/thermal_hwmon.h |  49 
>  5 files changed, 331 insertions(+), 254 deletions(-)
>  create mode 100644 drivers/thermal/thermal_hwmon.c
>  create mode 100644 drivers/thermal/thermal_hwmon.h
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index e988c81..7fb16bc 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -17,8 +17,17 @@ if THERMAL
> 
>  config THERMAL_HWMON
>   bool
> + prompt "Expose thermal sensors as hwmon device"
>   depends on HWMON=y || HWMON=THERMAL
>   default y
> + help
> +   In case a sensor is registered with the thermal
> +   framework, this option will also register it
> +   as a hwmon. The sensor will then have the common
> +   hwmon sysfs interface.
> +
> +   Say 'Y' here if you want all thermal sensors to
> +   have hwmon sysfs interface too.
> 
>  choice
>   prompt "Default Thermal governor"
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 67184a2..24cb894 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -5,6 +5,9 @@
>  obj-$(CONFIG_THERMAL)+= thermal_sys.o
>  thermal_sys-y+= thermal_core.o
> 
> +# interface to/from other layers providing sensors
> +thermal_sys-$(CONFIG_THERMAL_HWMON)  += thermal_hwmon.o
> +
>  # governors
>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
>  thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)  += step_wise.o
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 1f02e8e..247528b 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -38,6 +38,7 @@
>  #include 
> 
>  #include "thermal_core.h"
> +#include "thermal_hwmon.h"
> 
>  MODULE_AUTHOR("Zhang Rui");
>  MODULE_DESCRIPTION("Generic thermal management sysfs support");
> @@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device
> *dev,
> 
>  /* Device management */
> 
> -#if defined(CONFIG_THERMAL_HWMON)
> -
> -/* hwmon sys I/F */
> -#include 
> -
> -/* thermal zone devices with the same type share one hwmon device */
> -struct thermal_hwmon_device {
> - char type[THERMAL_NAME_LENGTH];
> - struct device *device;
> - int count;
> - struct list_head tz_list;
> - struct list_head node;
> -};
> -
> -struct thermal_hwmon_attr {
> - struct device_attribute attr;
> - char name[16];
> -};
> -
> -/* one temperature input for each thermal zone */
> -struct thermal_hwmon_temp {
> - struct list_head hwmon_node;
> - struct thermal_zone_device *tz;
> - struct thermal_hwmon_attr temp_input;   /* hwmon sys attr */
> - struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
> -};
> -
> -static LIST_HEAD(thermal_hwmon_list);
> -
> -static ssize_t
> -name_show(struct device *dev, struct device_attribute *attr, char *buf)
> -{
> - struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
> - return sprintf(buf, "%s\n", hwmon->type);
> -}
> -static DEVICE_ATTR(name, 0444, name_show, NULL);
> -
> -static ssize_t
> -temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
> -{
> - long temperature;
> - int ret;
> - struct thermal_hwmon_attr *hwmon_attr
> - = container_of(attr, struct thermal_hwmon_attr, attr);
> - struct thermal_hwmon_temp *temp
> - = container_of(hwmon_attr, struct
> thermal_hwmon_temp,
> -temp_input);
> - struct thermal_zone_device *tz = temp->tz;
> -
> - ret = 

RE: [lm-sensors] [RESEND PATCH V1 3/9] thermal: thermal_core: allow binding with limits on bind_params

[R, Durgadoss]

> -Original Message-
> From: lm-sensors-boun...@lm-sensors.org [mailto:lm-sensors-bounces@lm-
> sensors.org] On Behalf Of Eduardo Valentin
> Sent: Wednesday, July 17, 2013 8:47 PM
> To: devicetree-disc...@lists.ozlabs.org
> Cc: w...@nvidia.com; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> lm-sens...@lm-sensors.org; Eduardo Valentin; Zhang, Rui;
> l.st...@pengutronix.de
> Subject: [lm-sensors] [RESEND PATCH V1 3/9] thermal: thermal_core: allow
> binding with limits on bind_params
> 
> When registering a thermal zone device using platform information
> via bind_params, the thermal framework will always perform the
> cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).
> 
> This patch changes the data structures so that it is possible
> to inform what are the desired limits for each trip point
> inside a bind_param. The way the binding is performed is also
> changed so that it uses the new data structure.
> 
> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 

This patch looks good to me.
Acked-by: Durgadoss R 

Thanks,
Durga

> ---
>  Documentation/thermal/sysfs-api.txt |  7 +++
>  drivers/thermal/thermal_core.c  | 19 +++
>  include/linux/thermal.h | 10 ++
>  3 files changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/thermal/sysfs-api.txt
> b/Documentation/thermal/sysfs-api.txt
> index a71bd5b..2ad50e7 100644
> --- a/Documentation/thermal/sysfs-api.txt
> +++ b/Documentation/thermal/sysfs-api.txt
> @@ -134,6 +134,13 @@ temperature) and throttle appropriate devices.
> this thermal zone and cdev, for a particular trip point.
> If nth bit is set, then the cdev and thermal zone are bound
> for trip point n.
> +.limits: This is an array of cooling state limits. Must have exactly
> + 2 * thermal_zone.number_of_trip_points. It is an array consisting
> + of tuples  of state limits. Each trip
> + will be associated with one state limit tuple when binding.
> + A NULL pointer means 
> + on all trips. These limits are used when binding a cdev to a
> + trip point.
>  .match: This call back returns success(0) if the 'tz and cdev' need to
>   be bound, as per platform data.
>  1.4.2 struct thermal_zone_params
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 247528b..096c8be 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -202,14 +202,23 @@ static void print_bind_err_msg(struct
> thermal_zone_device *tz,
>  }
> 
>  static void __bind(struct thermal_zone_device *tz, int mask,
> - struct thermal_cooling_device *cdev)
> + struct thermal_cooling_device *cdev,
> + unsigned long *limits)
>  {
>   int i, ret;
> 
>   for (i = 0; i < tz->trips; i++) {
>   if (mask & (1 << i)) {
> + unsigned long upper, lower;
> +
> + upper = THERMAL_NO_LIMIT;
> + lower = THERMAL_NO_LIMIT;
> + if (limits) {
> + lower = limits[i * 2];
> + upper = limits[i * 2 + 1];
> + }
>   ret = thermal_zone_bind_cooling_device(tz, i, cdev,
> - THERMAL_NO_LIMIT,
> THERMAL_NO_LIMIT);
> +upper, lower);
>   if (ret)
>   print_bind_err_msg(tz, cdev, ret);
>   }
> @@ -254,7 +263,8 @@ static void bind_cdev(struct thermal_cooling_device
> *cdev)
>   if (tzp->tbp[i].match(pos, cdev))
>   continue;
>   tzp->tbp[i].cdev = cdev;
> - __bind(pos, tzp->tbp[i].trip_mask, cdev);
> + __bind(pos, tzp->tbp[i].trip_mask, cdev,
> +tzp->tbp[i].binding_limits);
>   }
>   }
> 
> @@ -292,7 +302,8 @@ static void bind_tz(struct thermal_zone_device *tz)
>   if (tzp->tbp[i].match(tz, pos))
>   continue;
>   tzp->tbp[i].cdev = pos;
> - __bind(tz, tzp->tbp[i].trip_mask, pos);
> + __bind(tz, tzp->tbp[i].trip_mask, pos,
> +tzp->tbp[i].binding_limits);
>   }
>   }
>  exit:
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index a386a1c..39575eb 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -207,6 +207,16 @@ struct thermal_bind_params {
>* See Documentation/thermal/sysfs-api.txt for more information.
>*/
>   int trip_mask;
> +
> + /*
> +  * This is an array of cooling 

RE: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file

[R, Durgadoss]

Hi Wei,

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Wei Ni
> Sent: Wednesday, July 17, 2013 3:19 PM
> To: Eduardo Valentin
> Cc: R, Durgadoss; linux...@vger.kernel.org; amit.dan...@samsung.com; Zhang,
> Rui; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single
> file
> 
> On 07/10/2013 12:54 AM, Eduardo Valentin wrote:
> > * PGP Signed: 07/09/2013 at 09:54:04 AM
> >
> > On 09-07-2013 12:04, R, Durgadoss wrote:
> >> Hi Eduardo,
> >>
> >>> -Original Message-
> >>> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> >>> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> >>> Sent: Tuesday, July 09, 2013 7:30 PM
> >>> To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
> >>> Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
> >>> Subject: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single
> file
> >>>
> >>> In order to improve code organization, this patch
> >>> moves the hwmon sysfs support to a file named
> >>> thermal_hwmon. This helps to add extra support
> >>> for hwmon without scrambling the code.
> >>
> >> Nice clean up for thermal_core.c. +1 from me.
> >>
> >> I am inclined to even remove the hwmon related code completely.
> >> AFAIK, there are not many users of this config option.
> >>
> >
> > Hmm. OK. I thought of keeping it as I dont know if there are users.
> > Besides, if new code comes out of the hwmon2thermalfw exercise, then it
> > would be a good place to keep all the hwmon code.
> >
> >> However people are looking for the other option. If they have a
> >> hwmon driver, how can it use the thermal framework with ease.
> >> [like what you mentioned about this in 0/5]
> 
> Yes, I'm trying to add lm90 driver to the thermal framework, but this
> driver already register as a hwmon device, so when register as thermal
> zone device, the thermal framework will register another virtual hwmon
> device, it mean we have duplicate hwmon devices, it will make confusion.
> How about to add a flag in the thermal_zone_params, so when call
> thermal_zone_device_register() to register, this flag can indicate if we
> want to register the virtual hwmon device or not.

I was following your threads in both lm-sensors and here.
I tend to agree with adding this flag in tzp structure.

But, we don't have tzp defined for all thermal zones
that are registering today. So, we need to define the default behavior.
I suggest we set the default to 'No', meaning 'do not create hwmon
devices when this zone is registered'.

Thanks,
Durga

> 
> Thanks.
> Wei.
> 
> >
> > yes, problem is that hwmon does not have a standard way of representing
> > the drivers. So, one cannot simply write a simple wrapper because hwmon
> > drivers does not have a standard get_temperature operation, for instance.
> >
> > We could either propose a way to standardize then or implement the call
> > to thermal fw driver by driver. Probably the later is desirable, if we
> > implement it in a need basis.
> >
> >>
> >> Thanks,
> >> Durga
> >>
> >>>
> >>> In order to do this move, the hwmon list head is now
> >>> using its own locking. Before, the list used
> >>> the global thermal locking.
> >>>
> >>> Cc: Zhang Rui 
> >>> Cc: linux...@vger.kernel.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>> Signed-off-by: Eduardo Valentin 
> >>> ---
> >>>  drivers/thermal/Kconfig |   9 ++
> >>>  drivers/thermal/Makefile|   3 +
> >>>  drivers/thermal/thermal_core.c  | 255 
> >>> +-
> >>>  drivers/thermal/thermal_hwmon.c | 268
> >>> 
> >>>  drivers/thermal/thermal_hwmon.h |  49 
> >>>  5 files changed, 330 insertions(+), 254 deletions(-)
> >>>  create mode 100644 drivers/thermal/thermal_hwmon.c
> >>>  create mode 100644 drivers/thermal/thermal_hwmon.h
> >>>
> >>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> >>> index e988c81..7fb16bc 100644
> >>> --- a/drivers/thermal/Kconfig
> >>> +++ b/drivers/thermal/Kconfig
> >>> @@ -17,8 +17,17 @@ if THERMAL
> >>>
> >>>  config THERMAL_HW

RE: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file

[R, Durgadoss]

Hi Wei,

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Wei Ni
 Sent: Wednesday, July 17, 2013 3:19 PM
 To: Eduardo Valentin
 Cc: R, Durgadoss; linux...@vger.kernel.org; amit.dan...@samsung.com; Zhang,
 Rui; linux-kernel@vger.kernel.org
 Subject: Re: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single
 file
 
 On 07/10/2013 12:54 AM, Eduardo Valentin wrote:
  * PGP Signed: 07/09/2013 at 09:54:04 AM
 
  On 09-07-2013 12:04, R, Durgadoss wrote:
  Hi Eduardo,
 
  -Original Message-
  From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
  ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
  Sent: Tuesday, July 09, 2013 7:30 PM
  To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
  Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
  Subject: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single
 file
 
  In order to improve code organization, this patch
  moves the hwmon sysfs support to a file named
  thermal_hwmon. This helps to add extra support
  for hwmon without scrambling the code.
 
  Nice clean up for thermal_core.c. +1 from me.
 
  I am inclined to even remove the hwmon related code completely.
  AFAIK, there are not many users of this config option.
 
 
  Hmm. OK. I thought of keeping it as I dont know if there are users.
  Besides, if new code comes out of the hwmon2thermalfw exercise, then it
  would be a good place to keep all the hwmon code.
 
  However people are looking for the other option. If they have a
  hwmon driver, how can it use the thermal framework with ease.
  [like what you mentioned about this in 0/5]
 
 Yes, I'm trying to add lm90 driver to the thermal framework, but this
 driver already register as a hwmon device, so when register as thermal
 zone device, the thermal framework will register another virtual hwmon
 device, it mean we have duplicate hwmon devices, it will make confusion.
 How about to add a flag in the thermal_zone_params, so when call
 thermal_zone_device_register() to register, this flag can indicate if we
 want to register the virtual hwmon device or not.

I was following your threads in both lm-sensors and here.
I tend to agree with adding this flag in tzp structure.

But, we don't have tzp defined for all thermal zones
that are registering today. So, we need to define the default behavior.
I suggest we set the default to 'No', meaning 'do not create hwmon
devices when this zone is registered'.

Thanks,
Durga

 
 Thanks.
 Wei.
 
 
  yes, problem is that hwmon does not have a standard way of representing
  the drivers. So, one cannot simply write a simple wrapper because hwmon
  drivers does not have a standard get_temperature operation, for instance.
 
  We could either propose a way to standardize then or implement the call
  to thermal fw driver by driver. Probably the later is desirable, if we
  implement it in a need basis.
 
 
  Thanks,
  Durga
 
 
  In order to do this move, the hwmon list head is now
  using its own locking. Before, the list used
  the global thermal locking.
 
  Cc: Zhang Rui rui.zh...@intel.com
  Cc: linux...@vger.kernel.org
  Cc: linux-kernel@vger.kernel.org
  Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
  ---
   drivers/thermal/Kconfig |   9 ++
   drivers/thermal/Makefile|   3 +
   drivers/thermal/thermal_core.c  | 255 
  +-
   drivers/thermal/thermal_hwmon.c | 268
  
   drivers/thermal/thermal_hwmon.h |  49 
   5 files changed, 330 insertions(+), 254 deletions(-)
   create mode 100644 drivers/thermal/thermal_hwmon.c
   create mode 100644 drivers/thermal/thermal_hwmon.h
 
  diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
  index e988c81..7fb16bc 100644
  --- a/drivers/thermal/Kconfig
  +++ b/drivers/thermal/Kconfig
  @@ -17,8 +17,17 @@ if THERMAL
 
   config THERMAL_HWMON
   bool
  +prompt Expose thermal sensors as hwmon device
   depends on HWMON=y || HWMON=THERMAL
   default y
  +help
  +  In case a sensor is registered with the thermal
  +  framework, this option will also register it
  +  as a hwmon. The sensor will then have the common
  +  hwmon sysfs interface.
  +
  +  Say 'Y' here if you want all thermal sensors to
  +  have hwmon sysfs interface too.
 
   choice
   prompt Default Thermal governor
  diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
  index 67184a2..24cb894 100644
  --- a/drivers/thermal/Makefile
  +++ b/drivers/thermal/Makefile
  @@ -5,6 +5,9 @@
   obj-$(CONFIG_THERMAL)   += thermal_sys.o
   thermal_sys-y   += thermal_core.o
 
  +# interface to/from other layers providing sensors
  +thermal_sys-$(CONFIG_THERMAL_HWMON) += thermal_hwmon.o
  +
   # governors
   thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)+= fair_share.o
   thermal_sys

RE: [lm-sensors] [RESEND PATCH V1 3/9] thermal: thermal_core: allow binding with limits on bind_params

[R, Durgadoss]

 -Original Message-
 From: lm-sensors-boun...@lm-sensors.org [mailto:lm-sensors-bounces@lm-
 sensors.org] On Behalf Of Eduardo Valentin
 Sent: Wednesday, July 17, 2013 8:47 PM
 To: devicetree-disc...@lists.ozlabs.org
 Cc: w...@nvidia.com; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 lm-sens...@lm-sensors.org; Eduardo Valentin; Zhang, Rui;
 l.st...@pengutronix.de
 Subject: [lm-sensors] [RESEND PATCH V1 3/9] thermal: thermal_core: allow
 binding with limits on bind_params
 
 When registering a thermal zone device using platform information
 via bind_params, the thermal framework will always perform the
 cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).
 
 This patch changes the data structures so that it is possible
 to inform what are the desired limits for each trip point
 inside a bind_param. The way the binding is performed is also
 changed so that it uses the new data structure.
 
 Cc: Zhang Rui rui.zh...@intel.com
 Cc: linux...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com

This patch looks good to me.
Acked-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

 ---
  Documentation/thermal/sysfs-api.txt |  7 +++
  drivers/thermal/thermal_core.c  | 19 +++
  include/linux/thermal.h | 10 ++
  3 files changed, 32 insertions(+), 4 deletions(-)
 
 diff --git a/Documentation/thermal/sysfs-api.txt
 b/Documentation/thermal/sysfs-api.txt
 index a71bd5b..2ad50e7 100644
 --- a/Documentation/thermal/sysfs-api.txt
 +++ b/Documentation/thermal/sysfs-api.txt
 @@ -134,6 +134,13 @@ temperature) and throttle appropriate devices.
 this thermal zone and cdev, for a particular trip point.
 If nth bit is set, then the cdev and thermal zone are bound
 for trip point n.
 +.limits: This is an array of cooling state limits. Must have exactly
 + 2 * thermal_zone.number_of_trip_points. It is an array consisting
 + of tuples lower-state upper-state of state limits. Each trip
 + will be associated with one state limit tuple when binding.
 + A NULL pointer means THERMAL_NO_LIMITS THERMAL_NO_LIMITS
 + on all trips. These limits are used when binding a cdev to a
 + trip point.
  .match: This call back returns success(0) if the 'tz and cdev' need to
   be bound, as per platform data.
  1.4.2 struct thermal_zone_params
 diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
 index 247528b..096c8be 100644
 --- a/drivers/thermal/thermal_core.c
 +++ b/drivers/thermal/thermal_core.c
 @@ -202,14 +202,23 @@ static void print_bind_err_msg(struct
 thermal_zone_device *tz,
  }
 
  static void __bind(struct thermal_zone_device *tz, int mask,
 - struct thermal_cooling_device *cdev)
 + struct thermal_cooling_device *cdev,
 + unsigned long *limits)
  {
   int i, ret;
 
   for (i = 0; i  tz-trips; i++) {
   if (mask  (1  i)) {
 + unsigned long upper, lower;
 +
 + upper = THERMAL_NO_LIMIT;
 + lower = THERMAL_NO_LIMIT;
 + if (limits) {
 + lower = limits[i * 2];
 + upper = limits[i * 2 + 1];
 + }
   ret = thermal_zone_bind_cooling_device(tz, i, cdev,
 - THERMAL_NO_LIMIT,
 THERMAL_NO_LIMIT);
 +upper, lower);
   if (ret)
   print_bind_err_msg(tz, cdev, ret);
   }
 @@ -254,7 +263,8 @@ static void bind_cdev(struct thermal_cooling_device
 *cdev)
   if (tzp-tbp[i].match(pos, cdev))
   continue;
   tzp-tbp[i].cdev = cdev;
 - __bind(pos, tzp-tbp[i].trip_mask, cdev);
 + __bind(pos, tzp-tbp[i].trip_mask, cdev,
 +tzp-tbp[i].binding_limits);
   }
   }
 
 @@ -292,7 +302,8 @@ static void bind_tz(struct thermal_zone_device *tz)
   if (tzp-tbp[i].match(tz, pos))
   continue;
   tzp-tbp[i].cdev = pos;
 - __bind(tz, tzp-tbp[i].trip_mask, pos);
 + __bind(tz, tzp-tbp[i].trip_mask, pos,
 +tzp-tbp[i].binding_limits);
   }
   }
  exit:
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index a386a1c..39575eb 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -207,6 +207,16 @@ struct thermal_bind_params {
* See Documentation/thermal/sysfs-api.txt for more information.
*/
   int trip_mask;
 +
 + /*
 +  * This is an array of cooling state 

RE: [lm-sensors] [RESEND PATCH V1 2/9] thermal: hwmon: move hwmon support to single file

[R, Durgadoss]

 -Original Message-
 From: lm-sensors-boun...@lm-sensors.org [mailto:lm-sensors-bounces@lm-
 sensors.org] On Behalf Of Eduardo Valentin
 Sent: Wednesday, July 17, 2013 8:47 PM
 To: devicetree-disc...@lists.ozlabs.org
 Cc: w...@nvidia.com; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 lm-sens...@lm-sensors.org; Eduardo Valentin; Zhang, Rui;
 l.st...@pengutronix.de
 Subject: [lm-sensors] [RESEND PATCH V1 2/9] thermal: hwmon: move hwmon
 support to single file
 
 In order to improve code organization, this patch
 moves the hwmon sysfs support to a file named
 thermal_hwmon. This helps to add extra support
 for hwmon without scrambling the code.
 
 In order to do this move, the hwmon list head is now
 using its own locking. Before, the list used
 the global thermal locking. Also, some minor changes
 in the code were required, as recommended by checkpatch.pl.
 
 Cc: Zhang Rui rui.zh...@intel.com
 Cc: linux...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com

Went through the patch, looks fine. Nice clean up Eduardo!!

Acked-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

 ---
  drivers/thermal/Kconfig |   9 ++
  drivers/thermal/Makefile|   3 +
  drivers/thermal/thermal_core.c  | 255 +
  drivers/thermal/thermal_hwmon.c | 269
 
  drivers/thermal/thermal_hwmon.h |  49 
  5 files changed, 331 insertions(+), 254 deletions(-)
  create mode 100644 drivers/thermal/thermal_hwmon.c
  create mode 100644 drivers/thermal/thermal_hwmon.h
 
 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index e988c81..7fb16bc 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -17,8 +17,17 @@ if THERMAL
 
  config THERMAL_HWMON
   bool
 + prompt Expose thermal sensors as hwmon device
   depends on HWMON=y || HWMON=THERMAL
   default y
 + help
 +   In case a sensor is registered with the thermal
 +   framework, this option will also register it
 +   as a hwmon. The sensor will then have the common
 +   hwmon sysfs interface.
 +
 +   Say 'Y' here if you want all thermal sensors to
 +   have hwmon sysfs interface too.
 
  choice
   prompt Default Thermal governor
 diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
 index 67184a2..24cb894 100644
 --- a/drivers/thermal/Makefile
 +++ b/drivers/thermal/Makefile
 @@ -5,6 +5,9 @@
  obj-$(CONFIG_THERMAL)+= thermal_sys.o
  thermal_sys-y+= thermal_core.o
 
 +# interface to/from other layers providing sensors
 +thermal_sys-$(CONFIG_THERMAL_HWMON)  += thermal_hwmon.o
 +
  # governors
  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
  thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)  += step_wise.o
 diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
 index 1f02e8e..247528b 100644
 --- a/drivers/thermal/thermal_core.c
 +++ b/drivers/thermal/thermal_core.c
 @@ -38,6 +38,7 @@
  #include net/genetlink.h
 
  #include thermal_core.h
 +#include thermal_hwmon.h
 
  MODULE_AUTHOR(Zhang Rui);
  MODULE_DESCRIPTION(Generic thermal management sysfs support);
 @@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device
 *dev,
 
  /* Device management */
 
 -#if defined(CONFIG_THERMAL_HWMON)
 -
 -/* hwmon sys I/F */
 -#include linux/hwmon.h
 -
 -/* thermal zone devices with the same type share one hwmon device */
 -struct thermal_hwmon_device {
 - char type[THERMAL_NAME_LENGTH];
 - struct device *device;
 - int count;
 - struct list_head tz_list;
 - struct list_head node;
 -};
 -
 -struct thermal_hwmon_attr {
 - struct device_attribute attr;
 - char name[16];
 -};
 -
 -/* one temperature input for each thermal zone */
 -struct thermal_hwmon_temp {
 - struct list_head hwmon_node;
 - struct thermal_zone_device *tz;
 - struct thermal_hwmon_attr temp_input;   /* hwmon sys attr */
 - struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
 -};
 -
 -static LIST_HEAD(thermal_hwmon_list);
 -
 -static ssize_t
 -name_show(struct device *dev, struct device_attribute *attr, char *buf)
 -{
 - struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
 - return sprintf(buf, %s\n, hwmon-type);
 -}
 -static DEVICE_ATTR(name, 0444, name_show, NULL);
 -
 -static ssize_t
 -temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
 -{
 - long temperature;
 - int ret;
 - struct thermal_hwmon_attr *hwmon_attr
 - = container_of(attr, struct thermal_hwmon_attr, attr);
 - struct thermal_hwmon_temp *temp
 - = container_of(hwmon_attr, struct
 thermal_hwmon_temp,
 -temp_input);
 - struct thermal_zone_device *tz = temp-tz;
 -
 - ret = thermal_zone_get_temp(tz, temperature);
 -
 - if (ret)
 -   

RE: [RFC PATCH 2/4] thermal: introduce device tree parser

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Monday, July 15, 2013 5:25 PM
> To: Wei Ni
> Cc: Eduardo Valentin; linux...@vger.kernel.org; R, Durgadoss;
> amit.dan...@samsung.com; Zhang, Rui; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 2/4] thermal: introduce device tree parser
> 
> On 10-07-2013 02:48, Wei Ni wrote:
> > On 07/09/2013 10:00 PM, Eduardo Valentin wrote:
> >> In order to be able to build thermal policies
> >> based on generic sensors, like I2C device, that
> >> can be places in different points on different boards,
> >> there is a need to have a way to feed board dependent
> >> data into the thermal framework.
> >>
> >> This patch introduces a thermal data parser for device
> >> tree. The parsed data is used to build thermal zones
> >> and thermal binding parameters. The output data
> >> can then be used to deploy thermal policies.
> >>
> >> This patch adds also documentation regarding this
> >> API and how to define define tree nodes to use
> >> this infrastructure.
> >
> > It looks good, with this infrastructure, we can add generic sensor
> > driver into the thermal fw easily.
> >
> >
> >> +
> >> +Below is an example:
> >> +thermal_zone {
> >> +type = "CPU";
> >> +mask = <0x03>; /* trips writability */
> >> +passive_delay = <250>; /* milliseconds */
> >> +polling_delay = <1000>; /* milliseconds */
> >> +governor = "step_wise";
> >> +trips {
> >> +alert@10{
> >> +temperature = <10>; /* milliCelsius */
> >> +hysteresis = <0>; /* milliCelsius */
> >> +type = <1>;
> >
> > how about to use the trip type name directly, such as named as
> > "passive-trip;", I think it's more readable. for example:
> > trip0 {
> > 
> > passive-trip;
> > }
> > trip1 {
> > 
> > active-trip;
> > }
> >
> >> +};
> >> +crit@125000{
> >> +temperature = <125000>; /* milliCelsius */
> >> +hysteresis = <0>; /* milliCelsius */
> >> +type = <3>;
> >> +};
> >> +};
> >> +bind_params {
> >> +action@0{
> >> +cooling_device = "thermal-cpufreq";
> >> +weight = <100>; /* percentage */
> >> +mask = <0x01>;
> >> +};
> >> +};
> >> +};
> >
> > as we know, thermal_zone_bind_cooling_device() will set the upper/lower
> > in the thermal_instance. In the default .bind function, it just set to
> > THERMAL_NO_LIMIT, but for some platform, it need to set these
> > upper/lower values for different cooling device and trips, how to pass
> > these values in DT? how about to set:
> > action@0 {
> > ...
> > mask = <0x03>; //or you can remove this property;
> 
> Well, this has been added accordingly to current API needs.
> 
> > trip0 = < 1 2>; //1 is lower value, 2 is upper value;
> > trip1 = < 3 4>;
> 
> I suppose the first item in you 3-tuple is the trip point.
> 
> > }
> 
> Yeah, I also noticed that I was missing the upper and lower limits. But
> unfortunately this is a limitation on the thermal FW API too!
> 
> If one passes a bind params, the structure which represents platform
> info, then it won't be able to pass the upper and lower limits. But by
> passing a .bind callback, then you have the opportunity to match it
> using these two values.
> 
> I believe we would need to change the data structures and the API to
> support upper and lower limits via platform representation. We could
> simply use the .bind callback of the dt thermal zone, but I believe that
> would abusing the API, assuming that .match is for platform binding.
> Durga, what do you think?

okay, I see.. Two approaches I could think of:
1. Introduce two arrays (size = number of trips in the tz) named
upper/lower_limits[size] in the 'thermal_bind_params' structure.
This way we don't need any API change. We can slightly cha

RE: [RFC PATCH 2/4] thermal: introduce device tree parser

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
 Sent: Monday, July 15, 2013 5:25 PM
 To: Wei Ni
 Cc: Eduardo Valentin; linux...@vger.kernel.org; R, Durgadoss;
 amit.dan...@samsung.com; Zhang, Rui; linux-kernel@vger.kernel.org
 Subject: Re: [RFC PATCH 2/4] thermal: introduce device tree parser
 
 On 10-07-2013 02:48, Wei Ni wrote:
  On 07/09/2013 10:00 PM, Eduardo Valentin wrote:
  In order to be able to build thermal policies
  based on generic sensors, like I2C device, that
  can be places in different points on different boards,
  there is a need to have a way to feed board dependent
  data into the thermal framework.
 
  This patch introduces a thermal data parser for device
  tree. The parsed data is used to build thermal zones
  and thermal binding parameters. The output data
  can then be used to deploy thermal policies.
 
  This patch adds also documentation regarding this
  API and how to define define tree nodes to use
  this infrastructure.
 
  It looks good, with this infrastructure, we can add generic sensor
  driver into the thermal fw easily.
 
 
  +
  +Below is an example:
  +thermal_zone {
  +type = CPU;
  +mask = 0x03; /* trips writability */
  +passive_delay = 250; /* milliseconds */
  +polling_delay = 1000; /* milliseconds */
  +governor = step_wise;
  +trips {
  +alert@10{
  +temperature = 10; /* milliCelsius */
  +hysteresis = 0; /* milliCelsius */
  +type = 1;
 
  how about to use the trip type name directly, such as named as
  passive-trip;, I think it's more readable. for example:
  trip0 {
  
  passive-trip;
  }
  trip1 {
  
  active-trip;
  }
 
  +};
  +crit@125000{
  +temperature = 125000; /* milliCelsius */
  +hysteresis = 0; /* milliCelsius */
  +type = 3;
  +};
  +};
  +bind_params {
  +action@0{
  +cooling_device = thermal-cpufreq;
  +weight = 100; /* percentage */
  +mask = 0x01;
  +};
  +};
  +};
 
  as we know, thermal_zone_bind_cooling_device() will set the upper/lower
  in the thermal_instance. In the default .bind function, it just set to
  THERMAL_NO_LIMIT, but for some platform, it need to set these
  upper/lower values for different cooling device and trips, how to pass
  these values in DT? how about to set:
  action@0 {
  ...
  mask = 0x03; //or you can remove this property;
 
 Well, this has been added accordingly to current API needs.
 
  trip0 = alert 1 2; //1 is lower value, 2 is upper value;
  trip1 = crit 3 4;
 
 I suppose the first item in you 3-tuple is the trip point.
 
  }
 
 Yeah, I also noticed that I was missing the upper and lower limits. But
 unfortunately this is a limitation on the thermal FW API too!
 
 If one passes a bind params, the structure which represents platform
 info, then it won't be able to pass the upper and lower limits. But by
 passing a .bind callback, then you have the opportunity to match it
 using these two values.
 
 I believe we would need to change the data structures and the API to
 support upper and lower limits via platform representation. We could
 simply use the .bind callback of the dt thermal zone, but I believe that
 would abusing the API, assuming that .match is for platform binding.
 Durga, what do you think?

okay, I see.. Two approaches I could think of:
1. Introduce two arrays (size = number of trips in the tz) named
upper/lower_limits[size] in the 'thermal_bind_params' structure.
This way we don't need any API change. We can slightly change the
implementation inside '__bind' function in thermal_core.c to get this
working.

2. Pass 3 more parameters in the .match function:
.match(tz, cdev, trip, lower, upper). The platform layer
then determines whether there is a match; and if so,
provides sane values for lower and upper variables.

At this point of time, I think I prefer method 1 ;)
Let me know your thoughts.

Thanks,
Durga
 
 
 
 
  Thanks.
  Wei.
 
 
 
 
 
 --
 You have got to be excited about what you are doing. (L. Lamport)
 
 Eduardo Valentin

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Tuesday, July 09, 2013 10:24 PM
> To: R, Durgadoss
> Cc: Eduardo Valentin; linux...@vger.kernel.org; amit.dan...@samsung.com;
> Zhang, Rui; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single
> file
> 
> On 09-07-2013 12:04, R, Durgadoss wrote:
> > Hi Eduardo,
> >
> >> -Original Message-
> >> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> >> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> >> Sent: Tuesday, July 09, 2013 7:30 PM
> >> To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
> >> Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
> >> Subject: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file
> >>
> >> In order to improve code organization, this patch
> >> moves the hwmon sysfs support to a file named
> >> thermal_hwmon. This helps to add extra support
> >> for hwmon without scrambling the code.
> >
> > Nice clean up for thermal_core.c. +1 from me.
> >
> > I am inclined to even remove the hwmon related code completely.
> > AFAIK, there are not many users of this config option.
> >
> 
> Hmm. OK. I thought of keeping it as I dont know if there are users.

Yes. This is fine for now.

> Besides, if new code comes out of the hwmon2thermalfw exercise, then it
> would be a good place to keep all the hwmon code.
> 
> > However people are looking for the other option. If they have a
> > hwmon driver, how can it use the thermal framework with ease.
> > [like what you mentioned about this in 0/5]
> 
> yes, problem is that hwmon does not have a standard way of representing
> the drivers. So, one cannot simply write a simple wrapper because hwmon
> drivers does not have a standard get_temperature operation, for instance.
> 
> We could either propose a way to standardize then or implement the call
> to thermal fw driver by driver. Probably the later is desirable, if we
> implement it in a need basis.

later is desirable: Agreed.

Thanks,
Durga

> 
> >
> > Thanks,
> > Durga
> >
> >>
> >> In order to do this move, the hwmon list head is now
> >> using its own locking. Before, the list used
> >> the global thermal locking.
> >>
> >> Cc: Zhang Rui 
> >> Cc: linux...@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Signed-off-by: Eduardo Valentin 
> >> ---
> >>  drivers/thermal/Kconfig |   9 ++
> >>  drivers/thermal/Makefile|   3 +
> >>  drivers/thermal/thermal_core.c  | 255 
> >> +-
> >>  drivers/thermal/thermal_hwmon.c | 268
> >> 
> >>  drivers/thermal/thermal_hwmon.h |  49 
> >>  5 files changed, 330 insertions(+), 254 deletions(-)
> >>  create mode 100644 drivers/thermal/thermal_hwmon.c
> >>  create mode 100644 drivers/thermal/thermal_hwmon.h
> >>
> >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> >> index e988c81..7fb16bc 100644
> >> --- a/drivers/thermal/Kconfig
> >> +++ b/drivers/thermal/Kconfig
> >> @@ -17,8 +17,17 @@ if THERMAL
> >>
> >>  config THERMAL_HWMON
> >>bool
> >> +  prompt "Expose thermal sensors as hwmon device"
> >>depends on HWMON=y || HWMON=THERMAL
> >>default y
> >> +  help
> >> +In case a sensor is registered with the thermal
> >> +framework, this option will also register it
> >> +as a hwmon. The sensor will then have the common
> >> +hwmon sysfs interface.
> >> +
> >> +Say 'Y' here if you want all thermal sensors to
> >> +have hwmon sysfs interface too.
> >>
> >>  choice
> >>prompt "Default Thermal governor"
> >> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> >> index 67184a2..24cb894 100644
> >> --- a/drivers/thermal/Makefile
> >> +++ b/drivers/thermal/Makefile
> >> @@ -5,6 +5,9 @@
> >>  obj-$(CONFIG_THERMAL) += thermal_sys.o
> >>  thermal_sys-y += thermal_core.o
> >>
> >> +# interface to/from other layers providing sensors
> >> +thermal_sys-$(CONFIG_THERMAL_HWMON)   +=
> thermal_hwmon.o
> >> +
> >>  # governo

RE: [RFC PATCH 2/4] thermal: introduce device tree parser

[R, Durgadoss]

Hi Eduardo,

> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> Sent: Tuesday, July 09, 2013 7:30 PM
> To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
> Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
> Subject: [RFC PATCH 2/4] thermal: introduce device tree parser
> 
> In order to be able to build thermal policies
> based on generic sensors, like I2C device, that
> can be places in different points on different boards,
> there is a need to have a way to feed board dependent
> data into the thermal framework.
> 
> This patch introduces a thermal data parser for device
> tree. The parsed data is used to build thermal zones
> and thermal binding parameters. The output data
> can then be used to deploy thermal policies.
> 
> This patch adds also documentation regarding this
> API and how to define define tree nodes to use
> this infrastructure.
> 
> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---

I looked at the Documentation part of this. And it looks good.

At some places you are using ERANGE. Technically, this represents
'Math result not representable'. May be should be use EINVAL 
itself ? I would leave it up to you ;)

Thanks,
Durga

>  .../devicetree/bindings/thermal/thermal.txt|  92 +
>  drivers/thermal/Kconfig|  13 +
>  drivers/thermal/Makefile   |   1 +
>  drivers/thermal/thermal_dt.c   | 412 
> +
>  drivers/thermal/thermal_dt.h   |  44 +++
>  include/linux/thermal.h|   3 +
>  6 files changed, 565 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>  create mode 100644 drivers/thermal/thermal_dt.c
>  create mode 100644 drivers/thermal/thermal_dt.h
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
> b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 000..2c25ab2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,92 @@
> +
> +Thermal Framework Device Tree descriptor
> +
> +
> +This file describes how to define a thermal structure using device tree.
> +A thermal structure includes thermal zones and their components, such
> +as name, governor, trip points, polling intervals and cooling devices
> +binding descriptors. A binding descriptor may contain information on
> +how to react, with a cooling stepped action or a weight on a fair share.
> +
> +
> +trip
> +
> +
> +The trip node is a node to describe a point in the temperature domain
> +in which the system takes an action. This node describes just the point,
> +not the action.
> +
> +A node describing a trip must contain:
> +- temperature: the trip temperature level, in milliCelsius.
> +- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative
> +value, in milliCelsius.
> +- type: the trip type. Here is the type mapping:
> + THERMAL_TRIP_ACTIVE = 0
> + THERMAL_TRIP_PASSIVE = 1
> + THERMAL_TRIP_HOT = 2
> + THERMAL_TRIP_CRITICAL = 3
> +
> +**
> +bind_param
> +**
> +
> +The bind_param node is a node to describe how cooling devices get assigned
> +to trip points of the zone. The cooling devices are expected to be loaded
> +in the target system.
> +
> +A node describing a bind_param must contain:
> +- cooling_device: A string with the cooling device name.
> +- weight: The 'influence' of a particular cooling device on this zone.
> + This is on a percentage scale. The sum of all these weights
> + (for a particular zone) cannot exceed 100.
> +- trip_mask: This is a bit mask that gives the binding relation between
> +   this thermal zone and cdev, for a particular trip point.
> +   If nth bit is set, then the cdev and thermal zone are bound
> +   for trip point n.
> +
> +
> +thermal_zone
> +
> +
> +The thermal_zone node is the node containing all the required info
> +for describing a thermal zone, including its cdev bindings. The thermal_zone
> +node must contain, apart from its own properties, one node containing
> +trip nodes and one node containing all the zone bind parameters.
> +
> +Required properties:
> +- type: this is a string containing the zone type. Say 'cpu', 'core', 'mem', 
> etc.
> +- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
> +
> +- passiv

RE: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file

[R, Durgadoss]

Hi Eduardo,

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Tuesday, July 09, 2013 7:30 PM
> To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
> Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
> Subject: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file
> 
> In order to improve code organization, this patch
> moves the hwmon sysfs support to a file named
> thermal_hwmon. This helps to add extra support
> for hwmon without scrambling the code.

Nice clean up for thermal_core.c. +1 from me.

I am inclined to even remove the hwmon related code completely.
AFAIK, there are not many users of this config option.

However people are looking for the other option. If they have a
hwmon driver, how can it use the thermal framework with ease.
[like what you mentioned about this in 0/5]

Thanks,
Durga

> 
> In order to do this move, the hwmon list head is now
> using its own locking. Before, the list used
> the global thermal locking.
> 
> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/Kconfig |   9 ++
>  drivers/thermal/Makefile|   3 +
>  drivers/thermal/thermal_core.c  | 255 +-
>  drivers/thermal/thermal_hwmon.c | 268
> 
>  drivers/thermal/thermal_hwmon.h |  49 
>  5 files changed, 330 insertions(+), 254 deletions(-)
>  create mode 100644 drivers/thermal/thermal_hwmon.c
>  create mode 100644 drivers/thermal/thermal_hwmon.h
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index e988c81..7fb16bc 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -17,8 +17,17 @@ if THERMAL
> 
>  config THERMAL_HWMON
>   bool
> + prompt "Expose thermal sensors as hwmon device"
>   depends on HWMON=y || HWMON=THERMAL
>   default y
> + help
> +   In case a sensor is registered with the thermal
> +   framework, this option will also register it
> +   as a hwmon. The sensor will then have the common
> +   hwmon sysfs interface.
> +
> +   Say 'Y' here if you want all thermal sensors to
> +   have hwmon sysfs interface too.
> 
>  choice
>   prompt "Default Thermal governor"
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 67184a2..24cb894 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -5,6 +5,9 @@
>  obj-$(CONFIG_THERMAL)+= thermal_sys.o
>  thermal_sys-y+= thermal_core.o
> 
> +# interface to/from other layers providing sensors
> +thermal_sys-$(CONFIG_THERMAL_HWMON)  += thermal_hwmon.o
> +
>  # governors
>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
>  thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)  += step_wise.o
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 1f02e8e..247528b 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -38,6 +38,7 @@
>  #include 
> 
>  #include "thermal_core.h"
> +#include "thermal_hwmon.h"
> 
>  MODULE_AUTHOR("Zhang Rui");
>  MODULE_DESCRIPTION("Generic thermal management sysfs support");
> @@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device
> *dev,
> 
>  /* Device management */
> 
> -#if defined(CONFIG_THERMAL_HWMON)
> -
> -/* hwmon sys I/F */
> -#include 
> -
> -/* thermal zone devices with the same type share one hwmon device */
> -struct thermal_hwmon_device {
> - char type[THERMAL_NAME_LENGTH];
> - struct device *device;
> - int count;
> - struct list_head tz_list;
> - struct list_head node;
> -};
> -
> -struct thermal_hwmon_attr {
> - struct device_attribute attr;
> - char name[16];
> -};
> -
> -/* one temperature input for each thermal zone */
> -struct thermal_hwmon_temp {
> - struct list_head hwmon_node;
> - struct thermal_zone_device *tz;
> - struct thermal_hwmon_attr temp_input;   /* hwmon sys attr */
> - struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
> -};
> -
> -static LIST_HEAD(thermal_hwmon_list);
> -
> -static ssize_t
> -name_show(struct device *dev, struct device_attribute *attr, char *buf)
> -{
> - struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
> - return sprintf(buf, "%s\n", hwmon->type);
> -}
> -static 

RE: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file

[R, Durgadoss]

Hi Eduardo,

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
 Sent: Tuesday, July 09, 2013 7:30 PM
 To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
 Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
 Subject: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file
 
 In order to improve code organization, this patch
 moves the hwmon sysfs support to a file named
 thermal_hwmon. This helps to add extra support
 for hwmon without scrambling the code.

Nice clean up for thermal_core.c. +1 from me.

I am inclined to even remove the hwmon related code completely.
AFAIK, there are not many users of this config option.

However people are looking for the other option. If they have a
hwmon driver, how can it use the thermal framework with ease.
[like what you mentioned about this in 0/5]

Thanks,
Durga

 
 In order to do this move, the hwmon list head is now
 using its own locking. Before, the list used
 the global thermal locking.
 
 Cc: Zhang Rui rui.zh...@intel.com
 Cc: linux...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  drivers/thermal/Kconfig |   9 ++
  drivers/thermal/Makefile|   3 +
  drivers/thermal/thermal_core.c  | 255 +-
  drivers/thermal/thermal_hwmon.c | 268
 
  drivers/thermal/thermal_hwmon.h |  49 
  5 files changed, 330 insertions(+), 254 deletions(-)
  create mode 100644 drivers/thermal/thermal_hwmon.c
  create mode 100644 drivers/thermal/thermal_hwmon.h
 
 diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
 index e988c81..7fb16bc 100644
 --- a/drivers/thermal/Kconfig
 +++ b/drivers/thermal/Kconfig
 @@ -17,8 +17,17 @@ if THERMAL
 
  config THERMAL_HWMON
   bool
 + prompt Expose thermal sensors as hwmon device
   depends on HWMON=y || HWMON=THERMAL
   default y
 + help
 +   In case a sensor is registered with the thermal
 +   framework, this option will also register it
 +   as a hwmon. The sensor will then have the common
 +   hwmon sysfs interface.
 +
 +   Say 'Y' here if you want all thermal sensors to
 +   have hwmon sysfs interface too.
 
  choice
   prompt Default Thermal governor
 diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
 index 67184a2..24cb894 100644
 --- a/drivers/thermal/Makefile
 +++ b/drivers/thermal/Makefile
 @@ -5,6 +5,9 @@
  obj-$(CONFIG_THERMAL)+= thermal_sys.o
  thermal_sys-y+= thermal_core.o
 
 +# interface to/from other layers providing sensors
 +thermal_sys-$(CONFIG_THERMAL_HWMON)  += thermal_hwmon.o
 +
  # governors
  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
  thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)  += step_wise.o
 diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
 index 1f02e8e..247528b 100644
 --- a/drivers/thermal/thermal_core.c
 +++ b/drivers/thermal/thermal_core.c
 @@ -38,6 +38,7 @@
  #include net/genetlink.h
 
  #include thermal_core.h
 +#include thermal_hwmon.h
 
  MODULE_AUTHOR(Zhang Rui);
  MODULE_DESCRIPTION(Generic thermal management sysfs support);
 @@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device
 *dev,
 
  /* Device management */
 
 -#if defined(CONFIG_THERMAL_HWMON)
 -
 -/* hwmon sys I/F */
 -#include linux/hwmon.h
 -
 -/* thermal zone devices with the same type share one hwmon device */
 -struct thermal_hwmon_device {
 - char type[THERMAL_NAME_LENGTH];
 - struct device *device;
 - int count;
 - struct list_head tz_list;
 - struct list_head node;
 -};
 -
 -struct thermal_hwmon_attr {
 - struct device_attribute attr;
 - char name[16];
 -};
 -
 -/* one temperature input for each thermal zone */
 -struct thermal_hwmon_temp {
 - struct list_head hwmon_node;
 - struct thermal_zone_device *tz;
 - struct thermal_hwmon_attr temp_input;   /* hwmon sys attr */
 - struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
 -};
 -
 -static LIST_HEAD(thermal_hwmon_list);
 -
 -static ssize_t
 -name_show(struct device *dev, struct device_attribute *attr, char *buf)
 -{
 - struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
 - return sprintf(buf, %s\n, hwmon-type);
 -}
 -static DEVICE_ATTR(name, 0444, name_show, NULL);
 -
 -static ssize_t
 -temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
 -{
 - long temperature;
 - int ret;
 - struct thermal_hwmon_attr *hwmon_attr
 - = container_of(attr, struct thermal_hwmon_attr, attr);
 - struct thermal_hwmon_temp *temp
 - = container_of(hwmon_attr, struct
 thermal_hwmon_temp,
 -temp_input);
 - struct thermal_zone_device *tz = temp-tz;
 -
 - ret

RE: [RFC PATCH 2/4] thermal: introduce device tree parser

[R, Durgadoss]

Hi Eduardo,

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Tuesday, July 09, 2013 7:30 PM
 To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
 Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
 Subject: [RFC PATCH 2/4] thermal: introduce device tree parser
 
 In order to be able to build thermal policies
 based on generic sensors, like I2C device, that
 can be places in different points on different boards,
 there is a need to have a way to feed board dependent
 data into the thermal framework.
 
 This patch introduces a thermal data parser for device
 tree. The parsed data is used to build thermal zones
 and thermal binding parameters. The output data
 can then be used to deploy thermal policies.
 
 This patch adds also documentation regarding this
 API and how to define define tree nodes to use
 this infrastructure.
 
 Cc: Zhang Rui rui.zh...@intel.com
 Cc: linux...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---

I looked at the Documentation part of this. And it looks good.

At some places you are using ERANGE. Technically, this represents
'Math result not representable'. May be should be use EINVAL 
itself ? I would leave it up to you ;)

Thanks,
Durga

  .../devicetree/bindings/thermal/thermal.txt|  92 +
  drivers/thermal/Kconfig|  13 +
  drivers/thermal/Makefile   |   1 +
  drivers/thermal/thermal_dt.c   | 412 
 +
  drivers/thermal/thermal_dt.h   |  44 +++
  include/linux/thermal.h|   3 +
  6 files changed, 565 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
  create mode 100644 drivers/thermal/thermal_dt.c
  create mode 100644 drivers/thermal/thermal_dt.h
 
 diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
 b/Documentation/devicetree/bindings/thermal/thermal.txt
 new file mode 100644
 index 000..2c25ab2
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
 @@ -0,0 +1,92 @@
 +
 +Thermal Framework Device Tree descriptor
 +
 +
 +This file describes how to define a thermal structure using device tree.
 +A thermal structure includes thermal zones and their components, such
 +as name, governor, trip points, polling intervals and cooling devices
 +binding descriptors. A binding descriptor may contain information on
 +how to react, with a cooling stepped action or a weight on a fair share.
 +
 +
 +trip
 +
 +
 +The trip node is a node to describe a point in the temperature domain
 +in which the system takes an action. This node describes just the point,
 +not the action.
 +
 +A node describing a trip must contain:
 +- temperature: the trip temperature level, in milliCelsius.
 +- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative
 +value, in milliCelsius.
 +- type: the trip type. Here is the type mapping:
 + THERMAL_TRIP_ACTIVE = 0
 + THERMAL_TRIP_PASSIVE = 1
 + THERMAL_TRIP_HOT = 2
 + THERMAL_TRIP_CRITICAL = 3
 +
 +**
 +bind_param
 +**
 +
 +The bind_param node is a node to describe how cooling devices get assigned
 +to trip points of the zone. The cooling devices are expected to be loaded
 +in the target system.
 +
 +A node describing a bind_param must contain:
 +- cooling_device: A string with the cooling device name.
 +- weight: The 'influence' of a particular cooling device on this zone.
 + This is on a percentage scale. The sum of all these weights
 + (for a particular zone) cannot exceed 100.
 +- trip_mask: This is a bit mask that gives the binding relation between
 +   this thermal zone and cdev, for a particular trip point.
 +   If nth bit is set, then the cdev and thermal zone are bound
 +   for trip point n.
 +
 +
 +thermal_zone
 +
 +
 +The thermal_zone node is the node containing all the required info
 +for describing a thermal zone, including its cdev bindings. The thermal_zone
 +node must contain, apart from its own properties, one node containing
 +trip nodes and one node containing all the zone bind parameters.
 +
 +Required properties:
 +- type: this is a string containing the zone type. Say 'cpu', 'core', 'mem', 
 etc.
 +- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
 +
 +- passive_delay: number of milliseconds to wait between polls when
 + performing passive cooling.
 +- polling_delay: number of milliseconds to wait between polls when checking
 +
 +- governor: A string containing the default governor for this zone.
 +
 +Below is an example:
 +thermal_zone {
 +type = CPU;
 +mask = 0x03; /* trips writability */
 +passive_delay

RE: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
 Sent: Tuesday, July 09, 2013 10:24 PM
 To: R, Durgadoss
 Cc: Eduardo Valentin; linux...@vger.kernel.org; amit.dan...@samsung.com;
 Zhang, Rui; linux-kernel@vger.kernel.org
 Subject: Re: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single
 file
 
 On 09-07-2013 12:04, R, Durgadoss wrote:
  Hi Eduardo,
 
  -Original Message-
  From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
  ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
  Sent: Tuesday, July 09, 2013 7:30 PM
  To: linux...@vger.kernel.org; R, Durgadoss; amit.dan...@samsung.com
  Cc: Zhang, Rui; Eduardo Valentin; linux-kernel@vger.kernel.org
  Subject: [RFC PATCH 1/4] thermal: hwmon: move hwmon support to single file
 
  In order to improve code organization, this patch
  moves the hwmon sysfs support to a file named
  thermal_hwmon. This helps to add extra support
  for hwmon without scrambling the code.
 
  Nice clean up for thermal_core.c. +1 from me.
 
  I am inclined to even remove the hwmon related code completely.
  AFAIK, there are not many users of this config option.
 
 
 Hmm. OK. I thought of keeping it as I dont know if there are users.

Yes. This is fine for now.

 Besides, if new code comes out of the hwmon2thermalfw exercise, then it
 would be a good place to keep all the hwmon code.
 
  However people are looking for the other option. If they have a
  hwmon driver, how can it use the thermal framework with ease.
  [like what you mentioned about this in 0/5]
 
 yes, problem is that hwmon does not have a standard way of representing
 the drivers. So, one cannot simply write a simple wrapper because hwmon
 drivers does not have a standard get_temperature operation, for instance.
 
 We could either propose a way to standardize then or implement the call
 to thermal fw driver by driver. Probably the later is desirable, if we
 implement it in a need basis.

later is desirable: Agreed.

Thanks,
Durga

 
 
  Thanks,
  Durga
 
 
  In order to do this move, the hwmon list head is now
  using its own locking. Before, the list used
  the global thermal locking.
 
  Cc: Zhang Rui rui.zh...@intel.com
  Cc: linux...@vger.kernel.org
  Cc: linux-kernel@vger.kernel.org
  Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
  ---
   drivers/thermal/Kconfig |   9 ++
   drivers/thermal/Makefile|   3 +
   drivers/thermal/thermal_core.c  | 255 
  +-
   drivers/thermal/thermal_hwmon.c | 268
  
   drivers/thermal/thermal_hwmon.h |  49 
   5 files changed, 330 insertions(+), 254 deletions(-)
   create mode 100644 drivers/thermal/thermal_hwmon.c
   create mode 100644 drivers/thermal/thermal_hwmon.h
 
  diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
  index e988c81..7fb16bc 100644
  --- a/drivers/thermal/Kconfig
  +++ b/drivers/thermal/Kconfig
  @@ -17,8 +17,17 @@ if THERMAL
 
   config THERMAL_HWMON
 bool
  +  prompt Expose thermal sensors as hwmon device
 depends on HWMON=y || HWMON=THERMAL
 default y
  +  help
  +In case a sensor is registered with the thermal
  +framework, this option will also register it
  +as a hwmon. The sensor will then have the common
  +hwmon sysfs interface.
  +
  +Say 'Y' here if you want all thermal sensors to
  +have hwmon sysfs interface too.
 
   choice
 prompt Default Thermal governor
  diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
  index 67184a2..24cb894 100644
  --- a/drivers/thermal/Makefile
  +++ b/drivers/thermal/Makefile
  @@ -5,6 +5,9 @@
   obj-$(CONFIG_THERMAL) += thermal_sys.o
   thermal_sys-y += thermal_core.o
 
  +# interface to/from other layers providing sensors
  +thermal_sys-$(CONFIG_THERMAL_HWMON)   +=
 thermal_hwmon.o
  +
   # governors
   thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)  += fair_share.o
   thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)   += step_wise.o
  diff --git a/drivers/thermal/thermal_core.c 
  b/drivers/thermal/thermal_core.c
  index 1f02e8e..247528b 100644
  --- a/drivers/thermal/thermal_core.c
  +++ b/drivers/thermal/thermal_core.c
  @@ -38,6 +38,7 @@
   #include net/genetlink.h
 
   #include thermal_core.h
  +#include thermal_hwmon.h
 
   MODULE_AUTHOR(Zhang Rui);
   MODULE_DESCRIPTION(Generic thermal management sysfs support);
  @@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct
 device
  *dev,
 
   /* Device management */
 
  -#if defined(CONFIG_THERMAL_HWMON)
  -
  -/* hwmon sys I/F */
  -#include linux/hwmon.h
  -
  -/* thermal zone devices with the same type share one hwmon device */
  -struct thermal_hwmon_device {
  -  char type[THERMAL_NAME_LENGTH];
  -  struct device *device;
  -  int count;
  -  struct list_head tz_list;
  -  struct list_head node;
  -};
  -
  -struct

RE: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature

[R, Durgadoss]

Hi Lukasz,

> -Original Message-
> From: Lukasz Majewski [mailto:l.majew...@majess.pl]
> Sent: Friday, July 05, 2013 2:28 AM
> To: R, Durgadoss
> Cc: Lukasz Majewski; Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo
> Valentin; cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; linux-kernel;
> Andre Przywara; Daniel Lezcano; Kukjin Kim; Myungjoo Ham
> Subject: Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST
> feature
> 
> On Thu, 4 Jul 2013 17:19:04 +
> "R, Durgadoss"  wrote:
> Hi,
> 

[Cut.]

> > > @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
> > > thermal_zone_device *tz)
> > >  static void handle_non_critical_trips(struct thermal_zone_device
> > > *tz, int trip, enum thermal_trip_type trip_type)
> > >  {
> > > + if (cpufreq_boost_supported()) {
> > > + tz->overheated = true;
> > > + cpufreq_boost_trigger_state(0);
> > > + if (!tz->polling_delay) {
> > > + tz->boost_polling = true;
> > > + tz->polling_delay = 1000;
> > > + }
> > > + }
> > > +
> > >   if (tz->governor)
> > >   tz->governor->throttle(tz, trip);
> > >  }
> > > @@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
> > > work_struct *work)
> > >   struct thermal_zone_device *tz = container_of(work, struct
> > > thermal_zone_device,
> > > poll_queue.work);
> > > + long trip_temp;
> > > +
> > > + if (cpufreq_boost_supported() && tz->overheated) {
> >
> > Not all thermal drivers support trip points. So, we first need a
> > if (tz->ops->get_trip_temp) check here.
> 
> Ok, thanks for tip. Bluntly speaking, I thought, that all SoCs supported
> by thermal set trip points.

We would wish to get there. But not the reality today ;)

> 
> >
> > > + tz->ops->get_trip_temp(tz, 0, _temp);
> > > + /*
> > > +  * Enable boost again only when current
> > > temperature is less
> > > +  * than 75% of trip_temp[0]
> > > +  */
> > > + if ((tz->temperature + (trip_temp >> 2)) <
> > > trip_temp) {
> >
> > Another way would be to use the get_trend APIs for this thermal zone.
> > If the trend is cooling we can re-enable boost otherwise not.
> 
> Trend evaluation seems like a good complementary idea.
> 
> However, I would also like to have the relative temperature drop
> measurement (if possible) like above (to 75% of the first trip point).
> 
> Then I would be more confident, that everything cooled down and that I
> can start boost again.
> 
> >
> > > + tz->overheated = false;
> > > + if (tz->boost_polling) {
> > > + tz->boost_polling = false;
> > > + tz->polling_delay = 0;
> > > + monitor_thermal_zone(tz);
> > > + }
> >
> > Overall, I believe this will work well only if the thermal zone is
> > CPU.
> 
> My assumption:
> 
> When I enable boost at CPU, then I also shall cool down the CPU. And
> the CPU zone seemed a natural choice.
> 
> However I might be missing something, so hints are welcome.
> 
> >
> > Another suggestion is: We tried hard to remove all throttling logic
> > from thermal_core.c.
> 
> By throttling logic you mean:
> if ((tz->temperature + (trip_temp >> 2)) and other conditions (like
> trend measurement)?

Yes. That is correct.

> 
> > May be we should include this kind of logic in
> > step_wise.c ?
> 
> It sounds interesting (since ->throttle at thermal_core.c is called
> always when needed), but I'm afraid of a code duplication when one
> use Boost with fair_share or other thermal governor.

right. So, for the time being, (as part of this patch series)
I am Okay to have this code in thermal_core.c. From the thermal
subsystem perspective, we will (need to) work out a better/
cleaner/easier approach for this later.

Thanks,
Durga

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature

[R, Durgadoss]

Hi Lukasz,

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Lukasz Majewski
> Sent: Thursday, July 04, 2013 2:20 PM
> To: Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo Valentin
> Cc: cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; Lukasz Majewski;
> l.majew...@majess.pl; linux-kernel; Andre Przywara; Daniel Lezcano; Kukjin 
> Kim;
> Myungjoo Ham
> Subject: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST
> feature
> 
> This patch provides auto disable/enable operation for boost. When any
> defined trip point is passed, the boost is disabled.
> In that moment thermal monitor workqueue is woken up and it monitors
> if the device temperature drops below 75% of the smallest trip point.
> When device cools down, the boost is enabled again.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Myungjoo Ham 
> 
> ---
> Changes for v5:
> - Move boost disable code from cpu_cooling.c to thermal_core.c
>   (to handle_non_critical_trips)
> - Extent struct thermal_zone_device by adding overheated bool flag
> - Implement auto enable of boost after device cools down
> - Introduce boost_polling flag, which indicates if thermal uses it's 
> predefined
>   pool delay or has woken up thermal workqueue only to wait until device
>   cools down.
> 
> Changes for v4:
> - New patch
> 
>  drivers/thermal/thermal_core.c |   31 +++
>  include/linux/thermal.h|2 ++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index d755440..12adbad 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
> thermal_zone_device *tz)
>  static void handle_non_critical_trips(struct thermal_zone_device *tz,
>   int trip, enum thermal_trip_type trip_type)
>  {
> + if (cpufreq_boost_supported()) {
> + tz->overheated = true;
> + cpufreq_boost_trigger_state(0);
> + if (!tz->polling_delay) {
> + tz->boost_polling = true;
> + tz->polling_delay = 1000;
> + }
> + }
> +
>   if (tz->governor)
>   tz->governor->throttle(tz, trip);
>  }
> @@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
> work_struct *work)
>   struct thermal_zone_device *tz = container_of(work, struct
> thermal_zone_device,
> poll_queue.work);
> + long trip_temp;
> +
> + if (cpufreq_boost_supported() && tz->overheated) {

Not all thermal drivers support trip points. So, we first need a
if (tz->ops->get_trip_temp) check here.

> + tz->ops->get_trip_temp(tz, 0, _temp);
> + /*
> +  * Enable boost again only when current temperature is less
> +  * than 75% of trip_temp[0]
> +  */
> + if ((tz->temperature + (trip_temp >> 2)) < trip_temp) {

Another way would be to use the get_trend APIs for this thermal zone.
If the trend is cooling we can re-enable boost otherwise not.

> + tz->overheated = false;
> + if (tz->boost_polling) {
> + tz->boost_polling = false;
> + tz->polling_delay = 0;
> + monitor_thermal_zone(tz);
> + }

Overall, I believe this will work well only if the thermal zone is CPU.

Another suggestion is: We tried hard to remove all throttling logic from
thermal_core.c. May be we should include this kind of logic in
step_wise.c ?  Rui/Eduardo: Any thoughts on this ?

Thanks,
Durga
> +
> + cpufreq_boost_trigger_state(1);
> + return;
> + }
> + }
> +
>   thermal_zone_device_update(tz);
>  }
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index a386a1c..f1aa3c2 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -172,6 +172,8 @@ struct thermal_zone_device {
>   int emul_temperature;
>   int passive;
>   unsigned int forced_passive;
> + bool overheated;
> + bool boost_polling;
>   const struct thermal_zone_device_ops *ops;
>   const struct thermal_zone_params *tzp;
>   struct thermal_governor *governor;
> --
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

RE: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature

[R, Durgadoss]

Hi Lukasz,

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Lukasz Majewski
 Sent: Thursday, July 04, 2013 2:20 PM
 To: Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo Valentin
 Cc: cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; Lukasz Majewski;
 l.majew...@majess.pl; linux-kernel; Andre Przywara; Daniel Lezcano; Kukjin 
 Kim;
 Myungjoo Ham
 Subject: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST
 feature
 
 This patch provides auto disable/enable operation for boost. When any
 defined trip point is passed, the boost is disabled.
 In that moment thermal monitor workqueue is woken up and it monitors
 if the device temperature drops below 75% of the smallest trip point.
 When device cools down, the boost is enabled again.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Myungjoo Ham myungjoo@samsung.com
 
 ---
 Changes for v5:
 - Move boost disable code from cpu_cooling.c to thermal_core.c
   (to handle_non_critical_trips)
 - Extent struct thermal_zone_device by adding overheated bool flag
 - Implement auto enable of boost after device cools down
 - Introduce boost_polling flag, which indicates if thermal uses it's 
 predefined
   pool delay or has woken up thermal workqueue only to wait until device
   cools down.
 
 Changes for v4:
 - New patch
 
  drivers/thermal/thermal_core.c |   31 +++
  include/linux/thermal.h|2 ++
  2 files changed, 33 insertions(+)
 
 diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
 index d755440..12adbad 100644
 --- a/drivers/thermal/thermal_core.c
 +++ b/drivers/thermal/thermal_core.c
 @@ -33,6 +33,7 @@
  #include linux/idr.h
  #include linux/thermal.h
  #include linux/reboot.h
 +#include linux/cpufreq.h
  #include net/netlink.h
  #include net/genetlink.h
 
 @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
 thermal_zone_device *tz)
  static void handle_non_critical_trips(struct thermal_zone_device *tz,
   int trip, enum thermal_trip_type trip_type)
  {
 + if (cpufreq_boost_supported()) {
 + tz-overheated = true;
 + cpufreq_boost_trigger_state(0);
 + if (!tz-polling_delay) {
 + tz-boost_polling = true;
 + tz-polling_delay = 1000;
 + }
 + }
 +
   if (tz-governor)
   tz-governor-throttle(tz, trip);
  }
 @@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
 work_struct *work)
   struct thermal_zone_device *tz = container_of(work, struct
 thermal_zone_device,
 poll_queue.work);
 + long trip_temp;
 +
 + if (cpufreq_boost_supported()  tz-overheated) {

Not all thermal drivers support trip points. So, we first need a
if (tz-ops-get_trip_temp) check here.

 + tz-ops-get_trip_temp(tz, 0, trip_temp);
 + /*
 +  * Enable boost again only when current temperature is less
 +  * than 75% of trip_temp[0]
 +  */
 + if ((tz-temperature + (trip_temp  2))  trip_temp) {

Another way would be to use the get_trend APIs for this thermal zone.
If the trend is cooling we can re-enable boost otherwise not.

 + tz-overheated = false;
 + if (tz-boost_polling) {
 + tz-boost_polling = false;
 + tz-polling_delay = 0;
 + monitor_thermal_zone(tz);
 + }

Overall, I believe this will work well only if the thermal zone is CPU.

Another suggestion is: We tried hard to remove all throttling logic from
thermal_core.c. May be we should include this kind of logic in
step_wise.c ?  Rui/Eduardo: Any thoughts on this ?

Thanks,
Durga
 +
 + cpufreq_boost_trigger_state(1);
 + return;
 + }
 + }
 +
   thermal_zone_device_update(tz);
  }
 
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index a386a1c..f1aa3c2 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -172,6 +172,8 @@ struct thermal_zone_device {
   int emul_temperature;
   int passive;
   unsigned int forced_passive;
 + bool overheated;
 + bool boost_polling;
   const struct thermal_zone_device_ops *ops;
   const struct thermal_zone_params *tzp;
   struct thermal_governor *governor;
 --
 1.7.10.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

RE: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature

[R, Durgadoss]

Hi Lukasz,

 -Original Message-
 From: Lukasz Majewski [mailto:l.majew...@majess.pl]
 Sent: Friday, July 05, 2013 2:28 AM
 To: R, Durgadoss
 Cc: Lukasz Majewski; Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo
 Valentin; cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; linux-kernel;
 Andre Przywara; Daniel Lezcano; Kukjin Kim; Myungjoo Ham
 Subject: Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST
 feature
 
 On Thu, 4 Jul 2013 17:19:04 +
 R, Durgadoss durgados...@intel.com wrote:
 Hi,
 

[Cut.]

   @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
   thermal_zone_device *tz)
static void handle_non_critical_trips(struct thermal_zone_device
   *tz, int trip, enum thermal_trip_type trip_type)
{
   + if (cpufreq_boost_supported()) {
   + tz-overheated = true;
   + cpufreq_boost_trigger_state(0);
   + if (!tz-polling_delay) {
   + tz-boost_polling = true;
   + tz-polling_delay = 1000;
   + }
   + }
   +
 if (tz-governor)
 tz-governor-throttle(tz, trip);
}
   @@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
   work_struct *work)
 struct thermal_zone_device *tz = container_of(work, struct
   thermal_zone_device,
   poll_queue.work);
   + long trip_temp;
   +
   + if (cpufreq_boost_supported()  tz-overheated) {
 
  Not all thermal drivers support trip points. So, we first need a
  if (tz-ops-get_trip_temp) check here.
 
 Ok, thanks for tip. Bluntly speaking, I thought, that all SoCs supported
 by thermal set trip points.

We would wish to get there. But not the reality today ;)

 
 
   + tz-ops-get_trip_temp(tz, 0, trip_temp);
   + /*
   +  * Enable boost again only when current
   temperature is less
   +  * than 75% of trip_temp[0]
   +  */
   + if ((tz-temperature + (trip_temp  2)) 
   trip_temp) {
 
  Another way would be to use the get_trend APIs for this thermal zone.
  If the trend is cooling we can re-enable boost otherwise not.
 
 Trend evaluation seems like a good complementary idea.
 
 However, I would also like to have the relative temperature drop
 measurement (if possible) like above (to 75% of the first trip point).
 
 Then I would be more confident, that everything cooled down and that I
 can start boost again.
 
 
   + tz-overheated = false;
   + if (tz-boost_polling) {
   + tz-boost_polling = false;
   + tz-polling_delay = 0;
   + monitor_thermal_zone(tz);
   + }
 
  Overall, I believe this will work well only if the thermal zone is
  CPU.
 
 My assumption:
 
 When I enable boost at CPU, then I also shall cool down the CPU. And
 the CPU zone seemed a natural choice.
 
 However I might be missing something, so hints are welcome.
 
 
  Another suggestion is: We tried hard to remove all throttling logic
  from thermal_core.c.
 
 By throttling logic you mean:
 if ((tz-temperature + (trip_temp  2)) and other conditions (like
 trend measurement)?

Yes. That is correct.

 
  May be we should include this kind of logic in
  step_wise.c ?
 
 It sounds interesting (since -throttle at thermal_core.c is called
 always when needed), but I'm afraid of a code duplication when one
 use Boost with fair_share or other thermal governor.

right. So, for the time being, (as part of this patch series)
I am Okay to have this code in thermal_core.c. From the thermal
subsystem perspective, we will (need to) work out a better/
cleaner/easier approach for this later.

Thanks,
Durga

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] thermal: consider emul_temperature while computing trend

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Thursday, May 30, 2013 3:07 AM
> To: Zhang, Rui
> Cc: Eduardo Valentin; Amit Daniel Kachhap; R, Durgadoss; linux-
> p...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 1/1] thermal: consider emul_temperature while computing
> trend
> 
> In case emulated temperature is in use, using the trend
> provided by driver layer can lead to bogus situation.
> In this case, debugger user would set a temperature value,
> but the trend would be from driver computation.
> 
> To avoid this situation, this patch changes the get_tz_trend()
> to consider the emulated temperature whenever that is in use.

Nice catch.
Sorry, I missed looking at it earlier. Just got woken up by Rui's reply
on this. The patch looks fine to me.

Thanks,
Durga
> 
> Cc: Zhang Rui 
> Cc: Amit Daniel Kachhap 
> Cc: Durgadoss R 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/thermal_core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> index d755440..c00dc92 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -155,7 +155,8 @@ int get_tz_trend(struct thermal_zone_device *tz, int
> trip)
>  {
>   enum thermal_trend trend;
> 
> - if (!tz->ops->get_trend || tz->ops->get_trend(tz, trip, )) {
> + if (tz->emul_temperature || !tz->ops->get_trend ||
> + tz->ops->get_trend(tz, trip, )) {
>   if (tz->temperature > tz->last_temperature)
>   trend = THERMAL_TREND_RAISING;
>   else if (tz->temperature < tz->last_temperature)
> --
> 1.8.2.1.342.gfa7285d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] thermal: consider emul_temperature while computing trend

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
 Sent: Thursday, May 30, 2013 3:07 AM
 To: Zhang, Rui
 Cc: Eduardo Valentin; Amit Daniel Kachhap; R, Durgadoss; linux-
 p...@vger.kernel.org; linux-kernel@vger.kernel.org
 Subject: [PATCH 1/1] thermal: consider emul_temperature while computing
 trend
 
 In case emulated temperature is in use, using the trend
 provided by driver layer can lead to bogus situation.
 In this case, debugger user would set a temperature value,
 but the trend would be from driver computation.
 
 To avoid this situation, this patch changes the get_tz_trend()
 to consider the emulated temperature whenever that is in use.

Nice catch.
Sorry, I missed looking at it earlier. Just got woken up by Rui's reply
on this. The patch looks fine to me.

Thanks,
Durga
 
 Cc: Zhang Rui rui.zh...@intel.com
 Cc: Amit Daniel Kachhap amit.dan...@samsung.com
 Cc: Durgadoss R durgados...@intel.com
 Cc: linux...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  drivers/thermal/thermal_core.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/thermal_core.c
 b/drivers/thermal/thermal_core.c
 index d755440..c00dc92 100644
 --- a/drivers/thermal/thermal_core.c
 +++ b/drivers/thermal/thermal_core.c
 @@ -155,7 +155,8 @@ int get_tz_trend(struct thermal_zone_device *tz, int
 trip)
  {
   enum thermal_trend trend;
 
 - if (!tz-ops-get_trend || tz-ops-get_trend(tz, trip, trend)) {
 + if (tz-emul_temperature || !tz-ops-get_trend ||
 + tz-ops-get_trend(tz, trip, trend)) {
   if (tz-temperature  tz-last_temperature)
   trend = THERMAL_TREND_RAISING;
   else if (tz-temperature  tz-last_temperature)
 --
 1.8.2.1.342.gfa7285d
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/3] Thermal: core: Ask .get_trip_temp() to register thermal zone device.

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Jonghwa Lee
> Sent: Saturday, May 18, 2013 3:20 PM
> To: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Zhang, Rui; Eduardo Valentin; Amit Dinel
> Kachhap; Jonghwa Lee; MyungJoo Ham
> Subject: [PATCH 1/3] Thermal: core: Ask .get_trip_temp() to register thermal
> zone device.
> 
> This patch adds a requirement needing .get_trip_temp() callback
> function for registering thermal zone device. This function is
> used when thermal zone is updated and essential where thermal core
> handles thermal trip based only polling way not hw interrupt.

Nice catch. Looks fine,
Acked-by: Durgadoss R 

Thanks,
Durga

> 
> Signed-off-by: Jonghwa Lee 
> Signed-off-by: MyungJoo Ham 
> ---
>  drivers/thermal/thermal_core.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> index d755440..f753f48 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1624,7 +1624,7 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
>   if (!ops || !ops->get_temp)
>   return ERR_PTR(-EINVAL);
> 
> - if (trips > 0 && !ops->get_trip_type)
> + if (trips > 0 && (!ops->get_trip_type || !ops->get_trip_temp))
>   return ERR_PTR(-EINVAL);
> 
>   tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL);
> --
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/3] Thermal: core: Ask .get_trip_temp() to register thermal zone device.

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Jonghwa Lee
 Sent: Saturday, May 18, 2013 3:20 PM
 To: linux...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org; Zhang, Rui; Eduardo Valentin; Amit Dinel
 Kachhap; Jonghwa Lee; MyungJoo Ham
 Subject: [PATCH 1/3] Thermal: core: Ask .get_trip_temp() to register thermal
 zone device.
 
 This patch adds a requirement needing .get_trip_temp() callback
 function for registering thermal zone device. This function is
 used when thermal zone is updated and essential where thermal core
 handles thermal trip based only polling way not hw interrupt.

Nice catch. Looks fine,
Acked-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

 
 Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 ---
  drivers/thermal/thermal_core.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/thermal_core.c
 b/drivers/thermal/thermal_core.c
 index d755440..f753f48 100644
 --- a/drivers/thermal/thermal_core.c
 +++ b/drivers/thermal/thermal_core.c
 @@ -1624,7 +1624,7 @@ struct thermal_zone_device
 *thermal_zone_device_register(const char *type,
   if (!ops || !ops-get_temp)
   return ERR_PTR(-EINVAL);
 
 - if (trips  0  !ops-get_trip_type)
 + if (trips  0  (!ops-get_trip_type || !ops-get_trip_temp))
   return ERR_PTR(-EINVAL);
 
   tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL);
 --
 1.7.9.5
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kobject_uevent in cpufreq.c

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Greg KH
> (gre...@linuxfoundation.org)
> Sent: Monday, May 13, 2013 5:28 PM
> To: R, Durgadoss
> Cc: linux-kernel@vger.kernel.org; Linux PM list (linux...@vger.kernel.org);
> Wysocki, Rafael J
> Subject: Re: Kobject_uevent in cpufreq.c
> 
> On Mon, May 13, 2013 at 11:31:57AM +, R, Durgadoss wrote:
> > Hi,
> >
> > I am observing an UEvent issue in cpufreq.c.
> > The cpufreq_add_dev() function is called whenever a core is 'onlined'.
> > we expect the kobject_uevent() method in cpufreq_add_dev() to
> > send an UEvent with KOBJ_ADD as the action parameter.
> >
> > But this call fails because of the 'filter function' inside 
> > kobject_uevent_env
> > inside lib/kobject_uevent.c. The ->filter points to 'dev_uevent_filter' in
> > drivers/base/core.c, where the check for 'device_ktype' fails.
> >
> > Error message:
> > kobject: 'cpufreq' (e5bbf290): kobject_uevent_env:
> > filter function caused the event to drop!
> >
> > As far as I can see, we need a kset, and associated filter function
> > inside cpufreq.c to get this working. Is this the right way to go ?
> > Any other easy/correct ways to get it working ? Please advise.
> 
> What exactly are you trying to do, and want the kernel to do?  You
> already get on/offline events for CPUs, why do you want them for cpufreq
> devices as well?

I want to update the permission of a cpufreq sysfs interface (scaling_*)
of a cpu (say cpu1) when the cpu resumes from suspend (s3).
I am trying to do this by listening to the uevent (sent by cpufreq.c,
when a cpu resumes) through udev.

For example,
chmod user:user /sys/devices/system/cpu1/cpufreq/scaling_max_freq

But I am not able to receive this event in udev, because kobject_uevent()
call fails due to the above-mentioned reason (i.e filter function)
I am trying to see how to make the kobject_uevent() call succeed,
so that I can change the permission as mentioned above.

The on/offline events come only when I manually do a
echo 0 > /sys/devices/system/cpu/cpu1/online
They don't come when the cpu resumes from suspend(s3)

[I checked this in code. Looks like during resume, the call flow
does not hit cpu.c, where this KOBJ_ONLINE is being sent]

Thanks,
Durga

> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kobject_uevent in cpufreq.c

[R, Durgadoss]

Hi,

I am observing an UEvent issue in cpufreq.c. 
The cpufreq_add_dev() function is called whenever a core is 'onlined'.
we expect the kobject_uevent() method in cpufreq_add_dev() to
send an UEvent with KOBJ_ADD as the action parameter.

But this call fails because of the 'filter function' inside kobject_uevent_env
inside lib/kobject_uevent.c. The ->filter points to 'dev_uevent_filter' in
drivers/base/core.c, where the check for 'device_ktype' fails.

Error message:
kobject: 'cpufreq' (e5bbf290): kobject_uevent_env:
filter function caused the event to drop!

As far as I can see, we need a kset, and associated filter function
inside cpufreq.c to get this working. Is this the right way to go ?
Any other easy/correct ways to get it working ? Please advise.

Thanks,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kobject_uevent in cpufreq.c

[R, Durgadoss]

Hi,

I am observing an UEvent issue in cpufreq.c. 
The cpufreq_add_dev() function is called whenever a core is 'onlined'.
we expect the kobject_uevent() method in cpufreq_add_dev() to
send an UEvent with KOBJ_ADD as the action parameter.

But this call fails because of the 'filter function' inside kobject_uevent_env
inside lib/kobject_uevent.c. The -filter points to 'dev_uevent_filter' in
drivers/base/core.c, where the check for 'device_ktype' fails.

Error message:
kobject: 'cpufreq' (e5bbf290): kobject_uevent_env:
filter function caused the event to drop!

As far as I can see, we need a kset, and associated filter function
inside cpufreq.c to get this working. Is this the right way to go ?
Any other easy/correct ways to get it working ? Please advise.

Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kobject_uevent in cpufreq.c

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Greg KH
 (gre...@linuxfoundation.org)
 Sent: Monday, May 13, 2013 5:28 PM
 To: R, Durgadoss
 Cc: linux-kernel@vger.kernel.org; Linux PM list (linux...@vger.kernel.org);
 Wysocki, Rafael J
 Subject: Re: Kobject_uevent in cpufreq.c
 
 On Mon, May 13, 2013 at 11:31:57AM +, R, Durgadoss wrote:
  Hi,
 
  I am observing an UEvent issue in cpufreq.c.
  The cpufreq_add_dev() function is called whenever a core is 'onlined'.
  we expect the kobject_uevent() method in cpufreq_add_dev() to
  send an UEvent with KOBJ_ADD as the action parameter.
 
  But this call fails because of the 'filter function' inside 
  kobject_uevent_env
  inside lib/kobject_uevent.c. The -filter points to 'dev_uevent_filter' in
  drivers/base/core.c, where the check for 'device_ktype' fails.
 
  Error message:
  kobject: 'cpufreq' (e5bbf290): kobject_uevent_env:
  filter function caused the event to drop!
 
  As far as I can see, we need a kset, and associated filter function
  inside cpufreq.c to get this working. Is this the right way to go ?
  Any other easy/correct ways to get it working ? Please advise.
 
 What exactly are you trying to do, and want the kernel to do?  You
 already get on/offline events for CPUs, why do you want them for cpufreq
 devices as well?

I want to update the permission of a cpufreq sysfs interface (scaling_*)
of a cpu (say cpu1) when the cpu resumes from suspend (s3).
I am trying to do this by listening to the uevent (sent by cpufreq.c,
when a cpu resumes) through udev.

For example,
chmod user:user /sys/devices/system/cpu1/cpufreq/scaling_max_freq

But I am not able to receive this event in udev, because kobject_uevent()
call fails due to the above-mentioned reason (i.e filter function)
I am trying to see how to make the kobject_uevent() call succeed,
so that I can change the permission as mentioned above.

The on/offline events come only when I manually do a
echo 0  /sys/devices/system/cpu/cpu1/online
They don't come when the cpu resumes from suspend(s3)

[I checked this in code. Looks like during resume, the call flow
does not hit cpu.c, where this KOBJ_ONLINE is being sent]

Thanks,
Durga

 
 thanks,
 
 greg k-h
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv3 1/3] thermal: introduce thermal_zone_get_zone_by_name helper function

[R, Durgadoss]

> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> Sent: Friday, April 05, 2013 6:02 PM
> To: Zhang, Rui
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
> Eduardo Valentin
> Subject: [PATCHv3 1/3] thermal: introduce
> thermal_zone_get_zone_by_name helper function
> 
> This patch adds a helper function to get a reference of
> a thermal zone, based on the zone type name.
> 
> It will perform a zone name lookup and return a reference
> to a thermal zone device that matches the name requested.
> In case the zone is not found or when several zones match
> same name or if the required parameters are invalid, it will return
> the corresponding error code (ERR_PTR).
> 
> Cc: Durgadoss R 
> Signed-off-by: Eduardo Valentin 

Looks okay to me.
Acked-by: Durgadoss R 

Thanks,
Durga

> ---
>  drivers/thermal/thermal_sys.c |   38
> ++
>  include/linux/thermal.h   |1 +
>  2 files changed, 39 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 5bd95d4..e9b636b 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -1790,6 +1790,44 @@ void thermal_zone_device_unregister(struct
> thermal_zone_device *tz)
>  }
>  EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
> 
> +/**
> + * thermal_zone_get_zone_by_name() - search for a zone and returns its
> ref
> + * @name: thermal zone name to fetch the temperature
> + *
> + * When only one zone is found with the passed name, returns a reference
> to it.
> + *
> + * Return: On success returns a reference to an unique thermal zone with
> + * matching name equals to @name, an ERR_PTR otherwise (-EINVAL for
> invalid
> + * paramenters, -ENODEV for not found and -EEXIST for multiple matches).
> + */
> +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> char *name)
> +{
> + struct thermal_zone_device *pos = NULL, *ref = ERR_PTR(-EINVAL);
> + unsigned int found = 0;
> +
> + if (!name)
> + goto exit;
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(pos, _tz_list, node)
> + if (!strnicmp(name, pos->type, THERMAL_NAME_LENGTH)) {
> + found++;
> + ref = pos;
> + }
> + mutex_unlock(_list_lock);
> +
> + /* nothing has been found, thus an error code for it */
> + if (found == 0)
> + ref = ERR_PTR(-ENODEV);
> + else if (found > 1)
> + /* Success only when an unique zone is found */
> + ref = ERR_PTR(-EEXIST);
> +
> +exit:
> + return ref;
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_get_zone_by_name);
> +
>  #ifdef CONFIG_NET
>  static struct genl_family thermal_event_genl_family = {
>   .id = GENL_ID_GENERATE,
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 542a39c..0cf9eb5 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -237,6 +237,7 @@ void thermal_zone_device_update(struct
> thermal_zone_device *);
>  struct thermal_cooling_device *thermal_cooling_device_register(char *,
> void *,
>   const struct thermal_cooling_device_ops *);
>  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
> +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> char *name);
> 
>  int thermal_zone_trend_get(struct thermal_zone_device *, int);
>  struct thermal_instance *thermal_instance_get(struct
> thermal_zone_device *,
> --
> 1.7.7.1.488.ge8e1c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv3 1/3] thermal: introduce thermal_zone_get_zone_by_name helper function

[R, Durgadoss]

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Friday, April 05, 2013 6:02 PM
 To: Zhang, Rui
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
 Eduardo Valentin
 Subject: [PATCHv3 1/3] thermal: introduce
 thermal_zone_get_zone_by_name helper function
 
 This patch adds a helper function to get a reference of
 a thermal zone, based on the zone type name.
 
 It will perform a zone name lookup and return a reference
 to a thermal zone device that matches the name requested.
 In case the zone is not found or when several zones match
 same name or if the required parameters are invalid, it will return
 the corresponding error code (ERR_PTR).
 
 Cc: Durgadoss R durgados...@intel.com
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com

Looks okay to me.
Acked-by: Durgadoss R durgados...@intel.com

Thanks,
Durga

 ---
  drivers/thermal/thermal_sys.c |   38
 ++
  include/linux/thermal.h   |1 +
  2 files changed, 39 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
 index 5bd95d4..e9b636b 100644
 --- a/drivers/thermal/thermal_sys.c
 +++ b/drivers/thermal/thermal_sys.c
 @@ -1790,6 +1790,44 @@ void thermal_zone_device_unregister(struct
 thermal_zone_device *tz)
  }
  EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
 
 +/**
 + * thermal_zone_get_zone_by_name() - search for a zone and returns its
 ref
 + * @name: thermal zone name to fetch the temperature
 + *
 + * When only one zone is found with the passed name, returns a reference
 to it.
 + *
 + * Return: On success returns a reference to an unique thermal zone with
 + * matching name equals to @name, an ERR_PTR otherwise (-EINVAL for
 invalid
 + * paramenters, -ENODEV for not found and -EEXIST for multiple matches).
 + */
 +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
 char *name)
 +{
 + struct thermal_zone_device *pos = NULL, *ref = ERR_PTR(-EINVAL);
 + unsigned int found = 0;
 +
 + if (!name)
 + goto exit;
 +
 + mutex_lock(thermal_list_lock);
 + list_for_each_entry(pos, thermal_tz_list, node)
 + if (!strnicmp(name, pos-type, THERMAL_NAME_LENGTH)) {
 + found++;
 + ref = pos;
 + }
 + mutex_unlock(thermal_list_lock);
 +
 + /* nothing has been found, thus an error code for it */
 + if (found == 0)
 + ref = ERR_PTR(-ENODEV);
 + else if (found  1)
 + /* Success only when an unique zone is found */
 + ref = ERR_PTR(-EEXIST);
 +
 +exit:
 + return ref;
 +}
 +EXPORT_SYMBOL_GPL(thermal_zone_get_zone_by_name);
 +
  #ifdef CONFIG_NET
  static struct genl_family thermal_event_genl_family = {
   .id = GENL_ID_GENERATE,
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index 542a39c..0cf9eb5 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -237,6 +237,7 @@ void thermal_zone_device_update(struct
 thermal_zone_device *);
  struct thermal_cooling_device *thermal_cooling_device_register(char *,
 void *,
   const struct thermal_cooling_device_ops *);
  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
 +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
 char *name);
 
  int thermal_zone_trend_get(struct thermal_zone_device *, int);
  struct thermal_instance *thermal_instance_get(struct
 thermal_zone_device *,
 --
 1.7.7.1.488.ge8e1c

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv2 1/3] thermal: introduce thermal_zone_get_zone_by_name helper function

[R, Durgadoss]

> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> Sent: Friday, April 05, 2013 1:52 AM
> To: R, Durgadoss
> Cc: Eduardo Valentin; Zhang, Rui; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCHv2 1/3] thermal: introduce
> thermal_zone_get_zone_by_name helper function
> 
> On 04-04-2013 13:12, R, Durgadoss wrote:
> >> -Original Message-
> >> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> >> Sent: Thursday, April 04, 2013 3:43 AM
> >> To: Zhang, Rui
> >> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R,
> Durgadoss;
> >> Eduardo Valentin
> >> Subject: [PATCHv2 1/3] thermal: introduce
> >> thermal_zone_get_zone_by_name helper function
> >>
> >> This patch adds a helper function to get a reference of
> >> a thermal zone, based on the zone type name.
> >>
> >> It will perform a zone name lookup and return a reference
> >> to a thermal zone device that matches the name requested.
> >> In case the zone is not found or when several zones match
> >> same name or if the required parameters are invalid, it will return
> >> the corresponding error code (ERR_PTR).
> >>
> >> Signed-off-by: Eduardo Valentin 
> >> ---
> >>   drivers/thermal/thermal_sys.c |   34
> >> ++
> >>   include/linux/thermal.h   |1 +
> >>   2 files changed, 35 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/thermal/thermal_sys.c
> b/drivers/thermal/thermal_sys.c
> >> index 5bd95d4..6e1da0a 100644
> >> --- a/drivers/thermal/thermal_sys.c
> >> +++ b/drivers/thermal/thermal_sys.c
> >> @@ -1790,6 +1790,40 @@ void thermal_zone_device_unregister(struct
> >> thermal_zone_device *tz)
> >>   }
> >>   EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
> >>
> >> +/**
> >> + * thermal_zone_get_zone_by_name() - search for a zone and returns
> its
> >> ref
> >> + * @name: thermal zone name to fetch the temperature
> >> + *
> >> + * When only one zone is found with the passed name, returns a
> reference
> >> to it.
> >> + *
> >> + * Return: On success returns a reference to an unique thermal zone
> with
> >> + * matching name equals to @name, a ERR_PTR otherwise.
> >> + */
> >> +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> >> char *name)
> >> +{
> >> +  struct thermal_zone_device *pos = NULL, *ref = ERR_PTR(-EINVAL);
> >> +  int found = 0;
> >> +
> >> +  if (!name)
> >> +  goto exit;
> >> +
> >> +  mutex_lock(_list_lock);
> >> +  list_for_each_entry(pos, _tz_list, node)
> >> +  if (!strnicmp(name, pos->type, THERMAL_NAME_LENGTH)) {
> >> +  found++;
> >> +  ref = pos;
> >> +  }
> >> +  mutex_unlock(_list_lock);
> >> +
> >> +  /* Success only when an unique zone is found */
> >> +  if (found != 1)
> >> +  ref = ERR_PTR(-ENODEV);
> >
> > I think we should differentiate between the two cases:
> > 1. The zone does not exist at all
> > return NULL in this case
> > 2. There are multiple zones
> > return ERR_PTR(-EEXIST) in this case
> >
> > This way the calling function can figure out the exact reason
> > for failure.
> 
> I think the code documentation is already clear enough to say that this
> is for unique matches. But in case you want to differentiate these
> cases, I can resend it. Do you have a usage for this?

Yes, the calling function may want to re-try (or even unregister a zone,
to proceed further..)

> 
> Besides, I would prefer to return ERR_PTR(-ENODEV) in the first case.
> The way it is in the original patch.

Okay, I am fine with that too :-)

> 
> >
> > Thanks,
> > Durga
> >
> >> +
> >> +exit:
> >> +  return ref;
> >> +}
> >> +EXPORT_SYMBOL_GPL(thermal_zone_get_zone_by_name);
> >> +
> >>   #ifdef CONFIG_NET
> >>   static struct genl_family thermal_event_genl_family = {
> >>.id = GENL_ID_GENERATE,
> >> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> >> index 542a39c..0cf9eb5 100644
> >> --- a/include/linux/thermal.h
> >> +++ b/include/linux/thermal.h
> >> @@ -237,6 +237,7 @@ void thermal_zone_device_update(struct
> >> thermal_zone_device *);
> >>   struct thermal_cooling_device *thermal_cooling_device_register(char *,
> >> void *,
> >>const struct thermal_cooling_device_ops *);
> >>   void thermal_cooling_device_unregister(struct thermal_cooling_device
> *);
> >> +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> >> char *name);
> >>
> >>   int thermal_zone_trend_get(struct thermal_zone_device *, int);
> >>   struct thermal_instance *thermal_instance_get(struct
> >> thermal_zone_device *,
> >> --
> >> 1.7.7.1.488.ge8e1c
> >
> >
> >

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv2 2/3] thermal: expose thermal_zone_get_temp API

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Thursday, April 04, 2013 3:43 AM
> To: Zhang, Rui
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
> Eduardo Valentin
> Subject: [PATCHv2 2/3] thermal: expose thermal_zone_get_temp API
> 
> This patch exports the thermal_zone_get_temp API so that driver
> writers can fetch temperature of thermal zones managed by other
> drivers.
> 
> Signed-off-by: Eduardo Valentin 

Looks fine,
Acked-By: Durgadoss R 

> ---
>  drivers/thermal/thermal_sys.c |   20 +---
>  include/linux/thermal.h   |1 +
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 6e1da0a..e8afb7f 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -371,16 +371,28 @@ static void handle_thermal_trip(struct
> thermal_zone_device *tz, int trip)
>   monitor_thermal_zone(tz);
>  }
> 
> -static int thermal_zone_get_temp(struct thermal_zone_device *tz,
> - unsigned long *temp)
> +/**
> + * thermal_zone_get_temp() - returns its the temperature of thermal zone
> + * @tz: a valid pointer to a struct thermal_zone_device
> + * @temp: a valid pointer to where to store the resulting temperature.
> + *
> + * When a valid thermal zone reference is passed, it will fetch its
> + * temperature and fill @temp.
> + *
> + * Return: On success returns 0, an error code otherwise
> + */
> +int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
> long *temp)
>  {
> - int ret = 0;
> + int ret = -EINVAL;
>  #ifdef CONFIG_THERMAL_EMULATION
>   int count;
>   unsigned long crit_temp = -1UL;
>   enum thermal_trip_type type;
>  #endif
> 
> + if (IS_ERR_OR_NULL(tz))
> + goto exit;
> +
>   mutex_lock(>lock);
> 
>   ret = tz->ops->get_temp(tz, temp);
> @@ -404,8 +416,10 @@ static int thermal_zone_get_temp(struct
> thermal_zone_device *tz,
>  skip_emul:
>  #endif
>   mutex_unlock(>lock);
> +exit:
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(thermal_zone_get_temp);
> 
>  static void update_temperature(struct thermal_zone_device *tz)
>  {
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 0cf9eb5..8eea86c 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -238,6 +238,7 @@ struct thermal_cooling_device
> *thermal_cooling_device_register(char *, void *,
>   const struct thermal_cooling_device_ops *);
>  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
>  struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> char *name);
> +int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
> long *temp);
> 
>  int thermal_zone_trend_get(struct thermal_zone_device *, int);
>  struct thermal_instance *thermal_instance_get(struct
> thermal_zone_device *,
> --
> 1.7.7.1.488.ge8e1c
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv2 1/3] thermal: introduce thermal_zone_get_zone_by_name helper function

[R, Durgadoss]

> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> Sent: Thursday, April 04, 2013 3:43 AM
> To: Zhang, Rui
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
> Eduardo Valentin
> Subject: [PATCHv2 1/3] thermal: introduce
> thermal_zone_get_zone_by_name helper function
> 
> This patch adds a helper function to get a reference of
> a thermal zone, based on the zone type name.
> 
> It will perform a zone name lookup and return a reference
> to a thermal zone device that matches the name requested.
> In case the zone is not found or when several zones match
> same name or if the required parameters are invalid, it will return
> the corresponding error code (ERR_PTR).
> 
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/thermal_sys.c |   34
> ++
>  include/linux/thermal.h   |1 +
>  2 files changed, 35 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 5bd95d4..6e1da0a 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -1790,6 +1790,40 @@ void thermal_zone_device_unregister(struct
> thermal_zone_device *tz)
>  }
>  EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
> 
> +/**
> + * thermal_zone_get_zone_by_name() - search for a zone and returns its
> ref
> + * @name: thermal zone name to fetch the temperature
> + *
> + * When only one zone is found with the passed name, returns a reference
> to it.
> + *
> + * Return: On success returns a reference to an unique thermal zone with
> + * matching name equals to @name, a ERR_PTR otherwise.
> + */
> +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> char *name)
> +{
> + struct thermal_zone_device *pos = NULL, *ref = ERR_PTR(-EINVAL);
> + int found = 0;
> +
> + if (!name)
> + goto exit;
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(pos, _tz_list, node)
> + if (!strnicmp(name, pos->type, THERMAL_NAME_LENGTH)) {
> + found++;
> + ref = pos;
> + }
> + mutex_unlock(_list_lock);
> +
> + /* Success only when an unique zone is found */
> + if (found != 1)
> + ref = ERR_PTR(-ENODEV);

I think we should differentiate between the two cases:
1. The zone does not exist at all
return NULL in this case
2. There are multiple zones
return ERR_PTR(-EEXIST) in this case

This way the calling function can figure out the exact reason
for failure.

Thanks,
Durga

> +
> +exit:
> + return ref;
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_get_zone_by_name);
> +
>  #ifdef CONFIG_NET
>  static struct genl_family thermal_event_genl_family = {
>   .id = GENL_ID_GENERATE,
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 542a39c..0cf9eb5 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -237,6 +237,7 @@ void thermal_zone_device_update(struct
> thermal_zone_device *);
>  struct thermal_cooling_device *thermal_cooling_device_register(char *,
> void *,
>   const struct thermal_cooling_device_ops *);
>  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
> +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> char *name);
> 
>  int thermal_zone_trend_get(struct thermal_zone_device *, int);
>  struct thermal_instance *thermal_instance_get(struct
> thermal_zone_device *,
> --
> 1.7.7.1.488.ge8e1c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv2 1/3] thermal: introduce thermal_zone_get_zone_by_name helper function

[R, Durgadoss]

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Thursday, April 04, 2013 3:43 AM
 To: Zhang, Rui
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
 Eduardo Valentin
 Subject: [PATCHv2 1/3] thermal: introduce
 thermal_zone_get_zone_by_name helper function
 
 This patch adds a helper function to get a reference of
 a thermal zone, based on the zone type name.
 
 It will perform a zone name lookup and return a reference
 to a thermal zone device that matches the name requested.
 In case the zone is not found or when several zones match
 same name or if the required parameters are invalid, it will return
 the corresponding error code (ERR_PTR).
 
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  drivers/thermal/thermal_sys.c |   34
 ++
  include/linux/thermal.h   |1 +
  2 files changed, 35 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
 index 5bd95d4..6e1da0a 100644
 --- a/drivers/thermal/thermal_sys.c
 +++ b/drivers/thermal/thermal_sys.c
 @@ -1790,6 +1790,40 @@ void thermal_zone_device_unregister(struct
 thermal_zone_device *tz)
  }
  EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
 
 +/**
 + * thermal_zone_get_zone_by_name() - search for a zone and returns its
 ref
 + * @name: thermal zone name to fetch the temperature
 + *
 + * When only one zone is found with the passed name, returns a reference
 to it.
 + *
 + * Return: On success returns a reference to an unique thermal zone with
 + * matching name equals to @name, a ERR_PTR otherwise.
 + */
 +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
 char *name)
 +{
 + struct thermal_zone_device *pos = NULL, *ref = ERR_PTR(-EINVAL);
 + int found = 0;
 +
 + if (!name)
 + goto exit;
 +
 + mutex_lock(thermal_list_lock);
 + list_for_each_entry(pos, thermal_tz_list, node)
 + if (!strnicmp(name, pos-type, THERMAL_NAME_LENGTH)) {
 + found++;
 + ref = pos;
 + }
 + mutex_unlock(thermal_list_lock);
 +
 + /* Success only when an unique zone is found */
 + if (found != 1)
 + ref = ERR_PTR(-ENODEV);

I think we should differentiate between the two cases:
1. The zone does not exist at all
return NULL in this case
2. There are multiple zones
return ERR_PTR(-EEXIST) in this case

This way the calling function can figure out the exact reason
for failure.

Thanks,
Durga

 +
 +exit:
 + return ref;
 +}
 +EXPORT_SYMBOL_GPL(thermal_zone_get_zone_by_name);
 +
  #ifdef CONFIG_NET
  static struct genl_family thermal_event_genl_family = {
   .id = GENL_ID_GENERATE,
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index 542a39c..0cf9eb5 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -237,6 +237,7 @@ void thermal_zone_device_update(struct
 thermal_zone_device *);
  struct thermal_cooling_device *thermal_cooling_device_register(char *,
 void *,
   const struct thermal_cooling_device_ops *);
  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
 +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
 char *name);
 
  int thermal_zone_trend_get(struct thermal_zone_device *, int);
  struct thermal_instance *thermal_instance_get(struct
 thermal_zone_device *,
 --
 1.7.7.1.488.ge8e1c

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv2 2/3] thermal: expose thermal_zone_get_temp API

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
 Sent: Thursday, April 04, 2013 3:43 AM
 To: Zhang, Rui
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
 Eduardo Valentin
 Subject: [PATCHv2 2/3] thermal: expose thermal_zone_get_temp API
 
 This patch exports the thermal_zone_get_temp API so that driver
 writers can fetch temperature of thermal zones managed by other
 drivers.
 
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com

Looks fine,
Acked-By: Durgadoss R durgados...@intel.com

 ---
  drivers/thermal/thermal_sys.c |   20 +---
  include/linux/thermal.h   |1 +
  2 files changed, 18 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
 index 6e1da0a..e8afb7f 100644
 --- a/drivers/thermal/thermal_sys.c
 +++ b/drivers/thermal/thermal_sys.c
 @@ -371,16 +371,28 @@ static void handle_thermal_trip(struct
 thermal_zone_device *tz, int trip)
   monitor_thermal_zone(tz);
  }
 
 -static int thermal_zone_get_temp(struct thermal_zone_device *tz,
 - unsigned long *temp)
 +/**
 + * thermal_zone_get_temp() - returns its the temperature of thermal zone
 + * @tz: a valid pointer to a struct thermal_zone_device
 + * @temp: a valid pointer to where to store the resulting temperature.
 + *
 + * When a valid thermal zone reference is passed, it will fetch its
 + * temperature and fill @temp.
 + *
 + * Return: On success returns 0, an error code otherwise
 + */
 +int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
 long *temp)
  {
 - int ret = 0;
 + int ret = -EINVAL;
  #ifdef CONFIG_THERMAL_EMULATION
   int count;
   unsigned long crit_temp = -1UL;
   enum thermal_trip_type type;
  #endif
 
 + if (IS_ERR_OR_NULL(tz))
 + goto exit;
 +
   mutex_lock(tz-lock);
 
   ret = tz-ops-get_temp(tz, temp);
 @@ -404,8 +416,10 @@ static int thermal_zone_get_temp(struct
 thermal_zone_device *tz,
  skip_emul:
  #endif
   mutex_unlock(tz-lock);
 +exit:
   return ret;
  }
 +EXPORT_SYMBOL_GPL(thermal_zone_get_temp);
 
  static void update_temperature(struct thermal_zone_device *tz)
  {
 diff --git a/include/linux/thermal.h b/include/linux/thermal.h
 index 0cf9eb5..8eea86c 100644
 --- a/include/linux/thermal.h
 +++ b/include/linux/thermal.h
 @@ -238,6 +238,7 @@ struct thermal_cooling_device
 *thermal_cooling_device_register(char *, void *,
   const struct thermal_cooling_device_ops *);
  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
  struct thermal_zone_device *thermal_zone_get_zone_by_name(const
 char *name);
 +int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
 long *temp);
 
  int thermal_zone_trend_get(struct thermal_zone_device *, int);
  struct thermal_instance *thermal_instance_get(struct
 thermal_zone_device *,
 --
 1.7.7.1.488.ge8e1c
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv2 1/3] thermal: introduce thermal_zone_get_zone_by_name helper function

[R, Durgadoss]

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Friday, April 05, 2013 1:52 AM
 To: R, Durgadoss
 Cc: Eduardo Valentin; Zhang, Rui; linux...@vger.kernel.org; linux-
 ker...@vger.kernel.org
 Subject: Re: [PATCHv2 1/3] thermal: introduce
 thermal_zone_get_zone_by_name helper function
 
 On 04-04-2013 13:12, R, Durgadoss wrote:
  -Original Message-
  From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
  Sent: Thursday, April 04, 2013 3:43 AM
  To: Zhang, Rui
  Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R,
 Durgadoss;
  Eduardo Valentin
  Subject: [PATCHv2 1/3] thermal: introduce
  thermal_zone_get_zone_by_name helper function
 
  This patch adds a helper function to get a reference of
  a thermal zone, based on the zone type name.
 
  It will perform a zone name lookup and return a reference
  to a thermal zone device that matches the name requested.
  In case the zone is not found or when several zones match
  same name or if the required parameters are invalid, it will return
  the corresponding error code (ERR_PTR).
 
  Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
  ---
drivers/thermal/thermal_sys.c |   34
  ++
include/linux/thermal.h   |1 +
2 files changed, 35 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/thermal/thermal_sys.c
 b/drivers/thermal/thermal_sys.c
  index 5bd95d4..6e1da0a 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -1790,6 +1790,40 @@ void thermal_zone_device_unregister(struct
  thermal_zone_device *tz)
}
EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
 
  +/**
  + * thermal_zone_get_zone_by_name() - search for a zone and returns
 its
  ref
  + * @name: thermal zone name to fetch the temperature
  + *
  + * When only one zone is found with the passed name, returns a
 reference
  to it.
  + *
  + * Return: On success returns a reference to an unique thermal zone
 with
  + * matching name equals to @name, a ERR_PTR otherwise.
  + */
  +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
  char *name)
  +{
  +  struct thermal_zone_device *pos = NULL, *ref = ERR_PTR(-EINVAL);
  +  int found = 0;
  +
  +  if (!name)
  +  goto exit;
  +
  +  mutex_lock(thermal_list_lock);
  +  list_for_each_entry(pos, thermal_tz_list, node)
  +  if (!strnicmp(name, pos-type, THERMAL_NAME_LENGTH)) {
  +  found++;
  +  ref = pos;
  +  }
  +  mutex_unlock(thermal_list_lock);
  +
  +  /* Success only when an unique zone is found */
  +  if (found != 1)
  +  ref = ERR_PTR(-ENODEV);
 
  I think we should differentiate between the two cases:
  1. The zone does not exist at all
  return NULL in this case
  2. There are multiple zones
  return ERR_PTR(-EEXIST) in this case
 
  This way the calling function can figure out the exact reason
  for failure.
 
 I think the code documentation is already clear enough to say that this
 is for unique matches. But in case you want to differentiate these
 cases, I can resend it. Do you have a usage for this?

Yes, the calling function may want to re-try (or even unregister a zone,
to proceed further..)

 
 Besides, I would prefer to return ERR_PTR(-ENODEV) in the first case.
 The way it is in the original patch.

Okay, I am fine with that too :-)

 
 
  Thanks,
  Durga
 
  +
  +exit:
  +  return ref;
  +}
  +EXPORT_SYMBOL_GPL(thermal_zone_get_zone_by_name);
  +
#ifdef CONFIG_NET
static struct genl_family thermal_event_genl_family = {
 .id = GENL_ID_GENERATE,
  diff --git a/include/linux/thermal.h b/include/linux/thermal.h
  index 542a39c..0cf9eb5 100644
  --- a/include/linux/thermal.h
  +++ b/include/linux/thermal.h
  @@ -237,6 +237,7 @@ void thermal_zone_device_update(struct
  thermal_zone_device *);
struct thermal_cooling_device *thermal_cooling_device_register(char *,
  void *,
 const struct thermal_cooling_device_ops *);
void thermal_cooling_device_unregister(struct thermal_cooling_device
 *);
  +struct thermal_zone_device *thermal_zone_get_zone_by_name(const
  char *name);
 
int thermal_zone_trend_get(struct thermal_zone_device *, int);
struct thermal_instance *thermal_instance_get(struct
  thermal_zone_device *,
  --
  1.7.7.1.488.ge8e1c
 
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC PATCH 3/5] Thermal: build thermal governors into thermal_sys module

[R, Durgadoss]

Hi Rui,

> -Original Message-
> From: Zhang, Rui
> Sent: Tuesday, March 26, 2013 9:56 PM
> To: linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: amit.dan...@samsung.com; R, Durgadoss; a...@lisas.de; Zhang, Rui
> Subject: [RFC PATCH 3/5] Thermal: build thermal governors into thermal_sys
> module
> 
> Signed-off-by: Zhang Rui 
> ---
>  drivers/thermal/Makefile   |6 +++---
>  drivers/thermal/fair_share.c   |   15 ++-
>  drivers/thermal/step_wise.c|   16 ++--
>  drivers/thermal/thermal_core.c |   36
> ++--
>  drivers/thermal/thermal_core.h |   25 +
>  drivers/thermal/user_space.c   |   15 ++-
>  include/linux/thermal.h|1 -
>  7 files changed, 68 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index b2009bd..b7fffc7 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -6,9 +6,9 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
>  thermal_sys-y+= thermal_core.o
> 
>  # governors
> -obj-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
> -obj-$(CONFIG_THERMAL_GOV_STEP_WISE)  += step_wise.o
> -obj-$(CONFIG_THERMAL_GOV_USER_SPACE) += user_space.o
> +thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) +=
> fair_share.o
> +thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)  += step_wise.o
> +thermal_sys-$(CONFIG_THERMAL_GOV_USER_SPACE) +=
> user_space.o
> 
>  # cpufreq cooling
>  obj-$(CONFIG_CPU_THERMAL)+= cpu_cooling.o
> diff --git a/drivers/thermal/fair_share.c b/drivers/thermal/fair_share.c
> index 792479f..944ba2f 100644
> --- a/drivers/thermal/fair_share.c
> +++ b/drivers/thermal/fair_share.c
> @@ -22,9 +22,6 @@
>   *
> ~~
> 
>   */
> 
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> -#include 
>  #include 
> 
>  #include "thermal_core.h"
> @@ -111,23 +108,15 @@ static int fair_share_throttle(struct
> thermal_zone_device *tz, int trip)
>  static struct thermal_governor thermal_gov_fair_share = {
>   .name   = "fair_share",
>   .throttle   = fair_share_throttle,
> - .owner  = THIS_MODULE,
>  };
> 
> -static int __init thermal_gov_fair_share_init(void)
> +int thermal_gov_fair_share_register(void)
>  {
>   return thermal_register_governor(_gov_fair_share);
>  }
> 
> -static void __exit thermal_gov_fair_share_exit(void)
> +void thermal_gov_fair_share_unregister(void)
>  {
>   thermal_unregister_governor(_gov_fair_share);
>  }
> 
> -/* This should load after thermal framework */
> -fs_initcall(thermal_gov_fair_share_init);
> -module_exit(thermal_gov_fair_share_exit);
> -
> -MODULE_AUTHOR("Durgadoss R");
> -MODULE_DESCRIPTION("A simple weight based thermal throttling
> governor");
> -MODULE_LICENSE("GPL");
> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> index 407cde3..a6c9666 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -22,9 +22,6 @@
>   *
> ~~
> 
>   */
> 
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> -#include 
>  #include 
> 
>  #include "thermal_core.h"
> @@ -180,23 +177,14 @@ static int step_wise_throttle(struct
> thermal_zone_device *tz, int trip)
>  static struct thermal_governor thermal_gov_step_wise = {
>   .name   = "step_wise",
>   .throttle   = step_wise_throttle,
> - .owner  = THIS_MODULE,
>  };
> 
> -static int __init thermal_gov_step_wise_init(void)
> +int thermal_gov_step_wise_register(void)
>  {
>   return thermal_register_governor(_gov_step_wise);
>  }
> 
> -static void __exit thermal_gov_step_wise_exit(void)
> +void thermal_gov_step_wise_unregister(void)
>  {
>   thermal_unregister_governor(_gov_step_wise);
>  }
> -
> -/* This should load after thermal framework */
> -fs_initcall(thermal_gov_step_wise_init);
> -module_exit(thermal_gov_step_wise_exit);
> -
> -MODULE_AUTHOR("Durgadoss R");
> -MODULE_DESCRIPTION("A step-by-step thermal throttling governor");
> -MODULE_LICENSE("GPL");
> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> index 845ed6e..eac9745 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1858,22 +1858,54 @@ static inline int genetlink_init(void) { return 0; }
>  static inlin

RE: [RFC PATCH 3/5] Thermal: build thermal governors into thermal_sys module

[R, Durgadoss]

Hi Rui,

 -Original Message-
 From: Zhang, Rui
 Sent: Tuesday, March 26, 2013 9:56 PM
 To: linux...@vger.kernel.org; linux-kernel@vger.kernel.org
 Cc: amit.dan...@samsung.com; R, Durgadoss; a...@lisas.de; Zhang, Rui
 Subject: [RFC PATCH 3/5] Thermal: build thermal governors into thermal_sys
 module
 
 Signed-off-by: Zhang Rui rui.zh...@intel.com
 ---
  drivers/thermal/Makefile   |6 +++---
  drivers/thermal/fair_share.c   |   15 ++-
  drivers/thermal/step_wise.c|   16 ++--
  drivers/thermal/thermal_core.c |   36
 ++--
  drivers/thermal/thermal_core.h |   25 +
  drivers/thermal/user_space.c   |   15 ++-
  include/linux/thermal.h|1 -
  7 files changed, 68 insertions(+), 46 deletions(-)
 
 diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
 index b2009bd..b7fffc7 100644
 --- a/drivers/thermal/Makefile
 +++ b/drivers/thermal/Makefile
 @@ -6,9 +6,9 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
  thermal_sys-y+= thermal_core.o
 
  # governors
 -obj-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
 -obj-$(CONFIG_THERMAL_GOV_STEP_WISE)  += step_wise.o
 -obj-$(CONFIG_THERMAL_GOV_USER_SPACE) += user_space.o
 +thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) +=
 fair_share.o
 +thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)  += step_wise.o
 +thermal_sys-$(CONFIG_THERMAL_GOV_USER_SPACE) +=
 user_space.o
 
  # cpufreq cooling
  obj-$(CONFIG_CPU_THERMAL)+= cpu_cooling.o
 diff --git a/drivers/thermal/fair_share.c b/drivers/thermal/fair_share.c
 index 792479f..944ba2f 100644
 --- a/drivers/thermal/fair_share.c
 +++ b/drivers/thermal/fair_share.c
 @@ -22,9 +22,6 @@
   *
 ~~
 
   */
 
 -#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
 -
 -#include linux/module.h
  #include linux/thermal.h
 
  #include thermal_core.h
 @@ -111,23 +108,15 @@ static int fair_share_throttle(struct
 thermal_zone_device *tz, int trip)
  static struct thermal_governor thermal_gov_fair_share = {
   .name   = fair_share,
   .throttle   = fair_share_throttle,
 - .owner  = THIS_MODULE,
  };
 
 -static int __init thermal_gov_fair_share_init(void)
 +int thermal_gov_fair_share_register(void)
  {
   return thermal_register_governor(thermal_gov_fair_share);
  }
 
 -static void __exit thermal_gov_fair_share_exit(void)
 +void thermal_gov_fair_share_unregister(void)
  {
   thermal_unregister_governor(thermal_gov_fair_share);
  }
 
 -/* This should load after thermal framework */
 -fs_initcall(thermal_gov_fair_share_init);
 -module_exit(thermal_gov_fair_share_exit);
 -
 -MODULE_AUTHOR(Durgadoss R);
 -MODULE_DESCRIPTION(A simple weight based thermal throttling
 governor);
 -MODULE_LICENSE(GPL);
 diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
 index 407cde3..a6c9666 100644
 --- a/drivers/thermal/step_wise.c
 +++ b/drivers/thermal/step_wise.c
 @@ -22,9 +22,6 @@
   *
 ~~
 
   */
 
 -#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
 -
 -#include linux/module.h
  #include linux/thermal.h
 
  #include thermal_core.h
 @@ -180,23 +177,14 @@ static int step_wise_throttle(struct
 thermal_zone_device *tz, int trip)
  static struct thermal_governor thermal_gov_step_wise = {
   .name   = step_wise,
   .throttle   = step_wise_throttle,
 - .owner  = THIS_MODULE,
  };
 
 -static int __init thermal_gov_step_wise_init(void)
 +int thermal_gov_step_wise_register(void)
  {
   return thermal_register_governor(thermal_gov_step_wise);
  }
 
 -static void __exit thermal_gov_step_wise_exit(void)
 +void thermal_gov_step_wise_unregister(void)
  {
   thermal_unregister_governor(thermal_gov_step_wise);
  }
 -
 -/* This should load after thermal framework */
 -fs_initcall(thermal_gov_step_wise_init);
 -module_exit(thermal_gov_step_wise_exit);
 -
 -MODULE_AUTHOR(Durgadoss R);
 -MODULE_DESCRIPTION(A step-by-step thermal throttling governor);
 -MODULE_LICENSE(GPL);
 diff --git a/drivers/thermal/thermal_core.c
 b/drivers/thermal/thermal_core.c
 index 845ed6e..eac9745 100644
 --- a/drivers/thermal/thermal_core.c
 +++ b/drivers/thermal/thermal_core.c
 @@ -1858,22 +1858,54 @@ static inline int genetlink_init(void) { return 0; }
  static inline void genetlink_exit(void) {}
  #endif /* !CONFIG_NET */
 
 +static int __init thermal_register_governors(void)
 +{
 + int result;
 +
 + result = thermal_gov_step_wise_register();
 + if (result)

[Patches 1,2 are fine with me].

A pr_err statement here, saying the registration failed,
would help us a lot.

 + return result;
 +
 + result = thermal_gov_fair_share_register();
 + if (result)
 + return result;
 +
 + result = thermal_gov_user_space_register();

Same check + print statement for the other two as well

RE: [PATCH 1/2] thermal: introduce thermal_zone_lookup_temperature helper function

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Zhang Rui
> Sent: Monday, March 25, 2013 11:41 AM
> To: Eduardo Valentin
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] thermal: introduce
> thermal_zone_lookup_temperature helper function
> 
> On Fri, 2013-03-22 at 17:13 -0400, Eduardo Valentin wrote:
> > This patch adds a helper function to get temperature of
> > a thermal zone, based on the zone type name.
> >
> > It will perform a zone name lookup and return the last
> > sensor temperature reading. In case the zone is not found
> > or if the required parameters are invalid, it will return
> > the corresponding error code.
> >
> > Signed-off-by: Eduardo Valentin 
> > ---
> >  drivers/thermal/thermal_sys.c |   32
> 
> >  include/linux/thermal.h   |1 +
> >  2 files changed, 33 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> > index 5bd95d4..f0caa13 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -1790,6 +1790,38 @@ void thermal_zone_device_unregister(struct
> thermal_zone_device *tz)
> >  }
> >  EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
> >
> > +/**
> > + * thermal_lookup_temperature - search for a zone and returns its
> temperature
> > + * @name: thermal zone name to fetch the temperature
> > + * @temperature: pointer to store the zone temperature, in case it is
> found
> > + *
> > + * When the zone is found, updates @temperature and returns 0.
> > + *
> > + * Return: -EINVAL in case of wrong parameters, -ENODEV in case the
> zone
> > + * is not found and 0 when it is successfully found.
> > + */
> > +int thermal_zone_lookup_temperature(const char *name, int
> *temperature)
> > +{
> > +   struct thermal_zone_device *pos = NULL;
> > +   bool found = false;
> > +
> > +   if (!name || !temperature)
> > +   return -EINVAL;
> > +
> > +   mutex_lock(_list_lock);
> > +   list_for_each_entry(pos, _tz_list, node)
> > +   if (!strcmp(pos->type, name)) {
> > +   found = true;
> > +   break;
> > +   }
> > +   if (found)
> > +   *temperature = pos->last_temperature;
> > +   mutex_unlock(_list_lock);
> > +
> > +   return found ? 0 : -ENODEV;
> > +}
> > +EXPORT_SYMBOL_GPL(thermal_zone_lookup_temperature);
> > +
> please do not use thermal zone type as the parameter because unique
> thermal zone type string is not a hard rule.

Okay, agree with this. This is what I am implementing in
my changes as well.

> If this is really needed, I'd prefer two APIs instead
> 1. struct thermal_zone_device * thermal_zone_get_zone_by_name(char
> *name);
> 2. int thermal_zone_get_temperature(struct thermal_zone_device *, int
> *temperature);

Why do we need this second API?
If the driver has a 'tz' pointer, it can use tz->ops->get_temp
to retrieve the temperature, right ?

Thanks,
Durga

RE: [PATCH 1/2] thermal: introduce thermal_zone_lookup_temperature helper function

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Zhang Rui
 Sent: Monday, March 25, 2013 11:41 AM
 To: Eduardo Valentin
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org
 Subject: Re: [PATCH 1/2] thermal: introduce
 thermal_zone_lookup_temperature helper function
 
 On Fri, 2013-03-22 at 17:13 -0400, Eduardo Valentin wrote:
  This patch adds a helper function to get temperature of
  a thermal zone, based on the zone type name.
 
  It will perform a zone name lookup and return the last
  sensor temperature reading. In case the zone is not found
  or if the required parameters are invalid, it will return
  the corresponding error code.
 
  Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
  ---
   drivers/thermal/thermal_sys.c |   32
 
   include/linux/thermal.h   |1 +
   2 files changed, 33 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
  index 5bd95d4..f0caa13 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -1790,6 +1790,38 @@ void thermal_zone_device_unregister(struct
 thermal_zone_device *tz)
   }
   EXPORT_SYMBOL_GPL(thermal_zone_device_unregister);
 
  +/**
  + * thermal_lookup_temperature - search for a zone and returns its
 temperature
  + * @name: thermal zone name to fetch the temperature
  + * @temperature: pointer to store the zone temperature, in case it is
 found
  + *
  + * When the zone is found, updates @temperature and returns 0.
  + *
  + * Return: -EINVAL in case of wrong parameters, -ENODEV in case the
 zone
  + * is not found and 0 when it is successfully found.
  + */
  +int thermal_zone_lookup_temperature(const char *name, int
 *temperature)
  +{
  +   struct thermal_zone_device *pos = NULL;
  +   bool found = false;
  +
  +   if (!name || !temperature)
  +   return -EINVAL;
  +
  +   mutex_lock(thermal_list_lock);
  +   list_for_each_entry(pos, thermal_tz_list, node)
  +   if (!strcmp(pos-type, name)) {
  +   found = true;
  +   break;
  +   }
  +   if (found)
  +   *temperature = pos-last_temperature;
  +   mutex_unlock(thermal_list_lock);
  +
  +   return found ? 0 : -ENODEV;
  +}
  +EXPORT_SYMBOL_GPL(thermal_zone_lookup_temperature);
  +
 please do not use thermal zone type as the parameter because unique
 thermal zone type string is not a hard rule.

Okay, agree with this. This is what I am implementing in
my changes as well.

 If this is really needed, I'd prefer two APIs instead
 1. struct thermal_zone_device * thermal_zone_get_zone_by_name(char
 *name);
 2. int thermal_zone_get_temperature(struct thermal_zone_device *, int
 *temperature);

Why do we need this second API?
If the driver has a 'tz' pointer, it can use tz-ops-get_temp
to retrieve the temperature, right ?

Thanks,
Durga

RE: [PATCH 4/8] Thermal: Add trip point sysfs nodes for sensor

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Friday, March 01, 2013 1:21 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 4/8] Thermal: Add trip point sysfs nodes for sensor
> 
> Durga,
> 
> 
> Same comments on patch 02/08 I want to rise here:
> - Minors on strlcpy, snprintf, devm_ helpers
> - documentation in the code for these helper functions and also better
> naming..
> 
> 
> On 05-02-2013 06:46, Durgadoss R wrote:
> > This patch adds a trip point related sysfs nodes
> > for each sensor under a zone in /sys/class/thermal/zoneX/.
> > The nodes will be named, sensorX_trip_active,
> > sensorX_trip_passive, sensorX_trip_hot, sensorX_trip_critical
> > for active, passive, hot and critical trip points
> > respectively for sensorX.
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >   drivers/thermal/thermal_sys.c |  225
> -
> >   include/linux/thermal.h   |   38 ++-
> >   2 files changed, 260 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> > index bf703b1..69a60a4 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -452,6 +452,37 @@ static void thermal_zone_device_check(struct
> work_struct *work)
> > thermal_zone_device_update(tz);
> >   }
> >
> > +static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char
> *name)
> > +{
> > +   int i, indx = -EINVAL;
> > +
> > +   mutex_lock(_list_lock);
> > +   for (i = 0; i < tz->sensor_indx; i++) {
> > +   if (!strnicmp(name, kobject_name(>sensors[i]-
> >device.kobj),
> > +   THERMAL_NAME_LENGTH)) {
> > +   indx = i;
> > +   break;
> > +   }
> > +   }
> > +   mutex_unlock(_list_lock);
> > +   return indx;
> > +}
> > +
> > +static void inline __remove_trip_attr(struct thermal_zone *tz, int indx)
> I believe the preferred format would be:

Ok, will change..

> 
> static inline void __remove_trip_attr(struct thermal_zone *tz, int indx)
> 
> > +{
> > +   int i;
> > +   struct thermal_trip_attr *attr = tz->trip_attr[indx];
> > +
> > +   if (!attr)
> > +   return;
> > +
> > +   for (i = 0; i < NUM_TRIP_TYPES; i++)
> > +   device_remove_file(>device, >attrs[i].attr);
> > +
> > +   kfree(tz->trip_attr[indx]);
> > +   tz->trip_attr[indx] = NULL;
> > +}
> > +
> >   static void remove_sensor_from_zone(struct thermal_zone *tz,
> > struct thermal_sensor *ts)
> >   {
> > @@ -463,9 +494,15 @@ static void remove_sensor_from_zone(struct
> thermal_zone *tz,
> >
> > sysfs_remove_link(>device.kobj, kobject_name(
> >device.kobj));
> >
> > +   /* Remove trip point attributes associated with this sensor */
> > +   __remove_trip_attr(tz, indx);
> > +
> > /* Shift the entries in the tz->sensors array */
> > -   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
> > +   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++) {
> > tz->sensors[j] = tz->sensors[j + 1];
> > +   tz->sensor_trip[j] = tz->sensor_trip[j + 1];
> > +   tz->trip_attr[j] = tz->trip_attr[j + 1];
> > +   }
> >
> > tz->sensor_indx--;
> >   }
> > @@ -879,6 +916,99 @@ policy_show(struct device *dev, struct
> device_attribute *devattr, char *buf)
> > return sprintf(buf, "%s\n", tz->governor->name);
> >   }
> >
> > +static ssize_t
> > +active_show(struct device *dev, struct device_attribute *attr, char *buf)
> > +{
> > +   int i, indx, ret = 0;
> > +   char kobj_name[THERMAL_NAME_LENGTH];
> > +   struct thermal_zone *tz = to_zone(dev);
> > +
> > +   if (!sscanf(attr->attr.name, "sensor%d_trip_active", ))
> > +   return -EINVAL;
> > +
> > +   snprintf(kobj_name, THERMAL_NAME_LENGTH, "sensor%d", i);
> > +   indx = get_sensor_indx_by_kobj(tz, kobj_name);
> > +   if (indx < 0)
> > +   return indx;
> > +
> > +   if (tz->sensor_trip[indx]->num_active_trips <= 0)
> > +   return sprintf(buf, "\n");
> 

RE: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone structure

[R, Durgadoss]

> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> Sent: Friday, March 01, 2013 1:06 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone
> structure
> 
> Durga,
> 
> On 05-02-2013 06:46, Durgadoss R wrote:
> > This patch creates new APIs to add/remove a
> > cdev to/from a zone. This patch does not change
> > the old cooling device implementation.
> 
> Same comments on patch 02/08 I want to rise here:
> 
> - Consider using linked list
> - You may have contention on your index/cdevs array
> - overflow on your buffer (carefully check your implementation)
> - zone removal condition. can we remove zones with cdevs registered?

Yes, as I said in 02/08.

> - get_by_name, why do we need it? (at least not on this patch)

The platform drivers need this API to query the pointer for cdevs,
sensors.

Thanks,
Durga

> - Minors on strlcpy, snprintf, devm_ helpers
> - documentation in the code for these helper functions and also better
> naming..
> 
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >   drivers/thermal/thermal_sys.c |   80
> +
> >   include/linux/thermal.h   |9 +
> >   2 files changed, 89 insertions(+)
> >
> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> > index 838d4fb..bf703b1 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -57,6 +57,7 @@ static LIST_HEAD(thermal_governor_list);
> >   static DEFINE_MUTEX(thermal_list_lock);
> >   static DEFINE_MUTEX(sensor_list_lock);
> >   static DEFINE_MUTEX(zone_list_lock);
> > +static DEFINE_MUTEX(cdev_list_lock);
> >   static DEFINE_MUTEX(thermal_governor_lock);
> >
> >   #define for_each_thermal_sensor(pos) \
> > @@ -83,6 +84,9 @@ static DEFINE_MUTEX(thermal_governor_lock);
> > ret;\
> >   })
> >
> > +#define for_each_cdev(pos) \
> > +   list_for_each_entry(pos, _cdev_list, node)
> > +
> >   static struct thermal_governor *__find_governor(const char *name)
> >   {
> > struct thermal_governor *pos;
> > @@ -466,6 +470,24 @@ static void remove_sensor_from_zone(struct
> thermal_zone *tz,
> > tz->sensor_indx--;
> >   }
> >
> > +static void remove_cdev_from_zone(struct thermal_zone *tz,
> > +   struct thermal_cooling_device *cdev)
> > +{
> > +   int j, indx;
> > +
> > +   indx = GET_INDEX(tz, cdev, cdev);
> > +   if (indx < 0)
> > +   return;
> > +
> > +   sysfs_remove_link(>device.kobj, kobject_name(
> >device.kobj));
> > +
> > +   /* Shift the entries in the tz->cdevs array */
> > +   for (j = indx; j < MAX_CDEVS_PER_ZONE - 1; j++)
> > +   tz->cdevs[j] = tz->cdevs[j + 1];
> > +
> > +   tz->cdev_indx--;
> > +}
> > +
> >   /* sys I/F for thermal zone */
> >
> >   #define to_thermal_zone(_dev) \
> > @@ -1462,6 +1484,7 @@ void thermal_cooling_device_unregister(struct
> thermal_cooling_device *cdev)
> > int i;
> > const struct thermal_zone_params *tzp;
> > struct thermal_zone_device *tz;
> > +   struct thermal_zone *tmp_tz;
> > struct thermal_cooling_device *pos = NULL;
> >
> > if (!cdev)
> > @@ -1499,6 +1522,13 @@ void thermal_cooling_device_unregister(struct
> thermal_cooling_device *cdev)
> >
> > mutex_unlock(_list_lock);
> >
> > +   mutex_lock(_list_lock);
> > +
> > +   for_each_thermal_zone(tmp_tz)
> > +   remove_cdev_from_zone(tmp_tz, cdev);
> > +
> > +   mutex_unlock(_list_lock);
> > +
> > if (cdev->type[0])
> > device_remove_file(>device, _attr_cdev_type);
> > device_remove_file(>device, _attr_max_state);
> > @@ -1794,6 +1824,23 @@ exit:
> >   }
> >   EXPORT_SYMBOL(remove_thermal_zone);
> >
> > +struct thermal_cooling_device *get_cdev_by_name(const char *name)
> > +{
> > +   struct thermal_cooling_device *pos;
> > +   struct thermal_cooling_device *cdev = NULL;
> > +
> > +   mutex_lock(_list_lock);
> > +   for_each_cdev(pos) {
> > +   if (!strnicmp(pos->type, name, THERMAL_NAME_LENGTH)) {
> > +   cdev = pos;
> > +   break;
> > +   }
> > +   }
> > +   mutex_unlock(_list

RE: [PATCH 2/8] Thermal: Create zone level APIs

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Friday, March 01, 2013 1:00 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 2/8] Thermal: Create zone level APIs
> 
> On 05-02-2013 06:46, Durgadoss R wrote:
> > This patch adds a new thermal_zone structure to
> > thermal.h. Also, adds zone level APIs to the thermal
> > framework.
> >
> > A thermal zone is a hot spot on the platform, which
> > can have one or more sensors and cooling devices attached
> > to it. These sensors can be mapped to a set of cooling
> > devices, which when throttled, can help to bring down
> > the temperature of the hot spot.
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >   drivers/thermal/thermal_sys.c |  196
> +
> >   include/linux/thermal.h   |   22 +
> >   2 files changed, 218 insertions(+)
> >
> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> > index cb94497..838d4fb 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -43,19 +43,46 @@ MODULE_DESCRIPTION("Generic thermal
> management sysfs support");
> >   MODULE_LICENSE("GPL");
> >
> >   static DEFINE_IDR(thermal_tz_idr);
> > +static DEFINE_IDR(thermal_zone_idr);
> >   static DEFINE_IDR(thermal_cdev_idr);
> >   static DEFINE_IDR(thermal_sensor_idr);
> >   static DEFINE_MUTEX(thermal_idr_lock);
> >
> >   static LIST_HEAD(thermal_tz_list);
> >   static LIST_HEAD(thermal_sensor_list);
> > +static LIST_HEAD(thermal_zone_list);
> >   static LIST_HEAD(thermal_cdev_list);
> >   static LIST_HEAD(thermal_governor_list);
> >
> >   static DEFINE_MUTEX(thermal_list_lock);
> >   static DEFINE_MUTEX(sensor_list_lock);
> > +static DEFINE_MUTEX(zone_list_lock);
> >   static DEFINE_MUTEX(thermal_governor_lock);
> >
> > +#define for_each_thermal_sensor(pos) \
> > +   list_for_each_entry(pos, _sensor_list, node)
> > +
> > +#define for_each_thermal_zone(pos) \
> > +   list_for_each_entry(pos, _zone_list, node)
> > +
> > +#define GET_INDEX(tz, ptr, type)   \
> 
> Why do you need type? You seam to be using it only for sensors. It
> becomes a bit cryptic :-)

In the next patch, we use it for cooling devices also.

> 
> > +({ \
> > +   int i, ret = -EINVAL;   \
> > +   do {\
> > +   if (!tz || !ptr)\
> > +   break;  \
> > +   mutex_lock(##_list_lock);  \
> > +   for (i = 0; i < tz->type##_indx; i++) { \
> > +   if (tz->type##s[i] == ptr) {\
> > +   ret = i;\
> > +   break;  \
> > +   }   \
> > +   }   \
> > +   mutex_unlock(##_list_lock);\
> > +   } while (0);\
> > +   ret;\
> > +})
> > +
> >   static struct thermal_governor *__find_governor(const char *name)
> >   {
> > struct thermal_governor *pos;
> > @@ -421,15 +448,44 @@ static void thermal_zone_device_check(struct
> work_struct *work)
> > thermal_zone_device_update(tz);
> >   }
> >
> > +static void remove_sensor_from_zone(struct thermal_zone *tz,
> > +   struct thermal_sensor *ts)
> > +{
> > +   int j, indx;
> > +
> > +   indx = GET_INDEX(tz, ts, sensor);
> > +   if (indx < 0)
> > +   return;
> > +
> > +   sysfs_remove_link(>device.kobj, kobject_name(
> >device.kobj));
> > +
> > +   /* Shift the entries in the tz->sensors array */
> > +   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
> > +   tz->sensors[j] = tz->sensors[j + 1];
> > +
> > +   tz->sensor_indx--;
> > +}
> > +
> >   /* sys I/F for thermal zone */
> >
> >   #define to_thermal_zone(_dev) \
> > container_of(_dev, struct thermal_zone_device, device)
> >
> > +#define to_zone(_dev) \
> > +   container_of(_dev, struct ther

RE: [PATCH 2/8] Thermal: Create zone level APIs

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
 Sent: Friday, March 01, 2013 1:00 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 2/8] Thermal: Create zone level APIs
 
 On 05-02-2013 06:46, Durgadoss R wrote:
  This patch adds a new thermal_zone structure to
  thermal.h. Also, adds zone level APIs to the thermal
  framework.
 
  A thermal zone is a hot spot on the platform, which
  can have one or more sensors and cooling devices attached
  to it. These sensors can be mapped to a set of cooling
  devices, which when throttled, can help to bring down
  the temperature of the hot spot.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
drivers/thermal/thermal_sys.c |  196
 +
include/linux/thermal.h   |   22 +
2 files changed, 218 insertions(+)
 
  diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
  index cb94497..838d4fb 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -43,19 +43,46 @@ MODULE_DESCRIPTION(Generic thermal
 management sysfs support);
MODULE_LICENSE(GPL);
 
static DEFINE_IDR(thermal_tz_idr);
  +static DEFINE_IDR(thermal_zone_idr);
static DEFINE_IDR(thermal_cdev_idr);
static DEFINE_IDR(thermal_sensor_idr);
static DEFINE_MUTEX(thermal_idr_lock);
 
static LIST_HEAD(thermal_tz_list);
static LIST_HEAD(thermal_sensor_list);
  +static LIST_HEAD(thermal_zone_list);
static LIST_HEAD(thermal_cdev_list);
static LIST_HEAD(thermal_governor_list);
 
static DEFINE_MUTEX(thermal_list_lock);
static DEFINE_MUTEX(sensor_list_lock);
  +static DEFINE_MUTEX(zone_list_lock);
static DEFINE_MUTEX(thermal_governor_lock);
 
  +#define for_each_thermal_sensor(pos) \
  +   list_for_each_entry(pos, thermal_sensor_list, node)
  +
  +#define for_each_thermal_zone(pos) \
  +   list_for_each_entry(pos, thermal_zone_list, node)
  +
  +#define GET_INDEX(tz, ptr, type)   \
 
 Why do you need type? You seam to be using it only for sensors. It
 becomes a bit cryptic :-)

In the next patch, we use it for cooling devices also.

 
  +({ \
  +   int i, ret = -EINVAL;   \
  +   do {\
  +   if (!tz || !ptr)\
  +   break;  \
  +   mutex_lock(type##_list_lock);  \
  +   for (i = 0; i  tz-type##_indx; i++) { \
  +   if (tz-type##s[i] == ptr) {\
  +   ret = i;\
  +   break;  \
  +   }   \
  +   }   \
  +   mutex_unlock(type##_list_lock);\
  +   } while (0);\
  +   ret;\
  +})
  +
static struct thermal_governor *__find_governor(const char *name)
{
  struct thermal_governor *pos;
  @@ -421,15 +448,44 @@ static void thermal_zone_device_check(struct
 work_struct *work)
  thermal_zone_device_update(tz);
}
 
  +static void remove_sensor_from_zone(struct thermal_zone *tz,
  +   struct thermal_sensor *ts)
  +{
  +   int j, indx;
  +
  +   indx = GET_INDEX(tz, ts, sensor);
  +   if (indx  0)
  +   return;
  +
  +   sysfs_remove_link(tz-device.kobj, kobject_name(ts-
 device.kobj));
  +
  +   /* Shift the entries in the tz-sensors array */
  +   for (j = indx; j  MAX_SENSORS_PER_ZONE - 1; j++)
  +   tz-sensors[j] = tz-sensors[j + 1];
  +
  +   tz-sensor_indx--;
  +}
  +
/* sys I/F for thermal zone */
 
#define to_thermal_zone(_dev) \
  container_of(_dev, struct thermal_zone_device, device)
 
  +#define to_zone(_dev) \
  +   container_of(_dev, struct thermal_zone, device)
  +
#define to_thermal_sensor(_dev) \
  container_of(_dev, struct thermal_sensor, device)
 
static ssize_t
  +zone_name_show(struct device *dev, struct device_attribute *attr, char
 *buf)
  +{
  +   struct thermal_zone *tz = to_zone(dev);
  +
  +   return sprintf(buf, %s\n, tz-name);
 snprintf
 
  +}
  +
  +static ssize_t
sensor_name_show(struct device *dev, struct device_attribute *attr,
 char *buf)
{
  struct thermal_sensor *ts = to_thermal_sensor(dev);
  @@ -811,6 +867,8 @@ static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR,
 policy_show, policy_store);
static DEVICE_ATTR(sensor_name, 0444, sensor_name_show, NULL);
static DEVICE_ATTR(temp_input, 0444, sensor_temp_show, NULL);
 
  +static DEVICE_ATTR(zone_name, 0444, zone_name_show, NULL);
  +
/* sys I/F for cooling device */
#define to_cooling_device

RE: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone structure

[R, Durgadoss]

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Friday, March 01, 2013 1:06 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone
 structure
 
 Durga,
 
 On 05-02-2013 06:46, Durgadoss R wrote:
  This patch creates new APIs to add/remove a
  cdev to/from a zone. This patch does not change
  the old cooling device implementation.
 
 Same comments on patch 02/08 I want to rise here:
 
 - Consider using linked list
 - You may have contention on your index/cdevs array
 - overflow on your buffer (carefully check your implementation)
 - zone removal condition. can we remove zones with cdevs registered?

Yes, as I said in 02/08.

 - get_by_name, why do we need it? (at least not on this patch)

The platform drivers need this API to query the pointer for cdevs,
sensors.

Thanks,
Durga

 - Minors on strlcpy, snprintf, devm_ helpers
 - documentation in the code for these helper functions and also better
 naming..
 
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
drivers/thermal/thermal_sys.c |   80
 +
include/linux/thermal.h   |9 +
2 files changed, 89 insertions(+)
 
  diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
  index 838d4fb..bf703b1 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -57,6 +57,7 @@ static LIST_HEAD(thermal_governor_list);
static DEFINE_MUTEX(thermal_list_lock);
static DEFINE_MUTEX(sensor_list_lock);
static DEFINE_MUTEX(zone_list_lock);
  +static DEFINE_MUTEX(cdev_list_lock);
static DEFINE_MUTEX(thermal_governor_lock);
 
#define for_each_thermal_sensor(pos) \
  @@ -83,6 +84,9 @@ static DEFINE_MUTEX(thermal_governor_lock);
  ret;\
})
 
  +#define for_each_cdev(pos) \
  +   list_for_each_entry(pos, thermal_cdev_list, node)
  +
static struct thermal_governor *__find_governor(const char *name)
{
  struct thermal_governor *pos;
  @@ -466,6 +470,24 @@ static void remove_sensor_from_zone(struct
 thermal_zone *tz,
  tz-sensor_indx--;
}
 
  +static void remove_cdev_from_zone(struct thermal_zone *tz,
  +   struct thermal_cooling_device *cdev)
  +{
  +   int j, indx;
  +
  +   indx = GET_INDEX(tz, cdev, cdev);
  +   if (indx  0)
  +   return;
  +
  +   sysfs_remove_link(tz-device.kobj, kobject_name(cdev-
 device.kobj));
  +
  +   /* Shift the entries in the tz-cdevs array */
  +   for (j = indx; j  MAX_CDEVS_PER_ZONE - 1; j++)
  +   tz-cdevs[j] = tz-cdevs[j + 1];
  +
  +   tz-cdev_indx--;
  +}
  +
/* sys I/F for thermal zone */
 
#define to_thermal_zone(_dev) \
  @@ -1462,6 +1484,7 @@ void thermal_cooling_device_unregister(struct
 thermal_cooling_device *cdev)
  int i;
  const struct thermal_zone_params *tzp;
  struct thermal_zone_device *tz;
  +   struct thermal_zone *tmp_tz;
  struct thermal_cooling_device *pos = NULL;
 
  if (!cdev)
  @@ -1499,6 +1522,13 @@ void thermal_cooling_device_unregister(struct
 thermal_cooling_device *cdev)
 
  mutex_unlock(thermal_list_lock);
 
  +   mutex_lock(zone_list_lock);
  +
  +   for_each_thermal_zone(tmp_tz)
  +   remove_cdev_from_zone(tmp_tz, cdev);
  +
  +   mutex_unlock(zone_list_lock);
  +
  if (cdev-type[0])
  device_remove_file(cdev-device, dev_attr_cdev_type);
  device_remove_file(cdev-device, dev_attr_max_state);
  @@ -1794,6 +1824,23 @@ exit:
}
EXPORT_SYMBOL(remove_thermal_zone);
 
  +struct thermal_cooling_device *get_cdev_by_name(const char *name)
  +{
  +   struct thermal_cooling_device *pos;
  +   struct thermal_cooling_device *cdev = NULL;
  +
  +   mutex_lock(cdev_list_lock);
  +   for_each_cdev(pos) {
  +   if (!strnicmp(pos-type, name, THERMAL_NAME_LENGTH)) {
  +   cdev = pos;
  +   break;
  +   }
  +   }
  +   mutex_unlock(cdev_list_lock);
  +   return cdev;
  +}
  +EXPORT_SYMBOL(get_cdev_by_name);
  +
struct thermal_sensor *get_sensor_by_name(const char *name)
{
  struct thermal_sensor *pos;
  @@ -1844,6 +1891,39 @@ exit_zone:
}
EXPORT_SYMBOL(add_sensor_to_zone);
 
  +int add_cdev_to_zone(struct thermal_zone *tz,
  +   struct thermal_cooling_device *cdev)
  +{
  +   int ret;
  +
  +   if (!tz || !cdev)
  +   return -EINVAL;
  +
  +   mutex_lock(zone_list_lock);
  +
  +   /* Ensure we are not adding the same cdev again!! */
  +   ret = GET_INDEX(tz, cdev, cdev);
  +   if (ret = 0) {
  +   ret = -EEXIST;
  +   goto exit_zone;
  +   }
  +
  +   mutex_lock(cdev_list_lock);
  +   ret = sysfs_create_link(tz-device.kobj, cdev-device.kobj,
  +   kobject_name(cdev-device.kobj));
  +   if (ret

RE: [PATCH 4/8] Thermal: Add trip point sysfs nodes for sensor

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
 Sent: Friday, March 01, 2013 1:21 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 4/8] Thermal: Add trip point sysfs nodes for sensor
 
 Durga,
 
 
 Same comments on patch 02/08 I want to rise here:
 - Minors on strlcpy, snprintf, devm_ helpers
 - documentation in the code for these helper functions and also better
 naming..
 
 
 On 05-02-2013 06:46, Durgadoss R wrote:
  This patch adds a trip point related sysfs nodes
  for each sensor under a zone in /sys/class/thermal/zoneX/.
  The nodes will be named, sensorX_trip_active,
  sensorX_trip_passive, sensorX_trip_hot, sensorX_trip_critical
  for active, passive, hot and critical trip points
  respectively for sensorX.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
drivers/thermal/thermal_sys.c |  225
 -
include/linux/thermal.h   |   38 ++-
2 files changed, 260 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
  index bf703b1..69a60a4 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -452,6 +452,37 @@ static void thermal_zone_device_check(struct
 work_struct *work)
  thermal_zone_device_update(tz);
}
 
  +static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char
 *name)
  +{
  +   int i, indx = -EINVAL;
  +
  +   mutex_lock(sensor_list_lock);
  +   for (i = 0; i  tz-sensor_indx; i++) {
  +   if (!strnicmp(name, kobject_name(tz-sensors[i]-
 device.kobj),
  +   THERMAL_NAME_LENGTH)) {
  +   indx = i;
  +   break;
  +   }
  +   }
  +   mutex_unlock(sensor_list_lock);
  +   return indx;
  +}
  +
  +static void inline __remove_trip_attr(struct thermal_zone *tz, int indx)
 I believe the preferred format would be:

Ok, will change..

 
 static inline void __remove_trip_attr(struct thermal_zone *tz, int indx)
 
  +{
  +   int i;
  +   struct thermal_trip_attr *attr = tz-trip_attr[indx];
  +
  +   if (!attr)
  +   return;
  +
  +   for (i = 0; i  NUM_TRIP_TYPES; i++)
  +   device_remove_file(tz-device, attr-attrs[i].attr);
  +
  +   kfree(tz-trip_attr[indx]);
  +   tz-trip_attr[indx] = NULL;
  +}
  +
static void remove_sensor_from_zone(struct thermal_zone *tz,
  struct thermal_sensor *ts)
{
  @@ -463,9 +494,15 @@ static void remove_sensor_from_zone(struct
 thermal_zone *tz,
 
  sysfs_remove_link(tz-device.kobj, kobject_name(ts-
 device.kobj));
 
  +   /* Remove trip point attributes associated with this sensor */
  +   __remove_trip_attr(tz, indx);
  +
  /* Shift the entries in the tz-sensors array */
  -   for (j = indx; j  MAX_SENSORS_PER_ZONE - 1; j++)
  +   for (j = indx; j  MAX_SENSORS_PER_ZONE - 1; j++) {
  tz-sensors[j] = tz-sensors[j + 1];
  +   tz-sensor_trip[j] = tz-sensor_trip[j + 1];
  +   tz-trip_attr[j] = tz-trip_attr[j + 1];
  +   }
 
  tz-sensor_indx--;
}
  @@ -879,6 +916,99 @@ policy_show(struct device *dev, struct
 device_attribute *devattr, char *buf)
  return sprintf(buf, %s\n, tz-governor-name);
}
 
  +static ssize_t
  +active_show(struct device *dev, struct device_attribute *attr, char *buf)
  +{
  +   int i, indx, ret = 0;
  +   char kobj_name[THERMAL_NAME_LENGTH];
  +   struct thermal_zone *tz = to_zone(dev);
  +
  +   if (!sscanf(attr-attr.name, sensor%d_trip_active, i))
  +   return -EINVAL;
  +
  +   snprintf(kobj_name, THERMAL_NAME_LENGTH, sensor%d, i);
  +   indx = get_sensor_indx_by_kobj(tz, kobj_name);
  +   if (indx  0)
  +   return indx;
  +
  +   if (tz-sensor_trip[indx]-num_active_trips = 0)
  +   return sprintf(buf, Not available\n);
  +
  +   ret += sprintf(buf, 0x%x, tz-sensor_trip[indx]-active_trip_mask);
  +   for (i = 0; i  tz-sensor_trip[indx]-num_active_trips; i++) {
  +   ret += sprintf(buf + ret,  %d,
  +   tz-sensor_trip[indx]-active_trips[i]);
  +   }
  +
  +   ret += sprintf(buf + ret, \n);
  +   return ret;
  +}
  +
 
 I believe the above function violates sysfs rules, no? Each and every
 file must contain only 1 value..

Yes, re-working this and similar thing in 05/08 in next version.

Thanks,
Durga

 
  +static ssize_t
  +ptrip_show(struct device *dev, struct device_attribute *attr, char *buf)
  +{
  +   int i, indx, ret = 0;
  +   char kobj_name[THERMAL_NAME_LENGTH];
  +   struct thermal_zone *tz = to_zone(dev);
  +
  +   if (!sscanf(attr-attr.name, sensor%d_trip_passive, i))
  +   return -EINVAL;
  +
  +   snprintf(kobj_name, THERMAL_NAME_LENGTH, sensor%d, i);
  +   indx = get_sensor_indx_by_kobj(tz, kobj_name);
  +   if (indx  0

RE: [PATCHv3 0/8] Thermal Framework Enhancements

[R, Durgadoss]

Hi Eduardo,

> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> Sent: Friday, March 01, 2013 3:04 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCHv3 0/8] Thermal Framework Enhancements
> 
> 
> Durga,
> 
> 
> 
> On 05-02-2013 06:46, Durgadoss R wrote:
> > This patch set is a v3 of the previous versions submitted here:
> > [v2]: http://lwn.net/Articles/531720/
> > [v1]: https://lkml.org/lkml/2012/12/18/108
> > [RFC]:https://patchwork.kernel.org/patch/1758921/
> 
> On this version I have some implementation details which applies mostly
> for the series. So, I am replying to patch 0 to summarize:
> 
> - Consider using linked list

This I thought through on my RFC itself.
I know we have arrays, but using list adds too many members
to the structures, and protection becomes really cryptic.

> - You may have contention on your indexes and arrays
> - overflow on your buffer (carefully check your implementation)
> - zone removal condition. can we remove zones with sensors/cdevs/maps
> registered?
> - Minors on strlcpy, snprintf, devm_ helpers
> - documentation in the code for these helper functions and also better
> naming..

I will try to take care of these in my next version, as far as I can see.
But would really help if you can point the specific code that needs
improvement.

Thanks,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/8] Thermal: Create sensor level APIs

[R, Durgadoss]

Hi Eduardo,

> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
> Sent: Friday, March 01, 2013 12:29 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 1/8] Thermal: Create sensor level APIs
> 
> Durga,
> 
> On 05-02-2013 06:46, Durgadoss R wrote:
> > This patch creates sensor level APIs, in the
> > generic thermal framework.
> >
> > A Thermal sensor is a piece of hardware that can report
> > temperature of the spot in which it is placed. A thermal
> > sensor driver reads the temperature from this sensor
> > and reports it out. This kind of driver can be in
> > any subsystem. If the sensor needs to participate
> > in platform thermal management, the corresponding
> > driver can use the APIs introduced in this patch, to
> > register(or unregister) with the thermal framework.
> 
> At first glance, patch seams reasonable. But I have one major concern as
> follows inline, apart from several minor comments.
> 
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >   drivers/thermal/thermal_sys.c |  280
> +
> >   include/linux/thermal.h   |   29 +
> >   2 files changed, 309 insertions(+)
> >
> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> > index 0a1bf6b..cb94497 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -44,13 +44,16 @@ MODULE_LICENSE("GPL");
> >
> >   static DEFINE_IDR(thermal_tz_idr);
> >   static DEFINE_IDR(thermal_cdev_idr);
> > +static DEFINE_IDR(thermal_sensor_idr);
> >   static DEFINE_MUTEX(thermal_idr_lock);
> >
> >   static LIST_HEAD(thermal_tz_list);
> > +static LIST_HEAD(thermal_sensor_list);
> >   static LIST_HEAD(thermal_cdev_list);
> >   static LIST_HEAD(thermal_governor_list);
> >
> >   static DEFINE_MUTEX(thermal_list_lock);
> > +static DEFINE_MUTEX(sensor_list_lock);
> >   static DEFINE_MUTEX(thermal_governor_lock);
> >
> >   static struct thermal_governor *__find_governor(const char *name)
> > @@ -423,6 +426,103 @@ static void thermal_zone_device_check(struct
> work_struct *work)
> >   #define to_thermal_zone(_dev) \
> > container_of(_dev, struct thermal_zone_device, device)
> >
> > +#define to_thermal_sensor(_dev) \
> > +   container_of(_dev, struct thermal_sensor, device)
> > +
> > +static ssize_t
> > +sensor_name_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> > +{
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   return sprintf(buf, "%s\n", ts->name);
> 
> For security reasons:
> s/sprintf/snprintf
> 
> > +}
> > +
> > +static ssize_t
> > +sensor_temp_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> > +{
> > +   int ret;
> > +   long val;
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   ret = ts->ops->get_temp(ts, );
> > +
> > +   return ret ? ret : sprintf(buf, "%ld\n", val);
> 
> ditto.
> 
> > +}
> > +
> > +static ssize_t
> > +hyst_show(struct device *dev, struct device_attribute *attr, char *buf)
> > +{
> > +   int indx, ret;
> > +   long val;
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   if (!sscanf(attr->attr.name, "threshold%d_hyst", ))
> 
> I'd rather check if it returns 1.
> 
> > +   return -EINVAL;
> > +
> > +   ret = ts->ops->get_hyst(ts, indx, );
> 
>  From your probe, you won't check for devices registered with
> ops.get_hyst == NULL. This may lead to a NULL pointer access above.

if ops.get_hyst is NULL, we don't even create these sysfs interfaces.
This check is in enable_sensor_thresholds function.

> 
> > +
> > +   return ret ? ret : sprintf(buf, "%ld\n", val);
> 
> snprintf.
> 
> > +}
> > +
> > +static ssize_t
> > +hyst_store(struct device *dev, struct device_attribute *attr,
> > +  const char *buf, size_t count)
> > +{
> > +   int indx, ret;
> > +   long val;
> > +   struct thermal_sensor *ts = to_thermal_sensor(dev);
> > +
> > +   if (!ts->ops->set_hyst)
> > +   return -EPERM;
> > +
> > +   if (!sscanf(attr->attr.name, "threshold%d_hyst", ))
> > +   return -EINVAL;
> > +
> >

RE: [PATCH 1/8] Thermal: Create sensor level APIs

[R, Durgadoss]

Hi Eduardo,

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Friday, March 01, 2013 12:29 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 1/8] Thermal: Create sensor level APIs
 
 Durga,
 
 On 05-02-2013 06:46, Durgadoss R wrote:
  This patch creates sensor level APIs, in the
  generic thermal framework.
 
  A Thermal sensor is a piece of hardware that can report
  temperature of the spot in which it is placed. A thermal
  sensor driver reads the temperature from this sensor
  and reports it out. This kind of driver can be in
  any subsystem. If the sensor needs to participate
  in platform thermal management, the corresponding
  driver can use the APIs introduced in this patch, to
  register(or unregister) with the thermal framework.
 
 At first glance, patch seams reasonable. But I have one major concern as
 follows inline, apart from several minor comments.
 
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
drivers/thermal/thermal_sys.c |  280
 +
include/linux/thermal.h   |   29 +
2 files changed, 309 insertions(+)
 
  diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
  index 0a1bf6b..cb94497 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -44,13 +44,16 @@ MODULE_LICENSE(GPL);
 
static DEFINE_IDR(thermal_tz_idr);
static DEFINE_IDR(thermal_cdev_idr);
  +static DEFINE_IDR(thermal_sensor_idr);
static DEFINE_MUTEX(thermal_idr_lock);
 
static LIST_HEAD(thermal_tz_list);
  +static LIST_HEAD(thermal_sensor_list);
static LIST_HEAD(thermal_cdev_list);
static LIST_HEAD(thermal_governor_list);
 
static DEFINE_MUTEX(thermal_list_lock);
  +static DEFINE_MUTEX(sensor_list_lock);
static DEFINE_MUTEX(thermal_governor_lock);
 
static struct thermal_governor *__find_governor(const char *name)
  @@ -423,6 +426,103 @@ static void thermal_zone_device_check(struct
 work_struct *work)
#define to_thermal_zone(_dev) \
  container_of(_dev, struct thermal_zone_device, device)
 
  +#define to_thermal_sensor(_dev) \
  +   container_of(_dev, struct thermal_sensor, device)
  +
  +static ssize_t
  +sensor_name_show(struct device *dev, struct device_attribute *attr,
 char *buf)
  +{
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   return sprintf(buf, %s\n, ts-name);
 
 For security reasons:
 s/sprintf/snprintf
 
  +}
  +
  +static ssize_t
  +sensor_temp_show(struct device *dev, struct device_attribute *attr,
 char *buf)
  +{
  +   int ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   ret = ts-ops-get_temp(ts, val);
  +
  +   return ret ? ret : sprintf(buf, %ld\n, val);
 
 ditto.
 
  +}
  +
  +static ssize_t
  +hyst_show(struct device *dev, struct device_attribute *attr, char *buf)
  +{
  +   int indx, ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   if (!sscanf(attr-attr.name, threshold%d_hyst, indx))
 
 I'd rather check if it returns 1.
 
  +   return -EINVAL;
  +
  +   ret = ts-ops-get_hyst(ts, indx, val);
 
  From your probe, you won't check for devices registered with
 ops.get_hyst == NULL. This may lead to a NULL pointer access above.

if ops.get_hyst is NULL, we don't even create these sysfs interfaces.
This check is in enable_sensor_thresholds function.

 
  +
  +   return ret ? ret : sprintf(buf, %ld\n, val);
 
 snprintf.
 
  +}
  +
  +static ssize_t
  +hyst_store(struct device *dev, struct device_attribute *attr,
  +  const char *buf, size_t count)
  +{
  +   int indx, ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   if (!ts-ops-set_hyst)
  +   return -EPERM;
  +
  +   if (!sscanf(attr-attr.name, threshold%d_hyst, indx))
  +   return -EINVAL;
  +
  +   if (kstrtol(buf, 10, val))
  +   return -EINVAL;
  +
  +   ret = ts-ops-set_hyst(ts, indx, val);
 
  From your probe, you won't check for devices registered with
 ops.set_hyst == NULL. This may lead to a NULL pointer access above.
 
  +
  +   return ret ? ret : count;
  +}
  +
  +static ssize_t
  +threshold_show(struct device *dev, struct device_attribute *attr, char
 *buf)
  +{
  +   int indx, ret;
  +   long val;
  +   struct thermal_sensor *ts = to_thermal_sensor(dev);
  +
  +   if (!sscanf(attr-attr.name, threshold%d, indx))
  +   return -EINVAL;
  +
  +   ret = ts-ops-get_threshold(ts, indx, val);
  From your probe, you won't check for devices registered with
 ops.get_threshold == NULL. This may lead to a NULL pointer access above.

It checks for ops.get_threshold, but not for the setter method.
Will take of that in next version.

 
  +
  +   return ret ? ret : sprintf(buf, %ld\n, val);
  +}
  +
  +static ssize_t
  +threshold_store(struct device

RE: [PATCHv3 0/8] Thermal Framework Enhancements

[R, Durgadoss]

Hi Eduardo,

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@ti.com]
 Sent: Friday, March 01, 2013 3:04 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCHv3 0/8] Thermal Framework Enhancements
 
 
 Durga,
 
 
 
 On 05-02-2013 06:46, Durgadoss R wrote:
  This patch set is a v3 of the previous versions submitted here:
  [v2]: http://lwn.net/Articles/531720/
  [v1]: https://lkml.org/lkml/2012/12/18/108
  [RFC]:https://patchwork.kernel.org/patch/1758921/
 
 On this version I have some implementation details which applies mostly
 for the series. So, I am replying to patch 0 to summarize:
 
 - Consider using linked list

This I thought through on my RFC itself.
I know we have arrays, but using list adds too many members
to the structures, and protection becomes really cryptic.

 - You may have contention on your indexes and arrays
 - overflow on your buffer (carefully check your implementation)
 - zone removal condition. can we remove zones with sensors/cdevs/maps
 registered?
 - Minors on strlcpy, snprintf, devm_ helpers
 - documentation in the code for these helper functions and also better
 naming..

I will try to take care of these in my next version, as far as I can see.
But would really help if you can point the specific code that needs
improvement.

Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/8] Thermal: Create zone level APIs

[R, Durgadoss]

> -Original Message-
> From: Zhang, Rui
> Sent: Friday, February 08, 2013 3:24 PM
> To: R, Durgadoss
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: RE: [PATCH 2/8] Thermal: Create zone level APIs
> 
> On Fri, 2013-02-08 at 01:54 -0700, R, Durgadoss wrote:
> > Hi Rui,
> >
> > > -Original Message-
> > > From: Zhang, Rui
> > > Sent: Friday, February 08, 2013 1:42 PM
> > > To: R, Durgadoss
> > > Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> > > Subject: Re: [PATCH 2/8] Thermal: Create zone level APIs
> > >
> > > On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
> > > > This patch adds a new thermal_zone structure to
> > > > thermal.h. Also, adds zone level APIs to the thermal
> > > > framework.
> > > >
> >
> > [snip.]
> >
> > > > +
> > > > +struct thermal_sensor *get_sensor_by_name(const char *name)
> > > > +{
> > > > +   struct thermal_sensor *pos;
> > > > +   struct thermal_sensor *ts = NULL;
> > > > +
> > > > +   mutex_lock(_list_lock);
> > > > +   for_each_thermal_sensor(pos) {
> > > > +   if (!strnicmp(pos->name, name, THERMAL_NAME_LENGTH))
> > > {
> > > > +   ts = pos;
> > > > +   break;
> > >
> > > this function depends on the assumption that all the sensor names are
> > > unique.
> > > thus I prefer to go through all the list and return -EINVAL if duplicate
> > > names found, because in this case, the pointer returned may be not the
> > > sensor we want to get.
> >
> > Yes, I agree with you. But I prefer having this check in the register API
> > itself, which then will not allow duplicates.
> >
> No, I do not think so.
> 
> Unique cdev/sensor name is not a hard rule for generic thermal layer,
> and will not be.
> Because any cooling device driver does not have the technology that if
> its name is platform unique or not.
> 
> Say, your platform thermal driver wants to use FAN cooling device, what
> if another FAN cooling device has been registered before the FAN your
> platform thermal driver wants to use get registered?
> If the platform thermal driver wants to use get_cdev/sensor_by_name(),
> it has already made the assumption that all the cooling devices have
> unique names. Thus duplicate names are a big issue, we should abort the
> platform thermal driver, rather than aborting the cooling device driver
> with duplicate names.
> 
> > The reason being, we use this get* API (comparatively) a lot more than
> > the register APIs.
> 
> why?
> why can not invoke get_sensor/cdev_by_name once and cache the pointer
> in
> the platform thermal driver?

Okay, I did not think of this caching part ..
Then, I am fine with this change. Will fix it in next version.

Thanks,
Durga

RE: [PATCH 5/8] Thermal: Create Thermal map sysfs attributes for a zone

[R, Durgadoss]

Hi Rui,

> -Original Message-
> From: Zhang, Rui
> Sent: Friday, February 08, 2013 2:35 PM
> To: R, Durgadoss
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 5/8] Thermal: Create Thermal map sysfs attributes for a
> zone
> 
> On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
> > This patch creates a thermal map sysfs node under
> > /sys/class/thermal/zoneX/. This contains
> > entries named mapY_trip_type, mapY_sensor_name,
> > mapY_cdev_name, mapY_trip_mask, mapY_weights.
> sorry I still not quite understand.
> 
> does it look like?
> /sys/class/thermal/zoneX/
> |
> map-->|-->map0_trip_type
>   |...
>   |-->map0_weight
>   |-->map1_trip_type
>   |...
>   |-->map1_weight
>   |...
> 

There is no separate 'map' directory.
So, everything is under /sys/class/thermal/zoneX/ directly,
named as map0_weight etc...

I think I should make the Doc/ABI patch should clarify this.

Thanks,
Durga

RE: [PATCH 2/8] Thermal: Create zone level APIs

[R, Durgadoss]

Hi Rui,

> -Original Message-
> From: Zhang, Rui
> Sent: Friday, February 08, 2013 1:42 PM
> To: R, Durgadoss
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 2/8] Thermal: Create zone level APIs
> 
> On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
> > This patch adds a new thermal_zone structure to
> > thermal.h. Also, adds zone level APIs to the thermal
> > framework.
> >

[snip.]

> > +
> > +struct thermal_sensor *get_sensor_by_name(const char *name)
> > +{
> > +   struct thermal_sensor *pos;
> > +   struct thermal_sensor *ts = NULL;
> > +
> > +   mutex_lock(_list_lock);
> > +   for_each_thermal_sensor(pos) {
> > +   if (!strnicmp(pos->name, name, THERMAL_NAME_LENGTH))
> {
> > +   ts = pos;
> > +   break;
> 
> this function depends on the assumption that all the sensor names are
> unique.
> thus I prefer to go through all the list and return -EINVAL if duplicate
> names found, because in this case, the pointer returned may be not the
> sensor we want to get.

Yes, I agree with you. But I prefer having this check in the register API
itself, which then will not allow duplicates.

The reason being, we use this get* API (comparatively) a lot more than
the register APIs. And putting this check in the register APIs means doing
this check only once. Let me know what you think.

And the same for cooling devices too.

Thanks,
Durga

RE: [PATCH 1/8] Thermal: Create sensor level APIs

[R, Durgadoss]

Hi Rui,

> -Original Message-
> From: Zhang, Rui
> Sent: Friday, February 08, 2013 1:24 PM
> To: R, Durgadoss
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 1/8] Thermal: Create sensor level APIs
> 
> On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
> > This patch creates sensor level APIs, in the
> > generic thermal framework.

[snip.]

> > +
> >  static ssize_t
> >  type_show(struct device *dev, struct device_attribute *attr, char *buf)
> >  {
> > @@ -707,6 +807,10 @@ static DEVICE_ATTR(mode, 0644, mode_show,
> mode_store);
> >  static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show,
> passive_store);
> >  static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show,
> policy_store);
> >
> > +/* Thermal sensor attributes */
> > +static DEVICE_ATTR(sensor_name, 0444, sensor_name_show, NULL);
> > +static DEVICE_ATTR(temp_input, 0444, sensor_temp_show, NULL);
> > +
> >  /* sys I/F for cooling device */
> >  #define to_cooling_device(_dev)\
> > container_of(_dev, struct thermal_cooling_device, device)
> > @@ -1493,6 +1597,182 @@ static void remove_trip_attrs(struct
> thermal_zone_device *tz)
> >  }
> >
> >  /**
> > + * enable_sensor_thresholds - create sysfs nodes for thresholdX
> 
> this is a little confusing.
> I'd prefer
> thermal_sensor_sysfs_add() and create sensor_name and temp_input
> attribute in this function as well, and thermal_sensor_sysfs_remove()
> to remove the sysfs I/F.
> And further more, we can do this for thermal zones and cooling devices.

I agree, and we will change this.
Since this involves change for all standard APIs, I think it is better to submit
a separate patch to do this. What do you think ?

> 
> others look okay to me.

Thank you :-)

> 
> thanks,
> rui

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 1/8] Thermal: Create sensor level APIs

[R, Durgadoss]

Hi Rui,

 -Original Message-
 From: Zhang, Rui
 Sent: Friday, February 08, 2013 1:24 PM
 To: R, Durgadoss
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 1/8] Thermal: Create sensor level APIs
 
 On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
  This patch creates sensor level APIs, in the
  generic thermal framework.

[snip.]

  +
   static ssize_t
   type_show(struct device *dev, struct device_attribute *attr, char *buf)
   {
  @@ -707,6 +807,10 @@ static DEVICE_ATTR(mode, 0644, mode_show,
 mode_store);
   static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show,
 passive_store);
   static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show,
 policy_store);
 
  +/* Thermal sensor attributes */
  +static DEVICE_ATTR(sensor_name, 0444, sensor_name_show, NULL);
  +static DEVICE_ATTR(temp_input, 0444, sensor_temp_show, NULL);
  +
   /* sys I/F for cooling device */
   #define to_cooling_device(_dev)\
  container_of(_dev, struct thermal_cooling_device, device)
  @@ -1493,6 +1597,182 @@ static void remove_trip_attrs(struct
 thermal_zone_device *tz)
   }
 
   /**
  + * enable_sensor_thresholds - create sysfs nodes for thresholdX
 
 this is a little confusing.
 I'd prefer
 thermal_sensor_sysfs_add() and create sensor_name and temp_input
 attribute in this function as well, and thermal_sensor_sysfs_remove()
 to remove the sysfs I/F.
 And further more, we can do this for thermal zones and cooling devices.

I agree, and we will change this.
Since this involves change for all standard APIs, I think it is better to submit
a separate patch to do this. What do you think ?

 
 others look okay to me.

Thank you :-)

 
 thanks,
 rui

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 2/8] Thermal: Create zone level APIs

[R, Durgadoss]

Hi Rui,

 -Original Message-
 From: Zhang, Rui
 Sent: Friday, February 08, 2013 1:42 PM
 To: R, Durgadoss
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 2/8] Thermal: Create zone level APIs
 
 On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
  This patch adds a new thermal_zone structure to
  thermal.h. Also, adds zone level APIs to the thermal
  framework.
 

[snip.]

  +
  +struct thermal_sensor *get_sensor_by_name(const char *name)
  +{
  +   struct thermal_sensor *pos;
  +   struct thermal_sensor *ts = NULL;
  +
  +   mutex_lock(sensor_list_lock);
  +   for_each_thermal_sensor(pos) {
  +   if (!strnicmp(pos-name, name, THERMAL_NAME_LENGTH))
 {
  +   ts = pos;
  +   break;
 
 this function depends on the assumption that all the sensor names are
 unique.
 thus I prefer to go through all the list and return -EINVAL if duplicate
 names found, because in this case, the pointer returned may be not the
 sensor we want to get.

Yes, I agree with you. But I prefer having this check in the register API
itself, which then will not allow duplicates.

The reason being, we use this get* API (comparatively) a lot more than
the register APIs. And putting this check in the register APIs means doing
this check only once. Let me know what you think.

And the same for cooling devices too.

Thanks,
Durga

RE: [PATCH 5/8] Thermal: Create Thermal map sysfs attributes for a zone

[R, Durgadoss]

Hi Rui,

 -Original Message-
 From: Zhang, Rui
 Sent: Friday, February 08, 2013 2:35 PM
 To: R, Durgadoss
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 5/8] Thermal: Create Thermal map sysfs attributes for a
 zone
 
 On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
  This patch creates a thermal map sysfs node under
  /sys/class/thermal/zoneX/. This contains
  entries named mapY_trip_type, mapY_sensor_name,
  mapY_cdev_name, mapY_trip_mask, mapY_weights.
 sorry I still not quite understand.
 
 does it look like?
 /sys/class/thermal/zoneX/
 |
 map--|--map0_trip_type
   |...
   |--map0_weight
   |--map1_trip_type
   |...
   |--map1_weight
   |...
 

There is no separate 'map' directory.
So, everything is under /sys/class/thermal/zoneX/ directly,
named as map0_weight etc...

I think I should make the Doc/ABI patch should clarify this.

Thanks,
Durga

RE: [PATCH 2/8] Thermal: Create zone level APIs

[R, Durgadoss]

 -Original Message-
 From: Zhang, Rui
 Sent: Friday, February 08, 2013 3:24 PM
 To: R, Durgadoss
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: RE: [PATCH 2/8] Thermal: Create zone level APIs
 
 On Fri, 2013-02-08 at 01:54 -0700, R, Durgadoss wrote:
  Hi Rui,
 
   -Original Message-
   From: Zhang, Rui
   Sent: Friday, February 08, 2013 1:42 PM
   To: R, Durgadoss
   Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
   eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
   Subject: Re: [PATCH 2/8] Thermal: Create zone level APIs
  
   On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
This patch adds a new thermal_zone structure to
thermal.h. Also, adds zone level APIs to the thermal
framework.
   
 
  [snip.]
 
+
+struct thermal_sensor *get_sensor_by_name(const char *name)
+{
+   struct thermal_sensor *pos;
+   struct thermal_sensor *ts = NULL;
+
+   mutex_lock(sensor_list_lock);
+   for_each_thermal_sensor(pos) {
+   if (!strnicmp(pos-name, name, THERMAL_NAME_LENGTH))
   {
+   ts = pos;
+   break;
  
   this function depends on the assumption that all the sensor names are
   unique.
   thus I prefer to go through all the list and return -EINVAL if duplicate
   names found, because in this case, the pointer returned may be not the
   sensor we want to get.
 
  Yes, I agree with you. But I prefer having this check in the register API
  itself, which then will not allow duplicates.
 
 No, I do not think so.
 
 Unique cdev/sensor name is not a hard rule for generic thermal layer,
 and will not be.
 Because any cooling device driver does not have the technology that if
 its name is platform unique or not.
 
 Say, your platform thermal driver wants to use FAN cooling device, what
 if another FAN cooling device has been registered before the FAN your
 platform thermal driver wants to use get registered?
 If the platform thermal driver wants to use get_cdev/sensor_by_name(),
 it has already made the assumption that all the cooling devices have
 unique names. Thus duplicate names are a big issue, we should abort the
 platform thermal driver, rather than aborting the cooling device driver
 with duplicate names.
 
  The reason being, we use this get* API (comparatively) a lot more than
  the register APIs.
 
 why?
 why can not invoke get_sensor/cdev_by_name once and cache the pointer
 in
 the platform thermal driver?

Okay, I did not think of this caching part ..
Then, I am fine with this change. Will fix it in next version.

Thanks,
Durga

RE: [PATCHv2 0/9] Thermal Framework Enhancements

[R, Durgadoss]

Hi Wei,

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Wei Ni
> Sent: Monday, February 04, 2013 11:10 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org
> Subject: Re: [PATCHv2 0/9] Thermal Framework Enhancements
> 
> On 01/07/2013 03:13 PM, Durgadoss R wrote:
> > This patch set is a v2 of the previous versions submitted here:
> > [v1]:  https://lkml.org/lkml/2012/12/18/108
> > [RFC]: https://patchwork.kernel.org/patch/1758921/
> >
> > This patch set is based on Rui's -thermal tree, and is
> > tested on a Core-i5 and an Atom netbook.
> >
> > Changes Since v1:
> >  * Removed kobject creation for thermal_trip and thermal_map
> >nodes as per Greg-KH's comments.
> >  * Added ABI Documentation under 'testing'.
> >  * Modified the GET_INDEX macro to be more linux-like, thanks
> >to Joe Perches.
> >  * Added get_[sensor/cdev]_by_name APIs to thermal.h
> 
> Hi, Durgadoss and Rui
> Will these patches be merged to next branch? or will you send out next
> version?

Yes, I have to send the v3, with some small changes on the patch 5/9
(map sysfs node..) and others won't have any changes.

> I wish to use this new framework, could I send out patches for RFC based
> on this serial patches?

So, if your patch set does not need 5/9, you can send your RFC.

Thanks,
Durga

> 
> Thanks.
> Wei.
> 
> >
> > This series contains 9 patches:
> > Patch 1/9: Creates new sensor level APIs
> > Patch 2/9: Creates new zone level APIs. The existing tzd structure is
> >kept as such for clarity and compatibility purposes.
> > Patch 3/9: Creates functions to add/remove a cdev to/from a zone. The
> >existing tcd structure need not be modified.
> > Patch 4/9: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
> >under /sys/class/thermal/zoneY/. This exposes various trip
> >points for sensorX present in zoneY.
> > Patch 5/9: Adds mapX sysfs node. It is a compact representation
> >of the binding relationship between a sensor and a cdev,
> >within a zone.
> > Patch 6/9: Creates Documentation for the new APIs. A new file is
> >created for clarity. Final goal is to merge with the existing
> >file or refactor the files, as whatever seems appropriate.
> > Patch 7/9: Make PER ZONE values configurable through Kconfig
> > Patch 8/9: Add ABI documentation for sysfs interfaces introduced in this
> patch.
> > Patch 9/9: A dummy driver that can be used for testing. This is not for
> merge.
> >
> > Thanks to Greg-KH, Hongbo Zhang and Joe Perches for their comments on
> v1.
> >
> > Durgadoss R (9):
> >   Thermal: Create sensor level APIs
> >   Thermal: Create zone level APIs
> >   Thermal: Add APIs to bind cdev to new zone structure
> >   Thermal: Add trip point sysfs nodes for sensor
> >   Thermal: Create 'mapX' sysfs node for a zone
> >   Thermal: Add Documentation to new APIs
> >   Thermal: Make PER_ZONE values configurable
> >   Thermal: Add ABI Documentation for sysfs interfaces
> >   Thermal: Dummy driver used for testing
> >
> >  Documentation/ABI/testing/sysfs-class-thermal |   93 +++
> >  Documentation/thermal/sysfs-api2.txt  |  248 +++
> >  drivers/thermal/Kconfig   |   19 +
> >  drivers/thermal/Makefile  |3 +
> >  drivers/thermal/thermal_sys.c |  881
> +
> >  drivers/thermal/thermal_test.c|  315 +
> >  include/linux/thermal.h   |  117 +++-
> >  7 files changed, 1675 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
> >  create mode 100644 Documentation/thermal/sysfs-api2.txt
> >  create mode 100644 drivers/thermal/thermal_test.c
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv2 0/9] Thermal Framework Enhancements

[R, Durgadoss]

Hi Wei,

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Wei Ni
 Sent: Monday, February 04, 2013 11:10 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org
 Subject: Re: [PATCHv2 0/9] Thermal Framework Enhancements
 
 On 01/07/2013 03:13 PM, Durgadoss R wrote:
  This patch set is a v2 of the previous versions submitted here:
  [v1]:  https://lkml.org/lkml/2012/12/18/108
  [RFC]: https://patchwork.kernel.org/patch/1758921/
 
  This patch set is based on Rui's -thermal tree, and is
  tested on a Core-i5 and an Atom netbook.
 
  Changes Since v1:
   * Removed kobject creation for thermal_trip and thermal_map
 nodes as per Greg-KH's comments.
   * Added ABI Documentation under 'testing'.
   * Modified the GET_INDEX macro to be more linux-like, thanks
 to Joe Perches.
   * Added get_[sensor/cdev]_by_name APIs to thermal.h
 
 Hi, Durgadoss and Rui
 Will these patches be merged to next branch? or will you send out next
 version?

Yes, I have to send the v3, with some small changes on the patch 5/9
(map sysfs node..) and others won't have any changes.

 I wish to use this new framework, could I send out patches for RFC based
 on this serial patches?

So, if your patch set does not need 5/9, you can send your RFC.

Thanks,
Durga

 
 Thanks.
 Wei.
 
 
  This series contains 9 patches:
  Patch 1/9: Creates new sensor level APIs
  Patch 2/9: Creates new zone level APIs. The existing tzd structure is
 kept as such for clarity and compatibility purposes.
  Patch 3/9: Creates functions to add/remove a cdev to/from a zone. The
 existing tcd structure need not be modified.
  Patch 4/9: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
 under /sys/class/thermal/zoneY/. This exposes various trip
 points for sensorX present in zoneY.
  Patch 5/9: Adds mapX sysfs node. It is a compact representation
 of the binding relationship between a sensor and a cdev,
 within a zone.
  Patch 6/9: Creates Documentation for the new APIs. A new file is
 created for clarity. Final goal is to merge with the existing
 file or refactor the files, as whatever seems appropriate.
  Patch 7/9: Make PER ZONE values configurable through Kconfig
  Patch 8/9: Add ABI documentation for sysfs interfaces introduced in this
 patch.
  Patch 9/9: A dummy driver that can be used for testing. This is not for
 merge.
 
  Thanks to Greg-KH, Hongbo Zhang and Joe Perches for their comments on
 v1.
 
  Durgadoss R (9):
Thermal: Create sensor level APIs
Thermal: Create zone level APIs
Thermal: Add APIs to bind cdev to new zone structure
Thermal: Add trip point sysfs nodes for sensor
Thermal: Create 'mapX' sysfs node for a zone
Thermal: Add Documentation to new APIs
Thermal: Make PER_ZONE values configurable
Thermal: Add ABI Documentation for sysfs interfaces
Thermal: Dummy driver used for testing
 
   Documentation/ABI/testing/sysfs-class-thermal |   93 +++
   Documentation/thermal/sysfs-api2.txt  |  248 +++
   drivers/thermal/Kconfig   |   19 +
   drivers/thermal/Makefile  |3 +
   drivers/thermal/thermal_sys.c |  881
 +
   drivers/thermal/thermal_test.c|  315 +
   include/linux/thermal.h   |  117 +++-
   7 files changed, 1675 insertions(+), 1 deletion(-)
   create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
   create mode 100644 Documentation/thermal/sysfs-api2.txt
   create mode 100644 drivers/thermal/thermal_test.c
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] Thermal: Fix to use read critical temperature when required

[R, Durgadoss]

> -Original Message-
> From: Zhang, Rui
> Sent: Friday, February 01, 2013 11:14 AM
> To: Amit Daniel Kachhap
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss
> Subject: Re: [PATCH] Thermal: Fix to use read critical temperature when
> required
> 
> On Tue, 2013-01-08 at 16:18 -0800, Amit Daniel Kachhap wrote:
> > This patch modifies the code to use get_crit_temp instead of
> > the normal get_trip_temp when critical threshold point is crossed
> > or queried about.
> >
> 
> is there any problem in the current code?
> 
> > Signed-off-by: Amit Daniel Kachhap 
> > ---
> >  drivers/thermal/thermal_sys.c |   15 +--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> > index ecdfc7d..0dc6403 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -345,7 +345,10 @@ static void handle_critical_trips(struct
> thermal_zone_device *tz,
> >  {
> > long trip_temp;
> >
> > -   tz->ops->get_trip_temp(tz, trip, _temp);
> > +   if (tz->ops->get_crit_temp)
> > +   tz->ops->get_crit_temp(tz, _temp);
> > +   else
> > +   tz->ops->get_trip_temp(tz, trip, _temp);
> >
> handle_critical_trips() can handle both active and hot trip points.
> this change will break HOT trip point.
> 
> > /* If we have not crossed the trip_temp, we do not care. */
> > if (tz->temperature < trip_temp)
> > @@ -550,6 +553,7 @@ trip_point_temp_show(struct device *dev, struct
> device_attribute *attr,
> > struct thermal_zone_device *tz = to_thermal_zone(dev);
> > int trip, ret;
> > long temperature;
> > +   enum thermal_trip_type type;
> >
> > if (!tz->ops->get_trip_temp)
> > return -EPERM;
> > @@ -557,7 +561,14 @@ trip_point_temp_show(struct device *dev, struct
> device_attribute *attr,
> > if (!sscanf(attr->attr.name, "trip_point_%d_temp", ))
> > return -EINVAL;
> >
> > -   ret = tz->ops->get_trip_temp(tz, trip, );
> > +   ret = tz->ops->get_trip_type(tz, trip, );
> > +   if (ret)
> > +   return ret;
> > +
> > +   if (type == THERMAL_TRIP_CRITICAL && tz->ops->get_crit_temp)
> > +   ret = tz->ops->get_crit_temp(tz, );
> > +   else
> > +   ret = tz->ops->get_trip_temp(tz, trip, );
> >
> 
> what's the benefit of using .get_crit_temp() instead of .get_trip_temp()
> for CRITICAL trip points here?
> .get_trip_point can also get the critical trip point temperature.
> 
> instead, I think we could remove .get_crit_temp callback.

I agree with you Rui here :-)

> for hwmon sysfs, we just need to use get_trip_type to find the critical
> trip point.

Yes, this should work.

Thanks,
Durga

RE: [PATCH] Thermal: Fix to use read critical temperature when required

[R, Durgadoss]

 -Original Message-
 From: Zhang, Rui
 Sent: Friday, February 01, 2013 11:14 AM
 To: Amit Daniel Kachhap
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss
 Subject: Re: [PATCH] Thermal: Fix to use read critical temperature when
 required
 
 On Tue, 2013-01-08 at 16:18 -0800, Amit Daniel Kachhap wrote:
  This patch modifies the code to use get_crit_temp instead of
  the normal get_trip_temp when critical threshold point is crossed
  or queried about.
 
 
 is there any problem in the current code?
 
  Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
  ---
   drivers/thermal/thermal_sys.c |   15 +--
   1 file changed, 13 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
  index ecdfc7d..0dc6403 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -345,7 +345,10 @@ static void handle_critical_trips(struct
 thermal_zone_device *tz,
   {
  long trip_temp;
 
  -   tz-ops-get_trip_temp(tz, trip, trip_temp);
  +   if (tz-ops-get_crit_temp)
  +   tz-ops-get_crit_temp(tz, trip_temp);
  +   else
  +   tz-ops-get_trip_temp(tz, trip, trip_temp);
 
 handle_critical_trips() can handle both active and hot trip points.
 this change will break HOT trip point.
 
  /* If we have not crossed the trip_temp, we do not care. */
  if (tz-temperature  trip_temp)
  @@ -550,6 +553,7 @@ trip_point_temp_show(struct device *dev, struct
 device_attribute *attr,
  struct thermal_zone_device *tz = to_thermal_zone(dev);
  int trip, ret;
  long temperature;
  +   enum thermal_trip_type type;
 
  if (!tz-ops-get_trip_temp)
  return -EPERM;
  @@ -557,7 +561,14 @@ trip_point_temp_show(struct device *dev, struct
 device_attribute *attr,
  if (!sscanf(attr-attr.name, trip_point_%d_temp, trip))
  return -EINVAL;
 
  -   ret = tz-ops-get_trip_temp(tz, trip, temperature);
  +   ret = tz-ops-get_trip_type(tz, trip, type);
  +   if (ret)
  +   return ret;
  +
  +   if (type == THERMAL_TRIP_CRITICAL  tz-ops-get_crit_temp)
  +   ret = tz-ops-get_crit_temp(tz, temperature);
  +   else
  +   ret = tz-ops-get_trip_temp(tz, trip, temperature);
 
 
 what's the benefit of using .get_crit_temp() instead of .get_trip_temp()
 for CRITICAL trip points here?
 .get_trip_point can also get the critical trip point temperature.
 
 instead, I think we could remove .get_crit_temp callback.

I agree with you Rui here :-)

 for hwmon sysfs, we just need to use get_trip_type to find the critical
 trip point.

Yes, this should work.

Thanks,
Durga

RE: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Greg KH
> Sent: Tuesday, January 08, 2013 12:51 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone
> 
> On Mon, Jan 07, 2013 at 12:43:22PM +0530, Durgadoss R wrote:
> > This patch creates a thermal map sysfs node under
> > /sys/class/thermal/zoneX/. This contains
> > entries named map0, map1 .. mapN. Each map has the
> > following space separated values:
> > trip_type sensor_name cdev_name trip_mask weights
> 
> sysfs file are always "one value per file".  This seems to violate that
> rule, so please rework this.

These values together represent the binding information of
sensors and cooling devices in a zone. That's why we put
them in a single file.

>From our previous discussion, I understand we can support
a lot of nodes in sysfs. So, I will work with Rui to see how we can
split this in a meaningful way.

Something like:
map0_trip_type
map0_sensor_name
map0_cdev_name
map0_mask
etc..

Rui, What do you think ?

Thanks,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[R, Durgadoss]

Hi Greg,

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, January 09, 2013 10:30 PM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> 
> On Wed, Jan 09, 2013 at 09:12:29AM +, R, Durgadoss wrote:
> > Hi Greg,
> >
> > > -Original Message-
> > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > > Sent: Tuesday, January 08, 2013 12:54 AM
> > > To: R, Durgadoss
> > > Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> > > Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> > >
> > > On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
> > > > This patch makes MAX_SENSORS_PER_ZONE and
> > > > MAX_CDEVS_PER_ZONE values configurable. The
> > > > default value is 1, and range is 1-12.
> > >
> > > Why would we ever want to change this?  Why make this configurable at
> > > all, how is a distro supposed to set this value?
> > >
> > > Shouldn't it be specified from the driver itself?
> >
> > These are platform level parameters, that can differ for various platforms.
> > (Mostly due to board design and thermistor layouts). Stand-alone thermal
> > sensor drivers are not (need not be) aware of these values.
> 
> Ok, and how does anyone know how to set them properly?
> 
> > That's why these values are made configurable.
> 
> Pushing work onto other people, without telling them what they need to
> do, isn't nice.  Please, either make it auto-configurable, or don't make
> it configurable at all.  As it is, this is useless for a distro, or any
> "normal" user, right?

These values are for OEM's to configure according to their platform design.
So, not making them configurable won't be good IMHO.

But, as you said, for normal users, it does not matter; so they can
leave it as it is, which will set it to the default value (i.e 1).

Thanks,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[R, Durgadoss]

Hi Greg,

 -Original Message-
 From: Greg KH [mailto:gre...@linuxfoundation.org]
 Sent: Wednesday, January 09, 2013 10:30 PM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
 
 On Wed, Jan 09, 2013 at 09:12:29AM +, R, Durgadoss wrote:
  Hi Greg,
 
   -Original Message-
   From: Greg KH [mailto:gre...@linuxfoundation.org]
   Sent: Tuesday, January 08, 2013 12:54 AM
   To: R, Durgadoss
   Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
   eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
   Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
  
   On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
This patch makes MAX_SENSORS_PER_ZONE and
MAX_CDEVS_PER_ZONE values configurable. The
default value is 1, and range is 1-12.
  
   Why would we ever want to change this?  Why make this configurable at
   all, how is a distro supposed to set this value?
  
   Shouldn't it be specified from the driver itself?
 
  These are platform level parameters, that can differ for various platforms.
  (Mostly due to board design and thermistor layouts). Stand-alone thermal
  sensor drivers are not (need not be) aware of these values.
 
 Ok, and how does anyone know how to set them properly?
 
  That's why these values are made configurable.
 
 Pushing work onto other people, without telling them what they need to
 do, isn't nice.  Please, either make it auto-configurable, or don't make
 it configurable at all.  As it is, this is useless for a distro, or any
 normal user, right?

These values are for OEM's to configure according to their platform design.
So, not making them configurable won't be good IMHO.

But, as you said, for normal users, it does not matter; so they can
leave it as it is, which will set it to the default value (i.e 1).

Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Greg KH
 Sent: Tuesday, January 08, 2013 12:51 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 5/9] Thermal: Create 'mapX' sysfs node for a zone
 
 On Mon, Jan 07, 2013 at 12:43:22PM +0530, Durgadoss R wrote:
  This patch creates a thermal map sysfs node under
  /sys/class/thermal/zoneX/. This contains
  entries named map0, map1 .. mapN. Each map has the
  following space separated values:
  trip_type sensor_name cdev_name trip_mask weights
 
 sysfs file are always one value per file.  This seems to violate that
 rule, so please rework this.

These values together represent the binding information of
sensors and cooling devices in a zone. That's why we put
them in a single file.

From our previous discussion, I understand we can support
a lot of nodes in sysfs. So, I will work with Rui to see how we can
split this in a meaningful way.

Something like:
map0_trip_type
map0_sensor_name
map0_cdev_name
map0_mask
etc..

Rui, What do you think ?

Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone structure

[R, Durgadoss]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, January 08, 2013 12:56 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone
> structure
> 
> On Mon, Jan 07, 2013 at 12:43:20PM +0530, Durgadoss R wrote:
> > +struct thermal_cooling_device *get_cdev_by_name(const char *name)
> > +{
> > +   struct thermal_cooling_device *pos;
> > +   struct thermal_cooling_device *cdev = NULL;
> > +
> > +   mutex_lock(_list_lock);
> > +   for_each_cdev(pos) {
> > +   if (!strnicmp(pos->type, name, THERMAL_NAME_LENGTH)) {
> > +   cdev = pos;
> > +   break;
> > +   }
> > +   }
> > +   mutex_unlock(_list_lock);
> > +   return cdev;
> > +}
> > +EXPORT_SYMBOL(get_cdev_by_name);
> 
> EXPORT_SYMBOL_GPL?

We have all other exports as EXPORT_SYMBOL in this file(thermal_sys.c)
If _GPL is required, the we will do a single patch changing all of them to
EXPORT_SYMBOL_GPL.

> 
> You also forgot to increment the reference count, which is required for
> all reference counted objects.

Sorry, I could not get what you are saying here.

Thanks,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[R, Durgadoss]

Hi Greg,

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, January 08, 2013 12:54 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
> Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
> 
> On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
> > This patch makes MAX_SENSORS_PER_ZONE and
> > MAX_CDEVS_PER_ZONE values configurable. The
> > default value is 1, and range is 1-12.
> 
> Why would we ever want to change this?  Why make this configurable at
> all, how is a distro supposed to set this value?
> 
> Shouldn't it be specified from the driver itself?

These are platform level parameters, that can differ for various platforms.
(Mostly due to board design and thermistor layouts). Stand-alone thermal
sensor drivers are not (need not be) aware of these values.
That's why these values are made configurable.

Thanks,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 7/9] Thermal: Make PER_ZONE values configurable

[R, Durgadoss]

Hi Greg,

 -Original Message-
 From: Greg KH [mailto:gre...@linuxfoundation.org]
 Sent: Tuesday, January 08, 2013 12:54 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 7/9] Thermal: Make PER_ZONE values configurable
 
 On Mon, Jan 07, 2013 at 12:43:24PM +0530, Durgadoss R wrote:
  This patch makes MAX_SENSORS_PER_ZONE and
  MAX_CDEVS_PER_ZONE values configurable. The
  default value is 1, and range is 1-12.
 
 Why would we ever want to change this?  Why make this configurable at
 all, how is a distro supposed to set this value?
 
 Shouldn't it be specified from the driver itself?

These are platform level parameters, that can differ for various platforms.
(Mostly due to board design and thermistor layouts). Stand-alone thermal
sensor drivers are not (need not be) aware of these values.
That's why these values are made configurable.

Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone structure

[R, Durgadoss]

 -Original Message-
 From: Greg KH [mailto:gre...@linuxfoundation.org]
 Sent: Tuesday, January 08, 2013 12:56 AM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org; w...@nvidia.com
 Subject: Re: [PATCH 3/9] Thermal: Add APIs to bind cdev to new zone
 structure
 
 On Mon, Jan 07, 2013 at 12:43:20PM +0530, Durgadoss R wrote:
  +struct thermal_cooling_device *get_cdev_by_name(const char *name)
  +{
  +   struct thermal_cooling_device *pos;
  +   struct thermal_cooling_device *cdev = NULL;
  +
  +   mutex_lock(cdev_list_lock);
  +   for_each_cdev(pos) {
  +   if (!strnicmp(pos-type, name, THERMAL_NAME_LENGTH)) {
  +   cdev = pos;
  +   break;
  +   }
  +   }
  +   mutex_unlock(cdev_list_lock);
  +   return cdev;
  +}
  +EXPORT_SYMBOL(get_cdev_by_name);
 
 EXPORT_SYMBOL_GPL?

We have all other exports as EXPORT_SYMBOL in this file(thermal_sys.c)
If _GPL is required, the we will do a single patch changing all of them to
EXPORT_SYMBOL_GPL.

 
 You also forgot to increment the reference count, which is required for
 all reference counted objects.

Sorry, I could not get what you are saying here.

Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 6/9] Thermal: Add Documentation to new APIs

[R, Durgadoss]

> -Original Message-
> From: Wei Ni [mailto:w...@nvidia.com]
> Sent: Monday, January 07, 2013 2:10 PM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org
> Subject: Re: [PATCH 6/9] Thermal: Add Documentation to new APIs
> 
> On 01/07/2013 03:13 PM, Durgadoss R wrote:
> > This patch adds Documentation for the new APIs
> > introduced in this patch set. The documentation
> > also has a model sysfs structure for reference.
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >  Documentation/thermal/sysfs-api2.txt |  248
> ++
> >  1 file changed, 248 insertions(+)
> >  create mode 100644 Documentation/thermal/sysfs-api2.txt
> >
> > diff --git a/Documentation/thermal/sysfs-api2.txt
> b/Documentation/thermal/sysfs-api2.txt
> > new file mode 100644
> > index 000..ffd0402
> > --- /dev/null
> > +++ b/Documentation/thermal/sysfs-api2.txt
> > @@ -0,0 +1,248 @@
> > +Thermal Framework
> > +-
> > +
> > +Written by Durgadoss R 
> > +Copyright (c) 2012 Intel Corporation
> > +
> > +Created on: 4 November 2012
> > +Updated on: 18 December 2012
> > +
> > +0. Introduction
> > +---
> > +The Linux thermal framework provides a set of interfaces for thermal
> > +sensors and thermal cooling devices (fan, processor...) to register
> > +with the thermal management solution and to be a part of it.
> > +
> > +This document focuses on how to enable new thermal sensors and
> cooling
> > +devices to participate in thermal management. This solution is intended
> > +to be 'light-weight' and platform/architecture independent. Any thermal
> > +sensor/cooling device should be able to use the infrastructure easily.
> > +
> > +The goal of thermal framework is to expose the thermal sensor/zone and
> > +cooling device attributes in a consistent way. This will help the
> > +thermal governors to make use of the information to manage platform
> > +thermals efficiently.
> > +
> > +The thermal sensor source file can be generic (can be any sensor driver,
> > +in any subsystem). This driver will use the sensor APIs and register with
> > +thermal framework to participate in platform Thermal management. This
> > +does not (and should not) know about which zone it belongs to, or any
> > +other information about platform thermals. A sensor driver is a
> standalone
> > +piece of code, which can optionally register with thermal framework.
> > +
> > +However, for any platform, there should be a platformX_thermal.c file,
> > +which will know about the platform thermal characteristics (like how many
> > +sensors, zones, cooling devices, etc.. And how they are related to each
> other
> > +i.e the mapping information). Only in this file, the zone level APIs should
> > +be used, in which case the file will have all information required to 
> > attach
> > +various sensors to a particular zone.
> > +
> > +This way, we can have one platform level thermal file, which can support
> > +multiple platforms (may be)using the same set of sensors (but)binded in
> > +a different way. This file can get the platform thermal information
> > +through Firmware, ACPI tables, device tree etc.
> > +
> > +Unfortunately, today we don't have many drivers that can be clearly
> > +differentiated as 'sensor_file.c' and 'platform_thermal_file.c'.
> > +But very soon we will need/have. The reason I am saying this is because
> > +we are seeing a lot of chip drivers, starting to use thermal framework,
> > +and we should keep it really light-weight for them to do so.
> > +
> > +An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver
> > +In one platform this sensor can belong to 'ZoneA' and in another the
> > +same can belong to 'ZoneB'. But, emc1403.c does not really care about
> > +where does it belong. It just reports temperature.
> > +
> > +1. Terminology
> > +--
> > +This section describes the terminology used in the rest of this
> > +document as well as the thermal framework code.
> > +
> > +thermal_sensor: Hardware that can report temperature of a particular
> > +   spot in the platform, where it is placed. The temperature
> > +   reported by the sensor is the 'real' temperature reported
> > +   by the hardware.
> > +thermal_zone:  A virtual area on the device, that gets heated up. It may
> > +   have one or more thermal sensors att

RE: [PATCH 6/9] Thermal: Add Documentation to new APIs

[R, Durgadoss]

 -Original Message-
 From: Wei Ni [mailto:w...@nvidia.com]
 Sent: Monday, January 07, 2013 2:10 PM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 eduardo.valen...@ti.com; hongbo.zh...@linaro.org
 Subject: Re: [PATCH 6/9] Thermal: Add Documentation to new APIs
 
 On 01/07/2013 03:13 PM, Durgadoss R wrote:
  This patch adds Documentation for the new APIs
  introduced in this patch set. The documentation
  also has a model sysfs structure for reference.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
   Documentation/thermal/sysfs-api2.txt |  248
 ++
   1 file changed, 248 insertions(+)
   create mode 100644 Documentation/thermal/sysfs-api2.txt
 
  diff --git a/Documentation/thermal/sysfs-api2.txt
 b/Documentation/thermal/sysfs-api2.txt
  new file mode 100644
  index 000..ffd0402
  --- /dev/null
  +++ b/Documentation/thermal/sysfs-api2.txt
  @@ -0,0 +1,248 @@
  +Thermal Framework
  +-
  +
  +Written by Durgadoss R durgados...@intel.com
  +Copyright (c) 2012 Intel Corporation
  +
  +Created on: 4 November 2012
  +Updated on: 18 December 2012
  +
  +0. Introduction
  +---
  +The Linux thermal framework provides a set of interfaces for thermal
  +sensors and thermal cooling devices (fan, processor...) to register
  +with the thermal management solution and to be a part of it.
  +
  +This document focuses on how to enable new thermal sensors and
 cooling
  +devices to participate in thermal management. This solution is intended
  +to be 'light-weight' and platform/architecture independent. Any thermal
  +sensor/cooling device should be able to use the infrastructure easily.
  +
  +The goal of thermal framework is to expose the thermal sensor/zone and
  +cooling device attributes in a consistent way. This will help the
  +thermal governors to make use of the information to manage platform
  +thermals efficiently.
  +
  +The thermal sensor source file can be generic (can be any sensor driver,
  +in any subsystem). This driver will use the sensor APIs and register with
  +thermal framework to participate in platform Thermal management. This
  +does not (and should not) know about which zone it belongs to, or any
  +other information about platform thermals. A sensor driver is a
 standalone
  +piece of code, which can optionally register with thermal framework.
  +
  +However, for any platform, there should be a platformX_thermal.c file,
  +which will know about the platform thermal characteristics (like how many
  +sensors, zones, cooling devices, etc.. And how they are related to each
 other
  +i.e the mapping information). Only in this file, the zone level APIs should
  +be used, in which case the file will have all information required to 
  attach
  +various sensors to a particular zone.
  +
  +This way, we can have one platform level thermal file, which can support
  +multiple platforms (may be)using the same set of sensors (but)binded in
  +a different way. This file can get the platform thermal information
  +through Firmware, ACPI tables, device tree etc.
  +
  +Unfortunately, today we don't have many drivers that can be clearly
  +differentiated as 'sensor_file.c' and 'platform_thermal_file.c'.
  +But very soon we will need/have. The reason I am saying this is because
  +we are seeing a lot of chip drivers, starting to use thermal framework,
  +and we should keep it really light-weight for them to do so.
  +
  +An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver
  +In one platform this sensor can belong to 'ZoneA' and in another the
  +same can belong to 'ZoneB'. But, emc1403.c does not really care about
  +where does it belong. It just reports temperature.
  +
  +1. Terminology
  +--
  +This section describes the terminology used in the rest of this
  +document as well as the thermal framework code.
  +
  +thermal_sensor: Hardware that can report temperature of a particular
  +   spot in the platform, where it is placed. The temperature
  +   reported by the sensor is the 'real' temperature reported
  +   by the hardware.
  +thermal_zone:  A virtual area on the device, that gets heated up. It may
  +   have one or more thermal sensors attached to it.
  +cooling_device:Any component that can help in reducing the
 temperature of
  +   a 'hot spot' either by reducing its performance (passive
  +   cooling) or by other means(Active cooling E.g. Fan)
  +
  +trip_points:   Various temperature levels for each sensor. As of now, we
  +   have four levels namely active, passive, hot and critical.
  +   Hot and critical trip point support only one value whereas
  +   active and passive can have any number of values. These
  +   temperature values can come from platform data, and are
  +   exposed through sysfs

RE: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone structure

[R, Durgadoss]

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Wei Ni
> Sent: Tuesday, December 25, 2012 2:01 PM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> hongbo.zh...@linaro.org
> Subject: Re: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone
> structure
> 
> On 12/18/2012 05:29 PM, Durgadoss R wrote:
> > This patch creates new APIs to add/remove a
> > cdev to/from a zone. This patch does not change
> > the old cooling device implementation.
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >  drivers/thermal/thermal_sys.c |   80
> +
> >  include/linux/thermal.h   |8 +
> >  2 files changed, 88 insertions(+)
> >
> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> > index 06d5a12..b39bf97 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -58,6 +58,7 @@ static LIST_HEAD(thermal_governor_list);
> >  static DEFINE_MUTEX(thermal_list_lock);
> >  static DEFINE_MUTEX(sensor_list_lock);
> >  static DEFINE_MUTEX(zone_list_lock);
> > +static DEFINE_MUTEX(cdev_list_lock);
> >  static DEFINE_MUTEX(thermal_governor_lock);
> >
> >  #define for_each_thermal_sensor(pos) \
> > @@ -82,6 +83,9 @@ static DEFINE_MUTEX(thermal_governor_lock);
> > mutex_unlock(##_list_lock);\
> > } while (0)
> >
> > +#define for_each_cdev(pos) \
> > +   list_for_each_entry(pos, _cdev_list, node)
> > +
> >  static struct thermal_governor *__find_governor(const char *name)
> >  {
> > struct thermal_governor *pos;
> > @@ -462,6 +466,24 @@ static void remove_sensor_from_zone(struct
> thermal_zone *tz,
> > tz->sensor_indx--;
> >  }
> >
> > +static void remove_cdev_from_zone(struct thermal_zone *tz,
> > +   struct thermal_cooling_device *cdev)
> > +{
> > +   int j, indx;
> > +
> > +   GET_INDEX(tz, cdev, indx, cdev);
> > +   if (indx < 0)
> > +   return;
> > +
> > +   sysfs_remove_link(>device.kobj, kobject_name(
> >device.kobj));
> > +
> > +   /* Shift the entries in the tz->cdevs array */
> > +   for (j = indx; j < MAX_CDEVS_PER_ZONE - 1; j++)
> > +   tz->cdevs[j] = tz->cdevs[j + 1];
> > +
> > +   tz->cdev_indx--;
> > +}
> > +
> >  /* sys I/F for thermal zone */
> >
> >  #define to_thermal_zone(_dev) \
> > @@ -1458,6 +1480,7 @@ void thermal_cooling_device_unregister(struct
> thermal_cooling_device *cdev)
> > int i;
> > const struct thermal_zone_params *tzp;
> > struct thermal_zone_device *tz;
> > +   struct thermal_zone *tmp_tz;
> > struct thermal_cooling_device *pos = NULL;
> >
> > if (!cdev)
> > @@ -1495,6 +1518,13 @@ void thermal_cooling_device_unregister(struct
> thermal_cooling_device *cdev)
> >
> > mutex_unlock(_list_lock);
> >
> > +   mutex_lock(_list_lock);
> > +
> > +   for_each_thermal_zone(tmp_tz)
> > +   remove_cdev_from_zone(tmp_tz, cdev);
> > +
> > +   mutex_unlock(_list_lock);
> > +
> > if (cdev->type[0])
> > device_remove_file(>device, _attr_cdev_type);
> > device_remove_file(>device, _attr_max_state);
> > @@ -1790,6 +1820,23 @@ exit:
> >  }
> >  EXPORT_SYMBOL(remove_thermal_zone);
> >
> > +struct thermal_cooling_device *get_cdev_by_name(const char *name)
> > +{
> > +   struct thermal_cooling_device *pos;
> > +   struct thermal_cooling_device *cdev = NULL;
> > +
> > +   mutex_lock(_list_lock);
> > +   for_each_cdev(pos) {
> > +   if (!strnicmp(pos->type, name, THERMAL_NAME_LENGTH)) {
> > +   cdev = pos;
> > +   break;
> > +   }
> > +   }
> > +   mutex_unlock(_list_lock);
> > +   return cdev;
> > +}
> > +EXPORT_SYMBOL(get_cdev_by_name);
> 
> It seems you forgot to add get_cdev_by_name() and
> get_sensor_by_name()
> to the include file.

Thanks.. Will take care of this in v2.

Regards,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 8/8] Thermal: Dummy driver used for testing

[R, Durgadoss]

> -Original Message-
> From: Wei Ni [mailto:w...@nvidia.com]
> Sent: Tuesday, December 25, 2012 2:08 PM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> hongbo.zh...@linaro.org
> Subject: Re: [PATCH 8/8] Thermal: Dummy driver used for testing
> 
> On 12/18/2012 05:29 PM, Durgadoss R wrote:
> > This patch has a dummy driver that can be used for
> > testing purposes. This patch is not for merge.
> >
> > Signed-off-by: Durgadoss R 
> > ---
> >  drivers/thermal/Kconfig|5 +
> >  drivers/thermal/Makefile   |3 +
> >  drivers/thermal/thermal_test.c |  315
> 
> >  3 files changed, 323 insertions(+)
> >  create mode 100644 drivers/thermal/thermal_test.c
> >
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index c5ba3340..3b92a76 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -136,4 +136,9 @@ config DB8500_CPUFREQ_COOLING
> >   bound cpufreq cooling device turns active to set CPU frequency low
> to
> >   cool down the CPU.
> >
> > +config THERMAL_TEST
> > +   tristate "test driver"
> > +   help
> > + Enable this to test the thermal framework.
> > +
> >  endif
> > diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> > index d8da683..02c3edb 100644
> > --- a/drivers/thermal/Makefile
> > +++ b/drivers/thermal/Makefile
> > @@ -18,3 +18,6 @@ obj-$(CONFIG_RCAR_THERMAL)+=
> rcar_thermal.o
> >  obj-$(CONFIG_EXYNOS_THERMAL)   += exynos_thermal.o
> >  obj-$(CONFIG_DB8500_THERMAL)   += db8500_thermal.o
> >  obj-$(CONFIG_DB8500_CPUFREQ_COOLING)   +=
> db8500_cpufreq_cooling.o
> > +
> > +# dummy driver for testing
> > +obj-$(CONFIG_THERMAL_TEST) += thermal_test.o
> > diff --git a/drivers/thermal/thermal_test.c
> b/drivers/thermal/thermal_test.c
> > new file mode 100644
> > index 000..5a11e34
> > --- /dev/null
> > +++ b/drivers/thermal/thermal_test.c
> > @@ -0,0 +1,315 @@
> > +/*
> > + * thermal_test.c - This driver can be used to test Thermal
> > + *Framework changes. Not specific to any
> > + *platform. Fills the log buffer generously ;)
> > + *
> > + * Copyright (C) 2012 Intel Corporation
> > + *
> > + *
> ~~
> 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; version 2 of the License.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See
> the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> along
> > + * with this program; if not, write to the Free Software Foundation, Inc.,
> > + * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> > + *
> > + *
> ~~
> 
> > + * Author: Durgadoss R 
> > + */
> > +
> > +#define pr_fmt(fmt)  "thermal_test: " fmt
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MAX_THERMAL_ZONES  2
> > +#define MAX_THERMAL_SENSORS2
> > +#define MAX_COOLING_DEVS   4
> > +#define NUM_THRESHOLDS 3
> > +
> > +static struct ts_data {
> > +   int curr_temp;
> > +   int flag;
> > +} ts_data;
> > +
> > +int active_trips[10] = {100, 90, 80, 70, 60, 50, 40, 30, 20, 10};
> > +int passive_trips[5] = {100, 90, 60, 50, 40};
> > +
> > +static struct platform_device *pdev;
> > +static unsigned long cur_cdev_state = 2;
> > +static struct thermal_sensor *ts, *ts1;
> > +static struct thermal_zone *tz;
> > +static struct thermal_cooling_device *cdev;
> > +
> > +static long thermal_thresholds[NUM_THRESHOLDS] = {3, 4,
> 5};
> > +
> > +static struct thermal_trip_point trip = {
> > +   .hot = 90,
> > +   .crit = 100,
> > +   .num_passive_trips = 5,
> > +   .passi

RE: [PATCH 8/8] Thermal: Dummy driver used for testing

[R, Durgadoss]

 -Original Message-
 From: Wei Ni [mailto:w...@nvidia.com]
 Sent: Tuesday, December 25, 2012 2:08 PM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 hongbo.zh...@linaro.org
 Subject: Re: [PATCH 8/8] Thermal: Dummy driver used for testing
 
 On 12/18/2012 05:29 PM, Durgadoss R wrote:
  This patch has a dummy driver that can be used for
  testing purposes. This patch is not for merge.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
   drivers/thermal/Kconfig|5 +
   drivers/thermal/Makefile   |3 +
   drivers/thermal/thermal_test.c |  315
 
   3 files changed, 323 insertions(+)
   create mode 100644 drivers/thermal/thermal_test.c
 
  diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
  index c5ba3340..3b92a76 100644
  --- a/drivers/thermal/Kconfig
  +++ b/drivers/thermal/Kconfig
  @@ -136,4 +136,9 @@ config DB8500_CPUFREQ_COOLING
bound cpufreq cooling device turns active to set CPU frequency low
 to
cool down the CPU.
 
  +config THERMAL_TEST
  +   tristate test driver
  +   help
  + Enable this to test the thermal framework.
  +
   endif
  diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
  index d8da683..02c3edb 100644
  --- a/drivers/thermal/Makefile
  +++ b/drivers/thermal/Makefile
  @@ -18,3 +18,6 @@ obj-$(CONFIG_RCAR_THERMAL)+=
 rcar_thermal.o
   obj-$(CONFIG_EXYNOS_THERMAL)   += exynos_thermal.o
   obj-$(CONFIG_DB8500_THERMAL)   += db8500_thermal.o
   obj-$(CONFIG_DB8500_CPUFREQ_COOLING)   +=
 db8500_cpufreq_cooling.o
  +
  +# dummy driver for testing
  +obj-$(CONFIG_THERMAL_TEST) += thermal_test.o
  diff --git a/drivers/thermal/thermal_test.c
 b/drivers/thermal/thermal_test.c
  new file mode 100644
  index 000..5a11e34
  --- /dev/null
  +++ b/drivers/thermal/thermal_test.c
  @@ -0,0 +1,315 @@
  +/*
  + * thermal_test.c - This driver can be used to test Thermal
  + *Framework changes. Not specific to any
  + *platform. Fills the log buffer generously ;)
  + *
  + * Copyright (C) 2012 Intel Corporation
  + *
  + *
 ~~
 
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License as published by
  + * the Free Software Foundation; version 2 of the License.
  + *
  + * This program is distributed in the hope that it will be useful, but
  + * WITHOUT ANY WARRANTY; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See
 the GNU
  + * General Public License for more details.
  + *
  + * You should have received a copy of the GNU General Public License
 along
  + * with this program; if not, write to the Free Software Foundation, Inc.,
  + * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
  + *
  + *
 ~~
 
  + * Author: Durgadoss R durgados...@intel.com
  + */
  +
  +#define pr_fmt(fmt)  thermal_test:  fmt
  +
  +#include linux/module.h
  +#include linux/init.h
  +#include linux/err.h
  +#include linux/param.h
  +#include linux/device.h
  +#include linux/slab.h
  +#include linux/pm.h
  +#include linux/platform_device.h
  +#include linux/thermal.h
  +
  +#define MAX_THERMAL_ZONES  2
  +#define MAX_THERMAL_SENSORS2
  +#define MAX_COOLING_DEVS   4
  +#define NUM_THRESHOLDS 3
  +
  +static struct ts_data {
  +   int curr_temp;
  +   int flag;
  +} ts_data;
  +
  +int active_trips[10] = {100, 90, 80, 70, 60, 50, 40, 30, 20, 10};
  +int passive_trips[5] = {100, 90, 60, 50, 40};
  +
  +static struct platform_device *pdev;
  +static unsigned long cur_cdev_state = 2;
  +static struct thermal_sensor *ts, *ts1;
  +static struct thermal_zone *tz;
  +static struct thermal_cooling_device *cdev;
  +
  +static long thermal_thresholds[NUM_THRESHOLDS] = {3, 4,
 5};
  +
  +static struct thermal_trip_point trip = {
  +   .hot = 90,
  +   .crit = 100,
  +   .num_passive_trips = 5,
  +   .passive_trips = passive_trips,
  +   .num_active_trips = 10,
  +   .active_trips = active_trips,
  +   .active_trip_mask = 0xCFF,
  +};
  +
  +static struct thermal_trip_point trip1 = {
  +   .hot = 95,
  +   .crit = 125,
  +   .num_passive_trips = 0,
  +   .passive_trips = passive_trips,
  +   .num_active_trips = 6,
  +   .active_trips = active_trips,
  +   .active_trip_mask = 0xFF,
  +};
  +
  +static int read_cur_state(struct thermal_cooling_device *cdev,
  +   unsigned long *state)
  +{
  +   *state = cur_cdev_state;
  +   return 0;
  +}
  +
  +static int write_cur_state(struct thermal_cooling_device *cdev,
  +   unsigned long state)
  +{
  +   cur_cdev_state = state;
  +   return 0;
  +}
  +
  +static int read_max_state(struct thermal_cooling_device *cdev

RE: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone structure

[R, Durgadoss]

 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
 ow...@vger.kernel.org] On Behalf Of Wei Ni
 Sent: Tuesday, December 25, 2012 2:01 PM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 hongbo.zh...@linaro.org
 Subject: Re: [PATCH 3/8] Thermal: Add APIs to bind cdev to new zone
 structure
 
 On 12/18/2012 05:29 PM, Durgadoss R wrote:
  This patch creates new APIs to add/remove a
  cdev to/from a zone. This patch does not change
  the old cooling device implementation.
 
  Signed-off-by: Durgadoss R durgados...@intel.com
  ---
   drivers/thermal/thermal_sys.c |   80
 +
   include/linux/thermal.h   |8 +
   2 files changed, 88 insertions(+)
 
  diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
  index 06d5a12..b39bf97 100644
  --- a/drivers/thermal/thermal_sys.c
  +++ b/drivers/thermal/thermal_sys.c
  @@ -58,6 +58,7 @@ static LIST_HEAD(thermal_governor_list);
   static DEFINE_MUTEX(thermal_list_lock);
   static DEFINE_MUTEX(sensor_list_lock);
   static DEFINE_MUTEX(zone_list_lock);
  +static DEFINE_MUTEX(cdev_list_lock);
   static DEFINE_MUTEX(thermal_governor_lock);
 
   #define for_each_thermal_sensor(pos) \
  @@ -82,6 +83,9 @@ static DEFINE_MUTEX(thermal_governor_lock);
  mutex_unlock(type##_list_lock);\
  } while (0)
 
  +#define for_each_cdev(pos) \
  +   list_for_each_entry(pos, thermal_cdev_list, node)
  +
   static struct thermal_governor *__find_governor(const char *name)
   {
  struct thermal_governor *pos;
  @@ -462,6 +466,24 @@ static void remove_sensor_from_zone(struct
 thermal_zone *tz,
  tz-sensor_indx--;
   }
 
  +static void remove_cdev_from_zone(struct thermal_zone *tz,
  +   struct thermal_cooling_device *cdev)
  +{
  +   int j, indx;
  +
  +   GET_INDEX(tz, cdev, indx, cdev);
  +   if (indx  0)
  +   return;
  +
  +   sysfs_remove_link(tz-device.kobj, kobject_name(cdev-
 device.kobj));
  +
  +   /* Shift the entries in the tz-cdevs array */
  +   for (j = indx; j  MAX_CDEVS_PER_ZONE - 1; j++)
  +   tz-cdevs[j] = tz-cdevs[j + 1];
  +
  +   tz-cdev_indx--;
  +}
  +
   /* sys I/F for thermal zone */
 
   #define to_thermal_zone(_dev) \
  @@ -1458,6 +1480,7 @@ void thermal_cooling_device_unregister(struct
 thermal_cooling_device *cdev)
  int i;
  const struct thermal_zone_params *tzp;
  struct thermal_zone_device *tz;
  +   struct thermal_zone *tmp_tz;
  struct thermal_cooling_device *pos = NULL;
 
  if (!cdev)
  @@ -1495,6 +1518,13 @@ void thermal_cooling_device_unregister(struct
 thermal_cooling_device *cdev)
 
  mutex_unlock(thermal_list_lock);
 
  +   mutex_lock(zone_list_lock);
  +
  +   for_each_thermal_zone(tmp_tz)
  +   remove_cdev_from_zone(tmp_tz, cdev);
  +
  +   mutex_unlock(zone_list_lock);
  +
  if (cdev-type[0])
  device_remove_file(cdev-device, dev_attr_cdev_type);
  device_remove_file(cdev-device, dev_attr_max_state);
  @@ -1790,6 +1820,23 @@ exit:
   }
   EXPORT_SYMBOL(remove_thermal_zone);
 
  +struct thermal_cooling_device *get_cdev_by_name(const char *name)
  +{
  +   struct thermal_cooling_device *pos;
  +   struct thermal_cooling_device *cdev = NULL;
  +
  +   mutex_lock(cdev_list_lock);
  +   for_each_cdev(pos) {
  +   if (!strnicmp(pos-type, name, THERMAL_NAME_LENGTH)) {
  +   cdev = pos;
  +   break;
  +   }
  +   }
  +   mutex_unlock(cdev_list_lock);
  +   return cdev;
  +}
  +EXPORT_SYMBOL(get_cdev_by_name);
 
 It seems you forgot to add get_cdev_by_name() and
 get_sensor_by_name()
 to the include file.

Thanks.. Will take care of this in v2.

Regards,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 0/8] Thermal Framework Enhancements

[R, Durgadoss]

> -Original Message-
> From: Hongbo Zhang [mailto:hongbo.zh...@linaro.org]
> Sent: Friday, December 21, 2012 2:17 PM
> To: R, Durgadoss
> Cc: Wei Ni; Zhang, Rui; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH 0/8] Thermal Framework Enhancements
> 
> On 21 December 2012 16:30, R, Durgadoss  wrote:
> > Hi Ni,
> >
> >> -Original Message-
> >> From: Wei Ni [mailto:w...@nvidia.com]
> >> Sent: Friday, December 21, 2012 1:36 PM
> >> To: R, Durgadoss
> >> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> hongbo.zh...@linaro.org
> >> Subject: Re: [PATCH 0/8] Thermal Framework Enhancements
> >>
> >> On 12/18/2012 05:29 PM, Durgadoss R wrote:
> >> > This patch is a v1 based on the RFC submitted here:
> >> > https://patchwork.kernel.org/patch/1758921/
> >> >
> >> > This patch set is based on Rui's -thermal tree, and is
> >> > tested on a Core-i5 and an Atom netbook.
> >> >
> >> > This series contains 8 patches:
> >> > Patch 1/8: Creates new sensor level APIs
> >> > Patch 2/8: Creates new zone level APIs. The existing tzd structure is
> >> >kept as such for clarity and compatibility purposes.
> >> > Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
> >> >existing tcd structure need not be modified.
> >> > Patch 4/8: Adds a thermal_trip sysfs node, which exposes various trip
> >> >points for all sensors present in a zone.
> >> > Patch 5/8: Adds a thermal_map sysfs node. It is a compact
> representation
> >> >of the binding relationship between a sensor and a cdev,
> >> >within a zone.
> >> > Patch 6/8: Creates Documentation for the new APIs. A new file is
> >> >created for clarity. Final goal is to merge with the existing
> >> >file or refactor the files, as whatever seems appropriate.
> >> > Patch 7/8: Make PER ZONE values configurable through Kconfig
> >> > Patch 8/8: A dummy driver that can be used for testing. This is not for
> >> merge.
> >>
> >> I read these patches, they create new APIs and sysfs, but it seems they
> >> didn't use the thermal_zone to handle the thermal_throttle issue,
> >> something like update thermal_zone, update temperature, handle
> >> governors
> >> when cross the trip temp. So will you send out next serial patches for
> >> these implementation?
> >
> > Yes, once these get into Rui's tree, we will start migrating the existing
> drivers/
> > and governors, to get things working.
> Durgadoss,
> See function psy_register_thermal() in power_supply_core.c,
> thermal_zone_device_register() is used here, what will this look like
> in future?

Yes, I know this code.
This will be a thermal_sensor_register.
Basically this will expose battery's temperature as a 'sensor'
under /sys/class/thermal/.

Then, each platform can add it to whatever zone they like to.

Thanks,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 0/8] Thermal Framework Enhancements

[R, Durgadoss]

Hi Ni,

> -Original Message-
> From: Wei Ni [mailto:w...@nvidia.com]
> Sent: Friday, December 21, 2012 1:36 PM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> hongbo.zh...@linaro.org
> Subject: Re: [PATCH 0/8] Thermal Framework Enhancements
> 
> On 12/18/2012 05:29 PM, Durgadoss R wrote:
> > This patch is a v1 based on the RFC submitted here:
> > https://patchwork.kernel.org/patch/1758921/
> >
> > This patch set is based on Rui's -thermal tree, and is
> > tested on a Core-i5 and an Atom netbook.
> >
> > This series contains 8 patches:
> > Patch 1/8: Creates new sensor level APIs
> > Patch 2/8: Creates new zone level APIs. The existing tzd structure is
> >kept as such for clarity and compatibility purposes.
> > Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
> >existing tcd structure need not be modified.
> > Patch 4/8: Adds a thermal_trip sysfs node, which exposes various trip
> >points for all sensors present in a zone.
> > Patch 5/8: Adds a thermal_map sysfs node. It is a compact representation
> >of the binding relationship between a sensor and a cdev,
> >within a zone.
> > Patch 6/8: Creates Documentation for the new APIs. A new file is
> >created for clarity. Final goal is to merge with the existing
> >file or refactor the files, as whatever seems appropriate.
> > Patch 7/8: Make PER ZONE values configurable through Kconfig
> > Patch 8/8: A dummy driver that can be used for testing. This is not for
> merge.
> 
> I read these patches, they create new APIs and sysfs, but it seems they
> didn't use the thermal_zone to handle the thermal_throttle issue,
> something like update thermal_zone, update temperature, handle
> governors
> when cross the trip temp. So will you send out next serial patches for
> these implementation?

Yes, once these get into Rui's tree, we will start migrating the existing 
drivers/
and governors, to get things working.

Thanks,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 0/8] Thermal Framework Enhancements

[R, Durgadoss]

Hi Ni,

 -Original Message-
 From: Wei Ni [mailto:w...@nvidia.com]
 Sent: Friday, December 21, 2012 1:36 PM
 To: R, Durgadoss
 Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
 hongbo.zh...@linaro.org
 Subject: Re: [PATCH 0/8] Thermal Framework Enhancements
 
 On 12/18/2012 05:29 PM, Durgadoss R wrote:
  This patch is a v1 based on the RFC submitted here:
  https://patchwork.kernel.org/patch/1758921/
 
  This patch set is based on Rui's -thermal tree, and is
  tested on a Core-i5 and an Atom netbook.
 
  This series contains 8 patches:
  Patch 1/8: Creates new sensor level APIs
  Patch 2/8: Creates new zone level APIs. The existing tzd structure is
 kept as such for clarity and compatibility purposes.
  Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
 existing tcd structure need not be modified.
  Patch 4/8: Adds a thermal_trip sysfs node, which exposes various trip
 points for all sensors present in a zone.
  Patch 5/8: Adds a thermal_map sysfs node. It is a compact representation
 of the binding relationship between a sensor and a cdev,
 within a zone.
  Patch 6/8: Creates Documentation for the new APIs. A new file is
 created for clarity. Final goal is to merge with the existing
 file or refactor the files, as whatever seems appropriate.
  Patch 7/8: Make PER ZONE values configurable through Kconfig
  Patch 8/8: A dummy driver that can be used for testing. This is not for
 merge.
 
 I read these patches, they create new APIs and sysfs, but it seems they
 didn't use the thermal_zone to handle the thermal_throttle issue,
 something like update thermal_zone, update temperature, handle
 governors
 when cross the trip temp. So will you send out next serial patches for
 these implementation?

Yes, once these get into Rui's tree, we will start migrating the existing 
drivers/
and governors, to get things working.

Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 0/8] Thermal Framework Enhancements

[R, Durgadoss]

 -Original Message-
 From: Hongbo Zhang [mailto:hongbo.zh...@linaro.org]
 Sent: Friday, December 21, 2012 2:17 PM
 To: R, Durgadoss
 Cc: Wei Ni; Zhang, Rui; linux...@vger.kernel.org; linux-
 ker...@vger.kernel.org
 Subject: Re: [PATCH 0/8] Thermal Framework Enhancements
 
 On 21 December 2012 16:30, R, Durgadoss durgados...@intel.com wrote:
  Hi Ni,
 
  -Original Message-
  From: Wei Ni [mailto:w...@nvidia.com]
  Sent: Friday, December 21, 2012 1:36 PM
  To: R, Durgadoss
  Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
  hongbo.zh...@linaro.org
  Subject: Re: [PATCH 0/8] Thermal Framework Enhancements
 
  On 12/18/2012 05:29 PM, Durgadoss R wrote:
   This patch is a v1 based on the RFC submitted here:
   https://patchwork.kernel.org/patch/1758921/
  
   This patch set is based on Rui's -thermal tree, and is
   tested on a Core-i5 and an Atom netbook.
  
   This series contains 8 patches:
   Patch 1/8: Creates new sensor level APIs
   Patch 2/8: Creates new zone level APIs. The existing tzd structure is
  kept as such for clarity and compatibility purposes.
   Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
  existing tcd structure need not be modified.
   Patch 4/8: Adds a thermal_trip sysfs node, which exposes various trip
  points for all sensors present in a zone.
   Patch 5/8: Adds a thermal_map sysfs node. It is a compact
 representation
  of the binding relationship between a sensor and a cdev,
  within a zone.
   Patch 6/8: Creates Documentation for the new APIs. A new file is
  created for clarity. Final goal is to merge with the existing
  file or refactor the files, as whatever seems appropriate.
   Patch 7/8: Make PER ZONE values configurable through Kconfig
   Patch 8/8: A dummy driver that can be used for testing. This is not for
  merge.
 
  I read these patches, they create new APIs and sysfs, but it seems they
  didn't use the thermal_zone to handle the thermal_throttle issue,
  something like update thermal_zone, update temperature, handle
  governors
  when cross the trip temp. So will you send out next serial patches for
  these implementation?
 
  Yes, once these get into Rui's tree, we will start migrating the existing
 drivers/
  and governors, to get things working.
 Durgadoss,
 See function psy_register_thermal() in power_supply_core.c,
 thermal_zone_device_register() is used here, what will this look like
 in future?

Yes, I know this code.
This will be a thermal_sensor_register.
Basically this will expose battery's temperature as a 'sensor'
under /sys/class/thermal/.

Then, each platform can add it to whatever zone they like to.

Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/