From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 2/4] drm/i915: kill obj->gtt_offset
Date: Fri, 15 Apr 2011 21:19:00 +0200
Message-ID: <20110415191859.GC3503@viiv.ffwll.ch>
References: <1302893858-8234-1-git-send-email-daniel.vetter@ffwll.ch>
	<1302893858-8234-3-git-send-email-daniel.vetter@ffwll.ch>
	<849307$cgjlsv@azsmga001.ch.intel.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 mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43])
	by gabe.freedesktop.org (Postfix) with ESMTP id A46A39E758
	for <intel-gfx@lists.freedesktop.org>;
	Fri, 15 Apr 2011 12:19:05 -0700 (PDT)
Received: by wwb17 with SMTP id 17so3011225wwb.12
	for <intel-gfx@lists.freedesktop.org>;
	Fri, 15 Apr 2011 12:19:04 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <849307$cgjlsv@azsmga001.ch.intel.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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Fri, Apr 15, 2011 at 07:56:10PM +0100, Chris Wilson wrote:
> On Fri, 15 Apr 2011 20:57:36 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Yet another massive round of sed'ing.
> 
> The only hitch here is that in the vmap code obj->gtt_offset !=
> obj->gtt_space.offset.
> 
> There obj->gtt_space.offset is the base of the page aligned region allocated
> in the GTT and obj->gtt_offset is obj->gtt_space.offset +
> offset_in_page(user_addr).
> 
> I haven't checked but is obj->gtt_space immutable by the caller, i.e. can
> we modify obj->gtt_space.offset and drm_mm still function correctly? Bake
> the page aligned assumption into drm_mm? Or simply undo the page_offset
> when releasing the gtt_space...? The latter sounds like it would work
> best.

Mucking around with drm_mm_node->start is a bad idea, it's used to track
the end of the preceding free area (if there is one).

Also I find having a bo with a not-page-aligned gtt offset kinda creepy
... So if the kernel really needs to track this, could it be tracked in a
special vmap handle object? Or is this really required, because all the
normal memory mapper syscalls only work on page boundaries, too. I.e. why
can't userspace keep track of the offset?
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48