All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Stefan Wahren <stefan.wahren@i2se.com>,
	Eric Anholt <eric@anholt.net>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: maxime@cerno.tech, linux-rpi-kernel@lists.infradead.org,
	f.fainelli@gmail.com,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/vc4: Fix HDMI mode validation
Date: Thu, 26 Mar 2020 18:36:20 +0100	[thread overview]
Message-ID: <486b5c63e5b9bd81051500c0c310e68af16956c4.camel@suse.de> (raw)
In-Reply-To: <c4b3e083-ac6e-b321-f0eb-f20e8ec3b1a6@i2se.com>

[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]

On Thu, 2020-03-26 at 18:19 +0100, Stefan Wahren wrote:
> Am 26.03.20 um 13:20 schrieb Nicolas Saenz Julienne:
> > Current mode validation impedes setting up some video modes which should
> > be supported otherwise. Namely 1920x1200@60Hz.
> > 
> > Fix this by lowering the minimum HDMI state machine clock to pixel clock
> > ratio allowed.
> > 
> > Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
> > Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
> > Suggested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >  drivers/gpu/drm/vc4/vc4_hdmi.c | 20 ++++++++++++++++----
> >  1 file changed, 16 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index cea18dc15f77..340719238753 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -681,11 +681,23 @@ static enum drm_mode_status
> >  vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
> >  			    const struct drm_display_mode *mode)
> >  {
> > -	/* HSM clock must be 108% of the pixel clock.  Additionally,
> > -	 * the AXI clock needs to be at least 25% of pixel clock, but
> > -	 * HSM ends up being the limiting factor.
> > +	/*
> > +	 * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
> > +	 * be faster than pixel clock, infinitesimally faster, tested in
> > +	 * simulation. Otherwise, exact value is unimportant for HDMI
> > +	 * operation." This conflicts with bcm2835's vc4 documentation, which
> > +	 * states HSM's clock has to be at least 108% of the pixel clock.
> > +	 *
> > +	 * Real life tests reveal that vc4's firmware statement holds up, and
> > +	 * users are able to use pixel clocks closer to HSM's, namely for
> > +	 * 1920x1200@60Hz. So it was decided to have leave a 1% margin between
> > +	 * both clocks. Which, for RPi0-3 implies a maximum pixel clock of
> 
> s/RPi0-3/bcm2835/ ?

Well as Dave Stevenson stated on the previous thread[1], it's the firmware that
sets up the HSM limitation. IIUC technically both HSM and pixel clocks could be
increased. Hence this being more of a RPi limitation than the chip itself.

"Whilst the firmware would appear to use a fixed HSM clock on Pi0-3, I
don't anticipate there being any issue with varying it. It looks like
there was the expectation of it being variable in the past, but
someone has refactored it and either accidentally or deliberately
given up on the idea."

Regards,
Nicolas

[1] https://www.spinics.net/lists/arm-kernel/msg794591.html


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Stefan Wahren <stefan.wahren@i2se.com>,
	Eric Anholt <eric@anholt.net>,
	 Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: f.fainelli@gmail.com,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	maxime@cerno.tech, linux-rpi-kernel@lists.infradead.org
Subject: Re: [PATCH] drm/vc4: Fix HDMI mode validation
Date: Thu, 26 Mar 2020 18:36:20 +0100	[thread overview]
Message-ID: <486b5c63e5b9bd81051500c0c310e68af16956c4.camel@suse.de> (raw)
In-Reply-To: <c4b3e083-ac6e-b321-f0eb-f20e8ec3b1a6@i2se.com>


[-- Attachment #1.1: Type: text/plain, Size: 2674 bytes --]

On Thu, 2020-03-26 at 18:19 +0100, Stefan Wahren wrote:
> Am 26.03.20 um 13:20 schrieb Nicolas Saenz Julienne:
> > Current mode validation impedes setting up some video modes which should
> > be supported otherwise. Namely 1920x1200@60Hz.
> > 
> > Fix this by lowering the minimum HDMI state machine clock to pixel clock
> > ratio allowed.
> > 
> > Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
> > Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
> > Suggested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >  drivers/gpu/drm/vc4/vc4_hdmi.c | 20 ++++++++++++++++----
> >  1 file changed, 16 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index cea18dc15f77..340719238753 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -681,11 +681,23 @@ static enum drm_mode_status
> >  vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
> >  			    const struct drm_display_mode *mode)
> >  {
> > -	/* HSM clock must be 108% of the pixel clock.  Additionally,
> > -	 * the AXI clock needs to be at least 25% of pixel clock, but
> > -	 * HSM ends up being the limiting factor.
> > +	/*
> > +	 * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
> > +	 * be faster than pixel clock, infinitesimally faster, tested in
> > +	 * simulation. Otherwise, exact value is unimportant for HDMI
> > +	 * operation." This conflicts with bcm2835's vc4 documentation, which
> > +	 * states HSM's clock has to be at least 108% of the pixel clock.
> > +	 *
> > +	 * Real life tests reveal that vc4's firmware statement holds up, and
> > +	 * users are able to use pixel clocks closer to HSM's, namely for
> > +	 * 1920x1200@60Hz. So it was decided to have leave a 1% margin between
> > +	 * both clocks. Which, for RPi0-3 implies a maximum pixel clock of
> 
> s/RPi0-3/bcm2835/ ?

Well as Dave Stevenson stated on the previous thread[1], it's the firmware that
sets up the HSM limitation. IIUC technically both HSM and pixel clocks could be
increased. Hence this being more of a RPi limitation than the chip itself.

"Whilst the firmware would appear to use a fixed HSM clock on Pi0-3, I
don't anticipate there being any issue with varying it. It looks like
there was the expectation of it being variable in the past, but
someone has refactored it and either accidentally or deliberately
given up on the idea."

Regards,
Nicolas

[1] https://www.spinics.net/lists/arm-kernel/msg794591.html


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-03-26 17:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26 12:20 [PATCH] drm/vc4: Fix HDMI mode validation Nicolas Saenz Julienne
2020-03-26 12:20 ` Nicolas Saenz Julienne
2020-03-26 12:32 ` Maxime Ripard
2020-03-26 12:32   ` Maxime Ripard
2020-03-26 17:19 ` Stefan Wahren
2020-03-26 17:19   ` Stefan Wahren
2020-03-26 17:21   ` Stefan Wahren
2020-03-26 17:21     ` Stefan Wahren
2020-03-26 17:36   ` Nicolas Saenz Julienne [this message]
2020-03-26 17:36     ` Nicolas Saenz Julienne
2020-03-26 17:52     ` Stefan Wahren
2020-03-26 17:52       ` Stefan Wahren
2020-03-27 11:46 ` Nicolas Saenz Julienne
2020-03-27 11:46   ` Nicolas Saenz Julienne
2020-03-27 12:40   ` Maxime Ripard
2020-03-27 12:40     ` Maxime Ripard
2020-03-27 12:40     ` Nicolas Saenz Julienne
2020-03-27 12:40       ` Nicolas Saenz Julienne

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=486b5c63e5b9bd81051500c0c310e68af16956c4.camel@suse.de \
    --to=nsaenzjulienne@suse.de \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=f.fainelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=maxime@cerno.tech \
    --cc=stefan.wahren@i2se.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.