On Fri, 10 Jun 2022 at 15:53, Matthew Auld <matthew.william.auld@xxxxxxxxx> wrote: > > On Fri, 10 Jun 2022 at 13:12, Juha-Pekka Heikkila > <juhapekka.heikkila@xxxxxxxxx> wrote: > > > > From: CQ Tang <cq.tang@xxxxxxxxx> > > > > Display might allocate a smem object and call > > i915_vma_pin_iomap(), the existing code will fail. > > > > This fix was suggested by Chris P Wilson, that we pin > > the smem with i915_gem_object_pin_map_unlocked(). > > > > v2 (jheikkil): Change i915_gem_object_pin_map_unlocked to > > i915_gem_object_pin_map > > > > Signed-off-by: CQ Tang <cq.tang@xxxxxxxxx> > > Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@xxxxxxxxx> > > Cc: Chris Wilson <chris.p.wilson@xxxxxxxxx> > > Cc: Jari Tahvanainen <jari.tahvanainen@xxxxxxxxx> > Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx> Although maybe consider putting this as patch 1, and then reword the commit title/message to be more like "drm/i915: extend i915_vma_iomap()" or so, which then becomes a prep patch for supporting the dpt fallback to smem. Otherwise it looks like this patch is basically just fixing the first patch to not trigger the WARN_ON(), which seems iffy IMO. Each patch by itself should ideally be functional.
