From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Jeffrey Hugo <quic_jhugo@quicinc.com>
Cc: Oded Gabbay <ogabbay@kernel.org>,
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC 3/4] accel/ivpu: Remove support for uncached buffers
Date: Tue, 19 Sep 2023 11:49:30 +0200 [thread overview]
Message-ID: <20230919094930.GB563961@linux.intel.com> (raw)
In-Reply-To: <9925ef5c-f4f9-6553-f720-35fb0b1a5aa1@quicinc.com>
On Mon, Sep 11, 2023 at 09:24:42AM -0600, Jeffrey Hugo wrote:
> On 9/1/2023 10:48 AM, Stanislaw Gruszka wrote:
> > From: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
> >
> > Usages of DRM_IVPU_BO_UNCACHED should be replaced by DRM_IVPU_BO_WC.
> > There is no functional benefit from DRM_IVPU_BO_UNCACHED if these
> > buffers are never mapped to host VM.
> >
> > This allows to cut the buffer handling code in the kernel driver
> > by half.
> >
> > Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
> > Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
> > ---
> > drivers/accel/ivpu/ivpu_fw.c | 2 +-
> > drivers/accel/ivpu/ivpu_gem.c | 3 ---
> > include/uapi/drm/ivpu_accel.h | 2 +-
> > 3 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
> > index 2fef9fe154aa..8ab0f3225205 100644
> > --- a/drivers/accel/ivpu/ivpu_fw.c
> > +++ b/drivers/accel/ivpu/ivpu_fw.c
> > @@ -248,7 +248,7 @@ static int ivpu_fw_mem_init(struct ivpu_device *vdev)
> > if (fw->shave_nn_size) {
> > fw->mem_shave_nn = ivpu_bo_alloc_internal(vdev, vdev->hw->ranges.shave.start,
> > - fw->shave_nn_size, DRM_IVPU_BO_UNCACHED);
> > + fw->shave_nn_size, DRM_IVPU_BO_WC);
> > if (!fw->mem_shave_nn) {
> > ivpu_err(vdev, "Failed to allocate shavenn buffer\n");
> > ret = -ENOMEM;
> > diff --git a/drivers/accel/ivpu/ivpu_gem.c b/drivers/accel/ivpu/ivpu_gem.c
> > index 915c53d7bb97..2a91eb1e3627 100644
> > --- a/drivers/accel/ivpu/ivpu_gem.c
> > +++ b/drivers/accel/ivpu/ivpu_gem.c
> > @@ -89,8 +89,6 @@ static int __must_check shmem_alloc_pages_locked(struct ivpu_bo *bo)
> > if (bo->flags & DRM_IVPU_BO_WC)
> > set_pages_array_wc(pages, npages);
> > - else if (bo->flags & DRM_IVPU_BO_UNCACHED)
> > - set_pages_array_uc(pages, npages);
> > bo->pages = pages;
> > return 0;
> > @@ -366,7 +364,6 @@ ivpu_bo_alloc(struct ivpu_device *vdev, u64 size, u32 flags, const struct ivpu_b
> > switch (flags & DRM_IVPU_BO_CACHE_MASK) {
> > case DRM_IVPU_BO_CACHED:
> > - case DRM_IVPU_BO_UNCACHED:
> > case DRM_IVPU_BO_WC:
> > break;
> > default:
> > diff --git a/include/uapi/drm/ivpu_accel.h b/include/uapi/drm/ivpu_accel.h
> > index 262db0c3beee..de1944e42c65 100644
> > --- a/include/uapi/drm/ivpu_accel.h
> > +++ b/include/uapi/drm/ivpu_accel.h
> > @@ -196,7 +196,7 @@ struct drm_ivpu_bo_create {
> > *
> > * %DRM_IVPU_BO_UNCACHED:
> > *
> > - * Allocated BO will not be cached on host side nor snooped on the VPU side.
> > + * Not supported. Use DRM_IVPU_BO_WC instead.
> > *
> > * %DRM_IVPU_BO_WC:
> > *
>
> Feels like this will break existing userspace. You could see if userspace
> specified UNCACHED and change it to WC before processing the request. Maybe
> also use WARN_ONCE to indicate that userspace should be updated.
>
> Or is it the case that userspace never actually used this?
Usage of those buffers was removed some time ago:
https://github.com/intel/linux-vpu-driver/commit/c473c9826cb28fa3dcf8883fc804b1e84c6b5fb1
And will not be part of first user-mode driver release. I think we can
safely do the change.
Regards
Stanislaw
next prev parent reply other threads:[~2023-09-19 9:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 16:48 [RFC 0/4] accel/ivpu: Use GEM shmem Stanislaw Gruszka
2023-09-01 16:48 ` [RFC 1/4] accel/ivpu: Allocate vpu_addr in gem->open() callback Stanislaw Gruszka
2023-09-11 15:19 ` Jeffrey Hugo
2023-09-19 9:24 ` Stanislaw Gruszka
2023-09-22 15:20 ` Jeffrey Hugo
2023-09-01 16:48 ` [RFC 2/4] accel/ivpu: Fix locking in ivpu_bo_remove_all_bos_from_context() Stanislaw Gruszka
2023-09-11 15:21 ` Jeffrey Hugo
2023-09-01 16:48 ` [RFC 3/4] accel/ivpu: Remove support for uncached buffers Stanislaw Gruszka
2023-09-11 15:24 ` Jeffrey Hugo
2023-09-19 9:49 ` Stanislaw Gruszka [this message]
2023-09-22 15:21 ` Jeffrey Hugo
2023-09-01 16:48 ` [RFC 4/4] accel/ivpu: Use GEM shmem helper for all buffers Stanislaw Gruszka
2023-09-11 15:27 ` Jeffrey Hugo
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=20230919094930.GB563961@linux.intel.com \
--to=stanislaw.gruszka@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacek.lawrynowicz@linux.intel.com \
--cc=ogabbay@kernel.org \
--cc=quic_jhugo@quicinc.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.