[PATCH 30/66] drm/i915: Getter/setter for object attributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 01, 2013 at 09:08:58PM +0200, Daniel Vetter wrote:
> On Mon, Jul 1, 2013 at 8:43 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> >> All of this is addressed in future patches. As we've discussed, I think
> >> I'll have to respin it anyway, so I'll name it as such upfront. To me it
> >> felt a little weird to start calling things "ggtt" before I made the
> >> separation.
> >
> > I think now that we know what the end result should (more or less at
> > least) look like we can aim to make it right the first time we touch a
> > piece of code. That will reduce the churn in the patch series and so
> > make the beast easier to review.
> >
> > Imo foreshadowing (to keep consistent with the "a patch series should
> > tell a story" analogy) is perfectly fine, and in many cases helps in
> > understanding the big picture of a large pile of patches.
> 
> I've forgotten to add one thing: If you switch these again later on
> (layz me didn't check for that) it's imo best to stick with those
> names (presuming they fit, since the gtt_size vs. obj->size
> disdinction is a rather important one). Again I think now that we know
> where to go to it's best to get there with as few intermediate steps
> as possible.
> -Daniel
>

I don't recall object size being very important actually, so I don't
think the distinction is too important, but I'm just arguing for the
sake of arguing. With the sg page stuff that Imre did, I think most size
calculations unrelated to gtt size are there anyway, and most of our mm
(not page allocation) code should only ever care about the gtt.

> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Ben Widawsky, Intel Open Source Technology Center


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux