Hi Robin,
Am Dienstag, 20. Februar 2018, 14:14:31 CET schrieb Robin Murphy:
> On 16/02/18 22:38, Heiko Stuebner wrote:
> > Add the chain of display nodes from the core display-subsystem
> > through the one vop to the dw-hdmi output.
> >
> > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 56 ++++++++++++++++++++++++++++++++
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > index 1615effcc191..65b7d460a044 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > @@ -185,6 +185,11 @@
> > interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> > };
> >
> > + display_subsystem: display-subsystem {
> > + compatible = "rockchip,display-subsystem";
> > + ports = <&vop_out>;
> > + };
> > +
> > psci {
> > compatible = "arm,psci-1.0", "arm,psci-0.2";
> > method = "smc";
> > @@ -626,6 +631,28 @@
> > status = "disabled";
> > };
> >
> > + vop: vop at ff370000 {
> > + compatible = "rockchip,rk3328-vop";
> > + reg = <0x0 0xff370000 0x0 0x3efc>;
> > + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>;
>
> Another of those rogue trailing zero cells has snuck in here.
Oh great.
Either they are missing when needed or trailing when not needed :-) .
> <digression>
> Unfortunately, even having learned the difference between drm-next and
> drm-misc-next (thanks for the pointer!) so I could apply this and the
> other series, I only managed to get it to not-quite-work on the box I'm
> currently reverse-engineering a mainline DT for (Beelink A1).
>
> I've got a monitor connected via HDMI-DVI (which the stock 3.10 Android
> kernel *does* drive happily) - it appears to be detected, but when the
> virtual console tries to come up I just see a handful of timeout splats
> from drm_atomic_helper_wait_for_vblanks() and no signal at the monitor.
>
> Any idea where to start debugging? (I'm 99% certain I had your clk/next
> branch pulled in as well since it looked significant, but I'll
> double-check tonight)
I guess first interesting point would be to check if the edid of the monitor
got read correctly. There are a bunch of funny GRF options related to i2c
voltages and such that get wiggled on hotplug events and they're not
really documented at all. (see all the *_5V_* constants in the dw-hdmi).
In my current setup (with a VS0801H hdmi switch between my boardfarm
and display) it's reading the monitor edid correctly every time, but I
remember having lots of issues with getting an actual edid at all.
I may need to check without the switch if this somehow improves the
situation in my installation.
Also, you could give Rockchip's 4.4 vendor kernel a try [0]. I wasn't even
aware that rk3328 boxes used a 3.10 kernel in the wild :-) . The 4.4 kernel
was similarly picky with my monitors edid, if I remember correctly.
Maybe also check your regulators (if any) if they get turned off.
And finally, for completenes sake, I do have a branch sitting on top of
lima kernel patches and recent mainline that includes everything and
does bring up the display [and partial gpu support :-) ] for me at [1].
Heiko
[0] https://github.com/rockchip-linux/kernel
[1] https://github.com/mmind/linux-rockchip/tree/devel/lima-yuq-mali450
