Re: [linux-pm] [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
Hi Vincent,
Thanks for the review.
Well actually your are correct that current temperature and last
temperature can be used to increase or decrease the cufreq. But this has to
be done again in cooling devices so to make the cooling devices generic and
to avoid the temperature comparision again this new trip type passes the
cooling device instance id.
Also about your queries that this may add dependency between trip index and
cooling state. This is actually needed and this dependency is created when
the cooling device is binded with trip points(For cpufreq type cooling
device just the instance of cooling device is associated with trip points).
More over the existing PASSIVE cooling trip type does the same thing and
iterates across all the cooling state.
Thanks,
Amit Daniel
On 20 December 2011 18:07, Vincent Guittot wrote:
> Hi Amit,
>
> I'm not sure that using the trip index for setting the state of a
> cooling device is a generic solution because you are adding a
> dependency between the trip index and the cooling device state that
> might be difficult to handle. This dependency implies that a cooling
> device like cpufreq_cooling_device must be registered in the 1st trips
> of a thermal_zone which is not possible when we want to register 2
> cpufreq_cooling_devices in the same thermal_zone.
> You should only rely on the current and last temperatures to detect if
> a trip_temp has been crossed and you should increase or decrease the
> current state of the cooling device accordingly.
>
> something like below should work with cpufreq_cooling_device and will
> not add any constraint on the trip index. The state of a cooling
> device is increased/decreased once for each trip
>
> + case THERMAL_TRIP_STATE_ACTIVE:
> + list_for_each_entry(instance, &tz->cooling_devices,
> + node) {
> + if (instance->trip != count)
> + continue;
> +
> + cdev = instance->cdev;
> +
> + if ((temp >= trip_temp)
> + && (trip_temp >
> tz->last_temperature)) {
> + cdev->ops->get_max_state(cdev,
> + &max_state);
> + cdev->ops->get_cur_state(cdev,
> + ¤t_state);
> + if (++current_state <= max_state)
> +
> cdev->ops->set_cur_state(cdev,
> +
> current_state);
> + }
> + else if ((temp < trip_temp)
> + && (trip_temp <=
> tz->last_temperature)) {
> + cdev->ops->get_cur_state(cdev,
> + ¤t_state);
> + if (current_state > 0)
> +
> cdev->ops->set_cur_state(cdev,
> +
> --current_state);
> + }
> + break;
>
> Regards,
> Vincent
>
> On 13 December 2011 16:13, Amit Daniel Kachhap
> wrote:
> > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
> > trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
> > device instance number. This helps the cooling device registered as
> > different instances to perform appropriate cooling action decision in
> > the set_cur_state call back function.
> >
> > Also since the trip temperature's are in ascending order so some logic
> > is put in place to skip the un-necessary checks.
> >
> > Signed-off-by: Amit Daniel Kachhap
> > ---
> > Documentation/thermal/sysfs-api.txt |4 ++--
> > drivers/thermal/thermal_sys.c | 27 ++-
> > include/linux/thermal.h |1 +
> > 3 files changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/thermal/sysfs-api.txt
> b/Documentation/thermal/sysfs-api.txt
> > index b61e46f..5c1d44e 100644
> > --- a/Documentation/thermal/sysfs-api.txt
> > +++ b/Documentation/thermal/sysfs-api.txt
> > @@ -184,8 +184,8 @@ trip_point_[0-*]_temp
> >
> > trip_point_[0-*]_type
> >Strings which indicate the type of the trip point.
> > - E.g. it can be one of critical, hot, passive, active[0-*] for
> ACPI
> > - thermal zone.
> > + E.g. it can be one of critical, hot, passive, active[0-1],
> > + state-active[0-*] for ACPI thermal zone.
> >RO, Optional
> >
> > cdev[0-*]
> > diff --git a/drivers/thermal/thermal_sys.c
> b/drivers/thermal/thermal_sys.c
> > index dd9a574..72b1ab3 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct
> device_attribute *attr,
> >return sprintf(buf, "passive\n");
> >case THERMAL_TRIP_ACTIVE:
> >
Re: [linux-pm] [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
Hi Vincent,
Thanks for the review.
Well actually your are correct that current temperature and last
temperature can be used to increase or decrease the cpu frequency. But
this has to be done again in cooling devices so to make the cooling
devices generic and to avoid the temperature comparison again this new
trip type passes the cooling device instance id.
Also about your queries that this may add dependency between trip
index and cooling state. This is actually needed and this dependency
is created when the cooling device is binded with trip points(For
cpufreq type cooling device just the instance of cooling device is
associated with trip points). More over the existing PASSIVE cooling
trip type does the same thing and iterates across all the cooling
state.
Thanks,
Amit Daniel
>
> On 20 December 2011 18:07, Vincent Guittot wrote:
>>
>> Hi Amit,
>>
>> I'm not sure that using the trip index for setting the state of a
>> cooling device is a generic solution because you are adding a
>> dependency between the trip index and the cooling device state that
>> might be difficult to handle. This dependency implies that a cooling
>> device like cpufreq_cooling_device must be registered in the 1st trips
>> of a thermal_zone which is not possible when we want to register 2
>> cpufreq_cooling_devices in the same thermal_zone.
>> You should only rely on the current and last temperatures to detect if
>> a trip_temp has been crossed and you should increase or decrease the
>> current state of the cooling device accordingly.
>>
>> something like below should work with cpufreq_cooling_device and will
>> not add any constraint on the trip index. The state of a cooling
>> device is increased/decreased once for each trip
>>
>> + case THERMAL_TRIP_STATE_ACTIVE:
>> + list_for_each_entry(instance, &tz->cooling_devices,
>> + node) {
>> + if (instance->trip != count)
>> + continue;
>> +
>> + cdev = instance->cdev;
>> +
>> + if ((temp >= trip_temp)
>> + && (trip_temp >
>> tz->last_temperature)) {
>> + cdev->ops->get_max_state(cdev,
>> + &max_state);
>> + cdev->ops->get_cur_state(cdev,
>> + ¤t_state);
>> + if (++current_state <= max_state)
>> +
>> cdev->ops->set_cur_state(cdev,
>> +
>> current_state);
>> + }
>> + else if ((temp < trip_temp)
>> + && (trip_temp <=
>> tz->last_temperature)) {
>> + cdev->ops->get_cur_state(cdev,
>> + ¤t_state);
>> + if (current_state > 0)
>> +
>> cdev->ops->set_cur_state(cdev,
>> +
>> --current_state);
>> + }
>> + break;
>>
>> Regards,
>> Vincent
>>
>> On 13 December 2011 16:13, Amit Daniel Kachhap
>> wrote:
>> > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
>> > trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
>> > device instance number. This helps the cooling device registered as
>> > different instances to perform appropriate cooling action decision in
>> > the set_cur_state call back function.
>> >
>> > Also since the trip temperature's are in ascending order so some logic
>> > is put in place to skip the un-necessary checks.
>> >
>> > Signed-off-by: Amit Daniel Kachhap
>> > ---
>> > Documentation/thermal/sysfs-api.txt | 4 ++--
>> > drivers/thermal/thermal_sys.c | 27 ++-
>> > include/linux/thermal.h | 1 +
>> > 3 files changed, 29 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/Documentation/thermal/sysfs-api.txt
>> > b/Documentation/thermal/sysfs-api.txt
>> > index b61e46f..5c1d44e 100644
>> > --- a/Documentation/thermal/sysfs-api.txt
>> > +++ b/Documentation/thermal/sysfs-api.txt
>> > @@ -184,8 +184,8 @@ trip_point_[0-*]_temp
>> >
>> > trip_point_[0-*]_type
>> > Strings which indicate the type of the trip point.
>> > - E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
>> > - thermal zone.
>> > + E.g. it can be one of critical, hot, passive, active[0-1],
>> > + state-active[0-*] for ACPI thermal zone.
>> > RO, Optional
>> >
>> > cdev[0-*]
>> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/th
Re: [PATCH V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
Hi Mr kim, All the comments have been addressed for the Exynos cpu idle patchset. The updated patchset was posted about one month back and there have been no further comments on the patchset since then. As this patchset seems to be stable now, do you think these these patches can merged in this 3.3 merge window? Kindly let me know your opinion. Thanks, Amit Daniel On Mon, Dec 5, 2011 at 4:36 PM, Amit Daniel Kachhap wrote: > Changes since V3: > *Implemented Russell feedback and moved sleep magic 4byte memory before > s3c_cpu_resume to data section. > > Changes since V2: > *Implemented the suggestion of MyungJoo Ham and used INFORM0/1 > registers for resume for some board versions. > *Added back save/restore through CPU PM notifiers as suggested by > Lorenzo Pieralisi. This is useful to restore vfp state. > *some patch modularization (s5p/exynos) and proper commit logs. > > Changes since V1: > *rebased the whole patch against 3.2-rc1 tree > *removed GIC save/restore in AFTR cpuidle state as it is external > to cpu powerdomain > *Added L2 setup code through device tree > *Removed only l2 save/restore registers in sleep > > This Patch series adds support for AFTR mode cpuidle state based on > patch (http://www.spinics.net/lists/arm-kernel/msg132243.html) earlier > submitted by Jaecheol Lee . > > This patch uses CPU PM notifiers , common l2 save/restore and > new cpu_suspend/resume interfaces and is based on the tip of > for-next branch of samsung tree. > (git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > for-next). > > Amit Daniel Kachhap (5): > ARM: exynos: Add support AFTR mode on EXYNOS4210 > ARM: exynos: save L2 settings during bootup > ARM: s5p: add L2 early resume code > ARM: exynos: remove useless code to save/restore L2 > ARM: exynos: Enable l2 configuration through device tree > > arch/arm/mach-exynos/cpu.c | 60 +--- > arch/arm/mach-exynos/cpuidle.c | 152 > ++- > arch/arm/mach-exynos/include/mach/pmu.h | 2 + > arch/arm/mach-exynos/pm.c | 15 --- > arch/arm/plat-s5p/sleep.S | 44 - > 5 files changed, 233 insertions(+), 40 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [lm-sensors] [RFC PATCH 2/3] thermal: exynos4: Register the tmu sensor with the thermal interface layer
Hi Guenter,
The main idea of this work is to leave the current userspace based
notification scheme and add the kernel based cooling scheme on top of
it. Anyway, It is a good idea to move the file hwmon/exynos4_tmu.c as
this creates 2 hwmon entries.
Adding CC: Donggeun Kim to know his opinion.
Thanks,
Amit Daniel
On 4 January 2012 03:55, Guenter Roeck wrote:
> On Wed, 2011-12-21 at 06:59 -0500, Amit Daniel Kachhap wrote:
>> Export and register information from the hwmon tmu sensor to the samsung
>> exynos kernel thermal framework where different cooling devices and thermal
>> zone are binded. The exported information is based according to the data
>> structure thermal_sensor_conf present in exynos_thermal.h. HWMON sysfs
>> functions are currently left although all of them are present in generic
>> linux thermal layer.
>> Also the platform data structure is modified to pass frequency cooling
>> in percentages for each thermal level.
>>
> Hi Amit,
>
> wouldn't it make more sense to merge the code as necessary from
> hwmon/exynos4_tmu.c into the new thermal/exynos_thermal.c, and drop
> hwmon/exynos4_tmu.c entirely ?
>
> With that, you should get the hwmon entries for free, and we would not
> have to maintain two drivers with overlapping functionality.
>
> Thanks,
> Guenter
>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> drivers/hwmon/exynos4_tmu.c | 34
>> ++--
>> include/linux/platform_data/exynos4_tmu.h | 7 ++
>> 2 files changed, 38 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
>> index f2359a0..6912a7f 100644
>> --- a/drivers/hwmon/exynos4_tmu.c
>> +++ b/drivers/hwmon/exynos4_tmu.c
>> @@ -37,6 +37,9 @@
>> #include
>>
>> #include
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> +#include
>> +#endif
>>
>> #define EXYNOS4_TMU_REG_TRIMINFO 0x0
>> #define EXYNOS4_TMU_REG_CONTROL 0x20
>> @@ -248,10 +251,13 @@ static void exynos4_tmu_work(struct work_struct *work)
>>
>> kobject_uevent(&data->hwmon_dev->kobj, KOBJ_CHANGE);
>>
>> - enable_irq(data->irq);
>>
>> clk_disable(data->clk);
>> mutex_unlock(&data->lock);
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> + exynos4_report_trigger();
>> +#endif
>> + enable_irq(data->irq);
>> }
>>
>> static irqreturn_t exynos4_tmu_irq(int irq, void *id)
>> @@ -345,6 +351,14 @@ static const struct attribute_group
>> exynos4_tmu_attr_group = {
>> .attrs = exynos4_tmu_attributes,
>> };
>>
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> +static struct thermal_sensor_conf exynos4_sensor_conf = {
>> + .name = "exynos4-therm",
>> + .read_temperature = (int (*)(void *))exynos4_tmu_read,
>> +};
>> +#endif
>> +/*CONFIG_SAMSUNG_THERMAL_INTERFACE*/
>> +
>> static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
>> {
>> struct exynos4_tmu_data *data;
>> @@ -432,9 +446,20 @@ static int __devinit exynos4_tmu_probe(struct
>> platform_device *pdev)
>> }
>>
>> exynos4_tmu_control(pdev, true);
>> -
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> + (&exynos4_sensor_conf)->private_data = data;
>> + (&exynos4_sensor_conf)->sensor_data = pdata;
>> + ret = exynos4_register_thermal(&exynos4_sensor_conf);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to register thermal interface\n");
>> + goto err_hwmon_device;
>> + }
>> +#endif
>> return 0;
>> -
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> +err_hwmon_device:
>> + hwmon_device_unregister(data->hwmon_dev);
>> +#endif
>> err_create_group:
>> sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>> err_clk:
>> @@ -458,6 +483,9 @@ static int __devexit exynos4_tmu_remove(struct
>> platform_device *pdev)
>>
>> exynos4_tmu_control(pdev, false);
>>
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> + exynos4_unregister_thermal();
>> +#endif
>> hwmon_device_unregister(data->hwmon_dev);
>> sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>>
>> diff --git a/include/linux/platform_data/exynos4_tmu.h
>> b/include/linux/platform_data/exynos4_tmu.h
>> index 39e038c..642c508 100644
>> --- a/include/linux/platform_data/exynos4_tmu.h
>> +++ b/include/linux/platform_data/exynos4_tmu.h
>> @@ -21,6 +21,7 @@
>>
>> #ifndef _LINUX_EXYNOS4_TMU_H
>> #define _LINUX_EXYNOS4_TMU_H
>> +#include
>>
>> enum calibration_type {
>> TYPE_ONE_POINT_TRIMMING,
>> @@ -64,6 +65,9 @@ enum calibration_type {
>> * in the positive-TC generator block
>> * 0 <= reference_voltage <= 31
>> * @cal_type: calibration type for temperature
>> + * @freq_pctg_table: Table representing frequency reduction percentage.
>> + * @freq_tab_count: Count of the above table as frequency reduction may
>> + * applicable to only some of the trigger levels.
>> *
>> * This structure is required for configuration of exynos4_tmu driver.
>> */
>> @@ -79,5
Re: [PATCH V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
On 3 January 2012 18:52, Kukjin Kim wrote: > amit kachhap wrote: >> >> Hi Mr kim, >> >> All the comments have been addressed for the Exynos cpu idle patchset. >> The updated patchset was posted about one month back and there have >> been no further comments on the patchset since then. >> >> As this patchset seems to be stable now, do you think these these >> patches can merged in this 3.3 merge window? Kindly let me know your >> opinion. >> > > This conflicts with local common.[ch] working for ARM restart. Please wait > until after the merge window for this patches. > Thanks for the update. Actually I have fixed the merging issue in common.[ch] files so sending the V5 series of the patchset shortly. If possible add in this merge window or next merge window is also fine. Regards, Amit daniel > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
Hi Zach/Ricardo, All the thermal Kconfigs are enabled in https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig. Thanks, Amit D On 10 January 2012 23:55, Amit Kucheria wrote: > Amit, could you please add the required Kconfig options that need to > be enabled to > https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig > under Exynos->Thermal? > > Zach and Ricardo will then ensure that their kernels have those > Kconfig options enabled. > > /Amit > > On Wed, Dec 14, 2011 at 6:54 PM, Amit Kachhap > wrote: > > Hi Nicolas, > > > > Please pull my samsung thermal implementation work from git repository > > (git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling). > > Some of the patches are under review and some are in mainline in 3.2 rc* > > version. > > It is all based on the tip of your tree. > > > > The patches are added since commit id > > 971be11492b1e248798f7078592b1fa0dfbf3534 > > > > Thanks, > > Amit Daniel > > > > > > On 14 December 2011 20:11, Amit Kachhap wrote: > >> > >> Hi Nicolas, > >> > >> Is it possible for you to add these 2 patches for this month release? I > am > >> not able to give you the git link as there is seems some problem with > the > >> linaro git server. > >> Also I attached the patches in case required. > >> > >> Thanks, > >> Amit Daniel > >> > >> > >> On 13 December 2011 20:43, Amit Daniel Kachhap > > >> wrote: > >> > PATCH 1) [thermal: Add a new trip type to use cooling device instance > >> > number] > >> > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes > >> > cooling device instance number and may be helpful for cpufreq cooling > >> > devices > >> > to take the correct cooling action. > >> > > >> > PATCH 2) [thermal: Add generic cpu cooling implementation] > >> > This patch adds generic cpu cooling low level implementation through > >> > frequency > >> > clipping and cpu hotplug. In future, other cpu related cooling devices > >> > may be > >> > added here. An ACPI version of this already > >> > exists(drivers/acpi/processor_thermal.c). > >> > But this will be useful for platforms like ARM using the generic > thermal > >> > interface > >> > along with the generic cpu cooling devices. The cooling device > >> > registration API's > >> > return cooling device pointers which can be easily binded with the > >> > thermal zone > >> > trip points. > >> > > >> > > >> > Amit Daniel Kachhap (2): > >> > thermal: Add a new trip type to use cooling device instance number > >> > thermal: Add generic cpu cooling implementation > >> > > >> > Documentation/thermal/cpu-cooling-api.txt | 52 + > >> > Documentation/thermal/sysfs-api.txt |4 +- > >> > drivers/thermal/Kconfig | 11 + > >> > drivers/thermal/Makefile |1 + > >> > drivers/thermal/cpu_cooling.c | 302 > >> > + > >> > drivers/thermal/thermal_sys.c | 27 +++- > >> > include/linux/cpu_cooling.h | 45 + > >> > include/linux/thermal.h |1 + > >> > 8 files changed, 440 insertions(+), 3 deletions(-) > >> > create mode 100644 Documentation/thermal/cpu-cooling-api.txt > >> > create mode 100644 drivers/thermal/cpu_cooling.c > >> > create mode 100644 include/linux/cpu_cooling.h > >> > > >> > > > > > > ___ > > linaro-dev mailing list > > linaro-dev@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro powertop doesn't work during initialization of ncurse
Hi Chanwoo Choi, I remember I found some of those issues when making cross-compiled static powertop binaries due to incompatible ncurses database files. Then I moved to native compilation of powertop binaries for ARM boards. May be this will give you some pointers. Anyway I will test with new libcurses library and let you know. Thanks, Amit Daniel On 12 January 2012 17:37, Chanwoo Choi wrote: > > Hi Amit, > > I used linaro powertop to check idle state on embedded board > with EXYNOS4 series. I modified Makefile to use -lncurse > instead of -lncursew and it was well operated on my board. > - kernel : 2.6.36 > - libncurse : libncurses5-dev > > But, same powertop binary doesn't work on new embedded board. > When execute powertop, I faced one problem which stop powertop > during initialization of ncurse in display.cpp. (init_display function) > - kernel : 3.0 > - libncurse : libncurses5-dev > Does anyone have experience about it? > > Regards, > Chanwoo Choi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 2/2] thermal: Add generic cpu cooling implementation
On 11 January 2012 13:32, Rob Lee wrote: > Hey Amit, I was able to use your code on an i.MX6Q thermal > implementation and it seemed to work pretty well. Thanks for adding > this. A couple of comments below. Thanks for testing and reviewing the code. > > On Tue, Dec 13, 2011 at 9:13 AM, Amit Daniel Kachhap > wrote: >> This patch adds support for generic cpu thermal cooling low level >> implementations using frequency scaling and cpuhotplugg currently. >> Different cpu related cooling devices can be registered by the >> user and the binding of these cooling devices to the corresponding >> trip points can be easily done as the registration API's return the >> cooling device pointer. >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> Documentation/thermal/cpu-cooling-api.txt | 52 + >> drivers/thermal/Kconfig | 11 + >> drivers/thermal/Makefile | 1 + >> drivers/thermal/cpu_cooling.c | 302 >> + >> include/linux/cpu_cooling.h | 45 + >> 5 files changed, 411 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> create mode 100644 drivers/thermal/cpu_cooling.c >> create mode 100644 include/linux/cpu_cooling.h >> >> diff --git a/Documentation/thermal/cpu-cooling-api.txt >> b/Documentation/thermal/cpu-cooling-api.txt >> new file mode 100644 >> index 000..d30b4f2 >> --- /dev/null >> +++ b/Documentation/thermal/cpu-cooling-api.txt >> @@ -0,0 +1,52 @@ >> +CPU cooling api's How To >> +=== >> + >> +Written by Amit Daniel Kachhap >> + >> +Updated: 13 Dec 2011 >> + >> +Copyright (c) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com) >> + >> +0. Introduction >> + >> +The generic cpu cooling(freq clipping, cpuhotplug) provides >> +registration/unregistration api's to the user. The binding of the cooling >> +devices to the trip types is left for the user. The registration api's >> returns >> +the cooling device pointer. >> + >> +1. cpufreq cooling api's >> + >> +1.1 cpufreq registration api's >> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( >> + struct freq_pctg_table *tab_ptr, unsigned int tab_size, >> + const struct cpumask *mask_val) >> + >> + This interface function registers the cpufreq cooling device with the >> name >> + "thermal-cpufreq". >> + >> + tab_ptr: The table containing the percentage of frequency to be clipped >> for >> + each cooling state. >> + .freq_clip_pctg[NR_CPUS]:Percentage of frequency to be clipped for >> each >> + cpu. >> + .polling_interval: polling interval for this cooling state. >> + tab_size: the total number of cooling state. >> + mask_val: all the allowed cpu's where frequency clipping can happen. >> + >> +1.1.2 void cpufreq_cooling_unregister(void) >> + >> + This interface function unregisters the "thermal-cpufreq" cooling >> device. >> + >> + >> +1.2 cpuhotplug registration api's >> + >> +1.2.1 struct thermal_cooling_device *cpuhotplug_cooling_register( >> + const struct cpumask *mask_val) >> + >> + This interface function registers the cpuhotplug cooling device with >> the name >> + "thermal-cpuhotplug". >> + >> + mask_val: all the allowed cpu's which can be hotplugged out. >> + >> +1.1.2 void cpuhotplug_cooling_unregister(void) >> + >> + This interface function unregisters the "thermal-cpuhotplug" cooling >> device. >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index f7f71b2..298c1cd 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -18,3 +18,14 @@ config THERMAL_HWMON >> depends on THERMAL >> depends on HWMON=y || HWMON=THERMAL >> default y >> + >> +config CPU_THERMAL >> + bool "generic cpu cooling support" >> + depends on THERMAL >> + help >> + This implements the generic cpu cooling mechanism through frequency >> + reduction, cpu hotplug and any other ways of reducing temperature. >> An >> + ACPI version of this already >> exists(drivers/acpi/processor_thermal.c). >> + This will be useful for platforms using the generic thermal >> interface >> + and not the ACPI interface. >> + If you want this support, you should say Y or M here. >> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >> index 31108a0..655cbc4 100644 >> --- a/drivers/thermal/Makefile >> +++ b/drivers/thermal/Makefile >> @@ -3,3 +3,4 @@ >> # >> >> obj-$(CONFIG_THERMAL) += thermal_sys.o >> +obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o >> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c >> new file mode 100644 >> index 000..cdd148c >> --- /dev/null >> +++ b/drivers/thermal/cpu_cooling.c >> @@ -0,0 +1,302 @@ >> +/* >> + * linux/drivers/thermal/cpu_cooling.c >> + * >> + * Copyright (C) 2011 Samsung Electronics Co., Ltd(ht
Re: [linux-pm] [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
Hi Rob,
I got your point. The main idea of doing like this is to keep the
cooling implementation independent from thermal zone
algorithms(thermal_sys.c). But binding freq_tab index to the trip
numbers may be not be bad idea. I will give more thought into it in
the next patchset.
Regards,
Amit D
On 11 January 2012 13:42, Rob Lee wrote:
> Hey Amit/Vincent,
>
> It appears that with this implementation the STATE_ACTIVE trip number
> used will also be the index of the cool_freq_tab used. If that is
> true, then perhaps a common structure would be beneficial that links
> each STATE_ACTIVE trip point with its corresponding cooling data.
>
> BR,
> Rob
>
> On Tue, Dec 20, 2011 at 11:11 PM, Amit Kachhap
> wrote:
>> Hi Vincent,
>>
>> Thanks for the review.
>> Well actually your are correct that current temperature and last
>> temperature can be used to increase or decrease the cpu frequency. But
>> this has to be done again in cooling devices so to make the cooling
>> devices generic and to avoid the temperature comparison again this new
>> trip type passes the cooling device instance id.
>> Also about your queries that this may add dependency between trip
>> index and cooling state. This is actually needed and this dependency
>> is created when the cooling device is binded with trip points(For
>> cpufreq type cooling device just the instance of cooling device is
>> associated with trip points). More over the existing PASSIVE cooling
>> trip type does the same thing and iterates across all the cooling
>> state.
>>
>> Thanks,
>> Amit Daniel
>>>
>>> On 20 December 2011 18:07, Vincent Guittot
>>> wrote:
>>>>
>>>> Hi Amit,
>>>>
>>>> I'm not sure that using the trip index for setting the state of a
>>>> cooling device is a generic solution because you are adding a
>>>> dependency between the trip index and the cooling device state that
>>>> might be difficult to handle. This dependency implies that a cooling
>>>> device like cpufreq_cooling_device must be registered in the 1st trips
>>>> of a thermal_zone which is not possible when we want to register 2
>>>> cpufreq_cooling_devices in the same thermal_zone.
>>>> You should only rely on the current and last temperatures to detect if
>>>> a trip_temp has been crossed and you should increase or decrease the
>>>> current state of the cooling device accordingly.
>>>>
>>>> something like below should work with cpufreq_cooling_device and will
>>>> not add any constraint on the trip index. The state of a cooling
>>>> device is increased/decreased once for each trip
>>>>
>>>> + case THERMAL_TRIP_STATE_ACTIVE:
>>>> + list_for_each_entry(instance, &tz->cooling_devices,
>>>> + node) {
>>>> + if (instance->trip != count)
>>>> + continue;
>>>> +
>>>> + cdev = instance->cdev;
>>>> +
>>>> + if ((temp >= trip_temp)
>>>> + && (trip_temp >
>>>> tz->last_temperature)) {
>>>> + cdev->ops->get_max_state(cdev,
>>>> + &max_state);
>>>> + cdev->ops->get_cur_state(cdev,
>>>> + ¤t_state);
>>>> + if (++current_state <= max_state)
>>>> +
>>>> cdev->ops->set_cur_state(cdev,
>>>> +
>>>> current_state);
>>>> + }
>>>> + else if ((temp < trip_temp)
>>>> + && (trip_temp <=
>>>> tz->last_temperature)) {
>>>> + cdev->ops->get_cur_state(cdev,
>>>> + ¤t_state);
>>>> + if (current_state > 0)
>>>> +
>>>> cdev->ops->set_cur_state(cdev,
>>>>
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
On 13 December 2011 20:43, Amit Daniel Kachhap wrote: > PATCH 1) [thermal: Add a new trip type to use cooling device instance number] > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes > cooling device instance number and may be helpful for cpufreq cooling devices > to take the correct cooling action. > > PATCH 2) [thermal: Add generic cpu cooling implementation] > This patch adds generic cpu cooling low level implementation through frequency > clipping and cpu hotplug. In future, other cpu related cooling devices may be > added here. An ACPI version of this already > exists(drivers/acpi/processor_thermal.c). > But this will be useful for platforms like ARM using the generic thermal > interface > along with the generic cpu cooling devices. The cooling device registration > API's > return cooling device pointers which can be easily binded with the thermal > zone > trip points. > Any comments on these patches? I submitted them quite long back. Regards, Amit D > > Amit Daniel Kachhap (2): > thermal: Add a new trip type to use cooling device instance number > thermal: Add generic cpu cooling implementation > > Documentation/thermal/cpu-cooling-api.txt | 52 + > Documentation/thermal/sysfs-api.txt | 4 +- > drivers/thermal/Kconfig | 11 + > drivers/thermal/Makefile | 1 + > drivers/thermal/cpu_cooling.c | 302 > + > drivers/thermal/thermal_sys.c | 27 +++- > include/linux/cpu_cooling.h | 45 + > include/linux/thermal.h | 1 + > 8 files changed, 440 insertions(+), 3 deletions(-) > create mode 100644 Documentation/thermal/cpu-cooling-api.txt > create mode 100644 drivers/thermal/cpu_cooling.c > create mode 100644 include/linux/cpu_cooling.h > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
On 1 February 2012 20:19, Matthew Garrett wrote:
> I'm not really a fan of this as it stands - the name isn't very
> intuitive and the code's pretty difficult to read. Would the following
> (incomplete and obviously untested) not have the effect you want? Then
> you register multiple trip points with the same cooling device but
> different private values, and the state set does whatever you want it
> to. Or am I misunderstanding the problem you're trying to solve?
>
Thanks for the detailed review of the patch. Actually i tried to merge the
benefits of trip type ACTIVE and PASSIVE into one so this name. This new
trip type is just like ACTIVE but instead of OFF(0)/ON(1) all values
greater then 0 is on. Anyways I looked at your implementation below but
this will not solve the purpose as thermal_cooling_device_register() need
to be be called only once to register a cooling device such cpu frequency
based. However the same cooling device may be binded many times to
different trips.
Say,
1) thermal_zone_bind_cooling_device(tz_dev, 0, cdev);
2) thermal_zone_bind_cooling_device(tz_dev, 1, cdev);
3) thermal_zone_bind_cooling_device(tz_dev, 2, cdev);
0,1, 2 are nothing but trip points so the set_cur_state should be called
like
set_cur_state(cdev, 0)
set_cur_state(cdev, 1)
set_cur_state(cdev, 2) when the trip point threshold are crossed.
Yeah I agree that implementation logic looks complex but this to prevent
the lower temp trip points cooling handlers to be called. I will surely
make this better in next version.
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 220ce7e..817f2ba 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -50,6 +50,7 @@ struct thermal_cooling_device_instance {
>char attr_name[THERMAL_NAME_LENGTH];
>struct device_attribute attr;
>struct list_head node;
> + unsigned long private;
> };
>
> static DEFINE_IDR(thermal_tz_idr);
> @@ -909,7 +910,8 @@ static struct class thermal_class = {
> * @ops: standard thermal cooling devices callbacks.
> */
> struct thermal_cooling_device *thermal_cooling_device_register(
> - char *type, void *devdata, const struct thermal_cooling_device_ops
> *ops)
> + char *type, void *devdata, const struct thermal_cooling_device_ops
> *ops,
> + unsigned long private)
> {
>struct thermal_cooling_device *cdev;
>struct thermal_zone_device *pos;
> @@ -936,6 +938,7 @@ struct thermal_cooling_device
> *thermal_cooling_device_register(
>cdev->ops = ops;
>cdev->device.class = &thermal_class;
>cdev->devdata = devdata;
> + cdev->private = private;
>dev_set_name(&cdev->device, "cooling_device%d", cdev->id);
>result = device_register(&cdev->device);
>if (result) {
> @@ -1079,11 +1082,14 @@ void thermal_zone_device_update(struct
> thermal_zone_device *tz)
>continue;
>
>cdev = instance->cdev;
> -
> - if (temp >= trip_temp)
> - cdev->ops->set_cur_state(cdev, 1);
> - else
> - cdev->ops->set_cur_state(cdev, 0);
> + if (cdev->private) {
> + cdev->ops->set_cur_state(cdev,
> cdev->private);
> + } else {
> + if (temp >= trip_temp)
> +
> cdev->ops->set_cur_state(cdev, 1);
> + else
> +
> cdev->ops->set_cur_state(cdev, 0);
> + }
>}
>break;
>case THERMAL_TRIP_PASSIVE:
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 796f1ff..04aac09 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -148,7 +148,7 @@ int thermal_zone_unbind_cooling_device(struct
> thermal_zone_device *, int,
> struct thermal_cooling_device *);
> 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 *);
> +const struct thermal_cooling_device_ops *, unsigned
> long private);
> void thermal_cooling_device_unregister(struct thermal_cooling_device *);
>
> #ifdef CONFIG_NET
>
>
> --
> Matthew Garrett | mj...@srcf.ucam.org
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
On 1 February 2012 20:19, Matthew Garrett wrote:
>
> I'm not really a fan of this as it stands - the name isn't very
> intuitive and the code's pretty difficult to read. Would the following
> (incomplete and obviously untested) not have the effect you want? Then
> you register multiple trip points with the same cooling device but
> different private values, and the state set does whatever you want it
> to. Or am I misunderstanding the problem you're trying to solve?
Thanks for the detailed review of the patch. Actually i tried to merge
the benefits of trip type ACTIVE and PASSIVE into one so this name.
This new trip type is just like ACTIVE but instead of OFF(0)/ON(1)
all values greater then 0 is on. Anyways I looked at your
implementation below but this will not solve the purpose as
thermal_cooling_device_register() need to be be called only once to
register a cooling device such cpu frequency based. However the same
cooling device may be binded many times to different trips.
Say,
1) thermal_zone_bind_cooling_device(tz_dev, 0, cdev);
2) thermal_zone_bind_cooling_device(tz_dev, 1, cdev);
3) thermal_zone_bind_cooling_device(tz_dev, 2, cdev);
0,1, 2 are nothing but trip points so the set_cur_state should be called like
set_cur_state(cdev, 0)
set_cur_state(cdev, 1)
set_cur_state(cdev, 2) when the trip point threshold are crossed.
Yeah I agree that implementation logic looks complex but this to
prevent the lower temp trip points cooling handlers to be called. I
will surely make this better in next version.
>
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 220ce7e..817f2ba 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -50,6 +50,7 @@ struct thermal_cooling_device_instance {
> char attr_name[THERMAL_NAME_LENGTH];
> struct device_attribute attr;
> struct list_head node;
> + unsigned long private;
> };
>
> static DEFINE_IDR(thermal_tz_idr);
> @@ -909,7 +910,8 @@ static struct class thermal_class = {
> * @ops: standard thermal cooling devices callbacks.
> */
> struct thermal_cooling_device *thermal_cooling_device_register(
> - char *type, void *devdata, const struct thermal_cooling_device_ops *ops)
> + char *type, void *devdata, const struct thermal_cooling_device_ops
> *ops,
> + unsigned long private)
> {
> struct thermal_cooling_device *cdev;
> struct thermal_zone_device *pos;
> @@ -936,6 +938,7 @@ struct thermal_cooling_device
> *thermal_cooling_device_register(
> cdev->ops = ops;
> cdev->device.class = &thermal_class;
> cdev->devdata = devdata;
> + cdev->private = private;
> dev_set_name(&cdev->device, "cooling_device%d", cdev->id);
> result = device_register(&cdev->device);
> if (result) {
> @@ -1079,11 +1082,14 @@ void thermal_zone_device_update(struct
> thermal_zone_device *tz)
> continue;
>
> cdev = instance->cdev;
> -
> - if (temp >= trip_temp)
> - cdev->ops->set_cur_state(cdev, 1);
> - else
> - cdev->ops->set_cur_state(cdev, 0);
> + if (cdev->private) {
> + cdev->ops->set_cur_state(cdev,
> cdev->private);
> + } else {
> + if (temp >= trip_temp)
> +
> cdev->ops->set_cur_state(cdev, 1);
> + else
> +
> cdev->ops->set_cur_state(cdev, 0);
> + }
> }
> break;
> case THERMAL_TRIP_PASSIVE:
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 796f1ff..04aac09 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -148,7 +148,7 @@ int thermal_zone_unbind_cooling_device(struct
> thermal_zone_device *, int,
> struct thermal_cooling_device *);
> 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 *);
> + const struct thermal_cooling_device_ops *, unsigned long
> private);
> void thermal_cooling_device_unregister(struct thermal_cooling_device *);
>
> #ifdef CONFIG_NET
>
>
> --
> Matthew Garrett | mj...@srcf.ucam.org
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 2/2] thermal: Add generic cpu cooling implementation
On 1 February 2012 20:27, Matthew Garrett wrote: > On Tue, Dec 13, 2011 at 08:43:16PM +0530, Amit Daniel Kachhap wrote: >> This patch adds support for generic cpu thermal cooling low level >> implementations using frequency scaling and cpuhotplugg currently. > > We've been over this kind of thing in the past. cpu hotplug is a > relatively expensive operation, so people have previously been > enthusiastic about using the scheduler to simply avoid running anything > on CPUs if they're overheating. Has any general consensus been reached > on this? yes you are right that cpuhotplug is an expensive process and it may further heat up the system before turning off so the ideal way would be to reduce the capacity of the cpu gradually. Anyway these patches are only exporting those API's and the actual use of them depends on the user. Although my bigger focus is on cpufreq as cooling devices so I might remove cpuhotplug in the next version. > > I'm also not entirely thrilled at now having two ways to manage the cpu > through the thermal layer. ACPI already plugs in via the passive trip > points. If we're going to do this then I'd like to see the ACPI code > merged in with the generic cpu cooling code. Yeah I also agree that there is a kind of repetition and not entirely sure where to place these codes. I will try adding them inside acpi. Thanks for the suggestion. > > -- > Matthew Garrett | mj...@srcf.ucam.org ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
On 3 February 2012 12:42, Zhang Rui wrote: > Hi, sorry for the late response. > > On 四, 2012-01-19 at 14:47 +0530, Amit Kachhap wrote: >> On 13 December 2011 20:43, Amit Daniel Kachhap >> wrote: >> > PATCH 1) [thermal: Add a new trip type to use cooling device instance >> > number] >> > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes >> > cooling device instance number and may be helpful for cpufreq cooling >> > devices >> > to take the correct cooling action. >> > > Sorry, I'm still not quite clear about how this will be used. > Say, processor has P0~P3, then we need to register a thermal zone with > three STATE_ACTIVE trip points, like the picture shown below? > > processor in full speed, i.e. P0 > > state active trip point 1 > > processor in P1 > > state active trip point 2 > > processor in P2 > > state active trip point 3 > > processor in P3 > Thanks for the review. Your representation of the 3 PSTATES and trip points are correct. Also remember the case that we have registered one cpufreq cooling device and binded 3 instance of it with the 3 trip points. So in the current patch set_cur_state will pass the instance id also which will help in moving to the current P state. This same behaviour is achieved through PASSIVE state but it iterates through all the P states. so the current patch avoids the iteration and goes to a single state directly. >> > PATCH 2) [thermal: Add generic cpu cooling implementation] >> > This patch adds generic cpu cooling low level implementation through >> > frequency >> > clipping and cpu hotplug. In future, other cpu related cooling devices may >> > be >> > added here. An ACPI version of this already >> > exists(drivers/acpi/processor_thermal.c). >> > But this will be useful for platforms like ARM using the generic thermal >> > interface >> > along with the generic cpu cooling devices. The cooling device >> > registration API's >> > return cooling device pointers which can be easily binded with the thermal >> > zone >> > trip points. >> > > It seems that we can convert the ACPI processor thermal driver to follow > this generic cpu cooling implementation, right? I am not sure if we can convert the processor thermal driver because it performs other cpu cooling like throttling, idle etc and then ACPI abstraction on top of it. I am thinking of exporting the generic low level cooling implementation like this patch is doing from processor_thermal.c file so that it can be usable with non-acpi interface. What is your opinion about it? Thanks, Amit Daniel > > thanks, > rui >> >> Any comments on these patches? I submitted them quite long back. >> >> Regards, >> Amit D >> >> > >> > Amit Daniel Kachhap (2): >> > thermal: Add a new trip type to use cooling device instance number >> > thermal: Add generic cpu cooling implementation >> > >> > Documentation/thermal/cpu-cooling-api.txt | 52 + >> > Documentation/thermal/sysfs-api.txt | 4 +- >> > drivers/thermal/Kconfig | 11 + >> > drivers/thermal/Makefile | 1 + >> > drivers/thermal/cpu_cooling.c | 302 >> > + >> > drivers/thermal/thermal_sys.c | 27 +++- >> > include/linux/cpu_cooling.h | 45 + >> > include/linux/thermal.h | 1 + >> > 8 files changed, 440 insertions(+), 3 deletions(-) >> > create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> > create mode 100644 drivers/thermal/cpu_cooling.c >> > create mode 100644 include/linux/cpu_cooling.h >> > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [RFC PATCH] thermal: Add support to report cooling statistics achieved by cooling devices
On 6 February 2012 09:03, Greg KH wrote: > On Mon, Feb 06, 2012 at 05:56:58PM +0100, Pavel Machek wrote: >> Hi! >> >> > Add a sysfs node code to report effective cooling of all cooling devices >> > attached to each trip points of a thermal zone. The cooling data reported >> > will be absolute if the higher temperature trip points are arranged first >> > otherwise the cooling stats is the cumulative effect of the earlier >> > invoked cooling handlers. >> > >> > The basic assumption is that cooling devices will bring down the >> > temperature >> > in a symmetric manner and those statistics can be stored back and used for >> > further tuning of the system. >> >> /sys fs should be one-value-per-file, talk to gregkh. > > That's correct. > > Why not use debugfs for this instead? > > thanks, > > greg k-h Thanks Greg/Pavel for looking into the patch. Basically I checked the places where single sysfs entry is showing more then 1 output. And 1) /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state 2) /sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table are the places where the output is more than 1 value. Anyway I can enclose this sysfs inside CONFIG_THERMAL_COOLING_STATS macro. Thanks, Amit Daniel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [RFC PATCH] thermal: Add support to report cooling statistics achieved by cooling devices
Hi eduardo,
Thanks for the detail review.
On 6 February 2012 23:09, Eduardo Valentin wrote:
> Hello Amit,
>
> some comments embedded.
>
> On Wed, Jan 18, 2012 at 02:51:07PM +0530, Amit Daniel Kachhap wrote:
>> Add a sysfs node code to report effective cooling of all cooling devices
>> attached to each trip points of a thermal zone. The cooling data reported
>> will be absolute if the higher temperature trip points are arranged first
>> otherwise the cooling stats is the cumulative effect of the earlier
>> invoked cooling handlers.
>>
>> The basic assumption is that cooling devices will bring down the temperature
>> in a symmetric manner and those statistics can be stored back and used for
>> further tuning of the system.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> Documentation/thermal/sysfs-api.txt | 10
>> drivers/thermal/thermal_sys.c | 96
>> +++
>> include/linux/thermal.h | 8 +++
>> 3 files changed, 114 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt
>> b/Documentation/thermal/sysfs-api.txt
>> index b61e46f..1db9a9d 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -209,6 +209,13 @@ passive
>> Valid values: 0 (disabled) or greater than 1000
>> RW, Optional
>>
>> +trip_stats
>> + This attribute presents the effective cooling generated from all the
>> + cooling devices attached to a trip point. The output is a pair of value
>> + for each trip point. Each pair represents
>> + (trip index, cooling temperature difference in millidegree Celsius)
>> + RO, Optional
>> +
>> *
>> * Cooling device attributes *
>> *
>> @@ -261,6 +268,9 @@ method, the sys I/F structure will be built like this:
>> |---cdev0_trip_point: 1 /* cdev0 can be used for passive */
>> |---cdev1: --->/sys/class/thermal/cooling_device3
>> |---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/
>> + |---trip_stats 0 0
>> + 1 8000 /*trip 1 causes 8 degree Celsius drop*/
>> + 2 3000 /*trip 2 causes 3 degree Celsius drop*/
>>
>> |cooling_device0:
>> |---type: Processor
>> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
>> index dd9a574..47e7b6e 100644
>> --- a/drivers/thermal/thermal_sys.c
>> +++ b/drivers/thermal/thermal_sys.c
>> @@ -92,6 +92,64 @@ static void release_idr(struct idr *idr, struct mutex
>> *lock, int id)
>> if (lock)
>> mutex_unlock(lock);
>> }
>> +static void update_cooling_stats(struct thermal_zone_device *tz, long
>> cur_temp)
>> +{
>> + int count, max_index, cur_interval;
>> + long trip_temp, max_temp = 0, cool_temp;
>> + static int last_trip_level = -1;
>
> I got confused here. Are you sure using a static variable here is safe? I
> suppose this function
> is called for any thermal_zone_device, which in turns, may have different
> amount of trips, and
> different update rate. You may be using last_trip_level as reference for a
> different tz. Meaning,
> you would be screwing the stat buffers silently.
>
> If that is the case, I suggest you to move this to your stat structure.
Agree. This looks a clear problem. Surely i will move last_trip_level
inside structure tz.
>
>> +
>> + if (cur_temp >= tz->last_temperature)
>> + return;
>> +
>> + /* find the trip according to last temperature */
>> + for (count = 0; count < tz->trips; count++) {
>> + tz->ops->get_trip_temp(tz, count, &trip_temp);
>> + if (tz->last_temperature >= trip_temp) {
>> + if (max_temp < trip_temp) {
>> + max_temp = trip_temp;
>> + max_index = count;
>> + }
>> + }
>> + }
>> +
>> + if (!max_temp) {
>> + last_trip_level = -1;
>> + return;
>> + }
>> +
>> + cur_interval = tz->stat[max_index].interval_ptr;
>> + cool_temp = tz->last_temperature - cur_temp;
>> +
>> + if (last_trip_level != max_index) {
>> + if (++cur_interval == INTERVAL_HISTORY)
>> + cur_interval = 0;
>> + tz->stat[max_index].cool_temp[cur_interval] = cool_temp;
>> + tz->stat[max_index].interval_ptr = cur_interval;
>> + last_trip_level = max_index;
>> + } else {
>> + tz->stat[max_index].cool_temp[cur_interval] += cool_temp;
>
> Why do you need to sum up here? Wouldn't this break your statistics? (I may
> completely missed your idea for last_trip_level).
This will be summed up because after applying cooling action there is
some cooling happening but not enough to change the trip level. So
unless there is cooling enough to change the trip level
Re: [linux-pm] [RFC PATCH 2/2] thermal: Add generic cpu cooling implementation
Hi eduardo, Again thanks for the review. On 7 February 2012 00:25, Eduardo Valentin wrote: > Hello Amit, > > On Tue, Dec 13, 2011 at 08:43:16PM +0530, Amit Daniel Kachhap wrote: >> This patch adds support for generic cpu thermal cooling low level >> implementations using frequency scaling and cpuhotplugg currently. >> Different cpu related cooling devices can be registered by the >> user and the binding of these cooling devices to the corresponding >> trip points can be easily done as the registration API's return the >> cooling device pointer. >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> Documentation/thermal/cpu-cooling-api.txt | 52 + >> drivers/thermal/Kconfig | 11 + >> drivers/thermal/Makefile | 1 + >> drivers/thermal/cpu_cooling.c | 302 >> + >> include/linux/cpu_cooling.h | 45 + >> 5 files changed, 411 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> create mode 100644 drivers/thermal/cpu_cooling.c >> create mode 100644 include/linux/cpu_cooling.h >> >> diff --git a/Documentation/thermal/cpu-cooling-api.txt >> b/Documentation/thermal/cpu-cooling-api.txt >> new file mode 100644 >> index 000..d30b4f2 >> --- /dev/null >> +++ b/Documentation/thermal/cpu-cooling-api.txt >> @@ -0,0 +1,52 @@ >> +CPU cooling api's How To >> +=== >> + >> +Written by Amit Daniel Kachhap >> + >> +Updated: 13 Dec 2011 >> + >> +Copyright (c) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com) >> + >> +0. Introduction >> + >> +The generic cpu cooling(freq clipping, cpuhotplug) provides >> +registration/unregistration api's to the user. The binding of the cooling >> +devices to the trip types is left for the user. The registration api's >> returns >> +the cooling device pointer. >> + >> +1. cpufreq cooling api's >> + >> +1.1 cpufreq registration api's >> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( >> + struct freq_pctg_table *tab_ptr, unsigned int tab_size, >> + const struct cpumask *mask_val) >> + >> + This interface function registers the cpufreq cooling device with the >> name >> + "thermal-cpufreq". >> + >> + tab_ptr: The table containing the percentage of frequency to be clipped >> for >> + each cooling state. >> + .freq_clip_pctg[NR_CPUS]:Percentage of frequency to be clipped for each >> + cpu. >> + .polling_interval: polling interval for this cooling state. >> + tab_size: the total number of cooling state. >> + mask_val: all the allowed cpu's where frequency clipping can happen. >> + >> +1.1.2 void cpufreq_cooling_unregister(void) >> + >> + This interface function unregisters the "thermal-cpufreq" cooling >> device. >> + >> + >> +1.2 cpuhotplug registration api's >> + >> +1.2.1 struct thermal_cooling_device *cpuhotplug_cooling_register( >> + const struct cpumask *mask_val) >> + >> + This interface function registers the cpuhotplug cooling device with >> the name >> + "thermal-cpuhotplug". >> + >> + mask_val: all the allowed cpu's which can be hotplugged out. >> + >> +1.1.2 void cpuhotplug_cooling_unregister(void) >> + >> + This interface function unregisters the "thermal-cpuhotplug" cooling >> device. >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index f7f71b2..298c1cd 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -18,3 +18,14 @@ config THERMAL_HWMON >> depends on THERMAL >> depends on HWMON=y || HWMON=THERMAL >> default y >> + >> +config CPU_THERMAL >> + bool "generic cpu cooling support" >> + depends on THERMAL >> + help >> + This implements the generic cpu cooling mechanism through frequency >> + reduction, cpu hotplug and any other ways of reducing temperature. An >> + ACPI version of this already >> exists(drivers/acpi/processor_thermal.c). >> + This will be useful for platforms using the generic thermal interface >> + and not the ACPI interface. >> + If you want this support, you should say Y or M here. >> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >> index 31108a0..655cbc4 100644 >> --- a/drivers/thermal/Makefile >> +++ b/drivers/thermal/Makefile >> @@ -3,3 +3,4 @@ >> # >> >> obj-$(CONFIG_THERMAL) += thermal_sys.o >> +obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o >> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c >> new file mode 100644 >> index 000..cdd148c >> --- /dev/null >> +++ b/drivers/thermal/cpu_cooling.c >> @@ -0,0 +1,302 @@ >> +/* >> + * linux/drivers/thermal/cpu_cooling.c >> + * >> + * Copyright (C) 2011 Samsung Electronics Co., >> Ltd(http://www.samsung.com) >> + * Copyright (C) 2011 Amit Daniel >> + * >> + * >> ~~ >> + * This progra
Re: [linux-pm] [RFC PATCH] thermal: Add support to report cooling statistics achieved by cooling devices
On 6 February 2012 16:18, Greg KH wrote: > On Mon, Feb 06, 2012 at 03:16:17PM -0800, Amit Kachhap wrote: >> On 6 February 2012 09:03, Greg KH wrote: >> > On Mon, Feb 06, 2012 at 05:56:58PM +0100, Pavel Machek wrote: >> >> Hi! >> >> >> >> > Add a sysfs node code to report effective cooling of all cooling devices >> >> > attached to each trip points of a thermal zone. The cooling data >> >> > reported >> >> > will be absolute if the higher temperature trip points are arranged >> >> > first >> >> > otherwise the cooling stats is the cumulative effect of the earlier >> >> > invoked cooling handlers. >> >> > >> >> > The basic assumption is that cooling devices will bring down the >> >> > temperature >> >> > in a symmetric manner and those statistics can be stored back and used >> >> > for >> >> > further tuning of the system. >> >> >> >> /sys fs should be one-value-per-file, talk to gregkh. >> > >> > That's correct. >> > >> > Why not use debugfs for this instead? >> > >> > thanks, >> > >> > greg k-h >> >> Thanks Greg/Pavel for looking into the patch. >> Basically I checked the places where single sysfs entry is showing >> more then 1 output. And >> 1) /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state >> 2) /sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table >> are the places where the output is more than 1 value. > > Yes, those are two known-bad files, whose files will change soon and > move to debugfs. > > Just because you found 2, instead of the thousands of other properly > formatted files, does not mean you are allowed to create something like > this. > >> Anyway I can enclose this sysfs inside CONFIG_THERMAL_COOLING_STATS macro. > > No, you can not create it at all in sysfs, if you really need such a > large single file, use debugfs instead, that is what it is there for. > > Again, one-value-per-file is the sysfs rule, and has been for a decade > now, please don't think this is a new thing. > > greg k-h Ok I will follow one-value-per-file rule for sysfs file. Thanks ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Last call for patches for the 12.02 release of linux-linaro kernel
Hi Andrey, Please pull my latest thermal changes from git://git.linaro.org/people/amitdanielk/linux.gitexynos_thermal_latest The configs option which needed to be turn on is defined below, https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig#Arch-independent-1 https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig#Samsung_Exynos Thanks, Amit Daniel On 13 February 2012 12:22, Andrey Konovalov wrote: > Greetings, > > If someone has something which is not in the mainline, was not in the 12.01 > kernel release, but worth including into the 12.02 kernel release, please > let me know by the end of Feb 14, PST (the git branch where I could pull > from). This release will be v3.3-rc3 based, so you patches should be based > on that (easiest for me), or on the tip of the linus tree. > > My expectations are that the power management WG has some topics to add to > the 12.02. > > I am aware of git://git.secretlab.ca/git/linux-2.6.git, irqdomain/next > > The kernel working group has some blueprints for 12.02. Please let me know, > if there is something for me to do here. > > The following commits from linux-linaro-3.2 branch will be carried over to > 12.02: > commit 2eb6f8b98d8471c83be7e3ab53fe4386884c96a9 > Author: Vincent Guittot > Date: Fri Oct 21 09:02:47 2011 +0200 > sched: Ensure cpu_power periodic update > > commit 2b21b980917662503a16e079b5d4a5a8a17886cd > Author: Arnd Bergmann > Date: Sat Oct 8 17:07:50 2011 +0200 > ARM: kprobes: work around build errors > > commit 61d24dd4d0528d369ea81f6e5d5e1db9c62ad46a > Author: Ming Lei > Date: Wed Aug 31 00:03:13 2011 +0800 > usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP > > Amit (Amit Daniel Kachhap), please let me know if for 12.02 I should use > the commits below, or take an updated version from you: > ARM: exynos4: Add thermal sensor driver platform device support > thermal: exynos4: Register the tmu sensor with the thermal interface layer > thermal: exynos: Add thermal interface support for linux thermal layer > thermal: Add generic cpu cooling implementation > thermal: Add a new trip type to use cooling device instance number > EXYNOS: Make EXYNOS common cpufreq driver > ARM: exynos: Enable l2 configuration through device tree > ARM: exynos: remove useless code to save/restore L2 > ARM: exynos: save L2 settings during bootup > ARM: s5p: add L2 early resume code > ARM: exynos: Add support AFTR mode on EXYNOS4210 > > > Thanks, > Andrey Konovalov > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: February 2012 Kernel Release
Hi Amit Kucheria, I have asked the samsung maintainer(Kukjin Kim) to queue this patch set 1 month back. But seems like it is not present. Hi Mr Kim, Can you please queue this patchset in your tree for next merge window? The V5 version submitted fixes all the known issues. http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/079214.html Thanks, Amit Daniel On 17 February 2012 11:42, Amit Kucheria wrote: > On Fri, Feb 17, 2012 at 11:03 AM, Deepak Saxena wrote: > >> - Various patches from Linaro >> >> * samsung_cpuidle_l2_retention patch set from the power management WG > > Amit, is this now in your maintainer's tree queued up for 3.4? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: February 2012 Kernel Release
Hi kukjin Kim, I was on travel for elc and linaro conferences so little late for replying. Thanks for testing these patches. I just submitted the V6 series of the cpuidle patchset. I rebased it against the 3.3-rc4 kernel version. I also tested it for SMDKV310 (evt1) and Origen (evt1.1) boards and they are working fine. Some modification was done for CHECK_FLAG. Thanks, Amit Daniel On 18 February 2012 07:29, Kukjin Kim wrote: > Amit Kachhap wrote: >> >> Hi Amit Kucheria, >> > Hi all, > > (Cc'ed Jaecheol Lee and Jongpill Lee) > >> I have asked the samsung maintainer(Kukjin Kim) to queue this patch set 1 >> month back. But seems like it is not present. >> > > If it works fine, then I'm apply this series. > > But now it is not working. As a note, I use your series on top of v3.3-rc3 > and fixed following for test. > > arch/arm/mach-exynos/cpuidle.c: In function 'exynos4_enter_core0_aftr': > arch/arm/mach-exynos/cpuidle.c:119: error: implicit declaration of function > 'BSYM' > make[1]: *** [arch/arm/mach-exynos/cpuidle.o] Error 1 > > I and Jaecheol Lee tested AFTR mode on SMDKV310 and SMDKC210 and then > rebooting happened. > See below log. > > If any updates, please let me know. > > --- > > Booting Linux on physical CPU 0 > Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc version > 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 KST > 2012 > CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > Machine: SMDKV310 > Memory policy: ECC disabled, Data cache writealloc > CPU EXYNOS4210 (id 0x43210010) > > [snip] > > [root@Samsung ~]# cd /sys/devices/system/cpu/cpu0/cpuidle/ > [root@Samsung cpuidle]# ls > state0/ state1/ > [root@Samsung cpuidle]# cd state1 > [root@Samsung state1]# ls > desc latency name power time usage > [root@Samsung state1]# cat name > C1 > [root@Samsung state1]# cat time > 0 > [root@Samsung state1]# echo 0 > /sys/devices/system/cpu/cpu1/online > CPU1: shutdown > [root@Samsung state1]# ðK > > U-Boot 2010.12-9-g300b392 (Jul 15 2011 - 16:39:20) for SMDKV310 > ... > > [snip] > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > Booting Linux on physical CPU 0 > Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc version > 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 KST > 2012 > CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > Machine: SMDKC210 > > [snip] > > Samsung SMDK Board on a armv7l > Samsung login: root > login[1002]: root login on 'ttySAC1' > [root@Samsung ~]# > [root@Samsung ~]# > [root@Samsung ~]# > [root@Samsung ~]# > [root@Samsung ~]# echo 0 > /sys/devices/system/cpu/cpu1/online > CPU1: shutdown > [root@Samsung ~]# O > > [snip] (as a note, the mark of 'O' means 'OK' printing from u-boot. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > > >> >> Hi Mr Kim, >> >> Can you please queue this patchset in your tree for next merge window? >> The V5 version submitted fixes all the known issues. >> http://lists.infradead.org/pipermail/linux-arm-kernel/2012- >> January/079214.html >> >> Thanks, >> Amit Daniel >> >> >> On 17 February 2012 11:42, Amit Kucheria wrote: >> > On Fri, Feb 17, 2012 at 11:03 AM, Deepak Saxena >> wrote: >> > >> >> - Various patches from Linaro >> >> >> >> * samsung_cpuidle_l2_retention patch set from the power management >> >> WG >> > >> > Amit, is this now in your maintainer's tree queued up for 3.4? > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: February 2012 Kernel Release
On 21 February 2012 16:37, Kukjin Kim wrote: > Amit Kachhap wrote: >> >> Hi kukjin Kim, >> > Hi, > >> I was on travel for elc and linaro conferences so little late for >> replying. Thanks for testing these patches. >> I just submitted the V6 series of the cpuidle patchset. I rebased it >> against the 3.3-rc4 kernel version. I also tested it for SMDKV310 >> (evt1) and Origen (evt1.1) boards and they are working fine. >> Some modification was done for CHECK_FLAG. >> > > OK, I checked it works fine on SMDKV310 now. > As I said, will apply your patches for v3.4 but I'm not sure there is a > problem with common cpuidle work. These patches could be part of your for-next branch (and available for v3.4 merge) and any work on common cpuidle code would be incremental changes to this patchset. Regards, Amit Daniel > > Anyway, good job. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > >> Thanks, >> Amit Daniel >> >> >> On 18 February 2012 07:29, Kukjin Kim wrote: >> > Amit Kachhap wrote: >> >> >> >> Hi Amit Kucheria, >> >> >> > Hi all, >> > >> > (Cc'ed Jaecheol Lee and Jongpill Lee) >> > >> >> I have asked the samsung maintainer(Kukjin Kim) to queue this patch set >> 1 >> >> month back. But seems like it is not present. >> >> >> > >> > If it works fine, then I'm apply this series. >> > >> > But now it is not working. As a note, I use your series on top of v3.3- >> rc3 >> > and fixed following for test. >> > >> > arch/arm/mach-exynos/cpuidle.c: In function 'exynos4_enter_core0_aftr': >> > arch/arm/mach-exynos/cpuidle.c:119: error: implicit declaration of >> function >> > 'BSYM' >> > make[1]: *** [arch/arm/mach-exynos/cpuidle.o] Error 1 >> > >> > I and Jaecheol Lee tested AFTR mode on SMDKV310 and SMDKC210 and then >> > rebooting happened. >> > See below log. >> > >> > If any updates, please let me know. >> > >> > --- >> > >> > Booting Linux on physical CPU 0 >> > Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc >> version >> > 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 >> KST >> > 2012 >> > CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d >> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache >> > Machine: SMDKV310 >> > Memory policy: ECC disabled, Data cache writealloc >> > CPU EXYNOS4210 (id 0x43210010) >> > >> > [snip] >> > >> > [root@Samsung ~]# cd /sys/devices/system/cpu/cpu0/cpuidle/ >> > [root@Samsung cpuidle]# ls >> > state0/ state1/ >> > [root@Samsung cpuidle]# cd state1 >> > [root@Samsung state1]# ls >> > desc latency name power time usage >> > [root@Samsung state1]# cat name >> > C1 >> > [root@Samsung state1]# cat time >> > 0 >> > [root@Samsung state1]# echo 0 > /sys/devices/system/cpu/cpu1/online >> > CPU1: shutdown >> > [root@Samsung state1]# ðK >> > >> > U-Boot 2010.12-9-g300b392 (Jul 15 2011 - 16:39:20) for SMDKV310 >> > ... >> > >> > [snip] >> > >> > Starting kernel ... >> > >> > Uncompressing Linux... done, booting the kernel. >> > Booting Linux on physical CPU 0 >> > Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc >> version >> > 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 >> KST >> > 2012 >> > CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d >> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache >> > Machine: SMDKC210 >> > >> > [snip] >> > >> > Samsung SMDK Board on a armv7l >> > Samsung login: root >> > login[1002]: root login on 'ttySAC1' >> > [root@Samsung ~]# >> > [root@Samsung ~]# >> > [root@Samsung ~]# >> > [root@Samsung ~]# >> > [root@Samsung ~]# echo 0 > /sys/devices/system/cpu/cpu1/online >> > CPU1: shutdown >> > [root@Samsung ~]# O >> > >> > [snip] (as a note, the mark of 'O' means 'OK' printing from u-boot. >> > >> > Thanks. >> > >> > Best regards, >> > Kgene. >> > -- >> > Kukjin Kim , Senior Engineer, >> > SW Solution Development Team, Samsung Electronics Co., Ltd. >> > >> > >> > >> >> >> >> Hi Mr Kim, >> >> >> >> Can you please queue this patchset in your tree for next merge window? >> >> The V5 version submitted fixes all the known issues. >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2012- >> >> January/079214.html >> >> >> >> Thanks, >> >> Amit Daniel >> >> >> >> >> >> On 17 February 2012 11:42, Amit Kucheria >> wrote: >> >> > On Fri, Feb 17, 2012 at 11:03 AM, Deepak Saxena >> >> wrote: >> >> > >> >> >> - Various patches from Linaro >> >> >> >> >> >> * samsung_cpuidle_l2_retention patch set from the power management >> >> >> WG >> >> > >> >> > Amit, is this now in your maintainer's tree queued up for 3.4? >> > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number
On 23 February 2012 12:16, R, Durgadoss wrote:
> Hi Amit,
>
>> -Original Message-----
>> From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
>> Kachhap
>> Sent: Wednesday, February 22, 2012 3:44 PM
>> To: linux...@lists.linux-foundation.org
>> Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
>> a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org;
>> amit.kach...@linaro.org; R, Durgadoss; rob@linaro.org; patc...@linaro.org
>> Subject: [PATCH 1/4] thermal: Add a new trip type to use cooling device
>> instance number
>>
>> This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
>> trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
>> device instance number. This helps the cooling device registered as
>> different instances to perform appropriate cooling action decision in
>> the set_cur_state call back function.
>>
>> Also since the trip temperature's are in ascending order so some logic
>> is put in place to skip the un-necessary checks.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> Documentation/thermal/sysfs-api.txt | 4 +-
>> drivers/thermal/thermal_sys.c | 45
>> --
>> include/linux/thermal.h | 1 +
>> 3 files changed, 45 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt
>> b/Documentation/thermal/sysfs-
>> api.txt
>> index 1733ab9..7a0c080 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -184,8 +184,8 @@ trip_point_[0-*]_temp
>>
>> trip_point_[0-*]_type
>> Strings which indicate the type of the trip point.
>> - E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
>> - thermal zone.
>> + E.g. it can be one of critical, hot, passive, active[0-1],
>> + state-active[0-*] for ACPI thermal zone.
>> RO, Optional
>>
>> cdev[0-*]
>> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
>> index 220ce7e..d4c9b20 100644
>> --- a/drivers/thermal/thermal_sys.c
>> +++ b/drivers/thermal/thermal_sys.c
>> @@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct
>> device_attribute *attr,
>> return sprintf(buf, "passive\n");
>> case THERMAL_TRIP_ACTIVE:
>> return sprintf(buf, "active\n");
>> + case THERMAL_TRIP_STATE_ACTIVE:
>> + return sprintf(buf, "state-active\n");
>> default:
>> return sprintf(buf, "unknown\n");
>> }
>> @@ -1034,10 +1036,10 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
>>
>> void thermal_zone_device_update(struct thermal_zone_device *tz)
>> {
>> - int count, ret = 0;
>> - long temp, trip_temp;
>> + int count, ret = 0, inst_id;
>> + long temp, trip_temp, max_state, last_trip_change = 0;
>> enum thermal_trip_type trip_type;
>> - struct thermal_cooling_device_instance *instance;
>> + struct thermal_cooling_device_instance *instance, *state_instance;
>> struct thermal_cooling_device *cdev;
>>
>> mutex_lock(&tz->lock);
>> @@ -1086,6 +1088,43 @@ void thermal_zone_device_update(struct
>> thermal_zone_device *tz)
>> cdev->ops->set_cur_state(cdev, 0);
>> }
>> break;
>> + case THERMAL_TRIP_STATE_ACTIVE:
>> + list_for_each_entry(instance, &tz->cooling_devices,
>> + node) {
>> + if (instance->trip != count)
>> + continue;
>> +
>> + if (temp <= last_trip_change)
>> + continue;
>> +
>> + inst_id = 0;
>> + /*
>> + *For this instance how many instance of same
>> + *cooling device occured before
>> + */
>> +
>> + list_for_each_entry(state_instance,
>> + &tz->cooling_devices, node) {
>> + if (instance->cdev ==
>> + state_instance->cdev)
>> +
Re: [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
Hi Durgadoss, Thanks for the detailed review comments. On 24 February 2012 16:34, R, Durgadoss wrote: > Hi Amit, > >> -Original Message----- >> From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel >> Kachhap >> Sent: Wednesday, February 22, 2012 3:44 PM >> To: linux...@lists.linux-foundation.org >> Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux- >> a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org; >> amit.kach...@linaro.org; R, Durgadoss; rob@linaro.org; patc...@linaro.org >> Subject: [PATCH 2/4] thermal: Add generic cpufreq cooling implementation >> >> This patch adds support for generic cpu thermal cooling low level >> implementations using frequency scaling up/down based on the request >> from user. Different cpu related cooling devices can be registered by the > > I believe what you mean by 'user' is another Driver using this code.. right ?? Yes. > >> user and the binding of these cooling devices to the corresponding >> trip points can be easily done as the registration API's return the >> cooling device pointer. The user of these api's are responsible for >> passing clipping frequency in percentages. >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> Documentation/thermal/cpu-cooling-api.txt | 40 >> drivers/thermal/Kconfig | 11 + >> drivers/thermal/Makefile | 1 + >> drivers/thermal/cpu_cooling.c | 310 >> + >> include/linux/cpu_cooling.h | 54 + >> 5 files changed, 416 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> create mode 100644 drivers/thermal/cpu_cooling.c >> create mode 100644 include/linux/cpu_cooling.h >> >> diff --git a/Documentation/thermal/cpu-cooling-api.txt >> b/Documentation/thermal/cpu-cooling-api.txt >> new file mode 100644 >> index 000..04de67c >> --- /dev/null >> +++ b/Documentation/thermal/cpu-cooling-api.txt >> @@ -0,0 +1,40 @@ >> +CPU cooling api's How To >> +=== >> + >> +Written by Amit Daniel Kachhap >> + >> +Updated: 13 Dec 2011 >> + >> +Copyright (c) 2011 Samsung Electronics Co., Ltd(http://www.samsung.com) >> + >> +0. Introduction >> + >> +The generic cpu cooling(freq clipping, cpuhotplug) provides >> +registration/unregistration api's to the user. The binding of the cooling >> +devices to the trip point is left for the user. The registration api's >> returns >> +the cooling device pointer. >> + >> +1. cpufreq cooling api's >> + >> +1.1 cpufreq registration api's >> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( >> + struct freq_pctg_table *tab_ptr, unsigned int tab_size, >> + const struct cpumask *mask_val) >> + >> + This interface function registers the cpufreq cooling device with the >> name >> + "thermal-cpufreq-%x". This api can support multiple instance of cpufreq >> cooling >> + devices. >> + >> + tab_ptr: The table containing the percentage of frequency to be clipped >> for >> + each cooling state. >> + .freq_clip_pctg: Percentage of frequency to be clipped for each allowed >> + cpus. >> + .polling_interval: polling interval for this cooling state. >> + tab_size: the total number of cooling state. > > Although I can understand that the table size is equal to > the total number of cooling states, it is better to name it > 'num_cooling_states' > (or something) that means what it is.. Yes your idea makes more sense. Will accept it in the next version. > >> + mask_val: all the allowed cpu's where frequency clipping can happen. >> + >> +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) >> + >> + This interface function unregisters the "thermal-cpufreq-%x" cooling >> device. >> + >> + cdev: Cooling device pointer which has to be unregistered. >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index f7f71b2..298c1cd 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -18,3 +18,14 @@ config THERMAL_HWMON >> depends on THERMAL >> depends on HWMON=y || HWMON=THERMAL >> default y >> + >> +config CPU_THERMAL >> + bool "generic cpu cooling support" >>
Re: [PATCH v6 3/9] ARM: exynos: Consolidate time keeping and irq enable
Hi,
I verified this patch on exynos4 based origen board.
Tested-by: Amit Daniel
Thanks,
Amit D
On 29 February 2012 08:41, Robert Lee wrote:
> Enable core cpuidle timekeeping and irq enabling and remove that
> handling from this code.
>
> Signed-off-by: Robert Lee
> ---
> arch/arm/mach-exynos/cpuidle.c | 53 ---
> 1 files changed, 6 insertions(+), 47 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
> index 9bf6743..75bb88b 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -34,22 +35,12 @@
>
> #define S5P_CHECK_AFTR 0xFCBA0D10
>
> -static int exynos4_enter_idle(struct cpuidle_device *dev,
> - struct cpuidle_driver *drv,
> - int index);
> static int exynos4_enter_lowpower(struct cpuidle_device *dev,
> struct cpuidle_driver *drv,
> int index);
>
> static struct cpuidle_state exynos4_cpuidle_set[] = {
> - [0] = {
> - .enter = exynos4_enter_idle,
> - .exit_latency = 1,
> - .target_residency = 10,
> - .flags = CPUIDLE_FLAG_TIME_VALID,
> - .name = "C0",
> - .desc = "ARM clock gating(WFI)",
> - },
> + [0] = CPUIDLE_ARM_WFI_STATE,
> [1] = {
> .enter = exynos4_enter_lowpower,
> .exit_latency = 300,
> @@ -63,8 +54,9 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
> static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
>
> static struct cpuidle_driver exynos4_idle_driver = {
> - .name = "exynos4_idle",
> - .owner = THIS_MODULE,
> + .name = "exynos4_idle",
> + .owner = THIS_MODULE,
> + .en_core_tk_irqen = 1,
> };
>
> /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
> @@ -103,13 +95,8 @@ static int exynos4_enter_core0_aftr(struct cpuidle_device
> *dev,
> struct cpuidle_driver *drv,
> int index)
> {
> - struct timeval before, after;
> - int idle_time;
> unsigned long tmp;
>
> - local_irq_disable();
> - do_gettimeofday(&before);
> -
> exynos4_set_wakeupmask();
>
> /* Set value of power down register for aftr mode */
> @@ -148,34 +135,6 @@ static int exynos4_enter_core0_aftr(struct
> cpuidle_device *dev,
> /* Clear wakeup state register */
> __raw_writel(0x0, S5P_WAKEUP_STAT);
>
> - do_gettimeofday(&after);
> -
> - local_irq_enable();
> - idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
> - (after.tv_usec - before.tv_usec);
> -
> - dev->last_residency = idle_time;
> - return index;
> -}
> -
> -static int exynos4_enter_idle(struct cpuidle_device *dev,
> - struct cpuidle_driver *drv,
> - int index)
> -{
> - struct timeval before, after;
> - int idle_time;
> -
> - local_irq_disable();
> - do_gettimeofday(&before);
> -
> - cpu_do_idle();
> -
> - do_gettimeofday(&after);
> - local_irq_enable();
> - idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
> - (after.tv_usec - before.tv_usec);
> -
> - dev->last_residency = idle_time;
> return index;
> }
>
> @@ -190,7 +149,7 @@ static int exynos4_enter_lowpower(struct cpuidle_device
> *dev,
> new_index = drv->safe_state_index;
>
> if (new_index == 0)
> - return exynos4_enter_idle(dev, drv, new_index);
> + return cpuidle_simple_enter(dev, drv, new_index);
> else
> return exynos4_enter_core0_aftr(dev, drv, new_index);
> }
> --
> 1.7.1
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/4] hwmon: exynos4: Move thermal sensor driver to driver/mfd directory
On 3 March 2012 17:51, Sylwester Nawrocki wrote: > On 03/03/2012 12:06 PM, Amit Daniel Kachhap wrote: >> >> This movement is needed because the hwmon entries and corresponding >> sysfs interface is a duplicate of utilities already provided by >> driver/thermal/thermal_sys.c. The goal is to place it in mfd folder >> and add necessary calls to get the temperature information. >> >> Signed-off-by: Amit Daniel Kachhap >> Signed-off-by: Donggeun Kim >> --- >> Documentation/hwmon/exynos4_tmu | 81 -- >> Documentation/mfd/exynos4_tmu | 81 ++ >> drivers/hwmon/Kconfig | 10 - >> drivers/hwmon/Makefile | 1 - >> drivers/hwmon/exynos4_tmu.c | 514 >> --- >> drivers/mfd/Kconfig | 10 + >> drivers/mfd/Makefile | 1 + >> drivers/mfd/exynos4_tmu.c | 514 >> +++ >> 8 files changed, 606 insertions(+), 606 deletions(-) >> delete mode 100644 Documentation/hwmon/exynos4_tmu >> create mode 100644 Documentation/mfd/exynos4_tmu >> delete mode 100644 drivers/hwmon/exynos4_tmu.c >> create mode 100644 drivers/mfd/exynos4_tmu.c > > > Please consider adding -M option to git format-patch next time, which > would make the patch smaller and would let to see clearly what's moved > and what has changed. Sure , will keep it in mind. Thanks > > -- > Thanks, > Sylwester ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [lm-sensors] [linux-pm] [PATCH 2/4] hwmon: exynos4: Move thermal sensor driver to driver/mfd directory
On 3 March 2012 23:34, Guenter Roeck wrote: > On Sat, Mar 03, 2012 at 11:44:10AM -0500, Mark Brown wrote: >> On Sat, Mar 03, 2012 at 04:36:05PM +0530, Amit Daniel Kachhap wrote: >> > This movement is needed because the hwmon entries and corresponding >> > sysfs interface is a duplicate of utilities already provided by >> > driver/thermal/thermal_sys.c. The goal is to place it in mfd folder >> > and add necessary calls to get the temperature information. >> >> > --- a/Documentation/hwmon/exynos4_tmu >> > +++ /dev/null >> >> Moving this seems to be a failure, the device is exposing a hwmon >> interface even if you've moved the code to mfd (though it doesn't >> actually look like a multi-function device at all as far as I can see - >> usually a MFD would have a bunch of unrelated functionality while this >> has one function used by two subsystems). >> >> If anything it looks like the ADC driver ought to be moved into IIO with >> either generic or Exynos specific function drivers layered on top of it >> in hwmon and thermal making use of the values that are read. >> > I would agree. Or maybe move it all to thermal, since thermal devices register > the hwmon subsystem. Ok I agree with your suggestion of moving into thermal. Since I wanted to separate exynos specific generic thermal implementation with the H/W driver so that other versions of the sensor driver can easily hook into the common part. Anyway this implementation seems possible. Thanks for the comments > > Guenter ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
Hi Durgadoss,
Thanks for the detailed review.
On 12 March 2012 16:21, R, Durgadoss wrote:
> Hi Amit,
>
> Thanks for keeping this up. And Sorry for late reply.
>
>> -Original Message-----
>> From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
>> Kachhap
>> Sent: Saturday, March 03, 2012 4:36 PM
>> To: linux...@lists.linux-foundation.org; linux-samsung-...@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
>> a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org; lm-
>> sens...@lm-sensors.org; amit.kach...@linaro.org; eduardo.valen...@ti.com; R,
>> Durgadoss; patc...@linaro.org
>> Subject: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux
>> thermal layer
>>
>> This codes uses the generic linux thermal layer and creates a bridge
>> between temperature sensors, linux thermal framework and cooling devices
>> for samsung exynos platform. This layer recieves or monitor the
>> temperature from the sensor and informs the generic thermal layer to take
>> the necessary cooling action.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> drivers/thermal/Kconfig | 8 +
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/exynos_thermal.c | 272
>> ++
>> include/linux/exynos_thermal.h | 72 ++
>> 4 files changed, 353 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/thermal/exynos_thermal.c
>> create mode 100644 include/linux/exynos_thermal.h
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 298c1cd..4e8df56 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -29,3 +29,11 @@ config CPU_THERMAL
>> This will be useful for platforms using the generic thermal interface
>> and not the ACPI interface.
>> If you want this support, you should say Y or M here.
>> +
>> +config SAMSUNG_THERMAL_INTERFACE
>> + bool "Samsung Thermal interface support"
>> + depends on THERMAL && CPU_THERMAL
>> + help
>> + This is a samsung thermal interface which will be used as
>> + a link between sensors and cooling devices with linux thermal
>> + framework.
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 655cbc4..c67b6b2 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -4,3 +4,4 @@
>>
>> obj-$(CONFIG_THERMAL) += thermal_sys.o
>> obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
>> +obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> new file mode 100644
>> index 000..878d45c
>> --- /dev/null
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -0,0 +1,272 @@
>> +/* linux/drivers/thermal/exynos_thermal.c
>> + *
>> + * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define MAX_COOLING_DEVICE 4
>> +struct exynos4_thermal_zone {
>> + unsigned int idle_interval;
>> + unsigned int active_interval;
>> + struct thermal_zone_device *therm_dev;
>> + struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
>> + unsigned int cool_dev_size;
>> + struct platform_device *exynos4_dev;
>> + struct thermal_sensor_conf *sensor_conf;
>> +};
>> +
>> +static struct exynos4_thermal_zone *th_zone;
>> +
>> +static int exynos4_get_mode(struct thermal_zone_device *thermal,
>> + enum thermal_device_mode *mode)
>> +{
>> + if (th_zone->sensor_conf) {
>> + pr_info("Temperature sensor not initialised\n");
>> + *mode = THERMAL_DEVICE_DISABLED;
>> + } else
>> + *mode = THERMAL_DEVICE_ENABLED;
>> + return 0;
>> +}
>> +
>> +static int exynos4_set_mode(struct thermal_zone_device *thermal,
>> + enum thermal
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
On 13 March 2012 09:24, Tushar Behera wrote:
> On 03/03/2012 04:36 PM, Amit Daniel Kachhap wrote:
>> This codes uses the generic linux thermal layer and creates a bridge
>> between temperature sensors, linux thermal framework and cooling devices
>> for samsung exynos platform. This layer recieves or monitor the
>> temperature from the sensor and informs the generic thermal layer to take
>> the necessary cooling action.
>>
>> Signed-off-by: Amit Daniel Kachhap
>
> If you are resubmitting the patchset, it would be good if you can
> address the nitpicks. Sorry for being so late in pointing them out now,
> none of the comments below are pertaning to the code flow - so you can
> ignore these comments if there are no plans for resubmission.
Thanks tushar. I will include your suggestion for next patchset submission.
>
>> ---
>> drivers/thermal/Kconfig | 8 +
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/exynos_thermal.c | 272
>> ++
>> include/linux/exynos_thermal.h | 72 ++
>> 4 files changed, 353 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/thermal/exynos_thermal.c
>> create mode 100644 include/linux/exynos_thermal.h
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 298c1cd..4e8df56 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -29,3 +29,11 @@ config CPU_THERMAL
>> This will be useful for platforms using the generic thermal interface
>> and not the ACPI interface.
>> If you want this support, you should say Y or M here.
>> +
>> +config SAMSUNG_THERMAL_INTERFACE
>> + bool "Samsung Thermal interface support"
>> + depends on THERMAL && CPU_THERMAL
>> + help
>> + This is a samsung thermal interface which will be used as
>> + a link between sensors and cooling devices with linux thermal
>> + framework.
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 655cbc4..c67b6b2 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -4,3 +4,4 @@
>>
>> obj-$(CONFIG_THERMAL) += thermal_sys.o
>> obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
>> +obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> new file mode 100644
>> index 000..878d45c
>> --- /dev/null
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -0,0 +1,272 @@
>> +/* linux/drivers/thermal/exynos_thermal.c
>> + *
>> + * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define MAX_COOLING_DEVICE 4
>> +struct exynos4_thermal_zone {
>> + unsigned int idle_interval;
>> + unsigned int active_interval;
>> + struct thermal_zone_device *therm_dev;
>> + struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
>> + unsigned int cool_dev_size;
>> + struct platform_device *exynos4_dev;
>> + struct thermal_sensor_conf *sensor_conf;
>> +};
>> +
>> +static struct exynos4_thermal_zone *th_zone;
>> +
>> +static int exynos4_get_mode(struct thermal_zone_device *thermal,
>> + enum thermal_device_mode *mode)
>
> Space here for intending is not required, we can go with TABs only.
>
>> +{
>> + if (th_zone->sensor_conf) {
>> + pr_info("Temperature sensor not initialised\n");
>> + *mode = THERMAL_DEVICE_DISABLED;
>> + } else
>> + *mode = THERMAL_DEVICE_ENABLED;
>> + return 0;
>> +}
>> +
>> +static int exynos4_set_mode(struct thermal_zone_device *thermal,
>> + enum thermal_device_mode mode)
>
> Space here for intending is not required, we can go with TABs only.
>
>> +{
>> + if (!th_zone->therm_dev) {
>> + pr_notice("thermal zone not registered\n");
>> + return 0;
>> + }
>> + if (mode == THERMAL_DEVICE_ENABLED)
>> + th_zone->therm_dev->polling_delay =
>> + th_zone->active_interval*1000;
>> + else
>> + th_zone->therm_dev->polling_delay =
>> + th_zone->idle_interval*1000;
>> +
>> + thermal_zone_device_update(th_zone->therm_dev);
>> + pr_info("thermal polling set for duration=%d sec\n",
>> + th_zone->therm_dev->polling_delay/1000);
>> + return 0;
>> +}
>> +
>> +/*This may be called from interrupt based temperature sensor*/
>
>
>> +void exynos4_report_trigger(void)
>> +{
>> + unsigned
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
On 11 March 2012 09:41, Sundar wrote: > Hi Amit, > > I am new here; so please bear with my questions/doubts :) > > On Wed, Feb 22, 2012 at 3:44 PM, Amit Daniel Kachhap > wrote: >> This patch adds support for generic cpu thermal cooling low level >> implementations using frequency scaling up/down based on the request >> from user. Different cpu related cooling devices can be registered by the >> user and the binding of these cooling devices to the corresponding > > "Different cpu related cooling devices": Do you mean cooling devices > for different CPUs (num_cpus) or are you referring to different > customers aka consumer drivers who could use this framework and impose > the cooling. Correct but the consumer driver only has to use the other thermal-sys.c functions. Only register cpu cooling devices is implemented in this work. > >> trip points can be easily done as the registration API's return the >> cooling device pointer. The user of these api's are responsible for >> passing clipping frequency in percentages. > > Why do you want to pass the clipping frequency in percentages? Wouldnt > it be simpler for any platform sensor driver to just pass the > frequency it wants to throttle the CPU? Yes i also agree. > >> + >> + This interface function registers the cpufreq cooling device with the >> name >> + "thermal-cpufreq-%x". This api can support multiple instance of cpufreq >> cooling >> + devices. > > When you refer to cooling devices, is it the number of instances > per-CPU that is supported? Sorry I am unable to follow. CPU cooling apis can be used as below 1)per cpus if different frequency clipping is needed. so multiple instance of this api can be called. 2)for all the cpus as provided with mask when same frequency clipping is needed. In this case single instance is fine. > >> + .polling_interval: polling interval for this cooling state. >> + tab_size: the total number of cooling state. > > By cooling_state, I assume you are referring to the thermal state for > the platform? or only for the CPU? Yes thermal state of the platform. > >> + mask_val: all the allowed cpu's where frequency clipping can happen. > > Why should this be a new variable? The policy->affected_cpus should be > the same as this IMO? yes this should be same. I will check this. > >> + help >> + This implements the generic cpu cooling mechanism through frequency >> + reduction, cpu hotplug and any other ways of reducing temperature. >> An > > Apart from reducing the CPU frequency, (probably) CPU hotplug, what > other means of reducing CPU temperature? Or are you referring to any > platform temperature controls? No only CPU related. Other control ways I thought was cpuidle with low power states and cpu_power factor modifications used in the schedular. > > It isnt very clear from the documentation (at least to me) if this is > only for CPU cooling or generic platform cooling. > > Cheers! > -- > - > The views expressed in this email are personal and do not necessarily > echo my employers'. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
On 13 March 2012 15:44, Sundar wrote: > On Tue, Mar 13, 2012 at 3:30 PM, Amit Kucheria > wrote: >> Sundar, > > Hi Amit, > >> At the moment it doesn't. But there was some discussion around >> creating something that will work with devfreq. This would allow >> peripheral drivers to be plugged in as well. Amit is investigating >> that at present. > > What if we work towards a generic constraint framework which models > thermals as a performance constraint. > > Drivers can register to this constraint; platform code can then decide > to issue restrictions either to the CPU or other power-hungry > peripherals based on the platform conditions. > > That also allows to model CPU frequency as a generic constraint but > via an actual consumer, say the thermal driver. Yes that should be helpful. Even the things your are suggesting are somewhat same with some patches submitted which sets cpufreq min/max constraint. > > Cheers! > > -- > - > The views expressed in this email are personal and do not necessarily > echo my employers. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 3/6] thermal: Add generic cpuhotplug cooling implementation
On 19 March 2012 17:15, Srivatsa S. Bhat
wrote:
> On 03/19/2012 11:47 AM, Amit Daniel Kachhap wrote:
>
>> This patch adds support for generic cpu thermal cooling low level
>> implementations using cpuhotplug based on the thermal level requested
>> from user. Different cpu related cooling devices can be registered by the
>> user and the binding of these cooling devices to the corresponding
>> trip points can be easily done as the registration APIs return the
>> cooling device pointer. The user of these APIs are responsible for
>> passing the cpumask.
>>
>
>
> I am really not aware of the cpu thermal cooling stuff, but since this patch
> deals with CPU Hotplug (which I am interested in), I have some questions
> below..
>
>
>> Signed-off-by: Amit Daniel Kachhap
>> +
>> +static int cpuhotplug_get_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + int ret = -EINVAL;
>> + struct hotplug_cooling_device *hotplug_dev;
>> +
>> + mutex_lock(&cooling_cpuhotplug_lock);
>> + list_for_each_entry(hotplug_dev, &cooling_cpuhotplug_list, node) {
>> + if (hotplug_dev && hotplug_dev->cool_dev == cdev) {
>> + *state = hotplug_dev->hotplug_state;
>> + ret = 0;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&cooling_cpuhotplug_lock);
>> + return ret;
>> +}
>> +
>> +/*This cooling may be as ACTIVE type*/
>> +static int cpuhotplug_set_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long state)
>> +{
>> + int cpuid, this_cpu = smp_processor_id();
>
>
> What prevents this task from being migrated to another CPU?
> IOW, what ensures that 'this_cpu' remains valid throughout this function?
>
> I see that you are acquiring mutex locks below.. So this is definitely not
> a preempt disabled section.. so I guess my question above is valid..
>
> Or is this code bound to a particular cpu?
No this thread is not bound to a cpu. Your comment is valid and some
synchronization is needed for preemption. Thanks for pointing this
out.
>
>> + struct hotplug_cooling_device *hotplug_dev;
>> +
>> + mutex_lock(&cooling_cpuhotplug_lock);
>> + list_for_each_entry(hotplug_dev, &cooling_cpuhotplug_list, node)
>> + if (hotplug_dev && hotplug_dev->cool_dev == cdev)
>> + break;
>> +
>> + mutex_unlock(&cooling_cpuhotplug_lock);
>> + if (!hotplug_dev || hotplug_dev->cool_dev != cdev)
>> + return -EINVAL;
>> +
>> + if (hotplug_dev->hotplug_state == state)
>> + return 0;
>> +
>> + /*
>> + * This cooling device may be of type ACTIVE, so state field can
>> + * be 0 or 1
>> + */
>> + if (state == 1) {
>> + for_each_cpu(cpuid, hotplug_dev->allowed_cpus) {
>> + if (cpu_online(cpuid) && (cpuid != this_cpu))
>
>
> What prevents the cpu numbered cpuid from being taken down right at this
> moment?
> Don't you need explicit synchronization with CPU Hotplug using something like
> get_online_cpus()/put_online_cpus() here?
>
>> + cpu_down(cpuid);
>> + }
>> + } else if (state == 0) {
>> + for_each_cpu(cpuid, hotplug_dev->allowed_cpus) {
>> + if (!cpu_online(cpuid) && (cpuid != this_cpu))
>
>
> Same here.
>
>> + cpu_up(cpuid);
>> + }
>> + } else {
>> + return -EINVAL;
>> + }
>> +
>> + hotplug_dev->hotplug_state = state;
>> +
>> + return 0;
>> +}
>> +/* bind hotplug callbacks to cpu hotplug cooling device */
>> +static struct thermal_cooling_device_ops cpuhotplug_cooling_ops = {
>> + .get_max_state = cpuhotplug_get_max_state,
>> + .get_cur_state = cpuhotplug_get_cur_state,
>> + .set_cur_state = cpuhotplug_set_cur_state,
>> +};
>> +
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] thermal: Fix for setting the thermal zone mode to enable/disable
On 21 March 2012 19:43, Jean Delvare wrote:
> On Wed, 21 Mar 2012 16:40:01 +0530, Amit Daniel Kachhap wrote:
>> Basically without this patch changing the mode of thermal zone
>> is not possible as wrong string size is passed to strncmp.
>
> Actually it is possible,
> $ echo -n disabled > mode
> works fine. But it fails without the -n, your patch would fix that.
Thanks for pointing this out. Anyway this patch makes some sense until
sysfs takes care of this.
>
> Acked-by: Jean Delvare
>
> Note that a quick grep suggests that drivers/misc/ad525x_dpot.c,
> security/selinux/hooks.c and arch/m68k/sun3/prom/console.c suffer from
> the same issue, if you want to fix them too.
>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> drivers/thermal/thermal_sys.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
>> index 220ce7e..96da1af 100644
>> --- a/drivers/thermal/thermal_sys.c
>> +++ b/drivers/thermal/thermal_sys.c
>> @@ -152,9 +152,9 @@ mode_store(struct device *dev, struct device_attribute
>> *attr,
>> if (!tz->ops->set_mode)
>> return -EPERM;
>>
>> - if (!strncmp(buf, "enabled", sizeof("enabled")))
>> + if (!strncmp(buf, "enabled", sizeof("enabled") - 1))
>> result = tz->ops->set_mode(tz, THERMAL_DEVICE_ENABLED);
>> - else if (!strncmp(buf, "disabled", sizeof("disabled")))
>> + else if (!strncmp(buf, "disabled", sizeof("disabled") - 1))
>> result = tz->ops->set_mode(tz, THERMAL_DEVICE_DISABLED);
>> else
>> result = -EINVAL;
>
>
> --
> Jean Delvare
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number
Hi Eduardo,
On 3 April 2012 19:45, Eduardo Valentin wrote:
> Hello,
>
> On Thu, Feb 23, 2012 at 04:50:14PM +0530, Amit Kachhap wrote:
>> On 23 February 2012 12:16, R, Durgadoss wrote:
>> > Hi Amit,
>> >
>> >> -Original Message-
>> >> From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
>> >> Kachhap
>> >> Sent: Wednesday, February 22, 2012 3:44 PM
>> >> To: linux...@lists.linux-foundation.org
>> >> Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
>> >> a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org;
>> >> amit.kach...@linaro.org; R, Durgadoss; rob@linaro.org;
>> >> patc...@linaro.org
>> >> Subject: [PATCH 1/4] thermal: Add a new trip type to use cooling device
>> >> instance number
>> >>
>> >> This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
>> >> trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
>> >> device instance number. This helps the cooling device registered as
>> >> different instances to perform appropriate cooling action decision in
>> >> the set_cur_state call back function.
>> >>
>> >> Also since the trip temperature's are in ascending order so some logic
>> >> is put in place to skip the un-necessary checks.
>> >>
>> >> Signed-off-by: Amit Daniel Kachhap
>> >> ---
>> >> Documentation/thermal/sysfs-api.txt | 4 +-
>> >> drivers/thermal/thermal_sys.c | 45
>> >> --
>> >> include/linux/thermal.h | 1 +
>> >> 3 files changed, 45 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/Documentation/thermal/sysfs-api.txt
>> >> b/Documentation/thermal/sysfs-
>> >> api.txt
>> >> index 1733ab9..7a0c080 100644
>> >> --- a/Documentation/thermal/sysfs-api.txt
>> >> +++ b/Documentation/thermal/sysfs-api.txt
>> >> @@ -184,8 +184,8 @@ trip_point_[0-*]_temp
>> >>
>> >> trip_point_[0-*]_type
>> >> Strings which indicate the type of the trip point.
>> >> - E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
>> >> - thermal zone.
>> >> + E.g. it can be one of critical, hot, passive, active[0-1],
>> >> + state-active[0-*] for ACPI thermal zone.
>> >> RO, Optional
>> >>
>> >> cdev[0-*]
>> >> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
>> >> index 220ce7e..d4c9b20 100644
>> >> --- a/drivers/thermal/thermal_sys.c
>> >> +++ b/drivers/thermal/thermal_sys.c
>> >> @@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct
>> >> device_attribute *attr,
>> >> return sprintf(buf, "passive\n");
>> >> case THERMAL_TRIP_ACTIVE:
>> >> return sprintf(buf, "active\n");
>> >> + case THERMAL_TRIP_STATE_ACTIVE:
>> >> + return sprintf(buf, "state-active\n");
>> >> default:
>> >> return sprintf(buf, "unknown\n");
>> >> }
>> >> @@ -1034,10 +1036,10 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
>> >>
>> >> void thermal_zone_device_update(struct thermal_zone_device *tz)
>> >> {
>> >> - int count, ret = 0;
>> >> - long temp, trip_temp;
>> >> + int count, ret = 0, inst_id;
>> >> + long temp, trip_temp, max_state, last_trip_change = 0;
>> >> enum thermal_trip_type trip_type;
>> >> - struct thermal_cooling_device_instance *instance;
>> >> + struct thermal_cooling_device_instance *instance, *state_instance;
>> >> struct thermal_cooling_device *cdev;
>> >>
>> >> mutex_lock(&tz->lock);
>> >> @@ -1086,6 +1088,43 @@ void thermal_zone_device_update(struct
>> >> thermal_zone_device *tz)
>> >> cdev->ops->set_cur_state(cdev, 0);
>> >> }
>> >> break;
>> >> + case THERMAL_TRIP_STATE_ACTIVE:
>> >> + list_for_each_entry(instance, &tz->cooling_devices,
>> >> +
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
Hi Len/Rui, Any comment or feedback from your side about the status of this patch? Is it merge-able or major re-work is needed? I have fixed most of the comments in this patchset and currently working on some of the minor comments received and will submit them shortly. Regards, Amit Daniel On 19 March 2012 11:47, Amit Daniel Kachhap wrote: > Changes since V1: > *Moved the sensor driver to driver/thermal folder from driver/hwmon folder > as suggested by Mark Brown and Guenter Roeck > *Added notifier support to notify the registered drivers of any cpu cooling > action. The driver can modify the default cooling behaviour(eg set different > max clip frequency). > *The percentage based frequency replaced with absolute clipped frequency. > *Some more conditional checks when setting max frequency. > *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to > THERMAL_TRIP_STATE_INSTANCE > *Many review comments from R, Durgadoss and > eduardo.valen...@ti.com implemented. > *Removed cooling stats through debugfs patch > *The V1 based can be found here, > https://lkml.org/lkml/2012/2/22/123 > http://lkml.org/lkml/2012/3/3/32 > > Changes since RFC: > *Changed the cpu cooling registration/unregistration API's to instance based > *Changed the STATE_ACTIVE trip type to pass correct instance id > *Adding support to restore back the policy->max_freq after doing frequency > clipping. > *Moved the trip cooling stats from sysfs node to debugfs node as suggested > by Greg KH g...@kroah.com > *Incorporated several review comments from eduardo.valen...@ti.com > *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd > as discussed with Guenter Roeck and > Donggeun Kim (https://lkml.org/lkml/2012/1/5/7) > *Some changes according to the changes in common cpu cooling APIs > *The RFC based patches can be found here, > https://lkml.org/lkml/2011/12/13/186 > https://lkml.org/lkml/2011/12/21/169 > > > Brief Description: > > 1) The generic cooling devices code is placed inside driver/thermal/* as > placing inside acpi folder will need un-necessary enabling of acpi code. This > codes is architecture independent. > > 2) This patchset adds a new trip type THERMAL_TRIP_STATE_INSTANCE which passes > cooling device instance number and may be helpful for cpufreq cooling devices > to take the correct cooling action. This trip type avoids the temperature > comparision check again inside the cooling handler. > > 3) This patchset adds generic cpu cooling low level implementation through > frequency clipping and cpu hotplug. In future, other cpu related cooling > devices may be added here. An ACPI version of this already exists > (drivers/acpi/processor_thermal.c). But this will be useful for platforms > like ARM using the generic thermal interface along with the generic cpu > cooling devices. The cooling device registration API's return cooling device > pointers which can be easily binded with the thermal zone trip points. > The important APIs exposed are, > a)struct thermal_cooling_device *cpufreq_cooling_register( > struct freq_clip_table *tab_ptr, unsigned int tab_size, > const struct cpumask *mask_val) > b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) > > 4) Samsung exynos platform thermal implementation is done using the generic > cpu cooling APIs and the new trip type. The temperature sensor driver present > in the hwmon folder(registered as hwmon driver) is moved to thermal folder > and registered as a thermal driver. > > All this patchset is based on Kernel version 3.3-rc7 > > A simple data/control flow diagrams is shown below, > > Core Linux thermal <-> Exynos thermal interface <- Temperature Sensor > | | > \|/ | > Cpufreq cooling device <--- > > > Amit Daniel Kachhap (6): > thermal: Add a new trip type to use cooling device instance number > thermal: Add generic cpufreq cooling implementation > thermal: Add generic cpuhotplug cooling implementation > hwmon: exynos4: Move thermal sensor driver to driver/thermal > directory > thermal: exynos4: Register the tmu sensor with the kernel thermal > layer > ARM: exynos4: Add thermal sensor driver platform device support > > Documentation/hwmon/exynos4_tmu | 81 --- > Documentation/thermal/cpu-cooling-api.txt | 76 +++ > Documentation/thermal/exynos4_tmu | 52 ++ > Documentation/thermal/sysfs-api.txt | 4 +- > arch/arm/mach-exynos/Kconfig | 11 + > arch/arm/mach-exynos/Makefile | 1 + > arch/arm/mach-exynos/clock.c | 4 + > arch/arm/mach-exynos/dev-tmu.c | 39 ++ > arch/arm/mach-exynos/include/mach/irqs.h | 2 + > arch/arm/mach-exynos/include/mach/map.h | 1 + > arch/arm/mach-exynos/mach-origen.c | 1 + > arch/arm/plat-samsung/include/plat/devs.h | 1 + > drivers/hwmon/Kconfig | 10 - >
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
Hi Rui,
Thanks for looking into the patches.
On 10 April 2012 06:28, Zhang Rui wrote:
> Hi, Amit,
>
> On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
>> Hi Len/Rui,
>>
>> Any comment or feedback from your side about the status of this patch?
>> Is it merge-able or major re-work is needed? I have fixed most of the
>> comments in this patchset and currently working on some of the minor
>> comments received and will submit them shortly.
>>
> Sorry for the late response.
>
> First of all, it makes sense to me to introduce the generic cpufrq
> cooling implementation.
ok thanks
> But I still have some questions.
> I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
> that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
> current passive handling in the generic thermal layer well, right?
> e.g. there is no tc1/tc2 on exynos4.
>
> If yes, is it possible that we can enhance the passive cooling to
> support the generic processor cooling?
> say, introduce another way to throttle the processor in
> thermal_zone_device_passive when tc1 and tc2 are not available?
I agree that this new trip type code can be moved into passive trip
type when tc1 and tc2 are 0. but this is special type of cooling
devices behaviour where only instances of the same cooling device is
binded to a trip point. The order of mapping is the only
differentiating criteria and there are some checks used to implement
this like
1) The trip points should be in ascending order.(This is missing in my
original patch, so I added below)
2) The set_cur_state has to be called for the exact temp range so
get_cur_state(&state) and set_cur_state(state ++/state--) logic is not
possible.
3) set_cur_state is called as set_cur_state(cdev_instance).
There is a chance that people might confuse that these checks are
applicable for passive trip types also which is not the case here.
@@ -1187,6 +1228,21 @@ struct thermal_zone_device
*thermal_zone_device_register(char *type,
tz->ops->get_trip_type(tz, count, &trip_type);
if (trip_type == THERMAL_TRIP_PASSIVE)
passive = 1;
+ /*
+* For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
+* be in ascending order.
+ */
+ if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
+ tz->ops->get_trip_temp(tz, count, &trip_temp);
+ if (first_trip_temp == 0)
+ first_trip_temp = trip_temp;
+ else if (first_trip_temp < trip_temp)
+ first_trip_temp = trip_temp;
+ else if (first_trip_temp > trip_temp) {
+ pr_warn("Zone trip points should be in
ascending order\n");
+ goto unregister;
+ }
+ }
}
if (!passive)
Anyway there is other alternative where this new trip type is not
needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
I had thought to make this generic and just to manage with 1 cooling
device.
What is your view?
Thanks,
Amit Daniel
>
> thanks,
> rui
>
>> Regards,
>> Amit Daniel
>>
>> On 19 March 2012 11:47, Amit Daniel Kachhap wrote:
>> > Changes since V1:
>> > *Moved the sensor driver to driver/thermal folder from driver/hwmon folder
>> > as suggested by Mark Brown and Guenter Roeck
>> > *Added notifier support to notify the registered drivers of any cpu cooling
>> > action. The driver can modify the default cooling behaviour(eg set
>> > different
>> > max clip frequency).
>> > *The percentage based frequency replaced with absolute clipped frequency.
>> > *Some more conditional checks when setting max frequency.
>> > *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
>> > THERMAL_TRIP_STATE_INSTANCE
>> > *Many review comments from R, Durgadoss and
>> > eduardo.valen...@ti.com implemented.
>> > *Removed cooling stats through debugfs patch
>> > *The V1 based can be found here,
>> > https://lkml.org/lkml/2012/2/22/123
>> > http://lkml.org/lkml/2012/3/3/32
>> >
>> > Changes since RFC:
>> > *Changed the cpu cooling registration/unregistration API's to instance
>> > based
>> > *Changed the STATE_ACTIVE trip type to pass correct instance id
>> > *Adding support to restore back the policy->max_freq after doing frequency
>> > clipping.
>> > *Moved the trip cooling stats from sysfs node to debugfs node as suggested
>
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 16 April 2012 07:37, Zhang Rui wrote:
> On 三, 2012-04-11 at 18:17 +0530, Amit Kachhap wrote:
>> Hi Rui,
>>
>> Thanks for looking into the patches.
>>
>> On 10 April 2012 06:28, Zhang Rui wrote:
>> > Hi, Amit,
>> >
>> > On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
>> >> Hi Len/Rui,
>> >>
>> >> Any comment or feedback from your side about the status of this patch?
>> >> Is it merge-able or major re-work is needed? I have fixed most of the
>> >> comments in this patchset and currently working on some of the minor
>> >> comments received and will submit them shortly.
>> >>
>> > Sorry for the late response.
>> >
>> > First of all, it makes sense to me to introduce the generic cpufrq
>> > cooling implementation.
>> ok thanks
>> > But I still have some questions.
>> > I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
>> > that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
>> > current passive handling in the generic thermal layer well, right?
>> > e.g. there is no tc1/tc2 on exynos4.
>> >
>> > If yes, is it possible that we can enhance the passive cooling to
>> > support the generic processor cooling?
>> > say, introduce another way to throttle the processor in
>> > thermal_zone_device_passive when tc1 and tc2 are not available?
>>
>> I agree that this new trip type code can be moved into passive trip
>> type when tc1 and tc2 are 0. but this is special type of cooling
>> devices behaviour where only instances of the same cooling device is
>> binded to a trip point. The order of mapping is the only
>> differentiating criteria and there are some checks used to implement
>> this like
>> 1) The trip points should be in ascending order.(This is missing in my
>> original patch, so I added below)
>> 2) The set_cur_state has to be called for the exact temp range so
>> get_cur_state(&state) and set_cur_state(state ++/state--) logic is not
>> possible.
>> 3) set_cur_state is called as set_cur_state(cdev_instance).
>
> Do you really need two THERMAL_TRIP_STATE_INSTANCE trip points?
Sorry for late reply as I was off for vacation.
Yes we need 2 trip points of type THERMAL_TRIP_STATE_INSTANCE as we
need different cooling for these 2 zones. Anyways Do you feel that
these whole/partial patch series(cpufreq cooling api's, new trip type
etc) is ack-able or some modification is needed?
>
> I'm not sure if my understanding is right, but IMO, we can have one
> THERMAL_TRIP_STATE_INSTANCE only, for both MONIROR_ZONE and WARN_ZONE,
> and the trip temperature equals MONIROR_ZONE.
> The cpufreq cooling device will work in the same way, no?
>
> thanks,
> rui
>
>> There is a chance that people might confuse that these checks are
>> applicable for passive trip types also which is not the case here.
>>
>> @@ -1187,6 +1228,21 @@ struct thermal_zone_device
>> *thermal_zone_device_register(char *type,
>> tz->ops->get_trip_type(tz, count, &trip_type);
>> if (trip_type == THERMAL_TRIP_PASSIVE)
>> passive = 1;
>> + /*
>> + * For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
>> + * be in ascending order.
>> + */
>> + if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
>> + tz->ops->get_trip_temp(tz, count, &trip_temp);
>> + if (first_trip_temp == 0)
>> + first_trip_temp = trip_temp;
>> + else if (first_trip_temp < trip_temp)
>> + first_trip_temp = trip_temp;
>> + else if (first_trip_temp > trip_temp) {
>> + pr_warn("Zone trip points should be in
>> ascending order\n");
>> + goto unregister;
>> + }
>> + }
>> }
>>
>> if (!passive)
>>
>> Anyway there is other alternative where this new trip type is not
>> needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
>> and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
>> I had thought to make this generic and just to manage with 1 cooling
>> device.
>> What is your view?
>>
>> Thanks,
>> Amit Daniel
>>
>>
>> >
>> > thanks,
>> > rui
>> >
>
Re: [PATCH] ARM: exynos: Adapt to cpuidle core time keeping and irq enable
Hi Mr Kukjin,
Any comment or update about this patch?
Regards,
Amit Daniel
On Mon, Apr 30, 2012 at 10:13 PM, Rob Lee wrote:
> On Wed, Apr 25, 2012 at 9:44 AM, Daniel Lezcano
> wrote:
>> On 04/25/2012 02:11 PM, Amit Daniel Kachhap wrote:
>>>
>>> This patch enables core cpuidle timekeeping and irq enabling and
>>> remove those redundant parts from the exynos cpuidle drivers
>>>
>>> CC: Daniel Lezcano
>>> CC: Robert Lee
>>> Signed-off-by: Amit Daniel
>>> ---
>>> arch/arm/mach-exynos/cpuidle.c | 53
>>> ---
>>> 1 files changed, 6 insertions(+), 47 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/cpuidle.c
>>> b/arch/arm/mach-exynos/cpuidle.c
>>> index 33ab4e7..26dac28 100644
>>> --- a/arch/arm/mach-exynos/cpuidle.c
>>> +++ b/arch/arm/mach-exynos/cpuidle.c
>>> @@ -20,6 +20,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> @@ -34,22 +35,12 @@
>>>
>>> #define S5P_CHECK_AFTR 0xFCBA0D10
>>>
>>> -static int exynos4_enter_idle(struct cpuidle_device *dev,
>>> - struct cpuidle_driver *drv,
>>> - int index);
>>> static int exynos4_enter_lowpower(struct cpuidle_device *dev,
>>> struct cpuidle_driver *drv,
>>> int index);
>>>
>>> static struct cpuidle_state exynos4_cpuidle_set[] __initdata = {
>>> - [0] = {
>>> - .enter = exynos4_enter_idle,
>>> - .exit_latency = 1,
>>> - .target_residency = 10,
>>> - .flags = CPUIDLE_FLAG_TIME_VALID,
>>> - .name = "C0",
>>> - .desc = "ARM clock gating(WFI)",
>>> - },
>>> + [0] = ARM_CPUIDLE_WFI_STATE,
>>> [1] = {
>>> .enter = exynos4_enter_lowpower,
>>> .exit_latency = 300,
>>> @@ -63,8 +54,9 @@ static struct cpuidle_state exynos4_cpuidle_set[]
>>> __initdata = {
>>> static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
>>>
>>> static struct cpuidle_driver exynos4_idle_driver = {
>>> - .name = "exynos4_idle",
>>> - .owner = THIS_MODULE,
>>> + .name = "exynos4_idle",
>>> + .owner = THIS_MODULE,
>>> + .en_core_tk_irqen = 1,
>>> };
>>>
>>> /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
>>> @@ -103,13 +95,8 @@ static int exynos4_enter_core0_aftr(struct
>>> cpuidle_device *dev,
>>> struct cpuidle_driver *drv,
>>> int index)
>>> {
>>> - struct timeval before, after;
>>> - int idle_time;
>>> unsigned long tmp;
>>>
>>> - local_irq_disable();
>>> - do_gettimeofday(&before);
>>> -
>>> exynos4_set_wakeupmask();
>>>
>>> /* Set value of power down register for aftr mode */
>>> @@ -150,34 +137,6 @@ static int exynos4_enter_core0_aftr(struct
>>> cpuidle_device *dev,
>>> /* Clear wakeup state register */
>>> __raw_writel(0x0, S5P_WAKEUP_STAT);
>>>
>>> - do_gettimeofday(&after);
>>> -
>>> - local_irq_enable();
>>> - idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
>>> - (after.tv_usec - before.tv_usec);
>>> -
>>> - dev->last_residency = idle_time;
>>> - return index;
>>> -}
>>> -
>>> -static int exynos4_enter_idle(struct cpuidle_device *dev,
>>> - struct cpuidle_driver *drv,
>>> - int index)
>>> -{
>>> - struct timeval before, after;
>>> - int idle_time;
>>> -
>>> - local_irq_disable();
>>> - do_gettimeofday(&before);
>>> -
>>> - cpu_do_idle();
>>> -
>>> - do_gettimeofday(&after);
>>> - local_irq_enable();
>>> - idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
>>> - (after.tv_usec - before.tv_usec);
>>> -
>>> - dev->last_residency = idle_time;
>>> return index;
>>> }
>>>
>>> @@ -192,7 +151,7 @@ static int exynos4_enter_lowpower(struct
>>> cpuidle_device *dev,
>>> new_index = drv->safe_state_index;
>>>
>>> if (new_index == 0)
>>> - return exynos4_enter_idle(dev, drv, new_index);
>>> + return arm_cpuidle_simple_enter(dev, drv, new_index);
>>> else
>>> return exynos4_enter_core0_aftr(dev, drv, new_index);
>>> }
>
> Acked-by: Robert Lee
>
>>
>>
>> Acked-by: Daniel Lezcano
>>
>> --
>> Facebook |
>> Twitter |
>>
Re: [PATCH v3 2/6] thermal: Add generic cpufreq cooling implementation
On 9 May 2012 01:46, Andrew Morton wrote:
> On Tue, 8 May 2012 21:48:14 +0530
> Amit Daniel Kachhap wrote:
>
>> This patch adds support for generic cpu thermal cooling low level
>> implementations using frequency scaling up/down based on the registration
>> parameters. Different cpu related cooling devices can be registered by the
>> user and the binding of these cooling devices to the corresponding
>> trip points can be easily done as the registration APIs return the
>> cooling device pointer. The user of these APIs are responsible for
>> passing clipping frequency . The drivers can also register to recieve
>> notification about any cooling action called. Even the driver can effect
>> the cooling action by modifying the default data such as freq_clip_max if
>> needed.
>>
>>
>> ...
>>
>> +struct cpufreq_cooling_device {
>> + int id;
>> + struct thermal_cooling_device *cool_dev;
>> + struct freq_clip_table *tab_ptr;
>> + unsigned int tab_size;
>> + unsigned int cpufreq_state;
>> + const struct cpumask *allowed_cpus;
>> + struct list_head node;
>> +};
>
> It would be nice to document the fields. Especially id, tab_size,
> cpufreq_state and node. For `node' we should describe the locking for
> the list, and describe which list_head anchors this list.
Thanks Andrew for the detailed review. I will add more documentation
and post the next version shortly.
>
>> +static LIST_HEAD(cooling_cpufreq_list);
>> +static DEFINE_MUTEX(cooling_cpufreq_lock);
>> +static DEFINE_IDR(cpufreq_idr);
>> +static DEFINE_PER_CPU(unsigned int, max_policy_freq);
>> +static struct freq_clip_table *notify_table;
>> +static int notify_state;
>> +static BLOCKING_NOTIFIER_HEAD(cputherm_state_notifier_list);
>> +
>> +static int get_idr(struct idr *idr, struct mutex *lock, int *id)
>> +{
>> + int err;
>> +again:
>> + if (unlikely(idr_pre_get(idr, GFP_KERNEL) == 0))
>> + return -ENOMEM;
>> +
>> + if (lock)
>> + mutex_lock(lock);
>
> The test for NULL `lock' is unneeded. In fact the `lock' argument
> could be removed altogether - just use cooling_cpufreq_lock directly.
Agreed
>
>> + err = idr_get_new(idr, NULL, id);
>> + if (lock)
>> + mutex_unlock(lock);
>> + if (unlikely(err == -EAGAIN))
>> + goto again;
>> + else if (unlikely(err))
>> + return err;
>> +
>> + *id = *id & MAX_ID_MASK;
>> + return 0;
>> +}
>> +
>> +static void release_idr(struct idr *idr, struct mutex *lock, int id)
>> +{
>> + if (lock)
>> + mutex_lock(lock);
>
> Ditto.
>
>> + idr_remove(idr, id);
>> + if (lock)
>> + mutex_unlock(lock);
>> +}
>> +
>>
>> ...
>>
>> +
>> +/*Below codes defines functions to be used for cpufreq as cooling device*/
>> +static bool is_cpufreq_valid(int cpu)
>> +{
>> + struct cpufreq_policy policy;
>> + return !cpufreq_get_policy(&policy, cpu) ? true : false;
>
> Can use
Ok
>
> return !cpufreq_get_policy(&policy, cpu);
>
>> +}
>> +
>> +static int cpufreq_apply_cooling(struct cpufreq_cooling_device
>> *cpufreq_device,
>> + unsigned long cooling_state)
>> +{
>> + unsigned int event, cpuid;
>> + struct freq_clip_table *th_table;
>> +
>> + if (cooling_state > cpufreq_device->tab_size)
>> + return -EINVAL;
>> +
>> + cpufreq_device->cpufreq_state = cooling_state;
>> +
>> + /*cpufreq thermal notifier uses this cpufreq device pointer*/
>
> This code looks like it was written by two people.
>
> /* One who does this */
> /*And one who does this*/
>
> The first one was right. Please go through all the comments in all the
> patches and get the layout consistent?
Sure will add more details.
>
>
>> + notify_state = cooling_state;
>> +
>> + if (notify_state > 0) {
>> + th_table = &(cpufreq_device->tab_ptr[cooling_state - 1]);
>> + memcpy(notify_table, th_table, sizeof(struct freq_clip_table));
>> + event = CPUFREQ_COOLING_TYPE;
>> + blocking_notifier_call_chain(&cputherm_state_notifier_list,
>> + event, notify_table);
>> + }
>> +
>> + for_each_cpu(cpuid, cpufreq_device->allowed_cpus) {
>> + if (is_cpufreq_valid(cpuid))
>> + cpufreq_update_policy(cpuid);
>> + }
>> +
>> + notify_state = -1;
>> +
>> + return 0;
>> +}
>> +
>> +static int cpufreq_thermal_notifier(struct notifier_block *nb,
>> + unsigned long event, void *data)
>> +{
>> + struct cpufreq_policy *policy = data;
>> + unsigned long max_freq = 0;
>> +
>> + if ((event != CPUFREQ_ADJUST) || (notify_state == -1))
>
> Please document `notify_state', at its definition site. This reader
> doesn't know what "notify_state == -1" *means*.
>
>> + return 0;
>> +
>> + if (notify_state > 0) {
>> + max_freq = notify_table->freq_clip_max;
>> +
>> +
Re: [PATCH v3 5/6] thermal: exynos: Register the tmu sensor with the kernel thermal layer
On 9 May 2012 01:46, Andrew Morton wrote:
> On Tue, 8 May 2012 21:48:17 +0530
> Amit Daniel Kachhap wrote:
>
>> This code added creates a link between temperature sensors, linux thermal
>> framework and cooling devices for samsung exynos platform. This layer
>> monitors the temperature from the sensor and informs the generic thermal
>> layer to take the necessary cooling action.
>>
>>
>> ...
>>
>> +static void exynos_report_trigger(void)
>> +{
>> + unsigned int i;
>> + char data[2];
>> + char *envp[] = { data, NULL };
>> +
>> + if (!th_zone || !th_zone->therm_dev)
>> + return;
>> +
>> + thermal_zone_device_update(th_zone->therm_dev);
>> +
>> + mutex_lock(&th_zone->therm_dev->lock);
>> + /* Find the level for which trip happened */
>> + for (i = 0; i < th_zone->sensor_conf->trip_data.trip_count; i++) {
>> + if (th_zone->therm_dev->last_temperature <
>> + th_zone->sensor_conf->trip_data.trip_val[i] * 1000)
>> + break;
>> + }
>> +
>> + if (th_zone->mode == THERMAL_DEVICE_ENABLED) {
>> + if (i > 0)
>> + th_zone->therm_dev->polling_delay = ACTIVE_INTERVAL;
>> + else
>> + th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
>> + }
>> +
>> + sprintf(data, "%u", i);
>
> yikes, if `i' exceeds 9, we have a stack scribble. Please review this
> and at least use snprintf(... sizeof(data)) to prevent accidents.
Ok
>
>
>> + kobject_uevent_env(&th_zone->therm_dev->device.kobj, KOBJ_CHANGE,
>> envp);
>> + mutex_unlock(&th_zone->therm_dev->lock);
>> +}
>> +
>>
>> ...
>>
>> +/* Get trip temperature callback functions for thermal zone */
>> +static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int
>> trip,
>> + unsigned long *temp)
>> +{
>> + if (trip < 0 || trip > 2)
>
> I don't know what `trip' does and I don't know the meaning of the
> values 0, 1 and 2. Documentation, please.
Agreed will put their description.
>
>> + return -EINVAL;
>> +
>> + *temp = th_zone->sensor_conf->trip_data.trip_val[trip];
>> + /* convert the temperature into millicelsius */
>> + *temp = *temp * 1000;
>> +
>> + return 0;
>> +}
>> +
>>
>> ...
>>
>> +/* Bind callback functions for thermal zone */
>> +static int exynos_bind(struct thermal_zone_device *thermal,
>> + struct thermal_cooling_device *cdev)
>> +{
>> + int ret = 0;
>> +
>> + /* if the cooling device is the one from exynos4 bind it */
>> + if (cdev != th_zone->cool_dev[0])
>> + return 0;
>> +
>> + if (thermal_zone_bind_cooling_device(thermal, 0, cdev)) {
>> + pr_err("error binding cooling dev inst 0\n");
>> + return -EINVAL;
>> + }
>> + if (thermal_zone_bind_cooling_device(thermal, 1, cdev)) {
>> + pr_err("error binding cooling dev inst 1\n");
>> + ret = -EINVAL;
>> + goto error_bind1;
>> + }
>
> There can never be more than two instances?
As of now it is fixed as we register only 2 zones
>
>> + return ret;
>> +error_bind1:
>> + thermal_zone_unbind_cooling_device(thermal, 0, cdev);
>> + return ret;
>> +}
>> +
>>
>> ...
>>
>> +/* Get temperature callback functions for thermal zone */
>> +static int exynos_get_temp(struct thermal_zone_device *thermal,
>> + unsigned long *temp)
>> +{
>> + void *data;
>> +
>> + if (!th_zone->sensor_conf) {
>> + pr_info("Temperature sensor not initialised\n");
>> + return -EINVAL;
>> + }
>> + data = th_zone->sensor_conf->private_data;
>> + *temp = th_zone->sensor_conf->read_temperature(data);
>> + /* convert the temperature into millicelsius */
>> + *temp = *temp * 1000;
>> + return 0;
>> +}
>> +
>> +/* Operation callback functions for thermal zone */
>> +static struct thermal_zone_device_ops exynos_dev_ops = {
>
> Can it be const? That sometimes saves space, as the table doesn't need
> to be moved into writeable storage at runtime.
Yes it can be made const
>
>> + .bind = exynos_bind,
>> + .unbind = exynos_unbind,
>> + .get_temp = exynos_get_temp,
>> + .get_mode = exynos_get_mode,
>> + .set_mode = exynos_set_mode,
>> + .get_trip_type = exynos_get_trip_type,
>> + .get_trip_temp = exynos_get_trip_temp,
>> + .get_crit_temp = exynos_get_crit_temp,
>> +};
>> +
>> +/* Register with the in-kernel thermal management */
>> +static int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf)
>> +{
>> + int ret, count, tab_size;
>> + struct freq_clip_table *tab_ptr;
>> +
>> + if (!sensor_conf || !sensor_conf->read_temperature) {
>> + pr_err("Temperature sensor not initialised\n");
>> + return -EINVAL;
>> + }
>> +
>> + th_zone = kzalloc(sizeof(struct exynos_thermal_zone), GFP_KERNEL);
>> + if (!th_zone) {
>> +
Re: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 9 May 2012 01:36, Zhang, Rui wrote:
> Hi, Amit,
>
> Sorry for the late response as I'm in a travel recently.
>
> I think the generic cpufreq cooling patches are good.
>
> But about the THERMAL_TRIP_STATE_INSTANCE patch, what I'd like to see is that
> 1. from thermal zone point of view, when the temperature is higher than a
> trip point, either ACTIVE or PASSIVE, what we should do is to set device
> cooling state to cur_state+1, right?
> The only difference is that if we should take passive cooling actions or
> active cooling actions based on the policy.
> So my question would be if it is possible to combine these two kind of trip
> points together. Maybe something like this:
>
> In thermal_zone_device_update(),
>
> ...
> case THERMAL_TRIP_PASSIVE:
> if (passive cooling not allowed)
> continue;
> if (tc1)
> thermal_zone_device_passive();
> else
> thermal_set_cooling_state();
> break;
> case THERMAL_TRIP_ACTIVE:
> if (active cooling not allowed)
> continue;
> thermal_set_cooling_state();
> break;
> ...
>
> and thermal_set_cooling_state() {
> list_for_each_entry(instance, &tz->cooling_devices, node) {
> if (instance->trip != count)
> continue;
>
> cdev = instance->cdev;
>
> if (temp >= trip_temp)
> cdev->ops->set_cur_state(cdev, 1);
> else
> cdev->ops->set_cur_state(cdev, 0);
> }
> }
>
> 2. use only one cooling_device instance for a thermal_zone, and introduce
> cdev->trips which shows the trip points this cooling device is bind to.
> And we may use multiple cooling devices states for one active trip point.
>
> Then, thermal_set_cooling_state() would be look like
>
> list_for_each_entry(instance, &tz->cooling_devices, node) {
> cdev = instance->cdev;
> /* check whether this cooling device is bind to the trip point */
> if (!(cdev->trips & 1< continue;
> cdev->ops->get_max_state(cdev, &max_state);
> cdev->ops->get_cur_state(cdev, &cur_state);
>
> if (temp >= trip_temp) {
> if (cur_state++ <= max_state))
> cdev->ops->set_cur_state(cdev, cur_state);
> } else if ((temp < trip_temp) && (cur_state-- >= 0))
> cdev->ops->set_cur_state(cdev, cur_state);
> }
> }
Hi Rui,
The above implementation also cools instance based cooling devices
like passive trip type. I need some changes on top of your
implementation such as,
thermal_set_cooling_state() {
list_for_each_entry(instance, &tz->cooling_devices,
node) {
cdev = instance->cdev;
if (!cdev->trips & 1ops->get_max_state(cdev, &max_state);
if ((temp >= trip_temp) && (inst_id <= max_state))
cdev->ops->set_cur_state(cdev, inst_id);
else if ((temp < trip_temp) && (--inst_id >= 0))
cdev->ops->set_cur_state(cdev, inst_id);
}
}
I agree with you that the instance based trip types violates the
concept like reading the cur_state and do cur_state++/cur_state--
depending upon threshold increase or decrease because it needs the
state_id/inst_id.
I am actually thinking of dropping this new trip type and use the
existing THERMAL_TRIP_ACTIVE because there is so much logic in
calculating the state_id. The only flip side of using TRIP_ACTIVE is
that I need to create so many cooling devices.
Thanks,
Amit D
>
> With these two things, I think the WARN_ZONE AND MONITOR_ZONE can be
> registered as two PASSIVE trip points in the generic thermal layer, right?
> Actually, this is one thing in my TODO list. And I'd glad to make it high
> priority if this solves the problem you have.
>
> Thanks,
> rui
>
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Amit Daniel Kachhap
> Sent: Tuesday, May 08, 2012 9:18 AM
> To: a...@linux-foundation.org; linux...@lists.linux-foundation.org
> Cc: R, Durgadoss; linux-a...@vger.kernel.org; l...@kernel.org; Zhang, Rui;
> amit.kach...@linaro.org; linaro-dev@lists.linaro.org;
> linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-...@vger.kernel.org; patc...@linaro.org
> Subject: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for
> exynos platform
> Importance: High
>
> Hi Andrew,
>
> This patchset introduces a new generic cooling device based on cpufreq that
> can be used on non-ACPI platforms. As a proof of concept, we have drivers for
> the following platforms using this mechanism now:
>
> * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git
> omap4460_thermal)
> * Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
> * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git
> imx6q_thermal)
>
> These patches have been reviewed by Rui Zhang
> (https://lkml.org/lkml/2012/4/9/448)
> who seems to agree with them in principle, but I haven't had a
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
Hi Rob/Eduardo, As these patches have still not made into mainline. I will rebase the whole set along with your suggestion and send them shortly. Sorry for late reply. Thanks, Amit Daniel On Tue, Jun 26, 2012 at 1:12 PM, Valentin, Eduardo wrote: > Hey Rob and Amit, > > On Tue, Jun 26, 2012 at 6:12 AM, Rob Lee wrote: >> Hey Amit, >> >> I was just re-organizing the imx thermal driver that uses this cpu >> cooling interface and noticed a couple of small issues here. If > > While rewriting the OMAP BG driver on top of this series I noticed > similar issues. Apart from those pointed by Rob, I have another minor > fix. > >> these suggestions are agreed upon and if it's too late for these >> issues be changed with this patchset, I can submit them separately >> unless you'd prefer to. >> >> On Sat, May 12, 2012 at 4:40 AM, Amit Daniel Kachhap >> wrote: >>> This patch adds support for generic cpu thermal cooling low level >>> implementations using frequency scaling up/down based on the registration >>> parameters. Different cpu related cooling devices can be registered by the >>> user and the binding of these cooling devices to the corresponding >>> trip points can be easily done as the registration APIs return the >>> cooling device pointer. The user of these APIs are responsible for >>> passing clipping frequency . The drivers can also register to recieve >>> notification about any cooling action called. >>> >>> Signed-off-by: Amit Daniel Kachhap >>> --- >>> Documentation/thermal/cpu-cooling-api.txt | 60 >>> drivers/thermal/Kconfig | 11 + >>> drivers/thermal/Makefile |3 +- >>> drivers/thermal/cpu_cooling.c | 483 >>> + >>> include/linux/cpu_cooling.h | 99 ++ >>> 5 files changed, 655 insertions(+), 1 deletions(-) >>> create mode 100644 Documentation/thermal/cpu-cooling-api.txt >>> create mode 100644 drivers/thermal/cpu_cooling.c >>> create mode 100644 include/linux/cpu_cooling.h >>> >>> diff --git a/Documentation/thermal/cpu-cooling-api.txt >>> b/Documentation/thermal/cpu-cooling-api.txt >>> new file mode 100644 >>> index 000..557adb8 >>> --- /dev/null >>> +++ b/Documentation/thermal/cpu-cooling-api.txt >>> @@ -0,0 +1,60 @@ >>> +CPU cooling APIs How To >>> +=== >>> + >>> +Written by Amit Daniel Kachhap >>> + >>> +Updated: 12 May 2012 >>> + >>> +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) >>> + >>> +0. Introduction >>> + >>> +The generic cpu cooling(freq clipping, cpuhotplug etc) provides >>> +registration/unregistration APIs to the caller. The binding of the cooling >>> +devices to the trip point is left for the user. The registration APIs >>> returns >>> +the cooling device pointer. >>> + >>> +1. cpu cooling APIs >>> + >>> +1.1 cpufreq registration/unregistration APIs >>> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( >>> + struct freq_clip_table *tab_ptr, unsigned int tab_size) >>> + >>> +This interface function registers the cpufreq cooling device with the >>> name >>> +"thermal-cpufreq-%x". This api can support multiple instances of >>> cpufreq >>> +cooling devices. >>> + >>> +tab_ptr: The table containing the maximum value of frequency to be >>> clipped >>> +for each cooling state. >>> + .freq_clip_max: Value of frequency to be clipped for each allowed >>> +cpus. >>> + .temp_level: Temperature level at which the frequency clamping will >>> + happen. >>> + .mask_val: cpumask of the allowed cpu's >>> +tab_size: the total number of cpufreq cooling states. >>> + >>> +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) >>> + >>> +This interface function unregisters the "thermal-cpufreq-%x" cooling >>> device. >>> + >>> +cdev: Cooling device pointer which has to be unregistered. >>> + >>> + >>> +1.2 CPU cooling action notifier register/unregister interface >>> +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, >>> + unsigned int list) >>> + >>> +This interface registers a driver with cpu cooling layer. The driver >>> will >>> +be notified when any cpu cooling action is called. >>> + >>> +nb: notifier function to register >>> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP >>> + >>> +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, >>> + unsigned int list) >>> + >>> +This interface registers a driver with cpu cooling layer. The driver >>> will >>> +be notified when any cpu cooling action is called. >>> + >>> +nb: notifier function to register >>> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP >>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>> index 514a691..d9c529f 100644 >>> --- a/drivers/thermal/Kconfig >>> +++ b/drivers/thermal/Kconfig >>> @@ -19,6 +19,17 @@ config THERMAL_HWMON >>>depends on HWM
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
On Tue, Jul 10, 2012 at 12:31 PM, Hongbo Zhang wrote: > > > On 12 May 2012 17:40, Amit Daniel Kachhap wrote: >> >> This patch adds support for generic cpu thermal cooling low level >> implementations using frequency scaling up/down based on the registration >> parameters. Different cpu related cooling devices can be registered by the >> user and the binding of these cooling devices to the corresponding >> trip points can be easily done as the registration APIs return the >> cooling device pointer. The user of these APIs are responsible for >> passing clipping frequency . The drivers can also register to recieve >> notification about any cooling action called. >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> Documentation/thermal/cpu-cooling-api.txt | 60 >> drivers/thermal/Kconfig | 11 + >> drivers/thermal/Makefile |3 +- >> drivers/thermal/cpu_cooling.c | 483 >> + >> include/linux/cpu_cooling.h | 99 ++ >> 5 files changed, 655 insertions(+), 1 deletions(-) >> create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> create mode 100644 drivers/thermal/cpu_cooling.c >> create mode 100644 include/linux/cpu_cooling.h >> >> diff --git a/Documentation/thermal/cpu-cooling-api.txt >> b/Documentation/thermal/cpu-cooling-api.txt >> new file mode 100644 >> index 000..557adb8 >> --- /dev/null >> +++ b/Documentation/thermal/cpu-cooling-api.txt >> @@ -0,0 +1,60 @@ >> +CPU cooling APIs How To >> +=== >> + >> +Written by Amit Daniel Kachhap >> + >> +Updated: 12 May 2012 >> + >> +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) >> + >> +0. Introduction >> + >> +The generic cpu cooling(freq clipping, cpuhotplug etc) provides >> +registration/unregistration APIs to the caller. The binding of the >> cooling >> +devices to the trip point is left for the user. The registration APIs >> returns >> +the cooling device pointer. >> + >> +1. cpu cooling APIs >> + >> +1.1 cpufreq registration/unregistration APIs >> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( >> + struct freq_clip_table *tab_ptr, unsigned int tab_size) >> + >> +This interface function registers the cpufreq cooling device with the >> name >> +"thermal-cpufreq-%x". This api can support multiple instances of >> cpufreq >> +cooling devices. >> + >> +tab_ptr: The table containing the maximum value of frequency to be >> clipped >> +for each cooling state. >> + .freq_clip_max: Value of frequency to be clipped for each allowed >> +cpus. >> + .temp_level: Temperature level at which the frequency clamping >> will >> + happen. >> + .mask_val: cpumask of the allowed cpu's >> +tab_size: the total number of cpufreq cooling states. >> + >> +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device >> *cdev) >> + >> +This interface function unregisters the "thermal-cpufreq-%x" cooling >> device. >> + >> +cdev: Cooling device pointer which has to be unregistered. >> + >> + >> +1.2 CPU cooling action notifier register/unregister interface >> +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, >> + unsigned int list) >> + >> +This interface registers a driver with cpu cooling layer. The driver >> will >> +be notified when any cpu cooling action is called. >> + >> +nb: notifier function to register >> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP >> + >> +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, >> + unsigned int list) >> + >> +This interface registers a driver with cpu cooling layer. The driver >> will >> +be notified when any cpu cooling action is called. >> + >> +nb: notifier function to register >> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index 514a691..d9c529f 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -19,6 +19,17 @@ config THERMAL_HWMON >> depends on HWMON=y || HWMON=THERMAL >> default y >> >> +config CPU_THERMAL >> + bool "generic cpu cooling support" >> + depends on THERMAL && CPU_FREQ >> + help >> + This implements the generic cpu cooling mechanism through >> frequency >> + reduction, cpu hotplug and any other ways of reducing >> temperature. An >> + ACPI version of this already >> exists(drivers/acpi/processor_thermal.c). >> + This will be useful for platforms using the generic thermal >> interface >> + and not the ACPI interface. >> + If you want this support, you should say Y or M here. >> + >> config SPEAR_THERMAL >> bool "SPEAr thermal sensor driver" >> depends on THERMAL >> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >> index a9fff0b..30c456c 100644 >> --- a/drivers/ther
Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
On Fri, Jul 13, 2012 at 3:39 PM, Hongbo Zhang wrote: > > > On 12 May 2012 17:40, Amit Daniel Kachhap wrote: >> >> This patch adds support for generic cpu thermal cooling low level >> implementations using frequency scaling up/down based on the registration >> parameters. Different cpu related cooling devices can be registered by the >> user and the binding of these cooling devices to the corresponding >> trip points can be easily done as the registration APIs return the >> cooling device pointer. The user of these APIs are responsible for >> passing clipping frequency . The drivers can also register to recieve >> notification about any cooling action called. >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> Documentation/thermal/cpu-cooling-api.txt | 60 >> drivers/thermal/Kconfig | 11 + >> drivers/thermal/Makefile |3 +- >> drivers/thermal/cpu_cooling.c | 483 >> + >> include/linux/cpu_cooling.h | 99 ++ >> 5 files changed, 655 insertions(+), 1 deletions(-) >> create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> create mode 100644 drivers/thermal/cpu_cooling.c >> create mode 100644 include/linux/cpu_cooling.h >> >> diff --git a/Documentation/thermal/cpu-cooling-api.txt >> b/Documentation/thermal/cpu-cooling-api.txt >> new file mode 100644 >> index 000..557adb8 >> --- /dev/null >> +++ b/Documentation/thermal/cpu-cooling-api.txt >> @@ -0,0 +1,60 @@ >> +CPU cooling APIs How To >> +=== >> + >> +Written by Amit Daniel Kachhap >> + >> +Updated: 12 May 2012 >> + >> +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) >> + >> +0. Introduction >> + >> +The generic cpu cooling(freq clipping, cpuhotplug etc) provides >> +registration/unregistration APIs to the caller. The binding of the >> cooling >> +devices to the trip point is left for the user. The registration APIs >> returns >> +the cooling device pointer. >> + >> +1. cpu cooling APIs >> + >> +1.1 cpufreq registration/unregistration APIs >> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( >> + struct freq_clip_table *tab_ptr, unsigned int tab_size) >> + >> +This interface function registers the cpufreq cooling device with the >> name >> +"thermal-cpufreq-%x". This api can support multiple instances of >> cpufreq >> +cooling devices. >> + >> +tab_ptr: The table containing the maximum value of frequency to be >> clipped >> +for each cooling state. >> + .freq_clip_max: Value of frequency to be clipped for each allowed >> +cpus. >> + .temp_level: Temperature level at which the frequency clamping >> will >> + happen. >> + .mask_val: cpumask of the allowed cpu's >> +tab_size: the total number of cpufreq cooling states. >> + >> +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device >> *cdev) >> + >> +This interface function unregisters the "thermal-cpufreq-%x" cooling >> device. >> + >> +cdev: Cooling device pointer which has to be unregistered. >> + >> + >> +1.2 CPU cooling action notifier register/unregister interface >> +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, >> + unsigned int list) >> + >> +This interface registers a driver with cpu cooling layer. The driver >> will >> +be notified when any cpu cooling action is called. >> + >> +nb: notifier function to register >> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP >> + >> +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, >> + unsigned int list) >> + >> +This interface registers a driver with cpu cooling layer. The driver >> will >> +be notified when any cpu cooling action is called. >> + >> +nb: notifier function to register >> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index 514a691..d9c529f 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -19,6 +19,17 @@ config THERMAL_HWMON >> depends on HWMON=y || HWMON=THERMAL >> default y >> >> +config CPU_THERMAL >> + bool "generic cpu cooling support" >> + depends on THERMAL && CPU_FREQ >> + help >> + This implements the generic cpu cooling mechanism through >> frequency >> + reduction, cpu hotplug and any other ways of reducing >> temperature. An >> + ACPI version of this already >> exists(drivers/acpi/processor_thermal.c). >> + This will be useful for platforms using the generic thermal >> interface >> + and not the ACPI interface. >> + If you want this support, you should say Y or M here. > > No M value for bool item, should be N ? Yes I will include this change. >> >> + >> config SPEAR_THERMAL >> bool "SPEAr thermal sensor driver" >> depends on THERMAL >> diff --git a/drivers/thermal/Makefile b/d
Re: [RFC] Add Arm cpu topology definition
I have some doubts about the bit fields of the MPIDR register.
Comments added below.
On 16 June 2011 14:19, Vincent Guittot wrote:
> The affinity between Arm processors is defined in the MPIDR register.
> We can identify which processors are in the same cluster,
> and which ones have performance interdependency. The cpu topology
> of an Arm platform can be set thanks to this register and this topology
> is then used by sched_mc and sched_smt.
>
> Signed-off-by: Vincent Guittot
> ---
> arch/arm/Kconfig | 26
> arch/arm/include/asm/topology.h | 33 ++
> arch/arm/kernel/Makefile | 1 +
> arch/arm/kernel/smp.c | 6 ++
> arch/arm/kernel/topology.c | 133
> +++
> 5 files changed, 199 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/kernel/topology.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9adc278..bacf9af 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -219,6 +219,24 @@ source "kernel/Kconfig.freezer"
>
> menu "System Type"
>
> +config SCHED_MC
> + bool "Multi-core scheduler support"
> + depends on SMP && ARM_CPU_TOPOLOGY
> + default n
> + help
> + Multi-core scheduler support improves the CPU scheduler's decision
> + making when dealing with multi-core CPU chips at a cost of slightly
> + increased overhead in some places. If unsure say N here.
> +
> +config SCHED_SMT
> + bool "SMT scheduler support"
> + depends on SMP && ARM_CPU_TOPOLOGY
> + default n
> + help
> + Improves the CPU scheduler's decision making when dealing with
> + MultiThreading at a cost of slightly increased overhead in some
> + places. If unsure say N here.
> +
> config MMU
> bool "MMU-based Paged Memory Management Support"
> default y
> @@ -1062,6 +1080,14 @@ if !MMU
> source "arch/arm/Kconfig-nommu"
> endif
>
> +config ARM_CPU_TOPOLOGY
> + bool "Support cpu topology definition"
> + depends on SMP && CPU_V7
> + help
> + Support Arm cpu topology definition. The MPIDR register defines
> + affinity between processors which is used to set the cpu
> + topology of an Arm System.
> +
> config ARM_ERRATA_411920
> bool "ARM errata: Invalidation of the Instruction Cache operation can
> fail"
> depends on CPU_V6 || CPU_V6K
> diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
> index accbd7c..cb90d0a 100644
> --- a/arch/arm/include/asm/topology.h
> +++ b/arch/arm/include/asm/topology.h
> @@ -1,6 +1,39 @@
> #ifndef _ASM_ARM_TOPOLOGY_H
> #define _ASM_ARM_TOPOLOGY_H
>
> +#ifdef CONFIG_ARM_CPU_TOPOLOGY
> +
> +#include
> +
> +struct cputopo_arm {
> + int thread_id;
> + int core_id;
> + int socket_id;
> + cpumask_t thread_sibling;
> + cpumask_t core_sibling;
> +};
> +
> +extern struct cputopo_arm cpu_topology[NR_CPUS];
> +
> +#define topology_physical_package_id(cpu) (cpu_topology[cpu].socket_id)
> +#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
> +#define topology_core_cpumask(cpu) (&(cpu_topology[cpu].core_sibling))
> +#define topology_thread_cpumask(cpu) (&(cpu_topology[cpu].thread_sibling))
> +
> +#define mc_capable() (cpu_topology[0].socket_id != -1)
> +#define smt_capable() (cpu_topology[0].thread_id != -1)
> +
> +void init_cpu_topology(void);
> +void store_cpu_topology(unsigned int cpuid);
> +const struct cpumask *cpu_coregroup_mask(unsigned int cpu);
> +
> +#else
> +
> +#define init_cpu_topology() {};
> +#define store_cpu_topology(cpuid) {};
> +
> +#endif
> +
> #include
>
> #endif /* _ASM_ARM_TOPOLOGY_H */
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index a5b31af..816a481 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_IWMMXT) += iwmmxt.o
> obj-$(CONFIG_CPU_HAS_PMU) += pmu.o
> obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
> AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
> +obj-$(CONFIG_ARM_CPU_TOPOLOGY) += topology.o
>
> ifneq ($(CONFIG_ARCH_EBSA110),y)
> obj-y += io.o
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 344e52b..3e8dc3b 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -268,6 +269,9 @@ static void __cpuinit smp_store_cpu_info(unsigned int
> cpuid)
> struct cpuinfo_arm *cpu_info = &per_cpu(cpu_data, cpuid);
>
> cpu_info->loops_per_jiffy = loops_per_jiffy;
> +
> + store_cpu_topology(cpuid);
> +
> }
>
> /*
> @@ -354,6 +358,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> {
> unsigned int ncores = num_possible_cpus();
>
> + init_cpu_topology();
> +
> smp_store_cpu_info(smp_processor_id());
>
>
Re: [PATCH powertop2.0] Modification to fix the removal of lock_depth field
On 23 June 2011 10:41, Arjan van de Ven wrote: > On 6/22/2011 10:12 PM, Amit Daniel Kachhap wrote: >> >> lock_depth field is removed from the power frequency events in the >> new linux kernel(2.6.38 onwards). So this creates issue to retrieve >> the lower members of the trace data. To fix this problem 2 separate >> structures are created and their use depends upon the format of the >> power_frequency events. These changes have been tested to work fine >> with both old and new kernels as well as on x86 and ARM platform. >> > > > eh no > > while it was temporarily removed in an -rc, it was added back (as padding) > after it was > found to break powertop (and abi). > > or am I missing something??? > > Ohh the padding field fixes this issue. Then this patch may not be needed. Thanks Arjan for quick review. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] powertop: Disable pci bus measurement for arm platforms
On 15 July 2011 22:56, Kok, Auke-jan H wrote: > On Thu, Jul 14, 2011 at 11:35 PM, Amit Daniel Kachhap > wrote: >> This patch disables pci related measurement which is not needed >> for ARM platforms and also library libpci is not needed. >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> Android.mk | 7 ++- >> devices/runtime_pm.cpp | 3 ++- >> lib.cpp | 7 --- >> main.cpp | 6 ++ >> tuning/runtime.cpp | 2 ++ >> 5 files changed, 20 insertions(+), 5 deletions(-) >> >> diff --git a/Android.mk b/Android.mk >> index 146f57a..6948011 100644 >> --- a/Android.mk >> +++ b/Android.mk >> @@ -4,7 +4,6 @@ include $(CLEAR_VARS) >> LOCAL_MODULE_TAGS := debug >> LOCAL_SHARED_LIBRARIES := libstlport \ >> libnl \ >> - libpci \ >> >> LOCAL_MODULE := powertop >> >> @@ -14,6 +13,12 @@ LOCAL_CPPFLAGS += -DDISABLE_NCURSES -DDISABLE_I18N >> -DDISABLE_TRYCATCH >> >> LOCAL_C_INCLUDES += external/stlport/stlport/ external/stlport/stlport/stl >> external/stlport/stlport/using/h/ bionic external/libnl/include/ >> >> +ifneq ($(TARGET_ARCH),arm) >> +LOCAL_SHARED_LIBRARIES += libpci >> +else #TARGET_ARCH != arm >> +LOCAL_CPPFLAGS += -DDISABLE_PCI >> +endif #TARGET_ARCH == arm > > should probably not use #ifdef ARM but something like #ifdef > HAVE_LIBPCI instead.. there will be other architectures that don't > have libpci as well. > Thanks for your comments. i will use this macro in the next patches. >> LOCAL_SRC_FILES += \ >> parameters/parameters.cpp \ >> parameters/persistent.cpp \ >> diff --git a/devices/runtime_pm.cpp b/devices/runtime_pm.cpp >> index 368d995..5a55426 100644 >> --- a/devices/runtime_pm.cpp >> +++ b/devices/runtime_pm.cpp >> @@ -200,7 +200,7 @@ static void do_bus(const char *bus) >> continue; >> >> dev = new class runtime_pmdevice(entry->d_name, filename); >> - >> +#ifndef DISABLE_PCI > > I'd prefer a nice HAVE_LIBPCI here instead as well for the rest of these... > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 3/3] powertop: ncurses: Enable ncurses for android and miscellaneous changes
On 15 July 2011 23:05, Kok, Auke-jan H wrote:
> On Thu, Jul 14, 2011 at 11:35 PM, Amit Daniel Kachhap
> wrote:
>> This patch enables ncurses for android. NCURSES_NOMACRO flag is enabled
>> as there is some conflict with stl libraries.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> Android.mk | 23 +++
>> display.cpp | 5 -
>> display.h | 3 ++-
>> lib.cpp | 6 --
>> main.cpp | 5 +
>> process/do_process.cpp | 4
>> 6 files changed, 38 insertions(+), 8 deletions(-)
>>
>> diff --git a/Android.mk b/Android.mk
>> index 6948011..e6e73b1 100644
>> --- a/Android.mk
>> +++ b/Android.mk
>> @@ -1,17 +1,32 @@
>> LOCAL_PATH := $(call my-dir)
>> include $(CLEAR_VARS)
>>
>> -LOCAL_MODULE_TAGS := debug
>> +LOCAL_MODULE_TAGS := optional
>> LOCAL_SHARED_LIBRARIES := libstlport \
>> - libnl \
>> + libnl
>> +
>> +LOCAL_STATIC_LIBRARIES := libncurses
>>
>> LOCAL_MODULE := powertop
>>
>> #LOCAL_CFLAGS += -Wall -O2 -g -fno-omit-frame-pointer -fstack-protector
>> -Wshadow -Wformat -D_FORTIFY_SOURCE=2
>> #LOCAL_CPPFLAGS += -Wall -O2 -g -fno-omit-frame-pointer
>> -LOCAL_CPPFLAGS += -DDISABLE_NCURSES -DDISABLE_I18N -DDISABLE_TRYCATCH
>> +LOCAL_CPPFLAGS += \
>> + -DDISABLE_I18N \
>> + -DDISABLE_TRYCATCH \
>> + -DNCURSES_NOMACROS \
>> + -DDISABLE_WSTRING \
>> + -DDEFAULT_TERM=\"xterm\" \
>>
>> -LOCAL_C_INCLUDES += external/stlport/stlport/ external/stlport/stlport/stl
>> external/stlport/stlport/using/h/ bionic external/libnl/include/
>> +LOCAL_C_INCLUDES += external/stlport/stlport/ \
>> + external/stlport/stlport/stl \
>> + external/stlport/stlport/using/h/ \
>> + bionic \
>> + external/libnl/include/ \
>> + external/ncurses \
>> + external/ncurses/lib \
>> + external/ncurses/include \
>> + external/ncurses/include/ncurses
>>
>> ifneq ($(TARGET_ARCH),arm)
>> LOCAL_SHARED_LIBRARIES += libpci
>> diff --git a/display.cpp b/display.cpp
>> index f486050..283743c 100644
>> --- a/display.cpp
>> +++ b/display.cpp
>> @@ -84,8 +84,11 @@ void reset_display(void)
>> keypad(stdscr, FALSE);
>> echo();
>> nocbreak();
>> -
>> +#ifndef NCURSES_NOMACROS
>> resetterm();
>> +#else
>> + reset_shell_mode();
>> +#endif
>> }
>>
>>
>> diff --git a/display.h b/display.h
>> index 3b24914..023f68d 100644
>> --- a/display.h
>> +++ b/display.h
>> @@ -49,7 +49,8 @@ public:
>> int cursor_pos;
>> int cursor_max;
>> WINDOW *win;
>> -
>> +
>> + virtual ~tab_window() {};
>> virtual void cursor_down(void) { if (cursor_pos < cursor_max )
>> cursor_pos++; repaint(); } ;
>> virtual void cursor_up(void) { if (cursor_pos > 0) cursor_pos--;
>> repaint(); };
>>
>> diff --git a/lib.cpp b/lib.cpp
>> index d058e4f..86fcf96 100644
>> --- a/lib.cpp
>> +++ b/lib.cpp
>> @@ -238,10 +238,12 @@ void format_watts(double W, char *buffer, unsigned int
>> len)
>> if (W < 0.0001)
>> sprintf(buffer, _(" 0 mW"));
>>
>> -#ifndef DISABLE_NCURSES
>> +#ifndef DISABLE_NCURSES
>> +#ifndef DISABLE_WSTRING
>> while (mbstowcs(NULL,buffer,0) < len)
>> strcat(buffer, " ");
>> -#endif
>> +#endif //DISABLE_WSTRING
>> +#endif //DISABLE_NCURSES
>> }
>>
>> #ifndef DISABLE_PCI
>> diff --git a/main.cpp b/main.cpp
>> index 3ee0a7e..fc4b0cf 100644
>> --- a/main.cpp
>> +++ b/main.cpp
>> @@ -280,6 +280,11 @@ int main(int argc, char **argv)
>> bindtextdomain ("powertop", "/usr/share/locale");
>> textdomain ("powertop");
>> #endif
>> +
>> +#ifdef DEFAULT_TERM
>> + if (!getenv("TERM"))
>> + setenv("TERM", DEFAULT_TERM, 1);
>> +#endif
>> uid = getuid();
>>
>> if (uid != 0) {
>> diff --git a/process/do_process.cpp b/process/do_process.cpp
>> index 5c382f1..7e39321 100644
>> --- a/process/do_process.cpp
>> +++ b/process/do_process.cpp
>> @@ -720,7 +720,9 @@ void process_update_display(void)
>> if (!show_power)
>> strcpy(power, " ");
>> sprintf(name, "%s", all_power[i]->type());
>> +#ifndef DISABLE_WSTRING
>> while (mbstowcs(NULL,name,0) < 14) strcat(name, " ");
>> +#endif
>>
>>
>> if (all_power[i]->events() == 0 && all_power[i]->usage() == 0
>> && all_power[i]->Witts() == 0)
>> @@ -733,7 +735,9 @@ void process_update_display(void)
>> else
>> sprintf(usage, "%5i%s",
>> (int)all_power[i]->usage(), all_power[i]->usage_units());
>> }
>> +#ifndef
Re: [RFC PATCH 17/17] ARM: kernel: save/restore build infrastructure
On 7 July 2011 21:20, Lorenzo Pieralisi wrote: > This patch adds the required Kconfig and Makefile entries to > enable and compile common idle code for ARM kernel. > > Common idle code depends on CPU_PM platform notifiers to trigger > save/restore of kernel subsystems like PMU, VFP, GIC. > > Signed-off-by: Lorenzo Pieralisi > --- > arch/arm/Kconfig | 11 +++ > arch/arm/kernel/Makefile | 4 > 2 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 356f266..5b670bd 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1992,6 +1992,17 @@ config VFP > > Say N if your target does not have VFP hardware. > > +config CONTEXT_SR > + bool "Save/Restore code support for CPU/Cluster Power Management" > + depends on CPU_V7 && CPU_PM > + help > + Say Y to include Save/Restore code in the kernel. This provides > + generic infrastructure to put the code in dormant/shutdown mode > + and save/restore the required system state inclusive of L2 cache > + logic. > + > + Say N if your target does not have Power Management hardware. > + Currently this is placed inside the "Floating point emulation" menu. "cpu power management" menu may be a better option. Also I did not find where configs CPU_PM, ARCH_USES_CPU_PM are enabled. > config VFPv3 > bool > depends on VFP > diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile > index 8b42d58..ac931f1 100644 > --- a/arch/arm/kernel/Makefile > +++ b/arch/arm/kernel/Makefile > @@ -49,6 +49,10 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > obj-$(CONFIG_SWP_EMULATE) += swp_emulate.o > CFLAGS_swp_emulate.o := -Wa,-march=armv7-a > obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o > +obj-$(CONFIG_CONTEXT_SR) += lb_lock.o sr_api.o sr_mapping.o \ > + sr_entry.o sr_arch.o sr_context.o \ > + sr_platform.o sr_power.o reset_v7.o \ > + sr_v7_helpers.o > > obj-$(CONFIG_CRUNCH) += crunch.o crunch-bits.o > AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312 > -- > 1.7.4.4 > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 06/17] ARM: kernel: save/restore generic infrastructure
On 7 July 2011 21:20, Lorenzo Pieralisi wrote:
>
> This patch provides the code infrastructure needed to maintain
> a generic per-cpu architecture implementation of idle code.
>
> sr_platform.c :
> - code manages patchset initialization and memory management
>
> sr_context.c:
> - code initializes run-time context save/restore generic
> support
>
> sr_power.c:
> - provides the generic infrastructure to enter exit low
> power modes and communicate with Power Control Unit (PCU)
>
> v7 support hinges on the basic infrastructure to provide per-cpu
> arch implementation basically through standard function pointers
> signatures.
>
> Preprocessor defines include size of data needed to save/restore
> L2 state. This define value should be moved to the respective
> subsystem (PL310) once the patchset IF to that subsystem is settled.
>
> Signed-off-by: Lorenzo Pieralisi
> ---
> arch/arm/kernel/sr.h | 162
> +
> arch/arm/kernel/sr_context.c | 23 ++
> arch/arm/kernel/sr_helpers.h | 56 ++
> arch/arm/kernel/sr_platform.c | 48
> arch/arm/kernel/sr_power.c | 26 +++
> 5 files changed, 315 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/kernel/sr.h
> create mode 100644 arch/arm/kernel/sr_context.c
> create mode 100644 arch/arm/kernel/sr_helpers.h
> create mode 100644 arch/arm/kernel/sr_platform.c
> create mode 100644 arch/arm/kernel/sr_power.c
>
> diff --git a/arch/arm/kernel/sr.h b/arch/arm/kernel/sr.h
> new file mode 100644
> index 000..6b24e53
> --- /dev/null
> +++ b/arch/arm/kernel/sr.h
> @@ -0,0 +1,162 @@
> +#define SR_NR_CLUSTERS 1
> +
> +#define STACK_SIZE 512
> +
> +#define CPU_A5 0x4100c050
> +#define CPU_A8 0x4100c080
> +#define CPU_A9 0x410fc090
> +#define L2_DATA_SIZE 16
> +#define CONTEXT_SPACE_UNCACHED (2 * PAGE_SIZE)
> +#define PA(f) ((typeof(f) *)virt_to_phys((void *)f))
> +
> +#ifndef __ASSEMBLY__
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * Structures we hide from the OS API
> + */
> +
> +struct sr_cpu_context {
> + u32 flags;
> + u32 saved_items;
> + u32 *mmu_data;
> +};
> +
> +struct sr_cluster_context {
> + u32 saved_items;
> + u32 *l2_data;
> +};
> +
> +struct sr_main_table {
> + pgd_t *os_mmu_context[SR_NR_CLUSTERS][CONFIG_NR_CPUS];
> + cpumask_t cpu_idle_mask[SR_NR_CLUSTERS];
> + pgd_t *fw_mmu_context;
> + u32 num_clusters;
> + struct sr_cluster *cluster_table;
> +};
> +
> +
> +/*
> + * A cluster is a container for CPUs, typically either a single CPU or a
> + * coherent cluster.
> + * We assume the CPUs in the cluster can be switched off independently.
> + */
> +struct sr_cluster {
> + u32 cpu_type; /* A9mpcore, A5mpcore, etc */
> + u32 num_cpus;
> + struct sr_cluster_context *context;
> + struct sr_cpu *cpu_table;
> + u32 power_state;
> + u32 cluster_down;
> + void __iomem *scu_address;
> + void *lock;
> +};
> +
> +struct sr_cpu {
> + struct sr_cpu_context *context;
> + u32 power_state;
> +};
> +
> +/*
> + * arch infrastructure
> + */
> +struct sr_arch {
> + unsigned int cpu_val;
> + unsigned int cpu_mask;
> +
> + int (*init)(void);
> +
> + int (*save_context)(struct sr_cluster *, struct sr_cpu *,
> + unsigned);
> + int (*restore_context)(struct sr_cluster *, struct sr_cpu *);
> + int (*enter_cstate)(unsigned cpu_index,
> + struct sr_cpu *cpu,
> + struct sr_cluster *cluster);
> + int (*leave_cstate)(unsigned, struct sr_cpu *,
> + struct sr_cluster *);
> + void (*reset)(void);
> +
> +};
> +
> +extern struct sr_arch *arch;
> +extern int lookup_arch(void);
> +
> +/*
> + * Global variables
> + */
> +extern struct sr_main_table main_table;
> +extern unsigned long idle_save_context;
> +extern unsigned long idle_restore_context;
> +extern unsigned long idle_mt;
> +extern void *context_memory_uncached;
> +
> +/*
> + * Context save/restore
> + */
> +typedef u32 (sr_save_context_t)
> + (struct sr_cluster *,
> + struct sr_cpu*, u32);
> +typedef u32 (sr_restore_context_t)
> + (struct sr_cluster *,
> + struct sr_cpu*);
> +
> +extern sr_save_context_t sr_save_context;
> +extern sr_restore_context_t sr_restore_context;
> +
> +
> +extern struct sr_arch *get_arch(void);
> +
> +
> +/*
> + * 1:1 mappings
> + */
> +
> +extern int linux_sr_setup_translation_tables(void);
> +
> +/*
> + * dumb memory allocator
> + */
> +
> +extern void *get_memory(unsigned int size);
> +
> +/*
> + * Entering/Leaving C-states function entries
> + */
> +
> +extern int sr_platform_enter_cstate(unsigned cp
Re: [RFC PATCH 3/4] ARM: EXYNOS4: Add support AFTR mode cpuidle state on EXYNOS4210
On 21 August 2011 22:48, Russell King - ARM Linux
wrote:
> On Fri, Aug 19, 2011 at 06:39:59PM +0530, Amit Daniel Kachhap wrote:
>> +ENTRY(exynos4_enter_lp)
>> + stmfd sp!, { r3 - r12, lr }
>> +
>> + adr r0, sleep_save_misc
>> +
>> + mrc p15, 0, r2, c15, c0, 0 @ read power control register
>> + str r2, [r0], #4
>> +
>> + mrc p15, 0, r2, c15, c0, 1 @ read diagnostic register
>> + str r2, [r0], #4
>> +
>> + ldr r3, =resume_with_mmu
>> + bl cpu_suspend
>> +
>> + mov r0, sp
>> + bl exynos4_cpu_lp
>> +
>> + /* Restore original sp */
>> + mov r0, sp
>> + add r0, r0, #4
>> + ldr sp, [r0]
>> +
>> + mov r0, #0
>> + b early_wakeup
>
> This is based upon old kernel code. Clearly hasn't been tested with
> anything later than 3.0.
>
You are right. I will rebase it to the latest tree in the next
version. The main intention of the patch series (mostly patch 4) is to
collect information or issues on samsung platform with the new common
cpuidle framework.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 2/4] ARM: EXYNOS4: Fix to work with origen boards.
On 19 August 2011 19:29, Kyungmin Park wrote:
> On Fri, Aug 19, 2011 at 10:09 PM, Amit Daniel Kachhap
> wrote:
>> This adds a function to get the revision id.
>>
>> Signed-off-by: Jaecheol Lee
>> Signed-off-by: Changhwan Youn
>> ---
>> arch/arm/mach-exynos4/cpu.c | 10 ++
>> arch/arm/plat-s5p/include/plat/exynos4.h | 1 +
>> 2 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
>> index 2d8a40c..8b106b8 100644
>> --- a/arch/arm/mach-exynos4/cpu.c
>> +++ b/arch/arm/mach-exynos4/cpu.c
>> @@ -234,6 +234,16 @@ static int __init exynos4_l2x0_cache_init(void)
>> early_initcall(exynos4_l2x0_cache_init);
>> #endif
>>
>> +int exynos4_subrev(void)
>> +{
>> + static int subrev = -1;
>> +
>> + if (unlikely(subrev < 0))
>> + subrev = readl(S5P_VA_CHIPID) & 0xf;
> How about to add the clock control here?
> 1. Register chipid clk
> 2. Get the chipid clk
> 3. Read CHPIID,
> 4. Put tht chipid clk.
Nice suggestion. Will do it in the next patch version. Actually the
main focus of this
patch series was to have a proof of concept of the new cpuidle common code.
Thanks,
Amit Daniel
>
> Then you can save some power.
>
> Thank you,
> Kyungmin Park
>> +
>> + return subrev;
>> +}
>> +
>> int __init exynos4_init(void)
>> {
>> printk(KERN_INFO "EXYNOS4: Initializing architecture\n");
>> diff --git a/arch/arm/plat-s5p/include/plat/exynos4.h
>> b/arch/arm/plat-s5p/include/plat/exynos4.h
>> index 907caab..d62f7f7 100644
>> --- a/arch/arm/plat-s5p/include/plat/exynos4.h
>> +++ b/arch/arm/plat-s5p/include/plat/exynos4.h
>> @@ -15,6 +15,7 @@
>> extern void exynos4_common_init_uarts(struct s3c2410_uartcfg *cfg, int no);
>> extern void exynos4_register_clocks(void);
>> extern void exynos4_setup_clocks(void);
>> +extern int exynos4_subrev(void);
>>
>> #ifdef CONFIG_CPU_EXYNOS4210
>>
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
samsung cpuidle pull request.
Hi Nicolas, This is a request to pull L2 retention cpuidle implementation from git://git.linaro.org/people/amitdanielk/linux.git (branch- samsung_cpuidle_l2_retention) The top 5 patches on this refers to the work and this is heavily based on Russell's rmk-next tree. So if it is possible to take this patches for this month linaro release then please pull them. All these patches with minor modifications will be upstreamed to mainline once Russell tree is in sync with Samsung's maintainers tree. Thanks, Amit Daniel Linaro PMWG member ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: samsung cpuidle pull request.
Adding the SHAID for the commits. 1)c3d9c1725dfdb595d6054a123222faff81b2d06b 2)1126792e47c4282fa9d9e491c18e7f6b933ca642 3)ece51a25086cfabd291b9122552dcefb70145620 4)d162be5c4a29161d727bb71bfcb27f1fdc1a3b0e 5)2ddd7157a90d8c0ad05cdb7a60fdfb7101eaebc2 Thanks, Amit Daniel Linaro PMWG member On 20 October 2011 14:33, Amit Kachhap wrote: > Hi Nicolas, > > This is a request to pull L2 retention cpuidle implementation from > git://git.linaro.org/people/amitdanielk/linux.git (branch- > samsung_cpuidle_l2_retention) > > The top 5 patches on this refers to the work and this is heavily based > on Russell's rmk-next tree. So if it is possible to take this patches > for this month linaro release then please pull them. > > All these patches with minor modifications will be upstreamed to > mainline once Russell tree is in sync with Samsung's maintainers tree. > > Thanks, > Amit Daniel > Linaro PMWG member > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: samsung cpuidle pull request.
Hi Nicolas, As suggested by you, I have cherry picked the necessary patches from rmk-next tree and applied it on top of latest linaro tree. Please pull them for next linaro release. The pull path is, git://git.linaro.org/people/amitdanielk/linux.git samsung_cpuidle_l2_retention. All the patches are tested and there details are, Amit Daniel Kachhap (3): ARM: EXYNOS4: Add support AFTR mode on EXYNOS4210 ARM: EXYNOS4: Added function to read chip id ARM: exynos4: add L2 early resume code Barry Song (3): ARM: 7089/1: L2X0: add explicit cpu_relax() for busy wait loop ARM: 7090/1: CACHE-L2X0: filter start address can be 0 and is often 0 ARM: 7114/1: cache-l2x0: add resume entry for l2 in secure mode Lorenzo Pieralisi (2): ARM: exynos4: remove useless churn in sleep.S ARM: exynos4: remove useless code to save/restore L2 and GIC state Rob Herring (1): ARM: 7009/1: l2x0: Add OF based initialization Shawn Guo (1): ARM: 7100/1: smp_scu: remove __init annotation from scu_enable() Documentation/devicetree/bindings/arm/l2cc.txt | 42 + arch/arm/include/asm/hardware/cache-l2x0.h | 42 + arch/arm/include/asm/outercache.h |7 + arch/arm/kernel/asm-offsets.c | 12 ++ arch/arm/kernel/smp_scu.c |2 +- arch/arm/mach-exynos4/cpu.c| 47 +- arch/arm/mach-exynos4/cpuidle.c| 151 - arch/arm/mach-exynos4/include/mach/pmu.h |2 + arch/arm/mach-exynos4/platsmp.c|7 +- arch/arm/mach-exynos4/pm.c | 87 -- arch/arm/mach-exynos4/sleep.S | 29 +++- arch/arm/mm/cache-l2x0.c | 216 +++- arch/arm/plat-s5p/include/plat/exynos4.h |1 + Thanks, Amit Daniel On 21 October 2011 02:19, Nicolas Pitre wrote: > On Thu, 20 Oct 2011, Amit Kachhap wrote: > >> Hi Nicolas, >> >> This is a request to pull L2 retention cpuidle implementation from >> git://git.linaro.org/people/amitdanielk/linux.git (branch- >> samsung_cpuidle_l2_retention) >> >> The top 5 patches on this refers to the work and this is heavily based >> on Russell's rmk-next tree. So if it is possible to take this patches >> for this month linaro release then please pull them. > > The Linaro kernel for this month was frozen today already. > > Still, I was ready to pull those patches if they were trivial. But they > are based on RMK's for-next branch which is _not_ a stable branch, > therefore I'm for sure not willing to pull all his for-next branch into > the linaro repository, and even less so on the Linaro kernel freeze > deadline. > > If you want those patches available in the Linaro kernel (maybe for next > month's release) I'd ask you to cherry-pick the required patches and > apply them to a branch which is based on the current state of the > linux-linaro-3.1 repository, and please test the resulting branch. > > > Nicolas > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 1/4] ARM: Exynos4: Add thermal sensor driver for samsung exynos4 platform.
On 27 October 2011 04:08, Kyungmin Park wrote:
> Hi,
>
> exynos4 tmu is already merged 3.2-rc
> you can find it at below message and latest git kernel
> http://www.spinics.net/lists/lm-sensors/msg33872.html
>
> Thank you,
> Kyungmin Park
ok I will rebase my work on top of sensor
Thanks for pointing this out.
>
> On Wed, Oct 26, 2011 at 8:36 PM, Amit Daniel Kachhap
> wrote:
>> This patch adds support for thermal sensor driver. It supports 3 trigger
>> level. The first 2 level are warn and monitor temperature level. The
>> third critical trigger level resets the system. The threshold
>> change information is sent to the thermal interface layer.
>>
>> Signed-off-by: SangWook Ju
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> arch/arm/mach-exynos4/include/mach/exynos4-tmu.h | 75
>> drivers/staging/Kconfig | 2 +
>> drivers/staging/Makefile | 1 +
>> drivers/staging/thermal_exynos4/sensor/Kconfig | 14 +
>> drivers/staging/thermal_exynos4/sensor/Makefile | 4 +
>> .../thermal_exynos4/sensor/exynos4210_tmu.c | 465
>>
>> 6 files changed, 561 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
>> create mode 100644 drivers/staging/thermal_exynos4/sensor/Kconfig
>> create mode 100644 drivers/staging/thermal_exynos4/sensor/Makefile
>> create mode 100644 drivers/staging/thermal_exynos4/sensor/exynos4210_tmu.c
>>
>> diff --git a/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
>> b/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
>> new file mode 100644
>> index 000..dc7bf37
>> --- /dev/null
>> +++ b/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
>> @@ -0,0 +1,75 @@
>> +/**
>> + * exynos4-tmu.h - definitions of exynos4 specific thermal interface
>> + *
>> + * Copyright (C) 2011 Samsung Electronics Co. ltd.
>> +
>> + * 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; either version 2 of the License, or
>> + * (at your option) any later version.
>> +
>> + * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
>> + */
>> +
>> +#ifndef _EXYNOS4_TMU_H
>> +#define _EXYNOS4_TMU_H
>> +
>> +/**
>> + * tmu_data - tmu driver private structure
>> + * @t1: colling stop temperature.
>> + * @dc_temp: Temperature base.
>> + * @init_threshold: Initial threshold temperature.
>> + * @mode: Compensation mode.
>> + * @comp_threshold: compensated threshold temperature.
>> + *
>> + */
>> +struct tmu_data {
>> + char te1;
>> + char te2;
>> + unsigned int init_threshold;
>> + int mode;
>> + int cooling;
>> + unsigned int comp_threshold;
>> + int tmu_flag;
>> +};
>> +
>> +/**
>> + * tmu_platform_device - tmu platform specific structure
>> + * @id: Device id.
>> + * @tmu_base: Memory register base.
>> + * @dev: TMU device.
>> + * @data: TMU driver private data structure.
>> + *
>> + */
>> +struct tmu_platform_device {
>> + int id;
>> + struct platform_device *pdev;
>> + void __iomem *tmu_base;
>> + struct device *dev;
>> + struct tmu_data data;
>> + struct thermal_dev *therm_fw;
>> +};
>> +
>> +#ifdef CONFIG_PM
>> +struct exynos4_tmu_register {
>> + unsigned int regval_thresh_temp;
>> + unsigned int regval_trig_lev0;
>> + unsigned int regval_trig_lev1;
>> + unsigned int regval_trig_lev2;
>> + unsigned int regval_trig_lev3;
>> + unsigned int regval_tmu_con0;
>> + unsigned int regval_int_en;
>> +};
>> +#endif
>> +
>> +extern void exynos4_tmu_set_platdata(struct tmu_data *pd);
>> +extern struct tmu_platform_device *exynos4_tmu_get_platdata(void);
>> +extern int exynos4_tmu_get_irqno(int num);
>> +#endif /* _EXYNOS4_TMU_H */
>> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
>> index 2582e18..4376fed 100644
>> --- a/drivers/staging/Kconfig
>> +++ b/drivers/staging/Kconfig
>> @@ -148,4 +148,6 @@ source "drivers/staging/mei/Kconfig"
>>
>> source "drivers/staging/nvec/Kconfig"
>>
>> +source "drivers/staging/thermal_exynos4/Kconfig"
>> +
>> endif # STAGING
>> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
>> index 50d112f..24a2943 100644
>> --- a/drivers/staging/Makefile
>> +++ b/drivers/staging/Makefile
>> @@ -65,3 +65,4 @@ obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4) += ste_rmi4/
>> o
[PATCH 2/4] ARM: exynos4: remove useless churn in sleep.S
From: Lorenzo Pieralisi This patch cleans up sleep code in preparation for L2 resume code and hotplug functions Signed-off-by: Lorenzo Pieralisi --- arch/arm/mach-exynos4/sleep.S |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos4/sleep.S b/arch/arm/mach-exynos4/sleep.S index 0984078..c19527b 100644 --- a/arch/arm/mach-exynos4/sleep.S +++ b/arch/arm/mach-exynos4/sleep.S @@ -27,8 +27,6 @@ */ #include -#include -#include .text @@ -52,3 +50,4 @@ ENTRY(s3c_cpu_resume) b cpu_resume +ENDPROC(s3c_cpu_resume) -- 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 3/4] ARM: exynos4: add L2 early resume code
From: Amit Daniel Kachhap
This patch adds code to save L2 register configuration at boot, and to
resume L2 before MMU is enabled in suspend and cpuidle resume paths.
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Amit Daniel Kachhap
---
arch/arm/mach-exynos4/cpu.c | 43 ++--
arch/arm/mach-exynos4/sleep.S | 26
2 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index a348434..53c6cd3 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
@@ -31,6 +32,7 @@
#include
#include
+#include
unsigned int gic_bank_offset __read_mostly;
@@ -254,20 +256,39 @@ core_initcall(exynos4_core_init);
#ifdef CONFIG_CACHE_L2X0
static int __init exynos4_l2x0_cache_init(void)
{
- /* TAG, Data Latency Control: 2cycle */
- __raw_writel(0x110, S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL);
+ if (!(__raw_readl(S5P_VA_L2CC + L2X0_CTRL) & 0x1)) {
- if (soc_is_exynos4210())
- __raw_writel(0x110, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
- else if (soc_is_exynos4212() || soc_is_exynos4412())
- __raw_writel(0x120, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
+ l2x0_saved_regs.phy_base = EXYNOS4_PA_L2CC;
+ /* TAG, Data Latency Control: 2 cycles */
+ l2x0_saved_regs.tag_latency = 0x110;
+
+ if (soc_is_exynos4212() || soc_is_exynos4412())
+ l2x0_saved_regs.data_latency = 0x120;
+ else
+ l2x0_saved_regs.data_latency = 0x110;
+
+ l2x0_saved_regs.prefetch_ctrl = 0x3007;
+ l2x0_saved_regs.pwr_ctrl =
+ (L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN);
- /* L2X0 Prefetch Control */
- __raw_writel(0x3007, S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
+ l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
- /* L2X0 Power Control */
- __raw_writel(L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN,
-S5P_VA_L2CC + L2X0_POWER_CTRL);
+ __raw_writel(l2x0_saved_regs.tag_latency,
+ S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL);
+ __raw_writel(l2x0_saved_regs.data_latency,
+ S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
+
+ /* L2X0 Prefetch Control */
+ __raw_writel(l2x0_saved_regs.prefetch_ctrl,
+ S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
+
+ /* L2X0 Power Control */
+ __raw_writel(l2x0_saved_regs.pwr_ctrl,
+ S5P_VA_L2CC + L2X0_POWER_CTRL);
+
+ clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
+ clean_dcache_area(&l2x0_saved_regs, sizeof(struct l2x0_regs));
+ }
l2x0_init(S5P_VA_L2CC, 0x7C470001, 0xC200);
diff --git a/arch/arm/mach-exynos4/sleep.S b/arch/arm/mach-exynos4/sleep.S
index c19527b..3284213 100644
--- a/arch/arm/mach-exynos4/sleep.S
+++ b/arch/arm/mach-exynos4/sleep.S
@@ -27,6 +27,8 @@
*/
#include
+#include
+#include
.text
@@ -47,7 +49,31 @@
* other way of restoring the stack pointer after sleep, and we
* must not write to the code segment (code is read-only)
*/
+ .align
+ .data
ENTRY(s3c_cpu_resume)
+ adr r0, l2x0_regs_phys
+ ldr r0, [r0]
+ ldr r1, [r0, #L2X0_R_PHY_BASE]
+ ldr r2, [r1, #L2X0_CTRL]
+ tst r2, #0x1
+ bne resume_l2on
+ ldr r2, [r0, #L2X0_R_AUX_CTRL]
+ str r2, [r1, #L2X0_AUX_CTRL]
+ ldr r2, [r0, #L2X0_R_TAG_LATENCY]
+ str r2, [r1, #L2X0_TAG_LATENCY_CTRL]
+ ldr r2, [r0, #L2X0_R_DATA_LATENCY]
+ str r2, [r1, #L2X0_DATA_LATENCY_CTRL]
+ ldr r2, [r0, #L2X0_R_PREFETCH_CTRL]
+ str r2, [r1, #L2X0_PREFETCH_CTRL]
+ ldr r2, [r0, #L2X0_R_PWR_CTRL]
+ str r2, [r1, #L2X0_POWER_CTRL]
+ mov r2, #1
+ str r2, [r1, #L2X0_CTRL]
+resume_l2on:
b cpu_resume
ENDPROC(s3c_cpu_resume)
+ .globl l2x0_regs_phys
+l2x0_regs_phys:
+ .long 0
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state
From: Amit Daniel Kachhap
This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode.
This patch ports the code to the latest interfaces to
save/restore CPU state inclusive of CPU PM notifiers, l2
resume and cpu_suspend/resume.
Signed-off-by: Jaecheol Lee
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Amit Daniel Kachhap
---
arch/arm/mach-exynos4/cpuidle.c | 152 +-
arch/arm/mach-exynos4/include/mach/pmu.h |2 +
2 files changed, 151 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-exynos4/cpuidle.c
index bf7e96f..111ccc3 100644
--- a/arch/arm/mach-exynos4/cpuidle.c
+++ b/arch/arm/mach-exynos4/cpuidle.c
@@ -11,22 +11,48 @@
#include
#include
#include
+#include
#include
-
+#include
+#include
#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24))
+#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20))
static int exynos4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_state *state);
+static int exynos4_enter_lowpower(struct cpuidle_device *dev,
+ struct cpuidle_state *state);
+
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
.enter = exynos4_enter_idle,
.exit_latency = 1,
.target_residency = 10,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .name = "IDLE",
+ .name = "C0",
.desc = "ARM clock gating(WFI)",
},
+ [1] = {
+ .enter = exynos4_enter_lowpower,
+ .exit_latency = 300,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = "C1",
+ .desc = "ARM power down",
+ },
};
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
@@ -36,6 +62,96 @@ static struct cpuidle_driver exynos4_idle_driver = {
.owner = THIS_MODULE,
};
+/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
+static void exynos4_set_wakeupmask(void)
+{
+ __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+}
+
+static unsigned int g_pwr_ctrl, g_diag_reg;
+
+static void save_cpu_arch_register(void)
+{
+ /*read power control register*/
+ asm("mrc p15, 0, %0, c15, c0, 0" : "=r"(g_pwr_ctrl) : : "cc");
+ /*read diagnostic register*/
+ asm("mrc p15, 0, %0, c15, c0, 1" : "=r"(g_diag_reg) : : "cc");
+ return;
+}
+
+static void restore_cpu_arch_register(void)
+{
+ /*write power control register*/
+ asm("mcr p15, 0, %0, c15, c0, 0" : : "r"(g_pwr_ctrl) : "cc");
+ /*write diagnostic register*/
+ asm("mcr p15, 0, %0, c15, c0, 1" : : "r"(g_diag_reg) : "cc");
+ return;
+}
+
+static int idle_finisher(unsigned long flags)
+{
+ cpu_do_idle();
+ return 1;
+}
+
+static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct timeval before, after;
+ int idle_time;
+ unsigned long tmp;
+
+ local_irq_disable();
+ do_gettimeofday(&before);
+
+ exynos4_set_wakeupmask();
+
+ /* Set value of power down register for aftr mode */
+ exynos4_sys_powerdown_conf(SYS_AFTR);
+
+ save_cpu_arch_register();
+
+ /* Setting Central Sequence Register for power down mode */
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ tmp &= ~S5P_CENTRAL_LOWPWR_CFG;
+ __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+
+ cpu_pm_enter();
+ cpu_cluster_pm_enter();
+
+ cpu_suspend(0, idle_finisher);
+
+ scu_enable(S5P_VA_SCU);
+
+ cpu_cluster_pm_exit();
+ cpu_pm_exit();
+
+ restore_cpu_arch_register();
+
+ /*
+* If PMU failed while entering sleep mode, WFI will be
+* ignored by PMU and then exiting cpu_do_idle().
+* S5P_CENTRAL_LOWPWR_CFG bit will not be set automatically
+* in this situation.
+*/
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ if (!(tmp & S5P_CENTRAL_LOWPWR_CFG)) {
+ tmp |= S5P_CENTRAL_LOWPWR_CFG;
+ __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+ }
+
+ /* Clear wakeup state register */
+ __raw_writel(0x0, S5P_WAKEUP_STAT);
+
+ do_gettimeofday(&after);
+
+ local_irq_enable();
+ idle_time = (after.tv_sec - befor
[PATCH 4/4] ARM: exynos4: remove useless code to save/restore L2 and GIC state
From: Amit Daniel Kachhap
Following the merge of CPU PM notifiers and L2 resume code, this patch
removes useless code to save and restore L2 and GIC registers.
This is now automatically covered by suspend calls which integrated
CPU PM notifiers and new sleep code that allows to resume L2 before MMU
is turned on.
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Amit Daniel Kachhap
---
arch/arm/mach-exynos4/pm.c | 86
1 files changed, 0 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-exynos4/pm.c b/arch/arm/mach-exynos4/pm.c
index 62e4f43..7499f14 100644
--- a/arch/arm/mach-exynos4/pm.c
+++ b/arch/arm/mach-exynos4/pm.c
@@ -63,77 +63,6 @@ static struct sleep_save exynos4_vpll_save[] = {
};
static struct sleep_save exynos4_core_save[] = {
- /* GIC side */
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x000),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x004),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x008),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x00C),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x014),
- SAVE_ITEM(S5P_VA_GIC_CPU + 0x018),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x000),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x004),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x100),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x104),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x108),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x300),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x304),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x308),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x400),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x404),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x408),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x40C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x410),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x414),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x418),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x41C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x420),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x424),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x428),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x42C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x430),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x434),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x438),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x43C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x440),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x444),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x448),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x44C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x450),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x454),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x458),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x45C),
-
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x800),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x804),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x808),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x80C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x810),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x814),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x818),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x81C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x820),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x824),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x828),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x82C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x830),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x834),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x838),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x83C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x840),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x844),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x848),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x84C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x850),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x854),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x858),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0x85C),
-
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC00),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC04),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC08),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC0C),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC10),
- SAVE_ITEM(S5P_VA_GIC_DIST + 0xC14),
SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x000),
SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x010),
@@ -154,13 +83,6 @@ static struct sleep_save exynos4_core_save[] = {
SAVE_ITEM(S5P_SROM_BC3),
};
-static struct sleep_save exynos4_l2cc_save[] = {
- SAVE_ITEM(S5P_VA_L2CC + L2X0_TAG_LATENCY_CTRL),
- SAVE_ITEM(S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL),
- SAVE_ITEM(S5P_VA_L2CC + L2X0_PREFETCH_CTRL),
- SAVE_ITEM(S5P_VA_L2CC + L2X0_POWER_CTRL),
- SAVE_ITEM(S5P_VA_L2CC + L2X0_AUX_CTRL),
-};
/* For Cortex-A9 Diagnostic and Power control register */
static unsigned int save_arm_register[2];
@@ -181,7 +103,6 @@ static void exynos4_pm_prepare(void)
u32 tmp;
s3c_pm_do_save(exynos4_core_save, ARRAY_SIZE(exynos4_core_save));
- s3c_pm_do_save(exynos4_l2cc_save, ARRAY_SIZE(exynos4_l2cc_save));
s3c_pm_do_save(exynos4_epll_save, ARRAY_SIZE(exynos4_epll_save));
s3c_pm_do_save(exynos4_vpll_save, ARRAY_SIZE(exynos4_vpll_save));
@@ -397,13 +318,6 @@ static void exynos4_pm_resume(void)
exynos4_scu_enable(S5P_VA_SCU);
-#ifdef CONFIG_CACHE_L2X0
- s3c_pm_do_restore_core(exynos4_l2c
[PATCH 0/4]ARM: exynos4: Add l2 retention mode cpuidle state
From: Amit Daniel Kachhap This Patch series adds support for AFTR mode cpuidle state based on patch (http://www.spinics.net/lists/arm-kernel/msg132243.html) earlier submitted by Jaecheol Lee . This patch uses CPU PM notifiers , common l2 save/restore and new cpu_suspend/resume interfaces and is based on the tip of linus tree(git://github.com/torvalds/linux.git). Amit Daniel Kachhap (3): ARM: exynos4: Add support for AFTR mode cpuidle state ARM: exynos4: add L2 early resume code ARM: exynos4: remove useless code to save/restore L2 and GIC state Lorenzo Pieralisi (1): ARM: exynos4: remove useless churn in sleep.S arch/arm/mach-exynos4/cpu.c | 43 ++-- arch/arm/mach-exynos4/cpuidle.c | 152 +- arch/arm/mach-exynos4/include/mach/pmu.h |2 + arch/arm/mach-exynos4/pm.c | 86 - arch/arm/mach-exynos4/sleep.S| 29 +- 5 files changed, 210 insertions(+), 102 deletions(-) -- 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 4/4] ARM: exynos4: remove useless code to save/restore L2 and GIC state
On 4 November 2011 23:03, Sylwester Nawrocki wrote:
> On 11/04/2011 06:03 PM, amit.kach...@linaro.org wrote:
>> From: Amit Daniel Kachhap
>>
>> Following the merge of CPU PM notifiers and L2 resume code, this patch
>> removes useless code to save and restore L2 and GIC registers.
>>
>> This is now automatically covered by suspend calls which integrated
>> CPU PM notifiers and new sleep code that allows to resume L2 before MMU
>> is turned on.
>>
>> Signed-off-by: Lorenzo Pieralisi
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> arch/arm/mach-exynos4/pm.c | 86
>>
>> 1 files changed, 0 insertions(+), 86 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos4/pm.c b/arch/arm/mach-exynos4/pm.c
>> index 62e4f43..7499f14 100644
>> --- a/arch/arm/mach-exynos4/pm.c
>> +++ b/arch/arm/mach-exynos4/pm.c
>> @@ -63,77 +63,6 @@ static struct sleep_save exynos4_vpll_save[] = {
>> };
>>
>> static struct sleep_save exynos4_core_save[] = {
>> - /* GIC side */
>> - SAVE_ITEM(S5P_VA_GIC_CPU + 0x000),
>> - SAVE_ITEM(S5P_VA_GIC_CPU + 0x004),
>> - SAVE_ITEM(S5P_VA_GIC_CPU + 0x008),
>> - SAVE_ITEM(S5P_VA_GIC_CPU + 0x00C),
>> - SAVE_ITEM(S5P_VA_GIC_CPU + 0x014),
>> - SAVE_ITEM(S5P_VA_GIC_CPU + 0x018),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x000),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x004),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x100),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x104),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x108),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x300),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x304),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x308),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x400),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x404),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x408),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x40C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x410),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x414),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x418),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x41C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x420),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x424),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x428),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x42C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x430),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x434),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x438),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x43C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x440),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x444),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x448),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x44C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x450),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x454),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x458),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x45C),
>> -
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x800),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x804),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x808),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x80C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x810),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x814),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x818),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x81C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x820),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x824),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x828),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x82C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x830),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x834),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x838),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x83C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x840),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x844),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x848),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x84C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x850),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x854),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x858),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0x85C),
>> -
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0xC00),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0xC04),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0xC08),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0xC0C),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0xC10),
>> - SAVE_ITEM(S5P_VA_GIC_DIST + 0xC14),
>
>
> This list is not complete anyway, some peripheral devices interrupts do not
> work after resume from system suspend to RAM.
> Is there any code already handling GIC state during system suspend/resume
> cycles?
> Or you refer to some upcoming patches ?
In my next patch series I have left the GIC save/restore from platform code.
>
> --
> Thanks,
> Sylwester
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freeze date for the Linaro 11.11 kernel release
Hi Nicolas, Please pull the samsung cpuidle code from, (git://git.linaro.org/people/amitdanielk/linux.git branch: samsung_cpuidle_l2_retention). The above branch is rebased on top of your tree and contains some necessary patches already in mainline. All these patches are submitted and under review(http://www.spinics.net/lists/arm-kernel/msg146579.html). Thanks, Amit Daniel On 9 November 2011 12:55, Amit Kucheria wrote: > On Wed, Nov 9, 2011 at 12:59 AM, Nicolas Pitre > wrote: >> >> We are considering freezing the 11.11 kernel this next Monday (Nov 14) >> in order to release it on Wednesday (Nov 16), so it is out there before >> the US Thanksgiving holiday. >> >> If anyone would like to see their patches included in the Linaro kernel >> for this month, please consider submitting them ASAP. >> >> As discussed in Orlando, we are also considering a shift towards using >> the latest tagged release from Torvalds' mainline tree. This process is >> not fully in place yet, so the regular Linaro release based on the >> latest stable upstream release will still occur for this month. > > Vincent, Amit: > > Could you please ensure that sched_mc optimisation and samsung cpuidle > patches are integrated and enabled into Nico's tree? > > Mike: > > Any chance of getting a preview of common clk on a separate branch and > asking the platform team to create a build for it? > > Rob, Daniel: Same thing for cpuidle core + imx changes as Mike. > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state
On 11 November 2011 13:03, MyungJoo Ham wrote: > On Sat, Nov 5, 2011 at 2:03 AM, wrote: >> From: Amit Daniel Kachhap >> >> This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in >> cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode. >> This patch ports the code to the latest interfaces to >> save/restore CPU state inclusive of CPU PM notifiers, l2 >> resume and cpu_suspend/resume. >> >> Signed-off-by: Jaecheol Lee >> Signed-off-by: Lorenzo Pieralisi >> Signed-off-by: Amit Daniel Kachhap >> --- > [] >> +#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \ >> + S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24)) >> +#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \ >> + S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20)) >> > [] >> + >> + __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)), >> + REG_DIRECTGO_ADDR); >> + __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG); >> + >> return 0; > > Hello, > > > Why are you using INFORM6 and 7 registers in order to save resume > address and power-mode flags? > > INFORM0 and 1 have been used in pm.c for the exactly same purpose. > Please use the same registers in cpuidle.c as well. > > The same part in bootloader (IPL) can handle whether it's > suspend-to-RAM or AFTR and the both modes are mutually exclusive and > you only need one value for resume PC. > > Therefore, you can keep the value at the same location, which is the > method we have been using. Hi, I tried using INFORM0 and INFORM1 in cpuidle and make it same as pm.c. But this doesnt work. Looks like my irom fused code checks for the wakeup source and needs INFORM7 and INFORM6 for non sleep wakeups. My cpu version is S5PV310AH--0AH1113(Origen board). I suggest adding support for both type of wakeups(directly from irom and through bootloader). Thanks, Amit D > > Besides, the Exynos4210 chipmaker (S.LSI) has told that INFORM6 and 7 > registers are used by in-chip code (iROM or iRAM). > > > Cheers! > MyungJoo > > > > -- > MyungJoo Ham, Ph.D. > Mobile Software Platform Lab, DMC Business, Samsung Electronics > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro powertop doesn't work well on a single core ARM SoC
Hi Barry,
You fix for invalid cpu id looks fine. As for the P states this new
powertop combines with the cpuidle numbers. so if the system is highly
idle it means processor is idle and hence P states is shown as 0.
Thanks,
Amit Daniel
On 12 December 2011 15:55, Barry Song <21cn...@gmail.com> wrote:
> Hi Tony/Amit,
> anybody has tried to use powertop from linaro on a single core ARM
> SoC? What i am using is
> git://android.git.linaro.org/platform/external/powertop.git.
> I got two questions:
> 1. powertop will crash in handle_one_cpu() due to it gets wrong cpu
> number(-1), then i made the following change to make it work:
>
> powertop: fix segment fault for single cpu env
>
> Signed-off-by: Barry Song
>
> diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
> index 29fc72c..c56c746 100644
> --- a/cpu/cpu.cpp
> +++ b/cpu/cpu.cpp
> @@ -302,6 +302,9 @@ void enumerate_cpus(void)
> model = strtoull(c, NULL, 10);
> }
> }
> +
> + if (number == -1)
> + number = 0;
> if (strncasecmp(line, "bogomips\t", 9) == 0) {
> handle_one_cpu(number, vendor, family, model);
> set_max_cpu(number);
>
> 2. after fixing problem1, powertop can run on PrimaII, but i always
> get 0.0% for every p states as you can see from attached pic.
> but if we check cpufreq stats in
> /sys/devices/system/cpu/cpu0/cpufreq/stats, my system does change freq
> based on ondemand.
>
> # cat time_in_state
> 80 2064
> 60 181
> 40 341
> 20 60381
>
> # cat trans_table
> From : To
> : 80 60 40 20
> 80: 0 13 13 14
> 60: 5 0 3 5
> 40: 5 0 0 11
> 20: 29 0 0 0
>
> # cat total_trans
> 98
>
> does anyone have experiences about it?
>
> Thanks
> barry
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
Hi Nicolas,
Is it possible for you to add these 2 patches for this month release? I am
not able to give you the git link as there is seems some problem with the
linaro git server.
Also I attached the patches in case required.
Thanks,
Amit Daniel
On 13 December 2011 20:43, Amit Daniel Kachhap
wrote:
> PATCH 1) [thermal: Add a new trip type to use cooling device instance
number]
> This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes
> cooling device instance number and may be helpful for cpufreq cooling
devices
> to take the correct cooling action.
>
> PATCH 2) [thermal: Add generic cpu cooling implementation]
> This patch adds generic cpu cooling low level implementation through
frequency
> clipping and cpu hotplug. In future, other cpu related cooling devices
may be
> added here. An ACPI version of this already
exists(drivers/acpi/processor_thermal.c).
> But this will be useful for platforms like ARM using the generic thermal
interface
> along with the generic cpu cooling devices. The cooling device
registration API's
> return cooling device pointers which can be easily binded with the
thermal zone
> trip points.
>
>
> Amit Daniel Kachhap (2):
> thermal: Add a new trip type to use cooling device instance number
> thermal: Add generic cpu cooling implementation
>
> Documentation/thermal/cpu-cooling-api.txt | 52 +
> Documentation/thermal/sysfs-api.txt |4 +-
> drivers/thermal/Kconfig | 11 +
> drivers/thermal/Makefile |1 +
> drivers/thermal/cpu_cooling.c | 302
+
> drivers/thermal/thermal_sys.c | 27 +++-
> include/linux/cpu_cooling.h | 45 +
> include/linux/thermal.h |1 +
> 8 files changed, 440 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/thermal/cpu-cooling-api.txt
> create mode 100644 drivers/thermal/cpu_cooling.c
> create mode 100644 include/linux/cpu_cooling.h
>
From 8719c5aca30fc986a7e89c600fa54d340342e9e2 Mon Sep 17 00:00:00 2001
From: Amit Daniel Kachhap
Date: Thu, 1 Dec 2011 18:51:39 +0530
Subject: [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number
This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.
Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.
Signed-off-by: Amit Daniel Kachhap
---
Documentation/thermal/sysfs-api.txt |4 ++--
drivers/thermal/thermal_sys.c | 27 ++-
include/linux/thermal.h |1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index b61e46f..5c1d44e 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
trip_point_[0-*]_type
Strings which indicate the type of the trip point.
- E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
- thermal zone.
+ E.g. it can be one of critical, hot, passive, active[0-1],
+ state-active[0-*] for ACPI thermal zone.
RO, Optional
cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index dd9a574..72b1ab3 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct device_attribute *attr,
return sprintf(buf, "passive\n");
case THERMAL_TRIP_ACTIVE:
return sprintf(buf, "active\n");
+ case THERMAL_TRIP_STATE_ACTIVE:
+ return sprintf(buf, "state-active\n");
default:
return sprintf(buf, "unknown\n");
}
@@ -1035,7 +1037,7 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
void thermal_zone_device_update(struct thermal_zone_device *tz)
{
int count, ret = 0;
- long temp, trip_temp;
+ long temp, trip_temp, max_state, last_trip_change = 0;
enum thermal_trip_type trip_type;
struct thermal_cooling_device_instance *instance;
struct thermal_cooling_device *cdev;
@@ -1086,6 +1088,29 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
cdev->ops->set_cur_state(cdev, 0);
}
break;
+ case THERMAL_TRIP_STATE_ACTIVE:
+ list_for_each_entry(instance, &tz->cooling_devices,
+ node) {
+if (instance->trip != count)
+ continue;
+
+if (temp <= last_trip_change)
+ continue;
+
+cdev = instance->cdev;
+cdev->ops->get_max_state(cdev, &max_state);
+
+if ((temp >= trip_temp) &&
+ ((count + 1) <= max_state))
+ cdev->ops->set_cur_state(cdev,
+count + 1);
+else if ((temp < trip_temp) &&
+ (count <= max_state))
+ cdev->ops->set_cur_state(cdev, count)
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
Hi Nicolas, Please pull my samsung thermal implementation work from git repository (git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling). Some of the patches are under review and some are in mainline in 3.2 rc* version. It is all based on the tip of your tree. The patches are added since commit id 971be11492b1e248798f7078592b1fa0dfbf3534 Thanks, Amit Daniel On 14 December 2011 20:11, Amit Kachhap wrote: > Hi Nicolas, > > Is it possible for you to add these 2 patches for this month release? I am > not able to give you the git link as there is seems some problem with the > linaro git server. > Also I attached the patches in case required. > > Thanks, > Amit Daniel > > > On 13 December 2011 20:43, Amit Daniel Kachhap > wrote: > > PATCH 1) [thermal: Add a new trip type to use cooling device instance > number] > > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes > > cooling device instance number and may be helpful for cpufreq cooling > devices > > to take the correct cooling action. > > > > PATCH 2) [thermal: Add generic cpu cooling implementation] > > This patch adds generic cpu cooling low level implementation through > frequency > > clipping and cpu hotplug. In future, other cpu related cooling devices > may be > > added here. An ACPI version of this already > exists(drivers/acpi/processor_thermal.c). > > But this will be useful for platforms like ARM using the generic thermal > interface > > along with the generic cpu cooling devices. The cooling device > registration API's > > return cooling device pointers which can be easily binded with the > thermal zone > > trip points. > > > > > > Amit Daniel Kachhap (2): > > thermal: Add a new trip type to use cooling device instance number > > thermal: Add generic cpu cooling implementation > > > > Documentation/thermal/cpu-cooling-api.txt | 52 + > > Documentation/thermal/sysfs-api.txt |4 +- > > drivers/thermal/Kconfig | 11 + > > drivers/thermal/Makefile |1 + > > drivers/thermal/cpu_cooling.c | 302 > + > > drivers/thermal/thermal_sys.c | 27 +++- > > include/linux/cpu_cooling.h | 45 + > > include/linux/thermal.h |1 + > > 8 files changed, 440 insertions(+), 3 deletions(-) > > create mode 100644 Documentation/thermal/cpu-cooling-api.txt > > create mode 100644 drivers/thermal/cpu_cooling.c > > create mode 100644 include/linux/cpu_cooling.h > > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 2/6] Thermal: make sure cpufreq cooling register after cpufreq driver
On 24 October 2012 17:28, hongbo.zhang wrote: > From: "hongbo.zhang" > > The cpufreq works as a cooling device, so the cooling layer should check if > the > cpufreq driver is initialized or not. > > Signed-off-by: hongbo.zhang > --- > drivers/thermal/cpu_cooling.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > index b6b4c2a..7519a0b 100644 > --- a/drivers/thermal/cpu_cooling.c > +++ b/drivers/thermal/cpu_cooling.c > @@ -354,6 +354,10 @@ struct thermal_cooling_device *cpufreq_cooling_register( > int ret = 0, i; > struct cpufreq_policy policy; > > + /* make sure cpufreq driver has been initialized */ > + if (!cpufreq_frequency_get_table(cpumask_any(clip_cpus))) > + return ERR_PTR(-EPROBE_DEFER); > + Hi Hongbo, I am not against this change but this might cause unnecessary delay in probe thread. I also thought about it but have not put this restriction. Actually you can put a check in platform_bind for this condition and defer the binding till the time actual throttling starts. So basically only after throttling cpufreq_table is needed. (See my implementation exynos_thermal.c). Thanks, Amit Daniel > list_for_each_entry(cpufreq_dev, &cooling_cpufreq_list, node) > cpufreq_dev_count++; > > -- > 1.7.11.3 > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 3/6] Thermal: fix bug of counting cpu frequencies.
On 24 October 2012 19:04, Viresh Kumar wrote: > On 24 October 2012 17:28, hongbo.zhang wrote: >> From: "hongbo.zhang" >> >> In the while loop for counting cpu frequencies, if table[i].frequency equals >> CPUFREQ_ENTRY_INVALID, index i won't be increased, so this leads to an >> endless >> loop, what's more the index i cannot be referred as cpu frequencies number if >> there is CPUFREQ_ENTRY_INVALID case. >> >> Signed-off-by: hongbo.zhang > > Good one. > > Reviewed-by: Viresh Kumar Changes looks fine. Adding thermal maintainer(Rui Zhang) in the mail list. Reviewed-by: Amit Daniel Kachhap Thanks, Amit Daniel > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 4/6] Thermal: Remove the cooling_cpufreq_list.
On 26 October 2012 12:39, hongbo.zhang wrote:
> From: "hongbo.zhang"
>
> Problem of using this list is that the cpufreq_get_max_state callback will be
> called when register cooling device by thermal_cooling_device_register, but
> this list isn't ready at this moment. What's more, there is no need to
> maintain
> such a list, we can get cpufreq_cooling_device instance by the private
> thermal_cooling_device.devdata.
Hi,
Removing this list seems fine as most of frequency checks are moved
inside generic thermal layer.
Some minor review comments below,
Reviewed-by: Amit Daniel Kachhap
>
> Signed-off-by: hongbo.zhang
> ---
> drivers/thermal/cpu_cooling.c | 91
> +--
> 1 file changed, 19 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 415b041..2ffd12c 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -58,8 +58,9 @@ struct cpufreq_cooling_device {
> };
> static LIST_HEAD(cooling_cpufreq_list);
> static DEFINE_IDR(cpufreq_idr);
> +static DEFINE_MUTEX(cooling_cpufreq_lock);
>
> -static struct mutex cooling_cpufreq_lock;
> +static unsigned int cpufreq_dev_count;
>
> /* notify_table passes value to the CPUFREQ_ADJUST callback function. */
> #define NOTIFY_INVALID NULL
> @@ -240,28 +241,18 @@ static int cpufreq_thermal_notifier(struct
> notifier_block *nb,
> static int cpufreq_get_max_state(struct thermal_cooling_device *cdev,
> unsigned long *state)
> {
> - int ret = -EINVAL, i = 0;
> - struct cpufreq_cooling_device *cpufreq_device;
> - struct cpumask *maskPtr;
> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
check cdev is not null.
> + struct cpumask *maskPtr = &cpufreq_device->allowed_cpus;
> unsigned int cpu;
> struct cpufreq_frequency_table *table;
> unsigned long count = 0;
> + int i = 0;
>
> - mutex_lock(&cooling_cpufreq_lock);
> - list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
> - if (cpufreq_device && cpufreq_device->cool_dev == cdev)
> - break;
> - }
> - if (cpufreq_device == NULL)
> - goto return_get_max_state;
> -
> - maskPtr = &cpufreq_device->allowed_cpus;
> cpu = cpumask_any(maskPtr);
> table = cpufreq_frequency_get_table(cpu);
> if (!table) {
> *state = 0;
> - ret = 0;
> - goto return_get_max_state;
> + return 0;
> }
>
> for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> @@ -272,12 +263,10 @@ static int cpufreq_get_max_state(struct
> thermal_cooling_device *cdev,
>
> if (count > 0) {
> *state = --count;
> - ret = 0;
> + return 0;
> }
>
> -return_get_max_state:
> - mutex_unlock(&cooling_cpufreq_lock);
> - return ret;
> + return -EINVAL;
> }
>
> /**
> @@ -288,20 +277,10 @@ return_get_max_state:
> static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
> unsigned long *state)
> {
> - int ret = -EINVAL;
> - struct cpufreq_cooling_device *cpufreq_device;
> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
>
> - mutex_lock(&cooling_cpufreq_lock);
> - list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
> - if (cpufreq_device && cpufreq_device->cool_dev == cdev) {
> - *state = cpufreq_device->cpufreq_state;
> - ret = 0;
> - break;
> - }
> - }
> - mutex_unlock(&cooling_cpufreq_lock);
> -
> - return ret;
> + *state = cpufreq_device->cpufreq_state;
> + return 0;
> }
>
> /**
> @@ -312,22 +291,9 @@ static int cpufreq_get_cur_state(struct
> thermal_cooling_device *cdev,
> static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
> unsigned long state)
> {
> - int ret = -EINVAL;
> - struct cpufreq_cooling_device *cpufreq_device;
> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
check cdev is not null
>
> - mutex_lock(&cooling_cpufreq_lock);
> - list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
> - if (cpufreq_device && cpufreq_device->cool_dev == cdev) {
> - ret = 0;
> - break;
> - }
> - }
> - if (!ret)
> - ret = cpufreq_apply_cooling(cpufreq_device, state);
> -
> - mutex_unlock(&cooling_cpufreq_lock);
> -
> - return ret;
> + return cpufreq_apply_cooling(cpufreq_device, state);
> }
>
> /* Bind cpufreq callbacks to thermal cooling device ops */
> @@ -351,7 +317,7 @@ struct thermal_cooling_device *cpufre
Re: [PATCH] ARM: SAMSUNG: Removing dependency on CONFIG_PM_DEBUG for clock debugging
yes this is a temporary patch untill all the PM
components(sleep/resume) are mainlined.
The exact compilation error is,
CC arch/arm/plat-samsung/pm.o
arch/arm/plat-samsung/pm.c:32: fatal error: mach/pm-core.h: No such
file or directory
compilation terminated.
make[1]: *** [arch/arm/plat-samsung/pm.o] Error 1
Thanks,
Amit Daniel
On 11 February 2011 02:57, Amit Kucheria wrote:
>
> On Sat, Feb 12, 2011 at 7:06 PM, Amit Daniel Kachhap
> wrote:
> > Enabling the macro CONFIG_PM_DEBUG is causing compilation error as all PM
> > components
> > are included which is not in mainline for samsung V310 platform, therefore,
> > this patch
> > removes the dependency on macro CONFIG_PM_DEBUG for clock debugging through
> > debugfs
> > interface.
>
> What is the exact error? Might be helpful to have it in the patch description.
>
> Presumably, this is a temporary patch until PM components
> (suspend/resume hooks?) are mainlined and then we can put all this
> back under PM_DEBUG? In that case, it might be a good idea to mark it
> as such.
>
> Regards,
> Amit
>
> > Signed-off-by: Amit Daniel Kachhap
> > ---
> > arch/arm/plat-samsung/clock.c | 4 ++--
> > arch/arm/plat-samsung/include/plat/clock.h | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c
> > index 7728928..aca5a25 100644
> > --- a/arch/arm/plat-samsung/clock.c
> > +++ b/arch/arm/plat-samsung/clock.c
> > @@ -450,7 +450,7 @@ int __init s3c24xx_register_baseclocks(unsigned long
> > xtal)
> > return 0;
> > }
> >
> > -#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> > +#if defined(CONFIG_DEBUG_FS)
> > /* debugfs support to trace clock tree hierarchy and attributes */
> >
> > static struct dentry *clk_debugfs_root;
> > @@ -538,4 +538,4 @@ err_out:
> > }
> > late_initcall(clk_debugfs_init);
> >
> > -#endif /* defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS) */
> > +#endif /* defined(CONFIG_DEBUG_FS) */
> > diff --git a/arch/arm/plat-samsung/include/plat/clock.h
> > b/arch/arm/plat-samsung/include/plat/clock.h
> > index 9a82b88..f6180ab 100644
> > --- a/arch/arm/plat-samsung/include/plat/clock.h
> > +++ b/arch/arm/plat-samsung/include/plat/clock.h
> > @@ -47,7 +47,7 @@ struct clk {
> >
> > struct clk_ops *ops;
> > int (*enable)(struct clk *, int enable);
> > -#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> > +#if defined(CONFIG_DEBUG_FS)
> > struct dentry *dent; /* For visible tree hierarchy */
> > #endif
> > };
> > --
> > 1.7.1
> >
> >
> > ___
> > linaro-dev mailing list
> > linaro-dev@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> >
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] CPUFREQ : calculate delay after dbs_check_cpu
Hi Vincent,
I checked this patch and I can see some performance improvement in my
arm platform also. So in your patch there are 2 changes. First one is
for calculating delay after rate_mult is set, this can be tested with
cpufreq-bench tool. For the second part which requires enabling power
save bias , the cpufreq-bench does not do that. So I tested with one
time setting of powersave_bias parameter and here also there is some
increase in performance. But ideally powersave mode should have more
power saving and some compromise in performance.
//Amit Daniel
On 15 February 2011 04:41, Vincent Guittot wrote:
> Hi,
>
> The ondemand delay value is calculated before calling dbs_check_cpu
> which can lead to a delay value of sampling_rate*sampling_down_factor
> but a frequency set to the lowest value. The main result is a slow
> responsiveness during this period. This patch moves the calculation of
> delay after the call of dbs_check_cpu. I have seen this problem when
> testing cpufreq-bench on my Arm platform.
>
> Vincent
>
> On 7 February 2011 17:14, Vincent Guittot wrote:
>> calculate ondemand delay after dbs_check_cpu call because it can
>> modify rate_mult value
>>
>> use freq_lo_jiffies value for the sub sample period of powersave_bias mode
>>
>> Signed-off-by: Vincent Guittot
>> ---
>> drivers/cpufreq/cpufreq_ondemand.c | 20 +---
>> 1 files changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq_ondemand.c
>> b/drivers/cpufreq/cpufreq_ondemand.c
>> index 58aa85e..44c2dba 100644
>> --- a/drivers/cpufreq/cpufreq_ondemand.c
>> +++ b/drivers/cpufreq/cpufreq_ondemand.c
>> @@ -641,13 +641,7 @@ static void do_dbs_timer(struct work_struct *work)
>> container_of(work, struct cpu_dbs_info_s, work.work);
>> unsigned int cpu = dbs_info->cpu;
>> int sample_type = dbs_info->sample_type;
>> -
>> - /* We want all CPUs to do sampling nearly on same jiffy */
>> - int delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
>> - * dbs_info->rate_mult);
>> -
>> - if (num_online_cpus() > 1)
>> - delay -= jiffies % delay;
>> + int delay;
>>
>> mutex_lock(&dbs_info->timer_mutex);
>>
>> @@ -660,10 +654,22 @@ static void do_dbs_timer(struct work_struct *work)
>> /* Setup timer for SUB_SAMPLE */
>> dbs_info->sample_type = DBS_SUB_SAMPLE;
>> delay = dbs_info->freq_hi_jiffies;
>> + } else {
>> + /* We want all CPUs to do sampling nearly on
>> + * same jiffy
>> + */
>> + delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
>> + * dbs_info->rate_mult);
>> +
>> + if (num_online_cpus() > 1)
>> + delay -= jiffies % delay;
>> +
>> }
>> +
>> } else {
>> __cpufreq_driver_target(dbs_info->cur_policy,
>> dbs_info->freq_lo, CPUFREQ_RELATION_H);
>> + delay = dbs_info->freq_lo_jiffies;
>> }
>> schedule_delayed_work_on(cpu, &dbs_info->work, delay);
>> mutex_unlock(&dbs_info->timer_mutex);
>> --
>> 1.7.1
>>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: Samsung: Basic CPUIDLE Support
Hi nicolas,
Can you merge this patch for adding basic cpuidle support? This may be
needed
for the current linaro release cycle.
Regards,
Amit Daniel
On 10 March 2011 10:41, Amit Daniel Kachhap wrote:
> This patch supports cpuidle framework for samsung S5PV310. Currently,
> Only one idle state is possible to use, but more idle states can
> be added followed by this patch.
>
> Signed-off-by: Jaecheol Lee
> Signed-off-by: Amit Daniel Kachhap
> ---
> Rebasing the patch for linaro 2.6.38 kernel. This patch adds basic cpuidle
> infrastructure and fixes the launchpad bug(bug id: 723543). This patch is
> under review in samsung mailing list.
> http://www.spinics.net/lists/linux-samsung-soc/msg04268.html
>
> arch/arm/mach-s5pv310/Makefile |1 +
> arch/arm/mach-s5pv310/cpuidle.c | 87
> +++
> 2 files changed, 88 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-s5pv310/cpuidle.c
>
> diff --git a/arch/arm/mach-s5pv310/Makefile
> b/arch/arm/mach-s5pv310/Makefile
> index 036fb38..c5db0fa 100644
> --- a/arch/arm/mach-s5pv310/Makefile
> +++ b/arch/arm/mach-s5pv310/Makefile
> @@ -15,6 +15,7 @@ obj- :=
> obj-$(CONFIG_CPU_S5PV310) += cpu.o init.o clock.o irq-combiner.o
> obj-$(CONFIG_CPU_S5PV310) += setup-i2c0.o time.o gpiolib.o irq-eint.o
> dma.o
> obj-$(CONFIG_CPU_FREQ) += cpufreq.o
> +obj-$(CONFIG_CPU_IDLE) += cpuidle.o
>
> obj-$(CONFIG_SMP) += platsmp.o headsmp.o
> obj-$(CONFIG_LOCAL_TIMERS) += localtimer.o
> diff --git a/arch/arm/mach-s5pv310/cpuidle.c
> b/arch/arm/mach-s5pv310/cpuidle.c
> new file mode 100644
> index 000..f35b537
> --- /dev/null
> +++ b/arch/arm/mach-s5pv310/cpuidle.c
> @@ -0,0 +1,87 @@
> +/* linux/arch/arm/mach-s5pv310/cpuidle.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static int s5pv310_enter_idle(struct cpuidle_device *dev,
> + struct cpuidle_state *state);
> +
> +static struct cpuidle_state s5pv310_cpuidle_set[] = {
> + [0] = {
> + .enter = s5pv310_enter_idle,
> + .exit_latency = 1,
> + .target_residency = 10,
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .name = "IDLE",
> + .desc = "ARM clock gating(WFI)",
> + },
> +};
> +
> +static DEFINE_PER_CPU(struct cpuidle_device, s5pv310_cpuidle_device);
> +
> +static struct cpuidle_driver s5pv310_idle_driver = {
> + .name = "s5pv310_idle",
> + .owner = THIS_MODULE,
> +};
> +
> +static int s5pv310_enter_idle(struct cpuidle_device *dev,
> + struct cpuidle_state *state)
> +{
> + struct timeval before, after;
> + int idle_time;
> +
> + local_irq_disable();
> + do_gettimeofday(&before);
> +
> + cpu_do_idle();
> +
> + do_gettimeofday(&after);
> + local_irq_enable();
> + idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
> + (after.tv_usec - before.tv_usec);
> +
> + return idle_time;
> +}
> +
> +static int __init s5pv310_init_cpuidle(void)
> +{
> + int i, max_cpuidle_state, cpu_id;
> + struct cpuidle_device *device;
> +
> + cpuidle_register_driver(&s5pv310_idle_driver);
> +
> + for_each_cpu(cpu_id, cpu_online_mask) {
> + device = &per_cpu(s5pv310_cpuidle_device, cpu_id);
> + device->cpu = cpu_id;
> +
> + device->state_count = (sizeof(s5pv310_cpuidle_set) /
> + sizeof(struct
> cpuidle_state));
> +
> + max_cpuidle_state = device->state_count;
> +
> + for (i = 0; i < max_cpuidle_state; i++) {
> + memcpy(&device->states[i], &s5pv310_cpuidle_set[i],
> + sizeof(struct cpuidle_state));
> + }
> +
> + if (cpuidle_register_device(device)) {
> + printk(KERN_ERR "CPUidle register device
> failed\n,");
> + return -EIO;
> + }
> + }
> + return 0;
> +}
> +
> +device_initcall(s5pv310_init_cpuidle);
> --
> 1.7.1
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V1] ARM: Samsung: Basic CPUIDLE Support
Hi Nicolas,
Please take this cpuidle commit from the samsung tree needed for Linaro new
rebuilt tree.
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=commit;h=df7bf189d23ecd1c211c273de462b93d9e3e1fef
Thanks,
Amit Daniel
On 18 March 2011 08:51, Amit Daniel Kachhap wrote:
> This patch supports cpuidle framework for EXYNOS4210. Currently,
> Only one idle state is possible to use, but more idle states can
> be added following by this patch.
>
> Signed-off-by: Jaecheol Lee
> Signed-off-by: Amit Daniel Kachhap
> ---
> FIX: Fixed the merging issue reported by Nicolas Pitre <
> nicolas.pi...@linaro.org>
>
> Sending the rebased patch for linaro 2.6.38 kernel. This patch adds basic
> cpuidle
> infrastructure and fixes the launchpad bug(bug id: 723543). This patch is
> under review in samsung mailing list.
> http://www.spinics.net/lists/linux-samsung-soc/msg04268.html
>
> arch/arm/mach-exynos4/Makefile |1 +
> arch/arm/mach-exynos4/cpuidle.c | 87
> +++
> 2 files changed, 88 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/cpuidle.c
>
> diff --git a/arch/arm/mach-exynos4/Makefile
> b/arch/arm/mach-exynos4/Makefile
> index b8f0e7d..f8a3a74 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_CPU_EXYNOS4210) += cpu.o init.o clock.o
> irq-combiner.o
> obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o gpiolib.o irq-eint.o dma.o
> obj-$(CONFIG_PM) += pm.o sleep.o
> obj-$(CONFIG_CPU_FREQ) += cpufreq.o
> +obj-$(CONFIG_CPU_IDLE) += cpuidle.o
>
> obj-$(CONFIG_SMP) += platsmp.o headsmp.o
>
> diff --git a/arch/arm/mach-exynos4/cpuidle.c
> b/arch/arm/mach-exynos4/cpuidle.c
> new file mode 100644
> index 000..a543a18
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/cpuidle.c
> @@ -0,0 +1,87 @@
> +/* linux/arch/arm/mach-exynos4/cpuidle.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static int exynos4_enter_idle(struct cpuidle_device *dev,
> + struct cpuidle_state *state);
> +
> +static struct cpuidle_state exynos4_cpuidle_set[] = {
> + [0] = {
> + .enter = exynos4_enter_idle,
> + .exit_latency = 1,
> + .target_residency = 10,
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .name = "IDLE",
> + .desc = "ARM clock gating(WFI)",
> + },
> +};
> +
> +static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
> +
> +static struct cpuidle_driver exynos4_idle_driver = {
> + .name = "exynos4_idle",
> + .owner = THIS_MODULE,
> +};
> +
> +static int exynos4_enter_idle(struct cpuidle_device *dev,
> + struct cpuidle_state *state)
> +{
> + struct timeval before, after;
> + int idle_time;
> +
> + local_irq_disable();
> + do_gettimeofday(&before);
> +
> + cpu_do_idle();
> +
> + do_gettimeofday(&after);
> + local_irq_enable();
> + idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
> + (after.tv_usec - before.tv_usec);
> +
> + return idle_time;
> +}
> +
> +static int __init exynos4_init_cpuidle(void)
> +{
> + int i, max_cpuidle_state, cpu_id;
> + struct cpuidle_device *device;
> +
> + cpuidle_register_driver(&exynos4_idle_driver);
> +
> + for_each_cpu(cpu_id, cpu_online_mask) {
> + device = &per_cpu(exynos4_cpuidle_device, cpu_id);
> + device->cpu = cpu_id;
> +
> + device->state_count = (sizeof(exynos4_cpuidle_set) /
> + sizeof(struct
> cpuidle_state));
> +
> + max_cpuidle_state = device->state_count;
> +
> + for (i = 0; i < max_cpuidle_state; i++) {
> + memcpy(&device->states[i], &exynos4_cpuidle_set[i],
> + sizeof(struct cpuidle_state));
> + }
> +
> + if (cpuidle_register_device(device)) {
> + printk(KERN_ERR "CPUidle register device
> failed\n,");
> + return -EIO;
> + }
> + }
> + return 0;
> +}
> +
> +device_initcall(exynos4_init_cpuidle);
> --
> 1.7.1
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Samsung: CPUIDLE Support
Hi Nicolas, I could not find this changes in the latest 2.6.38 Linaro kernel. Please merge the patch from the below mentioned samsung maintainers next link as this is required for the PM Linaro release. Thanks, Amit Daniel On 5 April 2011 01:36, Amit Kachhap wrote: > Hi Nicolas, > > Please take this cpuidle commit from the samsung tree needed for Linaro new > rebuilt tree. > > > http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=commit;h=df7bf189d23ecd1c211c273de462b93d9e3e1fef > > > Thanks, > Amit Daniel > > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Samsung: CPUIDLE Support
Hi John, Following macros can be enabled, CONFIG_CPU_IDLE, CONFIG_PM, CONFIG_PM_DEBUG Thanks, Amit Daniel On 11 April 2011 10:52, John Rigby wrote: > Amitk, So can I turn on all the CONFIG_PM* stuff for samsung now? > > > > On Mon, Apr 11, 2011 at 8:46 AM, Nicolas Pitre > wrote: > > On Mon, 11 Apr 2011, Amit Kachhap wrote: > > > >> Hi Nicolas, > >> > >> I could not find this changes in the latest 2.6.38 Linaro kernel. Please > >> merge the patch from the below > >> mentioned samsung maintainers next link as this is required for the PM > >> Linaro release. > > > > It is merged now. > > > > > > Nicolas > > > > ___ > > linaro-dev mailing list > > linaro-dev@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Samsung: CPUIDLE Support
Hi John, I forgot to mention that CONFIG_PM has dependency on CONFIG_SUSPEND. I tested in the latest Linaro kernel. Please enable the following macros, CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_PM_OPS=y CONFIG_ARCH_SUSPEND_POSSIBLE=y Regards, Amit Daniel On 12 April 2011 10:54, John Rigby wrote: > On Tue, Apr 12, 2011 at 2:39 AM, Amit Kachhap > wrote: > > Hi John, > > > > Following macros can be enabled, > > CONFIG_CPU_IDLE, > > CONFIG_PM, > > CONFIG_PM_DEBUG > Currently fails to compile with CONFIG_PM on. > > > > Thanks, > > Amit Daniel > > > > > > > > On 11 April 2011 10:52, John Rigby wrote: > >> > >> Amitk, So can I turn on all the CONFIG_PM* stuff for samsung now? > >> > >> > >> > >> On Mon, Apr 11, 2011 at 8:46 AM, Nicolas Pitre < > nicolas.pi...@linaro.org> > >> wrote: > >> > On Mon, 11 Apr 2011, Amit Kachhap wrote: > >> > > >> >> Hi Nicolas, > >> >> > >> >> I could not find this changes in the latest 2.6.38 Linaro kernel. > >> >> Please > >> >> merge the patch from the below > >> >> mentioned samsung maintainers next link as this is required for the > PM > >> >> Linaro release. > >> > > >> > It is merged now. > >> > > >> > > >> > Nicolas > >> > > >> > ___ > >> > linaro-dev mailing list > >> > linaro-dev@lists.linaro.org > >> > http://lists.linaro.org/mailman/listinfo/linaro-dev > >> > > > > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] Added an arm compiler flag
From: Amit Daniel Kachhap
Modified to extract correct elements of power_entry structure.
Signed-off-by: Amit Daniel Kachhap
---
cpu/cpu.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index 451c120..f9995be 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -747,7 +747,7 @@ void w_display_cpu_pstates(void)
struct power_entry {
-#ifdef __x86_64__
+#if defined(__x86_64__) || defined(__arm__)
int dummy;
#endif
int64_t type;
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] Modified Powertop to support ARM processor
From: Amit Daniel Kachhap
Added a compulsory field bogomips for each processor in case other
fields like model is missing. Error handling code added in case
of package id remains uninitialised.
Signed-off-by: Amit Daniel Kachhap
---
cpu/cpu.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index 39f00e7..451c120 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -171,6 +171,8 @@ static void handle_one_cpu(unsigned int number, char
*vendor, int family, int mo
file.close();
}
+ if (package_number == (unsigned int)-1)
+ package_number = 0;
if (system_level.children.size() <= package_number)
system_level.children.resize(package_number + 1, NULL);
@@ -263,6 +265,10 @@ void enumerate_cpus(void)
handle_one_cpu(number, vendor, family, model);
set_max_cpu(number);
}
+ if (strncasecmp(line, "bogomips\t",9) == 0) {
+ handle_one_cpu(number, vendor, family, model);
+ set_max_cpu(number);
+ }
}
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/2] Modified Powertop2.0 to support ARM processor
The following set of patches modify the powertop version 2.0 to work for ARM platform. The C states and P states was measured after doing these changes in powertop. Amit Daniel Kachhap (2): Modified Powertop to support ARM processor Added an arm compiler flag cpu/cpu.cpp |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) [PATCH 1/2] Modified Powertop to support ARM processor [PATCH 2/2] Added an arm compiler flag ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
