From: "Timur Kristóf" <timur.kristof@gmail.com>
To: "Christian König" <christian.koenig@amd.com>,
amd-gfx@lists.freedesktop.org,
"Alex Deucher" <alexander.deucher@amd.com>,
"Alexandre Demers" <alexandre.f.demers@gmail.com>,
"Rodrigo Siqueira" <siqueira@igalia.com>
Subject: Re: [PATCH 10/14] drm/amdgpu/vce1: Implement VCE1 IP block
Date: Thu, 30 Oct 2025 14:47:48 +0100 [thread overview]
Message-ID: <846c7fb4e4bc53cba45f089ead9c44b3e00a59b5.camel@gmail.com> (raw)
In-Reply-To: <3c44c0eb-b60d-44af-987d-c29edd3991b7@amd.com>
On Thu, 2025-10-30 at 12:12 +0100, Christian König wrote:
> On 10/29/25 23:48, Timur Kristóf wrote:
> > > > + ASSERT(adev->vce.vcpu_bo);
> > >
> > > Please drop that.
> >
> > Sure, but can you say why?
>
> ASSERT either uses BUG_ON() or WARN_ON().
>
> BUG_ON() will crash the kernel immediately and WARN_ON will warn,
> continue and then crash.
>
> The justification for a BUG_ON() is to prevent further data
> corruption and that is not the case here.
Thanks for explaining that. Technically the vcpu_bo should never be
NULL, so I think I'll just go with your original suggestion and remove
the assertion.
>
> What you can do is to use something like "if (WARN_ON(...)) return -
> EINVAL;".
>
> > >
> > > > +
> > > > + r = amdgpu_bo_reserve(adev->vce.vcpu_bo, false);
> > > > + if (r) {
> > > > + dev_err(adev->dev, "%s (%d) failed to reserve
> > > > VCE
> > > > bo\n", __func__, r);
> > > > + return r;
> > > > + }
> > > > +
> > > > + r = amdgpu_bo_kmap(adev->vce.vcpu_bo, (void
> > > > **)&cpu_addr);
> > > > + if (r) {
> > > > + amdgpu_bo_unreserve(adev->vce.vcpu_bo);
> > > > + dev_err(adev->dev, "%s (%d) VCE map failed\n",
> > > > __func__, r);
> > > > + return r;
> > > > + }
> > >
> > > That part is actually pretty pointless the cpu addr is already
> > > available as adev->vce.cpu_addr.
> >
> > I don't think so. amdgpu_vce_resume actually unmaps and unreserves
> > the
> > VCE BO, so I think we need to map and reserve it again if we want
> > to
> > access it again. Am I misunderstanding something?
>
> Yeah, I see. But that is a totally pointless leftover from radeon as
> well which we should probably be removed.
>
> The VCE BO needs to stay at the same location before and after resume
> since the FW code is not relocateable once started.
>
> So we need to keep it pinned all the time and so can keep it CPU
> mapped all the time as well.
Right, that makes a lot of sense. I can do it, but I'd like to be
careful about it because it sounds like this would affect all VCE
versions and not just VCE1.
Do you prefer that I add a patch to this series to deal with that, or
would it be better to do that after this series lands?
Thanks & best regards,
Timur
next prev parent reply other threads:[~2025-10-30 13:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 22:06 [PATCH 00/14] drm/amdgpu: Support VCE1 IP block Timur Kristóf
2025-10-28 22:06 ` [PATCH 01/14] drm/amdgpu/gmc: Don't hardcode GART page count before GTT Timur Kristóf
2025-10-29 10:00 ` Christian König
2025-10-29 11:41 ` Timur Kristóf
2025-10-28 22:06 ` [PATCH 02/14] drm/amdgpu/gmc6: Place gart at low address range Timur Kristóf
2025-10-29 10:00 ` Christian König
2025-10-28 22:06 ` [PATCH 03/14] drm/amdgpu/gmc6: Add GART space for VCPU BO Timur Kristóf
2025-10-29 10:05 ` Christian König
2025-10-29 11:26 ` Timur Kristóf
2025-10-28 22:06 ` [PATCH 04/14] drm/amdgpu/gart: Add helper to bind VRAM BO Timur Kristóf
2025-10-29 10:16 ` Christian König
2025-10-29 10:57 ` Timur Kristóf
2025-10-28 22:06 ` [PATCH 05/14] drm/amdgpu/vce: Clear VCPU BO before copying firmware to it Timur Kristóf
2025-10-29 10:19 ` Christian König
2025-10-29 10:48 ` Timur Kristóf
2025-10-28 22:06 ` [PATCH 06/14] drm/amdgpu/vce: Move firmware load to amdgpu_vce_early_init Timur Kristóf
2025-10-29 10:26 ` Christian König
2025-10-29 17:16 ` Liu, Leo
2025-10-28 22:06 ` [PATCH 07/14] drm/amdgpu/si, cik, vi: Verify IP block when querying video codecs Timur Kristóf
2025-10-29 10:35 ` Christian König
2025-10-29 10:54 ` [PATCH 07/14] drm/amdgpu/si,cik,vi: " Timur Kristóf
2025-10-28 22:06 ` [PATCH 08/14] drm/amdgpu/vce1: Clean up register definitions Timur Kristóf
2025-10-29 11:23 ` Christian König
2025-10-28 22:06 ` [PATCH 09/14] drm/amdgpu/vce1: Load VCE1 firmware Timur Kristóf
2025-10-29 11:28 ` Christian König
2025-10-28 22:06 ` [PATCH 10/14] drm/amdgpu/vce1: Implement VCE1 IP block Timur Kristóf
2025-10-29 11:38 ` Christian König
2025-10-29 22:48 ` Timur Kristóf
2025-10-30 11:12 ` Christian König
2025-10-30 13:47 ` Timur Kristóf [this message]
2025-10-30 13:56 ` Christian König
2025-10-28 22:06 ` [PATCH 11/14] drm/amdgpu/vce1: Ensure VCPU BO is in lower 32-bit address space Timur Kristóf
2025-10-29 11:41 ` Christian König
2025-10-28 22:06 ` [PATCH 12/14] drm/amd/pm/si: Hook up VCE1 to SI DPM Timur Kristóf
2025-10-29 11:47 ` Christian König
2025-10-28 22:06 ` [PATCH 13/14] drm/amdgpu/vce1: Enable VCE1 on Tahiti, Pitcairn, Cape Verde GPUs Timur Kristóf
2025-10-29 11:51 ` Christian König
2025-10-28 22:06 ` [PATCH 14/14] drm/amdgpu/vce1: Tolerate VCE PLL timeout better Timur Kristóf
2025-10-29 12:02 ` Christian König
2025-10-29 19:46 ` Deucher, Alexander
2025-11-03 16:01 ` timur.kristof
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=846c7fb4e4bc53cba45f089ead9c44b3e00a59b5.camel@gmail.com \
--to=timur.kristof@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=alexandre.f.demers@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=siqueira@igalia.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.