similar to: [PATCH 5/6] drm/fb-helper: Consolidate CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM

This patch changes DRM clients to not map the buffer by default. The buffer, like any buffer object, should be mapped and unmapped when needed. An unmapped buffer object can be evicted to system memory and does not consume video ram until displayed. This allows to use generic fbdev emulation with drivers for low-memory devices, such as ast and mgag200. This change affects the generic framebuffer

Hello Thomas, On 1/10/23 13:35, Thomas Zimmermann wrote: > Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") > converted nouveau to generic fbdev emulation. The driver's internal > implementation later got accidentally restored during a merge commit. > Remove the file from the driver. No functional changes. > > v2: > * point Fixes tag to

On Fri, Mar 10, 2023 at 01:59:42PM +0100, Javier Martinez Canillas wrote: > Christian Hergert reports that the driver doesn't enable the property and > that leads to always doing a full plane update, even when the driver does > support damage clipping for the primary plane. > > Don't enable it for the cursor plane, because its .atomic_update callback > doesn't handle

Hi On 22.10.20 10:49, Daniel Vetter wrote: > On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote: >> Kernel DRM clients now store their framebuffer address in an instance >> of struct dma_buf_map. Depending on the buffer's location, the address >> refers to system or I/O memory. >> >> Callers of drm_client_buffer_vmap() receive a copy of the

Hello Uwe, On 12/19/22 09:36, Uwe Kleine-K?nig wrote: > While working on a drm driver that doesn't need the i2c algobit stuff I > noticed that DRM selects this code even though only 8 drivers actually use > it. While also only some drivers use i2c, keep the select for I2C for the > next cleanup patch. Still prepare this already by also selecting I2C for > the individual

From: Sui Jingfeng <suijingfeng at loongson.cn> This patch adds the aperture_contain_firmware_fb() function to do the determination. Unfortunately due to the fact that apertures list will be freed dynamically, the location and size information of the firmware fb will be lost after dedicated drivers call aperture_remove_conflicting_devices(), aperture_remove_conflicting_pci_devices() or

Hi Am 09.01.23 um 15:15 schrieb Alex Deucher: > On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> >> Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") >> converted nouveau to generic fbdev emulation. Also remove the internal >> implementation from the driver. No functional changes. > > Looking

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. The driver's internal implementation later got accidentally restored during a merge commit. Remove the file from the driver. No functional changes. v2: * point Fixes tag to merge commit (Alex) Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>

Kernel DRM clients now store their framebuffer address in an instance of struct dma_buf_map. Depending on the buffer's location, the address refers to system or I/O memory. Callers of drm_client_buffer_vmap() receive a copy of the value in the call's supplied arguments. It can be accessed and modified with dma_buf_map interfaces. v6: * don't call page_to_phys() on framebuffers in

On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote: > Kernel DRM clients now store their framebuffer address in an instance > of struct dma_buf_map. Depending on the buffer's location, the address > refers to system or I/O memory. > > Callers of drm_client_buffer_vmap() receive a copy of the value in > the call's supplied arguments. It can be accessed and

From: Rob Clark <robdclark at chromium.org> Add a build option to disable modesetting support. This is useful in cases where the guest only needs to use the GPU in a headless mode, or (such as in the CrOS usage) window surfaces are proxied to a host compositor. As the modesetting ioctls are a big surface area for potential security bugs to be found (it's happened in the past, we

Hi Am 16.02.23 um 13:52 schrieb Ville Syrj?l?: > On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote: >> Hi, >> >> thanks for taking a look at the patches. >> >> Am 16.02.23 um 12:33 schrieb Gerd Hoffmann: >>> On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote: >>>> Set the VGA bit for unblanking with macro

On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") > converted nouveau to generic fbdev emulation. Also remove the internal > implementation from the driver. No functional changes. Looking at 4a16dd9d18a0, it appears to have removed this file already. I guess it

Kernel DRM clients now store their framebuffer address in an instance of struct dma_buf_map. Depending on the buffer's location, the address refers to system or I/O memory. Callers of drm_client_buffer_vmap() receive a copy of the value in the call's supplied arguments. It can be accessed and modified with dma_buf_map interfaces. Signed-off-by: Thomas Zimmermann <tzimmermann at

Kernel DRM clients now store their framebuffer address in an instance of struct dma_buf_map. Depending on the buffer's location, the address refers to system or I/O memory. Callers of drm_client_buffer_vmap() receive a copy of the value in the call's supplied arguments. It can be accessed and modified with dma_buf_map interfaces. Signed-off-by: Thomas Zimmermann <tzimmermann at

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. Also remove the internal implementation from the driver. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") Cc: Ben Skeggs <bskeggs at redhat.com> Cc:

On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote: > Hi, > > thanks for taking a look at the patches. > > Am 16.02.23 um 12:33 schrieb Gerd Hoffmann: > > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote: > >> Set the VGA bit for unblanking with macro constants instead of magic > >> values. No functional changes. > >

Hi, thanks for taking a look at the patches. Am 16.02.23 um 12:33 schrieb Gerd Hoffmann: > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote: >> Set the VGA bit for unblanking with macro constants instead of magic >> values. No functional changes. > > blank/unblank should work simliar to bochs (see commit 250e743915d4), > that is maybe a nice thing to add

Hi Am 27.02.23 um 19:15 schrieb Rob Clark: > On Mon, Feb 27, 2023 at 9:57 AM Dmitry Osipenko > <dmitry.osipenko at collabora.com> wrote: >> >> On 2/27/23 20:38, Rob Clark wrote: >> ... >>> + if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS)) { >>> + /* get display info */ >>> + virtio_cread_le(vgdev->vdev, struct

I forgot this change. Am 08.01.23 um 22:04 schrieb Dmitry Osipenko: > 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