[PATCH 00/17] video: dw_hdmi: Support Vendor PHY

[Jagan Teki]

On Mon, Dec 18, 2023 at 7:23 PM Robin Murphy <robin.murphy at arm.com> wrote:
>
> On 2023-12-15 7:13 am, Kever Yang wrote:
> > Hi Jagan,
> >
> > On 2023/12/15 14:36, Jagan Teki wrote:
> >> Hi Heiko/Kerver/Anatoloj,
> >>
> >> On Mon, Dec 11, 2023 at 2:30 PM Jagan Teki
> >> <jagan at amarulasolutions.com> wrote:
> >>> Unlike RK3399, Sunxi/Meson DW HDMI the new Rockchip SoC Rk3328 would
> >>> support external vendor PHY with DW HDMI chip.
> >>>
> >>> Support this vendor PHY by adding new platform PHY ops via DW HDMI
> >>> driver and call the respective generic phy from platform driver code.
> >>>
> >>> This series tested in RK3328 with 1080p (1920x1080) resolution.
> >>>
> >>> Patch 0001/0005: Support Vendor PHY
> >>> Patch 0006/0008: VOP extension for win, dsp offsets
> >>> Patch 0009/0010: RK3328 VOP, HDMI clocks
> >>> Patch 0011:      Rockchip Inno HDMI PHY
> >>> Patch 0012:      RK3328 HDMI driver
> >>> Patch 0013:      RK3328 VOP driver
> >>> Patch 0014/0017: Enable HDMI Out for RK3328
> >>>
> >>> Importent:
> >>> One pontential issues is that Linux HDMI out on RK3328 has effected by
> >>> this patchset as I wouldn't find any relation or clue.
> >>>
> >>> [    0.752016] Loading compiled-in X.509 certificates
> >>> [    0.787796] inno_hdmi_phy_rk3328_clk_recalc_rate: parent 24000000
> >>> [    0.788391] inno-hdmi-phy ff430000.phy:
> >>> inno_hdmi_phy_rk3328_clk_recalc_rate rate 148500000 vco 148500000
> >>> [    0.798353] rockchip-drm display-subsystem: bound ff370000.vop
> >>> (ops vop_component_ops)
> >>> [    0.799403] dwhdmi-rockchip ff3c0000.hdmi: supply avdd-0v9 not
> >>> found, using dummy regulator
> >>> [    0.800288] rk_iommu ff373f00.iommu: Enable stall request timed
> >>> out, status: 0x00004b
> >>> [    0.801131] dwhdmi-rockchip ff3c0000.hdmi: supply avdd-1v8 not
> >>> found, using dummy regulator
> >>> [    0.802056] rk_iommu ff373f00.iommu: Disable paging request timed
> >>> out, status: 0x00004b
> >>> [    0.803233] dwhdmi-rockchip ff3c0000.hdmi: Detected HDMI TX
> >>> controller v2.11a with HDCP (inno_dw_hdmi_phy2)
> >>> [    0.805355] dwhdmi-rockchip ff3c0000.hdmi: registered DesignWare
> >>> HDMI I2C bus driver
> >>> [    0.808769] rockchip-drm display-subsystem: bound ff3c0000.hdmi
> >>> (ops dw_hdmi_rockchip_ops)
> >>> [    0.810869] [drm] Initialized rockchip 1.0.0 20140818 for
> >>> display-subsystem on minor 0
> >>>
> >>> The only way I can use Linux HDMI by disabling IOMMU or support
> >>> disable-iommu link for RK3328 via DT [1].
> >>>
> >>> [1] https://www.spinics.net/lists/devicetree/msg605124.html
> >> Is anyone aware of this issue? I did post the patches for Linux IOMMU
> >> but seems not a proper solution. Any suggestions?
> >
> > I'm not expert in HDMI/VOP, so I can't provide a suitable solution in
> > the kernel,
> >
> > but here is the reason why we need patch to workaround the issue in the
> > kernel:
> >
> > - The VOP driver working in U-Boot is non-IOMMU mode, and the VOP access
> > DDR by physical address;
> >
> > - The VOP driver working in kernel with IOMMU enabled(by default), the
> > VOP access DDR with virtual address(by IOMMU);
> >
> > - The VOP is keep working in kernel before kernel VOP driver is enabled,
> > and the IOMMU driver will be enabled by
> >
> >     the Linux PM framework, since the IOMMU is not correctly configured
> > at this point, the VOP will access unknown
> >
> >      space(the original physical address in U-Boot) convert by IOMMU;
> >
> > So we need to disable the IOMMU temporary in kernel startup before VOP
> > driver is enabled.
>
> If U-Boot isn't handing off an active framebuffer, then it should be
> U-Boot's responsibility to stop the VOP before it exits; if on the other
> hand it is, then it can now use the "iommu-addresses" DT property (see
> the reserved-memory schema) on the framebuffer region, and we should
> just need a bit of work in the IOMMU driver to ensure that is respected
> during the period between the IOMMU initialising and the Linux VOP
> driver subsequently taking over (i.e. so it won't get stuck on an
> unexpected page fault as seems to be happening above). The IOMMU aspect
> of that ought to be fairly straightforward; the trickier part might be
> the runtime PM aspect to ensure the IOMMU doesn't let itself go idle and
> actually turn anything off during that period. I also still think that
> doing the full rk_iommu_disable() upon runtime suspend is wrong, but
> that's more of a thing which confounds the underlying issue here, rather
> than being the problem in itself.

Thanks for your comments. Okay, keeping the Linux IOMMU issue aside I
think whatever change that u-boot makes on VOP has to clear it before
handoff to Linux - so clearing the VOP registers during handoff seems
working. I only wonder why it happens only on RK3328 (RK3399 and
RK3288 seem fine).

I will post the next version with VOP clear during handoff.

Thanks,
Jagan.