• Ville Syrjälä's avatar
    drm/i915: Rewrite fb rotation GTT handling · 6687c906
    Ville Syrjälä authored
    Redo the fb rotation handling in order to:
    - eliminate the NV12 special casing
    - handle fb->offsets[] properly
    - make the rotation handling easier for the plane code
    
    To achieve these goals we reduce intel_rotation_info to only contain
    (for each plane) the rotated view width,height,stride in tile units,
    and the page offset into the object where the plane starts. Each plane
    is handled exactly the same way, no special casing for NV12 or other
    formats. We then store the computed rotation_info under
    intel_framebuffer so that we don't have to recompute it again.
    
    To handle fb->offsets[] we treat them as a linear offsets and convert
    them to x/y offsets from the start of the relevant GTT mapping (either
    normal or rotated). We store the x/y offsets under intel_framebuffer,
    and for some extra convenience we also store the rotated pitch (ie.
    tile aligned plane height). So for each plane we have the normal
    x/y offsets, rotated x/y offsets, and the rotated pitch. The normal
    pitch is available already in fb->pitches[].
    
    While we're gathering up all that extra information, we can also easily
    compute the storage requirements for the framebuffer, so that we can
    check that the object is big enough to hold it.
    
    When it comes time to deal with the plane source coordinates, we first
    rotate the clipped src coordinates to match the relevant GTT view
    orientation, then add to them the fb x/y offsets. Next we compute
    the aligned surface page offset, and as a result we're left with some
    residual x/y offsets. Finally, if required by the hardware, we convert
    the remaining x/y offsets into a linear offset.
    
    For gen2/3 we simply skip computing the final page offset, and just
    convert the src+fb x/y offsets directly into a linear offset since
    that's what the hardware wants.
    
    After this all platforms, incluing SKL+, compute these things in exactly
    the same way (excluding alignemnt differences).
    
    v2: Use BIT(DRM_ROTATE_270) instead of ROTATE_270 when rotating
        plane src coordinates
        Drop some spurious changes that got left behind during
        development
    v3: Split out more changes to prep patches (Daniel)
        s/intel_fb->plane[].foo.bar/intel_fb->foo[].bar/ for brevity
        Rename intel_surf_gtt_offset to intel_fb_gtt_offset
        Kill the pointless 'plane' parameter from intel_fb_gtt_offset()
    v4: Fix alignment vs. alignment-1 when calling
        _intel_compute_tile_offset() from intel_fill_fb_info()
        Pass the pitch in tiles in
        stad of pixels to intel_adjust_tile_offset() from intel_fill_fb_info()
        Pass the full width/height of the rotated area to
        drm_rect_rotate() for clarity
        Use u32 for more offsets
    v5: Preserve the upper_32_bits()/lower_32_bits() handling for the
        fb ggtt offset (Sivakumar)
    v6: Rebase due to drm_plane_state src/dst rects
    
    Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
    Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: default avatarSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1470821001-25272-2-git-send-email-ville.syrjala@linux.intel.comAcked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    6687c906
i915_gem_gtt.c 94.4 KB