[Intel-gfx] [PATCH 1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling

Ville Syrjälä ville.syrjala at linux.intel.com
Tue Feb 9 14:51:00 UTC 2021


On Tue, Feb 09, 2021 at 04:44:12PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 09, 2021 at 09:50:28AM +0000, Chris Wilson wrote:
> > Quoting Chris Wilson (2021-02-09 09:22:09)
> > > Quoting Ville Syrjala (2021-02-09 02:19:16)
> > > > +               while ((src_x + src_w) * cpp > plane_state->color_plane[0].stride) {
> > > > +                       if (offset == 0) {
> > > > +                               drm_dbg_kms(&dev_priv->drm,
> > > > +                                           "Unable to find suitable display surface offset due to X-tiling\n");
> > > > +                               return -EINVAL;
> > > > +                       }
> > > > +
> > > > +                       offset = intel_plane_adjust_aligned_offset(&src_x, &src_y, plane_state, 0,
> > > > +                                                                  offset, offset - alignment);
> > 
> > > The reason for choosing a nearby tile offset was to reduce src_x/src_y
> > > to fit within the crtc limits. While remapping could be used to solve
> > > that, the aligned_offset computation allows reuse of a single view.
> > 
> > Should there not be a second constraint on the loop to make sure src_x +
> > src_w is less than 4095/8191/etc?
> 
> Yeah, but we don't have that in the skl code either atm.
> Should add it to both.

Actually no. We already cap the max stride such that it never
exceeds that limit. So the single check already covers that.

What I think we should be checking is that src_y stays below the
appropriate limit. Although I'm not sure if we could realistically
hit a case where that fails but still find a suitably aligned
offset before hitting 0. Oh and I've not actually confirmed
whether src_y+src_h also has an upper limit or not.

-- 
Ville Syrjälä
Intel


More information about the Intel-gfx mailing list