Re: [PATCH 11/18] MAINTAINERS: SI4713: Fix file pattern
On Sun, Jul 21, 2013 at 8:15 PM, Joe Perches wrote:
> commit c937ca034a0 ("[media] MAINTAINERS: Add maintainer entry for
> si4713 FM transmitter driver") typoed the pattern, fix it.
>
> Signed-off-by: Joe Perches
> cc: Eduardo Valentin
Acked-by: Eduardo Valentin
> cc: Mauro Carvalho Chehab
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 81d68ae..aa5ccd0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7394,7 +7394,7 @@ L:linux-me...@vger.kernel.org
> T: git git://linuxtv.org/media_tree.git
> W: http://linuxtv.org
> S: Odd Fixes
> -F: drivers/media/radio/radio-si4713.h
> +F: drivers/media/radio/radio-si4713.c
>
> SIANO DVB DRIVER
> M: Mauro Carvalho Chehab
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] media/si4713-i2c: take usecs_to_jiffies_timeout into use
Imre, On Tue, May 14, 2013 at 10:48 AM, Imre Deak wrote: > Use usecs_to_jiffies_timeout instead of open-coding the same. > > Signed-off-by: Imre Deak Acked-by: Eduardo Valentin > --- > drivers/media/radio/si4713-i2c.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/radio/si4713-i2c.c > b/drivers/media/radio/si4713-i2c.c > index fe16088..e12f058 100644 > --- a/drivers/media/radio/si4713-i2c.c > +++ b/drivers/media/radio/si4713-i2c.c > @@ -233,7 +233,7 @@ static int si4713_send_command(struct si4713_device > *sdev, const u8 command, > > /* Wait response from interrupt */ > if (!wait_for_completion_timeout(&sdev->work, > - usecs_to_jiffies(usecs) + 1)) > + usecs_to_jiffies_timeout(usecs))) > v4l2_warn(&sdev->sd, > "(%s) Device took too much time to answer.\n", > __func__); > @@ -470,7 +470,7 @@ static int si4713_wait_stc(struct si4713_device *sdev, > const int usecs) > > /* Wait response from STC interrupt */ > if (!wait_for_completion_timeout(&sdev->work, > - usecs_to_jiffies(usecs) + 1)) > + usecs_to_jiffies_timeout(usecs))) > v4l2_warn(&sdev->sd, > "%s: device took too much time to answer (%d > usec).\n", > __func__, usecs); > -- > 1.7.10.4 > -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: omap-thermal: remove trailing whitespace from omap-bandgap.c
Fixing to right email address. On Mon, Apr 8, 2013 at 1:22 PM, Greg KH wrote: > On Sun, Apr 07, 2013 at 06:47:20PM -0700, Tyrel Datwyler wrote: >> This patch removes trailing whitespace from a blank line in omap-bandgap.c as >> detected by the checkpatch.pl tool. >> >> Signed-off-by: Tyrel Datwyler >> --- >> drivers/staging/omap-thermal/omap-bandgap.c | 2 +- > > This file no longer is in my tree, are you sure you made this against > the proper branch? Please always make staging patches against the > linux-next tree. > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 22/22] radio-si4713: depend on SND_SOC
Arnd, On Thu, May 2, 2013 at 11:16 AM, Arnd Bergmann wrote: > It is not possible to select SND_SOC_SI476X if we have not also > enabled SND_SOC. > > warning: (RADIO_SI476X) selects SND_SOC_SI476X which has unmet > direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC) > > Cc: Hans Verkuil > Cc: linux-me...@vger.kernel.org > Signed-off-by: Arnd Bergmann > --- Note on your patch title, this change is against si476X, not on *si4713*. > drivers/media/radio/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig > index c0beee2..d529ba7 100644 > --- a/drivers/media/radio/Kconfig > +++ b/drivers/media/radio/Kconfig > @@ -22,6 +22,7 @@ config RADIO_SI476X > tristate "Silicon Laboratories Si476x I2C FM Radio" > depends on I2C && VIDEO_V4L2 > depends on MFD_SI476X_CORE > + depends on SND_SOC > select SND_SOC_SI476X > ---help--- > Choose Y here if you have this FM radio chip. > -- > 1.8.1.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
Arnd,
On Thu, Apr 25, 2013 at 1:28 PM, Arnd Bergmann wrote:
> The newly rewritten get_property() function causes a bogus warning
> from gcc-3.8, which cannot figure out that "level" is always
> initialized at the point where it gets evaluated:
>
> drivers/thermal/cpu_cooling.c: In function 'get_property':
> drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>if (property == GET_FREQ && level == j) {
> ^
>
> Slightly rearranging the code makes this more obvious and
> avoids the warning.
>
> Signed-off-by: Arnd Bergmann
> Cc: Zhang Rui
> Cc: Amit Daniel kachhap
Rui has merged a patch that removes this bogus compiler warning:
http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=next&id=4469b99743d296e24aefc5f8ed7df1bc9cfbbac8
Though, as not as elegant as your patch, it does the trick. :-)
> ---
> drivers/thermal/cpu_cooling.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 768b508..34878e6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long
> input,
> return 0;
> }
>
> - if (property == GET_FREQ)
> - level = descend ? input : (max_level - input -1);
> -
> -
> for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
> /* ignore invalid entry */
> if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> @@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long
> input,
> *output = descend ? j : (max_level - j - 1);
> return 0;
> }
> - if (property == GET_FREQ && level == j) {
> - /* get frequency by level */
> - *output = freq;
> - return 0;
> +
> + if (property == GET_FREQ) {
> + level = descend ? input : (max_level - input -1);
> +
> + if (level == j) {
> + /* get frequency by level */
> + *output = freq;
> + return 0;
> + }
> }
> j++;
> }
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Thermal SoC management updates for v3.19-rc5
Hello Rui, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git fixes to receive Thermal SoC Management updates for v3.19-rc5 with top-most ee853addd9fedb116bd34a18f11dd5959fcf0428: thermal: rcar: Spelling/grammar: s/drier use .../driver uses ...s/ (2015-01-12 16:48:10 -0400) on top of commit 5e0f872c7d7e371fbdf09e864eddd24bddfda8fe: Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit (2014-12-31 14:52:18 -0800) Specifics: - Minor fixes on drivers' side: IMX and RCAR. - Update TI SoC thermal maintainer entry. - type qualifier fix in OF thermal. - Updated documentation of OF cpufreq cooling register. BR, Eduardo Valentin Anson Huang (1): Thermal: imx: add clk disable/enable for suspend/resume Eduardo Valentin (1): MAINTAINERS: update ti-soc-thermal status Geert Uytterhoeven (2): thermal: of: Remove bogus type qualifier for of_thermal_get_trip_points() thermal: rcar: Spelling/grammar: s/drier use .../driver uses ...s/ Javi Merino (1): Documentation: thermal: document of_cpufreq_cooling_register() Nishanth Menon (1): MAINTAINERS: Add linux-omap to list of reviewers for TI Thermal Yoshihiro Shimoda (2): thermal: rcar: fix ENR register value thermal: rcar: change type of ctemp in rcar_thermal_update_temp() Documentation/thermal/cpu-cooling-api.txt | 15 +-- MAINTAINERS | 3 ++- drivers/thermal/imx_thermal.c | 2 ++ drivers/thermal/of-thermal.c | 2 +- drivers/thermal/rcar_thermal.c| 17 +++-- drivers/thermal/thermal_core.h| 4 ++-- 6 files changed, 31 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/3] thermal: trace: Trace when temperature is above a trip point
Punit,
On Tue, Jun 24, 2014 at 6:41 AM, Punit Agrawal wrote:
> "Javi Merino" writes:
>
>> Hi Punit,
>>
>> On Wed, Jun 11, 2014 at 12:31:44PM +0100, Punit Agrawal wrote:
>>> Create a new event to trace when the temperature is above a trip
>>> point. Use the trace-point when handling non-critical and critical
>>> trip pionts.
>>>
>>> Cc: Zhang Rui
>>> Cc: Eduardo Valentin
>>> Cc: Steven Rostedt
>>> Cc: Frederic Weisbecker
>>> Cc: Ingo Molnar
>>> Signed-off-by: Punit Agrawal
>>> ---
>>> Hi Steven,
>>>
>>> I am facing an issue with partial trace being emitted when using
>>> __print_symbolic in this patch.
>>>
>>> When the trip_type is THERMAL_TRIP_ACTIVE (i.e., the first value in
>>> the symbol map), the emitted trace contains the corresponding string
>>> ("active"). But for other values of trip_type an empty string is
>>> emitted in the trace.
>>>
>>> I've looked at other uses of __print_symbolic in the kernel and don't
>>> see any difference in usage. Do you know what could be causing this or
>>> alternately have any pointers on how to debug this behaviour?
>>>
>>> Thanks.
>>> Punit
>>>
>>> drivers/thermal/fair_share.c |7 ++-
>>> drivers/thermal/step_wise.c|5 -
>>> drivers/thermal/thermal_core.c |2 ++
>>> include/trace/events/thermal.h | 30 ++
>>> 4 files changed, 42 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/thermal/fair_share.c b/drivers/thermal/fair_share.c
>>> index 944ba2f..2cddd68 100644
>>> --- a/drivers/thermal/fair_share.c
>>> +++ b/drivers/thermal/fair_share.c
>>> @@ -23,6 +23,7 @@
>>> */
>>>
>>> #include
>>> +#include
>>>
>>> #include "thermal_core.h"
>>>
>>> @@ -34,14 +35,18 @@ static int get_trip_level(struct thermal_zone_device
>>> *tz)
>>> {
>>> int count = 0;
>>> unsigned long trip_temp;
>>> +enum thermal_trip_type trip_type;
>>>
>>> if (tz->trips == 0 || !tz->ops->get_trip_temp)
>>> return 0;
>>>
>>> for (count = 0; count < tz->trips; count++) {
>>> tz->ops->get_trip_temp(tz, count, &trip_temp);
>>> -if (tz->temperature < trip_temp)
>>> +if (tz->temperature < trip_temp) {
>>> +tz->ops->get_trip_type(tz, count, &trip_type);
>>> +trace_thermal_zone_trip(tz, count, trip_type);
>>
>> This should be outside the if condition. You want to report when trip
>> points have been hit, like in the step_wise code below.
>>
>
> It turned out to be a bit more subtle than moving the trace outside the
> if. I have the below fixup with an added comment. Let me know if that
> doesn't solve the problem.
>
> -- >8 --
> Subject: [PATCH] fixup! thermal: trace: Trace when temperature is above a
> trip point
Can you please repost the patch with the fixup merged?
Cheers,
>
> ---
> drivers/thermal/fair_share.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/fair_share.c b/drivers/thermal/fair_share.c
> index 2cddd68..6e0a3fb 100644
> --- a/drivers/thermal/fair_share.c
> +++ b/drivers/thermal/fair_share.c
> @@ -42,12 +42,19 @@ static int get_trip_level(struct thermal_zone_device *tz)
>
> for (count = 0; count < tz->trips; count++) {
> tz->ops->get_trip_temp(tz, count, &trip_temp);
> - if (tz->temperature < trip_temp) {
> - tz->ops->get_trip_type(tz, count, &trip_type);
> - trace_thermal_zone_trip(tz, count, trip_type);
> + if (tz->temperature < trip_temp)
> break;
> - }
> }
> +
> + /*
> +* count > 0 only if temperature is greater than first trip
> +* point, in which case, trip_point = count - 1
> +*/
> + if (count > 0) {
> + tz->ops->get_trip_type(tz, count - 1, &trip_type);
> + trace_thermal_zone_trip(tz, count - 1, trip_type);
> + }
> +
> return count;
> }
>
> --
> 1.7.10.4
>
>>> break;
>>> +}
>>> }
>>> return count;
>>> }
>>> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
>>> index f251521..3b54c2c 100644
>>> --- a/drivers/thermal/step_wise.c
>>> +++ b/drivers/thermal/step_wise.c
>>> @@ -23,6 +23,7 @@
>>> */
>>>
>>> #include
>>> +#include
>>>
>>> #include "thermal_core.h"
>>>
>>> @@ -129,8 +130,10 @@ static void thermal_zone_trip_update(struct
>>> thermal_zone_device *tz, int trip)
>>>
>>> trend = get_tz_trend(tz, trip);
>>>
>>> -if (tz->temperature >= trip_temp)
>>> +if (tz->temperature >= trip_temp) {
>>> throttle = true;
>>> +trace_thermal_zone_trip(tz, trip, trip_type);
>>> +}
>>>
>>> dev_dbg(&tz->device, "Trip%d[type=%d,temp=%ld]:trend=%d,throttle=%d\n",
>>> trip, trip_type, trip_temp, trend, throttle);
>>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_
Re: [PATCH] thermal: Bind cooling devices with the correct arguments
Punit, On Tue, Jun 3, 2014 at 5:59 AM, Punit Agrawal wrote: > When binding cooling devices to thermal zones created from the device > tree the minimum and maximum cooling states are in the wrong order > leading to failure to bind. > > Fix the order of cooling states in the call to > thermal_zone_bind_cooling_device to fix this. > > Cc:Zhang Rui Acked-by: Eduardo Valentin Rui, to avoid further delays, can you please pick this one directly? > Signed-off-by: Punit Agrawal > --- > Hi Eduardo, > > I am hoping this can be picked up for 3.16 as a bug fix. > > Thanks, > Punit > > drivers/thermal/of-thermal.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c > index 04b1be7..97d312f 100644 > --- a/drivers/thermal/of-thermal.c > +++ b/drivers/thermal/of-thermal.c > @@ -156,8 +156,8 @@ static int of_thermal_bind(struct thermal_zone_device > *thermal, > > ret = thermal_zone_bind_cooling_device(thermal, > tbp->trip_id, cdev, > - tbp->min, > - tbp->max); > + tbp->max, > + tbp->min); > if (ret) > return ret; > } > -- > 1.7.10.4 > -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] acpi: fan.c: printk replacement
Hello Sudip,
On Thu, Aug 28, 2014 at 7:33 AM, Sudip Mukherjee
wrote:
> printk replaced with corresponding dev_err and dev_info
> fixed one broken user-visible string
> multiine comment edited for correct commenting style
> asm/uaccess.h replaced with linux/uaccess.h
> PREFIX removed
>
Just a minor tip. When sending a new version of your patches do not
use the RESEND prefix in you subject line. RESEND means you did not
make changes on your patches and you are just resending it because,
for instance, people did not answer it. When you modify your changes
after, say updating it due to review comments, it is a good practice
to use 'vX' prefix, so those who are following the patch will
understand that this patch has something new from previous version. In
this case, I suppose the current patch should be '[PATCH v2]' instead
of [PATCH][RESEND].
BR,
> Signed-off-by: Sudip Mukherjee
> ---
>
> modified with reference to the discussion at
> https://lkml.org/lkml/2014/8/22/176
>
> drivers/acpi/fan.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> index 8acf53e..5328b10 100644
> --- a/drivers/acpi/fan.c
> +++ b/drivers/acpi/fan.c
> @@ -27,12 +27,10 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> -#define PREFIX "ACPI: "
> -
> #define ACPI_FAN_CLASS "fan"
> #define ACPI_FAN_FILE_STATE"state"
>
> @@ -127,8 +125,9 @@ static const struct thermal_cooling_device_ops
> fan_cooling_ops = {
> };
>
> /* --
> - Driver Interface
> -
> -- */
> + * Driver Interface
> + * --
> +*/
>
> static int acpi_fan_add(struct acpi_device *device)
> {
> @@ -143,7 +142,7 @@ static int acpi_fan_add(struct acpi_device *device)
>
> result = acpi_bus_update_power(device->handle, NULL);
> if (result) {
> - printk(KERN_ERR PREFIX "Setting initial power state\n");
> + dev_err(&device->dev, "Setting initial power state\n");
> goto end;
> }
>
> @@ -168,10 +167,9 @@ static int acpi_fan_add(struct acpi_device *device)
>&device->dev.kobj,
>"device");
> if (result)
> - dev_err(&device->dev, "Failed to create sysfs link "
> - "'device'\n");
> + dev_err(&device->dev, "Failed to create sysfs link
> 'device'\n");
>
> - printk(KERN_INFO PREFIX "%s [%s] (%s)\n",
> + dev_info(&device->dev, "ACPI: %s [%s] (%s)\n",
>acpi_device_name(device), acpi_device_bid(device),
>!device->power.state ? "on" : "off");
>
> @@ -217,7 +215,7 @@ static int acpi_fan_resume(struct device *dev)
>
> result = acpi_bus_update_power(to_acpi_device(dev)->handle, NULL);
> if (result)
> - printk(KERN_ERR PREFIX "Error updating fan power state\n");
> + dev_err(dev, "Error updating fan power state\n");
>
> return result;
> }
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] dt-bindings: document Rockchip thermal
Hello,
On Tue, Sep 9, 2014 at 9:02 PM, Zhang Rui wrote:
> On Tue, 2014-09-09 at 11:09 -0400, Eduardo Valentin wrote:
>> Hello
>>
>> On Tue, Sep 09, 2014 at 01:35:31PM +0200, Heiko Stübner wrote:
>> > Am Dienstag, 9. September 2014, 10:27:17 schrieb Zhang Rui:
>> > > On Thu, 2014-09-04 at 09:02 +0800, Caesar Wang wrote:
>> > > > 在 2014年09月03日 16:07, Heiko Stübner 写道:
>> > > > > Am Mittwoch, 3. September 2014, 10:10:37 schrieb Caesar Wang:
>> > > > >> This add the necessary binding documentation for the thermal
>> > > > >> found on Rockchip SoCs
>> > > > >>
>> > > > >> Signed-off-by: zhaoyifeng
>> > > > >> Signed-off-by: Caesar Wang
>> > > > >> ---
>> > > > >>
>> > > > >> .../devicetree/bindings/thermal/rockchip-thermal.txt | 20
>> > > > >>
>> > > > >> 1 file changed, 20 insertions(+)
>> > > > >>
>> > > > >> create mode 100644
>> > > > >>
>> > > > >> Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
>> > > > >>
>> > > > >> diff --git
>> > > > >> a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
>> > > > >> b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt new
>> > > > >> file
>> > > > >> mode 100644
>> > > > >> index 000..1ed4d4c
>> > > > >> --- /dev/null
>> > > > >> +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
>> > > > >> @@ -0,0 +1,20 @@
>> > > > >> +* Temperature Sensor ADC (TSADC) on rockchip SoCs
>> > > > >> +
>> > > > >> +Required properties:
>> > > > >> +- compatible: "rockchip,rk3288-tsadc"
>> > > > >> +- reg: physical base address of the controller and length of memory
>> > > > >> mapped
>> > > > >> + region.
>> > > > >> +- interrupts: The interrupt number to the cpu. The interrupt
>> > > > >> specifier
>> > > > >> format + depends on the interrupt controller.
>> > > > >> +- clocks: Must contain an entry for each entry in clock-names.
>> > > > >> +- clock-names: Shall be "tsadc" for the converter-clock, and
>> > > > >> "apb_pclk" for +the peripheral clock.
>> > > > >
>> > > > > You're using the passive-temp, critical-temp and force-shut-temp
>> > > > > properties in your driver without declaring them here.
>> > > >
>> > > > frankly,the about are need be declared. but there are 4 types[0] for
>> > > > trip in thermal framework,
>> > > > there is no force-shut for me. So I want to change it three additional
>> > > > properties in [PATCH V4 4/4],
>> > > >
>> > > >
>> > > > [0]
>> > > > {
>> > > >
>> > > > THERMAL_TRIP_CRITICAL,
>> > > > THERMAL_TRIP_HOT,
>> > > > THERMAL_TRIP_PASSIVE,
>> > > > THERMAL_TRIP_ACTIVE,
>> > > >
>> > > > }
>> > >
>> > > this sounds reasonable to me.
>> > >
>> > > > > But more importantly, please use the generic trip-points for this. I
>> > > > > guess it shouldn't be a problem to introduce a "forced-shutdown"
>> > > > > trippoint [0] for the additional trip-point you have - thermal
>> > > > > maintainers, please shout if I'm wrong :-)
>> > >
>> > > what is the difference between a critical trip point and a
>> > > "forced-shutdown" trip point?
>> > > Thermal core will do a shutdown in case the critical trip point is
>> > > triggered.
>> >
>> > The forced-shutdown is where the thermal controller is supposed to also do
>> > a
>>
>> Currently, there is no discrimination between hardware configured /
>> triggered thermal shutdown and software detected / triggered thermal
>> shutdown.
>> One way to implement it though is to reuse the critical trip type. Even
>> if you use more than one trip type it is doable, it will depend on the
>> priorities you give to software triggered and hardware triggered.
>>
>> > shutdown in hardware. As you said the thermal core will also shutdown at
>> > the
>> > critical trip point, I guess we could map Caesar's value like
>> >
>> > trip-point tsadc
>> > criticalforced-shutdown (the 120 degrees in patch 4)
>>
>> > hot critical (the 100 degrees)
>> > ...
>> >
>> >
>>
>> In the case we are planing to expand the trip type range, adding one
>> specific to hardware configurable shutdown makes sense to me too.
> hmmm, why? you don't want an orderly shutdown? I still do not understand
> why we need a hardware shutdown trip point.
> Say, if we expect the system to be shutdown at 100C, I don't think we
> have a chance to trigger the hardware shutdown trip point.
> Further more, if my understanding is right, thermal core won't do
> anything for the hardware shutdown trip point because the system will be
> shutdown automatically, right? If this is true, why bother introducing
> this to thermal core?
>
Some ICs allow configuring the temperature when the shutdown will
happen. That is, you setup in registers the thermal shutdown
threshold, and one of the output pin of the IC is wired to, say, the
processor reset pin. Some other ICs have the threshold hardwired, and
cannot be configured.
Those options are a last chance to avoid processors to burn, in case
software really gets s
Re: [PATCH] tools/thermal: fix calloc argument ordering
Hello,
On Mon, Aug 18, 2014 at 5:33 AM, Arjun Sreedharan wrote:
> @number first, @size second argument
>
> Signed-off-by: Arjun Sreedharan
Acked-by: Eduardo Valentin
> ---
> tools/thermal/tmon/sysfs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/thermal/tmon/sysfs.c b/tools/thermal/tmon/sysfs.c
> index dfe4548..1c12536 100644
> --- a/tools/thermal/tmon/sysfs.c
> +++ b/tools/thermal/tmon/sysfs.c
> @@ -446,7 +446,7 @@ int probe_thermal_sysfs(void)
> return -1;
> }
>
> - ptdata.tzi = calloc(sizeof(struct tz_info), ptdata.max_tz_instance+1);
> + ptdata.tzi = calloc(ptdata.max_tz_instance+1, sizeof(struct tz_info));
> if (!ptdata.tzi) {
> fprintf(stderr, "Err: allocate tz_info\n");
> return -1;
> @@ -454,8 +454,8 @@ int probe_thermal_sysfs(void)
>
> /* we still show thermal zone information if there is no cdev */
> if (ptdata.nr_cooling_dev) {
> - ptdata.cdi = calloc(sizeof(struct cdev_info),
> - ptdata.max_cdev_instance + 1);
> + ptdata.cdi = calloc(ptdata.max_cdev_instance + 1,
> + sizeof(struct cdev_info));
> if (!ptdata.cdi) {
> free(ptdata.tzi);
> fprintf(stderr, "Err: allocate cdev_info\n");
> --
> 1.8.1.msysgit.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
Amit,
On Tue, Aug 19, 2014 at 8:07 AM, Chanwoo Choi wrote:
> This patch add support for TRIM_RELOAD feature at Exynos3250. The TMU of
> Exynos3250 has two TRIMINFO_CON register.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> Cc: Zhang Rui
> Cc: Eduardo Valentin
What do you think about this patch?
> ---
> Changes from v1:
> - Add missing 'TMU_SUPPORT_TRIM_RELOAD' features
>
> drivers/thermal/samsung/exynos_tmu.c | 7 +--
> drivers/thermal/samsung/exynos_tmu.h | 5 +++--
> drivers/thermal/samsung/exynos_tmu_data.c | 11 +--
> drivers/thermal/samsung/exynos_tmu_data.h | 7 +--
> 4 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index acbff14..ed01606 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -164,8 +164,11 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> }
> }
>
> - if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
> - __raw_writel(1, data->base + reg->triminfo_ctrl);
> + if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) {
> + for (i = 0; i < pdata->triminfo_reload_count; i++)
> + __raw_writel(pdata->triminfo_reload[i],
> + data->base + reg->triminfo_ctrl[i]);
> + }
>
> if (pdata->cal_mode == HW_MODE)
> goto skip_calib_data;
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index 1b4a644..72cb54e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -151,8 +151,7 @@ struct exynos_tmu_registers {
> u32 triminfo_25_shift;
> u32 triminfo_85_shift;
>
> - u32 triminfo_ctrl;
> - u32 triminfo_ctrl1;
> + u32 triminfo_ctrl[2];
> u32 triminfo_reload_shift;
>
> u32 tmu_ctrl;
> @@ -295,6 +294,8 @@ struct exynos_tmu_platform_data {
> u8 second_point_trim;
> u8 default_temp_offset;
> u8 test_mux;
> + u8 triminfo_reload[2];
> + u8 triminfo_reload_count;
>
> enum calibration_type cal_type;
> enum calibration_mode cal_mode;
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index aa8e0de..b45aa90 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -95,6 +95,8 @@ static const struct exynos_tmu_registers
> exynos3250_tmu_registers = {
> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> + .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON1,
> + .triminfo_ctrl[1] = EXYNOS_TMU_TRIMINFO_CON2,
> .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> @@ -160,8 +162,11 @@ static const struct exynos_tmu_registers
> exynos3250_tmu_registers = {
> .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> + .triminfo_reload[0] = 0x1, \
> + .triminfo_reload[1] = 0x11, \
> + .triminfo_reload_count = 2, \
> .registers = &exynos3250_tmu_registers, \
> - .features = (TMU_SUPPORT_EMULATION | \
> + .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD\
> TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS |
> \
> TMU_SUPPORT_EMUL_TIME)
> #endif
> @@ -184,7 +189,7 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> - .triminfo_ctrl = EXYNOS_TMU_TRIMINFO_CON,
> + .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON2,
> .triminfo_reload_shift = EXYNOS_TRIMINFO_RELOAD_SHIFT,
> .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> @@ -252,6 +257,8 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> + .triminfo_reload[0] = 0x1, \
> + .triminfo_reload_count = 1, \
> .registers = &exynos4412_tmu_registers, \
> .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
> TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS |
> \
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
> b/drivers/thermal/samsung/exynos_tmu_data.h
> index f0979e5..e0536c3 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.h
> +++ b/drivers/thermal/samsung/exynos_tmu_data.h
> @@ -57,8 +57,11 @@
> #define EXYNOS4
Re: [RFC PATCH v5 05/10] thermal: let governors have private data for each thermal zone
Javi,
On Thu, Jul 10, 2014 at 10:18 AM, Javi Merino wrote:
> A governor may need to store its current state between calls to
> throttle(). That state depends on the thermal zone, so store it as
> private data in struct thermal_zone_device.
>
> The governors may have two new ops: bind_to_tz() and unbind_from_tz().
> When provided, these functions let governors do some initialization
> and teardown when they are bound/unbound to a tz and possibly store that
> information in the governor_data field of the struct
> thermal_zone_device.
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Signed-off-by: Javi Merino
> ---
> drivers/thermal/thermal_core.c | 83
> ++
> include/linux/thermal.h| 9 +
> 2 files changed, 84 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 71b0ec0c370d..3da99dd80ad5 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -72,6 +72,58 @@ static struct thermal_governor *__find_governor(const char
> *name)
> return NULL;
> }
>
> +/**
> + * bind_previous_governor() - bind the previous governor of the thermal zone
> + * @tz:a valid pointer to a struct thermal_zone_device
> + * @failed_gov_name: the name of the governor that failed to register
> + *
> + * Register the previous governor of the thermal zone after a new
> + * governor has failed to be bound.
> + */
> +static void bind_previous_governor(struct thermal_zone_device *tz,
> + const char *failed_gov_name)
> +{
> + if (tz->governor && tz->governor->bind_to_tz) {
> + if (tz->governor->bind_to_tz(tz)) {
> + dev_warn(&tz->device,
> + "governor %s failed to bind and the previous
> one (%s) failed to register again, thermal zone %s has no governor\n",
> + failed_gov_name, tz->governor->name,
> tz->type);
The above must be a dev_err(), not warn. Besides, I would prefer if
you could improve the message. What is the difference between register
and bind?
> + tz->governor = NULL;
> + }
> + }
> +}
> +
> +/**
> + * thermal_set_governor() - Switch to another governor
> + * @tz:a valid pointer to a struct thermal_zone_device
> + * @new_gov: pointer to the new governor
> + *
> + * Change the governor of thermal zone @tz.
> + *
> + * Return: 0 on success, an error if the new governor's bind_to_tz() failed.
> + */
> +static int thermal_set_governor(struct thermal_zone_device *tz,
> + struct thermal_governor *new_gov)
> +{
> + int ret = 0;
> +
> + if (tz->governor && tz->governor->unbind_from_tz)
> + tz->governor->unbind_from_tz(tz);
> +
> + if (new_gov && new_gov->bind_to_tz) {
> + ret = new_gov->bind_to_tz(tz);
> + if (ret) {
> + bind_previous_governor(tz, new_gov->name);
> +
> + return ret;
> + }
> + }
> +
> + tz->governor = new_gov;
> +
> + return ret;
> +}
> +
> int thermal_register_governor(struct thermal_governor *governor)
> {
> int err;
> @@ -104,8 +156,15 @@ int thermal_register_governor(struct thermal_governor
> *governor)
>
> name = pos->tzp->governor_name;
>
> - if (!strnicmp(name, governor->name, THERMAL_NAME_LENGTH))
> - pos->governor = governor;
> + if (!strnicmp(name, governor->name, THERMAL_NAME_LENGTH)) {
> + int ret;
> +
> + ret = thermal_set_governor(pos, governor);
> + if (ret)
> + dev_warn(&pos->device,
> + "Failed to set governor %s for
> thermal zone %s: %d\n",
> + governor->name, pos->type, ret);
dev_err here too.
> + }
> }
>
> mutex_unlock(&thermal_list_lock);
> @@ -131,7 +190,7 @@ void thermal_unregister_governor(struct thermal_governor
> *governor)
> list_for_each_entry(pos, &thermal_tz_list, node) {
> if (!strnicmp(pos->governor->name, governor->name,
> THERMAL_NAME_LENGTH))
> - pos->governor = NULL;
> + thermal_set_governor(pos, NULL);
> }
>
> mutex_unlock(&thermal_list_lock);
> @@ -756,8 +815,9 @@ policy_store(struct device *dev, struct device_attribute
> *attr,
> if (!gov)
> goto exit;
>
> - tz->governor = gov;
> - ret = count;
> + ret = thermal_set_governor(tz, gov);
> + if (!ret)
> + ret = count;
>
> exit:
> mutex_unlock(&thermal_governor_lock);
> @@ -1452,6 +1512,7 @@ struct thermal_zone_device
> *therma
Re: [PATCH v4 4/4] thermal: Add Tegra SOCTHERM thermal management driver
Juha-Matti, moro,
On Tue, Aug 19, 2014 at 10:09 AM, Juha-Matti Tilli
wrote:
>> This adds support for the Tegra SOCTHERM thermal sensing and management
>> system found in the Tegra124 system-on-chip. This initial driver supports
>> temperature polling for four thermal zones.
>
> I have several comments about this patch. Overall, the code looks clean,
> way cleaner than NVIDIA's internal soc_therm driver. I adopted your code
> to run on the internal firmware of a Tegra124 SoC. Additionally, I
> tested the code as-is on a Jetson TK1.
Thanks for the testing effort!
>
> My test shows that the temperature readings look sane and do vary with
> load, so the code seems to work. However, I have some concerns about the
> calibration values calculated by this code and the error handling of the
> code.
>
> Originally, I thought the fuse offsets were incorrect but as it turns
> out, the official Linux kernel starts counting the fuses at a different
> location than NVIDIA's internal kernel.
>
This is a major concern. Juha-Matti and Mikko, can you please cross
check if this driver is accessing to the correct fuse register
location?
> [snip]
>> +static int calculate_shared_calibration(struct tsensor_shared_calibration
>> *r)
>> +{
>> + u32 val;
>> + u32 shifted_cp, shifted_ft;
>> + int err;
>> +
>> + err = tegra_fuse_readl(FUSE_TSENSOR8_CALIB, &val);
>> + if (err)
>> + return err;
>> + r->base_cp = val & FUSE_TSENSOR8_CALIB_CP_TS_BASE_MASK;
>> + r->base_ft = (val & FUSE_TSENSOR8_CALIB_FT_TS_BASE_MASK)
>> + >> FUSE_TSENSOR8_CALIB_FT_TS_BASE_SHIFT;
>> +
>> + err = tegra_fuse_readl(FUSE_SPARE_REALIGNMENT_REG_0, &val);
>> + if (err)
>> + return err;
>> + shifted_cp = sign_extend32(val, 5);
>> + val = ((val & FUSE_SPARE_REALIGNMENT_REG_SHIFT_FT_MASK)
>> + >> FUSE_SPARE_REALIGNMENT_REG_SHIFT_FT_SHIFT);
>> + shifted_ft = sign_extend32(val, 4);
>> +
>> + r->actual_temp_cp = 2 * NOMINAL_CALIB_CP_T124 + shifted_cp;
>> + r->actual_temp_ft = 2 * NOMINAL_CALIB_FT_T124 + shifted_ft;
>> +
>> + return 0;
>> +}
>> +
>> +static int calculate_tsensor_calibration(
>> + struct tegra_tsensor *sensor,
>> + struct tsensor_shared_calibration shared,
>> + u32 *calib
>> +)
>> +{
>> + u32 val;
>> + s32 actual_tsensor_ft, actual_tsensor_cp;
>> + s32 delta_sens, delta_temp;
>> + s32 mult, div;
>> + s16 therma, thermb;
>> + int err;
>> +
>> + err = tegra_fuse_readl(sensor->calib_fuse_offset, &val);
>> + if (err)
>> + return err;
>> +
>> + actual_tsensor_cp = (shared.base_cp * 64) + sign_extend32(val, 12);
>> + val = (val & FUSE_TSENSOR_CALIB_FT_TS_BASE_MASK)
>> + >> FUSE_TSENSOR_CALIB_FT_TS_BASE_SHIFT;
>> + actual_tsensor_ft = (shared.base_ft * 32) + sign_extend32(val, 12);
>> +
>> + delta_sens = actual_tsensor_ft - actual_tsensor_cp;
>> + delta_temp = shared.actual_temp_ft - shared.actual_temp_cp;
>> +
>> + mult = t124_tsensor_config.pdiv * t124_tsensor_config.tsample_ate;
>> + div = t124_tsensor_config.tsample * t124_tsensor_config.pdiv_ate;
>> +
>> + therma = div_s64((s64) delta_temp * (1LL << 13) * mult,
>> + (s64) delta_sens * div);
>> + thermb = div_s64(((s64) actual_tsensor_ft * shared.actual_temp_cp) -
>> + ((s64) actual_tsensor_cp * shared.actual_temp_ft),
>> + (s64) delta_sens);
>> +
>> + therma = div_s64((s64) therma * sensor->fuse_corr_alpha,
>> + (s64) 100LL);
>> + thermb = div_s64((s64) thermb * sensor->fuse_corr_alpha +
>> + sensor->fuse_corr_beta,
>> + (s64) 100LL);
>> +
>> + *calib = ((u16)(therma) << SENSOR_CONFIG2_THERMA_SHIFT) |
>> + ((u16)thermb << SENSOR_CONFIG2_THERMB_SHIFT);
>> +
>> + return 0;
>> +}
>> +
>> +static int enable_tsensor(struct tegra_soctherm *tegra,
>> + struct tegra_tsensor *sensor,
>> + struct tsensor_shared_calibration shared)
>> +{
>> + void * __iomem base = tegra->regs + sensor->base;
>> + unsigned int val;
>> + u32 calib;
>> + int err;
>> +
>> + err = calculate_tsensor_calibration(sensor, shared, &calib);
>> + if (err)
>> + return err;
>> +
>> + val = 0;
>> + val |= t124_tsensor_config.tall << SENSOR_CONFIG0_TALL_SHIFT;
>> + writel(val, base + SENSOR_CONFIG0);
>> +
>> + val = 0;
>> + val |= (t124_tsensor_config.tsample - 1) <<
>> + SENSOR_CONFIG1_TSAMPLE_SHIFT;
>> + val |= t124_tsensor_config.tiddq_en << SENSOR_CONFIG1_TIDDQ_EN_SHIFT;
>> + val |= t124_tsensor_config.ten_count << SENSOR_CONFIG1_TEN_COUNT_SHIFT;
>> + val |= SENSOR_CONFIG1_TEMP_ENABLE;
>> + writel(val, base + SENSOR_CONFIG1);
>> +
>> + writel(calib, base + SENSOR_CONFIG2);
>> +
>> + return 0;
>> +}
>
> This code writes different values to SENSOR_CONFIG2 registers than what
> the NVIDIA's int
Re: [PATCHv3] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
Hello Chanwoo,
On Tue, Aug 19, 2014 at 7:52 PM, Chanwoo Choi wrote:
> This patch add support for TRIM_RELOAD feature at Exynos3250. The TMU of
> Exynos3250 has two TRIMINFO_CON register.
Can you please split the two changes above into two patches? Meaning,
one that adds TRIMINFO_CON2 and another that adds TRIM_RELOAD?
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Amit Daniel Kachhap
> ---
> Changes from v2:
> - Fix build break because of missing 'or' operation.
> Changes from v1:
> - Add missing 'TMU_SUPPORT_TRIM_RELOAD' feature
>
> drivers/thermal/samsung/exynos_tmu.c | 7 +--
> drivers/thermal/samsung/exynos_tmu.h | 5 +++--
> drivers/thermal/samsung/exynos_tmu_data.c | 11 +--
> drivers/thermal/samsung/exynos_tmu_data.h | 7 +--
> 4 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index acbff14..ed01606 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -164,8 +164,11 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> }
> }
>
> - if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
> - __raw_writel(1, data->base + reg->triminfo_ctrl);
> + if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) {
> + for (i = 0; i < pdata->triminfo_reload_count; i++)
> + __raw_writel(pdata->triminfo_reload[i],
> + data->base + reg->triminfo_ctrl[i]);
> + }
What is the logic behind the trim reload feature? Which SoCs support it?
>
> if (pdata->cal_mode == HW_MODE)
> goto skip_calib_data;
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index 1b4a644..72cb54e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -151,8 +151,7 @@ struct exynos_tmu_registers {
> u32 triminfo_25_shift;
> u32 triminfo_85_shift;
>
> - u32 triminfo_ctrl;
> - u32 triminfo_ctrl1;
> + u32 triminfo_ctrl[2];
The above change needs to be documented.
> u32 triminfo_reload_shift;
>
> u32 tmu_ctrl;
> @@ -295,6 +294,8 @@ struct exynos_tmu_platform_data {
> u8 second_point_trim;
> u8 default_temp_offset;
> u8 test_mux;
> + u8 triminfo_reload[2];
> + u8 triminfo_reload_count;
>
The above addition needs to be documented too.
> enum calibration_type cal_type;
> enum calibration_mode cal_mode;
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index aa8e0de..8cd609c 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -95,6 +95,8 @@ static const struct exynos_tmu_registers
> exynos3250_tmu_registers = {
> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> + .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON1,
> + .triminfo_ctrl[1] = EXYNOS_TMU_TRIMINFO_CON2,
> .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> @@ -160,8 +162,11 @@ static const struct exynos_tmu_registers
> exynos3250_tmu_registers = {
> .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> + .triminfo_reload[0] = 0x1, \
> + .triminfo_reload[1] = 0x11, \
What does 0x1 mean? How about 0x11?
> + .triminfo_reload_count = 2, \
What is count?
> .registers = &exynos3250_tmu_registers, \
> - .features = (TMU_SUPPORT_EMULATION | \
> + .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
> TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS |
> \
> TMU_SUPPORT_EMUL_TIME)
> #endif
> @@ -184,7 +189,7 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> - .triminfo_ctrl = EXYNOS_TMU_TRIMINFO_CON,
> + .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON2,
> .triminfo_reload_shift = EXYNOS_TRIMINFO_RELOAD_SHIFT,
> .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> @@ -252,6 +257,8 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> + .triminfo_reload[0] = 0x1, \
> + .triminfo_reload_count = 1, \
Your patch description says nothing about TRIM_RELOAD
Re: [PATCH v3 3/4] thermal: add more description for thermal-zones
Hello Wei, On Thu, Aug 28, 2014 at 11:03 PM, Wei Ni wrote: > On 08/28/2014 09:21 PM, Eduardo Valentin wrote: >> Hello Wei, >> >> On Thu, Aug 28, 2014 at 09:50:01AM +0800, Wei Ni wrote: >>> On 08/27/2014 09:32 PM, Eduardo Valentin wrote: Hello Wei, On Wed, Aug 27, 2014 at 10:54:07AM +0800, Wei Ni wrote: > On 08/26/2014 08:12 PM, Eduardo Valentin wrote: >> On Tue, Aug 26, 2014 at 10:17:29AM +0800, Wei Ni wrote: >>> On 08/25/2014 07:07 PM, Eduardo Valentin wrote: Hello Wei Ni, On Mon, Aug 25, 2014 at 02:29:47PM +0800, Wei Ni wrote: > Add more description for the "polling-delay" property. > Set "trips" and "cooling maps" as optional property, because > if missing these two sub-nodes, the thermal zone device still > work properly. > > Signed-off-by: Wei Ni > --- > Documentation/devicetree/bindings/thermal/thermal.txt | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt > b/Documentation/devicetree/bindings/thermal/thermal.txt > index f5db6b7..e3d3ed9 100644 > --- a/Documentation/devicetree/bindings/thermal/thermal.txt > +++ b/Documentation/devicetree/bindings/thermal/thermal.txt > @@ -136,8 +136,8 @@ containing trip nodes and one sub-node containing > all the zone cooling maps. > > Required properties: > - polling-delay: The maximum number of milliseconds to wait > between polls > - Type: unsigned when checking this thermal zone. > - Size: one cell > + Type: unsigned when checking this thermal zone. If this value > is 0, the > + Size: one cell driver will not run polling queue, but just > cancel it. > The description above is specific to Linux kernel implementation nomenclature. DT description needs to be OS agnostic. > - polling-delay-passive: The maximum number of milliseconds to wait >Type: unsigned between polls when performing passive cooling. > @@ -148,14 +148,16 @@ Required properties: >phandles + sensor >specifier > > +Optional property: > - trips: A sub-node which is a container of only trip > point nodes >Type: sub-node required to describe the thermal zone. > > - cooling-maps: A sub-node which is a container of > only cooling device >Type: sub-node map nodes, used to describe the relation > between trips > - and cooling devices. > + and cooling devices. If missing the "trips" > property, > + This sub-node will not be parsed, because no > trips can > + be bound to cooling devices. Do you mean if the thermal zone misses the "trips" property? Actually, the binding describes both, cooling-maps and trips, as required properties. Thus, both needs to be in place to consider the thermal zone as a proper described zone. >>> >>> I moved the "trips" and "cooling-maps" to optional property, because if >>> missing these two properties, the thermal zone devices still can be >>> registered, and the driver can work properly, it has the basic function, >>> can read temperature from thermal sysfs, although it doesn't have trips >>> and bind with cooling devices. >> >> >> If a thermal zone is used only for monitoring, then I believe it lost >> its purpose. As Maybe a different framework shall be used, such as >> hwmon, >> for instance? > > Yes, if we only use it for monitoring, we can use hwmon. But we have > more functions base on these two thermal zone devices. We have a > skin-temperature driver, which used nct1008's remote and local > temperatures to estimator the skin temperature. As you know the thermal > framework is more powerful, the remote/local sensors can be register as > thermal zone, then the skin-temp driver can use thermal_zone_get_temp() > to read their temperatures and then estimator skin's temp. We also will > set trips and cooling devices for this skin-temp. In this case, don't you think it would make sense to create a thermal zone for the skin temperature and add the required sensors (including the nct1008) in it? >>> >>> Hi, Eduardo >>> Yes, we will create a thermal zone for the skin-temp driver and add the >>> required sensors in it, but in here we want to register these required >>> sensors as thermal zone devices, then the thermal framework can export >>> functions to read these sensors temperat
Re: Re: [PATCH v3 1/4] thermal: rockchip: add driver for thermal
Hello Zhao, On Thu, Aug 28, 2014 at 9:54 PM, 赵仪峰 wrote: > Hi Heiko， > >The TS-ADC on RK3288 has two component, a tsadc and a tsadc controller. > The tsadc controller is similar like the thermal manager unit on other SOCs. > We followed the naming of 3066, but not named as the Thermal Manager. > >Moreover,there is only one set of apb registers to access the tsadc > controller,and the tsadc is controlled by the tsadc controller,could not > access directly. If we write a general tsadc driver by accessed tsadc > controller registers, and it hardly to write a driver for the tsadc > controller. As suggested by Arnd, you can use the generic driver as interface between thermal framework and IIO layer. The driver you are going to write to your ADC is going to be in the IIO subsystem. The only difference is that the generic driver would work for any ADC driver in the IIO subsystem. https://lkml.org/lkml/2014/2/5/810 In fact, there is already a generic driver. We just need to get it up to date. I see some testing has been already done, and results sound promising. > >So, I do not agree to write a generic adc driver for the rk3288-tsadc. > > > Yifeng Zhao > > 发件人： HeikoStübner > 发送时间： 2014-08-29 00:11 > 收件人： Eduardo Valentin > 抄送： Arnd Bergmann; Caesar Wang; rui.zhang; grant.likely; robh+dt; > linux-kernel; linux-pm; linux-arm-kernel; devicetree; linux-doc; huangtao; > cf; dianders; dtor; zyw; addy.ke; dmitry.torokhov; zhaoyifeng; linux-iio; > Jonathan Cameron > 主题： Re: [PATCH v3 1/4] thermal: rockchip: add driver for thermal > > Am Donnerstag, 28. August 2014, 10:37:35 schrieb Eduardo Valentin: >> Ceasar and Arnd, >> >> On Thu, Aug 28, 2014 at 10:48:23AM +0200, Arnd Bergmann wrote: >> > On Thursday 28 August 2014 08:59:19 Caesar Wang wrote: >> > > Thermal is TS-ADC Controller module supports user-defined mode and >> > > automatic mode. >> > > >> > > User-defined mode refers,TSADC all the control signals entirely by >> > > software >> > > writing to register for direct control. >> > > >> > > Automaic mode refers to the module automatically poll TSADC output,and >> > > the results Were checked. >> > > >> > > If you find that the temperature High in a period of time, an >> > > interrupt >> > > is generated to the processor down-measures taken;if the temperature >> > > over a period of time High, the resulting TSHUT gave CRU module,let it >> > > reset the entire chip, or via GPIO give PMIC. >> > > >> > > Signed-off-by: zhaoyifeng >> > > Signed-off-by: Caesar Wang >> > >> > Hi Caesar, >> > >> > After looking at the driver (last time I only received the patch for >> > the binding), I have a more general comment: >> > >> > This looks like a general-purpose ADC device, not an IP block that is >> > specific to thermal management. The binding looks ok for that purpose >> > but should probably be moved into >> > Documentation/devicetree/bindings/iio/adc/ as a minor change. >> >> I agree with Arnd's point here. It makes sense to me to have this driver >> under the IIO umbrella. > > interesting suggestion :-) > > I've just taken another look at the registers of the ts-adc on the rk3066 > which is completely different from the rk3288 one. Interestingly the rk3066 > one > is "just" another saradc IP, so for this one it would really make sense. > > >> > On the driver side, I believe the correct way to deal with this setup >> > is to split your driver into a generic drivers/iio/adc/rockchips-tsadc.c >> > file, and a smaller thermal driver that uses the iio in-kernel >> > interfaces, >> > ideally one that is independent of the underlying hardware and can >> > work on any ADC implementation. >> >> Agreed. If you can write such interface and make your driver to work in >> such way, that would be great. > > But I currently don't see how you would model the temperature handling parts > from a generic thermal driver to a generic adc driver for the rk3288-tsadc. > > I guess the general temperature irq handling would use iio-triggers? But how > does the target temperature get into the TSADC_COMP1_INT register. > > Also when getting the temperature, Caesar's driver compares it to its trip > points and sets the next trip point depending on the current temperature > (passive <-> critical) in rockchip_get_temp. > > Maybe there is some completely easy way for this, but currently I don't see > it. > > > Heiko > > -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/8] thermal: exynos: various cleanups
Amit On Mon, Sep 1, 2014 at 6:53 AM, amit daniel kachhap wrote: > On Thu, Aug 28, 2014 at 8:19 PM, Eduardo Valentin wrote: >> Amit, >> >> On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote: >>> Hi, >>> >>> This patch series contains various cleanups for EXYNOS thermal >>> driver. Overall it decreases driver's LOC by 9%. It is based >>> on next-20140731 kernel. It should not cause any functionality >>> changes. >>> >> >> Did you have the time to test this series? > > Hi Eduardo/Bartlomiej, > > For the whole series tested on exynos5250 based arndale board. > Tested-by: Amit Daniel Kachhap > Thanks! I will pull the series on my tree. > Sorry for the delay as I was busy in some internal work. > > Thanks, > Amit D >> >>> Changes since v2 (https://lkml.org/lkml/2014/6/17/436): >>> - synced patches against next-20140731 >>> - dropped patch "thermal: exynos: remove dead code for >>> TYPE_TWO_POINT_TRIMMING calibration" (newly added Exynos3250 >>> SoC support uses TYPE_TWO_POINT_TRIMMING calibration) >>> - updated patch description for patch #2 >>> - dropped Reviewed-by from Amit from patch #8 (due to changed >>> scope of the patch) >>> >>> Changes since v1 (https://lkml.org/lkml/2014/5/5/194): >>> - synced patches against next-20140617 >>> - merged patch "thermal: exynos: remove unused defines" into >>> "thermal: exynos: remove unused struct exynos_tmu_registers >>> entries" one (per request from Eduardo) >>> - improved patch descriptions for patches #1-5 >>> - fixed documentation for pdata->gain and pdata->reference_voltage >>> - added Reviewed-by from Amit to patches #6, #7 and #10 >>> - added missing Acked-by from Kyungmin Park >>> >>> Best regards, >>> -- >>> Bartlomiej Zolnierkiewicz >>> Samsung R&D Institute Poland >>> Samsung Electronics >>> >>> >>> Bartlomiej Zolnierkiewicz (8): >>> thermal: exynos: remove unused struct exynos_tmu_registers entries >>> thermal: exynos: remove dead code for HW_MODE calibration >>> thermal: exynos: remove redundant pdata checks from >>> exynos_tmu_initialize() >>> thermal: exynos: remove redundant threshold_code checks from >>> exynos_tmu_initialize() >>> thermal: exynos: simplify temp_to_code() and code_to_temp() >>> thermal: exynos: cache non_hw_trigger_levels in pdata >>> thermal: exynos: remove redundant pdata checks from >>> exynos_tmu_control() >>> thermal: exynos: remove identical values from exynos*_tmu_registers >>> structures >>> >>> drivers/thermal/samsung/exynos_thermal_common.h | 1 - >>> drivers/thermal/samsung/exynos_tmu.c| 126 >>> +--- >>> drivers/thermal/samsung/exynos_tmu.h| 74 +- >>> drivers/thermal/samsung/exynos_tmu_data.c | 56 ++- >>> drivers/thermal/samsung/exynos_tmu_data.h | 31 +- >>> 5 files changed, 35 insertions(+), 253 deletions(-) >>> >>> -- >>> 1.8.2.3 >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] Thermal: imx: add i.mx6sx thermal support
Hello Anson,
On Wed, Aug 6, 2014 at 3:05 AM, anson.hu...@freescale.com
wrote:
> Sorry for leaving such warnings, I thought we did NOT care about the long
> line issue now, will fix them in V3 patch.
>
Lines over 80 columns are not an error of style. We simply suggest to
keep this. By now, I think it really depends on which subsystem you
are working with. I would prefer you keep this rule, as most of the
code inside the thermal framework follows it.
>
>
> Thanks Varka.
>
>
>
> Best regards!
>
> Anson Huang
>
>
>
> From: Varka Bhadram [mailto:varkabhad...@gmail.com]
> Sent: 2014-08-06 3:01 PM
> To: Huang Yongcai-B20788; edubez...@gmail.com; shawn@linaro.org;
> rui.zh...@intel.com
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH V2] Thermal: imx: add i.mx6sx thermal support
>
>
>
> On 08/06/2014 10:47 AM, Anson Huang wrote:
>
> i.MX6SX has some new features of thermal interrupt function,
>
> there are LOW, HIGH and PANIC irq for thermal sensor, so add
>
> platform data to separate different thermal version;
>
>
>
> The reset value of LOW ALARM is 0 which means the highest
>
> temp, so the LOW ALARM will be triggered once irq is enabled,
>
> so we need to correct it before enabling thermal irq;
>
>
>
> Enable PANIC ALARM as critical trip point, it will trigger
>
> system reset via SRC module once PANIC IRQ is triggered, it
>
> is pure hardware function, so use it instead of software
>
> reset by cooling device.
>
>
>
> Signed-off-by: Anson Huang
>
> ---
>
> .../devicetree/bindings/thermal/imx-thermal.txt|5 +-
>
> drivers/thermal/imx_thermal.c | 89
> +---
>
> 2 files changed, 80 insertions(+), 14 deletions(-)
>
>
>
> ./scripts/checkpatch.pl --show-types
> V2-Thermal-imx-add-i.mx6sx-thermal-support.patch
>
> WARNING:LONG_LINE: line over 80 characters
>
> #109: FILE: drivers/thermal/imx_thermal.c:185:
>
> +/* Update alarm value to next higher trip point, only TEMPMON_IMX6Q
> needs it */
>
>
>
> WARNING:LONG_LINE: line over 80 characters
>
> #111: FILE: drivers/thermal/imx_thermal.c:187:
>
> +if (data->alarm_temp == data->temp_passive && *temp >=
> data->temp_passive)
>
>
>
> WARNING:LONG_LINE: line over 80 characters
>
> #113: FILE: drivers/thermal/imx_thermal.c:189:
>
> +if (data->alarm_temp == data->temp_critical && *temp <
> data->temp_passive) {
>
>
>
> --
>
> Regards,
>
> Varka Bhadram.
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] Thermal: imx: add i.mx6sx thermal support
Hello again,
On Wed, Aug 6, 2014 at 8:56 AM, edubez...@gmail.com wrote:
> Hello Anson,
>
> On Wed, Aug 6, 2014 at 3:05 AM, anson.hu...@freescale.com
> wrote:
>> Sorry for leaving such warnings, I thought we did NOT care about the long
>> line issue now, will fix them in V3 patch.
>>
>
> Lines over 80 columns are not an error of style. We simply suggest to
> keep this. By now, I think it really depends on which subsystem you
> are working with. I would prefer you keep this rule, as most of the
> code inside the thermal framework follows it.
>
Let me put this straight, quoting the Kernel Documentation/CodingStyle:
75 Chapter 2: Breaking long lines and strings
76
77 Coding style is all about readability and maintainability using commonly
78 available tools.
79
80 The limit on the length of lines is 80 columns and this is a strongly
81 preferred limit.
82
83 Statements longer than 80 columns will be broken into sensible
chunks, unless
84 exceeding 80 columns significantly increases readability and does not hide
85 information. Descendants are always substantially shorter than the
parent and
86 are placed substantially to the right. The same applies to function headers
87 with a long argument list. However, never break user-visible strings such as
88 printk messages, because that breaks the ability to grep for them."
>>
>>
>> Thanks Varka.
>>
>>
>>
>> Best regards!
>>
>> Anson Huang
>>
>>
>>
>> From: Varka Bhadram [mailto:varkabhad...@gmail.com]
>> Sent: 2014-08-06 3:01 PM
>> To: Huang Yongcai-B20788; edubez...@gmail.com; shawn@linaro.org;
>> rui.zh...@intel.com
>> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> devicet...@vger.kernel.org
>> Subject: Re: [PATCH V2] Thermal: imx: add i.mx6sx thermal support
>>
>>
>>
>> On 08/06/2014 10:47 AM, Anson Huang wrote:
>>
>> i.MX6SX has some new features of thermal interrupt function,
>>
>> there are LOW, HIGH and PANIC irq for thermal sensor, so add
>>
>> platform data to separate different thermal version;
>>
>>
>>
>> The reset value of LOW ALARM is 0 which means the highest
>>
>> temp, so the LOW ALARM will be triggered once irq is enabled,
>>
>> so we need to correct it before enabling thermal irq;
>>
>>
>>
>> Enable PANIC ALARM as critical trip point, it will trigger
>>
>> system reset via SRC module once PANIC IRQ is triggered, it
>>
>> is pure hardware function, so use it instead of software
>>
>> reset by cooling device.
>>
>>
>>
>> Signed-off-by: Anson Huang
>>
>> ---
>>
>> .../devicetree/bindings/thermal/imx-thermal.txt|5 +-
>>
>> drivers/thermal/imx_thermal.c | 89
>> +---
>>
>> 2 files changed, 80 insertions(+), 14 deletions(-)
>>
>>
>>
>> ./scripts/checkpatch.pl --show-types
>> V2-Thermal-imx-add-i.mx6sx-thermal-support.patch
>>
>> WARNING:LONG_LINE: line over 80 characters
>>
>> #109: FILE: drivers/thermal/imx_thermal.c:185:
>>
>> +/* Update alarm value to next higher trip point, only TEMPMON_IMX6Q
>> needs it */
>>
>>
>>
>> WARNING:LONG_LINE: line over 80 characters
>>
>> #111: FILE: drivers/thermal/imx_thermal.c:187:
>>
>> +if (data->alarm_temp == data->temp_passive && *temp >=
>> data->temp_passive)
>>
>>
>>
>> WARNING:LONG_LINE: line over 80 characters
>>
>> #113: FILE: drivers/thermal/imx_thermal.c:189:
>>
>> +if (data->alarm_temp == data->temp_critical && *temp <
>> data->temp_passive) {
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Varka Bhadram.
>
>
>
> --
> Eduardo Bezerra Valentin
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] Thermal: imx: add i.mx6sx thermal support
Hello Anson,
On Wed, Aug 6, 2014 at 3:12 AM, Anson Huang wrote:
> i.MX6SX has some new features of thermal interrupt function,
> there are LOW, HIGH and PANIC irq for thermal sensor, so add
> platform data to separate different thermal version;
>
> The reset value of LOW ALARM is 0 which means the highest
> temp, so the LOW ALARM will be triggered once irq is enabled,
> so we need to correct it before enabling thermal irq;
>
> Enable PANIC ALARM as critical trip point, it will trigger
> system reset via SRC module once PANIC IRQ is triggered, it
> is pure hardware function, so use it instead of software
> reset by cooling device.
So far the patch is pretty much better now. Unfortunately, I do not
have a way to test it. Can you please check if some workmate of yours
can do a testing on both hardwares and send his/her tested-by?
>
> Signed-off-by: Anson Huang
> ---
> .../devicetree/bindings/thermal/imx-thermal.txt|5 +-
> drivers/thermal/imx_thermal.c | 91
> +---
> 2 files changed, 82 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> index 1f0f672..3c67bd5 100644
> --- a/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> @@ -1,7 +1,10 @@
> * Temperature Monitor (TEMPMON) on Freescale i.MX SoCs
>
> Required properties:
> -- compatible : "fsl,imx6q-thermal"
> +- compatible : "fsl,imx6q-tempmon" for i.MX6Q, "fsl,imx6sx-tempmon" for
> i.MX6SX.
> + i.MX6SX has two more IRQs than i.MX6Q, one is IRQ_LOW and the other is
> IRQ_PANIC,
> + when temperature is below than low threshold, IRQ_LOW will be triggered,
> when temperature
> + is higher than panic threshold, system will auto reboot by SRC module.
> - fsl,tempmon : phandle pointer to system controller that contains TEMPMON
>control registers, e.g. ANATOP on imx6q.
> - fsl,tempmon-data : phandle pointer to fuse controller that contains TEMPMON
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index 2c516f2..461bf3d 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -31,6 +32,11 @@
>
> #define MISC0 0x0150
> #define MISC0_REFTOP_SELBIASOFF(1 << 3)
> +#define MISC1 0x0160
> +#define MISC1_IRQ_TEMPHIGH (1 << 29)
> +/* Below LOW and PANIC bits are only for TEMPMON_IMX6SX */
> +#define MISC1_IRQ_TEMPLOW (1 << 28)
> +#define MISC1_IRQ_TEMPPANIC(1 << 27)
>
> #define TEMPSENSE0 0x0180
> #define TEMPSENSE0_ALARM_VALUE_SHIFT 20
> @@ -43,6 +49,12 @@
>
> #define TEMPSENSE1 0x0190
> #define TEMPSENSE1_MEASURE_FREQ0x
> +/* Below TEMPSENSE2 is only for TEMPMON_IMX6SX */
> +#define TEMPSENSE2 0x0290
> +#define TEMPSENSE2_LOW_VALUE_SHIFT 0
> +#define TEMPSENSE2_LOW_VALUE_MASK 0xfff
> +#define TEMPSENSE2_PANIC_VALUE_SHIFT 16
> +#define TEMPSENSE2_PANIC_VALUE_MASK0xfff
>
> #define OCOTP_ANA1 0x04e0
>
> @@ -66,6 +78,21 @@ enum imx_thermal_trip {
> #define FACTOR115976
> #define FACTOR24297157
>
> +#define TEMPMON_IMX6Q 1
> +#define TEMPMON_IMX6SX 2
> +
> +struct thermal_soc_data {
> + u32 version;
> +};
> +
> +static struct thermal_soc_data thermal_imx6q_data = {
> + .version = TEMPMON_IMX6Q,
> +};
> +
> +static struct thermal_soc_data thermal_imx6sx_data = {
> + .version = TEMPMON_IMX6SX,
> +};
> +
> struct imx_thermal_data {
> struct thermal_zone_device *tz;
> struct thermal_cooling_device *cdev;
> @@ -79,8 +106,21 @@ struct imx_thermal_data {
> bool irq_enabled;
> int irq;
> struct clk *thermal_clk;
> + const struct thermal_soc_data *socdata;
> };
>
> +static void imx_set_panic_temp(struct imx_thermal_data *data,
> + signed long panic_temp)
> +{
> + struct regmap *map = data->tempmon;
> + int critical_value;
> +
> + critical_value = (data->c2 - panic_temp) / data->c1;
> + regmap_write(map, TEMPSENSE2 + REG_CLR, TEMPSENSE2_PANIC_VALUE_MASK);
> + regmap_write(map, TEMPSENSE2 + REG_SET, critical_value <<
> + TEMPSENSE2_PANIC_VALUE_SHIFT);
> +}
> +
> static void imx_set_alarm_temp(struct imx_thermal_data *data,
>signed long alarm_temp)
> {
> @@ -142,13 +182,17 @@ static int imx_get_temp(struct thermal_zone_device *tz,
> unsigned long *temp)
> /* See imx_get_sensor_data() for formula derivation */
> *temp = data->c2 - n_meas * data
Re: How can I get trip index when get_trend is called ?
Hello Yang, I am copying the list, as others may have same questions. On Thu, Aug 7, 2014 at 7:07 PM, Hyungwoo Yang wrote: > > Hello, > > My trend calculation uses trip temperature. depending on how far current > temperature from trip point, trend is different. It worked fine but ,with DT > support from you, I cannot find a way to get trip index for trend > calculation. I am not sure how the rate of temperature can be dependent on trip temperature. Are you adding an artifact to, say, make the trend look increasing faster if it is closer to trip temperature? > > Could you help me to get this? why did you change interface ? what is the > alternative ? Well, I do not recall changing any interface with of-thermal. The DT support in fact adds interfaces. Side question, what driver are you dealing with? Is it already merged in the Linux Kernel mainline? > > Best Regard, > Hyungwoo Yang -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] Thermal: imx: add i.mx6sx thermal support
Hello Shawn, On Thu, Aug 7, 2014 at 4:50 AM, Shawn Guo wrote: > On Wed, Aug 06, 2014 at 03:12:09PM +0800, Anson Huang wrote: >> i.MX6SX has some new features of thermal interrupt function, >> there are LOW, HIGH and PANIC irq for thermal sensor, so add >> platform data to separate different thermal version; >> >> The reset value of LOW ALARM is 0 which means the highest >> temp, so the LOW ALARM will be triggered once irq is enabled, >> so we need to correct it before enabling thermal irq; >> >> Enable PANIC ALARM as critical trip point, it will trigger >> system reset via SRC module once PANIC IRQ is triggered, it >> is pure hardware function, so use it instead of software >> reset by cooling device. >> >> Signed-off-by: Anson Huang > > Tested-by: Shawn Guo Thanks! Did you have the chance to test on both? i.MX6Q and i.MX6SX? -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: fixed spelling of "celcius" to "celsius"
Hello Ankit,
On Sat, Aug 9, 2014 at 4:02 AM, Ankit wrote:
> Fixed spelling issue -- changed celcius to celsius
>
> Kernel version: mainline
>
> Signed-off-by: Ankit
On the thermal part,
Acked-by: Eduardo Valentin
but I think might be worth splitting the change per domain, so we
avoid merge conflicts. The change is just one liner though.
> ---
> drivers/gpu/drm/nouveau/core/engine/graph/nv10.c | 4 ++--
> drivers/gpu/drm/nouveau/core/engine/graph/nv20.c | 2 +-
> drivers/gpu/drm/nouveau/core/engine/graph/nv25.c | 2 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +-
> drivers/power/ds2780_battery.c| 2 +-
> drivers/power/ds2782_battery.c| 2 +-
> drivers/thermal/thermal_core.c| 2 +-
> 7 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv10.c
> b/drivers/gpu/drm/nouveau/core/engine/graph/nv10.c
> index 4532f7e..1faeeb1 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nv10.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nv10.c
> @@ -451,7 +451,7 @@ nv10_graph_sclass[] = {
> { 0x0093, &nv04_graph_ofuncs }, /* surf3d */
> { 0x0094, &nv04_graph_ofuncs }, /* ttri */
> { 0x0095, &nv04_graph_ofuncs }, /* mtri */
> - { 0x0056, &nv04_graph_ofuncs }, /* celcius */
> + { 0x0056, &nv04_graph_ofuncs }, /* celsius */
> {},
> };
>
> @@ -474,7 +474,7 @@ nv15_graph_sclass[] = {
> { 0x0093, &nv04_graph_ofuncs }, /* surf3d */
> { 0x0094, &nv04_graph_ofuncs }, /* ttri */
> { 0x0095, &nv04_graph_ofuncs }, /* mtri */
> - { 0x0096, &nv04_graph_ofuncs }, /* celcius */
> + { 0x0096, &nv04_graph_ofuncs }, /* celsius */
> {},
> };
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c
> b/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c
> index d145e08..eb00689 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c
> @@ -31,7 +31,7 @@ nv20_graph_sclass[] = {
> { 0x0072, &nv04_graph_ofuncs, NULL }, /* beta4 */
> { 0x0089, &nv04_graph_ofuncs, NULL }, /* sifm */
> { 0x008a, &nv04_graph_ofuncs, NULL }, /* ifc */
> - { 0x0096, &nv04_graph_ofuncs, NULL }, /* celcius */
> + { 0x0096, &nv04_graph_ofuncs, NULL }, /* celsius */
> { 0x0097, &nv04_graph_ofuncs, NULL }, /* kelvin */
> { 0x009e, &nv04_graph_ofuncs, NULL }, /* swzsurf */
> { 0x009f, &nv04_graph_ofuncs, NULL }, /* imageblit */
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv25.c
> b/drivers/gpu/drm/nouveau/core/engine/graph/nv25.c
> index 7a80d00..fcfe1c5 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nv25.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nv25.c
> @@ -28,7 +28,7 @@ nv25_graph_sclass[] = {
> { 0x0072, &nv04_graph_ofuncs, NULL }, /* beta4 */
> { 0x0089, &nv04_graph_ofuncs, NULL }, /* sifm */
> { 0x008a, &nv04_graph_ofuncs, NULL }, /* ifc */
> - { 0x0096, &nv04_graph_ofuncs, NULL }, /* celcius */
> + { 0x0096, &nv04_graph_ofuncs, NULL }, /* celsius */
> { 0x009e, &nv04_graph_ofuncs, NULL }, /* swzsurf */
> { 0x009f, &nv04_graph_ofuncs, NULL }, /* imageblit */
> { 0x0597, &nv04_graph_ofuncs, NULL }, /* kelvin */
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
> index f5786d5..b0f7ab0 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
> @@ -1264,7 +1264,7 @@ static ssize_t qlcnic_hwmon_show_temp(struct device
> *dev,
> value = QLC_SHARED_REG_RD32(adapter, QLCNIC_ASIC_TEMP);
>
> temperature = qlcnic_get_temp_val(value);
> - /* display millidegree celcius */
> + /* display millidegree celsius */
> temperature *= 1000;
> return sprintf(buf, "%u\n", temperature);
> }
> diff --git a/drivers/power/ds2780_battery.c b/drivers/power/ds2780_battery.c
> index 9f418fa..bf7d4bd 100644
> --- a/drivers/power/ds2780_battery.c
> +++ b/drivers/power/ds2780_battery.c
> @@ -210,7 +210,7 @@ static int ds2780_get_temperature(struct
> ds2780_device_info *dev_info,
> return ret;
>
> /*
> -* Temperature is measured in units of 0.125 degrees celcius, the
> +* Temperature is measured in units of 0.125 degrees celsius, the
> * power_supply class measures temperature in tenths of degrees
> * celsius. The temperature value is stored as a 10 bit number, plus
> * sign in the upper bits of a 16 bit register.
> diff --git a/drivers/power/ds2782_battery.c b/drivers/power/ds2782_battery.c
> index 041f9b6..adc7d32 100644
> --- a/drivers/power/ds2782_battery.c
> +++ b/drivers/power/ds2782_battery.c
> @@ -104,7 +104,7 @@ static int ds278x_get_temp(struct ds278x_info *info, int
> *temp)
>
Re: [PATCH 3.13 061/259] thermal: hwmon: Make the check for critical temp valid consistent
Hello,
On Fri, Aug 8, 2014 at 4:38 PM, Kamal Mostafa wrote:
> 3.13.11.6 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Aaron Lu
>
> commit e8db5d6736a712a3e2280c0e31f4b301d85172d8 upstream.
>
> On 05/21/2014 04:22 PM, Aaron Lu wrote:
>> On 05/21/2014 01:57 PM, Kui Zhang wrote:
>>> Hello,
>>>
>>> I get following error when rmmod thermal.
>>>
>>> rmmod thermal
>>> Killed
>
> While dealing with this problem, I found another problem that also
> results in a kernel crash on thermal module removal:
>
> From: Aaron Lu
> Date: Wed, 21 May 2014 16:05:38 +0800
> Subject: [PATCH] thermal: hwmon: Make the check for critical temp valid
> consistent
>
> We used the tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, temp)
> to decide if we need to create the temp_crit attribute file but we just
> check if tz->ops->get_crit_temp exists to decide if we need to remove
> that attribute file. Some ACPI thermal zone doesn't have a valid critical
> trip point and that would result in removing a non-existent device file
> on thermal module unload.
>
> Signed-off-by: Aaron Lu
> Signed-off-by: Zhang Rui
> Signed-off-by: Kamal Mostafa
Acked-by: Eduardo Valentin
> ---
> drivers/thermal/thermal_hwmon.c | 33 ++---
> 1 file changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
> index fdb0719..1967bee 100644
> --- a/drivers/thermal/thermal_hwmon.c
> +++ b/drivers/thermal/thermal_hwmon.c
> @@ -140,6 +140,12 @@ thermal_hwmon_lookup_temp(const struct
> thermal_hwmon_device *hwmon,
> return NULL;
> }
>
> +static bool thermal_zone_crit_temp_valid(struct thermal_zone_device *tz)
> +{
> + unsigned long temp;
> + return tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, &temp);
> +}
> +
> int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
> {
> struct thermal_hwmon_device *hwmon;
> @@ -189,21 +195,18 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device
> *tz)
> if (result)
> goto free_temp_mem;
>
> - if (tz->ops->get_crit_temp) {
> - unsigned long temperature;
> - if (!tz->ops->get_crit_temp(tz, &temperature)) {
> - snprintf(temp->temp_crit.name,
> -sizeof(temp->temp_crit.name),
> + if (thermal_zone_crit_temp_valid(tz)) {
> + snprintf(temp->temp_crit.name,
> + sizeof(temp->temp_crit.name),
> "temp%d_crit", hwmon->count);
> - temp->temp_crit.attr.attr.name = temp->temp_crit.name;
> - temp->temp_crit.attr.attr.mode = 0444;
> - temp->temp_crit.attr.show = temp_crit_show;
> - sysfs_attr_init(&temp->temp_crit.attr.attr);
> - result = device_create_file(hwmon->device,
> - &temp->temp_crit.attr);
> - if (result)
> - goto unregister_input;
> - }
> + temp->temp_crit.attr.attr.name = temp->temp_crit.name;
> + temp->temp_crit.attr.attr.mode = 0444;
> + temp->temp_crit.attr.show = temp_crit_show;
> + sysfs_attr_init(&temp->temp_crit.attr.attr);
> + result = device_create_file(hwmon->device,
> + &temp->temp_crit.attr);
> + if (result)
> + goto unregister_input;
> }
>
> mutex_lock(&thermal_hwmon_list_lock);
> @@ -250,7 +253,7 @@ void thermal_remove_hwmon_sysfs(struct
> thermal_zone_device *tz)
> }
>
> device_remove_file(hwmon->device, &temp->temp_input.attr);
> - if (tz->ops->get_crit_temp)
> + if (thermal_zone_crit_temp_valid(tz))
> device_remove_file(hwmon->device, &temp->temp_crit.attr);
>
> mutex_lock(&thermal_hwmon_list_lock);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] power_supply: Introduce PSE compliant algorithm
Hello Jenny,
On Wed, Aug 13, 2014 at 8:09 AM, Jenny TC wrote:
> As per Product Safety Engineering (PSE) specification for battery charging,
> the
> battery characteristics and thereby the charging rates can vary on different
> temperature zones. This patch introduces a PSE compliant charging algorithm
> with
> maintenance charging support. The algorithm can be selected by the power
> supply
> charging driver based on the type of the battery charging profile.
>
> Signed-off-by: Jenny TC
> ---
> drivers/power/Kconfig | 15 ++
> drivers/power/Makefile |1 +
> drivers/power/charging_algo_pse.c | 216
>
> include/linux/power/power_supply_charger.h | 66 +
> 4 files changed, 298 insertions(+)
> create mode 100644 drivers/power/charging_algo_pse.c
>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index f679f82..54a0321 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -22,6 +22,21 @@ config POWER_SUPPLY_CHARGER
> drivers to keep the charging logic outside and the charger driver
> just need to abstract the charger hardware.
>
> +config POWER_SUPPLY_CHARGING_ALGO_PSE
> + bool "PSE compliant charging algorithm"
> + depends on POWER_SUPPLY_CHARGER
> + help
> + Say Y here to select Product Safety Engineering (PSE) compliant
> + charging algorithm. As per PSE standard the battery characteristics
> + and thereby the charging rates can vary on different temperature
> + zones. Select this if your charging algorithm need to change the
> + charging parameters based on the battery temperature and the battery
> + charging profile follows the struct psy_pse_chrg_prof definition.
> + This config will enable PSE compliant charging algorithm with
> + maintenance charging support. At runtime the algorithm will be
> + selected by the psy charger driver based on the type of the battery
> + charging profile.
> +
> config PDA_POWER
> tristate "Generic PDA/phone power driver"
> depends on !S390
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 405f0f4..77535fd 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_SUPPLY) += power_supply.o
> obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
>
> obj-$(CONFIG_POWER_SUPPLY_CHARGER) += power_supply_charger.o
> +obj-$(CONFIG_POWER_SUPPLY_CHARGING_ALGO_PSE) += charging_algo_pse.o
> obj-$(CONFIG_PDA_POWER)+= pda_power.o
> obj-$(CONFIG_APM_POWER)+= apm_power.o
> obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
> diff --git a/drivers/power/charging_algo_pse.c
> b/drivers/power/charging_algo_pse.c
> new file mode 100644
> index 000..cbedebe
> --- /dev/null
> +++ b/drivers/power/charging_algo_pse.c
> @@ -0,0 +1,216 @@
> +/*
> + * Copyright (C) 2014 Intel Corporation
> + *
> + * ~~
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the GNU
> + * General Public License for more details.
> + *
> + * ~~
> + * Author: Jenny TC
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Why do you need thermal.h here?
In theory, if you are creating thermal zones or cooling devices with
your generic psi driver, then I agree, we need a link with thermal
subsystem. But I cannot see how the code below is using the thermal
code.
> +#include "power_supply.h"
> +#include "power_supply_charger.h"
> +
> +/* 98% of CV is considered as voltage to detect Full */
> +#define FULL_CV_MIN 98
> +
> +/*
> + * Offset to exit from maintenance charging. In maintenance charging
> + * if the volatge is less than the (maintenance_lower_threshold -
> + * MAINT_EXIT_OFFSET) then system can switch to normal charging
> + */
> +
> +#define MAINT_EXIT_OFFSET 50 /* mV */
> +
> +static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
> + int temp)
> +{
> + int i = 0, temp_range_cnt;
> +
> + temp_range_cnt = pse_mod_bprof->temp_mon_ranges;
> +
> + if (!temp_range_cnt || temp_range_cnt > BATT_TEMP_NR_RNG)
> + return -EINVAL;
> +
> + /* Basic validity check. Ensure zones are in decreasing order */
> +
> + for (i = 0; i < temp_range_cnt - 1; i++) {
> + if (pse_mod_bprof->temp_m
Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points
Moro,
On Fri, Aug 1, 2014 at 7:42 AM, Mikko Perttunen wrote:
> Moi Eduardo :)
>
>
> On 30/07/14 17:16, Eduardo Valentin wrote:
>>
>> Terve Mikko,
>>
>> On Fri, Jun 27, 2014 at 11:11:34AM +0300, Mikko Perttunen wrote:
>>>
>>> This adds support for hardware-tracked trip points to the device tree
>>> thermal sensor framework.
>>>
>>> The framework supports an arbitrary number of trip points. Whenever
>>> the current temperature is updated, the trip points immediately
>>> below and above the current temperature are found. A sensor driver
>>
>>
>> One thing I don't follow on your proposal is the groundings you need to
>> 'set_trips' whenever temperature changes. Given your intention is to add
>> support to interrupt driven devices, shouldn't we 'set_trips' just when
>> we cross the previously set trips range?
>
>
> I think the reasoning for this was that I didn't want to make changes to
> thermal_core and thermal_zone_device_update only calls get_temp on the zone,
> so I had to add this code to get_temp. set_trips would anyway only be called
> if we had crossed a trip point.
>
>
I see.
>>
>>> callback `set_trips' is then called with the temperatures.
>>> If there is no trip point above or below the current temperature,
>>> the passed trip temperature will be LONG_MAX or LONG_MIN respectively.
>>> In this callback, the driver should program the hardware such that
>>> it is notified when either of these trip points are triggered.
>>> When a trip point is triggered, the driver should call
>>> `thermal_zone_device_update' for the respective thermal zone. This
>>> will cause the trip points to be updated again.
>>>
>>> If the `set_trips' callback is not implemented (is NULL), the framework
>>> behaves as before.
>>
>>
>> As already mentioned by swarren, the proposal must be wider. We shall
>> keep the same support in case the device is used in a system without
>> device tree. In other words, if you want to see extra functionality for
>> interrupt driven devices, you shall update the core part too, and draft
>> a common messaging path.
>
>
> Yeah, this is sensible. A simpler solution would be to just tell of-thermal
> drivers about the trip points and let the driver do whatever it wants. That
> would mirror the way normal thermal_core drivers are done. What is your
> opinion on that?
>
>
In fact, with the current implementation in the thermal framework,
there is nothing else left than coding the feature in the driver
itself. The framework would know only about the existance of the
trips. This approach would need to be cleaned whenever we write the
fix in the core though.
For this reason, I would prefer to clean the core first, then write
the driver as a proof that the changes in core are properly covering
the existing drivers and interrupt driven drivers.
>>
>> In general, interrupt driven devices are not mapped in the current
>> thermal framework. That is, the current code is timer interrupt driven.
>> Other interrupt updates from devices are propagated to
>> the framework using thermal_zone_device_update(). In other words, you
>> would
>> reprogram your hardware trips from your interrupt handler/workqueue then
>> just let the framework know what is going on with temperature, via a
>> simple
>> thermal_zone_device_update().
>>
>> The way I see this going forward it would be a common interface to
>> configure the thermal zones to be monitored:
>> a. via polling only
>> b. via interrupt only
>> c. both a + b
>>
>> obviously, the above shall be informative only for userland.
>>
>> keep in mind also that changing interrupt configuration for high and low
>> temperature thresholds can be racy.
>>
>> This feature was kept in the TODO list of the of-thermal.c because the
>> we lack a proper support from the thermal framework (never came out of
>> the TODO list, I know, I apologize for this). And this missing feature
>> was spotted by the hwmon folks also, as they do have such support. So,
>> the major missing improvements on interrupt driven devices shall come in
>> three steps: (i) thermal framework, (ii) of-thermal (iii) thermal
>> framework and hwmon interface.
>
>
> For now, I think I'll submit a driver with just polling support so that we
> can get some support in.
I see. I will be looking into the changes in core. Whenever I have a
working RFC I will share with the list.
Terveydeksi!,
>
>>
>>
>> Cheers,
>>
>>
>
> Thanks, Mikko
>
>
>>>
>>> Signed-off-by: Mikko Perttunen
>>> ---
>>> drivers/thermal/of-thermal.c | 97
>>> ++--
>>> include/linux/thermal.h | 3 +-
>>> 2 files changed, 95 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>>> index 04b1be7..bfccea5 100644
>>> --- a/drivers/thermal/of-thermal.c
>>> +++ b/drivers/thermal/of-thermal.c
>>> @@ -89,6 +89,7 @@ struct __thermal_zone {
>>>/* trip data */
>>>int ntrips;
>>>struct __thermal_trip *trips;
>>> + long prev_l
Re: [PATCH v2 0/9] thermal: exynos: various cleanups
Bartlomiej, On Thu, Jul 31, 2014 at 1:37 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Tuesday, July 29, 2014 08:58:48 AM Eduardo Valentin wrote: >> On Mon, Jul 28, 2014 at 08:30:53PM +0530, amit daniel kachhap wrote: >> > Hi Eduardo, >> >> Hello Amit, >> >> > >> > Please reject this entire series as this is not re-based recently. >> > Actually two point trimming which this series seeks to remove is used >> > by exynos3250 and is in Rui's tree >> > (https://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=next&id=1fe56dc16a3dab400206443f70ae158c8f595c42). >> > >> >> Yeah, that was my original concern when I first looked this series. >> However, as I saw a couple of your acks I thought you would be in sync >> with Bartlomiej. >> >> I agree with Bartlomiej that we need to keep the kernel code in very >> good shape, but if we are removing features for the sake of reducing >> LOCs and we end up dropping support to known chips, I definitely won't >> agree. > > There is no intention to drop support for known chips. Two months after > initial posting of my patchset support for the new Exynos3250 SoC was > posted and it happens to use the two point trimming calibration code (that > was introduced back in September 2011 but never used previously). If we > had removed it earlier it would have to be readded partially but we are > talking about less than 100 lines of rather straightforward code (also > the calibration code in question is not perfect anyway and would profit > from some cleaning but I left it as it is for now). > >> Can you guys please reach a common agreement on these cleanups? >> >> Bartlomiej, best thing to do is to sync your work on top of Rui's tree. > > Done, I posted v3 of patchset today: > > http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35013.html > > I hope that it is acceptable for Amit now (Amit, please take a look at > patches when you find some time, thanks!). > Thanks for updating the series. Amit, can you please test the series on socs you have available? I would prefer to merge this one now if we have a proper tested-by. > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > >> For now I am dropping this series from my -next branch. :-( >> >> > Thanks, >> > Amit D >> > >> > >> > On Mon, Jul 28, 2014 at 8:07 PM, Eduardo Valentin >> > wrote: >> > > On Tue, Jun 17, 2014 at 07:27:16PM +0200, Bartlomiej Zolnierkiewicz >> > > wrote: >> > >> Hi, >> > >> >> > >> This patch series contains various cleanups for EXYNOS thermal >> > >> driver. Overall it decreases driver's LOC by 12%. It is based >> > >> on next-20140617 kernel. It should not cause any functionality >> > >> changes. >> > >> >> > >> Changes since v1: >> > >> - synced patches against next-20140617 >> > >> - merged patch "thermal: exynos: remove unused defines" into >> > >> "thermal: exynos: remove unused struct exynos_tmu_registers >> > >> entries" one (per request from Eduardo) >> > >> - improved patch descriptions for patches #1-5 >> > >> - fixed documentation for pdata->gain and pdata->reference_voltage >> > >> - added Reviewed-by from Amit to patches #6, #7 and #10 >> > >> - added missing Acked-by from Kyungmin Park >> > > >> > > Pulled the series. >> > > >> > > Thanks. >> > > >> > >> >> > >> Best regards, >> > >> -- >> > >> Bartlomiej Zolnierkiewicz >> > >> Samsung R&D Institute Poland >> > >> Samsung Electronics >> > >> >> > >> >> > >> Bartlomiej Zolnierkiewicz (9): >> > >> thermal: exynos: remove unused struct exynos_tmu_registers entries >> > >> thermal: exynos: remove dead code for HW_MODE calibration >> > >> thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING >> > >> calibration >> > >> thermal: exynos: remove redundant pdata checks from >> > >> exynos_tmu_initialize() >> > >> thermal: exynos: remove redundant threshold_code checks from >> > >> exynos_tmu_initialize() >> > >> thermal: exynos: simplify temp_to_code() and code_to_temp() >> > >> thermal: exynos: cache non_hw_trigger_levels in pdata >> > >> thermal: exynos: remove redundant pdata checks from >> > >> exynos_tmu_control() >> > >> thermal: exynos: remove identical values from exynos*_tmu_registers >> > >> structures >> > >> >> > >> drivers/thermal/samsung/exynos_thermal_common.h | 1 - >> > >> drivers/thermal/samsung/exynos_tmu.c| 181 >> > >> >> > >> drivers/thermal/samsung/exynos_tmu.h| 90 +--- >> > >> drivers/thermal/samsung/exynos_tmu_data.c | 64 + >> > >> drivers/thermal/samsung/exynos_tmu_data.h | 33 + >> > >> 5 files changed, 41 insertions(+), 328 deletions(-) >> > >> >> > >> -- >> > >> 1.8.2.3 > -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.
