On 19.04.2023 18:00, Luca Weiss wrote:
> Hi Konrad,
>
> On Montag, 30. Jänner 2023 21:37:29 CEST Luca Weiss wrote:
>> On Montag, 30. Jänner 2023 19:42:51 CET Konrad Dybcio wrote:
>>> On 30.01.2023 19:36, Luca Weiss wrote:
>>>> On Montag, 30. Jänner 2023 19:30:04 CET Konrad Dybcio wrote:
>>>>> On 30.01.2023 19:20, luca@xxxxxxxxx wrote:
>>>>>> From: Craig Tatlor <ctatlor97@xxxxxxxxx>
>>>>>>
>>>>>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
>>>>>> defined previously. Adjust the tsens offsets accordingly.
>>>>>>
>>>>>> [luca@xxxxxxxxx: extract to standalone patch]
>>>>>>
>>>>>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
>>>>>> qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@xxxxxxxxx>
>>>>>> Signed-off-by: Luca Weiss <luca@xxxxxxxxx>
>>>>>> ---
>>>>>
>>>>> Isn't this a raw vs ecc-corrected values problem?
>>>>
>>>> Not quite sure what you mean.
>>>
>>> The QFPROM is split into two parts: one where raw values
>>> are stored, and the other one where ECC-corrected copies
>>> of them reside. Usually it's at offset of 0x4000. We should
>>> generally be using the ECC-corrected ones, because.. well..
>>> they are ECC-corrected.. You may want to check if the
>>> fuse you're adding reads the same value at +0x4000.
>>
>> Yeah that actually seems to work...
>>
>> But downstream's using this +0x4000 only for tsens it seems
>>
>> <0xfc4bc000 0x1000> as "tsens_eeprom_physical"
>>
>> qcom,clock-krait-8974 is using this:
>>
>> <0xfc4b80b0 0x08> as "efuse"
>>
>> Also seems HDMI driver is using a mix for HDCP stuff
>>
>> drivers/video/msm/mdss/mdss_hdmi_util.h:
>>
>> /* QFPROM Registers for HDMI/HDCP */
>> #define QFPROM_RAW_FEAT_CONFIG_ROW0_LSB (0x000000F8)
>> #define QFPROM_RAW_FEAT_CONFIG_ROW0_MSB (0x000000FC)
>> #define HDCP_KSV_LSB (0x000060D8)
>> #define HDCP_KSV_MSB (0x000060DC)
>>
>> Any clue why Qualcomm used it this way in downstream? I'd rather not deviate
>> too much if not for a good reason...
>
> Any comments on the above?
This thread got burried to deep in the mailbox!
I see two reasons why they could be using the uncorrected region:
- their generators are messed up in general
- they may have had an early chip revision once where there were
problems with this and their generators were messed up to
accommodate for it and everybody forgot to fix that
No other good explanations as far as I'm aware!
Konrad
>
> Regards
> Luca
>
>>
>> Regards
>> Luca
>>
>>> Konrad
>>>
>>>> The original intention behind this patch is to allow to use the pvs fuse
>>>> at
>>>> (now) 0xb0 which was inaccessible with the former definition.
>>>>
>>>> pvs: pvs@b0 {
>>>>
>>>> reg = <0xb0 0x8>;
>>>>
>>>> };
>>>>
>>>> Regards
>>>> Luca
>>>>
>>>>> Konrad
>>>>>
>>>>>> arch/arm/boot/dts/qcom-msm8974.dtsi | 12 ++++++------
>>>>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>>>> b/arch/arm/boot/dts/qcom-msm8974.dtsi index 8d216a3c0851..922d235c6065
>>>>>> 100644
>>>>>> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>>>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>>>>>> @@ -1132,16 +1132,16 @@ restart@fc4ab000 {
>>>>>>
>>>>>> reg = <0xfc4ab000 0x4>;
>>>>>>
>>>>>> };
>>>>>>
>>>>>> - qfprom: qfprom@fc4bc000 {
>>>>>> + qfprom: qfprom@fc4b8000 {
>>>>>>
>>>>>> compatible = "qcom,msm8974-qfprom",
>>>>
>>>> "qcom,qfprom";
>>>>
>>>>>> - reg = <0xfc4bc000 0x1000>;
>>>>>> + reg = <0xfc4b8000 0x7000>;
>>>>>>
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <1>;
>>>>>>
>>>>>> - tsens_calib: calib@d0 {
>>>>>> - reg = <0xd0 0x18>;
>>>>>> + tsens_calib: calib@40d0 {
>>>>>> + reg = <0x40d0 0x18>;
>>>>>>
>>>>>> };
>>>>>>
>>>>>> - tsens_backup: backup@440 {
>>>>>> - reg = <0x440 0x10>;
>>>>>> + tsens_backup: backup@4440 {
>>>>>> + reg = <0x4440 0x10>;
>>>>>>
>>>>>> };
>>>>>>
>>>>>> };
>>>>>>
>>>>>> ---
>>>>>> base-commit: 6d796c50f84ca79f1722bb131799e5a5710c4700
>>>>>> change-id: 20230130-msm8974-qfprom-619c0e8f26eb
>>>>>>
>>>>>> Best regards,
>
>
>
>
