All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: dri-devel@lists.freedesktop.org,
	Michael Riesch <michael.riesch@wolfvision.net>,
	Sandy Huang <hjc@rock-chips.com>,
	kernel@pengutronix.de, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 1/2] drm/rockchip: dw_hdmi: relax mode_valid hook
Date: Thu, 25 Aug 2022 13:40:25 +0200	[thread overview]
Message-ID: <20220825114025.GR17485@pengutronix.de> (raw)
In-Reply-To: <a279a697-6960-c517-8984-335aa207126a@arm.com>

On Wed, Aug 24, 2022 at 05:07:50PM +0100, Robin Murphy wrote:
> On 2022-08-22 16:20, Sascha Hauer wrote:
> > The driver checks if the pixel clock of the given mode matches an entry
> > in the mpll config table. The frequencies in the mpll table are meant as
> > a frequency range up to which the entry works, not as a frequency that
> > must match the pixel clock. Return MODE_OK when the pixelclock is
> > smaller than one of the mpll frequencies to allow for more display
> > resolutions.
> 
> Has the issue been fixed that this table is also used to validate modes on
> RK3328, which doesn't even *have* the Synopsys phy? Last time I looked, that
> tended to lead to complete display breakage when the proper phy driver later
> decides it doesn't like a pixel clock that mode_valid already said was OK.
> 
> The more general concern is that these known-good clock rates are good, but
> others may not be even when nominally supported, which I suspect is the
> dirty secret of why it was implemented this way to begin with. I would
> really really love this patch so my RK3399 board can drive my 1920x1200
> monitor at native resolution, but on the other hand my RK3288 box generates
> such a crap 154MHz clock for that mode that - unless that's been improved in
> the meantime too - patch #2 might be almost be considered a regression if it
> means such a setup would start defaulting to an unusably glitchy display
> instead of falling back to 1920x1080 which does at least work perfectly
> (even if the slightly squished aspect ratio is ugly).

I could limit the change to rk3568 only. Would that be an option?
Not sure if I should rk3399 as well then as this would work, at least in
your setup.

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: Robin Murphy <robin.murphy@arm.com>
Cc: kernel@pengutronix.de, linux-rockchip@lists.infradead.org,
	Michael Riesch <michael.riesch@wolfvision.net>,
	dri-devel@lists.freedesktop.org, Sandy Huang <hjc@rock-chips.com>
Subject: Re: [PATCH 1/2] drm/rockchip: dw_hdmi: relax mode_valid hook
Date: Thu, 25 Aug 2022 13:40:25 +0200	[thread overview]
Message-ID: <20220825114025.GR17485@pengutronix.de> (raw)
In-Reply-To: <a279a697-6960-c517-8984-335aa207126a@arm.com>

On Wed, Aug 24, 2022 at 05:07:50PM +0100, Robin Murphy wrote:
> On 2022-08-22 16:20, Sascha Hauer wrote:
> > The driver checks if the pixel clock of the given mode matches an entry
> > in the mpll config table. The frequencies in the mpll table are meant as
> > a frequency range up to which the entry works, not as a frequency that
> > must match the pixel clock. Return MODE_OK when the pixelclock is
> > smaller than one of the mpll frequencies to allow for more display
> > resolutions.
> 
> Has the issue been fixed that this table is also used to validate modes on
> RK3328, which doesn't even *have* the Synopsys phy? Last time I looked, that
> tended to lead to complete display breakage when the proper phy driver later
> decides it doesn't like a pixel clock that mode_valid already said was OK.
> 
> The more general concern is that these known-good clock rates are good, but
> others may not be even when nominally supported, which I suspect is the
> dirty secret of why it was implemented this way to begin with. I would
> really really love this patch so my RK3399 board can drive my 1920x1200
> monitor at native resolution, but on the other hand my RK3288 box generates
> such a crap 154MHz clock for that mode that - unless that's been improved in
> the meantime too - patch #2 might be almost be considered a regression if it
> means such a setup would start defaulting to an unusably glitchy display
> instead of falling back to 1920x1080 which does at least work perfectly
> (even if the slightly squished aspect ratio is ugly).

I could limit the change to rk3568 only. Would that be an option?
Not sure if I should rk3399 as well then as this would work, at least in
your setup.

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:[~2022-08-25 11:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22 15:20 [PATCH 0/2] drm/rockchip: dw_hdmi: Add 4k@30 support Sascha Hauer
2022-08-22 15:20 ` [PATCH 1/2] drm/rockchip: dw_hdmi: relax mode_valid hook Sascha Hauer
2022-08-24 16:07   ` Robin Murphy
2022-08-24 16:07     ` Robin Murphy
2022-08-25 11:40     ` Sascha Hauer [this message]
2022-08-25 11:40       ` Sascha Hauer
2022-09-22 13:09       ` Robin Murphy
2022-09-22 13:09         ` Robin Murphy
2022-08-22 15:20 ` [PATCH 2/2] drm/rockchip: dw_hdmi: Add support for 4k@30 resolution Sascha Hauer
2022-08-24  5:43 ` [PATCH 0/2] drm/rockchip: dw_hdmi: Add 4k@30 support Michael Riesch
2022-08-24  5:43   ` Michael Riesch
2022-08-24  7:10   ` Sascha Hauer
2022-08-24  7:10     ` Sascha Hauer
2022-08-24 12:03     ` Dan Johansen
2022-08-24  7:07 ` Sascha Hauer
2022-09-03  7:53   ` Andy Yan

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=20220825114025.GR17485@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=robin.murphy@arm.com \
    /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.