Factor out pages unpinning code from drm_gem_shmem_purge() into new
drm_gem_shmem_unpin_pages(). This prepares code for addition of memory
shrinker support. The new common function will be used by shrinker for
eviction of shmem pages.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm
Export drm_gem_shmem_get_pages_sgt_locked() that will be used by virtio-gpu
shrinker during GEM swap-in operation done under the held reservation lock.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 1 +
include/drm/drm_gem_shmem_helper.h | 1 +
2 files changed
-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 67 +-
1 file changed, 54 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index ad01c43ff26e..49ab49454783 100644
--- a/drivers/gpu/
do
that. Switch the vmap/vunmap to use pin/unpin functions in a preparation
of addition of the memory shrinker support.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers
mann.
- Added acks and r-b's that were given to v10.
v10:- Was partially applied to misc-fixes/next.
https://lore.kernel.org/dri-devel/6c16f303-81df-7ebe-85e9-51bb40a8b...@collabora.com/T/
Dmitry Osipenko (10):
drm/shmem-helper: Factor out pages alloc/release from
drm_gem_sh
On 2/17/23 16:19, Thomas Zimmermann wrote:
>> +/**
>> + * drm_gem_shmem_swap_in() - Moves shmem GEM back to memory and enables
>> + * hardware access to the memory.
>
> Do we have a better name than _swap_in()? I suggest
> drm_gem_shmem_unevict(), which suggest that it's
On 2/17/23 15:02, Thomas Zimmermann wrote:
> Hi
>
> Am 08.01.23 um 22:04 schrieb Dmitry Osipenko:
>> Consider this scenario:
>>
>> 1. APP1 continuously creates lots of small GEMs
>> 2. APP2 triggers `drop_caches`
>> 3. Shrinker starts to evict APP1
On 2/17/23 16:41, Dmitry Osipenko wrote:
> On 2/17/23 16:28, Thomas Zimmermann wrote:
>> Hi,
>>
>> I looked through the series. Most of the patches should have an r-b or
>> a-b at this point. I can't say much about patch 2 and had questions
>> about others.
&g
On 12/7/22 04:13, yang.yan...@zte.com.cn wrote:
> From: Xu Panda
>
> The implementation of strscpy() is more robust and safer.
> That's now the recommended way to copy NUL terminated strings.
>
> Signed-off-by: Xu Panda
> Signed-off-by: Yang Yang
> ---
> drivers/gpu/drm/virtio/virtgpu_vq.c |
On 2/21/23 19:29, Dmitry Osipenko wrote:
> On 2/20/23 18:44, Dmitry Osipenko wrote:
>> On 2/16/23 23:44, Jani Nikula wrote:
>>> Mostly this is prep work and plumbing for easier use of displayid
>>> structure version and primary use case for parsing the displayid block
On 2/16/23 18:35, Rob Clark wrote:
> On Sun, Jan 8, 2023 at 1:13 PM Dmitry Osipenko
> wrote:
>>
>> drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
>> in the dma-buf shmem GEM object getting prematurely freed leading to a
>> later use-af
On 2/25/23 17:55, Dmitry Osipenko wrote:
> On 2/24/23 18:34, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> The "vdev->dev.parent" should be used instead of "vdev->dev" as a device
>> for which to perform the DMA opera
On 2/5/23 15:51, Asahi Lina wrote:
> -EXPORT_SYMBOL_GPL(drm_gem_shmem_get_pages_sgt);
> +EXPORT_SYMBOL(drm_gem_shmem_get_pages_sgt);
Note it was a GPL symbol. I expect that all drm-shmem exports should be GPL.
--
Best regards,
Dmitry
On 1/19/23 03:41, Dmitry Osipenko wrote:
> + ret = drm_syncobj_find_fence(file, syncobj_desc.handle,
> + syncobj_desc.point, 0, &in_fence);
> + if (ret)
> + break;
> +
> + if (!d
On 2/24/23 21:02, Rob Clark wrote:
> obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index ae97b98750b6..9cb7d6dd3da6 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virt
m(bo) && use_dma_api)
> - dma_sync_sgtable_for_device(&vgdev->vdev->dev,
> + dma_sync_sgtable_for_device(vgdev->vdev->dev.parent,
> bo->base.sgt, DMA_TO_DEVICE);
>
> cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
Indeed, it's only the vgpu drm device that was moved to use the pci
parent device. On x86 the vdev always has dma-ops, also
virtio_has_dma_quirk=true for modern Qemu. So I didn't test this code
path and apparently it's only testable on Xen, which is good to know.
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 2/20/23 18:44, Dmitry Osipenko wrote:
> On 2/16/23 23:44, Jani Nikula wrote:
>> Mostly this is prep work and plumbing for easier use of displayid
>> structure version and primary use case for parsing the displayid blocks,
>> but it can be nicely used for figurin
_for_each(block, &iter) {
> - if (block->tag == DATA_BLOCK_TILED_DISPLAY)
> + if (displayid_is_tiled_block(&iter, block))
> drm_parse_tiled_block(connector, block);
> }
> displayid_iter_end(&iter);
I don't have display setup to test this, but looks okay.
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 2/16/23 23:45, Jani Nikula wrote:
> Use the DisplayID 2.0 primary use case information to deduce whether
> this is a head-mounted display, and should not be used for desktop.
>
> Cc: Iaroslav Boliukin
> Cc: Dmitry Osipenko
> Signed-off-by: Jani Nikula
> ---
> dr
th store and
> retrieve the information during parsing.
>
> Promote using accessors rather than users poking at the iterator
> directly.
>
> Cc: Iaroslav Boliukin
> Cc: Dmitry Osipenko
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_displayid.c | 30
On 2/16/23 23:44, Jani Nikula wrote:
> Avoid figuring out the header pointer multiple times.
>
> Cc: Iaroslav Boliukin
> Cc: Dmitry Osipenko
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_displayid.c | 17 -
> 1 file changed, 8 insertions(+),
On 2/16/23 23:44, Jani Nikula wrote:
> Add a helper to get a pointer to struct displayid_header. To be
> pedantic, add buffer overflow checks to not touch the base if that
> itself would overflow.
>
> Cc: Iaroslav Boliukin
> Cc: Dmitry Osipenko
> Signed-off-by: Jani Nikula
; BR,
> Jani.
>
> Cc: Iaroslav Boliukin
> Cc: Dmitry Osipenko
>
> Jani Nikula (4):
> drm/displayid: add displayid_get_header() and check bounds better
> drm/displayid: return struct displayid_header from
> validate_displayid()
> drm/displayid: provide acc
On 2/17/23 16:28, Thomas Zimmermann wrote:
> Hi,
>
> I looked through the series. Most of the patches should have an r-b or
> a-b at this point. I can't say much about patch 2 and had questions
> about others.
>
> Maybe you can already land patches 2, and 4 to 6? They look independent
> from the
On 2/17/23 15:52, Thomas Zimmermann wrote:
> Hi
>
> Am 08.01.23 um 22:04 schrieb Dmitry Osipenko:
>> Replace all drm-shmem locks with a GEM reservation lock. This makes locks
>> consistent with dma-buf locking convention where importers are
>> responsible
>> for
On 2/16/23 15:15, Daniel Vetter wrote:
> On Mon, Jan 30, 2023 at 03:02:10PM +0300, Dmitry Osipenko wrote:
>> On 1/27/23 11:13, Gerd Hoffmann wrote:
>>> On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote:
>>>> Hello Thomas and Gerd,
>>>>
&
On 2/16/23 21:26, Iaroslav Boliukin wrote:
> On 2/14/23 12:50, Dmitry Osipenko wrote:
>> On 2/13/23 14:50, Jani Nikula wrote:
>>> On Mon, 13 Feb 2023, Dmitry Osipenko
>>> wrote:
>>>> On 2/13/23 12:56, Jani Nikula wrote:
>>>>> On Sun
return ERR_PTR(-ENOMEM);
>
> @@ -656,7 +656,6 @@ static struct msm_submit_post_dep
> *msm_parse_post_deps(struct drm_device *dev,
> }
>
> post_deps[i].point = syncobj_desc.point;
> - post_deps[i].chain = NULL;
>
> if (sync
On 2/13/23 14:50, Jani Nikula wrote:
> On Mon, 13 Feb 2023, Dmitry Osipenko wrote:
>> On 2/13/23 12:56, Jani Nikula wrote:
>>> On Sun, 12 Feb 2023, Dmitry Osipenko wrote:
>>>> Hi,
>>>>
>>>> On 1/18/22 20:00, Yaroslav Bolyukin wrote:
>>&
On 2/13/23 12:56, Jani Nikula wrote:
> On Sun, 12 Feb 2023, Dmitry Osipenko wrote:
>> Hi,
>>
>> On 1/18/22 20:00, Yaroslav Bolyukin wrote:
>>
>> Add a brief commit message, describing a user-visible effect of this
>> patch. Tell that this change prevents e
Hi,
On 1/18/22 20:00, Yaroslav Bolyukin wrote:
Add a brief commit message, describing a user-visible effect of this
patch. Tell that this change prevents exposing headset as a regular
display to the system, while it will work with SteamVR.
> Signed-off-by: Yaroslav Bolyukin
> ---
> drivers/gpu
icit
> synchronization")
> Signed-off-by: Ryan Neph
> Reviewed-by: Rob Clark
> Reviewed-by: Dmitry Osipenko
>
> ---
>
> Changes in v2:
> - No longer modifies exbuf->fence_fd unless DRM_IOCTL_VIRTGPU_EXECBUFFER
> succeeds.
> - Added r-b tags (Rob/Dmitry) from v1.
Thanks! Applied to misc-fixes
--
Best regards,
Dmitry
truct drm_virtgpu_map {
> __u32 pad;
> };
>
> +/* For ioctl() returning ERESTARTSYS or EINTR, fence_fd is unmodified.
> + * For all other errors it is set to -1.
> + */
> struct drm_virtgpu_execbuffer {
> __u32 flags;
> __u32 size;
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 2/2/23 05:17, Dmitry Osipenko wrote:
> On 2/1/23 18:48, Rob Clark wrote:
>> On Wed, Feb 1, 2023 at 5:28 AM Dmitry Osipenko
>> wrote:
>>>
>>> On 1/27/23 01:58, Ryan Neph wrote:
>>>> An interrupted dma_fence_wait() becomes an
On 2/1/23 18:48, Rob Clark wrote:
> On Wed, Feb 1, 2023 at 5:28 AM Dmitry Osipenko
> wrote:
>>
>> On 1/27/23 01:58, Ryan Neph wrote:
>>> An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned
>>> to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) cal
On 1/27/23 01:58, Ryan Neph wrote:
> An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned
> to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to
> retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1,
> making the retry attempt fail at sync_file_get_fen
On 1/27/23 11:13, Gerd Hoffmann wrote:
> On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote:
>> Hello Thomas and Gerd,
>>
>> On 1/9/23 00:04, Dmitry Osipenko wrote:
>>> This series:
>>>
>>> 1. Makes minor fixes for drm_gem_lru and Pan
On 1/9/23 00:13, Dmitry Osipenko wrote:
> drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
> in the dma-buf shmem GEM object getting prematurely freed leading to a
> later use-after-free.
>
> Fixes: f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_m
On 1/26/23 15:17, Gerd Hoffmann wrote:
> On Mon, Jan 09, 2023 at 12:04:40AM +0300, Dmitry Osipenko wrote:
>> its own refcounting of vmaps, use it instead of drm-shmem
>> counting. This change prepares drm-shmem for addition of memory shrinker
>> support where drm-shmem will
Hello Thomas and Gerd,
On 1/9/23 00:04, Dmitry Osipenko wrote:
> This series:
>
> 1. Makes minor fixes for drm_gem_lru and Panfrost
> 2. Brings refactoring for older code
> 3. Adds common drm-shmem memory shrinker
> 4. Enables shrinker for VirtIO-GPU driver
>
NERS
> @@ -20563,10 +20563,12 @@ TEGRA VIDEO DRIVER
> M: Thierry Reding
> M: Jonathan Hunter
> M: Sowjanya Komatineni
> +M: Luca Ceresoli
> L: linux-me...@vger.kernel.org
> L: linux-te...@vger.kernel.org
> S: Maintained
> F:
> Documentation
On 1/25/23 00:14, Luca Ceresoli wrote:
> Hi Dmitry,
>
> On Tue, 24 Jan 2023 20:02:39 +0300
> Dmitry Osipenko wrote:
>
>> On 12/29/22 16:31, Luca Ceresoli wrote:
>>> +vip {
>>> +compatible = "nvidia,tegra20-vip";
>>>
On 12/29/22 16:31, Luca Ceresoli wrote:
> +vip {
> +compatible = "nvidia,tegra20-vip";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +channel@0 {
> +reg = <0>;
> +ports {
> +#address-cells
Add sync object DRM UAPI support to VirtIO-GPU driver. It's required
for enabling full-featured Vulkan fencing by Venus and native context
VirtIO-GPU Mesa drivers.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c
VirtIO-GPU IOCTL and more. Today we have several VirtIO-GPU context
drivers in works that require VirtIO-GPU to support sync objects UAPI.
The patch is heavily inspired by the sync object UAPI implementation of the
MSM driver.
Dmitry Osipenko (1):
drm/virtio: Support sync objects
drivers/gpu/drm
16.01.2023 18:11, Christian König пишет:
>
>
>> mmapping the memory with that new offset should still work. The
>> imported BO is created with ttm_bo_type_sg, and AFAICT ttm_bo_vm.c
>> supports mapping of SG BOs.
>
> Actually it shouldn't. This can go boom really easily.
>>
Hello Sean,
On 1/11/23 20:05, Sean Christopherson wrote:
> On Thu, Aug 18, 2022, Christian König wrote:
>> Am 18.08.22 um 01:13 schrieb Dmitry Osipenko:
>>> On 8/18/22 01:57, Dmitry Osipenko wrote:
>>>> On 8/15/22 18:54, Dmitry Osipenko wrote:
>>>>
On 1/10/23 04:47, Rob Clark wrote:
> On Mon, Jan 9, 2023 at 3:28 PM Dmitry Osipenko
> wrote:
>>
>> On 12/17/22 02:33, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> Userspace can guess the handle value and try to race GEM object creation
>>>
On 12/17/22 02:33, Rob Clark wrote:
> From: Rob Clark
>
> Userspace can guess the handle value and try to race GEM object creation
> with handle close, resulting in a use-after-free if we dereference the
> object after dropping the handle's reference. For that reason, dropping
> the handle's ref
drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
in the dma-buf shmem GEM object getting prematurely freed leading to a
later use-after-free.
Fixes: f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_mmap forwarding bug")
Cc: sta...@vger.kernel.org
Signed-off-by:
Replace Panfrost's custom memory shrinker with a common drm-shmem
memory shrinker.
Tested-by: Steven Price # Firefly-RK3288
Reviewed-by: Steven Price
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 2 -
drivers/gpu/drm/panfrost/Makefile
memory if
guest supports SWAP file or partition.
Signed-off-by: Daniel Almeida
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 18 +++-
drivers/gpu/drm/virtio/virtgpu_gem.c| 52 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 37 +++
drivers/gpu/drm/virti
Add unlocked variants of drm_gem_un/pin() functions. These new helpers
will take care of GEM dma-reservation locking for DRM drivers.
VirtIO-GPU driver will use these helpers to pin shmem framebuffers,
preventing them from eviction during scanout.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu
. Initialize drm-shmem internals using drmm_gem_shmem_init(drm_device),
which will register drm-shmem shrinker
3. Implement madvise IOCTL that will use drm_gem_shmem_madvise()
Signed-off-by: Daniel Almeida
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 460
: Daniel Vetter
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 185 +++---
drivers/gpu/drm/lima/lima_gem.c | 8 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +-
.../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +-
drivers
DMA-buf core has its own refcounting of vmaps, use it instead of drm-shmem
counting. This change prepares drm-shmem for addition of memory shrinker
support where drm-shmem will use a single dma-buf reservation lock for
all operations performed over dma-bufs.
Signed-off-by: Dmitry Osipenko
Ease debugging of a multi-GPU system by using drm_WARN_*() and
drm_dbg_kms() helpers that print out DRM device name corresponding
to shmem GEM.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 38 +++---
1 file
Group all 1-bit boolean members of struct drm_gem_shmem_object in the end
of the structure, allowing compiler to pack data better and making code to
look more consistent.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
include/drm/drm_gem_shmem_helper.h | 30
Add new common evict() callback to drm_gem_object_funcs and corresponding
drm_gem_object_evict() helper. This is a first step on a way to providing
common GEM-shrinker API for DRM drivers.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 16
table flushing and runtime PM
interaction ")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 4e83a1891f3e..66
ed-by: Rob Clark
Fixes: b352ba54a820 ("drm/msm/gem: Convert to using drm_gem_lru")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 9 +++--
drivers/gpu/drm/msm/msm_gem_shrinker.c | 8 ++--
include/drm/drm_gem.h | 4 +++-
3 files changed
ommits/panfrost-madvise
The Mesa and IGT patches will be sent out once the kernel part will land.
Dmitry Osipenko (11):
drm/msm/gem: Prevent blocking within shrinker loop
drm/panfrost: Don't sync rpm suspension after mmu flushing
drm/gem: Add evict() callback to drm_gem_object_funcs
drm/
On 1/2/23 17:17, youling 257 wrote:
> which patch?
https://patchwork.freedesktop.org/patch/512652/
I applied it to next-fixes
--
Best regards,
Dmitry
On 11/23/22 03:13, Dmitry Osipenko wrote:
> The drm_sched_entity_kill() is invoked twice by drm_sched_entity_destroy()
> while userspace process is exiting or being killed. First time it's invoked
> when sched entity is flushed and second time when entity is released. This
> cause
On 11/9/22 12:19, Xiu Jianfeng wrote:
> The virtio_gpu_object_shmem_init() will alloc memory and save it in
> @ents, so when virtio_gpu_array_alloc() fails, this memory should be
> freed, this patch fixes it.
>
> Fixes: e7fef0923303 ("drm/virtio: Simplify error handling of
> virtio_gpu_object_cre
On 11/30/22 03:08, Rob Clark wrote:
> From: Rob Clark
>
> Add a sequence # for more easily matching up cmd/resp, and the # of free
> slots in the virtqueue to more easily see starvation issues.
>
> v2: Fix handling of string fields as well
>
> Signed-off-by: Rob Clar
On 1/1/23 21:29, youling257 wrote:
> Linux 6.2-rc1 has memory leak on amdgpu, git bisect bad commit is
> "drm/scheduler: rework entity flush, kill and fini".
> git bisect start
> # status: waiting for both good and bad commits
> # good: [eb7081409f94a9a8608593d0fb63a1aa3d6f95d8] Linux 6.1-rc6
> gi
Hi,
On 12/27/22 22:28, Guilherme G. Piccoli wrote:
> Hi Dmitry / Christian, thanks for the fix!
>
> (And thanks Melissa for pointing that, saving me lots of time in
> research heh)
>
> Is this fix planned to be released on 6.2-rc cycle? I've just tested it
> on Steam Deck, and it resolved a lock
23.12.2022 16:02, Dmitry Osipenko пишет:
> 28.11.2022 18:23, Luca Ceresoli пишет:
>> +static int tegra20_vip_start_streaming(struct tegra_vip_channel *vip_chan)
>> +{
>> +struct tegra_vi_channel *vi_chan =
>> v4l2_get_subdev_hostdata(&vip_chan->sub
28.11.2022 18:23, Luca Ceresoli пишет:
> +static int tegra20_vip_start_streaming(struct tegra_vip_channel *vip_chan)
> +{
> + struct tegra_vi_channel *vi_chan =
> v4l2_get_subdev_hostdata(&vip_chan->subdev);
> + int width = vi_chan->format.width;
> + int height = vi_chan->format.heigh
28.11.2022 18:23, Luca Ceresoli пишет:
> +/* --
> + * VIP
> + */
> +
> +/*
> + * VIP-specific configuration for stream start.
> + *
> + * Whatever is common among VIP and CSI is done by the VI component (see
> + * tegra20_vi_st
23.12.2022 15:15, Dmitry Osipenko пишет:
> 22.12.2022 12:03, Luca Ceresoli пишет:
>> Hello Dmitry,
>>
>> On Wed, 21 Dec 2022 00:40:20 +0300
>> Dmitry Osipenko wrote:
>>
>>> 28.11.2022 18:23, Luca Ceresoli пишет:
>>>> +static int tegra
22.12.2022 12:03, Luca Ceresoli пишет:
> Hello Dmitry,
>
> On Wed, 21 Dec 2022 00:40:20 +0300
> Dmitry Osipenko wrote:
>
>> 28.11.2022 18:23, Luca Ceresoli пишет:
>>> +static int tegra20_channel_capture_frame(struct tegra_vi_channel *chan,
>>> +
28.11.2022 18:23, Luca Ceresoli пишет:
> +static int tegra20_channel_capture_frame(struct tegra_vi_channel *chan,
> + struct tegra_channel_buffer *buf)
> +{
> + u32 value;
> + int err;
> +
> + chan->next_out_sp_idx++;
> +
> + tegra20_channel_vi_b
28.11.2022 18:23, Luca Ceresoli пишет:
> Tegra20 and other Tegra SoCs have a video input (VI) peripheral that can
> receive from either MIPI CSI-2 or parallel video (called respectively "CSI"
> and "VIP" in the documentation). The kernel currently has a staging driver
> for Tegra210 CSI capture. Th
02.12.2022 11:11, Luca Ceresoli пишет:
> Hello Rob,
>
> Thanks for your review.
>
> On Thu, 1 Dec 2022 17:19:36 -0600
> Rob Herring wrote:
>
>> On Mon, Nov 28, 2022 at 04:23:16PM +0100, Luca Ceresoli wrote:
>>> VIP is the parallel video capture component within the video input
>>> subsystem of
On 11/30/22 21:57, Rob Clark wrote:
> From: Rob Clark
>
> drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM
> object getting prematurely freed leading to a later use-after-free.
>
> Link: https://syzkaller.appspot.com/bug?extid=c8ae65286134dd1b800d
> Reported-by: syzbot+c8ae6
| 3 +++
> drivers/gpu/drm/virtio/virtgpu_trace.h | 20
> drivers/gpu/drm/virtio/virtgpu_vq.c| 13 ++---
> 3 files changed, 25 insertions(+), 11 deletions(-)
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 11/23/22 18:58, Steven Price wrote:
> On 23/11/2022 02:57, Dmitry Osipenko wrote:
>> Add new common evict() callback to drm_gem_object_funcs and corresponding
>> drm_gem_object_evict() helper. This is a first step on a way to providing
>> common GEM-shrinker API for DRM dri
On 11/23/22 03:13, Dmitry Osipenko wrote:
> The drm_sched_entity_kill() is invoked twice by drm_sched_entity_destroy()
> while userspace process is exiting or being killed. First time it's invoked
> when sched entity is flushed and second time when entity is released. This
> cause
memory if
guest supports SWAP file or partition.
Signed-off-by: Daniel Almeida
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 18 +++-
drivers/gpu/drm/virtio/virtgpu_gem.c| 52 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 37 +++
drivers/gpu/drm/virti
Lockdep warns about potential circular locking dependency of devfreq
with the fs_reclaim caused by immediate device suspension when mapping is
released by shrinker. Fix it by doing the suspension asynchronously.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2
ff-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 9 +++--
drivers/gpu/drm/msm/msm_gem_shrinker.c | 8 ++--
include/drm/drm_gem.h | 4 +++-
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_
. Initialize drm-shmem internals using drmm_gem_shmem_init(drm_device),
which will register drm-shmem shrinker
3. Implement madvise IOCTL that will use drm_gem_shmem_madvise()
Signed-off-by: Daniel Almeida
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 465
: Daniel Vetter
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 183 +++---
drivers/gpu/drm/lima/lima_gem.c | 8 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +-
.../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +-
drivers
Add unlocked variants of drm_gem_un/pin() functions. These new helpers
will take care of GEM dma-reservation locking for DRM drivers.
VirtIO-GPU driver will use these helpers to pin shmem framebuffers,
preventing them from eviction during scanout.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu
DMA-buf core has its own refcounting of vmaps, use it instead of drm-shmem
counting. This change prepares drm-shmem for addition of memory shrinker
support where drm-shmem will use a single dma-buf reservation lock for
all operations performed over dma-bufs.
Signed-off-by: Dmitry Osipenko
Replace Panfrost's custom memory shrinker with a common drm-shmem
memory shrinker.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 2 -
drivers/gpu/drm/panfrost/Makefile | 1 -
drivers/gpu/drm/panfrost/panfrost_device.h| 4 -
driver
Group all 1-bit boolean members of struct drm_gem_shmem_object in the end
of the structure, allowing compiler to pack data better and making code to
look more consistent.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
include/drm/drm_gem_shmem_helper.h | 30
Add new common evict() callback to drm_gem_object_funcs and corresponding
drm_gem_object_evict() helper. This is a first step on a way to providing
common GEM-shrinker API for DRM drivers.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 15
Ease debugging of a multi-GPU system by using drm_WARN_*() and
drm_dbg_kms() helpers that print out DRM device name corresponding
to shmem GEM.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 38 +++---
1 file
patches once the kernel part will land.
Dmitry Osipenko (11):
drm/msm/gem: Prevent blocking within shrinker loop
drm/gem: Add evict() callback to drm_gem_object_funcs
drm/panfrost: Don't sync rpm suspension after mmu flushing
drm/shmem: Put booleans in the end of struct drm_gem_shmem_
that is reproducible by killing
any application in a middle of 3d drawing operation.
Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c |
On 11/17/22 20:08, Lukasz Wiecaszek wrote:
> On Thu, Nov 17, 2022 at 12:04:35PM +0300, Dmitry Osipenko wrote:
>> Hi,
>>
>> On 11/17/22 07:58, Lukasz Wiecaszek wrote:
>>> The reason behind that patch is associated with videobuf2 subsystem
>>> (or more genrall
On 11/17/22 18:09, Christian König wrote:
> Am 17.11.22 um 15:41 schrieb Dmitry Osipenko:
>> [SNIP]
>>> drm_sched_entity_flush() should be called from the flush callback from
>>> the file_operations structure of panfrost. See amdgpu_flush() and
>>> amdgpu_ctx
On 11/17/22 16:11, Christian König wrote:
> Am 17.11.22 um 14:00 schrieb Dmitry Osipenko:
>> On 11/17/22 15:59, Dmitry Osipenko wrote:
>>> On 11/17/22 15:55, Christian König wrote:
>>>> Am 17.11.22 um 13:47 schrieb Dmitry Osipenko:
>>>>> On 11/17/22 12:
On 11/17/22 15:59, Dmitry Osipenko wrote:
> On 11/17/22 15:55, Christian König wrote:
>> Am 17.11.22 um 13:47 schrieb Dmitry Osipenko:
>>> On 11/17/22 12:53, Christian König wrote:
>>>> Am 17.11.22 um 03:36 schrieb Dmitry Osipenko:
>>>>> Hi,
>>
On 11/17/22 15:55, Christian König wrote:
> Am 17.11.22 um 13:47 schrieb Dmitry Osipenko:
>> On 11/17/22 12:53, Christian König wrote:
>>> Am 17.11.22 um 03:36 schrieb Dmitry Osipenko:
>>>> Hi,
>>>>
>>>> On 10/14/22 11:46, Christian König wro
On 11/17/22 12:53, Christian König wrote:
> Am 17.11.22 um 03:36 schrieb Dmitry Osipenko:
>> Hi,
>>
>> On 10/14/22 11:46, Christian König wrote:
>>> +/* Remove the entity from the scheduler and kill all pending jobs */
>>> +static void drm_sched_enti
Hi,
On 11/17/22 07:58, Lukasz Wiecaszek wrote:
> The reason behind that patch is associated with videobuf2 subsystem
> (or more genrally with v4l2 framework) and user created
> dma buffers (udmabuf). In some circumstances
> when dealing with V4L2_MEMORY_DMABUF buffers videobuf2 subsystem
> wants t
401 - 500 of 2018 matches
Mail list logo
