public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chon Ming Lee <chon.ming.lee@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Modify DP set clock to accomodate more eDP timings.
Date: Fri, 30 Aug 2013 10:28:39 +0300	[thread overview]
Message-ID: <87txi7iqmw.fsf@intel.com> (raw)
In-Reply-To: <1377885465-23851-1-git-send-email-chon.ming.lee@intel.com>

On Fri, 30 Aug 2013, Chon Ming Lee <chon.ming.lee@intel.com> wrote:
> eDP 1.4 supports 4-5 extra link rates in additional to current 2 link
> rate.  Create a structure to store the DPLL divisor data to improve
> readability.

DP 1.2 already supports 3 link rates, right?

> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   48 +++++++++++++++++++-------------------
>  1 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2151d13..ab8a5ff 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -38,6 +38,19 @@
>  
>  #define DP_LINK_CHECK_TIMEOUT	(10 * 1000)
>  
> +struct dp_link_dpll{

Missing space before {.

> +	int link_bw;
> +	struct dpll dpll;
> +};
> +
> +static const struct dp_link_dpll gen4_dpll[] = 
> +				{{ DP_LINK_BW_1_62, {2,23,8,2,10,0,0,0,0}},
> +				{ DP_LINK_BW_2_7,  {1,14,2,1,10,0,0,0,0}}};
> +
> +static const struct dp_link_dpll pch_dpll[] = 
> +				{{ DP_LINK_BW_1_62, {1,12,9,2,10,0,0,0,0}},
> +				{ DP_LINK_BW_2_7,  {2,14,8,1,10,0,0,0,0}}};
> +

Please switch these to use C99 designated initializers for clarity,
something like this:

static const struct dp_link_dpll gen4_dpll[] = {
	{
		.link_bw = DP_LINK_BW_1_62,
		.dpll = {
			.n = 2,
			.m1 = 23, m2 = 8,
			p1 = 2, p2 = 10, 
		},
	}, {
		.link_bw = DP_LINK_BW_2_7,
		.dpll = {
			.n = 1,
			.m1 = 14, m2 = 2,
			p1 = 1, p2 = 10, 
		},
	}
};

>  /**
>   * is_edp - is the given port attached to an eDP panel (either CPU or PCH)
>   * @intel_dp: DP struct
> @@ -649,37 +662,24 @@ intel_dp_set_clock(struct intel_encoder *encoder,
>  		   struct intel_crtc_config *pipe_config, int link_bw)
>  {
>  	struct drm_device *dev = encoder->base.dev;
> +	int i;
>  
>  	if (IS_G4X(dev)) {
> -		if (link_bw == DP_LINK_BW_1_62) {
> -			pipe_config->dpll.p1 = 2;
> -			pipe_config->dpll.p2 = 10;
> -			pipe_config->dpll.n = 2;
> -			pipe_config->dpll.m1 = 23;
> -			pipe_config->dpll.m2 = 8;
> -		} else {
> -			pipe_config->dpll.p1 = 1;
> -			pipe_config->dpll.p2 = 10;
> -			pipe_config->dpll.n = 1;
> -			pipe_config->dpll.m1 = 14;
> -			pipe_config->dpll.m2 = 2;
> +		for(i = 0; i < sizeof(gen4_dpll) / sizeof(struct dp_link_dpll); i++) {

Please use i < ARRAY_SIZE(gen4_dpll).

> +			if (link_bw == gen4_dpll[i].link_bw){
> +				pipe_config->dpll = gen4_dpll[i].dpll;
> +				break;
> +			}
>  		}

The old if-else used some values even if link_bw was bogus. I'm not sure
how likely that is. But if the link_bw is not found in the table for
some obscure reason (e.g. the hw doesn't support the link rate), this
fails. Perhaps we should have a test for i == ARRAY_SIZE(gen4_dpll) here
and complain loudly if we hit that, and perhaps use a fallback value.

>  		pipe_config->clock_set = true;
>  	} else if (IS_HASWELL(dev)) {
>  		/* Haswell has special-purpose DP DDI clocks. */
>  	} else if (HAS_PCH_SPLIT(dev)) {
> -		if (link_bw == DP_LINK_BW_1_62) {
> -			pipe_config->dpll.n = 1;
> -			pipe_config->dpll.p1 = 2;
> -			pipe_config->dpll.p2 = 10;
> -			pipe_config->dpll.m1 = 12;
> -			pipe_config->dpll.m2 = 9;
> -		} else {
> -			pipe_config->dpll.n = 2;
> -			pipe_config->dpll.p1 = 1;
> -			pipe_config->dpll.p2 = 10;
> -			pipe_config->dpll.m1 = 14;
> -			pipe_config->dpll.m2 = 8;
> +		for(i = 0; i < sizeof(pch_dpll) / sizeof(struct dp_link_dpll); i++) {
> +			if (link_bw == pch_dpll[i].link_bw){ 
> +				pipe_config->dpll = pch_dpll[i].dpll;
> +				break;
> +			}
>  		}

Same here.

BR,
Jani.


>  		pipe_config->clock_set = true;
>  	} else if (IS_VALLEYVIEW(dev)) {
> -- 
> 1.7.7.6
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

  parent reply	other threads:[~2013-08-30  7:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30 17:57 [PATCH 1/2] drm/i915: Modify DP set clock to accomodate more eDP timings Chon Ming Lee
2013-08-30  7:13 ` Daniel Vetter
2013-08-30  7:28 ` Jani Nikula [this message]
2013-09-01 15:26   ` Lee, Chon Ming
2013-08-30 17:57 ` [PATCH 2/2] drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock Chon Ming Lee
2013-08-30  8:00   ` Jani Nikula
2013-09-01 15:42     ` Lee, Chon Ming

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=87txi7iqmw.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=chon.ming.lee@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