| Message ID | 20191029164537.1561-3-p.paillet@st.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Eduardo Valentin |
| Headers | show |
| Series | thermal: stm32: driver improvements | expand |
Hi Pascal, On 29/10/2019 17:45, Pascal Paillet wrote: > Fix IRQ flood on low threshold by too ways: Can you state the issue first ? > - improve temperature reading resolution, > - add an hysteresis to the low threshold: on low threshold interrupt, > it is not possible to get the temperature value that has fired the > interrupt. The time to acquire a new value is enough for the CPU to > become hotter than the current low threshold.> Signed-off-by: Pascal Paillet <p.paillet@st.com> > Change-Id: I3b63b8aab38fd651a165c4e69a2d090b3c6f5db3 Please remove the Change-Id tag. Joe, Andy? checkpatch does not see the Change-Id, is it the expected behavior? [ ... ]
On Tue, 2019-10-29 at 18:11 +0100, Daniel Lezcano wrote: > On 29/10/2019 17:45, Pascal Paillet wrote: > > Fix IRQ flood on low threshold by too ways: > > Can you state the issue first ? > > > - improve temperature reading resolution, > > - add an hysteresis to the low threshold: on low threshold interrupt, > > it is not possible to get the temperature value that has fired the > > interrupt. The time to acquire a new value is enough for the CPU to > > become hotter than the current low threshold. [] > > Signed-off-by: Pascal Paillet <p.paillet@st.com> > > Change-Id: I3b63b8aab38fd651a165c4e69a2d090b3c6f5db3 > > Please remove the Change-Id tag. > > Joe, Andy? checkpatch does not see the Change-Id, is it the expected > behavior? Yes. It's after a sign-off so checkpatch doesn't care.
On 29/10/2019 18:15, Joe Perches wrote: > On Tue, 2019-10-29 at 18:11 +0100, Daniel Lezcano wrote: >> On 29/10/2019 17:45, Pascal Paillet wrote: >>> Fix IRQ flood on low threshold by too ways: >> >> Can you state the issue first ? >> >>> - improve temperature reading resolution, >>> - add an hysteresis to the low threshold: on low threshold interrupt, >>> it is not possible to get the temperature value that has fired the >>> interrupt. The time to acquire a new value is enough for the CPU to >>> become hotter than the current low threshold. > [] >>> Signed-off-by: Pascal Paillet <p.paillet@st.com> >>> Change-Id: I3b63b8aab38fd651a165c4e69a2d090b3c6f5db3 >> >> Please remove the Change-Id tag. >> >> Joe, Andy? checkpatch does not see the Change-Id, is it the expected >> behavior? > > Yes. It's after a sign-off so checkpatch doesn't care. Ah, I guess it is for Gerrit but we don't want those Change-Id in the kernel history, right?
On Tue, 2019-10-29 at 18:21 +0100, Daniel Lezcano wrote: > On 29/10/2019 18:15, Joe Perches wrote: > > On Tue, 2019-10-29 at 18:11 +0100, Daniel Lezcano wrote: > > > On 29/10/2019 17:45, Pascal Paillet wrote: > > > > Fix IRQ flood on low threshold by too ways: > > > > > > Can you state the issue first ? > > > > > > > - improve temperature reading resolution, > > > > - add an hysteresis to the low threshold: on low threshold interrupt, > > > > it is not possible to get the temperature value that has fired the > > > > interrupt. The time to acquire a new value is enough for the CPU to > > > > become hotter than the current low threshold. > > [] > > > > Signed-off-by: Pascal Paillet <p.paillet@st.com> > > > > Change-Id: I3b63b8aab38fd651a165c4e69a2d090b3c6f5db3 > > > > > > Please remove the Change-Id tag. > > > > > > Joe, Andy? checkpatch does not see the Change-Id, is it the expected > > > behavior? > > > > Yes. It's after a sign-off so checkpatch doesn't care. > > Ah, I guess it is for Gerrit but we don't want those Change-Id in the > kernel history, right? So remove it from the patch. checkpatch is not a perfect tool. checkpatch will never be a perfect tool. It's not possible for checkpatch to be a perfect tool.
On 29/10/2019 18:24, Joe Perches wrote: > On Tue, 2019-10-29 at 18:21 +0100, Daniel Lezcano wrote: >> On 29/10/2019 18:15, Joe Perches wrote: >>> On Tue, 2019-10-29 at 18:11 +0100, Daniel Lezcano wrote: >>>> On 29/10/2019 17:45, Pascal Paillet wrote: >>>>> Fix IRQ flood on low threshold by too ways: >>>> >>>> Can you state the issue first ? >>>> >>>>> - improve temperature reading resolution, >>>>> - add an hysteresis to the low threshold: on low threshold interrupt, >>>>> it is not possible to get the temperature value that has fired the >>>>> interrupt. The time to acquire a new value is enough for the CPU to >>>>> become hotter than the current low threshold. >>> [] >>>>> Signed-off-by: Pascal Paillet <p.paillet@st.com> >>>>> Change-Id: I3b63b8aab38fd651a165c4e69a2d090b3c6f5db3 >>>> >>>> Please remove the Change-Id tag. >>>> >>>> Joe, Andy? checkpatch does not see the Change-Id, is it the expected >>>> behavior? >>> >>> Yes. It's after a sign-off so checkpatch doesn't care. >> >> Ah, I guess it is for Gerrit but we don't want those Change-Id in the >> kernel history, right? > > So remove it from the patch. It was not a sarcastic question. I just wanted to be sure the Change-Id is something we always want to remove. There are some of them in the kernel log and I got a doubt. checkpatch is perfectly fine for me. -- Daniel
diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c index 0aae1cc14235..4bc1bbece0de 100644 --- a/drivers/thermal/st/stm_thermal.c +++ b/drivers/thermal/st/stm_thermal.c @@ -59,7 +59,6 @@ /* Less significant bit position definitions */ #define TS1_T0_POS 16 -#define TS1_SMP_TIME_POS 16 #define TS1_HITTHD_POS 16 #define TS1_LITTHD_POS 0 #define HSREF_CLK_DIV_POS 24 @@ -83,15 +82,10 @@ #define ONE_MHZ 1000000 #define POLL_TIMEOUT 5000 #define STARTUP_TIME 40 -#define TS1_T0_VAL0 30 -#define TS1_T0_VAL1 130 +#define TS1_T0_VAL0 30000 /* 30 celsius */ +#define TS1_T0_VAL1 130000 /* 130 celsius */ #define NO_HW_TRIG 0 - -/* The Thermal Framework expects millidegrees */ -#define mcelsius(temp) ((temp) * 1000) - -/* The Sensor expects oC degrees */ -#define celsius(temp) ((temp) / 1000) +#define SAMPLING_TIME 15 struct stm_thermal_sensor { struct device *dev; @@ -222,12 +216,8 @@ static int stm_thermal_calibration(struct stm_thermal_sensor *sensor) if (!clk_freq) return -EINVAL; - prescaler = 0; - clk_freq /= ONE_MHZ; - if (clk_freq) { - while (prescaler <= clk_freq) - prescaler++; - } + /* calculate divider for maximum 1MHz PCLK */ + prescaler = clk_freq / ONE_MHZ + 1; value = readl_relaxed(sensor->base + DTS_CFGR1_OFFSET); @@ -235,7 +225,7 @@ static int stm_thermal_calibration(struct stm_thermal_sensor *sensor) value &= ~HSREF_CLK_DIV_MASK; /* Set prescaler. pclk_freq/prescaler < 1MHz */ - value |= (prescaler << HSREF_CLK_DIV_POS); + value |= (prescaler << HSREF_CLK_DIV_POS) & HSREF_CLK_DIV_MASK; /* Select PCLK as reference clock */ value &= ~REFCLK_SEL; @@ -289,28 +279,16 @@ static int stm_thermal_calculate_threshold(struct stm_thermal_sensor *sensor, int temp, u32 *th) { int freqM; - u32 sampling_time; - - /* Retrieve the number of periods to sample */ - sampling_time = (readl_relaxed(sensor->base + DTS_CFGR1_OFFSET) & - TS1_SMP_TIME_MASK) >> TS1_SMP_TIME_POS; /* Figure out the CLK_PTAT frequency for a given temperature */ - freqM = ((temp - sensor->t0) * sensor->ramp_coeff) - + sensor->fmt0; - - dev_dbg(sensor->dev, "%s: freqM for threshold = %d Hz", - __func__, freqM); + freqM = ((temp - sensor->t0) * sensor->ramp_coeff) / 1000 + + sensor->fmt0; /* Figure out the threshold sample number */ - *th = clk_get_rate(sensor->clk); + *th = clk_get_rate(sensor->clk) * SAMPLING_TIME / freqM; if (!*th) return -EINVAL; - *th = *th / freqM; - - *th *= sampling_time; - dev_dbg(sensor->dev, "freqM=%d Hz, threshold=0x%x", freqM, *th); return 0; @@ -320,42 +298,28 @@ static int stm_thermal_calculate_threshold(struct stm_thermal_sensor *sensor, static int stm_thermal_get_temp(void *data, int *temp) { struct stm_thermal_sensor *sensor = data; - u32 sampling_time; + u32 periods; int freqM, ret; if (sensor->mode != THERMAL_DEVICE_ENABLED) return -EAGAIN; - /* Retrieve the number of samples */ - ret = readl_poll_timeout(sensor->base + DTS_DR_OFFSET, freqM, - (freqM & TS1_MFREQ_MASK), STARTUP_TIME, - POLL_TIMEOUT); - + /* Retrieve the number of periods sampled */ + ret = readl_relaxed_poll_timeout(sensor->base + DTS_DR_OFFSET, periods, + (periods & TS1_MFREQ_MASK), + STARTUP_TIME, POLL_TIMEOUT); if (ret) return ret; - if (!freqM) - return -ENODATA; - - /* Retrieve the number of periods sampled */ - sampling_time = (readl_relaxed(sensor->base + DTS_CFGR1_OFFSET) & - TS1_SMP_TIME_MASK) >> TS1_SMP_TIME_POS; - - /* Figure out the number of samples per period */ - freqM /= sampling_time; - /* Figure out the CLK_PTAT frequency */ - freqM = clk_get_rate(sensor->clk) / freqM; + freqM = (clk_get_rate(sensor->clk) * SAMPLING_TIME) / periods; if (!freqM) return -EINVAL; - dev_dbg(sensor->dev, "%s: freqM=%d\n", __func__, freqM); - /* Figure out the temperature in mili celsius */ - *temp = mcelsius(sensor->t0 + ((freqM - sensor->fmt0) / - sensor->ramp_coeff)); + *temp = (freqM - sensor->fmt0) * 1000 / sensor->ramp_coeff + sensor->t0; - dev_dbg(sensor->dev, "temperature = %d millicelsius", *temp); + dev_dbg(sensor->dev, "periods=0x%x t=%d mC", periods, *temp); return 0; } @@ -379,7 +343,8 @@ static int stm_thermal_set_trips(void *data, int low, int high) if (low > -INT_MAX) { sensor->low_en = 1; - ret = stm_thermal_calculate_threshold(sensor, low, &th); + /* add 0.5 of hysteresis due to measurement error */ + ret = stm_thermal_calculate_threshold(sensor, low - 500, &th); if (ret) return ret;
Fix IRQ flood on low threshold by too ways: - improve temperature reading resolution, - add an hysteresis to the low threshold: on low threshold interrupt, it is not possible to get the temperature value that has fired the interrupt. The time to acquire a new value is enough for the CPU to become hotter than the current low threshold. Signed-off-by: Pascal Paillet <p.paillet@st.com> Change-Id: I3b63b8aab38fd651a165c4e69a2d090b3c6f5db3 --- drivers/thermal/st/stm_thermal.c | 73 +++++++++----------------------- 1 file changed, 19 insertions(+), 54 deletions(-)