mbox series

[v4,00/27] drm/rockchip: RK356x VOP2 support

Message ID 20220126145549.617165-1-s.hauer@pengutronix.de
Headers show
Series drm/rockchip: RK356x VOP2 support | expand

Message

Sascha Hauer Jan. 26, 2022, 2:55 p.m. UTC
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

Comments

Doug Anderson Jan. 26, 2022, 3:42 p.m. UTC | #1
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
Doug Anderson Jan. 26, 2022, 3:54 p.m. UTC | #2
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
Peter Geis Jan. 26, 2022, 4:04 p.m. UTC | #3
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
>
Peter Geis Jan. 26, 2022, 6:44 p.m. UTC | #4
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
Robin Murphy Jan. 26, 2022, 7:24 p.m. UTC | #5
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
Sascha Hauer Jan. 27, 2022, 11 a.m. UTC | #6
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
Michael Riesch Jan. 27, 2022, 2:16 p.m. UTC | #7
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
>
Piotr Oniszczuk Jan. 27, 2022, 2:43 p.m. UTC | #8
> 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).
Heiko Stuebner Feb. 8, 2022, 1:21 p.m. UTC | #9
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,