All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>,
	Matthew Brost <matthew.brost@intel.com>,
	intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: christian.koenig@amd.com, thomas.hellstrom@linux.intel.com
Subject: Re: [PATCH v7 5/8] drm/xe/display: Update intel_bo_read_from_page to use ttm_bo_access
Date: Tue, 03 Dec 2024 11:08:40 +0200	[thread overview]
Message-ID: <878qsx5e1z.fsf@intel.com> (raw)
In-Reply-To: <39f2bbb3-5a53-4a6b-b066-be6be1ead293@intel.com>

On Mon, 02 Dec 2024, Matthew Auld <matthew.auld@intel.com> wrote:
> On 02/12/2024 11:43, Jani Nikula wrote:
>> On Tue, 26 Nov 2024, Matthew Brost <matthew.brost@intel.com> wrote:
>>> Don't open code vmap of a BO, use ttm_bo_access helper which is safe for
>>> non-contiguous BOs and non-visible BOs.
>>>
>>> Suggested-by: Matthew Auld <matthew.auld@intel.com>
>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
>> 
>> I've seen a few cases of [1] lately, and Thomas tipped me off to this
>> change. We get:
>> 
>> <4> [374.262965] xe 0000:03:00.0: [drm] drm_WARN_ON(ret)
>> <4> [374.262983] WARNING: CPU: 8 PID: 5462 at drivers/gpu/drm/i915/display/intel_display.c:7637 intel_atomic_commit_tail+0x16c7/0x17f0 [xe]
>> 
>> and that's intel_atomic_prepare_plane_clear_colors():
>> 
>> 		ret = intel_bo_read_from_page(intel_fb_bo(fb),
>> 					      fb->offsets[cc_plane] + 16,
>> 					      &plane_state->ccval,
>> 					      sizeof(plane_state->ccval));
>> 		/* The above could only fail if the FB obj has an unexpected backing store type. */
>> 		drm_WARN_ON(&i915->drm, ret);
>> 
>> 
>> So I don't have any conclusive evidence, but could this be the reason?
>
> @@ -40,8 +40,13 @@ int intel_bo_fb_mmap(struct drm_gem_object *obj, 
> struct vm_area_struct *vma)
>   int intel_bo_read_from_page(struct drm_gem_object *obj, u64 offset, 
> void *dst, int size)
>   {
>          struct xe_bo *bo = gem_to_xe_bo(obj);
> +       int ret;
>
> -       return ttm_bo_access(&bo->ttm, offset, dst, size, 0);
> +       ret = ttm_bo_access(&bo->ttm, offset, dst, size, 0);
> +       if (ret == size)
> +               ret = 0;
> +
> +       return ret;
>   }
>
> I think we somehow missed that bo_access is returning @size on success?

On a another look, we got the warn in the CI results [1] for the
series. :(

BR,
Jani.



[1] https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-140200v7/shard-dg2-435/igt@kms_plane@pixel-format-source-clamping@pipe-a-plane-3.html#dmesg-warnings69



>
>> 
>> BR,
>> Jani.
>> 
>> 
>> 
>> [1] https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-138070v8/shard-dg2-434/igt@kms_flip_tiling@flip-change-tiling@pipe-d-dp-4-linear-to-4-rc-ccs-cc.html
>> 
>> 
>>> ---
>>>   drivers/gpu/drm/xe/display/intel_bo.c | 25 +------------------------
>>>   1 file changed, 1 insertion(+), 24 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/display/intel_bo.c b/drivers/gpu/drm/xe/display/intel_bo.c
>>> index 9f54fad0f1c0..43141964f6f2 100644
>>> --- a/drivers/gpu/drm/xe/display/intel_bo.c
>>> +++ b/drivers/gpu/drm/xe/display/intel_bo.c
>>> @@ -40,31 +40,8 @@ int intel_bo_fb_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
>>>   int intel_bo_read_from_page(struct drm_gem_object *obj, u64 offset, void *dst, int size)
>>>   {
>>>   	struct xe_bo *bo = gem_to_xe_bo(obj);
>>> -	struct ttm_bo_kmap_obj map;
>>> -	void *src;
>>> -	bool is_iomem;
>>> -	int ret;
>>>   
>>> -	ret = xe_bo_lock(bo, true);
>>> -	if (ret)
>>> -		return ret;
>>> -
>>> -	ret = ttm_bo_kmap(&bo->ttm, offset >> PAGE_SHIFT, 1, &map);
>>> -	if (ret)
>>> -		goto out_unlock;
>>> -
>>> -	offset &= ~PAGE_MASK;
>>> -	src = ttm_kmap_obj_virtual(&map, &is_iomem);
>>> -	src += offset;
>>> -	if (is_iomem)
>>> -		memcpy_fromio(dst, (void __iomem *)src, size);
>>> -	else
>>> -		memcpy(dst, src, size);
>>> -
>>> -	ttm_bo_kunmap(&map);
>>> -out_unlock:
>>> -	xe_bo_unlock(bo);
>>> -	return ret;
>>> +	return ttm_bo_access(&bo->ttm, offset, dst, size, 0);
>>>   }
>>>   
>>>   struct intel_frontbuffer *intel_bo_get_frontbuffer(struct drm_gem_object *obj)
>> 
>

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-12-03  9:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26 17:46 [PATCH v7 0/8] Fix non-contiguous VRAM BO access in Xe Matthew Brost
2024-11-26 17:46 ` [PATCH v7 1/8] drm/xe: Add xe_bo_vm_access Matthew Brost
2024-11-26 17:46 ` [PATCH v7 2/8] drm/ttm: Add ttm_bo_access Matthew Brost
2024-11-27 13:19   ` Christian König
2024-11-28 10:47     ` Rodrigo Vivi
2024-11-29 14:05       ` Maxime Ripard
2024-12-02  8:00       ` Christian König
2024-11-26 17:46 ` [PATCH v7 3/8] drm/xe: Add xe_ttm_access_memory Matthew Brost
2024-11-26 17:46 ` [PATCH v7 4/8] drm/xe: Take PM ref in delayed snapshot capture worker Matthew Brost
2024-11-26 17:46 ` [PATCH v7 5/8] drm/xe/display: Update intel_bo_read_from_page to use ttm_bo_access Matthew Brost
2024-12-02 11:43   ` Jani Nikula
2024-12-02 14:17     ` Matthew Auld
2024-12-03  9:08       ` Jani Nikula [this message]
2024-11-26 17:46 ` [PATCH v7 6/8] drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed Matthew Brost
2025-01-15  8:44   ` Thomas Hellström
2024-11-26 17:46 ` [PATCH v7 7/8] drm/xe: Set XE_BO_FLAG_PINNED in migrate selftest BOs Matthew Brost
2024-11-26 17:46 ` [PATCH v7 8/8] drm/xe: Only allow contiguous BOs to use xe_bo_vmap Matthew Brost
2024-11-26 18:18 ` ✓ CI.Patch_applied: success for Fix non-contiguous VRAM BO access in Xe (rev7) Patchwork
2024-11-26 18:19 ` ✗ CI.checkpatch: warning " Patchwork
2024-11-26 18:20 ` ✓ CI.KUnit: success " Patchwork
2024-11-26 18:38 ` ✓ CI.Build: " Patchwork
2024-11-26 18:40 ` ✓ CI.Hooks: " Patchwork
2024-11-26 18:41 ` ✗ CI.checksparse: warning " Patchwork
2024-11-26 19:23 ` ✓ Xe.CI.BAT: success " Patchwork
2024-11-26 21:04 ` ✗ Xe.CI.Full: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878qsx5e1z.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.