Re: [PATCH v2 2/2] drm/msm/dp: attach the DP subconnector property

On Wed, Oct 25, 2023 at 12:23:10PM +0300, Dmitry Baryshkov wrote: > While developing and testing the commit bfcc3d8f94f4 ("drm/msm/dp: > support setting the DP subconnector type") I had the patch [1] in my > tree. I haven't noticed that it was a dependency for the commit in > question. Mea culpa.

Re: [PATCH v2 1/2] drm/msm/dp: don't touch DP subconnector property in eDP case

On Wed, Oct 25, 2023 at 12:23:09PM +0300, Dmitry Baryshkov wrote: > From: Abel Vesa > > In case of the eDP connection there is no subconnetor and as such no > subconnector property. Put drm_dp_set_subconnector_property() calls > under the !is_edp condition. > > Fixes: bfcc3d8f94f4 ("drm/msm/dp:

Re: [PATCH] drm/sched: Define pr_fmt() for DRM using pr_*()

On Tue, 14 Nov 2023, Luben Tuikov wrote: > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h > index a93a387f8a1a15..ce784118e4f762 100644 > --- a/include/drm/drm_print.h > +++ b/include/drm/drm_print.h > @@ -453,7 +453,7 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct > dev

Re: [PATCH 09/11] drm/rockchip: vop2: Add support for rk3588

Am Mittwoch, 15. November 2023, 03:02:42 CET schrieb Andy Yan: > Hi Heiko: > > On 11/15/23 07:34, Heiko Stübner wrote: > > Hi Andy, > > > > Am Dienstag, 14. November 2023, 12:28:55 CET schrieb Andy Yan: > >> From: Andy Yan > >> > >> VOP2 on rk3588: > >> > >> Four video ports: > >> VP0 Max 4096x21

Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'

Hi Christian, CC virtgpu On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky wrote: > On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote: > > I can confirm there is no graphics output with m68k/virt, and Before the error message you reported: virtio-mmio virtio-mmio.125: [drm] *ERRO

Re: [PATCH v2 1/6] drm/msm/dpu: fix video mode DSC for DSI

On Wed, 15 Nov 2023 at 01:00, Jonathan Marek wrote: > > Add necessary DPU changes for DSC to work with DSI video mode. > > Note this changes the logic to enable HCTL to match downstream, it will > now be enabled for the no-DSC no-widebus case. > > Signed-off-by: Jonathan Marek > --- > drivers/gp

Re: [PATCH 09/11] drm/rockchip: vop2: Add support for rk3588

Hi Andy, Thanks for your patches, some remarks inline. On Tue, Nov 14, 2023 at 07:28:55PM +0800, Andy Yan wrote: > From: Andy Yan > > VOP2 on rk3588: > > Four video ports: > VP0 Max 4096x2160 > VP1 Max 4096x2160 > VP2 Max 4096x2160 > VP3 Max 2048x1080 > > 4 4K Cluster windows with AFBC/line R

Re: [PATCH] drm/nouveau: Prevents NULL pointer dereference in nouveau_uvmm_sm_prepare

Hello Danilo, On Tue, Nov 14, 2023 at 05:23:59PM +0100, Danilo Krummrich wrote: > Hi Yuran, > > op_map_prepare() can't be called with `args` being NULL, since when called > through nouveau_uvmm_sm_unmap_prepare() we can't hit the DRM_GPUVA_OP_MAP > case at all. > > Unmapping something never leads

Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'

On Wed, Nov 15, 2023 at 09:33:28AM +0100, Geert Uytterhoeven wrote: > Hi Christian, > > CC virtgpu > > On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky > wrote: > > On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote: > > > I can confirm there is no graphics output with m68k/virt, and >

Re: [PATCH v3 2/7] drm/radeon: Switch from pci_is_thunderbolt_attached() to dev_is_removable()

Am 14.11.23 um 21:07 schrieb Mario Limonciello: pci_is_thunderbolt_attached() looks at the hierarchy of the PCIe device to determine if any bridge along the way has the is_thunderbolt bit set. This bit will only be set when one of the devices in the hierarchy is an Intel Thunderbolt device. Howe

[PATCH] dma-buf: fix check in dma_resv_add_fence

It's valid to add the same fence multiple times to a dma-resv object and we shouldn't need one extra slot for each. Signed-off-by: Christian König Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really later") Cc: sta...@vger.kernel.org # v5.19+ --- drivers/dma-buf/dma-resv.c

[syzbot] [dri?] divide error in drm_mode_debug_printmodeline

Hello, syzbot found the following issue on: HEAD commit:ac347a0655db Merge tag 'arm64-fixes' of git://git.kernel.o.. git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=101ba588e8 kernel config: https://syzkaller.appspot.com/x/.config?x=88e7ba51eecd9cd6 das

Re: [PATCH] drm/doc/rfc: SR-IOV support on the new Xe driver

On 14/11/2023 16:55, Michal Wajdeczko wrote: On 14.11.2023 13:37, Tvrtko Ursulin wrote: On 10/11/2023 18:22, Michal Wajdeczko wrote: The Single Root I/O Virtualization (SR-IOV) extension to the PCI Express (PCIe) specification suite is supported starting from 12th generation of Intel Graphics

[PATCH 00/32] fbdev: Modularize helpers for struct fb_ops

Convert the remaining fbdev drivers to use fbdev's helpers macros for struct fb_ops. Then push the current default code for file-I/O operations into a module and remove it as default. Each driver now selects the helpers its needs for file I/O and drawing to its framebuffer. If no helper has been se

[PATCH 08/32] auxdisplay/cfag12864bfb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the

[PATCH 15/32] fbdev/udlfb: Select correct helpers

The driver uses deferred I/O. Select the correct helpers via FB_SYSMEM_HELPERS_DEFERRED in the Kconfig file. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev

[PATCH 02/32] fbdev/sm712fb: Use correct initializer macros for struct fb_ops

Only initialize mmap and draw helpers with macros; leave read/write callbacks to driver implementations. Fixes the following warnings: CC [M] drivers/video/fbdev/sm712fb.o sm712fb.c:1355:25: warning: initialized field overwritten [-Woverride-init] 1355 | .fb_fillrect = cfb_fillrect

[PATCH 17/32] fbdev/au1200fb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in DMA-able virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes re

[PATCH 20/32] media/ivtvfb: Initialize fb_ops to fbdev I/O-memory helpers

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in I/O address space. This explictily sets the read/write, draw and mmap callbacks to the correct default implementation. Fbdev drivers sometimes rely on the callbacks being NULL for a default implementation to

[PATCH 01/32] fbdev/acornfb: Fix name of fb_ops initializer macro

Fix build by using the correct name for the initializer macro for struct fb_ops. Signed-off-by: Thomas Zimmermann Fixes: 9037afde8b9d ("fbdev/acornfb: Use fbdev I/O helpers") Cc: Thomas Zimmermann Cc: Sam Ravnborg Cc: Helge Deller Cc: Javier Martinez Canillas Cc: Arnd Bergmann Cc: # v6.6+ -

[PATCH 04/32] fbdev/vfb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the

[PATCH 07/32] auxdisplay/cfag12864bfb: Set FBINFO_VIRTFB flag

The cfag12864bfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Miguel Ojeda --- drivers/auxdisplay/cfag12864bfb.c | 1 + 1 file changed, 1 insertion(+)

[PATCH 16/32] fbdev/au1200fb: Set FBINFO_VIRTFB flag

The au1200fb driver operates on DMA-able system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/au1200fb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a

[PATCH 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag

The picolcd_fb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: "Bruno Prémont" Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-in...@vger.kernel.org --

[PATCH 18/32] fbdev/ps3fb: Set FBINFO_VIRTFB flag

The ps3fb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: linuxppc-...@lists.ozlabs.org --

[PATCH 06/32] fbdev/arcfb: Use generator macros for deferred I/O

Implement the driver's fops with the generator macros for deferred I/O. Only requires per-driver code for the on-scren scanout buffer. The generated helpers implement reading, writing and drawing on top of that. Also update the selected Kconfig tokens accordingly. Actual support for deferred I/O i

[PATCH 27/32] fbdev: Rename FB_SYS_FOPS token to FB_SYSMEM_FOPS

Rename the token to harmonize naming among various helpers. For example, I/O-memory helpers use FB_IOMEM_FOPS. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 4 ++-- drivers/video/fbdev/core/Kconfig | 6 +++--- drivers/video/fbdev/core/Makefile | 2 +- 3 files changed,

[PATCH 13/32] fbdev/sh_mobile_lcdcfb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in DMA-able virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. The driver uses a mixture

[PATCH 28/32] fbdev: Remove trailing whitespaces

Fix coding style. No functional changes. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/sbuslib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c index 21e9fd8e69e26..4d524db5c4f26 100644 --- a/driver

[PATCH 14/32] fbdev/smscufx: Select correct helpers

The driver uses deferred I/O. Select the correct helpers via FB_SYSMEM_HELPERS_DEFERRED in the Kconfig file. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev

[PATCH 26/32] staging/sm750fb: Initialize fb_ops with fbdev macros

Initialize all instances of struct fb_ops with fbdev initializer macros for framebuffers in I/O address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the ca

[PATCH 25/32] staging/sm750fb: Declare fb_ops as constant

Split up lynxfb_ops and declare each as constant. The fb_ops instance used to be modified while initializing the driver. It is now constant and the driver picks the correct instance, depending on the settings for acceleration and cursor support. Signed-off-by: Thomas Zimmermann Cc: Sudip Mukherje

[PATCH 30/32] fbdev: Move default fb_mmap code into helper function

Move the default fb_mmap code for I/O address spaces into the helper function fb_io_mmap(). The helper can either be called via struct fb_ops.fb_mmap or as the default if no fb_mmap has been set. Also set the new helper in __FB_DEFAULT_IOMEM_OPS_MMAP. In the mid-term, fb_io_mmap() is supposed to b

[PATCH 10/32] auxdisplay/ht16k33: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the

[PATCH 24/32] fbdev/cyber2000fb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in I/O address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the cal

[PATCH 31/32] fbdev: Warn on incorrect framebuffer access

Test in framebuffer read, write and drawing helpers if FBINFO_VIRTFB has been set correctly. Framebuffers in I/O memory should only be accessed with the architecture's respective helpers. Framebuffers in system memory should be accessed with the regular load and store operations. Presumably not all

[PATCH 29/32] fbdev: Push pgprot_decrypted() into mmap implementations

If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically calls pgprot_decrypted(). But the default fb_mmap code doesn't handle pgprot_decrypted(). Move the call to pgprot_decrypted() into each drivers' fb_mmap function. This only concerns fb_mmap functions for system and DMA memory. Fo

[PATCH 21/32] fbdev/clps711x-fb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in I/O address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. The driver previously selected drawing

[PATCH 09/32] auxdisplay/ht16k33: Set FBINFO_VIRTFB flag

The ht16k33 driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Miguel Ojeda Cc: Robin van der Gracht --- drivers/auxdisplay/ht16k33.c | 1 + 1 file changed

[PATCH 23/32] fbdev/wm8505fb: Initialize fb_ops to fbdev I/O-memory helpers

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in DMA-able address space. This explictily sets the read/write, draw and mmap callbacks to the correct default implementation. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the c

[PATCH 19/32] fbdev/ps3fb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the

[PATCH 05/32] fbdev/arcfb: Set FBINFO_VIRTFB flag

The arcfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Jaya Kumar --- drivers/video/fbdev/arcfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/

[PATCH 12/32] fbdev/sh_mobile_lcdcfb: Set FBINFO_VIRTFB flag

The sh_mobile_lcdcfb driver operates on DMA-able system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/sh_mobile_lcdcfb.c | 2 ++ 1 file changed, 2 insertions(

[PATCH 32/32] fbdev: Remove default file-I/O implementations

Drop the default implementations for file read, write and mmap operations. Each fbdev driver must now provide an implementation and select any necessary helpers. If no implementation has been set, fbdev returns an errno code to user space. The code is the same as if the operation had not been set i

[PATCH 22/32] fbdev/vt8500lcdfb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in DMA-able virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes re

[PATCH 03/32] fbdev/vfb: Set FBINFO_VIRTFB flag

The vfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/vfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/

[PATCH] drm/test: rearrange test entries in Kconfig and Makefile

Rearrange entries in Kconfig and Makefile alphabetically to make room for additional KUnit test suites. Signed-off-by: Marco Pagani --- drivers/gpu/drm/Kconfig| 10 +- drivers/gpu/drm/tests/Makefile | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers

Re: [PATCH v3 5/7] PCI: ACPI: Detect PCIe root ports that are used for tunneling

Hi Mario, On Tue, Nov 14, 2023 at 02:07:53PM -0600, Mario Limonciello wrote: > USB4 routers support a feature called "PCIe tunneling". This > allows PCIe traffic to be transmitted over USB4 fabric. > > PCIe root ports that are used in this fashion can be discovered > by device specific data that

[PATCH] drm/i915/gsc: Mark internal GSC engine with reserved uabi class

From: Tvrtko Ursulin The GSC CS is not exposed to the user, so we skipped assigning a uabi class number for it. However, the trace logs use the uabi class and instance to identify the engine, so leaving uabi class unset makes the GSC CS show up as the RCS in those logs. Given that the engine is

[PATCH] accel/ivpu/37xx: Fix hangs related to MMIO reset

There is no need to call MMIO reset using VPU_37XX_BUTTRESS_VPU_IP_RESET register. IP will be reset by FLR or by entering d0i3. Also IP reset during power_up is not needed as the VPU is already in reset. Removing MMIO reset improves stability as it a partial device reset that is not safe in some c

Re: (subset) [PATCH] drm/test: rearrange test entries in Kconfig and Makefile

On Wed, 15 Nov 2023 11:35:36 +0100, Marco Pagani wrote: > Rearrange entries in Kconfig and Makefile alphabetically to make room > for additional KUnit test suites. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

[PATCH v1 2/3] dt-bindings: display: bridge: lt8912b: Add power supplies

From: Stefan Eichenberger Add Lontium lt8912b power supplies. Signed-off-by: Stefan Eichenberger Signed-off-by: Francesco Dolcini --- .../display/bridge/lontium,lt8912b.yaml | 21 +++ 1 file changed, 21 insertions(+) diff --git a/Documentation/devicetree/bindings/displ

[PATCH v1 0/3] drm/bridge: lt8912b: Add power supplies

From: Francesco Dolcini Add support for suspend and resume, power off the bridge when going into suspend and power on when resuming. Stefan Eichenberger (3): drm/bridge: lt8912b: Add suspend/resume support dt-bindings: display: bridge: lt8912b: Add power supplies drm/bridge: lt8912b: Add p

[PATCH v1 1/3] drm/bridge: lt8912b: Add suspend/resume support

From: Stefan Eichenberger Add support for suspend and resume. The lt8912b will power off when going into suspend and power on when resuming. Signed-off-by: Stefan Eichenberger Signed-off-by: Francesco Dolcini --- drivers/gpu/drm/bridge/lontium-lt8912b.c | 28 1 file c

[PATCH v1 3/3] drm/bridge: lt8912b: Add power supplies

From: Stefan Eichenberger Add supplies to the driver that can be used to turn the Lontium lt8912b on and off. It can have up to 7 independent supplies, we add them all and enable/disable them with bulk_enable/disable. Signed-off-by: Stefan Eichenberger Signed-off-by: Francesco Dolcini --- dri

Re: [RFC PATCH v2] drm/test: add a test suite for GEM objects backed by shmem

Hi, On Tue, Nov 14, 2023 at 05:18:08PM +0100, Marco Pagani wrote: > On 2023-11-10 15:41, Maxime Ripard wrote: > > On Wed, Nov 08, 2023 at 02:42:03PM +0100, Marco Pagani wrote: > >> This patch introduces an initial KUnit test suite for GEM objects > >> backed by shmem buffers. > >> > >> Suggested-b

RE: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support

Hi Jacopo Mondi, Thanks for the feedback. > Subject: Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support > > Hi Biju > > the series does not apply on v6.3. What is the base for the series ? > > On Thu, Nov 02, 2023 at 03:07:43PM +, Biju Das wrote: > > The LCD controller is composed o

[PATCH v4] Documentation/gpu: VM_BIND locking document

Add the first version of the VM_BIND locking document which is intended to be part of the xe driver upstreaming agreement. The document describes and discuss the locking used during exec- functions, evicton and for userptr gpu-vmas. Intention is to be using the same nomenclature as the drm-vm-bind

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

Hi Sui, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.7-rc1 next-20231115] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to

Re: [PATCH v6 1/7] drm/client: Do not acquire module reference

Am 02.11.23 um 14:08 schrieb Thomas Zimmermann: Do not acquire a reference on the module that provides a client's callback functions in drm_client_init(). The additional reference prevents the user from unloading the callback functions' module and thus creating dangling pointers. This is only

[PATCH v2 0/5] drm: Allow the damage helpers to handle buffer damage

Hello, This series is to fix an issue that surfaced after damage clipping was enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the primary plane"). After that change, flickering artifacts was reported to be present with both weston and wlroots wa

[PATCH v2 4/5] drm/plane: Extend damage tracking kernel-doc

The "Damage Tracking Properties" section in the documentation doesn't have info about the two type of damage handling: frame damage vs buffer damage. Add it to the section and mention that helpers only support frame damage, and how drivers handling buffer damage can indicate that the damage clips

[PATCH v2 2/5] drm/virtio: Disable damage clipping if FB changed since last page-flip

The driver does per-buffer uploads and needs to force a full plane update if the plane's attached framebuffer has change since the last page-flip. Fixes: 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the primary plane") Cc: # v6.4+ Reported-by: nerdopolis Closes: https://bugzil

[PATCH v2 3/5] drm/vmwgfx: Disable damage clipping if FB changed since last page-flip

The driver does per-buffer uploads and needs to force a full plane update if the plane's attached framebuffer has change since the last page-flip. Suggested-by: Sima Vetter Signed-off-by: Javier Martinez Canillas --- Changes in v2: - Set struct drm_plane_state .ignore_damage_clips in vmwgfx pla

[PATCH v2 5/5] drm/todo: Add entry about implementing buffer age for damage tracking

Currently, only damage tracking for frame damage is supported. If a driver needs to do buffer damage (e.g: the framebuffer attached to plane's state has changed since the last page-flip), the damage helpers just fallback to a full plane update. Add en entry in the TODO about implementing buffer ag

[PATCH v2 1/5] drm: Allow drivers to indicate the damage helpers to ignore damage clips

It allows drivers to set a struct drm_plane_state .ignore_damage_clips in their plane's .atomic_check callback, as an indication to damage helpers such as drm_atomic_helper_damage_iter_init() that the damage clips should be ignored. To be used by drivers that do per-buffer (e.g: virtio-gpu) upload

RE: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support

Hi Jacopo Mondi, > -Original Message- > From: Jacopo Mondi > Subject: Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support > > Hi Biju > > the series does not apply on v6.3. What is the base for the series ? This patch series is based on drm-misc. I will add base-commit id on next

Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support

Hi Biju On Wed, Nov 15, 2023 at 12:36:55PM +, Biju Das wrote: > Hi Jacopo Mondi, > > Thanks for the feedback. > > > Subject: Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support > > > > Hi Biju > > > > the series does not apply on v6.3. What is the base for the series ? > > > > On Thu, No

Re: [PATCH v2 3/6] drm/fourcc: Add drm/vs tiled modifiers

ok， I will do this in my next patch Thanks your advice! On 2023/10/25 23:44, Simon Ser wrote: > it seems like you could start with just simple > enumerated modifiers like Intel does, and then only switch to more > complicated logic with macros and fields if there is an actual need in > the future

Re: [PATCH] drm/doc/rfc: SR-IOV support on the new Xe driver

Hi Michal, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc1 next-20231115

[PATCH v2] Remove custom dumb_map_offset implementation in msm driver

Make msm use drm_gem_create_map_offset() instead of its custom implementation for associating GEM object with a fake offset. Since, we already have this generic implementation, we don't need the custom implementation and it is better to standardize the code for GEM based drivers. This also removes

[PATCH] nouveau: don't fail driver load if no display hw present.

From: Dave Airlie If we get back ENODEV don't fail load. There are nvidia devices that don't have display blocks and the driver should work on those. Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM") Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/270 Signed-off-by

Re: [PATCH v1 2/3] dt-bindings: display: bridge: lt8912b: Add power supplies

On Wed, Nov 15, 2023 at 01:13:37PM +0100, Francesco Dolcini wrote: > From: Stefan Eichenberger > > Add Lontium lt8912b power supplies. > > Signed-off-by: Stefan Eichenberger > Signed-off-by: Francesco Dolcini Acked-by: Conor Dooley Cheers, Conor, > --- > .../display/bridge/lontium,lt8912b

Re: [Nouveau] [PATCH] nouveau: don't fail driver load if no display hw present.

On Wed, 15 Nov 2023 at 05:54, Danilo Krummrich wrote: > > On 11/5/23 21:37, Dave Airlie wrote: > > From: Dave Airlie > > > > If we get back ENODEV don't fail load. > > Maybe worth to note why this is OK in this case, might not be obvious > to future readers of the code. Sent an updated version w

dri-devel@lists.freedesktop.org

On 2023/10/25 21:57, Maxime Ripard wrote: > On Wed, Oct 25, 2023 at 06:39:56PM +0800, Keith Zhao wrote: >> +static struct drm_crtc_state * >> +vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc) >> +{ >> +struct vs_crtc_state *ori_state; >> +struct vs_crtc_state *state; >> + >> +if

Re: [PATCH v2] Remove custom dumb_map_offset implementation in msm driver

On Wed, 15 Nov 2023 at 16:30, Dipam Turkar wrote: > > Make msm use drm_gem_create_map_offset() instead of its custom > implementation for associating GEM object with a fake offset. Since, > we already have this generic implementation, we don't need the custom > implementation and it is better to s

[PATCH] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()

The rcar_du_vsps_init() doesn't free the np allocated by of_parse_phandle_with_fixed_args() for the non-error case. Fix memory leak for the non-error case. Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same VSP") Signed-off-by: Biju Das --- drivers/gpu/drm/renesas/rcar-d

Re: [PATCH v4] Documentation/gpu: VM_BIND locking document

On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote: > Add the first version of the VM_BIND locking document which is > intended to be part of the xe driver upstreaming agreement. > > The document describes and discuss the locking used during exec- > functions, evicton and for userptr

Re: [PATCH 1/3] kunit: Add a macro to wrap a deferred action function

Hi David, On Sat, Nov 11, 2023 at 04:08:26AM +0800, David Gow wrote: > KUnit's deferred action API accepts a void(*)(void *) function pointer > which is called when the test is exited. However, we very frequently > want to use existing functions which accept a single pointer, but which > may not b

[PATCH 1/4] drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5

From: Chris Morgan The comments at the top of the driver state the panel size incorrectly as 5.5" instead of 3.5". Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-elida-

[PATCH 0/4] Elida KD35T133 Panel Improvements

From: Chris Morgan Fix a few bugs and clean up no longer needed code on the Elida KD35T133 DSI panel, as used in devices such as the Odroid Go Advance and the Anbernic RG351M. Chris Morgan (4): drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5 drm/panel-elida-kd35t133: hold

[PATCH 3/4] drm/panel-elida-kd35t133: drop drm_connector_set_orientation_from_panel

From: Chris Morgan Stop calling drm_connector_set_orientation_from_panel() as its now called by the panel bridge directly when it is initialized. Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 2/4] drm/panel-elida-kd35t133: hold panel in reset for unprepare

From: Chris Morgan For devices like the Anbernic RG351M and RG351P the panel is wired to an always on regulator. When the device suspends and wakes up, there are some slight artifacts on the screen that go away over time. If instead we hold the panel in reset status after it is unprepared, this d

[PATCH 4/4] drm/panel-elida-kd35t133: Drop prepare/unprepare logic

From: Chris Morgan Drop the prepare/unprepare logic, as this is now tracked elsewhere. Additionally, the driver shutdown is also duplicate as it calls drm_unprepare and drm_disable which are called anyway when associated drivers are shutdown/removed. Signed-off-by: Chris Morgan --- drivers/gpu

[PATCH v6 1/2] dt-bindings: backlight: mp3309c: remove two required properties

The two properties: - max-brightness - default brightness are not really required, so they can be removed from the "required" section. The "max-brightness" is no longer used in the current version of the driver (it was used only in the first version). The "default-brightness", if omitted in the D

[PATCH v6 0/2] backlight: mp3309c: Add support for MPS MP3309C

This patchset (rebased on v6.7-rc1 kernel version): - updates the mps,mp3309c.yaml dt bindings file: - Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml - adds the related device driver to support the MPS MP3309C backlight chip. Note: about the first point, the mps,mp3309c.ya

[PATCH v6 2/2] backlight: mp3309c: Add support for MPS MP3309C

The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a programmable switching frequency to optimize efficiency. The brightness can be controlled either by I2C commands (called "analog" mode) or by a PWM input signal (PWM mode). This driver supports both modes. For DT configura

Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go

Resending from the email address linked to my GitHub account. -- >8 -- The Legion Go has a 2560x1600 portrait screen, with the native "up" facing = the right controller (90=C2=B0 CW from the rest of the device). Signed-off-by: Brenton Simpson --- drivers/gpu/drm/drm_panel_orientation_quirks.c

Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go

Arg - the special characters got mangled. One last time. -- >8 -- The Legion Go has a 2560x1600 portrait screen, with the native "up" facing the right controller (90° CW from the rest of the device). Signed-off-by: Brenton Simpson --- drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++

Re: [PATCH 2/3] drm/tests: Use KUNIT_DEFINE_ACTION_WRAPPER()

Hi David, On Sat, Nov 11, 2023 at 04:08:27AM +0800, David Gow wrote: > In order to pass functions to kunit_add_action(), they need to be of the > kunit_action_t type. While casting the function pointer can work, it > will break control-flow integrity. > > drm_kunit_helpers already defines wrapper

Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go

Hi, On 11/15/23 16:48, Brenton Simpson wrote: > Resending from the email address linked to my GitHub account. Ok, this doesn't really help. I'll just fix-up the author field of the original patch. Do understand correctly that both the author and the Signed-off-by should be set to: Brenton Simps

Re: [PATCH 1/3] kunit: Add a macro to wrap a deferred action function

On Sat, 11 Nov 2023 04:08:26 +0800, David Gow wrote: > KUnit's deferred action API accepts a void(*)(void *) function pointer > which is called when the test is exited. However, we very frequently > want to use existing functions which accept a single pointer, but which > may not be of type void*.

Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go

Yes, thanks! That's the email attached to my public git work, so it should be the one here as well. Sorry for the hassle. Very new to sending PRs over email, and still working through the kinks. On Wed, Nov 15, 2023 at 7:51 AM Hans de Goede wrote: > > Hi, > > On 11/15/23 16:48, Brenton Simpson

dri-devel@lists.freedesktop.org

On Wed, 15 Nov 2023 at 15:30, Keith Zhao wrote: > > > > On 2023/11/14 18:59, Dmitry Baryshkov wrote: > > On Tue, 14 Nov 2023 at 12:42, Keith Zhao > > wrote: > >> > >> > >> > >> On 2023/10/26 3:28, Dmitry Baryshkov wrote: > >> > On 25/10/2023 13:39, Keith Zhao wrote: > >> >> add 2 crtcs and 8 pla

Re: [PATCH 1/3] kunit: Add a macro to wrap a deferred action function

On Wed, 15 Nov 2023 at 16:51, Maxime Ripard wrote: > > On Sat, 11 Nov 2023 04:08:26 +0800, David Gow wrote: > > KUnit's deferred action API accepts a void(*)(void *) function pointer > > which is called when the test is exited. However, we very frequently > > want to use existing functions which a

Re: [PATCH v4] Documentation/gpu: VM_BIND locking document

Hi, Danilo, On Wed, 2023-11-15 at 16:11 +0100, Danilo Krummrich wrote: > On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote: > > Add the first version of the VM_BIND locking document which is > > intended to be part of the xe driver upstreaming agreement. > > > > The document descri

Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go

Hi Brenton, On 11/15/23 16:52, Brenton Simpson wrote: > Yes, thanks! > > That's the email attached to my public git work, so it should be the > one here as well. Ok, I've pushed this to drm-misc-fixes now, thank you for the patch. > Sorry for the hassle. Very new to sending PRs over email, and

[PATCH 01/10] accel/habanalabs/gaudi2: assume hard-reset by FW upon PCIe AXI drain

From: Tomer Tayar When a PCIe AXI drain event happens, it is possible that the driver cannot access the device through PCIe, and therefore cannot send a hard-reset request to FW. Starting from FW version 1.13, FW will initiate a hard-reset in such a case without waiting for a reset request from t

[PATCH 02/10] accel/habanalabs: add log when eq event is not received

From: Farah Kassabri Add error log when no eq event is received from FW, to cover a scenario when FW is stuck for some reason. In such case driver will not receive neither the eq error interrupt or the eq heartbeat event, and will just initiate a reset without indication in the dmesg about the re

[PATCH 03/10] accel/habanalabs: add support for Gaudi2C device

Gaudi2 with PCI revision ID with the value of '3' represents Gaudi2C device and should be detected and initialized as Gaudi2. Signed-off-by: Oded Gabbay --- drivers/accel/habanalabs/common/device.c | 3 +++ drivers/accel/habanalabs/common/habanalabs.h | 2 ++ drivers/

  1   2   >