public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Konduru, Chandra" <chandra.konduru@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v2 3/9] drm/i915: Enable default_phase in GCP	when possible
Date: Wed, 3 Jun 2015 12:34:26 +0300	[thread overview]
Message-ID: <20150603093426.GE5176@intel.com> (raw)
In-Reply-To: <76A9B330A4D78C4D99CB292C4CC06C0E36FEFAFD@fmsmsx101.amr.corp.intel.com>

On Tue, Jun 02, 2015 at 06:21:59PM +0000, Konduru, Chandra wrote:
> > > > @@ -560,6 +560,49 @@ static bool hdmi_sink_is_deep_color(struct
> > > > drm_encoder *encoder)
> > > >  	return false;
> > > >  }
> > > >
> > > > +/*
> > > > + * Determine if default_phase=1 can be indicated in the GCP infoframe.
> > > > + *
> > > > + * From HDMI specification 1.4a:
> > > > + * - The first pixel of each Video Data Period shall always have a
> > > > +pixel packing phase of 0
> > > > + * - The first pixel following each Video Data Period shall have a
> > > > +pixel packing phase of 0
> > > > + * - The PP bits shall be constant for all GCPs and will be equal to
> > > > +the last packing phase
> > > > + * - The first pixel following every transition of HSYNC or VSYNC shall have a
> > > > pixel packing
> > > > + *   phase of 0
> > > > + */
> > > > +static bool gcp_default_phase_possible(int pipe_bpp,
> > > > +				       const struct drm_display_mode *mode) {
> > > > +	unsigned int pixels_per_group;
> > > > +
> > > > +	switch (pipe_bpp) {
> > > > +	case 30:
> > > > +		/* 4 pixels in 5 clocks */
> > > > +		pixels_per_group = 4;
> > > > +		break;
> > > > +	case 36:
> > > > +		/* 2 pixels in 3 clocks */
> > > > +		pixels_per_group = 2;
> > > > +		break;
> > > > +	case 48:
> > > > +		/* 1 pixel in 2 clocks */
> > > > +		pixels_per_group = 1;
> > > > +		break;
> > > > +	default:
> > > > +		/* phase information not relevant for 8bpc */
> > > > +		return false;
> > > > +	}
> > > > +
> > > > +	return mode->crtc_hdisplay % pixels_per_group == 0 &&
> > > > +		mode->crtc_htotal % pixels_per_group == 0 &&
> > > > +		mode->crtc_hblank_start % pixels_per_group == 0 &&
> > > > +		mode->crtc_hblank_end % pixels_per_group == 0 &&
> > > > +		mode->crtc_hsync_start % pixels_per_group == 0 &&
> > > > +		mode->crtc_hsync_end % pixels_per_group == 0 &&
> > >
> > > For hsync, bspec says Hsync is an even number.
> > > Isn't it above check should be something like (hsync_end - hsync_start) % 2 ==
> > 0?
> > > And similarly for front & back porches, right?
> > 
> > If X and Y are even then (X - Y) is even too. Also the text in bspec is
> > less informative than the text in HDMI spec, which is why I quited the
> > HDMI spec instead.
> 
> Sure, if X and Y are even X - Y is even, but it is more restrictive check than
> needed. Because if both X and Y are odd, X - Y is even, and in that case
> above code doesn't allow to use default phase. Which may be OK, but
> it didn't truly allow default phase when possible.

Default phase should not be enabled in that case. As the HDMI spec says
"The first pixel following every transition of HSYNC or VSYNC shall have
a pixel packing phase of 0", so having a misaligned hsync_start or
hsync_end is not allowed.

Or you can also read bspec. While the text is less clear there IMO it
does disallow the case you outlined. What bspec does say is this:
"Htotal is an even number
 Hactive is an even number
 Hsync is an even number
 Front and back porches for Hsync are even numbers
 Vsync always starts on an even-numbered pixel within a line in
 interlaced modes (starting counting with 0)"

That doesn't allow hsync_start or hsync_end to be odd either.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-06-03  9:34 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-05 14:06 [PATCH 0/9] drm/i915: HDMI 12bpc fixes ville.syrjala
2015-05-05 14:06 ` [PATCH v2 1/9] drm/i915: Implement WaEnableHDMI8bpcBefore12bpc:snb, ivb ville.syrjala
2015-05-05 14:24   ` Jani Nikula
2015-05-25 11:39   ` Ander Conselvan De Oliveira
2015-06-01 21:49   ` Konduru, Chandra
2015-05-05 14:06 ` [PATCH v2 2/9] drm/i915: Send GCP infoframes for deep color HDMI sinks ville.syrjala
2015-05-25 12:32   ` Ander Conselvan De Oliveira
2015-05-25 12:44     ` Ville Syrjälä
2015-05-25 13:09       ` Ander Conselvan De Oliveira
2015-05-25 13:14         ` Ville Syrjälä
2015-06-01 21:49   ` Konduru, Chandra
2015-06-02 12:58     ` Ville Syrjälä
2015-06-02 19:07       ` Konduru, Chandra
2015-05-05 14:06 ` [PATCH v2 3/9] drm/i915: Enable default_phase in GCP when possible ville.syrjala
2015-06-01 21:49   ` Konduru, Chandra
2015-06-02 11:46     ` Ville Syrjälä
2015-06-02 18:21       ` Konduru, Chandra
2015-06-03  9:34         ` Ville Syrjälä [this message]
2015-06-03 20:38           ` Konduru, Chandra
2015-05-05 14:06 ` [PATCH v2 4/9] drm/i915: Fix HDMI 12bpc TRANSCONF bpc value ville.syrjala
2015-06-01 21:48   ` Konduru, Chandra
2015-05-05 14:06 ` [PATCH v2 5/9] drm/i915: Fix 12bpc HDMI enable for IBX ville.syrjala
2015-06-03 20:52   ` Konduru, Chandra
2015-05-05 14:06 ` [PATCH v2 6/9] drm/i915: Disable all infoframes when turning off the HDMI port ville.syrjala
2015-06-01 22:48   ` Konduru, Chandra
2015-06-02 11:11     ` Ville Syrjälä
2015-06-02 18:18       ` Konduru, Chandra
2015-06-03  9:21         ` Ville Syrjälä
2015-06-03 23:24           ` Konduru, Chandra
2015-05-05 14:06 ` [PATCH 7/9] drm/i915: Check infoframe state more diligently ville.syrjala
2015-06-01 22:57   ` Konduru, Chandra
2015-05-05 14:06 ` [PATCH 8/9] drm/i915: Fix hdmi clock readout with pixel repeat ville.syrjala
2015-06-01 22:59   ` Konduru, Chandra
2015-05-05 14:06 ` [PATCH 9/9] drm/i915: Double the port clock when using double clocked modes with 12bpc ville.syrjala
2015-05-21 11:20   ` Ville Syrjälä
2015-06-01 23:23   ` Konduru, Chandra
2015-06-01 19:04 ` [PATCH 0/9] drm/i915: HDMI 12bpc fixes Konduru, Chandra
2015-06-15  9:37   ` Daniel Vetter

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=20150603093426.GE5176@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chandra.konduru@intel.com \
    --cc=intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox