From: "Lespiau, Damien" <damien.lespiau@intel.com>
To: Keith Packard <keithp@keithp.com>
Cc: intel-gfx@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after display_bpc is set
Date: Fri, 17 Aug 2012 15:58:57 +0100 [thread overview]
Message-ID: <CAPX-8+-fcLQB_48DjL8UN5j3_brH8JHOJXFc4MgOwwHBrsw_Mg@mail.gmail.com> (raw)
In-Reply-To: <1344918891-6283-5-git-send-email-keithp@keithp.com>
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard <keithp@keithp.com> wrote:
> @@ -3845,8 +3836,20 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
>
> display_bpc = min(display_bpc, bpc);
>
> - DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d)\n",
> - bpc, display_bpc);
> + display_bpc = 6;
It seems that you are overriding display_bpc unconditionally here,
some left over from debugging?
> + if (display_bpc * 3 > max_fdi_bpp) {
> + if (max_fdi_bpp < 24)
> + display_bpc = 6;
> + else if (max_fdi_bpp < 30)
> + display_bpc = 8;
> + else if (max_fdi_bpp < 36)
> + display_bpc = 10;
> + DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
> + }
> +
> + DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d) (max_fdi_bpp %d)\n",
> + bpc, display_bpc, max_fdi_bpp);
>
> *pipe_bpp = display_bpc * 3;
"setting pipe bpc to %d", bpc and *pipe_bpp = display_bpc, looks like
a bogus debug message to me.
> @@ -4763,9 +4765,12 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
> * Compute the available FDI bandwidth, use that
> * to compute the maximum supported BPP
> */
> - fdi_bw = link_bw * max_lane * 19 / 20;
> - max_fdi_bpp = fdi_bw / target_clock;
> - DRM_DEBUG_KMS("max lane %d yields max fdi bpp %d\n", max_lane, max_fdi_bpp);
> + fdi_bw = (link_bw * 8) * max_lane;
> + pps = target_clock * 21 / 20;
> +
> + max_fdi_bpp = fdi_bw / pps;
> + DRM_DEBUG_KMS("link_bw %d max_lane %d fdi_bw %u pps %u max_fdi_bpp %d\n",
> + link_bw, max_lane, fdi_bw, pps, max_fdi_bpp);
> }
While I understood the first computation of max_fdi_bpp in patch 2 of
this series, I have to confess you lost me there. Would you mind
clarifying this?
--
Damien
WARNING: multiple messages have this Message-ID (diff)
From: "Lespiau, Damien" <damien.lespiau@intel.com>
To: Keith Packard <keithp@keithp.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after display_bpc is set
Date: Fri, 17 Aug 2012 15:58:57 +0100 [thread overview]
Message-ID: <CAPX-8+-fcLQB_48DjL8UN5j3_brH8JHOJXFc4MgOwwHBrsw_Mg@mail.gmail.com> (raw)
In-Reply-To: <1344918891-6283-5-git-send-email-keithp@keithp.com>
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard <keithp@keithp.com> wrote:
> @@ -3845,8 +3836,20 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
>
> display_bpc = min(display_bpc, bpc);
>
> - DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d)\n",
> - bpc, display_bpc);
> + display_bpc = 6;
It seems that you are overriding display_bpc unconditionally here,
some left over from debugging?
> + if (display_bpc * 3 > max_fdi_bpp) {
> + if (max_fdi_bpp < 24)
> + display_bpc = 6;
> + else if (max_fdi_bpp < 30)
> + display_bpc = 8;
> + else if (max_fdi_bpp < 36)
> + display_bpc = 10;
> + DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
> + }
> +
> + DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d) (max_fdi_bpp %d)\n",
> + bpc, display_bpc, max_fdi_bpp);
>
> *pipe_bpp = display_bpc * 3;
"setting pipe bpc to %d", bpc and *pipe_bpp = display_bpc, looks like
a bogus debug message to me.
> @@ -4763,9 +4765,12 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
> * Compute the available FDI bandwidth, use that
> * to compute the maximum supported BPP
> */
> - fdi_bw = link_bw * max_lane * 19 / 20;
> - max_fdi_bpp = fdi_bw / target_clock;
> - DRM_DEBUG_KMS("max lane %d yields max fdi bpp %d\n", max_lane, max_fdi_bpp);
> + fdi_bw = (link_bw * 8) * max_lane;
> + pps = target_clock * 21 / 20;
> +
> + max_fdi_bpp = fdi_bw / pps;
> + DRM_DEBUG_KMS("link_bw %d max_lane %d fdi_bw %u pps %u max_fdi_bpp %d\n",
> + link_bw, max_lane, fdi_bw, pps, max_fdi_bpp);
> }
While I understood the first computation of max_fdi_bpp in patch 2 of
this series, I have to confess you lost me there. Would you mind
clarifying this?
--
Damien
next prev parent reply other threads:[~2012-08-17 14:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 4:34 [PATCH 0/7] drm/i915: IVB FDI B/C fixes and misc cleanups Keith Packard
2012-08-14 4:34 ` [PATCH 1/7] drm/i915: Allow VGA on CRTC 2 Keith Packard
2012-08-15 22:42 ` Daniel Vetter
2012-08-14 4:34 ` [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge Keith Packard
2012-08-17 14:45 ` [Intel-gfx] " Lespiau, Damien
2012-08-17 15:00 ` Keith Packard
2012-08-17 15:00 ` Keith Packard
2012-08-17 15:12 ` [Intel-gfx] " Lespiau, Damien
2012-08-14 4:34 ` [PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear FDI_RX_IIR before training Keith Packard
2012-08-17 15:34 ` [Intel-gfx] " Lespiau, Damien
2012-08-14 4:34 ` [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after display_bpc is set Keith Packard
2012-08-17 14:58 ` Lespiau, Damien [this message]
2012-08-17 14:58 ` Lespiau, Damien
2012-08-14 4:34 ` [PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR Keith Packard
2012-08-17 15:50 ` [Intel-gfx] " Lespiau, Damien
2012-08-14 4:34 ` [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX Keith Packard
2012-08-17 16:43 ` [Intel-gfx] " Lespiau, Damien
2012-08-17 16:43 ` Lespiau, Damien
2012-08-17 23:10 ` [Intel-gfx] " Keith Packard
2012-08-17 23:10 ` Keith Packard
2012-08-14 4:34 ` [PATCH 7/7] drm/i915: Merge FDI RX reg writes during training Keith Packard
2012-08-17 17:14 ` [Intel-gfx] " Lespiau, Damien
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=CAPX-8+-fcLQB_48DjL8UN5j3_brH8JHOJXFc4MgOwwHBrsw_Mg@mail.gmail.com \
--to=damien.lespiau@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=keithp@keithp.com \
--cc=linux-kernel@vger.kernel.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.