diff mbox series

ARM: dts: qcom: msm8974: correct qfprom node reg

Message ID 20230130-msm8974-qfprom-v1-1-975aa0e5e083@z3ntu.xyz
State New
Headers
Series ARM: dts: qcom: msm8974: correct qfprom node reg |

Commit Message

Luca Weiss Jan. 30, 2023, 6:20 p.m. UTC 
  From: Craig Tatlor <ctatlor97@gmail.com>

The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
defined previously. Adjust the tsens offsets accordingly.

[luca@z3ntu.xyz: extract to standalone patch]

Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and qfprom nodes")
Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)


---
base-commit: 6d796c50f84ca79f1722bb131799e5a5710c4700
change-id: 20230130-msm8974-qfprom-619c0e8f26eb

Best regards,

Comments

Luca Weiss Jan. 30, 2023, 6:36 p.m. UTC | #1 
On Montag, 30. Jänner 2023 19:30:04 CET Konrad Dybcio wrote:
> On 30.01.2023 19:20, luca@z3ntu.xyz wrote:
> > From: Craig Tatlor <ctatlor97@gmail.com>
> > 
> > The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> > defined previously. Adjust the tsens offsets accordingly.
> > 
> > [luca@z3ntu.xyz: extract to standalone patch]
> > 
> > Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
> > qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
> > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > ---
> 
> Isn't this a raw vs ecc-corrected values problem?

Not quite sure what you mean.

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,
Konrad Dybcio Jan. 30, 2023, 6:42 p.m. UTC | #2 
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@z3ntu.xyz wrote:
>>> From: Craig Tatlor <ctatlor97@gmail.com>
>>>
>>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
>>> defined previously. Adjust the tsens offsets accordingly.
>>>
>>> [luca@z3ntu.xyz: extract to standalone patch]
>>>
>>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
>>> qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
>>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
>>> ---
>>
>> 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.

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,
> 
> 
> 
>
Luca Weiss Jan. 30, 2023, 8:37 p.m. UTC | #3 
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@z3ntu.xyz wrote:
> >>> From: Craig Tatlor <ctatlor97@gmail.com>
> >>> 
> >>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> >>> defined previously. Adjust the tsens offsets accordingly.
> >>> 
> >>> [luca@z3ntu.xyz: extract to standalone patch]
> >>> 
> >>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
> >>> qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
> >>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> >>> ---
> >> 
> >> 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...

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,
Luca Weiss April 19, 2023, 4 p.m. UTC | #4 
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@z3ntu.xyz wrote:
> > >>> From: Craig Tatlor <ctatlor97@gmail.com>
> > >>> 
> > >>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> > >>> defined previously. Adjust the tsens offsets accordingly.
> > >>> 
> > >>> [luca@z3ntu.xyz: extract to standalone patch]
> > >>> 
> > >>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
> > >>> qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
> > >>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > >>> ---
> > >> 
> > >> 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?

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,
Konrad Dybcio April 19, 2023, 4:12 p.m. UTC | #5 
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@z3ntu.xyz wrote:
>>>>>> From: Craig Tatlor <ctatlor97@gmail.com>
>>>>>>
>>>>>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
>>>>>> defined previously. Adjust the tsens offsets accordingly.
>>>>>>
>>>>>> [luca@z3ntu.xyz: extract to standalone patch]
>>>>>>
>>>>>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
>>>>>> qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
>>>>>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
>>>>>> ---
>>>>>
>>>>> 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,
> 
> 
> 
>
Luca Weiss April 19, 2023, 4:18 p.m. UTC | #6 
On Mittwoch, 19. April 2023 18:12:04 CEST Konrad Dybcio wrote:
> 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@z3ntu.xyz wrote:
> >>>>>> From: Craig Tatlor <ctatlor97@gmail.com>
> >>>>>> 
> >>>>>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> >>>>>> defined previously. Adjust the tsens offsets accordingly.
> >>>>>> 
> >>>>>> [luca@z3ntu.xyz: extract to standalone patch]
> >>>>>> 
> >>>>>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
> >>>>>> qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
> >>>>>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> >>>>>> ---
> >>>>> 
> >>>>> 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!

So, resolution is to use the offsets as declared in downstream, so take this 
patch to have the full range available?

Regards
Luca
Konrad Dybcio April 19, 2023, 4:20 p.m. UTC | #7 
On 19.04.2023 18:18, Luca Weiss wrote:
> On Mittwoch, 19. April 2023 18:12:04 CEST Konrad Dybcio wrote:
>> 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@z3ntu.xyz wrote:
>>>>>>>> From: Craig Tatlor <ctatlor97@gmail.com>
>>>>>>>>
>>>>>>>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
>>>>>>>> defined previously. Adjust the tsens offsets accordingly.
>>>>>>>>
>>>>>>>> [luca@z3ntu.xyz: extract to standalone patch]
>>>>>>>>
>>>>>>>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
>>>>>>>> qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@gmail.com>
>>>>>>>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
>>>>>>>> ---
>>>>>>>
>>>>>>> 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!
> 
> So, resolution is to use the offsets as declared in downstream, so take this 
> patch to have the full range available?
No, the correct resolution to "fix QFPROM reg" would be to
increase the size to 0x7000-0x4000 = 0x3000, as we should be
using the ECC-corrected entries.

Konrad
> 
> Regards
> Luca
> 
> 
>
diff mbox series

Patch

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>;
 			};
 		};