Re: [PATCH 3/3] drm/i915: Use intel_plane_obj_offset from more places

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 06/16/2015 12:48 PM, Chris Wilson wrote:
> On Tue, Jun 16, 2015 at 12:31:23PM +0100, Tvrtko Ursulin wrote:
>> That is partially correct, I do see it as problematic since I
>> assumed someone will modeset with this fb/object at some point, and
>> there will be state available then, which won't have the cached
>> display address at all since the state is not present during fbdev
>> setup.
>>
>> Does that never happens? I mean, the modeset with state using the
>> fb/object prepared in intefb_alloc?
>
> No. The setup in intelfb_alloc is only concerned with generating a GGTT
> mmapping that is consistent with later use by modesetting. The important
> detail is to make sure the alignment is correct (or else the modeset
> will fail as it cannot move the object as it is already pinned).
>
> As Ville has extracted the linear alignment, we can export that and all
> pin_to_display directly so that we can set up the fbdev without the
> confusion of calling intel_pin_and_fence_fb. Or we can just live with
> the confustion and comment appropriately.

Ok, think I get it now. Will send three RFC patches shortly.

1/3 looks innocent but it actually a bugfix once display address caching 
come along.

2/3 is the caching itself.

3/3 is what is not yet needed today, but analogous to 1/3 it fixes a bug 
which will become apparent in the future.

If this looks more along the lines of what you had in mind I can polish 
the comments or whatnot. 80 char line breaks were especially ugly in 
some of them to very long variable names. :)

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx