On 30.01.2023 19:20, [email protected] wrote:
> From: Craig Tatlor <[email protected]>
>
> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> defined previously. Adjust the tsens offsets accordingly.
>
> [[email protected]: extract to standalone patch]
>
> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and qfprom nodes")
> Signed-off-by: Craig Tatlor <[email protected]>
> Signed-off-by: Luca Weiss <[email protected]>
> ---
Isn't this a raw vs ecc-corrected values problem?
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,
On Montag, 30. J?nner 2023 19:30:04 CET Konrad Dybcio wrote:
> On 30.01.2023 19:20, [email protected] wrote:
> > From: Craig Tatlor <[email protected]>
> >
> > The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> > defined previously. Adjust the tsens offsets accordingly.
> >
> > [[email protected]: extract to standalone patch]
> >
> > Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
> > qfprom nodes") Signed-off-by: Craig Tatlor <[email protected]>
> > Signed-off-by: Luca Weiss <[email protected]>
> > ---
>
> 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,
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, [email protected] wrote:
>>> From: Craig Tatlor <[email protected]>
>>>
>>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
>>> defined previously. Adjust the tsens offsets accordingly.
>>>
>>> [[email protected]: extract to standalone patch]
>>>
>>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
>>> qfprom nodes") Signed-off-by: Craig Tatlor <[email protected]>
>>> Signed-off-by: Luca Weiss <[email protected]>
>>> ---
>>
>> 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,
>
>
>
>
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, [email protected] wrote:
> >>> From: Craig Tatlor <[email protected]>
> >>>
> >>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> >>> defined previously. Adjust the tsens offsets accordingly.
> >>>
> >>> [[email protected]: extract to standalone patch]
> >>>
> >>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
> >>> qfprom nodes") Signed-off-by: Craig Tatlor <[email protected]>
> >>> Signed-off-by: Luca Weiss <[email protected]>
> >>> ---
> >>
> >> 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,
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, [email protected] wrote:
> > >>> From: Craig Tatlor <[email protected]>
> > >>>
> > >>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> > >>> defined previously. Adjust the tsens offsets accordingly.
> > >>>
> > >>> [[email protected]: extract to standalone patch]
> > >>>
> > >>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
> > >>> qfprom nodes") Signed-off-by: Craig Tatlor <[email protected]>
> > >>> Signed-off-by: Luca Weiss <[email protected]>
> > >>> ---
> > >>
> > >> 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,
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, [email protected] wrote:
>>>>>> From: Craig Tatlor <[email protected]>
>>>>>>
>>>>>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
>>>>>> defined previously. Adjust the tsens offsets accordingly.
>>>>>>
>>>>>> [[email protected]: extract to standalone patch]
>>>>>>
>>>>>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
>>>>>> qfprom nodes") Signed-off-by: Craig Tatlor <[email protected]>
>>>>>> Signed-off-by: Luca Weiss <[email protected]>
>>>>>> ---
>>>>>
>>>>> 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,
>
>
>
>
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, [email protected] wrote:
> >>>>>> From: Craig Tatlor <[email protected]>
> >>>>>>
> >>>>>> The qfprom actually starts at 0xfc4b8000 instead of 0xfc4bc000 as
> >>>>>> defined previously. Adjust the tsens offsets accordingly.
> >>>>>>
> >>>>>> [[email protected]: extract to standalone patch]
> >>>>>>
> >>>>>> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and
> >>>>>> qfprom nodes") Signed-off-by: Craig Tatlor <[email protected]>
> >>>>>> Signed-off-by: Luca Weiss <[email protected]>
> >>>>>> ---
> >>>>>
> >>>>> 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