Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 6 Apr 2023 18:20:34 +0200
From:   Stephan Gerhold <stephan@gerhold.net>
To:     Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc:     amitk@kernel.org, thara.gopinath@gmail.com, agross@kernel.org,
        andersson@kernel.org, konrad.dybcio@linaro.org, rafael@kernel.org,
        daniel.lezcano@linaro.org, rui.zhang@intel.com,
        dmitry.baryshkov@linaro.org, linux-pm@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] drivers/thermal/qcom/tsens: Add ability to read and
 shift-in non-contiguous calibration data
Message-ID: <ZC7xSG7qVZ7vlOB7@gerhold.net>
References: <20230406145850.357296-1-bryan.odonoghue@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230406145850.357296-1-bryan.odonoghue@linaro.org>
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, Apr 06, 2023 at 03:58:47PM +0100, Bryan O'Donoghue wrote:
> On MSM8939 the last sensor has calibration data that cannot be extracted in
> one big read.
> 
> Rather than have a lot of MSM8939 specific code this series makes a generic
> modification to allow any other calibration data that is non-contiguous to
> be extracted and recovered.
> 
> For example s9-p2 takes bits 1-5 from @4b and bit 13 from @4d. The bit from
> bit13 then becomes the sixth bit in the calibration data.
> 
> tsens_s9_p2: s9-p2@4b {
>     reg = <0x4b 0x1>;
>     bits = <1 5>;
> };
> 
> tsens_s9_p2_msb: s9-p2-msb@4d {
>     reg = <0x4d 0x1>;
>     bits = <13 1>;
> };

As far as I can tell the sensor with the non-contiguous calibration data
is the one with hwid=10, so do you mean s10-p2 instead of s9-p2 here?

It's easy to mix up the numbering: Since hwid=4 is missing for MSM8939,
the sensor 9 in the calibration code downstream (TSENS9_8939_POINT*)
actually refers to hwid=10. hwid=9 is sensor 8 in the calibration code
(TSENS8_8939_POINT*).

Sensor hwid=10 was disabled for MSM8939 in the tsens driver because it
seems unused, only exists on MSM8939 v3.0, and specifically to avoid
having to handle this non-contiguous calibration data, see commit
903238a33c11 ("thermal/drivers/tsens: limit num_sensors to 9 for msm8939"):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=903238a33c116edf5f64f7a3fd246e6169cccfa6

> On msm8939 last (hwid=10) sensor was added in the hw revision 3.0.
> Calibration data for it was placed outside of the main calibration  
> data blob, so it is not accessible by the current blob-parsing code.
>
> Moreover data for the sensor's p2 is not contiguous in the fuses. This
> makes it hard to use nvmem_cell API to parse calibration data in a
> generic way.
>
> Since the sensor doesn't seem to be actually used by the existing
> hardware, disable the sensor for now.
>
> Fixes: 332bc8ebab2c ("thermal: qcom: tsens-v0_1: Add support for MSM8939")
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

So with sensor hwid=10 disabled, I think this patch series is actually
not needed? :)

Thanks,
Stephan