Re: [PATCH v5 14/14] drm/amd/display: move dc_sink from dc_edid to drm_edid

On 18-07-2025 20:32, Alex Hung wrote: > Melisa, > > The following NULL pointer error was reported from promotion test with this > patch: Hi Alex, Sorry for the delay on addressing it. I just sent a v6. To address this NULL pointer dereference, I use the same sanity check proposed in https://gi

[PATCH v6 14/14] drm/amd/display: move dc_sink from dc_edid to drm_edid

Reduce direct handling of edid data by resorting to drm helpers that deal with this info inside drm_edid infrastructure. v3: - use dc_edid_sink_edid_free in link_detection v5: - no need of drm_edid duplication (Mario) - fix mem leak on dc_sink->drm_edid v6: - fix NULL pointer dereference (Alex H

[PATCH v6 13/14] drm/amd/display: add drm_edid to dc_sink

Add Linux opaque object to dc_sink for storing EDID data cross driver, drm_edid. Also include the Linux call to free this object, the drm_edid_free() Signed-off-by: Melissa Wen --- drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.c | 6 ++ drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.h | 1 +

[PATCH v6 12/14] drm/edid: introduce a helper that compares edid data from two drm_edid

AMD driver has a function used to compare if two edid are the same; this is useful to some of the link detection algorithms implemented by amdgpu. Since the amdgpu function can be helpful for other drivers, this commit abstracts the AMD function to make it available at the DRM level by wrapping exi

[PATCH v6 11/14] drm/amd/display: create a function to fill dc_sink with edid data

From: Rodrigo Siqueira As part of the effort of stopping using raw edid, this commit move the copy of the edid in DC to a dedicated function that will allow the usage of drm_edid in the next steps. Signed-off-by: Rodrigo Siqueira Co-developer-by: Melissa Wen Signed-off-by: Melissa Wen --- dr

[PATCH v6 10/14] drm/amd/display: add a mid-layer file to handle EDID in DC

From: Rodrigo Siqueira Since DC is a shared code, this commit introduces a new file to work as a mid-layer in DC for the edid manipulation. Signed-off-by: Rodrigo Siqueira Co-developed-by: Melissa Wen Signed-off-by: Melissa Wen --- .../gpu/drm/amd/display/amdgpu_dm/Makefile| 1 + .../gp

[PATCH v6 09/14] drm/amd/display: change DC functions to accept private types for edid

There is an opaque obj in Linux/DRM to encapsulate edid data as `drm_edid`. This obj isn't present in other platforms but we need to pass it through DC when adding sink. To pass this data without compromise the independence of DC code, make some DC functions accept edid data as private options. Si

[PATCH v6 08/14] drm/amd/display: simplify dm_helpers_parse_edid_caps signature

Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains edid info. It's a groundwork to get rid of raw edid stored as dc_edid. Signed-off-by: Melissa Wen --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +--- .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 23 --

[PATCH v6 07/14] drm/amd/display: get SADB from drm_eld when parsing EDID caps

drm_edid_connector_update() updates display info, filling ELD with speaker allocation data in the last step of update_dislay_info(). Our goal is stopping using raw edid, so we can extract SADB from drm_eld instead of access raw edid to get audio caps. Reviewed-by: Mario Limonciello Signed-off-by:

[PATCH v6 06/14] drm/amd/display: get SAD from drm_eld when parsing EDID caps

drm_edid_connector_update() updates display info, filling ELD with audio info from Short-Audio Descriptors in the last step of update_dislay_info(). Our goal is stopping using raw edid, so we can extract SAD from drm_eld instead of access raw edid to get audio caps. Reviewed-by: Mario Limonciello

[PATCH v6 05/14] drm/amd/display: get panel id with drm_edid helper

Instead of using driver-specific code, use DRM helpers. Reviewed-by: Mario Limonciello Signed-off-by: Melissa Wen --- .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdg

[PATCH v6 04/14] drm/edid: introduce a helper that gets monitor name from drm_edid

Original drm_edid_get_monitor_name encapsulates raw edid in drm_edid and then call get_monitor_name. AMD still stores the display name for debugging, but it is migrating to drm_edid, on the other hand, drm_dp_mst_topology and sil-sii8620 still use the raw edid version. Split drm_edid_get_monitor_n

[PATCH v6 03/14] drm/amd/display: use drm_edid_product_id for parsing EDID product info

Use drm_edid_product_id [1] to get debug info from drm_edid instead of directly parsing raw EDID. [1] 3ddbd345539e ("drm/edid: add drm_edid_get_product_id()"). Signed-off-by: Melissa Wen -- v5: - replace series url to commit hash (Mario) --- .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c |

[PATCH v6 00/14] drm/amd/display: more drm_edid to AMD display driver

Hi, Siqueira and I have been working on a solution to reduce the usage of drm_edid_raw in the AMD display driver, since the current guideline in the DRM subsystem is to stop handling raw edid data in driver-specific implementation and use opaque `drm_edid` object with common-code helpers. To keep

[PATCH v6 02/14] drm/amd/display: start using drm_edid helpers to parse EDID caps

Groundwork that allocates a temporary drm_edid from raw edid to take advantage of DRM common-code helpers instead of driver-specific code. Signed-off-by: Melissa Wen --- .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c| 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff

[PATCH v6 01/14] drm/amd/display: make sure drm_edid stored in aconnector doesn't leak

Make sure the drm_edid container stored in aconnector is freed when destroying the aconnector. Fixes: 48edb2a4256e ("drm/amd/display: switch amdgpu_dm_connector to use struct drm_edid") Reviewed-by: Mario Limonciello Signed-off-by: Melissa Wen --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_d

dri-devel@lists.freedesktop.org

On Thu, Jul 24, 2025 at 04:02:54PM +0800, Damon Ding wrote: > In order to move the parnel/bridge parsing and attachmenet to the > Analogix side, add component struct drm_bridge *bridge to platform > data struct analogix_dp_plat_data. > > The movemenet makes sense because the panel/bridge should lo

dri-devel@lists.freedesktop.org

On Thu, Jul 24, 2025 at 04:02:55PM +0800, Damon Ding wrote: > Use &analogix_dp_plat_data.bridge instead of &exynos_dp_device.ptn_bridge > directly. > > Signed-off-by: Damon Ding > > -- > > Changes in v3: > - Fix the typographical error for &dp->plat_data.bridge. > --- > drivers/gpu/drm/exy

dri-devel@lists.freedesktop.org

On Thu, Jul 24, 2025 at 04:02:56PM +0800, Damon Ding wrote: > The &exynos_dp_device.connector is assigned in exynos_dp_bridge_attach() > but never used. It should make sense to remove it. > > Signed-off-by: Damon Ding > --- > drivers/gpu/drm/exynos/exynos_dp.c | 3 --- > 1 file changed, 3 deleti

Re: [PATCH v3 07/14] drm/bridge: analogix_dp: Remove redundant &analogix_dp_plat_data.skip_connector

On Thu, Jul 24, 2025 at 04:02:57PM +0800, Damon Ding wrote: > The &analogix_dp_plat_data.skip_connector related check can be replaced > by &analogix_dp_plat_data.bridge. > > Signed-off-by: Damon Ding > > -- > > Changes in v3: > - Squash the Exynos side commit and the Analogix side commit to

Re: [PATCH v3 03/14] drm/rockchip: analogix_dp: Apply drmm_encoder_init() instead of drm_simple_encoder_init()

On Thu, Jul 24, 2025 at 04:02:53PM +0800, Damon Ding wrote: > Compared with drm_simple_encoder_init(), drmm_encoder_init() can handle > the cleanup automatically through registering drm_encoder_cleanup() with > drmm_add_action(). > > Signed-off-by: Damon Ding > --- > drivers/gpu/drm/rockchip/ana

Re: [PATCH v5 10/10] arm64: dts: rockchip: Enable DP2HDMI for ROCK 5 ITX

On Wed, Jul 16, 2025 at 06:04:37PM +0800, Andy Yan wrote: > From: Andy Yan > > The HDMI0(Port next to Headphone Jack) is drived by DP1 on rk3588 > via RA620(a dp2hdmi converter). > > Add related dt nodes to enable it. > > Note: ROCKCHIP_VOP2_EP_DP1 is defined as 11 in dt-binding header, > but i

Re: [PATCH v5 09/10] arm64: dts: rockchip: Enable DisplayPort for rk3588s Cool Pi 4B

On Wed, Jul 16, 2025 at 06:04:36PM +0800, Andy Yan wrote: > From: Andy Yan > > Enable the Mini DisplayPort on this board. > Note that ROCKCHIP_VOP2_EP_DP0 is defined as 10 in dt-binding header, > but it will trigger a dtc warning like "graph node unit address error, > expected "a"" if we use it d

Re: [PATCH v5 02/10] drm/bridge: synopsys: Add DW DPTX Controller support library

On Wed, Jul 16, 2025 at 06:04:29PM +0800, Andy Yan wrote: > From: Andy Yan > > The DW DP TX Controller is compliant with the DisplayPort Specification > Version 1.4 with the following features: > > * DisplayPort 1.4a > * Main Link: 1/2/4 lanes > * Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and

Re: [PATCH 3/9] drm/xe/xe_late_bind_fw: Introducing xe_late_bind_fw

On Thu, Jul 10, 2025 at 11:08:34AM -0400, Rodrigo Vivi wrote: From: Badal Nilawar Introducing xe_late_bind_fw to enable firmware loading for the devices, here and in the subject: no gerund, please. such as the fan controller, during the driver probe. Typically, firmware for such devices are

Re: [PATCH 2/2] drm/panel: novatek-nt35560: Fix bug and clean up

Hi, On Thu, Jul 24, 2025 at 1:23 PM Brigham Campbell wrote: > > Fix bug in nt35560_set_brightness() which causes the function to > erroneously report an error. mipi_dsi_dcs_write() returns either a > negative value when an error occurred or a positive number of bytes > written when no error occu

Re: [PATCH 0/2] drm/panel: novatek-nt35560: Fix bug and clean up

Hi, On Thu, Jul 24, 2025 at 1:23 PM Brigham Campbell wrote: > > This series does the following: > - Add mipi_dsi_dcs_read_multi() to drm_mipi_dsi.c for improved error >handling in drivers which use mipi_dsi_dcs_read() such as the >novatek-nt35560 driver. > - Fix a bug in nt35560_set_br

Re: [PATCH 1/2] drm: Create mipi_dsi_dcs_read_multi()

Hi, On Thu, Jul 24, 2025 at 1:23 PM Brigham Campbell wrote: > > +void mipi_dsi_dcs_read_multi(struct mipi_dsi_multi_context *ctx, u8 cmd, > +void *data, size_t len) > +{ > + struct mipi_dsi_device *dsi = ctx->dsi; > + struct device *dev = &dsi->dev; > +

Re: [PATCH v2 01/19] gpu: nova-core: register: minor grammar and spelling fixes

On 7/25/25 9:14 AM, Daniel Almeida wrote: Hi Alex. Thank you and John for working on this in general. It will be useful for the whole ecosystem! :) On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: From: John Hubbard There is only one top-level macro in this file at the moment, but the "ma

Re: [git pull] drm fixes (part two) for 6.16-rc8/final

The pull request you sent on Sat, 26 Jul 2025 06:32:20 +1000: > https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-07-26 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5f33ebd2018ced2600b3fad2f8e2052498eb4072 Thank you! -- Deet-doot-dot, I am a bot. h

Re: [git pull] drm fixes (part two) for 6.16-rc8/final

On Fri, 25 Jul 2025 at 13:32, Dave Airlie wrote: > > Okay this time hopefully in plain text from the start Apparently your weekend muscle memory theory was indeed correct. Linus

[git pull] drm fixes (part two) for 6.16-rc8/final

Hi Linus, Okay this time hopefully in plain text from the start, just the follow up fixes for i915 and xe, all pretty minor. Thanks, Dave. drm-fixes-2025-07-26: drm fixes (part 2) for 6.16-rc8/final i915: - Fix DP 2.7 Gbps DP_LINK_BW value on g4x - Fix return value on intel_atomic_commit_fence_

Re: [PATCH 12/38] dt-bindings: regulator: mediatek,mt6331: Add missing compatible

On Thu, 24 Jul 2025 10:38:48 +0200, AngeloGioacchino Del Regno wrote: > This binding had no compatible and for this reason would not be > applied to anything: add the missing "mediatek,mt6331-regulator" > comaptible. > > Fixes: 6385e21692bb ("regulator: Add bindings for MT6331 regulator") > Sign

Re: [PATCH 11/38] dt-bindings: regulator: mediatek,mt6331: Fix various regulator names

On Thu, 24 Jul 2025 10:38:47 +0200, AngeloGioacchino Del Regno wrote: > This binding was never applied to anything because it misses the > compatible, hence any mistake in it got unnoticed. > > Before adding the compatible to let it apply, fix the names and > the node names of various regulators

Re: [PATCH 10/38] dt-bindings: regulator: mediatek, mt6332-regulator: Add missing compatible

On Thu, 24 Jul 2025 10:38:46 +0200, AngeloGioacchino Del Regno wrote: > This binding had no compatible and for this reason would not be > applied to anything: add the missing "mediatek,mt6332-regulator" > compatible. > > Fixes: e22943e32e1f regulator: ("Add bindings for MT6332 regulator") > Sign

Re: [PATCH 07/38] dt-bindings: pinctrl: mediatek, mt7622-pinctrl: Add missing pwm_ch7_2

On Thu, 24 Jul 2025 10:38:43 +0200, AngeloGioacchino Del Regno wrote: > The MT7622 SoC has a PWM channel 7-2 group for the pwm7 IP: add > the missing pwm_ch7_2 group. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml| 2 +-

Re: [PATCH 06/38] dt-bindings: timer: mediatek: Add compatible for MT6795 GP Timer

On Thu, 24 Jul 2025 10:38:42 +0200, AngeloGioacchino Del Regno wrote: > Add a compatible for the General Purpose Timer (GPT) found on the > MediaTek Helio X10 MT6795 SoC which is fully compatible with the > one found in MT6577. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documenta

Re: [PATCH 03/38] dt-bindings: mailbox: mediatek,gce-mailbox: Make clock-names optional

On Thu, 24 Jul 2025 10:38:39 +0200, AngeloGioacchino Del Regno wrote: > The GCE Mailbox needs only one clock and the clock-names can be > used only by the driver (which, for instance, does not use it), > and this is true for all of the currently supported MediaTek SoCs. > > Stop requiring to spe

Re: [PATCH 02/38] dt-bindings: display: mediatek,dp: Allow DisplayPort AUX bus

On Thu, 24 Jul 2025 10:38:38 +0200, AngeloGioacchino Del Regno wrote: > Like others, the MediaTek DisplayPort controller provides an > auxiliary bus: import the common dp-aux-bus.yaml in this binding > to allow specifying an aux-bus subnode. > > Signed-off-by: AngeloGioacchino Del Regno > > --

Re: [PATCH 01/38] dt-bindings: display: mediatek: dpi: Allow specifying resets

On Thu, Jul 24, 2025 at 05:16:21PM +0800, Chen-Yu Tsai wrote: > On Thu, Jul 24, 2025 at 4:39 PM AngeloGioacchino Del Regno > wrote: > > > > Even though the DPI IP has a reset bit on all MediaTek SoCs, it > > is optional, and has always been unused until MT8195; specifically: > > on older SoCs, lik

Re: [PATCH 1/4] dt-bindings: backlight: Add max25014 bindings

On Fri, Jul 25, 2025 at 04:06:45PM +0200, Maud Spierings wrote: > > > On 7/25/25 15:27, Rob Herring (Arm) wrote: > > > > On Fri, 25 Jul 2025 13:09:23 +0200, Maud Spierings wrote: > > > The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC > > > with intgrated boost controller. >

Re: [PATCH 02/12] dt-bindings: display: st,stm32-ltdc: add access-controllers property

On Fri, 25 Jul 2025 12:03:54 +0200, Raphael Gallais-Pou wrote: > access-controllers is an optional property that allows a peripheral to > refer to one or more domain access controller(s). > > This property is added when the peripheral is under the STM32 firewall > controller. It allows an accur

Re: [PATCH 01/12] dt-bindings: display: st: add new compatible to LTDC device

On Fri, Jul 25, 2025 at 12:03:53PM +0200, Raphael Gallais-Pou wrote: > The new STMicroelectronics SoC features a display controller similar to > the one used in previous SoCs. Because there is additional registers, > it is incompatible with existing IPs. > > Add the new name to the list of compat

Re: [PATCH v3 00/14] Apply drm_bridge_connector and panel_bridge helper for the Analogix DP driver

Hi Damon, Am Freitag, 25. Juli 2025, 04:15:06 Mitteleuropäische Sommerzeit schrieb Damon Ding: > On 2025/7/24 21:10, Heiko Stübner wrote: > > Am Donnerstag, 24. Juli 2025, 10:02:50 Mitteleuropäische Sommerzeit schrieb > > Damon Ding: > >> PATCH 1 is a small format optimization for struct analogid

Re: [PATCH] Partially revert "rust: drm: gem: Implement AlwaysRefCounted for all gem objects automatically"

a-ha, ok. I made a mistake here with misremembering where the compilation issue I saw here really was. It's not that multiple gem object implementations are triggering it, it's that it immediately breaks compilation if any other type tries to do a blanket implementation with AlwaysRefCounted like

Re: [PATCH v2 17/19] gpu: nova-core: register: add support for register arrays

[…] > > Assuming that the @io_fixed stuff is correct: > > Reviewed-by: Daniel Almeida > > — Daniel For the stuff in macros.rs . I did not check the device-specific part in Nova, as I’m not familiar with how it works. — Daniel

Re: [PATCH v2 17/19] gpu: nova-core: register: add support for register arrays

Hi Alex, > On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > Having registers that can be interpreted identically in a contiguous I/O > area (or at least, following a given stride) is a common way to organize > registers, and is used by NVIDIA hardware. Thus, add a way to simply and > safel

Re: [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function

On 2025-07-25 12:54, Leon Romanovsky wrote: >> The solution that would make more sense to me would be for either >> dma_iova_try_alloc() or another helper in dma-iommu.c to handle the >> P2PDMA case. dma-iommu.c already uses those same interfaces and thus >> there would be no need to export the

Re: [PATCH v2 15/19] gpu: nova-core: register: redesign relative registers

Hi Alex, > On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > The relative registers are currently very unsafe to use: callers can > specify any constant as the base address for access, meaning they can > effectively interpret any I/O address as any relative register. > > Ideally, valid bas

Re: [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function

On Fri, Jul 25, 2025 at 10:30:46AM -0600, Logan Gunthorpe wrote: > > > On 2025-07-24 02:13, Leon Romanovsky wrote: > > On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote: > >> On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote: > >>> From: Leon Romanovsky > >>> > >>>

Re: [PATCH v2 14/19] gpu: nova-core: register: use #[inline(always)] for all methods

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > These methods should always be inlined, so use the strongest compiler > hint that exists to maximize the chance they will indeed be. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/nova-core/regs/macros.rs | 16 ---

Re: [PATCH v2 13/19] gpu: nova-core: register: split @io rule into fixed and relative versions

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > We used the same @io rule with different patterns to define both the > fixed and relative I/O accessors. This can be confusing as the matching > rules are very similar. > > Since all call sites know which version they want to call, spli

Re: [PATCH v2 12/19] gpu: nova-core: register: generate correct `Default` implementation

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > The `Default` implementation of a register should be the aggregate of > the default values of all its fields, and not simply be zeroed. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/nova-core/regs/macros.rs | 26

Re: [PATCH v2 19/19] drm: Make passing of format info to drm_helper_mode_fill_fb_struct() mandatory

On Fri, Jul 25, 2025 at 05:23:36PM +0300, Imre Deak wrote: > On Fri, Jul 25, 2025 at 02:36:31PM +0100, Mark Brown wrote: > > This regression is still present in today's -next, I've not seen any > > response to my report? > Looks like the following would fix it, could you give it a go?: Yes, that

Re: [PATCH v3] Documentation: dma-buf: heaps: Add naming guidelines

On 7/17/25 3:10 AM, Maxime Ripard wrote: We've discussed a number of times of how some heap names are bad, but not really what makes a good heap name. Let's document what we expect the heap names to look like. Reviewed-by: Bagas Sanjaya Signed-off-by: Maxime Ripard --- Changes in v3: - Gramma

Re: [PATCH v2 11/19] gpu: nova-core: register: improve `Debug` implementation

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > Now that we have an internal rule to dispatch field information where > needed, use it to generate a better `Debug` implementation where the raw > hexadecimal value of the register is displayed, as well as the `Debug` > values of its ind

Re: [PATCH v2 10/19] gpu: nova-core: register: add fields dispatcher internal rule

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > Fields are complex and cumbersome to match in a rule, and were only > captured in order to generate the field accessors. However, there are > other places (like the `Debug` and `Default` implementations) where we > would benefit from hav

Re: [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function

On 2025-07-24 02:13, Leon Romanovsky wrote: > On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote: >> On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote: >>> From: Leon Romanovsky >>> >>> Export the pci_p2pdma_map_type() function to allow external modules >>> and subs

Re: [PATCH v2 09/19] gpu: nova-core: register: add missing doccomments for fixed registers I/O accessors

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > Add the missing doccomments for these accessors, as having a bit of > inline documentation is always helpful. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/nova-core/regs/macros.rs | 4 > 1 file changed, 4 insertions(+)

Re: [PATCH v2 08/19] gpu: nova-core: register: fix documentation and indentation

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > Fix a few documentation inconsistencies, and harmonize indentation where > possible. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/nova-core/regs/macros.rs | 34 +- > 1 file changed, 9 insertio

Re: [PATCH v2 07/19] gpu: nova-core: register: move OFFSET declaration to I/O impl block

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > The OFFSET const is an I/O property, and having to pass it to the > @common rule makes it impossible to make I/O optional, as we want to get > to eventually. > > Thus, move OFFSET to the I/O impl block so it is not needed by the > @comm

Re: [PATCH v2 06/19] gpu: nova-core: register: remove `try_` accessors for relative registers

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > Relative registers are always accessed using a literal base, meaning > their validity can always be checked at compile-time. Thus remove the > `try_` accessors that have no purpose. > > Signed-off-by: Alexandre Courbot > --- > drivers/

Re: [PATCH v2 05/19] gpu: nova-core: register: simplify @leaf_accessor rule

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > The `$type` metavariable is not used in the @leaf_accessor rule, so > remove it. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/nova-core/regs/macros.rs | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff

Re: [PATCH v2 04/19] gpu: nova-core: register: improve documentation for basic registers

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > Reword parts of the documentation that were a bit heavy to read, and > harmonize/fix the examples. > > The relative registers section is about to be redesigned and its > documentation rewritten, so do not touch this part. > > Signed-of

Re: [PATCH v2 03/19] gpu: nova-core: register: allow fields named `offset`

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > `offset` is a common field name, yet using it triggers a build error due > to the conflict between the uppercased field constant (which becomes > `OFFSET` in this case) containing the bitrange of the field, and the > `OFFSET` constant co

Re: [PATCH v2 02/19] gpu: nova-core: register: fix typo

> On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > A space was missing between arguments in this invocation. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/nova-core/regs/macros.rs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/nova-core/

Re: [PATCH v2 01/19] gpu: nova-core: register: minor grammar and spelling fixes

Hi Alex. Thank you and John for working on this in general. It will be useful for the whole ecosystem! :) > On 18 Jul 2025, at 04:26, Alexandre Courbot wrote: > > From: John Hubbard > > There is only one top-level macro in this file at the moment, but the > "macros.rs" file name allows for mo

Re: [PATCH v9 00/10] New DRM accel driver for Rockchip's RKNN NPU

On 7/21/2025 3:17 AM, Tomeu Vizoso wrote: This series adds a new driver for the NPU that Rockchip includes in its newer SoCs, developed by them on the NVDLA base. In its current form, it supports the specific NPU in the RK3588 SoC. The userspace driver is part of Mesa and an initial draft can b

Re: [PATCH] MAINTAINERS: Update email address for Carl Vanderlip

On 7/21/2025 4:08 PM, Carl Vanderlip wrote: Qualcomm is changing open source email address policy. LKML and other busy mailing lists use the oss.qualcomm.com domain. Signed-off-by: Carl Vanderlip Applied to drm-misc-next -Jeff

Re: [PATCH 00/32] drm/mipi-dsi: avoid DSI host drivers to have pointers to DSI devices

previous mail, we should probably figure it out, > document it, and then make it work for your drivers. Once we have a > documentation we can point to, the rest will fall in line. Thanks for taking time to reply this! I just sent a patch to do the mentioned change in samsung-dsim [0] to st

[PATCH] samsung-dsim: move drm_bridge_add() call to probe

ridge); + return 0; err_disable_runtime: --- base-commit: e48123c607a0db8b9ad02f83c8c3d39918dbda06 change-id: 20250725-drm-bridge-samsung-dsim-add-in-probe-7c549360af90 Best regards, -- Luca Ceresoli

Re: [PATCH v5 02/10] drm/bridge: synopsys: Add DW DPTX Controller support library

On Wed, Jul 16, 2025 at 06:04:29PM +0800, Andy Yan wrote: > From: Andy Yan > > The DW DP TX Controller is compliant with the DisplayPort Specification > Version 1.4 with the following features: > > * DisplayPort 1.4a > * Main Link: 1/2/4 lanes > * Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and

Re: [PATCH 00/32] drm/mipi-dsi: avoid DSI host drivers to have pointers to DSI devices

On Mon, Jul 07, 2025 at 12:13:19PM +0200, Luca Ceresoli wrote: > Hi Maxime, > > ouch, e-mail sent by mistake unfinished and without proof-reading... > well, let me continue it below. > > On Mon, 7 Jul 2025 11:58:53 +0200 > Luca Ceresoli wrote: > > > On Mon, 7 Jul 2025 08:16:49 +0200 > > Maxime

Re: [PATCH 00/32] drm/mipi-dsi: avoid DSI host drivers to have pointers to DSI devices

Hi Luca, On Mon, Jul 07, 2025 at 11:58:53AM +0200, Luca Ceresoli wrote: > On Mon, 7 Jul 2025 08:16:49 +0200 > Maxime Ripard wrote: > > On Wed, Jun 25, 2025 at 06:45:04PM +0200, Luca Ceresoli wrote: > > > This series is the first attempt at avoiding DSI host drivers to have > > > pointers to DSI d

[PATCH v5 7/7] drm/panthor: Expose the panthor perf ioctls

This patch implements the PANTHOR_PERF_CONTROL ioctl series, and a PANTHOR_GET_UOBJ wrapper to deal with the backwards and forwards compatibility of the uAPI. The minor version is bumped to indicate that the feature is now supported. Signed-off-by: Lukas Zapolskas Reviewed-by: Adrián Larumbe --

[PATCH v5 6/7] drm/panthor: Add suspend, resume and reset handling

The sampler must disable and re-enable counter sampling around suspends, and must re-program the FW interface after a reset to avoid losing data. Signed-off-by: Lukas Zapolskas --- drivers/gpu/drm/panthor/panthor_device.c | 7 +- drivers/gpu/drm/panthor/panthor_perf.c | 89 +++

[PATCH v5 3/7] drm/panthor: Add panthor perf initialization and termination

Added the panthor_perf system initialization and unplug code to allow for the handling of userspace sessions to be added in follow-up patches. Signed-off-by: Lukas Zapolskas --- drivers/gpu/drm/panthor/panthor_device.c | 2 + drivers/gpu/drm/panthor/panthor_device.h | 5 +- drivers/gpu/drm/pan

[PATCH v5 5/7] drm/panthor: Implement the counter sampler and sample handling

From: Adrián Larumbe The sampler aggregates counter and set requests coming from userspace and mediates interactions with the FW interface, to ensure that user sessions cannot override the global configuration. >From the top-level interface, the sampler supports two different types of samples: c

[PATCH v5 4/7] drm/panthor: Introduce sampling sessions to handle userspace clients

To allow for combining the requests from multiple userspace clients, an intermediary layer between the HW/FW interfaces and userspace is created, containing the information for the counter requests and tracking of insert and extract indices. Each session starts inactive and must be explicitly activ

[PATCH v5 1/7] drm/panthor: Add performance counter uAPI

This patch extends the DEV_QUERY ioctl to return information about the performance counter setup for userspace, and introduces the new ioctl DRM_PANTHOR_PERF_CONTROL in order to allow for the sampling of performance counters. The new design is inspired by the perf aux ringbuffer [0], with the inse

[PATCH v5 2/7] drm/panthor: Add DEV_QUERY.PERF_INFO handling for Gx10

This change adds the IOCTL to query data about the performance counter setup. Some of this data was available via previous DEV_QUERY calls, for instance for GPU info, but exposing it via PERF_INFO minimizes the overhead of creating a single session to just the one aggregate IOCTL. Signed-off-by: L

[PATCH v5 0/7] Performance counter implementation with single manual client support

Hello, This patch set implements initial support for performance counter sampling in Panthor, as a follow-up for Adrián Larumbe's patch set [1]. This version of the patch series fixes a number of issues, including FW ring buffer wrapping and IRQ handling for the performance counter IRQs. The size

Re: [Linux-stm32] [PATCH 09/12] arm64: dts: st: add lvds support on stm32mp255

On 7/25/25 13:13, Clement LE GOFFIC wrote: > On 7/25/25 13:08, Clement LE GOFFIC wrote: >> Hi Raphael, >> >> On 7/25/25 12:04, Raphael Gallais-Pou wrote: >>> The LVDS is used on STM32MP2 as a display interface. >>> >>> Add the LVDS node. >>> >>> Signed-off-by: Raphael Gallais-Pou >>> --- >>>  

RE: [PATCH v8 3/3] drm/amdgpu: Allow kfd CRIU with no buffer objects

[AMD Official Use Only - AMD Internal Distribution Only] Acked-by: David Yat Sin > -Original Message- > From: Francis, David > Sent: Friday, July 18, 2025 10:48 AM > To: dri-devel@lists.freedesktop.org > Cc: tvrtko.ursu...@igalia.com; Kuehling, Felix ; Yat > Sin, > David ; Freehill, C

Re: [PATCH v2 19/19] drm: Make passing of format info to drm_helper_mode_fill_fb_struct() mandatory

On Fri, Jul 25, 2025 at 02:36:31PM +0100, Mark Brown wrote: > On Tue, Jul 22, 2025 at 02:41:53PM +0100, Mark Brown wrote: > > On Tue, Jul 01, 2025 at 12:07:22PM +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Now that everyone passes along the format info to > > > drm_helper_mod

Re: [PATCH v8 2/4] dt-bindings: gpu: img,powervr-rogue: Add TH1520 GPU compatible

On 25/07/2025 12:08, Krzysztof Kozlowski wrote: > On 25/07/2025 11:00, Matt Coster wrote: >> On 25/07/2025 07:59, Krzysztof Kozlowski wrote: >>> On Thu, Jul 24, 2025 at 04:18:59PM +0200, Michal Wilczynski wrote: Update the img,powervr-rogue.yaml to include the T-HEAD TH1520 SoC's specific

Re: [PATCH 4/9] drm/omapdrm: use drm_bridge_chain_get_last_bridge()

On Mon, Jul 14, 2025 at 12:32:40PM +0200, Luca Ceresoli wrote: > Hi Maxime, > > On Thu, 10 Jul 2025 09:13:46 +0200 > Maxime Ripard wrote: > > > On Wed, Jul 09, 2025 at 06:48:03PM +0200, Luca Ceresoli wrote: > > > Use drm_bridge_chain_get_last_bridge() instead of open coding a loop with > > > two

Re: [PATCH 1/4] dt-bindings: backlight: Add max25014 bindings

ected) from schema $id: http://devicetree.org/schemas/leds/backlight/maxim,max25014.yaml# Ah oops, leftover from old version, fixed in rv2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250725-max25014-v1-1-0e8cce920...@go

Re: [PATCH] gpu: nova-core: vbios: use offset_of in PmuLookupTableHeader::new

On 7/25/25 3:35 PM, Alexandre Courbot wrote: This chunk does not apply - on nova-next PmuLookupTableHeader does not seem to exist. I think I remember you split PmuLookupTableHeader in another patch, so can you send all the relevant patches as a series that applies cleanly on top of nova-next? I

Re: [PATCH 00/38] MediaTek devicetree/bindings warnings sanitization

On Thu, Jul 24, 2025 at 3:39 AM AngeloGioacchino Del Regno wrote: > > As Rob pointed out, MediaTek devicetrees are *poor* in the dtbs_check > tests, and got an infinite load of warnings. > > This series starts attacking this situation. > > I didn't really count how many warnings I have resolved -

Re: [PATCH] drm: nova-drm: fix 32-bit arm build

Hi Miguel, On 24.07.25 6:54 PM, Miguel Ojeda wrote: > In 32-bit arm, the build fails with: > > error[E0308]: mismatched types > --> drivers/gpu/drm/nova/file.rs:42:28 >| > 42 | getparam.set_value(value); >| - ^ expected `u64`, fou

Re: [PATCH v12 10/12] drm/msm/dpu: support SSPP assignment for quad-pipe case

On Thu, Jul 24, 2025 at 09:56:21AM +0800, Jun Nie wrote: > Dmitry Baryshkov 于2025年7月22日周二 20:04写道： > > > > On Mon, Jul 21, 2025 at 04:06:13PM +0800, Jun Nie wrote: > > > Dmitry Baryshkov 于2025年7月19日周六 > > > 18:09写道： > > > > > > > > On Mon, Jul 07, 2025 at 02:18:05PM +0800, Jun Nie wrote: > > > >

Re: [PATCH v2 19/19] drm: Make passing of format info to drm_helper_mode_fill_fb_struct() mandatory

On Tue, Jul 22, 2025 at 02:41:53PM +0100, Mark Brown wrote: > On Tue, Jul 01, 2025 at 12:07:22PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Now that everyone passes along the format info to > > drm_helper_mode_fill_fb_struct() we can make this behaviour > > mandatory and drop the

Re: [PATCH] gpu: nova-core: vbios: use offset_of in PmuLookupTableHeader::new

On Fri Jul 18, 2025 at 4:36 PM JST, Rhys Lloyd wrote: > Use the offset_of macro for each struct field, annotate the > `PmuLookupTableHeader` struct with `#[repr(C)]` attribute, > and add a TODO message to use FromBytes when available. > > Signed-off-by: Rhys Lloyd > --- > drivers/gpu/nova-core/vb

Re: [PATCH v3] gpu: nova-core: vbios: change PmuLookupTableEntry to use size_of

On Fri Jul 18, 2025 at 4:36 PM JST, Rhys Lloyd wrote: > Annotate the PmuLookupTableEntry with an `#[repr(C, packed)]` attribute. > Removes another magic number by making the struct the same size as > the data it needs to read, allowing the use of > `size_of::()` > > Signed-off-by: Rhys Lloyd Look

Re: [PATCH v2] gpu: nova-core: vbios: use size_of instead of magic number

On Fri Jul 18, 2025 at 4:36 PM JST, Rhys Lloyd wrote: > 12 is identical to the value of `size_of::()`, > so use the latter instead. > > Signed-off-by: Rhys Lloyd Looking good - I'll push this to nova-next unless someone complains. Thanks!

Re: [PATCH 1/4] dt-bindings: backlight: Add max25014 bindings

reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250725-max25014-v1-1-0e8cce920...@gocontroll.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_c

[syzbot] Monthly dri report (Jul 2025)

Hello dri maintainers/developers, This is a 31-day syzbot report for the dri subsystem. All related reports/information can be found at: https://syzkaller.appspot.com/upstream/s/dri During the period, 0 new issues were detected and 0 were fixed. In total, 20 issues are still open and 32 have alre

Re: [PATCH 02/12] dt-bindings: display: st,stm32-ltdc: add access-controllers property

but found 6 (indentation) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250725-drm-misc-next-v1-2-a59848e62...@foss.st.com The base for the series is generally the latest rc1. A different dependency sho

Re: [PATCH 01/12] dt-bindings: display: st: add new compatible to LTDC device

#x27;maxItems': 1, 'items': [{'const': 'lcd'}]} should not be valid under {'required': ['maxItems']} hint: "maxItems" is not needed with an "items" list from schema $id: http://devicetree.org/meta-schemas/items.

  1   2   >