On Mon, Dec 18, 2023 at 7:23 PM Robin Murphy <robin.mur...@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 > >> <ja...@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.