From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: "Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Tomi Valkeinen" <tomba@kernel.org>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Tomasz Figa" <tfiga@chromium.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Emil Velikov" <emil.l.velikov@gmail.com>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
kernel@collabora.com, linux-media@vger.kernel.org
Subject: Re: [PATCH v4 6/6] drm/shmem-helper: Switch to reservation lock
Date: Mon, 26 Jun 2023 16:05:33 +0300 [thread overview]
Message-ID: <4f652b3b-8691-84f4-037a-64950a30d496@collabora.com> (raw)
In-Reply-To: <20230626114014.2c837255@collabora.com>
On 6/26/23 12:40, Boris Brezillon wrote:
> I think here is the major problem I have with this patch: you've made
> drm_gem_shmem_{get_pages,pin}() private, which forces me to call
> drm_gem_shmem_pin() in a path where I already acquired the resv lock
> (using the drm_exec infra proposed by Christian). That would
> probably work if you were letting ret == -EALREADY go through, but I'm
> wondering if it wouldn't be preferable to expose
> drm_gem_shmem_pin_locked().
You should be free to expose the necessary functions. They are private
because nobody need them so far and we don't want to export unused
functions.
--
Best regards,
Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: dri-devel@lists.freedesktop.org,
"Thierry Reding" <thierry.reding@gmail.com>,
"John Stultz" <jstultz@google.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
kernel@collabora.com, "Sumit Semwal" <sumit.semwal@linaro.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
linux-media@vger.kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Tomi Valkeinen" <tomba@kernel.org>,
"Emil Velikov" <emil.l.velikov@gmail.com>,
linux-kernel@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH v4 6/6] drm/shmem-helper: Switch to reservation lock
Date: Mon, 26 Jun 2023 16:05:33 +0300 [thread overview]
Message-ID: <4f652b3b-8691-84f4-037a-64950a30d496@collabora.com> (raw)
In-Reply-To: <20230626114014.2c837255@collabora.com>
On 6/26/23 12:40, Boris Brezillon wrote:
> I think here is the major problem I have with this patch: you've made
> drm_gem_shmem_{get_pages,pin}() private, which forces me to call
> drm_gem_shmem_pin() in a path where I already acquired the resv lock
> (using the drm_exec infra proposed by Christian). That would
> probably work if you were letting ret == -EALREADY go through, but I'm
> wondering if it wouldn't be preferable to expose
> drm_gem_shmem_pin_locked().
You should be free to expose the necessary functions. They are private
because nobody need them so far and we don't want to export unused
functions.
--
Best regards,
Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: dri-devel@lists.freedesktop.org,
"John Stultz" <jstultz@google.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
kernel@collabora.com, "Sumit Semwal" <sumit.semwal@linaro.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
linux-media@vger.kernel.org, "Daniel Vetter" <daniel@ffwll.ch>,
"Arnd Bergmann" <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Tomi Valkeinen" <tomba@kernel.org>,
linux-kernel@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/shmem-helper: Switch to reservation lock
Date: Mon, 26 Jun 2023 16:05:33 +0300 [thread overview]
Message-ID: <4f652b3b-8691-84f4-037a-64950a30d496@collabora.com> (raw)
In-Reply-To: <20230626114014.2c837255@collabora.com>
On 6/26/23 12:40, Boris Brezillon wrote:
> I think here is the major problem I have with this patch: you've made
> drm_gem_shmem_{get_pages,pin}() private, which forces me to call
> drm_gem_shmem_pin() in a path where I already acquired the resv lock
> (using the drm_exec infra proposed by Christian). That would
> probably work if you were letting ret == -EALREADY go through, but I'm
> wondering if it wouldn't be preferable to expose
> drm_gem_shmem_pin_locked().
You should be free to expose the necessary functions. They are private
because nobody need them so far and we don't want to export unused
functions.
--
Best regards,
Dmitry
next prev parent reply other threads:[~2023-06-26 13:05 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-29 22:39 [PATCH v4 0/6] Move dma-buf mmap() reservation locking down to exporters Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 1/6] media: videobuf2: Don't assert held reservation lock for dma-buf mmapping Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 2/6] dma-buf/heaps: " Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-06-21 17:21 ` T.J. Mercier
2023-06-21 17:21 ` [Intel-gfx] " T.J. Mercier
2023-06-21 17:21 ` T.J. Mercier
2023-06-21 18:16 ` Dmitry Osipenko
2023-06-21 18:16 ` [Intel-gfx] " Dmitry Osipenko
2023-06-21 18:16 ` Dmitry Osipenko
2023-06-21 19:24 ` T.J. Mercier
2023-06-21 19:24 ` T.J. Mercier
2023-06-21 19:24 ` [Intel-gfx] " T.J. Mercier
2023-05-29 22:39 ` [PATCH v4 3/6] udmabuf: " Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 4/6] drm: " Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 5/6] dma-buf: Change locking policy for mmap() Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
[not found] ` <91466907-d4e1-1619-27a8-a49a01cbc8f1@collabora.com>
2023-06-20 15:58 ` Dmitry Osipenko
2023-06-20 15:58 ` [Intel-gfx] " Dmitry Osipenko
2023-06-20 15:58 ` Dmitry Osipenko
2023-06-21 5:42 ` Christian König
2023-06-21 5:42 ` Christian König
2023-06-21 5:42 ` [Intel-gfx] " Christian König
2023-06-21 18:17 ` Dmitry Osipenko
2023-06-21 18:17 ` Dmitry Osipenko
2023-06-21 18:17 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 6/6] drm/shmem-helper: Switch to reservation lock Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-06-26 9:40 ` Boris Brezillon
2023-06-26 9:40 ` [Intel-gfx] " Boris Brezillon
2023-06-26 9:40 ` Boris Brezillon
2023-06-26 9:57 ` Boris Brezillon
2023-06-26 9:57 ` [Intel-gfx] " Boris Brezillon
2023-06-26 9:57 ` Boris Brezillon
2023-06-26 13:05 ` Dmitry Osipenko
2023-06-26 13:05 ` [Intel-gfx] " Dmitry Osipenko
2023-06-26 13:05 ` Dmitry Osipenko
2023-06-26 13:05 ` Dmitry Osipenko [this message]
2023-06-26 13:05 ` [Intel-gfx] " Dmitry Osipenko
2023-06-26 13:05 ` Dmitry Osipenko
2023-05-31 2:17 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move dma-buf mmap() reservation locking down to exporters (rev4) Patchwork
2023-05-31 2:35 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-06-21 19:13 ` [PATCH v4 0/6] Move dma-buf mmap() reservation locking down to exporters Dmitry Osipenko
2023-06-21 19:13 ` [Intel-gfx] " Dmitry Osipenko
2023-06-21 19:13 ` Dmitry Osipenko
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=4f652b3b-8691-84f4-037a-64950a30d496@collabora.com \
--to=dmitry.osipenko@collabora.com \
--cc=Brian.Starkey@arm.com \
--cc=arnd@arndb.de \
--cc=benjamin.gaignard@collabora.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jstultz@google.com \
--cc=kernel@collabora.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=tfiga@chromium.org \
--cc=thierry.reding@gmail.com \
--cc=tomba@kernel.org \
--cc=tzimmermann@suse.de \
/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.