From: Eduardo Valentin <edubezval@gmail.com> To: kernel@martin.sperl.org Cc: Zhang Rui <rui.zhang@intel.com>, Lee Jones <lee@kernel.org>, Eric Anholt <eric@anholt.net>, linux-pm@vger.kernel.org, linux-rpi-kernel <linux-rpi-kernel@lists.infradead.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH V9] thermal: bcm2835: add thermal driver for bcm2835 soc Date: Wed, 1 Feb 2017 20:29:32 -0800 [thread overview] Message-ID: <20170202042930.GA6377@localhost.localdomain> (raw) In-Reply-To: <0452720A-5914-469B-9EF7-0581CF1B5478@martin.sperl.org> Hello Martin, On Tue, Jan 24, 2017 at 10:52:43AM +0100, kernel@martin.sperl.org wrote: > > > On 24.01.2017, at 10:31, Eduardo Valentin <edubezval@gmail.com> wrote: > > > > Hello Martin, > > > > On Fri, Jan 20, 2017 at 08:54:07AM +0100, kernel@martin.sperl.org wrote: > >> > >>> On 20.01.2017, at 05:14, Eduardo Valentin <edubezval@gmail.com> wrote: > >>> > >>> Hello Martin, > >>> > >>> On Sat, Jan 07, 2017 at 04:55:45PM +0000, kernel@martin.sperl.org wrote: > >>>> From: Martin Sperl <kernel@martin.sperl.org> > >>>> > >>>> Add basic thermal driver for bcm2835 SOC. > >>>> > >>>> This driver currently relies on the firmware setting up the > >>>> tsense HW block and does not set it up itself. > >>>> > >>>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org> > >>>> Acked-by: Eric Anholt <eric@anholt.net> > >>>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com> > >>>> > >>> > >>> <cut> > >>> > >>>> + > >>>> +static const struct of_device_id bcm2835_thermal_of_match_table[] = { > >>>> + { > >>>> + .compatible = "brcm,bcm2835-thermal", > >>>> + .data = &(struct bcm2835_thermal_info) { > >>>> + .offset = 407000, > >>>> + .slope = -538, > >>>> + .trip_temp = 80000 > >>>> + } > >>>> + }, > >>>> + { > >>>> + .compatible = "brcm,bcm2836-thermal", > >>>> + .data = &(struct bcm2835_thermal_info) { > >>>> + .offset = 407000, > >>>> + .slope = -538, > >>>> + .trip_temp = 80000 > >>>> + } > >>>> + }, > >>>> + { > >>>> + .compatible = "brcm,bcm2837-thermal", > >>>> + .data = &(struct bcm2835_thermal_info) { > >>>> + /* the bcm2837 needs adjustment of +5C */ > >>>> + .offset = 407000 + 5000, > >>>> + .slope = -538, > >>>> + .trip_temp = 80000 > >>>> + } > >>>> + }, > >>>> + {}, > >>> > >>> Just for the same of clarification, is there anything preventing this > >>> driver of using of-thermal API? the above data (slope, offset, and > >>> trip_temps) would be in DT the place where they are supposed to be, > >>> instead of code. > >>> > >> > >> As the DT changes, that only define compatible strings, have already gone > >> in without any such properties set, we need to define defaults for the > >> slope/offset and trip_temp values. > >> > > > > These properties won't go into the same node you are referring to. They > > go into the thermal-zone node you would create, which would then refer > > to the node you referred (already merged). Therefore, I do not see > > anything blocking a proper of-thermal usage to cover for the above data. > > > >> I guess (for newer SOC) you still can use the values in the DT, > >> as (I guess) these are parsed and set in thermal_zone_device_register > >> after the defaults are set in thermal_zone_params. > > > > Not sure what you meant here, but these values, when correctly used in > > DT, they would come as part of the thermal_zone_params and in the > > thermal trips of the thermal zones, as the of-thermal code with already > > deal with those for you. > > > > Please have a look at: > > a. Documentation/devicetree/bindings/thermal/thermal.txt > > b. drivers/thermal/of-thermal.c > > > > And let me know if you see anything that would prevent this driver of > > using the correct API to describe hardware data with DT. > > > I guess you miss my point: Maybe you missed, or did not read the doc I pointed you... > The argument is that we have DT in the 4.10.0-rc2 kernel right now that > look like this: > thermal@7e212000 { > compatible = "brcm,bcm2835-thermal"; > clocks = <0x6 0x1b>; > status = "okay"; > reg = <0x7e212000 0x8>; > } > so we still need to be compatible with those without any extra defines. Yes, but the above DT entry will still be valid if you add the correct of-thermal support. In fact, you would add in your DTS a thermal-zones node, and in one of the defined zone, you would then reference the node you already got into mainline. Below is a copy of the doc I mentioned before: #include <dt-bindings/thermal/thermal.h> ocp { ... /* * A simple IC with several bandgap temperature sensors. */ bandgap0: bandgap@0x0000ED00 { ... #thermal-sensor-cells = <1>; }; }; thermal-zones { cpu_thermal: cpu-thermal { polling-delay-passive = <250>; /* milliseconds */ polling-delay = <1000>; /* milliseconds */ /* sensor ID */ thermal-sensors = <&bandgap0 0>; trips { /* each zone within the SoC may have its own trips */ cpu_alert: cpu-alert { temperature = <100000>; /* millicelsius */ hysteresis = <2000>; /* millicelsius */ type = "passive"; }; cpu_crit: cpu-crit { temperature = <125000>; /* millicelsius */ hysteresis = <2000>; /* millicelsius */ type = "critical"; }; }; cooling-maps { /* each zone within the SoC may have its own cooling */ ... }; }; > > Hence we need to define those slopes and offsets in the driver itself > to stay compatible with those older device-trees. not really, as long as we do not merge the driver with the missing of-thermal support, I see no need to have both supports in your driver, i.e., if we start correct for the beggining there is no need to have offsets and slopes data in your driver code. > > As for if it works with the framework - I have to admit I do not > have the slightest clue - it looks way to complicated for the soc right > now. Well, there is the documentation I mentioned, which several other drivers used as base for their support. You can also look at other thermal zones already defined in the existing DTS(I)'s. > > As a note: afaiu the trip_temp register is the temperature at which the > soc will reboot on its own - similar to a watchdog, but for temperatures. > (main reason for the assumption is because there is no interrupt that > can get assigned a handler to catch this situation). > OK. But that does not prevent you to have other trips so your running system can act before the shutdown trip is crossed. > Martin > > BR, Eduardo Valentin
WARNING: multiple messages have this Message-ID (diff)
From: edubezval@gmail.com (Eduardo Valentin) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V9] thermal: bcm2835: add thermal driver for bcm2835 soc Date: Wed, 1 Feb 2017 20:29:32 -0800 [thread overview] Message-ID: <20170202042930.GA6377@localhost.localdomain> (raw) In-Reply-To: <0452720A-5914-469B-9EF7-0581CF1B5478@martin.sperl.org> Hello Martin, On Tue, Jan 24, 2017 at 10:52:43AM +0100, kernel at martin.sperl.org wrote: > > > On 24.01.2017, at 10:31, Eduardo Valentin <edubezval@gmail.com> wrote: > > > > Hello Martin, > > > > On Fri, Jan 20, 2017 at 08:54:07AM +0100, kernel at martin.sperl.org wrote: > >> > >>> On 20.01.2017, at 05:14, Eduardo Valentin <edubezval@gmail.com> wrote: > >>> > >>> Hello Martin, > >>> > >>> On Sat, Jan 07, 2017 at 04:55:45PM +0000, kernel at martin.sperl.org wrote: > >>>> From: Martin Sperl <kernel@martin.sperl.org> > >>>> > >>>> Add basic thermal driver for bcm2835 SOC. > >>>> > >>>> This driver currently relies on the firmware setting up the > >>>> tsense HW block and does not set it up itself. > >>>> > >>>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org> > >>>> Acked-by: Eric Anholt <eric@anholt.net> > >>>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com> > >>>> > >>> > >>> <cut> > >>> > >>>> + > >>>> +static const struct of_device_id bcm2835_thermal_of_match_table[] = { > >>>> + { > >>>> + .compatible = "brcm,bcm2835-thermal", > >>>> + .data = &(struct bcm2835_thermal_info) { > >>>> + .offset = 407000, > >>>> + .slope = -538, > >>>> + .trip_temp = 80000 > >>>> + } > >>>> + }, > >>>> + { > >>>> + .compatible = "brcm,bcm2836-thermal", > >>>> + .data = &(struct bcm2835_thermal_info) { > >>>> + .offset = 407000, > >>>> + .slope = -538, > >>>> + .trip_temp = 80000 > >>>> + } > >>>> + }, > >>>> + { > >>>> + .compatible = "brcm,bcm2837-thermal", > >>>> + .data = &(struct bcm2835_thermal_info) { > >>>> + /* the bcm2837 needs adjustment of +5C */ > >>>> + .offset = 407000 + 5000, > >>>> + .slope = -538, > >>>> + .trip_temp = 80000 > >>>> + } > >>>> + }, > >>>> + {}, > >>> > >>> Just for the same of clarification, is there anything preventing this > >>> driver of using of-thermal API? the above data (slope, offset, and > >>> trip_temps) would be in DT the place where they are supposed to be, > >>> instead of code. > >>> > >> > >> As the DT changes, that only define compatible strings, have already gone > >> in without any such properties set, we need to define defaults for the > >> slope/offset and trip_temp values. > >> > > > > These properties won't go into the same node you are referring to. They > > go into the thermal-zone node you would create, which would then refer > > to the node you referred (already merged). Therefore, I do not see > > anything blocking a proper of-thermal usage to cover for the above data. > > > >> I guess (for newer SOC) you still can use the values in the DT, > >> as (I guess) these are parsed and set in thermal_zone_device_register > >> after the defaults are set in thermal_zone_params. > > > > Not sure what you meant here, but these values, when correctly used in > > DT, they would come as part of the thermal_zone_params and in the > > thermal trips of the thermal zones, as the of-thermal code with already > > deal with those for you. > > > > Please have a look at: > > a. Documentation/devicetree/bindings/thermal/thermal.txt > > b. drivers/thermal/of-thermal.c > > > > And let me know if you see anything that would prevent this driver of > > using the correct API to describe hardware data with DT. > > > I guess you miss my point: Maybe you missed, or did not read the doc I pointed you... > The argument is that we have DT in the 4.10.0-rc2 kernel right now that > look like this: > thermal at 7e212000 { > compatible = "brcm,bcm2835-thermal"; > clocks = <0x6 0x1b>; > status = "okay"; > reg = <0x7e212000 0x8>; > } > so we still need to be compatible with those without any extra defines. Yes, but the above DT entry will still be valid if you add the correct of-thermal support. In fact, you would add in your DTS a thermal-zones node, and in one of the defined zone, you would then reference the node you already got into mainline. Below is a copy of the doc I mentioned before: #include <dt-bindings/thermal/thermal.h> ocp { ... /* * A simple IC with several bandgap temperature sensors. */ bandgap0: bandgap at 0x0000ED00 { ... #thermal-sensor-cells = <1>; }; }; thermal-zones { cpu_thermal: cpu-thermal { polling-delay-passive = <250>; /* milliseconds */ polling-delay = <1000>; /* milliseconds */ /* sensor ID */ thermal-sensors = <&bandgap0 0>; trips { /* each zone within the SoC may have its own trips */ cpu_alert: cpu-alert { temperature = <100000>; /* millicelsius */ hysteresis = <2000>; /* millicelsius */ type = "passive"; }; cpu_crit: cpu-crit { temperature = <125000>; /* millicelsius */ hysteresis = <2000>; /* millicelsius */ type = "critical"; }; }; cooling-maps { /* each zone within the SoC may have its own cooling */ ... }; }; > > Hence we need to define those slopes and offsets in the driver itself > to stay compatible with those older device-trees. not really, as long as we do not merge the driver with the missing of-thermal support, I see no need to have both supports in your driver, i.e., if we start correct for the beggining there is no need to have offsets and slopes data in your driver code. > > As for if it works with the framework - I have to admit I do not > have the slightest clue - it looks way to complicated for the soc right > now. Well, there is the documentation I mentioned, which several other drivers used as base for their support. You can also look at other thermal zones already defined in the existing DTS(I)'s. > > As a note: afaiu the trip_temp register is the temperature at which the > soc will reboot on its own - similar to a watchdog, but for temperatures. > (main reason for the assumption is because there is no interrupt that > can get assigned a handler to catch this situation). > OK. But that does not prevent you to have other trips so your running system can act before the shutdown trip is crossed. > Martin > > BR, Eduardo Valentin
next prev parent reply other threads:[~2017-02-02 4:29 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-07 16:55 [PATCH V9] thermal: bcm2835: add thermal driver for bcm2835 soc kernel 2017-01-07 16:55 ` kernel at martin.sperl.org 2017-01-20 4:14 ` Eduardo Valentin 2017-01-20 4:14 ` Eduardo Valentin 2017-01-20 4:23 ` Eduardo Valentin 2017-01-20 4:23 ` Eduardo Valentin [not found] ` <20170120042323.GA6651-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2017-01-20 8:43 ` kernel-TqfNSX0MhmxHKSADF0wUEw 2017-01-20 8:43 ` kernel at martin.sperl.org 2017-01-24 9:26 ` Eduardo Valentin 2017-01-24 9:26 ` Eduardo Valentin 2017-01-24 9:37 ` kernel 2017-01-24 9:37 ` kernel at martin.sperl.org [not found] ` <20170120041400.GA24617-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2017-01-20 7:54 ` kernel-TqfNSX0MhmxHKSADF0wUEw 2017-01-20 7:54 ` kernel at martin.sperl.org [not found] ` <060918B6-A773-46A5-8D10-C9F6BBA6D3F1-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org> 2017-01-24 9:31 ` Eduardo Valentin 2017-01-24 9:31 ` Eduardo Valentin 2017-01-24 9:52 ` kernel 2017-01-24 9:52 ` kernel at martin.sperl.org 2017-02-02 4:29 ` Eduardo Valentin [this message] 2017-02-02 4:29 ` Eduardo Valentin 2017-02-04 8:35 ` kernel 2017-02-04 8:35 ` kernel at martin.sperl.org 2017-02-04 14:16 ` [PATCH 1/2] dt-bindings: Add thermal zone to bcm2835-thermal example Stefan Wahren 2017-02-04 14:16 ` [PATCH 2/2] ARM: dts: bcm283x: Add critical thermal zone for GPU Stefan Wahren [not found] ` <1486217787-15703-2-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org> 2017-02-08 4:19 ` Eduardo Valentin [not found] ` <20170208041929.GA6809-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2017-02-08 4:23 ` Eduardo Valentin [not found] ` <20170208042351.GB6809-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2017-02-08 9:56 ` Stefan Wahren 2017-02-08 19:50 ` Eric Anholt 2017-02-09 17:48 ` Stefan Wahren [not found] ` <124007607.358509.1486662532562-7tX72C7vayboQLBSYMtkGA@public.gmane.org> 2017-02-09 23:34 ` Eric Anholt 2017-02-08 22:02 ` [PATCH 1/2] dt-bindings: Add thermal zone to bcm2835-thermal example Rob Herring [not found] ` <E0A4388D-788A-40B4-9193-36FD75284654-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org> 2017-02-08 4:31 ` [PATCH V9] thermal: bcm2835: add thermal driver for bcm2835 soc Eduardo Valentin 2017-02-08 4:31 ` Eduardo Valentin [not found] ` <20170208043107.GA7097-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2017-02-08 8:19 ` kernel-TqfNSX0MhmxHKSADF0wUEw 2017-02-08 8:19 ` kernel at martin.sperl.org 2017-02-04 9:36 ` Stefan Wahren 2017-02-04 9:36 ` Stefan Wahren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170202042930.GA6377@localhost.localdomain \ --to=edubezval@gmail.com \ --cc=eric@anholt.net \ --cc=kernel@martin.sperl.org \ --cc=lee@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-rpi-kernel@lists.infradead.org \ --cc=rui.zhang@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.