From mboxrd@z Thu Jan  1 00:00:00 1970
From: ykzhao <yakui.zhao@intel.com>
Subject: Re: [PATCH 1/7 resend] drm/i915: Add the support of	eDP
	on DP-D for Ibex/CPT
Date: Thu, 17 Jun 2010 09:11:40 +0800
Message-ID: <1276737100.4564.150.camel@localhost.localdomain>
References: <1276324347-15668-1-git-send-email-zhenyuw@linux.intel.com>
	<1276324347-15668-2-git-send-email-zhenyuw@linux.intel.com>
	<89k83a$8inni8@azsmga001.ch.intel.com>
	<1276525735.26204.55.camel@atropine.boston.devel.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
	by gabe.freedesktop.org (Postfix) with ESMTP id 9CF1B9E70A
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 16 Jun 2010 18:13:35 -0700 (PDT)
In-Reply-To: <1276525735.26204.55.camel@atropine.boston.devel.redhat.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Adam Jackson <ajax@redhat.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Mon, 2010-06-14 at 22:28 +0800, Adam Jackson wrote:
> On Sat, 2010-06-12 at 09:28 +0100, Chris Wilson wrote:
> > On Sat, 12 Jun 2010 14:32:21 +0800, Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> > >  static void
> > > -intel_dp_compute_m_n(int bytes_per_pixel,
> > > +intel_dp_compute_m_n(int bpp,
> > >  		     int nlanes,
> > >  		     int pixel_clock,
> > >  		     int link_clock,
> > >  		     struct intel_dp_m_n *m_n)
> > >  {
> > >  	m_n->tu = 64;
> > > -	m_n->gmch_m = pixel_clock * bytes_per_pixel;
> > > +	m_n->gmch_m = (pixel_clock * bpp) >> 3;
> > >  	m_n->gmch_n = link_clock * nlanes;
> > >  	intel_reduce_ratio(&m_n->gmch_m, &m_n->gmch_n);
> > >  	m_n->link_m = pixel_clock;
> > 
> > This rounds the gmch_m down. Is this correct?
> 
> It's not, though thanks to the magic of PLLs it's probably close enough.
> However...
> 
> > And how close to overflow is pixel_clock today?
> 
> % echo $(( (2 ** 31 - 1) / 24. ))
> 89478485.291666672
> 
> 89MHz isn't even a single LVDS link.  Looks like that math needs to be
> 64-bit.

Yes. 64-bit math is required on the above scenario if the actual pixel
clock is directly used.

But the pixel clock in code uses the KHz as the unit. E.g. If the actual
pixel clock is 89000 KHz, then 89000 will be used for the calculation.
In such case it seems that the 32-bit math is enough. 

Thanks.
    Yakui
> 
> - ajax