All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: FUKAUMI Naoki <naoki@radxa.com>
Cc: "Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Dan Johansen" <strit@manjaro.org>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	kernel@pengutronix.de, "Robin Murphy" <robin.murphy@arm.com>
Subject: Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support
Date: Mon, 6 Feb 2023 16:48:51 +0100	[thread overview]
Message-ID: <20230206154851.GD10447@pengutronix.de> (raw)
In-Reply-To: <20230206140448.GB10447@pengutronix.de>

On Mon, Feb 06, 2023 at 03:04:48PM +0100, Sascha Hauer wrote:
> On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote:
> > hi,
> > 
> > I'm trying this patch series with 6.1.x kernel. it works fine on rk356x
> > based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4).
> > 
> > on rk3399 with this patch, I can see large noise area (about one third right
> > side of the screen) at 4k@30. 1080p works fine as same as before.
> > 
> > can someone reproduce this problem on rk3399?
> 
> Ok, I could easily reproduce the problem here.
> 
> The RK3399 has two VOPs, vopb(ig) and vopl(ittle). Only the former can
> do 4k@30 while the latter can only do 1080p. Unfortunately vopl is used
> by default. We can force using vopb by disabling vopl in the device tree
> and get a good 4k@30 picture then. The other possibility I found is to
> use the other CRTC with modetest. I have no idea how we could set the
> default to vopb.
> 
> I guess a first step would be to limit the maximum resolution of vopl
> to what the hardware can do. We would likely end up with 1080p by
> default then for the applications.

I did that, but the result is not what I expected. Discarding a mode in
the connector means it won't show up in the connectors list of modes.
Discarding it in the CRTC though means the mode is still exposed by the
connector, but actually trying to use it then fails.

This means when discarding the mode in the CRTC the screen stays black.

I am not sure where I should go from here.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de>
To: FUKAUMI Naoki <naoki@radxa.com>
Cc: Dan Johansen <strit@manjaro.org>,
	Sandy Huang <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	Michael Riesch <michael.riesch@wolfvision.net>,
	kernel@pengutronix.de, Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support
Date: Mon, 6 Feb 2023 16:48:51 +0100	[thread overview]
Message-ID: <20230206154851.GD10447@pengutronix.de> (raw)
In-Reply-To: <20230206140448.GB10447@pengutronix.de>

On Mon, Feb 06, 2023 at 03:04:48PM +0100, Sascha Hauer wrote:
> On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote:
> > hi,
> > 
> > I'm trying this patch series with 6.1.x kernel. it works fine on rk356x
> > based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4).
> > 
> > on rk3399 with this patch, I can see large noise area (about one third right
> > side of the screen) at 4k@30. 1080p works fine as same as before.
> > 
> > can someone reproduce this problem on rk3399?
> 
> Ok, I could easily reproduce the problem here.
> 
> The RK3399 has two VOPs, vopb(ig) and vopl(ittle). Only the former can
> do 4k@30 while the latter can only do 1080p. Unfortunately vopl is used
> by default. We can force using vopb by disabling vopl in the device tree
> and get a good 4k@30 picture then. The other possibility I found is to
> use the other CRTC with modetest. I have no idea how we could set the
> default to vopb.
> 
> I guess a first step would be to limit the maximum resolution of vopl
> to what the hardware can do. We would likely end up with 1080p by
> default then for the applications.

I did that, but the result is not what I expected. Discarding a mode in
the connector means it won't show up in the connectors list of modes.
Discarding it in the CRTC though means the mode is still exposed by the
connector, but actually trying to use it then fails.

This means when discarding the mode in the CRTC the screen stays black.

I am not sure where I should go from here.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2023-02-06 16:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18 13:22 [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support Sascha Hauer
2023-01-18 13:22 ` Sascha Hauer
2023-01-18 13:22 ` [PATCH v3 1/3] drm/rockchip: dw_hdmi: relax mode_valid hook Sascha Hauer
2023-01-18 13:22   ` Sascha Hauer
2023-01-18 13:22 ` [PATCH v3 2/3] drm/rockchip: dw_hdmi: Add support for 4k@30 resolution Sascha Hauer
2023-01-18 13:22   ` Sascha Hauer
2023-01-18 13:22 ` [PATCH v3 3/3] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks Sascha Hauer
2023-01-18 13:22   ` Sascha Hauer
2023-01-18 14:10 ` [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support Dan Johansen
2023-01-18 14:10   ` Dan Johansen
2023-01-18 14:24 ` Michael Riesch
2023-01-18 14:24   ` Michael Riesch
2023-01-18 18:42 ` Nicolas Frattaroli
2023-01-18 18:42   ` Nicolas Frattaroli
2023-01-31  8:09 ` Sascha Hauer
2023-01-31  8:09   ` Sascha Hauer
2023-02-01  0:23   ` FUKAUMI Naoki
2023-02-03 13:09     ` Sascha Hauer
2023-02-03 13:09       ` Sascha Hauer
2023-02-03 16:56       ` Jonas Karlman
2023-02-03 16:56         ` Jonas Karlman
2023-02-06 14:04     ` Sascha Hauer
2023-02-06 14:04       ` Sascha Hauer
2023-02-06 15:48       ` Sascha Hauer [this message]
2023-02-06 15:48         ` Sascha Hauer
2023-02-06 16:14         ` Daniel Stone
2023-02-06 16:14           ` Daniel Stone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230206154851.GD10447@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=michael.riesch@wolfvision.net \
    --cc=naoki@radxa.com \
    --cc=robin.murphy@arm.com \
    --cc=strit@manjaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.