[RESEND PATCH v2 4/9] imx: thermal: Configure trip point from DT

Marco Felsch m.felsch at pengutronix.de
Fri Jun 17 02:28:48 PDT 2022


On 22-06-17, Francesco Dolcini wrote:
> On Fri, Jun 17, 2022 at 10:40:17AM +0200, Marco Felsch wrote:
> > On 22-06-17, Francesco Dolcini wrote:
> > > Allow over-writing critical and passive trip point for each
> > > temperature grade from the device tree, by default the pre-existing
> > > hard-coded trip points are used.
> > > 
> > > This change enables configuring the system thermal characteristics into
> > > the system-specific device tree instead of relying on global hard-coded
> > > temperature thresholds that does not take into account the specific
> > > system thermal design.
> > > 
> > > Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> > > ---
> > > v2:
> > >  - return immediately if no thermal node present in the dts
> > >  - use dev_info instead of dev_dbg if there is an invalid trip
> > >  - additional comment in case passive trip point is higher than critical
> > > ---
> > >  drivers/thermal/imx_thermal.c | 58 +++++++++++++++++++++++++++++++++++
> > >  1 file changed, 58 insertions(+)
> > > 
> > > diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> > > index 16663373b682..a964baf802fc 100644
> > > --- a/drivers/thermal/imx_thermal.c
> > > +++ b/drivers/thermal/imx_thermal.c
> > > @@ -17,6 +17,8 @@
> > >  #include <linux/nvmem-consumer.h>
> > >  #include <linux/pm_runtime.h>
> > >  
> > > +#include "thermal_core.h"
> > > +
> > >  #define REG_SET		0x4
> > >  #define REG_CLR		0x8
> > >  #define REG_TOG		0xc
> > > @@ -479,36 +481,92 @@ static int imx_init_calib(struct platform_device *pdev, u32 ocotp_ana1)
> > >  	return 0;
> > >  }
> > >  
> > > +static void imx_init_temp_from_of(struct platform_device *pdev, const char *name)
> > > +{
> > > +	struct imx_thermal_data *data = platform_get_drvdata(pdev);
> > > +	struct device_node *thermal, *trips, *trip_point;
> > > +
> > > +	thermal = of_get_child_by_name(pdev->dev.of_node, name);
> > > +	if (!thermal)
> > > +		return;
> > > +
> > > +	trips = of_get_child_by_name(thermal, "trips");
> > > +
> > > +	for_each_child_of_node(trips, trip_point) {
> > > +		struct thermal_trip t;
> > > +
> > > +		if (thermal_of_populate_trip(trip_point, &t))
> > > +			continue;
> > > +
> > > +		switch (t.type) {
> > > +		case THERMAL_TRIP_PASSIVE:
> > > +			data->temp_passive = t.temperature;
> > > +			break;
> > > +		case THERMAL_TRIP_CRITICAL:
> > 
> > Should we check also the temp_critical and temp_passive not exceeding
> > the temp_max? Sry. that it came not earlier in my mind. So system damage
> > is avoided.
> 
> I would not add such kind of restriction in the code. I can think of
> multiple situations in which a system designer would prefer to take the
> chances of burning a silicon (or more likely just age it a little bit
> faster) than to just shut down the system.
> 
> In the end whoever is building the system should be empowered to do
> something like that and it's no different from what it's already possible
> with thermal_of driver for example. 
> 
> In addition to that from a system debug prospective all the threshold
> (max, passive, critical) are already available in the kernel logs.

Okay, fine with me since you provided dt-snippets with the correct
temperature. But we should really print a warning since this is a
abnormal usage and the user should be warned.

Regards,
  Marco
> 
> Francesco
> 
> 



More information about the linux-arm-kernel mailing list