On 7/19/22 4:09 PM, Konrad Dybcio wrote:
On 18.07.2022 08:34, bhupesh.sharma@xxxxxxxxxx wrote:
Hi Konrad,
On 7/15/22 8:26 PM, Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxx> wrote:
On 1.07.2022 16:58, Bhupesh Sharma wrote:
Since for some QCoM tsens controllers, its suggested to
monitor the controller health periodically and in case an
issue is detected, to re-initialize the tsens controller
via trustzone, add the support for the same in the
qcom tsens driver.
Note that Once the tsens controller is reset using scm call,
all SROT and TM region registers will enter the reset mode.
While all the SROT registers will be re-programmed and
re-enabled in trustzone prior to the scm call exit, the TM
region registers will not re-initialized in trustzone and thus
need to be handled by the tsens driver.
Cc: Amit Kucheria <amitk@xxxxxxxxxx>
Cc: Thara Gopinath <thara.gopinath@xxxxxxxxx>
Cc: linux-pm@xxxxxxxxxxxxxxx
Cc: linux-arm-msm@xxxxxxxxxxxxxxx
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@xxxxxxxxxx>
Reported-by: kernel test robot <lkp@xxxxxxxxx>
---
Hi, I think this should be also checked and applied on init. This
seems required for at least SM6375, as the controller starts (or
well, doesn't start...) in an unknown state and the driver does
not like it, as the TSENS_EN indicates it is disabled.
Downstream runs this right at probe..
Hmm.. very interesting. I was not aware of the SM6375 case, as for SM8150
the controller starts in a valid state but may require reinit during operation.
So, I did not use the downstream approach to do it right at _probe() and then
later while get_temp() is called.
Let me add that in v2. BTW do you want me to set the need_reinit_wa as true
for SM6375 as well, or would you like to add that with a followup-patch ?
Please set it, I'll happily test it!
Thanks. Will share v2 shortly.
Regards,
Bhupesh
