[Intel-gfx] [PATCH 2/3] drm/i915: Fix i915_vma_pin_iomap()
Juha-Pekka Heikkila
juhapekka.heikkila at gmail.com
Mon Jun 20 09:38:48 UTC 2022
On 10.6.2022 20.43, Matthew Auld wrote:
> On Fri, 10 Jun 2022 at 15:53, Matthew Auld
> <matthew.william.auld at gmail.com> wrote:
>>
>> On Fri, 10 Jun 2022 at 13:12, Juha-Pekka Heikkila
>> <juhapekka.heikkila at gmail.com> wrote:
>>>
>>> From: CQ Tang <cq.tang at intel.com>
>>>
>>> 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 at intel.com>
>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila at gmail.com>
>>> Cc: Chris Wilson <chris.p.wilson at intel.com>
>>> Cc: Jari Tahvanainen <jari.tahvanainen at intel.com>
>> Reviewed-by: Matthew Auld <matthew.auld at intel.com>
>
> 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
More information about the Intel-gfx
mailing list