Re: [PATCH 2/2] arm64: dts: qcom: sm7225-fairphone-fp4: Add PM6150L thermals

[Luca Weiss]

On Wed Jan 10, 2024 at 8:16 PM CET, Konrad Dybcio wrote:
>
>
> On 1/9/24 12:24, Luca Weiss wrote:
> > On Tue Jan 9, 2024 at 11:09 AM CET, Konrad Dybcio wrote:
> >>
> >>
> >> On 1/5/24 15:54, Luca Weiss wrote:
> >>> Configure the thermals for the PA_THERM1, MSM_THERM, PA_THERM0,
> >>> RFC_CAM_THERM, CAM_FLASH_THERM and QUIET_THERM thermistors connected to
> >>> PM6150L.
> >>>
> >>> Due to hardware constraints we can only register 4 zones with
> >>> pm6150l_adc_tm, the other 2 we can register via generic-adc-thermal.
> >>
> >> Ugh.. so the ADC can support more inputs than the ADC_TM that was
> >> designed to ship alongside it can?
> >>
> >> And that's why the "generic-adc-thermal"-provided zones need to
> >> be polled?
> > 
> > This part of the code from qcom-spmi-adc-tm5.c was trigerring if I
> > define more than 4 channels, and looking at downstream I can also see
> > that only 4 zones are registered properly with adc_tm, the rest is
> > registered with "qcom,adc-tm5-iio" which skips from what I could tell
> > basically all the HW bits and only registering the thermal zone.
> > 
> > 
> > 	ret = adc_tm5_read(chip, ADC_TM5_NUM_BTM,
> > 			   &channels_available, sizeof(channels_available));
> > 	if (ret) {
> > 		dev_err(chip->dev, "read failed for BTM channels\n");
> > 		return ret;
> > 	}
> > 
> > 	for (i = 0; i < chip->nchannels; i++) {
> > 		if (chip->channels[i].channel >= channels_available) {
> > 			dev_err(chip->dev, "Invalid channel %d\n", chip->channels[i].channel);
> > 			return -EINVAL;
> > 		}
> > 	}
> > 
> > 
> >>
> >>>
> >>> The trip points can really only be considered as placeholders, more
> >>> configuration with cooling etc. can be added later.
> >>>
> >>> Signed-off-by: Luca Weiss <luca.weiss@xxxxxxxxxxxxx>
> >>> ---
> >> [...]
> >>
> >> I've read the sentence above, but..
> >>> +		sdm-skin-thermal {
> >>> +			polling-delay-passive = <1000>;
> >>> +			polling-delay = <5000>;
> >>> +			thermal-sensors = <&msm_therm_sensor>;
> >>> +
> >>> +			trips {
> >>> +				active-config0 {
> >>> +					temperature = <125000>;
> >>> +					hysteresis = <1000>;
> >>> +					type = "passive";
> >>
> >> I don't fancy burnt fingers for dinner!
> > 
> > With passive trip point it wouldn't even do anything now, but at what
> > temp do you think it should do what? I'd definitely need more time to
> > understand more of how the thermal setup works in downstream Android,
> > and then replicate a sane configuration for mainline with proper
> > temperatures, cooling, etc.
> If "skin therm" means "the temperature of some part of the phone's
> body that can be felt with a human hand", then definitely some
> throttling should happen at 40ish with heavy throttling at 50
> and crit at 55 or so..
>
> We should probably make this a broader topic and keep a single
> policy for all supported phones.

I agree that this shouldn't be implemented differently per device since
it's really more a question "what should Linux do" that's quite a
general question and not device-specific. Of course some device-specific
tweaks could be here and there, like if the phone has metal back or
plastic back but it's only minor.

Based on the config here
https://gerrit-public.fairphone.software/plugins/gitiles/platform/hardware/qcom/thermal/+/refs/heads/odm/dev/target/13/fp5/thermalConfig.cpp#946
it looks like throtteling starts for internal components at 95degC with
a shutdown threshold of 115degC.
The skin sensor here has a throttling threshold of 40degC and shutdown
threshold of 95degC.

But actually I'm not even sure this config gets active for QCM6490 with
socid=497. So yeah I need more time digging into the thermal code to see
what it's actually doing.. Not that it would/should be much different
for socid=497 I guess though.

There's also plenty of thermal code in qcom proprietary.

Regards
Luca

>
> + CC AGdR, may be interested in where this leads
>
> Konrad