| Message ID | 20220126145549.617165-1-s.hauer@pengutronix.de |
|---|---|
| Headers | show |
| Series | drm/rockchip: RK356x VOP2 support | expand |
Hi, On Wed, Jan 26, 2022 at 6:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote: > > From: Douglas Anderson <dianders@chromium.org> > > Jitter was improved by lowering the MPLL bandwidth to account for high > frequency noise in the rk3288 PLL. In each case MPLL bandwidth was > lowered only enough to get us a comfortable margin. We believe that > lowering the bandwidth like this is safe given sufficient testing. > > Changes since v3: > - new patch > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > Signed-off-by: Yakir Yang <ykk@rock-chips.com> > (am from https://patchwork.kernel.org/patch/9223301/) Probably remove the "am from" line? It's not standard in upstream and that link doesn't seem to go anywhere anymore... > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 ++-------------- > 1 file changed, 2 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > index c44eb4d2e2d5..77f82a4fd027 100644 > --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > @@ -176,20 +176,8 @@ static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = { > static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = { > /* pixelclk bpp8 bpp10 bpp12 */ > { > - 40000000, { 0x0018, 0x0018, 0x0018 }, > - }, { > - 65000000, { 0x0028, 0x0028, 0x0028 }, > - }, { > - 66000000, { 0x0038, 0x0038, 0x0038 }, > - }, { > - 74250000, { 0x0028, 0x0038, 0x0038 }, > - }, { > - 83500000, { 0x0028, 0x0038, 0x0038 }, > - }, { > - 146250000, { 0x0038, 0x0038, 0x0038 }, > - }, { > - 148500000, { 0x0000, 0x0038, 0x0038 }, > - }, { > + 600000000, { 0x0000, 0x0000, 0x0000 }, > + }, { This is what we did for rk3288. I can't personally vouch for the effects on other SoCs. -Doug
Hi, On Wed, Jan 26, 2022 at 6:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote: > > From: Douglas Anderson <dianders at chromium.org> > > The previous tables for mpll_cfg and curr_ctrl were created using the > 20-pages of example settings provided by the PHY vendor. Those > example settings weren't particularly dense, so there were places > where we were guessing what the settings would be for 10-bit and > 12-bit (not that we use those anyway). It was also always a lot of > extra work every time we wanted to add a new clock rate since we had > to cross-reference several tables. > > In <http://crosreview.com/285855> I've gone through the work to figure The `crosreview.com` syntax doesn't seem to work anymore. Could maybe update to https://crrev.com/c/285855 ? > out how to generate this table automatically. Let's now use the > automatically generated table and then we'll never need to look at it > again. > > We only support 8-bit mode right now and only support a small number > of clock rates and and I've verified that the only 8-bit rate that was > affected was 148.5. That mode appears to have been wrong in the old > table. > > Changes since v3: > - new patch > > Signed-off-by: Douglas Anderson <dianders at chromium.org> > Signed-off-by: Yakir Yang <ykk at rock-chips.com> Should probably change the "at" to "@" ? > Reviewed-by: Stéphane Marchesin <marcheu at chromium.org> In general shouldn't carry downstream reviews when posting upstream unless you're certain that the person intended it... It's been a long time, but in general I think I was fairly confident in the numbers that my script pumped out, at least given the caveat of no pixel repetition and 8-bit only. That being said, I didn't have any inside knowledge of the hardware and just figured out formulas that seemed to match the table that I had. YMMV. I'll also say that when I did a rebase of veyron (rk3288-based Chromebook) to 4.19 about 2.5 years ago, I ended up squashing several of these patches into 1. That can be found at <https://crrev.com/c/1661056>. That also has details about why some of these patches never made it upstream. The main reason, at least in the case of rk3288, was the PLL sharing problem that nobody ever solved. rk3288 didn't have quite enough PLLs and thus, if you were using both VOPs, one of the VOPs was going to be severely limited in what pixel clocks it could make. There was no framework deciding which VOP should be limited and how the system should react to this... In any case, I'm pretty far disconnected from all this stuff now, but I wish you the best of luck in trying to get it all solved! -Doug
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote: > > Add support for the HDMI port found on RK3568. > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++- > 1 file changed, 36 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > index 4008bd666d01..e38fb223e9b8 100644 > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > @@ -10,7 +10,6 @@ > #include <dt-bindings/pinctrl/rockchip.h> > #include <dt-bindings/power/rk3568-power.h> > #include <dt-bindings/soc/rockchip,boot-mode.h> > -#include <dt-bindings/soc/rockchip,vop2.h> > #include <dt-bindings/thermal/thermal.h> > > / { > @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 { > status = "disabled"; > }; > > + hdmi: hdmi@fe0a0000 { > + compatible = "rockchip,rk3568-dw-hdmi"; > + reg = <0x0 0xfe0a0000 0x0 0x20000>; > + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&cru PCLK_HDMI_HOST>, > + <&cru CLK_HDMI_SFR>, > + <&cru CLK_HDMI_CEC>, > + <&pmucru CLK_HDMI_REF>, > + <&cru HCLK_VOP>; > + clock-names = "iahb", "isfr", "cec", "ref", "hclk"; > + pinctrl-names = "default"; > + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>; I looked into CEC support here, and it seems that it does work with one change. Please add the two following lines to your patch: assigned-clocks = <&cru CLK_HDMI_CEC>; assigned-clock-rates = <32768>; The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to function. > + power-domains = <&power RK3568_PD_VO>; > + reg-io-width = <4>; > + rockchip,grf = <&grf>; > + #sound-dai-cells = <0>; > + status = "disabled"; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + hdmi_in: port@0 { > + reg = <0>; > + #address-cells = <1>; > + #size-cells = <0>; > + }; > + > + hdmi_out: port@1 { > + reg = <1>; > + #address-cells = <1>; > + #size-cells = <0>; > + }; > + }; > + }; > + > qos_gpu: qos@fe128000 { > compatible = "rockchip,rk3568-qos", "syscon"; > reg = <0x0 0xfe128000 0x0 0x20>; > -- > 2.30.2 >
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2022-01-26 16:04, Peter Geis wrote: > > On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote: > >> > >> Add support for the HDMI port found on RK3568. > >> > >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > >> --- > >> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++- > >> 1 file changed, 36 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > >> index 4008bd666d01..e38fb223e9b8 100644 > >> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi > >> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > >> @@ -10,7 +10,6 @@ > >> #include <dt-bindings/pinctrl/rockchip.h> > >> #include <dt-bindings/power/rk3568-power.h> > >> #include <dt-bindings/soc/rockchip,boot-mode.h> > >> -#include <dt-bindings/soc/rockchip,vop2.h> > >> #include <dt-bindings/thermal/thermal.h> > >> > >> / { > >> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 { > >> status = "disabled"; > >> }; > >> > >> + hdmi: hdmi@fe0a0000 { > >> + compatible = "rockchip,rk3568-dw-hdmi"; > >> + reg = <0x0 0xfe0a0000 0x0 0x20000>; > >> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; > >> + clocks = <&cru PCLK_HDMI_HOST>, > >> + <&cru CLK_HDMI_SFR>, > >> + <&cru CLK_HDMI_CEC>, > >> + <&pmucru CLK_HDMI_REF>, > >> + <&cru HCLK_VOP>; > >> + clock-names = "iahb", "isfr", "cec", "ref", "hclk"; > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>; > > > > I looked into CEC support here, and it seems that it does work with one change. > > Please add the two following lines to your patch: > > assigned-clocks = <&cru CLK_HDMI_CEC>; > > assigned-clock-rates = <32768>; > > > > The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which > > feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to > > function. > > Wouldn't it make far more sense to just stick a suitable clk_set_rate() > call in the driver? AFAICS it's already explicitly aware of the CEC clock. This is handled purely in the drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to touch it there as it would affect all users, not just Rockchip. Could someone familiar with the dw-hdmi IP weigh in on the minimum and maximum clock rate the CEC block can handle? > > Robin. > > >> + power-domains = <&power RK3568_PD_VO>; > >> + reg-io-width = <4>; > >> + rockchip,grf = <&grf>; > >> + #sound-dai-cells = <0>; > >> + status = "disabled"; > >> + > >> + ports { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + hdmi_in: port@0 { > >> + reg = <0>; > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + }; > >> + > >> + hdmi_out: port@1 { > >> + reg = <1>; > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + }; > >> + }; > >> + }; > >> + > >> qos_gpu: qos@fe128000 { > >> compatible = "rockchip,rk3568-qos", "syscon"; > >> reg = <0x0 0xfe128000 0x0 0x20>; > >> -- > >> 2.30.2 > >> > > > > _______________________________________________ > > Linux-rockchip mailing list > > Linux-rockchip@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-rockchip
On 2022-01-26 18:44, Peter Geis wrote: > On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy <robin.murphy@arm.com> wrote: >> >> On 2022-01-26 16:04, Peter Geis wrote: >>> On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote: >>>> >>>> Add support for the HDMI port found on RK3568. >>>> >>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> >>>> --- >>>> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++- >>>> 1 file changed, 36 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi >>>> index 4008bd666d01..e38fb223e9b8 100644 >>>> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi >>>> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi >>>> @@ -10,7 +10,6 @@ >>>> #include <dt-bindings/pinctrl/rockchip.h> >>>> #include <dt-bindings/power/rk3568-power.h> >>>> #include <dt-bindings/soc/rockchip,boot-mode.h> >>>> -#include <dt-bindings/soc/rockchip,vop2.h> >>>> #include <dt-bindings/thermal/thermal.h> >>>> >>>> / { >>>> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 { >>>> status = "disabled"; >>>> }; >>>> >>>> + hdmi: hdmi@fe0a0000 { >>>> + compatible = "rockchip,rk3568-dw-hdmi"; >>>> + reg = <0x0 0xfe0a0000 0x0 0x20000>; >>>> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; >>>> + clocks = <&cru PCLK_HDMI_HOST>, >>>> + <&cru CLK_HDMI_SFR>, >>>> + <&cru CLK_HDMI_CEC>, >>>> + <&pmucru CLK_HDMI_REF>, >>>> + <&cru HCLK_VOP>; >>>> + clock-names = "iahb", "isfr", "cec", "ref", "hclk"; >>>> + pinctrl-names = "default"; >>>> + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>; >>> >>> I looked into CEC support here, and it seems that it does work with one change. >>> Please add the two following lines to your patch: >>> assigned-clocks = <&cru CLK_HDMI_CEC>; >>> assigned-clock-rates = <32768>; >>> >>> The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which >>> feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to >>> function. >> >> Wouldn't it make far more sense to just stick a suitable clk_set_rate() >> call in the driver? AFAICS it's already explicitly aware of the CEC clock. > > This is handled purely in the > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to > touch it there as it would affect all users, not just Rockchip. I'd have a strong hunch that it's a standard thing for the DesignWare IP and not affected by platform integration. I don't have the magical Synopsys databook, but between the trusty old i.MX6 manual and most of the other in-tree DTs getting their dw-hdmi "cec" clock from suspiciously-obviously-named sources, I'd be somewhat surprised if it was ever anything other than 32KHz. Robin. > Could someone familiar with the dw-hdmi IP weigh in on the minimum and > maximum clock rate the CEC block can handle? > >> >> Robin. >> >>>> + power-domains = <&power RK3568_PD_VO>; >>>> + reg-io-width = <4>; >>>> + rockchip,grf = <&grf>; >>>> + #sound-dai-cells = <0>; >>>> + status = "disabled"; >>>> + >>>> + ports { >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + >>>> + hdmi_in: port@0 { >>>> + reg = <0>; >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + }; >>>> + >>>> + hdmi_out: port@1 { >>>> + reg = <1>; >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + }; >>>> + }; >>>> + }; >>>> + >>>> qos_gpu: qos@fe128000 { >>>> compatible = "rockchip,rk3568-qos", "syscon"; >>>> reg = <0x0 0xfe128000 0x0 0x20>; >>>> -- >>>> 2.30.2 >>>> >>> >>> _______________________________________________ >>> Linux-rockchip mailing list >>> Linux-rockchip@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
On Thu, Jan 27, 2022 at 10:17:13AM +0100, Piotr Oniszczuk wrote: > Sascha, > > FYI > small report regarding 4k modes support in v4: > > -on rk3399 it gives me 4k screen where right vertical 1/3 part of screen is garbage > -on rk3566 my samsung 4k monitor has black screen and cycle of OSD msgs: HDMI2 connected; HDMI2 disconnected; .... Same here on my rk3568, also with a samsung monitor. Was it 4k@60Hz or 4k@30Hz? If the former, could you give 4k@30Hz a try? That mode works well here. > > I would suggest split v4 into 2 separated series: Yeah, splitting up the series makes sense. At the moment I have it all in one series to ease others testing it. Sascha > > -VOP2 support > -HDMI 4k modes support > > BTW: getting well working 4k HDMI modes on rk3399 was real story for me. > There is many different series of patches to address this - but all have some subtle issues for me (i.e. 4k HDMI modes works but i.e. Qt is failing with DRM atomic commits in EGLFS) > I developed well working [1] giving me reliable 4k on rk3399 (including working Qt DRM drawing in EGLFS mode) > Maybe it will be somehow helpful to get 4k modes solution for rk3566 _and_ rk3399 (on single kernel binary)? > > [1] https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.16/files/0730-drm-rockchip-add-4k-videomodes-support.patch At least there are patches in it that I have in my series as well and keep popping up everywhere like "drm/rockchip: dw_hdmi: Use auto-generated tables" and "drm/rockchip: dw_hdmi: Set cur_ctr to 0 always" Sascha
Hello Sascha, On 1/26/22 15:55, Sascha Hauer wrote: > This is v4 of adding RK356x VOP2 support. Due to popular demand I added > a changelog to each patch, at least starting with changes to v3, I > didn't care to add the older changes as well. I hopefully integrated all > feedback I received to v3. Additionally I added some patches to the HDMI > driver to support resolutions up to 4k@60Hz. The patches are mostly > taken from the downstream kernel. Some have been send to public lists, > but were never applied upstream for reasons I do not know. The patches > are a bit more intrusive than needed for my case, but are present in the > downstream kernel for a long time, so I decided just to take them > instead of stripping them down to my needs. With these patches I > successfully used the driver with 4k@30Hz. 4k@60Hz doesn't work for me, > I hope this is due to my low quality cable. The cable might be the issue indeed, at least in my tests 4k@60Hz worked just fine. On a RK3568 EVB1, using $ modetest -M rockchip -s 69:{1920x1080,3840x2160}-{30,60} and a HP 27f 4K monitor: Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Thanks for your work and best regards, Michael > > Sascha > > Changes since v3: > - added changelog to each patch > - Add 4k support to hdmi driver > - rebase on v5.17-rc1 > > Changes since v2: > - Add pin names to HDMI supply pin description > - Add hclk support to HDMI driver > - Dual license rockchip-vop2 binding, update binding > - Add HDMI connector to board dts files > - drop unnecessary gamma_lut registers from vop2 > - Update dclk_vop[012] clock handling, no longer hacks needed > - Complete regmap conversion > > Changes since v1: > - drop all unnecessary waiting for frames within atomic modeset and plane update > - Cluster subwin support removed > - gamma support removed > - unnecessary irq_lock removed > - interrupt handling simplified > - simplified zpos handling > - drop is_alpha_support(), use fb->format->has_alpha instead > - use devm_regulator_get() rather than devm_regulator_get_optional() for hdmi regulators > - Use fixed number of planes per video port > - Drop homegrown regmap code from vop2 driver (not complete yet) > - Add separate include file for vop2 driver to not pollute the vop include > > Andy Yan (1): > drm: rockchip: Add VOP2 driver > > Benjamin Gaignard (1): > dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 > HDMI > > Douglas Anderson (2): > drm/rockchip: dw_hdmi: Use auto-generated tables > drm/rockchip: dw_hdmi: Set cur_ctr to 0 always > > Michael Riesch (1): > arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a > > Nickey Yang (1): > drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz > > Sascha Hauer (21): > drm/encoder: Add of_graph port to struct drm_encoder > drm/rockchip: dw_hdmi: Do not leave clock enabled in error case > drm/rockchip: dw_hdmi: rename vpll clock to reference clock > drm/rockchip: dw_hdmi: add rk3568 support > drm/rockchip: dw_hdmi: add regulator support > drm/rockchip: dw_hdmi: Add support for hclk > drm/rockchip: dw_hdmi: drop mode_valid hook > clk: rockchip: rk3568: Add more PLL rates > dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional > dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name > dt-bindings: display: rockchip: dw-hdmi: Add regulator support > dt-bindings: display: rockchip: dw-hdmi: Add additional clock > dt-bindings: display: rockchip: Add binding for VOP2 > arm64: dts: rockchip: rk3399: reorder hmdi clocks > arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref' > arm64: dts: rockchip: rk356x: Add VOP2 nodes > arm64: dts: rockchip: rk356x: Add HDMI nodes > arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi > clk: rk3568: drop CLK_SET_RATE_PARENT from dclk_vop* > clk: rk3568: Add CLK_SET_RATE_PARENT to the HDMI reference clock > drm/rockchip: Make VOP driver optional > > .../display/rockchip/rockchip,dw-hdmi.yaml | 29 +- > .../display/rockchip/rockchip-vop2.yaml | 146 + > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +- > .../boot/dts/rockchip/rk3566-quartz64-a.dts | 48 + > arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 + > .../boot/dts/rockchip/rk3568-evb1-v10.dts | 48 + > arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 + > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 86 + > drivers/clk/rockchip/clk-rk3568.c | 14 +- > drivers/gpu/drm/rockchip/Kconfig | 14 + > drivers/gpu/drm/rockchip/Makefile | 4 +- > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 293 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 7 +- > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 + > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 15 + > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2665 +++++++++++++++++ > drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 480 +++ > drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 285 ++ > include/drm/drm_encoder.h | 2 + > include/dt-bindings/soc/rockchip,vop2.h | 14 + > 21 files changed, 4039 insertions(+), 130 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c > create mode 100644 include/dt-bindings/soc/rockchip,vop2.h >
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 27.01.2022, o godz. 12:00: > >> >> -on rk3399 it gives me 4k screen where right vertical 1/3 part of screen is garbage >> -on rk3566 my samsung 4k monitor has black screen and cycle of OSD msgs: HDMI2 connected; HDMI2 disconnected; .... > > Same here on my rk3568, also with a samsung monitor. Was it 4k@60Hz or > 4k@30Hz? If the former, could you give 4k@30Hz a try? That mode works > well here. It was 4k@30 Indeed - firmware of my samsung is total crap in UI aspects - so maybe in hdmi modes are as well :-p Anyway - this crap monitor works ok with 4k@30 on AW/RPI4/rk3399/n3450/MacBookPro >> >> BTW: getting well working 4k HDMI modes on rk3399 was real story for me. >> There is many different series of patches to address this - but all have some subtle issues for me (i.e. 4k HDMI modes works but i.e. Qt is failing with DRM atomic commits in EGLFS) >> I developed well working [1] giving me reliable 4k on rk3399 (including working Qt DRM drawing in EGLFS mode) >> Maybe it will be somehow helpful to get 4k modes solution for rk3566 _and_ rk3399 (on single kernel binary)? >> >> [1] https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.16/files/0730-drm-rockchip-add-4k-videomodes-support.patch > > At least there are patches in it that I have in my series as well and > keep popping up everywhere like "drm/rockchip: dw_hdmi: Use > auto-generated tables" and "drm/rockchip: dw_hdmi: Set cur_ctr to 0 > always" > What was time-consuming for me was finding working patches combination which not breaks Qt DRM Atomic commits. Many series floating arround various git repos/projects were offering 4k modes but breaking Qt in the same time.... btw: have you plans to look/address non-working DRM planes in VOP2? Rendering to DRM plane gives me green screen on rk3566. The same code (and binaries) are working ok on rk3399 (and other SoCs).
On Wed, 26 Jan 2022 15:55:22 +0100, Sascha Hauer wrote: > This is v4 of adding RK356x VOP2 support. Due to popular demand I added > a changelog to each patch, at least starting with changes to v3, I > didn't care to add the older changes as well. I hopefully integrated all > feedback I received to v3. Additionally I added some patches to the HDMI > driver to support resolutions up to 4k@60Hz. The patches are mostly > taken from the downstream kernel. Some have been send to public lists, > but were never applied upstream for reasons I do not know. The patches > are a bit more intrusive than needed for my case, but are present in the > downstream kernel for a long time, so I decided just to take them > instead of stripping them down to my needs. With these patches I > successfully used the driver with 4k@30Hz. 4k@60Hz doesn't work for me, > I hope this is due to my low quality cable. > > [...] Applied, thanks! [18/27] arm64: dts: rockchip: rk3399: reorder hmdi clocks commit: 2e8a8b5955a000cc655f7e368670518cbb77fe58 Best regards,
This is v4 of adding RK356x VOP2 support. Due to popular demand I added a changelog to each patch, at least starting with changes to v3, I didn't care to add the older changes as well. I hopefully integrated all feedback I received to v3. Additionally I added some patches to the HDMI driver to support resolutions up to 4k@60Hz. The patches are mostly taken from the downstream kernel. Some have been send to public lists, but were never applied upstream for reasons I do not know. The patches are a bit more intrusive than needed for my case, but are present in the downstream kernel for a long time, so I decided just to take them instead of stripping them down to my needs. With these patches I successfully used the driver with 4k@30Hz. 4k@60Hz doesn't work for me, I hope this is due to my low quality cable. Sascha Changes since v3: - added changelog to each patch - Add 4k support to hdmi driver - rebase on v5.17-rc1 Changes since v2: - Add pin names to HDMI supply pin description - Add hclk support to HDMI driver - Dual license rockchip-vop2 binding, update binding - Add HDMI connector to board dts files - drop unnecessary gamma_lut registers from vop2 - Update dclk_vop[012] clock handling, no longer hacks needed - Complete regmap conversion Changes since v1: - drop all unnecessary waiting for frames within atomic modeset and plane update - Cluster subwin support removed - gamma support removed - unnecessary irq_lock removed - interrupt handling simplified - simplified zpos handling - drop is_alpha_support(), use fb->format->has_alpha instead - use devm_regulator_get() rather than devm_regulator_get_optional() for hdmi regulators - Use fixed number of planes per video port - Drop homegrown regmap code from vop2 driver (not complete yet) - Add separate include file for vop2 driver to not pollute the vop include Andy Yan (1): drm: rockchip: Add VOP2 driver Benjamin Gaignard (1): dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMI Douglas Anderson (2): drm/rockchip: dw_hdmi: Use auto-generated tables drm/rockchip: dw_hdmi: Set cur_ctr to 0 always Michael Riesch (1): arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a Nickey Yang (1): drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz Sascha Hauer (21): drm/encoder: Add of_graph port to struct drm_encoder drm/rockchip: dw_hdmi: Do not leave clock enabled in error case drm/rockchip: dw_hdmi: rename vpll clock to reference clock drm/rockchip: dw_hdmi: add rk3568 support drm/rockchip: dw_hdmi: add regulator support drm/rockchip: dw_hdmi: Add support for hclk drm/rockchip: dw_hdmi: drop mode_valid hook clk: rockchip: rk3568: Add more PLL rates dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name dt-bindings: display: rockchip: dw-hdmi: Add regulator support dt-bindings: display: rockchip: dw-hdmi: Add additional clock dt-bindings: display: rockchip: Add binding for VOP2 arm64: dts: rockchip: rk3399: reorder hmdi clocks arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref' arm64: dts: rockchip: rk356x: Add VOP2 nodes arm64: dts: rockchip: rk356x: Add HDMI nodes arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi clk: rk3568: drop CLK_SET_RATE_PARENT from dclk_vop* clk: rk3568: Add CLK_SET_RATE_PARENT to the HDMI reference clock drm/rockchip: Make VOP driver optional .../display/rockchip/rockchip,dw-hdmi.yaml | 29 +- .../display/rockchip/rockchip-vop2.yaml | 146 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +- .../boot/dts/rockchip/rk3566-quartz64-a.dts | 48 + arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 + .../boot/dts/rockchip/rk3568-evb1-v10.dts | 48 + arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 + arch/arm64/boot/dts/rockchip/rk356x.dtsi | 86 + drivers/clk/rockchip/clk-rk3568.c | 14 +- drivers/gpu/drm/rockchip/Kconfig | 14 + drivers/gpu/drm/rockchip/Makefile | 4 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 293 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 7 +- drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 15 + drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2665 +++++++++++++++++ drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 480 +++ drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 285 ++ include/drm/drm_encoder.h | 2 + include/dt-bindings/soc/rockchip,vop2.h | 14 + 21 files changed, 4039 insertions(+), 130 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c create mode 100644 include/dt-bindings/soc/rockchip,vop2.h