| Message ID | 20231211085939.5478-1-jagan@amarulasolutions.com |
|---|---|
| Headers | show |
| Series | video: dw_hdmi: Support Vendor PHY | expand |
Hi Heiko/Kerver/Anatoloj, On Mon, Dec 11, 2023 at 2:30 PM Jagan Teki <jagan@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? Thanks, Jagan.
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@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. Thanks, - Kever > > Thanks, > Jagan.
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@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, Robin.
On Mon, Dec 18, 2023 at 7:23 PM Robin Murphy <robin.murphy@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@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.