Re: [PATCH 2/3] drm/i915: Fix i915_vma_pin_iomap()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

/Juha-Pekka



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux