Re: [PATCH 4/6] thermal: qcom: tsens: add hardware-bin trip-point filtering

[Gaurav Kohli]

On 10/30/2026 6:08 PM, Konrad Dybcio wrote:
> On 10/27/26 1:59 PM, Gaurav Kohli wrote:
> > On 10/26/2026 5:21 PM, Konrad Dybcio wrote:
> > > On 10/23/26 12:01 PM, Gaurav Kohli wrote:
> > > > On 10/22/2026 2:39 PM, Konrad Dybcio wrote:
> > > > > On 10/2/26 12:46 PM, Gaurav Kohli wrote:
> > > > > > From: Amit Kucheria <amit.kucheria@xxxxxxxxxxxxxxxx>
> > > > > >
> > > > > > Some Qualcomm SoCs are binned at manufacturing time and expose the bin
> > > > > > in qfprom fuses.  The thermal core's supported_hw_bin mechanism filters
> > > > > > trip points by hardware version; wire tsens up to feed it.
> > > > >
> > > > > [...]
> > > > >
> > > > > > +    /* Hardware-bin values for thermal-hw-bin matching in DT. */
> > > > > > +    const u32 hw_bin_std = 0x1;
> > > > > > +    const u32 hw_bin_elevated = 0x2;
> > > > > > +
> > > > > > +    /* Higher thermal profile identification for qcm6490/sc7280 bins. */
> > > > > > +    const u32 tsens_chip_id0 = 0x197;
> > > > > > +    const u32 tsens_chip_id1 = 0x198;
> > > > > > +    const u32 tsens_chip_id2 = 0x20e;
> > > > > > +    const u32 tsens_chip_id3 = 0x20f;
> > > > > > +    const u8 tsens_feat_id2 = 0x2;
> > > > > > +    const u8 tsens_feat_id3 = 0x3;
> > > > > > +    const u8 tsens_feat_id4 = 0x4;
> > > > >
> > > > > Isn't that (also) exposed over SMEM?
> > > >
> > > > Thanks Konrad, for review.
> > > >
> > > > SMEM has related socinfo data, but there is no exported helper for the
> > > > exact fields needed here, such as feat-id, which is also used as the bin
> > > > value.
> > >
> > > Is that different to qcom_smem_get_feature_code()?
> >
> > Thanks for review.
> > I am checking internally and will update with the exact difference from
> > feat-id. My understanding is that qcom_smem_get_feature_code() returns
> > the SMEM socinfo feature_code, while this code needs the QFPROM feat-id
> > field from the JTAG ID fuse word.
>
> I traced down some code, only managed to find the sources for newer
> SoCs. The JTAG ID is present in socinfo->raw_id. I have a Kodiak
> (QCM6490) phone on my desk - the JTAG_ID part of the fuse reads as
> 0x197 and the socinfo data reads the same. I attached a patch for you.
>
> The feature ID is not exposed via SMEM to the best of my knowledge so
> it needs to stay as a fuse.

Thanks for checking and for the help.
Since feat-id still needs QFPROM, let me use same implementation and 
source the bin data from nvmem. That also keeps the approach uniform 
across the targets handled by this series.

> Konrad
>
> > For this series, would prefer to keep the fuse-based path. The same
> > binding is also used by the generic i-temp fuse bit for Hamoa/future
> > targets, while the jtag-id/feat-id decoding remains only the
> > Kodiak/QCM6490-specific callback. Please let me know if you are fine with this approach.
> > > > This jtag-id/feat-id decoding is Kodiak/QCM6490-specific, and the
> > > > thermal-bin mapping needs both values. Other/future targets are expected
> > > > to use only the generic i-temp fuse bit, like Hamoa.
> > >
> > > So there are variants of kodiak that ""incorrectly"" set the feat_id?
> >
> > No, Kodiak is not incorrectly setting it.