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