Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu, Jul 3, 2025 at 2:55 PM Tamir Duberstein wrote: > > On Thu, Jul 3, 2025 at 11:08 AM Benno Lossin wrote: > > > > On Thu Jul 3, 2025 at 3:55 PM CEST, Tamir Duberstein wrote: > > > On Thu, Jul 3, 2025 at 5:32 AM Benno Lossin wrote: > > >> On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Duberstein

[PATCH v6 02/10] mei: late_bind: add late binding component driver

From: Alexander Usyskin Add late binding component driver. It allows pushing the late binding configuration from, for example, the Xe graphics driver to the Intel discrete graphics card's CSE device. Signed-off-by: Alexander Usyskin Signed-off-by: Badal Nilawar Reviewed-by: Anshuman Gupta ---

[PATCH v6 03/10] drm/xe/xe_late_bind_fw: Introducing xe_late_bind_fw

Introducing xe_late_bind_fw to enable firmware loading for the devices, such as the fan controller, during the driver probe. Typically, firmware for such devices are part of IFWI flash image but can be replaced at probe after OEM tuning. This patch binds mei late binding component to enable firmwar

[PATCH v6 00/10] Introducing firmware late binding

Introducing firmware late binding feature to enable firmware loading for the devices, such as the fan controller and voltage regulator, during the driver probe. Typically, firmware for these devices are part of IFWI flash image but can be replaced at probe after OEM tuning. v2: - Dropped voltage

[PATCH v6 01/10] mei: bus: add mei_cldev_mtu interface

From: Alexander Usyskin Allow to bus client to obtain client mtu. Signed-off-by: Alexander Usyskin Signed-off-by: Badal Nilawar Reviewed-by: Umesh Nerlige Ramappa --- drivers/misc/mei/bus.c | 13 + include/linux/mei_cl_bus.h | 1 + 2 files changed, 14 insertions(+) diff --g

[PATCH v6 06/10] drm/xe/xe_late_bind_fw: Reload late binding fw in rpm resume

Reload late binding fw during runtime resume. Signed-off-by: Badal Nilawar Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/xe/xe_late_bind_fw.c | 2 +- drivers/gpu/drm/xe/xe_late_bind_fw.h | 1 + drivers/gpu/drm/xe/xe_pm.c | 4 3 files changed, 6 insertions(+), 1 deletion(-) diff

[PATCH v6 09/10] drm/xe/xe_late_bind_fw: Extract and print version info

Extract and print version info of the late binding binary. v2: Some refinements (Daniele) Signed-off-by: Badal Nilawar Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/xe/xe_late_bind_fw.c | 124 + drivers/gpu/drm/xe/xe_late_bind_fw_types.h | 3 + drivers/gpu

[PATCH v6 04/10] drm/xe/xe_late_bind_fw: Initialize late binding firmware

Search for late binding firmware binaries and populate the meta data of firmware structures. v2 (Daniele): - drm_err if firmware size is more than max pay load size - s/request_firmware/firmware_request_nowarn/ as firmware will not be available for all possible cards v3 (Daniele): - init fir

[PATCH v6 05/10] drm/xe/xe_late_bind_fw: Load late binding firmware

Load late binding firmware v2: - s/EAGAIN/EBUSY/ - Flush worker in suspend and driver unload (Daniele) v3: - Use retry interval of 6s, in steps of 200ms, to allow other OS components release MEI CL handle (Sasha) v4: - return -ENODEV if component not added (Daniele) - parse and print statu

[PATCH v6 07/10] drm/xe/xe_late_bind_fw: Reload late binding fw during system resume

Reload late binding fw during resume from system suspend v2: - Unconditionally reload late binding fw (Rodrigo) - Flush worker during system suspend Cc: Rodrigo Vivi Signed-off-by: Badal Nilawar Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/xe/xe_pm.c | 4 1 file changed, 4 insertion

[PATCH v6 10/10] drm/xe/xe_late_bind_fw: Select INTEL_MEI_LATE_BIND for CI

Do not review Signed-off-by: Badal Nilawar --- drivers/gpu/drm/xe/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig index f66e6d39e319..ef3f4807b0b3 100644 --- a/drivers/gpu/drm/xe/Kconfig +++ b/drivers/gpu/drm/xe/Kconfig @@ -45,6

[PATCH v6 08/10] drm/xe/xe_late_bind_fw: Introduce debug fs node to disable late binding

Introduce a debug filesystem node to disable late binding fw reload during the system or runtime resume. This is intended for situations where the late binding fw needs to be loaded from user mode, perticularly for validation purpose. Note that xe kmd doesn't participate in late binding flow from u

Re: [PATCH v2] agp/amd64: Check AGP Capability before binding to unsupported devices

I suspect these days it would be also reasonable to drop it this old hack. If any of these old chipsets are still missing I would rather adds its PCI-ID. There will be certainly not any new unknown ones for these old CPUs. Also there shouldn't be that many high speed devices that need the old

Re: [RFC 00/12] io_uring dmabuf read/write support

On 03.07.25 16:23, Christoph Hellwig wrote: > [Note: it would be really useful to Cc all relevant maintainers] > > On Fri, Jun 27, 2025 at 04:10:27PM +0100, Pavel Begunkov wrote: >> This series implements it for read/write io_uring requests. The uAPI >> looks similar to normal registered buffers,

[PATCH resend] drm/i915/bios: Apply vlv_fixup_mipi_sequences() to v2 mipi-sequences too

From: Hans de Goede It turns out that the fixup from vlv_fixup_mipi_sequences() is necessary for some DSI panel's with version 2 mipi-sequences too. Specifically the Acer Iconia One 8 A1-840 (not to be confused with the A1-840FHD which is different) has the following sequences: BDB block 53 (12

[PATCH 6.15 209/263] drm/udl: Unregister device before cleaning up on disconnect

6.15-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Zimmermann commit ff9cb6d2035c586ea7c8f1754d4409eec7a2d26d upstream. Disconnecting a DisplayLink device results in the following kernel error messages [ 93.041748] [drm:udl_urb_compl

[PATCH 6.15 202/263] drm/ast: Fix comment on modeset lock

6.15-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Zimmermann commit 7cce65f3789e04c0f7668a66563e680d81d54493 upstream. The ast driver protects the commit tail against concurrent reads of the display modes by acquiring a lock. The comme

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu Jul 3, 2025 at 3:55 PM CEST, Tamir Duberstein wrote: > On Thu, Jul 3, 2025 at 5:32 AM Benno Lossin wrote: >> On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Duberstein wrote: >> > Introduce a `fmt!` macro which wraps all arguments in >> > `kernel::fmt::Adapter` and a `kernel::fmt::Display` trait.

Re: [PATCH 1/1] drm: Simplify drmm_alloc_ordered_workqueue return

On Thu, Jul 03, 2025 at 10:12:41AM +0200, Louis Chauvet wrote: > > > Le 03/07/2025 à 01:28, Matthew Brost a écrit : > > Rather than returning ERR_PTR or NULL on failure, replace the NULL > > return with ERR_PTR(-ENOMEM). This simplifies error handling at the > > caller. While here, add kernel doc

Re: [PATCH v6 2/2] i2c: i2c-qcom-geni: Add Block event interrupt support

On Thu, 3 Jul 2025 at 15:51, Jyothi Kumar Seerapu wrote: > > > > On 6/19/2025 9:46 PM, Jyothi Kumar Seerapu wrote: > > > > > > On 6/18/2025 1:02 AM, Dmitry Baryshkov wrote: > >> On Tue, 17 Jun 2025 at 17:11, Jyothi Kumar Seerapu > >> wrote: > >>> > >>> > >>> > >>> On 5/30/2025 10:12 PM, Dmitry Ba

Re: [PATCH] drm/msm: Update register xml

On Thu, Jul 03, 2025 at 10:51:19AM -0700, Rob Clark wrote: > Sync register xml from mesa commit eb3e0b7164a3 ("freedreno/a6xx: Split > descriptors out into their own file"). > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/msm/Makefile |5 + > drivers/gpu/drm/msm/adreno/

Re: [PATCH] drm/msm: Use of_reserved_mem_region_to_resource() for "memory-region"

On Thu, Jul 03, 2025 at 01:34:41PM -0500, Rob Herring (Arm) wrote: > Use the newly added of_reserved_mem_region_to_resource() function to > handle "memory-region" properties. > > The original code did not set 'zap_available' to false if > of_address_to_resource() failed which seems like an oversig

Re: [PATCH] misc: fastrpc: Use of_reserved_mem_region_to_resource() for "memory-region"

On Thu, Jul 03, 2025 at 01:34:54PM -0500, Rob Herring (Arm) wrote: > Use the newly added of_reserved_mem_region_to_resource() function to > handle "memory-region" properties. > > The error handling is a bit different. "memory-region" is optional, so > failed lookup is not an error. But then an err

Re: [RFC 4/4] drm: define NVIDIA DRM format modifiers for GB20x

On 7/3/25 16:22, Faith Ekstrand wrote: On Thu, Jul 3, 2025 at 6:34 PM James Jones > wrote: The layout of bits within the individual tiles (referred to as sectors in the DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro) changed for some formats starting in

Re: Warnings in next-20250703 caused by commit 582111e630f5

Hi Am 03.07.25 um 13:59 schrieb Bert Karwatzki: When booting next-20250703 on my Msi Alpha 15 Laptop running debian sid (last updated 20250703) I get a several warnings of the following kind: [8.702999] [ T1628] [ cut here ] [8.703001] [ T1628

Re: drm/bridge: tc358767: convert to devm_drm_bridge_alloc() API

Hello Colin, sorry for the late reply (vacation time). On Wed, 2 Jul 2025 10:41:52 +0100 "Colin King (gmail)" wrote: > Hi, > > I believe there is a regression in linux-next caused by the following > commit: > > commit a59a271769149f0b8258507276f3d2a24370cbdb > Author: Luca Ceresoli > Date:

Re: Warnings in next-20250703 caused by commit 582111e630f5

Hi, before I give up on the issue, could you please test the attached patch? Best regards Thomas Am 03.07.25 um 13:59 schrieb Bert Karwatzki: When booting next-20250703 on my Msi Alpha 15 Laptop running debian sid (last updated 20250703) I get a several warnings of the following kind

Re: [PATCH v3 6/7] Documentation: gpu: nova-core: Document fwsec operation and layout

On 7/2/2025 8:25 PM, Bagas Sanjaya wrote: > On Wed, Jul 02, 2025 at 08:00:43PM +0900, Alexandre Courbot wrote: >> +FWSEC Memory Layout >> +--- >> +The memory layout of the FWSEC image is as follows (this is using an GA-102 >> +Ampere GPU as an example and could vary for future GP

Re: [PATCH v3 4/7] Documentation: gpu: nova-core: Document vbios layout

On 7/2/2025 8:20 PM, Bagas Sanjaya wrote: > On Wed, Jul 02, 2025 at 08:00:41PM +0900, Alexandre Courbot wrote: >> diff --git a/Documentation/gpu/nova/core/vbios.rst >> b/Documentation/gpu/nova/core/vbios.rst >> new file mode 100644 >> index >> ..55d7dd4a

Re: Warnings in next-20250703 caused by commit 582111e630f5

Hi Am 03.07.25 um 15:45 schrieb Christian König: On 03.07.25 15:37, Thomas Zimmermann wrote: Hi Am 03.07.25 um 13:59 schrieb Bert Karwatzki: When booting next-20250703 on my Msi Alpha 15 Laptop running debian sid (last updated 20250703) I get a several warnings of the following kind

Re: [PATCH] drm/bridge: analogix_dp: Use devm_drm_bridge_alloc() API

Hi Maxime, On Tue, 1 Jul 2025 16:27:54 +0200 Maxime Ripard wrote: > On Tue, Jul 01, 2025 at 04:02:19PM +0200, Luca Ceresoli wrote: > > Hello Marek, Maxime, > > > > thanks Marek for spotting the issue and sending a patch! > > > > On Mon, 30 Jun 2025 18:44:24 +0200 > > Maxime Ripard wrote: > >

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu, Jul 3, 2025 at 3:56 PM Tamir Duberstein wrote: > > Can you help me understand why? The changes you ask to be separated > would all be in different files, so why would separate commits make it > easier to review? By the way, if we are talking about splitting, it is easier to land patches t

[PATCH] drm/bridge: tc358767: fix uninitialized variable regression

e(dev->of_node, node) { + of_graph_parse_endpoint(node, &endpoint); if (endpoint.port == 2) { of_property_read_u8_array(node, "toshiba,pre-emphasis", tc->pre_emphasis, --- base-commit: b4cd18f485687a2061ee

[PATCH] fbdev: simplefb: Use of_reserved_mem_region_to_resource() for "memory-region"

Use the newly added of_reserved_mem_region_to_resource() function to handle "memory-region" properties. The error handling is a bit different. "memory-region" is optional, so failed lookup is not an error. But then an error in of_address_to_resource() is treated as an error. However, that distinct

[PATCH] misc: fastrpc: Use of_reserved_mem_region_to_resource() for "memory-region"

Use the newly added of_reserved_mem_region_to_resource() function to handle "memory-region" properties. The error handling is a bit different. "memory-region" is optional, so failed lookup is not an error. But then an error in of_reserved_mem_lookup() is treated as an error. However, that distinct

[PATCH] drm/msm: Use of_reserved_mem_region_to_resource() for "memory-region"

Use the newly added of_reserved_mem_region_to_resource() function to handle "memory-region" properties. The original code did not set 'zap_available' to false if of_address_to_resource() failed which seems like an oversight. Signed-off-by: Rob Herring (Arm) --- drivers/gpu/drm/msm/adreno/adreno

[PATCH] drm/simpledrm: Use of_reserved_mem_region_to_resource() for "memory-region"

Use the newly added of_reserved_mem_region_to_resource() function to handle "memory-region" properties. Signed-off-by: Rob Herring (Arm) --- drivers/gpu/drm/sysfb/simpledrm.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/sysfb/simpledrm.c b

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu, Jul 3, 2025 at 11:08 AM Benno Lossin wrote: > > On Thu Jul 3, 2025 at 3:55 PM CEST, Tamir Duberstein wrote: > > On Thu, Jul 3, 2025 at 5:32 AM Benno Lossin wrote: > >> On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Duberstein wrote: > >> > Introduce a `fmt!` macro which wraps all arguments in

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu, Jul 3, 2025 at 12:26 PM Miguel Ojeda wrote: > > On Thu, Jul 3, 2025 at 3:56 PM Tamir Duberstein wrote: > > > > Can you help me understand why? The changes you ask to be separated > > would all be in different files, so why would separate commits make it > > easier to review? > > By the wa

Re: [PATCH v3 2/3] i2c: stm32f7: unmap DMA mapped buffer

Hi Andi, On 7/2/25 19:08, Andi Shyti wrote: Hi Clement, On Mon, Jun 30, 2025 at 02:55:14PM +0200, Clément Le Goffic wrote: Fix an issue where the mapped DMA buffer was not unmapped. "Fix an issue..." is too generic. Can you be more specific? Where was it mapped? Where was it left unmapped?

Re: [PATCH v3 3/3] i2c: stm32f7: support i2c_*_dma_safe_msg_buf APIs

Hi Andy, On 7/2/25 19:15, Andi Shyti wrote: Hi Clement, On Mon, Jun 30, 2025 at 02:55:15PM +0200, Clément Le Goffic wrote: Use the i2c-core-base APIs to allocate a DMA safe buffer when needed. same here, I don't understand anything... you could have written "do some coding" and it would have

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Duberstein wrote: > Introduce a `fmt!` macro which wraps all arguments in > `kernel::fmt::Adapter` and a `kernel::fmt::Display` trait. This enables > formatting of foreign types (like `core::ffi::CStr`) that do not > implement `core::fmt::Display` due to co

Re: [PATCH 03/10] drm/ast: Move Gen6+ POST code to separate source file

On 02/07/2025 15:12, Thomas Zimmermann wrote: Move POST code for Gen6+ to separate source file and hide it in ast_2500_post(). With P2A configuration, it performs a full board POST; otherwise it enables the transmitter chip. No changes to the overall logic. Thanks, it looks good to me. Reviewe

Re: [PATCH 04/10] drm/ast: Move Gen4+ POST code to separate source file

On 02/07/2025 15:12, Thomas Zimmermann wrote: Move POST code for Gen4+ to separate source file and hide it in ast_2300_post(). With P2A configuration, it performs a full board POST and enables the transmitter chip; otherwise it only enables the transmitter chip. Thanks, it looks good to me. Re

Re: [PATCH 05/10] drm/ast: Move Gen2+ and Gen1 POST code to separate source files

On 02/07/2025 15:12, Thomas Zimmermann wrote: Move POST code for Gen2+ and Gen1 to separate source files and hide it in ast_2100_post() ans ast_2000_post(). With P2A configuration, the POST logic for these chip generations has been mingled in ast_init_dram_reg(). Hence, handle all generations in

Re: [PATCH 06/10] drm/ast: Move struct ast_dramstruct to ast_post.h

On 02/07/2025 15:12, Thomas Zimmermann wrote: Declare struct ast_dramstruct in ast_post.h and remove its original header file. Thanks, it looks good to me. Reviewed-by: Jocelyn Falempe Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_2000.c| 2 +- drivers/gpu/drm/a

Re: [PATCH 07/10] drm/ast: Handle known struct ast_dramstruct with helpers

On 02/07/2025 15:12, Thomas Zimmermann wrote: Most of struct ast_dramstruct stores hardware state. Some index values have known or special meaning. The known values are - 0x - Terminal entry in the array - 0xff00 - Delays the programming for usecs - 0x0004 - Sets the type of DRAM Add consta

Re: [PATCH 08/10] drm/ast: Split ast_set_def_ext_reg() by chip generation

On 02/07/2025 15:12, Thomas Zimmermann wrote: Duplicate ast_set_def_ext_reg() for individual chip generations and move call it into per-chip source files. Remove the original code. AST2100 and AST2500 reuse the function from earlier chips. AST2600 appears to be incorrect as it uses an older funct

Re: [PATCH 09/10] drm/ast: Gen7: Disable VGASR0[1] as on Gen4+

On 02/07/2025 15:12, Thomas Zimmermann wrote: Set VGACRB6[5], which disables asynchronous sequencer resets via VGASR0[1]. This was most likely an oversight when adding support for Gen7. Aligns Gen7 with the earlier Gen4+. Thanks, it looks good to me. Reviewed-by: Jocelyn Falempe Signed-off

Re: [PATCH 10/10] drm/ast: Gen7: Switch default registers to gen4+ state

On 02/07/2025 15:12, Thomas Zimmermann wrote: Change the default register settings for Gen7 to mach Gen4 and later. Gen7 currently uses the settings for Gen1, which is most likely incorrect. Using Gen4+ settings enables E2M linear-access modes in VGACRA2. It appears to be related to the chip's P

[PATCH v2 3/7] drm/gpuvm: Pass map arguments through a struct

From: Boris Brezillon We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](), so, before we do that, let's pass arguments through a struct instead of changing each call site every time a new optional argument is added. Signed-off-by: Boris Brezillon Signed-off-by: Caterina Shabl

[PATCH v2 4/7] drm/gpuvm: Add a helper to check if two VA can be merged

From: Boris Brezillon We are going to add flags/properties that will impact the VA merging ability. Instead of sprinkling tests all over the place in __drm_gpuvm_sm_map(), let's add a helper aggregating all these checks can call it for every existing VA we walk through in the __drm_gpuvm_sm_map()

[PATCH v2 1/7] drm/panthor: Add support for atomic page table updates

From: Boris Brezillon Move the lock/flush_mem operations around the gpuvm_sm_map() calls so we can implement true atomic page updates, where any access in the locked range done by the GPU has to wait for the page table updates to land before proceeding. This is needed for vkQueueBindSparse(), so

[PATCH v2 2/7] drm/gpuvm: Kill drm_gpuva_init()

From: Boris Brezillon drm_gpuva_init() only has one internal user, and given we are about to add new optional fields, it only add maintenance burden for no real benefit, so let's kill the thing now. Signed-off-by: Boris Brezillon Signed-off-by: Caterina Shablia --- include/drm/drm_gpuvm.h | 1

[PATCH v2 6/7] drm/gpuvm: Add DRM_GPUVA_REPEAT flag and logic

From: Asahi Lina To be able to support "fake sparse" mappings without relying on GPU page fault handling, drivers may need to create large (e.g. 4GiB) mappings of the same page repeatedly (or same range of pages). Doing this through individual mappings would be very wasteful. This can be handled

[PATCH v2 5/7] drm/gpuvm: Add a flags field to drm_gpuvm_map_req/drm_gpuva_op_map

From: Asahi Lina drm_gpuva objects have a flags field. Currently, this can be managed by drivers out-of-band, without any special handling in drm_gpuvm. To be able to introduce flags that do affect the logic in the drm_gpuvm core, we need to plumb it through the map calls. This will allow the co

[PATCH v2 7/7] drm/panthor: Add support for repeated mappings

From: Boris Brezillon This allows us to optimize mapping of a relatively small portion of a BO over and over in a large VA range, which is useful to support Vulkan sparse bindings in an efficient way. Signed-off-by: Boris Brezillon Co-developed-by: Caterina Shablia Signed-off-by: Caterina Shab

Re: [PATCH v5 10/10] drm/xe/xe_late_bind_fw: Select INTEL_MEI_LATE_BIND for CI

On 7/2/2025 2:48 PM, Rodrigo Vivi wrote: On Wed, Jul 02, 2025 at 10:22:16PM +0530, Badal Nilawar wrote: Do not review Why? Why don't we add this dependency here? For INTEL_MEI_LATE_BIND to work we also need  INTEL_MEI_GSC, which is the config for the mei child device and depends on the c

Re: Warnings in next-20250703 caused by commit 582111e630f5

utions Germany GmbH > Frankenstrasse 146, 90461 Nuernberg, Germany > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > HRB 36809 (AG Nuernberg) I applied the patch on top of next-20250703 $ git log --oneline 18ee3ed3cb60 (HEAD -> drm_gem_object_handle_put) drm/amdg

Re: [PATCH] drm/display: hdmi-cec-helper: Fix adapter unregistration

On Thu, Jul 03, 2025 at 11:05:45PM +0300, Cristian Ciocaltea wrote: > Attempting to reload a kernel module of an HDMI driver making use of the > new CEC helpers revealed a resource deallocation issue, i.e. the entries > in /dev/cec* keep growing. > > Moreover, after a couple of tries the kernel cr

Re: [PATCH v6 05/10] drm/xe/xe_late_bind_fw: Load late binding firmware

On 7/3/2025 12:31 PM, Badal Nilawar wrote: Load late binding firmware v2: - s/EAGAIN/EBUSY/ - Flush worker in suspend and driver unload (Daniele) v3: - Use retry interval of 6s, in steps of 200ms, to allow other OS components release MEI CL handle (Sasha) v4: - return -ENODEV if c

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu, Jul 3, 2025 at 11:28 PM Andrew Lunn wrote: > > A small patch tends to be more obviously correct than a big patch. The > commit message is more focused and helpful because it refers to a > small chunk of code. Because the commit message is more focused, it > can answer questions reviewers m

Re: [PATCH] nouveau/gsp: add a 50ms delay between fbsr and driver unload rpcs

On 7/3/25 1:27 AM, Dave Airlie wrote: From: Dave Airlie This fixes a bunch of command hangs after runtime suspend/resume. This fixes a regression caused by code movement in the commit below, the commit seems to just change timings enough to cause this to happen now, and adding the sleep seems

Re: [PATCH] nouveau/gsp: add a 50ms delay between fbsr and driver unload rpcs

On Fri, Jul 4, 2025 at 7:46 AM Danilo Krummrich wrote: > > On 7/3/25 1:27 AM, Dave Airlie wrote: > > From: Dave Airlie > > > > This fixes a bunch of command hangs after runtime suspend/resume. > > > > This fixes a regression caused by code movement in the commit below, > > the commit seems to jus

Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property

Hi Thomas, On 3-Jul-25 8:47 AM, Thomas Zimmermann wrote: > Hi > > Am 02.07.25 um 22:43 schrieb Krzysztof Kozlowski: >> On 30/06/2025 10:40, Hans de Goede wrote: No one asks to drop them from the driver. I only want specific front compatible which will list and constrain the properties.

Re: [PATCH v1 1/3] drm/buddy: add a flag to disable trimming of non cleared blocks

On 02.07.25 18:12, Pierre-Eric Pelloux-Prayer wrote: > A vkcts test case is triggering a case where the drm buddy allocator > wastes lots of memory and performs badly: > > dEQP-VK.memory.allocation.basic.size_8KiB.reverse.count_4000 > > For each memory pool type, the test will allocate 4000 8kB

[PATCH] drm/amd/display:fix a Null pointer dereference vulnerability

A null pointer dereference vulnerability exists in the AMD display driver's (DC module) cleanup function dc_destruct(). When display control context (dc->ctx) construction fails (due to memory allocation failure), this pointer remains NULL. During subsequent error handling when dc_destruct() is

Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property

Hi Am 03.07.25 um 10:34 schrieb Hans de Goede: Hi Thomas, On 3-Jul-25 8:47 AM, Thomas Zimmermann wrote: Hi Am 02.07.25 um 22:43 schrieb Krzysztof Kozlowski: On 30/06/2025 10:40, Hans de Goede wrote: No one asks to drop them from the driver. I only want specific front compatible which will l

Re: [PATCH v2] agp/amd64: Check AGP Capability before binding to unsupported devices

Hi Lukas, On 2-Jul-25 5:15 PM, Lukas Wunner wrote: > Since commit 172efbb40333 ("AGP: Try unsupported AGP chipsets on x86-64 > by default"), the AGP driver for AMD Opteron/Athlon64 CPUs has attempted > to bind to any PCI device possessing an AGP Capability. > > Commit 6fd024893911 ("amd64-agp: Pr

Re: [PATCH] drm/gem-shmem: Do not map s/g table by default

Le 30/06/2025 à 16:34, Thomas Zimmermann a écrit : The vast majority of drivers that use GEM-SHMEM helpers do not use an s/g table for imported buffers; specifically all drivers that use DRM_GEM_SHMEM_DRIVER_OPS. Therefore convert the initializer macro to DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT an

Re: Warnings in next-20250703 caused by commit 582111e630f5

Hi Am 03.07.25 um 15:56 schrieb Christian König: On 03.07.25 15:54, Thomas Zimmermann wrote: Hi Am 03.07.25 um 15:45 schrieb Christian König: On 03.07.25 15:37, Thomas Zimmermann wrote: Hi Am 03.07.25 um 13:59 schrieb Bert Karwatzki: When booting next-20250703 on my Msi Alpha 15 Laptop

Re: (subset) [PATCH 01/11] zynqmp: don't bother with debugfs_file_{get,put}() in proxied fops

On Thu, Jul 03, 2025 at 01:37:58PM +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 03, 2025 at 01:23:29AM +0100, Al Viro wrote: > > On Wed, Jul 02, 2025 at 05:19:12PM -0600, Jens Axboe wrote: > > > > > > On Wed, 02 Jul 2025 22:14:08 +0100, Al Viro wrote: > > > > When debugfs file has been created b

[PATCH 6.6 058/139] tty: vt: make init parameter of consw::con_init() a bool

6.6-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Slaby (SUSE) [ Upstream commit dae3e6b6180f1a2394b984c596d39ed2c57d25fe ] The 'init' parameter of consw::con_init() is true for the first call of the hook on a particular console. So make

[PATCH 6.6 059/139] tty: vt: sanitize arguments of consw::con_clear()

6.6-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Slaby (SUSE) [ Upstream commit 559f01a0ee6d924c6fec3eaf6a5b078b15e71070 ] In consw::con_clear(): * Height is always 1, so drop it. * Offsets and width are always unsigned values, so re-typ

[PATCH 6.6 060/139] tty: vt: make consw::con_switch() return a bool

6.6-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Slaby (SUSE) [ Upstream commit 8d5cc8eed738e3202379722295c626cba0849785 ] The non-zero (true) return value from consw::con_switch() means a redraw is needed. So make this return type a boo

[PATCH 6.6 061/139] dummycon: Trigger redraw when switching consoles with deferred takeover

6.6-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Zimmermann [ Upstream commit 03bcbbb3995ba5df43af9aba45334e35f2dfe27b ] Signal vt subsystem to redraw console when switching to dummycon with deferred takeover enabled. Makes the console

[PATCH 5.10] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap

From: Anand K Mistry commit 8244a3bc27b3efd057da154b8d7e414670d5044f upstream. drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will b

[PATCH 6.6 114/139] drm/udl: Unregister device before cleaning up on disconnect

6.6-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Zimmermann commit ff9cb6d2035c586ea7c8f1754d4409eec7a2d26d upstream. Disconnecting a DisplayLink device results in the following kernel error messages [ 93.041748] [drm:udl_urb_comple

Re: [PATCH] drm/amd/display:fix a Null pointer dereference vulnerability

On 2025-07-02 23:39, jackysliu wrote: > A null pointer dereference vulnerability exists in the AMD display driver's > (DC module) cleanup function dc_destruct(). > When display control context (dc->ctx) construction fails > (due to memory allocation failure), this pointer remains NULL. > During

[PATCH 6.6 109/139] drm/ast: Fix comment on modeset lock

6.6-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Zimmermann commit 7cce65f3789e04c0f7668a66563e680d81d54493 upstream. The ast driver protects the commit tail against concurrent reads of the display modes by acquiring a lock. The commen

Re: [RESEND PATCH v2] drm/msm/dsi: Fix 14nm DSI PHY PLL Lock issue

Hi Dmitry, On Sun, Jun 29, 2025 at 4:57 PM Dmitry Baryshkov wrote: > > On Sun, Jun 29, 2025 at 10:50:36AM +0200, Loic Poulain wrote: > > To configure and enable the DSI PHY PLL clocks, the MDSS AHB clock must > > be active for MMIO operations. Typically, this AHB clock is enabled as > > part of t

Re: [PATCH v4 0/5] Improvements to S5 power consumption

On Mon, Jun 16, 2025 at 7:50 PM Mario Limonciello wrote: > > From: Mario Limonciello > > A variety of issues both in function and in power consumption have been > raised as a result of devices not being put into a low power state when > the system is powered off. > > There have been some localize

Re: Warnings in next-20250703 caused by commit 582111e630f5

On 03.07.25 15:54, Thomas Zimmermann wrote: > Hi > > Am 03.07.25 um 15:45 schrieb Christian König: >> On 03.07.25 15:37, Thomas Zimmermann wrote: >>> Hi >>> >>> Am 03.07.25 um 13:59 schrieb Bert Karwatzki: >>>> When booting next-20250703 on

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu, Jul 3, 2025 at 5:32 AM Benno Lossin wrote: > > On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Duberstein wrote: > > Introduce a `fmt!` macro which wraps all arguments in > > `kernel::fmt::Adapter` and a `kernel::fmt::Display` trait. This enables > > formatting of foreign types (like `core::ffi:

[PULL] drm-misc-fixes

Hi Dave, Simona, Fixes for rc5. :-) Kind regards, ~Maarten drm-misc-fixes-2025-07-03: drm-misc-fixes for v6.16-rc5: - Replace simple panel lookup hack with proper fix. - nullpointer deref in vesadrm fix. - fix dma_resv_wait_timeout. - fix error handling in ttm_buffer_object_transfer. - bridge fi

[PATCH v2 5/7] drm/gpuvm: Add a flags field to drm_gpuvm_map_req/drm_gpuva_op_map

From: Asahi Lina drm_gpuva objects have a flags field. Currently, this can be managed by drivers out-of-band, without any special handling in drm_gpuvm. To be able to introduce flags that do affect the logic in the drm_gpuvm core, we need to plumb it through the map calls. This will allow the co

[PATCH v2 6/7] drm/gpuvm: Add DRM_GPUVA_REPEAT flag and logic

From: Asahi Lina To be able to support "fake sparse" mappings without relying on GPU page fault handling, drivers may need to create large (e.g. 4GiB) mappings of the same page repeatedly (or same range of pages). Doing this through individual mappings would be very wasteful. This can be handled

[PATCH v2 7/7] drm/panthor: Add support for repeated mappings

From: Boris Brezillon This allows us to optimize mapping of a relatively small portion of a BO over and over in a large VA range, which is useful to support Vulkan sparse bindings in an efficient way. Signed-off-by: Boris Brezillon Co-developed-by: Caterina Shablia Signed-off-by: Caterina Shab

Re: [PATCH 17/17] amdgpu: add support for memory cgroups

> > Do you mean a task in cgroup A does amdgpu_gem_object_create() and then > the actual allocation can happen in the task in cgroup B? On android and in some graphics scenarios, this might happen, not sure if it does always though. We have scenarios where a display server allocate a buffer for an

Re: [PATCH] rust: drm: device: drop_in_place() the drm::Device in release()

On Sun, Jun 29, 2025 at 5:38 PM Danilo Krummrich wrote: > > In drm::Device::new() we allocate with __drm_dev_alloc() and return an > ARef. > > When the reference count of the drm::Device falls to zero, the C code > automatically calls drm_dev_release(), which eventually frees the memory > allocate

Re: [PATCH] drm/nouveau: Do not fail module init on debugfs errors

On Thu, 2025-07-03 at 21:19 +, Aaron Thompson wrote: > From: Aaron Thompson > > If CONFIG_DEBUG_FS is enabled, nouveau_drm_init() returns an error if it > fails to create the "nouveau" directory in debugfs. One case where that > will happen is when debugfs access is restricted by > CONFIG_DEB

Re: [PATCH v3 2/2] drm/bridge: Pass down connector to drm bridge detect hook

On Thu, Jul 03, 2025 at 08:49:53PM +0800, Andy Yan wrote: > From: Andy Yan > > In some application scenarios, we hope to get the corresponding > connector when the bridge's detect hook is invoked. > > In most cases, we can get the connector by > drm_atomic_get_connector_for_encoder > if the enc

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu, Jul 03, 2025 at 02:55:30PM -0400, Tamir Duberstein wrote: > On Thu, Jul 3, 2025 at 11:08 AM Benno Lossin wrote: > > > > On Thu Jul 3, 2025 at 3:55 PM CEST, Tamir Duberstein wrote: > > > On Thu, Jul 3, 2025 at 5:32 AM Benno Lossin wrote: > > >> On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Dub

Re: [PATCH 17/17] amdgpu: add support for memory cgroups

On Thu, Jul 03, 2025 at 08:15:09PM +0200, Christian König wrote: > On 03.07.25 19:58, Shakeel Butt wrote: > > On Thu, Jul 03, 2025 at 12:53:44PM +1000, David Airlie wrote: > >> On Thu, Jul 3, 2025 at 2:03 AM Shakeel Butt wrote: > >>> > >>> On Mon, Jun 30, 2025 at 02:49:36PM +1000, Dave Airlie wrot

[PATCH] drm/display: hdmi-cec-helper: Fix adapter unregistration

ter_adapter(data->adapter); if (data->funcs->uninit) data->funcs->uninit(connector); --- base-commit: 8d6c58332c7a8ba025fcfa76888b6c37dbce9633 change-id: 20250703-hdmi-cec-helper-unreg-fix-d9e71349c1f4

Re: [PATCH v13 2/5] rust: support formatting of foreign types

On Thu Jul 3, 2025 at 8:55 PM CEST, Tamir Duberstein wrote: > On Thu, Jul 3, 2025 at 11:08 AM Benno Lossin wrote: >> On Thu Jul 3, 2025 at 3:55 PM CEST, Tamir Duberstein wrote: >> > On Thu, Jul 3, 2025 at 5:32 AM Benno Lossin wrote: >> >> On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Duberstein wrote

[PATCH v3 7/7] drm/panthor: Add support for repeated mappings

From: Boris Brezillon This allows us to optimize mapping of a relatively small portion of a BO over and over in a large VA range, which is useful to support Vulkan sparse bindings in an efficient way. Signed-off-by: Boris Brezillon Co-developed-by: Caterina Shablia Signed-off-by: Caterina Shab

[PATCH v3 6/7] drm/gpuvm: Add DRM_GPUVA_REPEAT flag and logic

From: Asahi Lina To be able to support "fake sparse" mappings without relying on GPU page fault handling, drivers may need to create large (e.g. 4GiB) mappings of the same page repeatedly (or same range of pages). Doing this through individual mappings would be very wasteful. This can be handled

[PATCH v3 4/7] drm/gpuvm: Add a helper to check if two VA can be merged

From: Boris Brezillon We are going to add flags/properties that will impact the VA merging ability. Instead of sprinkling tests all over the place in __drm_gpuvm_sm_map(), let's add a helper aggregating all these checks can call it for every existing VA we walk through in the __drm_gpuvm_sm_map()

[PATCH v3 5/7] drm/gpuvm: Add a flags field to drm_gpuvm_map_req/drm_gpuva_op_map

From: Asahi Lina drm_gpuva objects have a flags field. Currently, this can be managed by drivers out-of-band, without any special handling in drm_gpuvm. To be able to introduce flags that do affect the logic in the drm_gpuvm core, we need to plumb it through the map calls. This will allow the co

  1   2   >