All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Dan Johansen <strit@manjaro.org>
Cc: dri-devel@lists.freedesktop.org, Sandy Huang <hjc@rock-chips.com>,
	linux-rockchip@lists.infradead.org,
	Michael Riesch <michael.riesch@wolfvision.net>,
	kernel@pengutronix.de, Robin Murphy <robin.murphy@arm.com>,
	FUKAUMI Naoki <naoki@radxa.com>
Subject: Re: [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities
Date: Tue, 7 Feb 2023 10:40:09 +0100	[thread overview]
Message-ID: <20230207094009.GE10447@pengutronix.de> (raw)
In-Reply-To: <33d2fe54-7d29-67da-f4c9-9ff084937f11@manjaro.org>

On Tue, Feb 07, 2023 at 10:16:57AM +0100, Dan Johansen wrote:
> 
> Den 07.02.2023 kl. 09.44 skrev Sascha Hauer:
> > The different VOP variants support different maximum resolutions. Reject
> > resolutions that are not supported by a specific variant.
> > 
> > This hasn't been a problem in the upstream driver so far as 1920x1080
> > has been the maximum resolution supported by the HDMI driver and that
> > resolution is supported by all VOP variants. Now with higher resolutions
> > supported in the HDMI driver we have to limit the resolutions to the
> > ones supported by the VOP.
> > 
> > The actual maximum resolutions are taken from the Rockchip downstream
> > Kernel.
> 
> So just so I understand it, this will allow only up to 1080p on rk3399 or
> will it change something that allows higher resolutions, but with lower
> clock/pixel rates?

This patch is not about bandwidth limitations, only limitations in the
maximum resolution.

The RK3399 has two VOPs, VOPB and VOPL. The latter can only do 1080p
whereas the former can do up to 4k@30. This patch limits the allowed
resolutions to what the VOP can do. So when your application chooses
VOPB you should see 4k@30 as long as your monitor supports it.

In my testing weston has chosen VOPB and thus shows 4k@30, but I can't
tell if it does so because weston is smart enough, or just happens to
default to the VOPB.

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: Dan Johansen <strit@manjaro.org>
Cc: Sandy Huang <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	FUKAUMI Naoki <naoki@radxa.com>,
	Michael Riesch <michael.riesch@wolfvision.net>,
	kernel@pengutronix.de, Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities
Date: Tue, 7 Feb 2023 10:40:09 +0100	[thread overview]
Message-ID: <20230207094009.GE10447@pengutronix.de> (raw)
In-Reply-To: <33d2fe54-7d29-67da-f4c9-9ff084937f11@manjaro.org>

On Tue, Feb 07, 2023 at 10:16:57AM +0100, Dan Johansen wrote:
> 
> Den 07.02.2023 kl. 09.44 skrev Sascha Hauer:
> > The different VOP variants support different maximum resolutions. Reject
> > resolutions that are not supported by a specific variant.
> > 
> > This hasn't been a problem in the upstream driver so far as 1920x1080
> > has been the maximum resolution supported by the HDMI driver and that
> > resolution is supported by all VOP variants. Now with higher resolutions
> > supported in the HDMI driver we have to limit the resolutions to the
> > ones supported by the VOP.
> > 
> > The actual maximum resolutions are taken from the Rockchip downstream
> > Kernel.
> 
> So just so I understand it, this will allow only up to 1080p on rk3399 or
> will it change something that allows higher resolutions, but with lower
> clock/pixel rates?

This patch is not about bandwidth limitations, only limitations in the
maximum resolution.

The RK3399 has two VOPs, VOPB and VOPL. The latter can only do 1080p
whereas the former can do up to 4k@30. This patch limits the allowed
resolutions to what the VOP can do. So when your application chooses
VOPB you should see 4k@30 as long as your monitor supports it.

In my testing weston has chosen VOPB and thus shows 4k@30, but I can't
tell if it does so because weston is smart enough, or just happens to
default to the VOPB.

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-07  9:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07  8:44 [PATCH v4 0/4] drm/rockchip: dw_hdmi: Add 4k@30 support Sascha Hauer
2023-02-07  8:44 ` Sascha Hauer
2023-02-07  8:44 ` [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities Sascha Hauer
2023-02-07  8:44   ` Sascha Hauer
2023-02-07  9:16   ` Dan Johansen
2023-02-07  9:16     ` Dan Johansen
2023-02-07  9:40     ` Sascha Hauer [this message]
2023-02-07  9:40       ` Sascha Hauer
2023-02-07 10:46   ` Jonas Karlman
2023-02-07 10:46     ` Jonas Karlman
2023-02-07 12:34     ` Sascha Hauer
2023-02-07 12:34       ` Sascha Hauer
2023-02-07  8:44 ` [PATCH v4 2/4] drm/rockchip: dw_hdmi: relax mode_valid hook Sascha Hauer
2023-02-07  8:44   ` Sascha Hauer
2023-02-07  8:44 ` [PATCH v4 3/4] drm/rockchip: dw_hdmi: Add support for 4k@30 resolution Sascha Hauer
2023-02-07  8:44   ` Sascha Hauer
2023-02-07  8:44 ` [PATCH v4 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks Sascha Hauer
2023-02-07  8:44   ` Sascha Hauer
2023-02-07 11:01   ` Jonas Karlman
2023-02-07 11:01     ` Jonas Karlman
2023-02-07 12:51     ` Sascha Hauer
2023-02-07 12:51       ` Sascha Hauer
2023-02-07 16:29       ` Jonas Karlman
2023-02-07 16:29         ` Jonas Karlman

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=20230207094009.GE10447@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=dri-devel@lists.freedesktop.org \
    --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.