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.we...@fairphone.com>
> >>> ---
> >> [...]
> >>
> >> 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


Reply via email to