[Intel-gfx] FW: [PATCH v4 10/21] drm/i915: Rewrite fb rotation GTT handling

[Chris Wilson]

On Mon, May 02, 2016 at 09:40:45PM +0300, Ville Syrjälä wrote:
> On Mon, May 02, 2016 at 11:01:19PM +0530, Thulasimani, Sivakumar wrote:
> > basic question, the old code had linear_offset calculated first and then 
> > x  & y
> > were updated if rotation was set. the new code looks better since we handle
> > it after rotation but why not do the same for gen >= 4 too ? i.e move the
> > intel_compute_tile_offset after considering rotation ?
> 
> The hardware gets upset it you ask it to walk backwards past DSPSURF,
> so DSPSURF must be below the entire scanned out surface. Hence we must
> compute it before considering 180 degree rotation. Should probably add
> a comment somewhere to explain that...
> 
> Hmm. Now that I think about this, the old code tried to play tricks to
> compute both the linear and tiled offsets probably so that we could
> switch tiling modes with CS flips without reprogramming the linear/x/y
> offsets. But that can't actually work correctly unless the tile offset
> is tile row aligned, which it might not be. So yeah, I think the
> "change tiling mode with CS flips" thing was broken already, and still
> will be after this patch.

It is for a slightly different reason: emulating large (>8192 e.g.)
CRTC x/y offsets.

Changing tiling mode through flips should have been exercised (and I
guess a missed opportunity now would be to use i915.mmio_flips to force
that test case to exercise both CS and mmio flips explicitly).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre