On Mon, 20 Jun 2022 at 10:38, Juha-Pekka Heikkila <juhapekka.heikkila@xxxxxxxxx> wrote: > > On 10.6.2022 20.43, Matthew Auld wrote: > > 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. > > Probably easiest is to put patch 1 in as last, it's the final customer > for these two other patches. This way if someone will end up doing > bisecting there would be nothing interesting to see with these. > > I did finally get ci to look all green after last weeks outages. I'd > guess these patches are ready to be pushed but I don't have commit > rights to drm-tip. Are you able to help with these or I'll go bother > Imre or Jani to get them into tip? Ok, if no objections I will go ahead and push this to drm-intel-gt-next, with the tweaked patch ordering. > > /Juha-Pekka
