Re: [PATCH RFC v2 4/5] ARM: dts: qcom: msm8974: add HDMI nodes

[Stephen Boyd]

Quoting Brian Masney (2019-10-08 23:05:20)
> On Tue, Oct 08, 2019 at 07:21:30PM -0700, Stephen Boyd wrote:
> > Quoting Brian Masney (2019-10-06 18:45:08)
> > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > index 7fc23e422cc5..af02eace14e2 100644
> > > --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > @@ -1335,6 +1342,77 @@
> > >                                 clocks = <&mmcc MDSS_AHB_CLK>;
> > >                                 clock-names = "iface";
> > >                         };
> > > +
> > > +                       hdmi: hdmi-tx@fd922100 {
> > > +                               status = "disabled";
> > > +
> > > +                               compatible = "qcom,hdmi-tx-8974";
> > > +                               reg = <0xfd922100 0x35c>,
> > > +                                     <0xfc4b8000 0x60f0>;
> > > +                               reg-names = "core_physical",
> > > +                                           "qfprom_physical";
> > 
> > Is this the qfprom "uncorrected" physical address? If so, why can't this
> > node use an nvmem to read whatever it needs out of the qfprom?
> 
> The MSM HDMI code is configured to look for this reg-name here:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/hdmi/hdmi.c#L582
> 
> There is a qcom,qfprom configured for this board in DTS, however its at
> a different address range, so maybe there are multiple qfproms?
> 
> https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/qcom-msm8974.dtsi#L424
> 
> msm8996.dtsi has the same style of configuration:
> 
> https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L956
> https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L1736
> 

There's only one qfprom and there's the address space that's
"uncorrected" which is not supposed to be used and there's the space
that is "corrected" and is supposed to be used. It looks like this is
poking the uncorrected space and it should probably stop doing that and
use the nvmem provider instead. Maybe someone with docs for this chip
and 8996 can help confirm this.