Hi
Am 18.08.25 um 01:57 schrieb Leander Kieweg:
From: [Leander Kieweg]
Hello,
I am a new contributor looking to get started with kernel development. I found the
"Convert logging to drm_* functions" task on the gpu/todo.html list.
The task description advises contacting the relevant maintaine
Remove dead code in error handling path. When drm_dp_dpcd_write_byte()
fails and ret < 0, the condition in "ret < 0 ? ret : -EIO" will always
be true, making -EIO unreachable.
Simplify by directly returning the error code from
drm_dp_dpcd_write_byte(), which provides more specific error informatio
Some simple if-else logic can be simplified using the ! operator to improve
code readability.
Signed-off-by: Liao Yuanhong
---
.../gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c| 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/
Hi,
I have tested this patch series (rev 16) with
https://invent.kde.org/plasma/kwin/-/merge_requests/7689, uApi works well. The
sharpness is applied and the changes are seen immediately and relative to the
change in user input (Strength).
Tested-by: Adarsh G M
Warm regards,
Adarsh G M
On Mon, Aug 18, 2025 at 12:38:53PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> Documentation/gpu/drm-mm:506: drivers/gpu/drm/drm_gpuvm.c:2446: ERROR:
> Unexpected indentation. [docutils]
>
This abstraction enables implementing new DRM connector APIs in Rust.
Interfaces can be exported to both C and Rust consumers. The initial
intention is to implement a new DRM connector level backlight API to handle
multiple panels with backlight controls on a single system. Ideally,
various functio
The Rust DRM abstractions would incorrectly reference headers using the
non-existent path include/linux/drm. Correct the path to include/drm.
Signed-off-by: Rahul Rameshbabu
Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction")
Fixes: 07c9016085f9 ("rust: drm: add driver abstraction
Substitute 'platform' with 'pci' where appropriate in the comments.
Signed-off-by: Rahul Rameshbabu
Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI device / driver abstractions")
Fixes: 18ebb25dfa18 ("rust: pci: implement Driver::unbind()")
---
rust/kernel/pci.rs | 6 +++---
1 file changed, 3 ins
Hello,
I am working on a drm_connector scoped backlight API in Rust. I have been
looking through Hans de Goede's previous efforts on this topic to help
guide my design. My hope is to enable backlight control over external
displays through DDC or USB Monitor Control Class while also supporting
inte
Hi CK and Paul,
On Mon, Aug 18, 2025 at 12:39 PM Chun-Kuang Hu wrote:
>
> Paul Menzel 於 2025年5月25日 週日 下午2:01寫道：
> >
> > Dear Linux folks,
> >
> >
> > On the older MT8183 device Lenovo IdeaPad Duet Chromebook, running
> > ChromeOS with their Linux 5.10.x, connecting a 1920x1080 Dell monitor to
>
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (htmldocs)
produced these warnings:
Documentation/gpu/drm-mm:506: drivers/gpu/drm/drm_gpuvm.c:2446: ERROR:
Unexpected indentation. [docutils]
Documentation/gpu/drm-mm:506: drivers/gpu/drm/drm_gpuvm.c:2448: WARNING: Block
qu
On 08/13/2025, Wolfram Sang wrote:
> When using MMIO with regmap, fast_io is implied. No need to set it
> again.
>
> Signed-off-by: Wolfram Sang
> ---
> No dependencies, can be applied directly to the subsystem tree. Buildbot is
> happy, too.
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi2.c
When the system is powered off the kernel will call device_shutdown()
which will issue callbacks into PCI core to wake up a device and call
it's shutdown() callback. This will leave devices in ACPI D0 which can
cause some devices to misbehave with spurious wakeups and also leave some
devices on wh
Normally resources are evicted on dGPUs at suspend or hibernate and
on APUs at hibernate. These steps are unnecessary when using the S4
callbacks to put the system into S5.
Cc: AceLan Kao
Cc: Kai-Heng Feng
Cc: Mark Pearson
Cc: Denis Benato
Cc: Merthan Karakaş
Tested-by: Eric Naim
Acked-by:
For the suspend flow PCIe bridges that have downstream devices are put into
the appropriate low power state (D3hot or D3cold depending upon specific
devices). For the hibernate flow, PCIe bridges with downstream devices
stay in D0 however. This can lead to PCIe bridges that are remained
powered on
In order to unify suspend and hibernate codepaths without code duplication
the common code should be in common helpers. Move it from
pci_pm_suspend_noirq() into a helper. No intended functional changes.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Split from earlier p
Devices with no subordinate should be put into D3 during hibernate, but
devices that have bridge_d3 set should also be put to sleep during
hibernate. Adjust the check in pci_pm_poweroff_noirq() to use
pci_power_manageable() to cover those as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonci
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re-order
v4:
*
https://lore.kernel.org/linux-pci/20
Suspend resume actions will check the state of the device and whether
bus PM should be skipped. These same actions make sense during hibernation
image restore. Apply them there as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Split out patch
---
drivers/pci/pci-
If powering off the system with the S4 flow USB wakeup sources should
be ignored. Add a new callback hcd_pci_poweroff() which will differentiate
whether target state is S5 and pass PMSG_POWEROFF as the message so that
suspend_common() will avoid doing wakeups.
Signed-off-by: Mario Limonciello (AMD
PCI devices can be programmed as a wakeup source from low power states
by sysfs. However when using the S4 flow to go into S5 these wakeup
sources should be disabled to avoid what users would perceive as
spurious wakeup events.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re-order
* Add tags
v4:
*
https://lore.kernel.org/
PMSG_POWEROFF will be used for the PM core to allow differentiating between
an S4 or S5 shutdown sequence when re-using callbacks.
This event should not have wakeups enabled so update PMSG_NO_WAKEUP() to
match it as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re
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 localized changes[1] to PCI core to help these issues,
but they have had various downsides.
This series i
On Fri, Aug 08, 2025 at 11:52:59AM +0200, Henrik Grimler wrote:
> Hi Dmitry,
>
> On Sun, Jul 27, 2025 at 08:07:37PM +0300, Dmitry Baryshkov wrote:
> > On Thu, Jul 24, 2025 at 08:50:53PM +0200, Henrik Grimler wrote:
> > > To use MHL we currently need the MHL chip to be permanently on, which
> > > c
Reviewed-by: Alex Hung
On 8/7/25 20:52, Xichao Zhao wrote:
The clamp() macro explicitly expresses the intent of constraining
a value within bounds.Therefore, replacing min(max(a, b), c) with
clamp(val, lo, hi) can improve code readability.
Signed-off-by: Xichao Zhao
---
drivers/gpu/drm/amd/
Reviewed-by: Alex Hung
On 8/6/25 06:41, Liao Yuanhong wrote:
Replace the original swapping logic with swap() to improve readability and
remove temporary variables
Signed-off-by: Liao Yuanhong
---
drivers/gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c | 6 ++
1 file changed, 2 inse
Reviewed-by: Alex Hung
On 7/31/25 01:54, Xichao Zhao wrote:
Adjust whitespace around operators to improve code readability
and comply with kernel coding style guidelines.
These changes are purely stylistic and introduce no
functional modifications.
Signed-off-by: Xichao Zhao
---
.../amd/di
From: [Leander Kieweg]
Hello,
I am a new contributor looking to get started with kernel development. I found
the "Convert logging to drm_* functions" task on the gpu/todo.html list.
The task description advises contacting the relevant maintainers before
starting the work to ensure a patch woul
Reviewed-by: Alex Hung
On 7/23/25 20:36, Chenyuan Yang wrote:
The function mod_hdcp_hdcp1_create_session() calls the function
get_first_active_display(), but does not check its return value.
The return value is a null pointer if the display list is empty.
This will lead to a null pointer derefe
Hi Randy,
On Sun, 17 Aug 2025 16:24:02 -0700 Randy Dunlap wrote:
>
> On 7/9/25 12:37 AM, Danilo Krummrich wrote:
> > On 7/9/25 4:45 AM, Bagas Sanjaya wrote:
> >> Stephen Rothwell reports multiple indentation warnings when merging
> >> drm-msm tree:
> >>
> >> Documentation/gpu/drm-mm:506: ./driv
On 8/12/25 4:36 PM, Tomi Valkeinen wrote:
Hello Tomi,
On 08/06/2025 17:24, Marek Vasut wrote:
Implement support for DSI command transfer mode. Transmission of both Short
I constantly kept reading "DSI command mode support". So I was quite
confused for a bit =). Maybe avoid the use of "mode"
kzalloc() already zero-initializes the destination buffers, making
strscpy() sufficient for safely copying the names. The additional
NUL-padding performed by strscpy_pad() is unnecessary.
If the destination buffer has a fixed length, strscpy() automatically
determines its size using sizeof() when
On 7/9/25 12:37 AM, Danilo Krummrich wrote:
> On 7/9/25 4:45 AM, Bagas Sanjaya wrote:
>> Stephen Rothwell reports multiple indentation warnings when merging
>> drm-msm tree:
>>
>> Documentation/gpu/drm-mm:506: ./drivers/gpu/drm/drm_gpuvm.c:2445: ERROR:
>> Unexpected indentation. [docutils]
>> D
On 8/14/25 7:39 AM, Tomi Valkeinen wrote:
Hello Tomi,
The 1/2/3 lane mode was already implemented in the driver, except it was
broken.
If it never worked, was it broken or not implemented? How much code the
original driver must have for the feature to have the feature
"implemented, just broke
On Fri, Aug 15, 2025 at 12:40:43AM +0800, Icenowy Zheng wrote:
> This is a from-scratch driver targeting Verisilicon DC-series display
> controllers, which feature self-identification functionality like their
> GC-series GPUs.
>
> Only DC8200 is being supported now, and only the main framebuffer i
On Thu, Aug 14, 2025 at 05:44:31PM +0530, Riana Tauro wrote:
> Add documentation for Xe Device Wedging so that
> file can be referenced in following patches.
>
> Signed-off-by: Riana Tauro
Reviewed-by: Rodrigo Vivi
> ---
> Documentation/gpu/xe/index.rst | 1 +
> Documentation/gpu/xe/xe_d
On Thu, Aug 14, 2025 at 05:44:32PM +0530, Riana Tauro wrote:
> Address the need for a recovery method (firmware flash on Firmware errors)
> introduced in the later patches of Xe KMD.
> Whenever XE KMD detects a firmware error, a firmware flash is required to
> recover the device to normal operation
On Fri, Aug 15, 2025 at 02:36:23PM +0800, zhaoguo...@kylinos.cn wrote:
> From: GuoHan Zhao
>
> In xe_hwmon_pcode_rmw_power_limit(), when xe_pcode_read() fails,
> the function logs the error but continues to execute the subsequent
> logic. This can result in undefined behavior as the values val0 a
On Wed, 13 Aug 2025 17:42:27 +0800, Yongbang Shi wrote:
> There are some bugfix for hibmc-drm driver.
>
Applied to drm-misc-fixes, thanks!
[01/11] drm/hisilicon/hibmc: fix the i2c device resource leak when vdac init
failed
commit: e5f48bfa2ae0806d5f51fb8061afc619a73599a7
[03/11] drm/his
On Wed, Aug 13, 2025 at 05:42:33PM +0800, Yongbang Shi wrote:
> From: Baihan Li
>
> If DP is connected, check the DP BW in mode_valid_ctx() to ensure
> that DP's link rate supports high-resolution data transmission.
>
> Fixes: f9698f802e50 ("drm/hisilicon/hibmc: Restructuring the header dp_reg.h
On Wed, Aug 13, 2025 at 05:42:33PM +0800, Yongbang Shi wrote:
> From: Baihan Li
>
> If DP is connected, check the DP BW in mode_valid_ctx() to ensure
> that DP's link rate supports high-resolution data transmission.
>
> Fixes: f9698f802e50 ("drm/hisilicon/hibmc: Restructuring the header dp_reg.h
The patch is in msm-fixes, but I was out last week so haven't had a
chance to send a PR yet
thx
BR,
-R
On Fri, Aug 15, 2025 at 1:10 PM Maíra Canal wrote:
>
> Hi,
>
> Gentle ping on this patch.
>
> Best Regards,
> - Maíra
>
> On 7/20/25 18:42, Maíra Canal wrote:
> > The global fault counter is n
On Wed, Aug 13, 2025 at 05:42:38PM +0800, Yongbang Shi wrote:
> From: Baihan Li
>
> The DP reset was adding in the former commit, so move HDCP cfg after DP
> controller deresets, so that configuration takes effect.
>
> Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq
On Wed, Aug 13, 2025 at 05:42:37PM +0800, Yongbang Shi wrote:
> From: Baihan Li
>
> Add colorbar disable operation before reset controller, to make sure
> colorbar status is clear in the DP init, so if rmmod the driver and the
> previous colorbar configuration will not affect the next time insmod
On Wed, Aug 13, 2025 at 05:42:35PM +0800, Yongbang Shi wrote:
> From: Baihan Li
>
> Our chip support KVM over IP feature, so hibmc driver need to support
> displaying without any connectors plugged in. If no connectors connected,
> set the vdac connector status to 'connected' to handle BMC KVM. U
amdgpu_dm_connector_ddc_get_modes() reinitializes a connector's probed
modes list without cleaning it up. First time it is called during the
driver's initialization phase, then via drm_mode_getconnector() ioctl.
The leaks observed with Kmemleak are as following:
unreferenced object 0x88812f91b
47 matches
Mail list logo
