From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Mateo Lozano, Oscar" <oscar.mateo@intel.com>
Subject: Re: [PATCH 12/53] drm/i915/bdw: Populate LR contexts
 (somewhat)
Date: Mon, 23 Jun 2014 15:11:58 +0000
Message-ID: <92648605EABDA246B775AAB04C95A7A3137C0F85@IRSMSX103.ger.corp.intel.com>
References: <1402673891-14618-1-git-send-email-oscar.mateo@intel.com>
 <1402673891-14618-13-git-send-email-oscar.mateo@intel.com>
 <20140618232409.GD5716@bdvolkin-ubuntu-desktop>
 <92648605EABDA246B775AAB04C95A7A3137BEBBB@IRSMSX103.ger.corp.intel.com>
 <20140623150544.GA31279@bdvolkin-ubuntu-desktop>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by gabe.freedesktop.org (Postfix) with ESMTP id CFE706E303
 for <intel-gfx@lists.freedesktop.org>; Mon, 23 Jun 2014 08:12:09 -0700 (PDT)
In-Reply-To: <20140623150544.GA31279@bdvolkin-ubuntu-desktop>
Content-Language: en-US
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>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

> -----Original Message-----
> From: Volkin, Bradley D
> Sent: Monday, June 23, 2014 4:06 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 12/53] drm/i915/bdw: Populate LR contexts
> (somewhat)
> =

> On Mon, Jun 23, 2014 at 05:42:50AM -0700, Mateo Lozano, Oscar wrote:
> > > -----Original Message-----
> > > From: Volkin, Bradley D
> > > > +	reg_state[CTX_RING_HEAD+1] =3D 0;
> > > > +	reg_state[CTX_RING_TAIL] =3D RING_TAIL(ring->mmio_base);
> > > > +	reg_state[CTX_RING_TAIL+1] =3D 0;
> > > > +	reg_state[CTX_RING_BUFFER_START] =3D RING_START(ring-
> > > >mmio_base);
> > > > +	reg_state[CTX_RING_BUFFER_START+1] =3D
> > > i915_gem_obj_ggtt_offset(ring_obj);
> > > > +	reg_state[CTX_RING_BUFFER_CONTROL] =3D RING_CTL(ring-
> > > >mmio_base);
> > > > +	reg_state[CTX_RING_BUFFER_CONTROL+1] =3D (31 * PAGE_SIZE) |
> > > > +RING_VALID;
> > >
> > > The size here doesn't look right to me. Shouldn't it be (number of pa=
ges -
> 1)?
> > > See init_ring_common()
> >
> > But that=B4s exactly what it is, right?
> >
> > Our ringbuf->size =3D 32 * PAGE_SIZE;
> > so we are setting 31 * PAGE_SIZE
> =

> Ok, on closer inspection, the result is correct because the Buffer Length=
 field
> happens to be bits 20:12. But it looked to me like a size-in-bytes rather=
 than
> the encoding I expected. So I guess I'd prefer that we do it as in
> init_ring_common(), using ring_obj->base.size and the RING_NR_PAGES
> mask so that it's a bit more obvious what's going on.
> =

> Thanks,
> Brad

Yeah, it probably looks less magical that way. Ok, will do.