Hello Krzysztof,
Thank you for your feedback.
On Fri, Jan 31, 2025 at 4:47 PM Krzysztof Kozlowski wrote:
>
> On Fri, Jan 31, 2025 at 03:43:53PM +0900, Hironori KIKUCHI wrote:
> > This is a binding for generic MIPI-DSI/DPI panels that require
> > initialization with a simple command sequence befo
Am 21.01.25 um 23:31 schrieb Werner Sembach:
Hi,
after some other work, picked this up again.
Only coding style changes vs v4.
I now got my feet a little wet with hid-bpf regarding something else, and
with that knowledge I would leave the long arrays in the beginning in the
kernel code for the
On 1/31/25 2:04 PM, Danilo Krummrich wrote:
Add the initial nova-core driver stub.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova
From: "Dr. David Alan Gilbert"
The mrst_helper_funcs const was added in 2013 by
commit ac6113ebb70d ("drm/gma500/mrst: Add SDVO clock calculation")
and commented as 'Not used yet'.
It's not been used since, so remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/gma500/oaktrai
On 1/30/2025 3:01 AM, Markus Elfring wrote:
>> Teach the script to suggest conversions for timeout patterns where the
>> arguments to msecs_to_jiffies() are expressions as well.
>
> Does anything hinder to benefit any more from a source code analysis approach
> (like the following by the extended
The pull request you sent on Sat, 1 Feb 2025 07:31:07 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2025-02-01
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/851faa888a523f74f9796c2c1cc7b3f7626f0e25
Thank you!
--
Deet-doot-dot, I am a bot.
htt
FRAME_WARN), $(frame_warn_limit)),y)
+frame_warn_flag := -Wframe-larger-than=$(frame_warn_limit)
+endif
endif
subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/dml2
---
base-commit: 7f2b5237e313e39008a85b33ca94ab503a8fdff9
change-id: 20250131-amdgpu-respect-config_frame_warn-739a9b24496e
Be
Add the initial documentation of the Nova project.
The initial project documentation consists out of a brief introduction
of the project, as well as project guidelines both general and nova-core
specific and a task list for nova-core specifically.
The task list is divided into tasks for general R
Add the initial nova-core driver stub.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova project, including nova-core and nova-drm, in
On Thu, Jan 30, 2025 at 12:00:44PM +0200, Kirill A. Shutemov wrote:
> The recently introduced PG_dropbehind allows for freeing folios
> immediately after writeback. Unlike PG_reclaim, it does not need vmscan
> to be involved to get the folio freed.
>
> Instead of using folio_set_reclaim(), use fol
Hi Linus,
Back from travel, thanks to Sima for taking care of things, only one
MR left for me to finish the merge window, this is only AMD fixes.
Dave.
drm-next-2025-02-01:
drm fixes for 6.14-rc1
amdgpu:
- GC 12 fix
- Aldebaran fix
- DCN 3.5 fix
- Freesync fix
amdkfd:
- Per queue reset fix
- M
On Thu, Jan 30, 2025 at 12:00:40PM +0200, Kirill A. Shutemov wrote:
> Use folios instead of pages.
>
> This is preparation for removing PG_reclaim.
>
> Signed-off-by: Kirill A. Shutemov
> Acked-by: David Hildenbrand
> ---
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 18 +-
> 1
Currently we use a combination of TTM and GEM reference counting which is
cumbersome. TTM references are used for kernel internal BOs and operations
like validation. Simply switching the ttm_bo_(get|put) calls to their
GEM equivalents is insufficient as not all BOs are GEM BOs so we must set
the GE
We are working on extending support for CRIU checkpoint/restore in the amdgpu
driver to support new use cases and ROCm applications increasingly using
render node ioctls for memory management. In the longer term this may also
allow checkpoint/restore of graphics application. With this patch series
This patch (in combination with the accompanying CRIU patch)
allows the amdgpu CRIU plugin to support dmabuf IPC.
It includes
- A new amdgpu ioctl (amdgpu_criu_op_ioctl), which has similar
options to kfd_ioctl_criu, and accompanying structs.
- New "is_retry" field in amdkfd CRIU ioctls, to
On Thu, 2025-01-30 at 17:42 -0500, Vivi, Rodrigo wrote:
> On Tue, Jan 28, 2025 at 10:36:49AM -0800, Alan Previn wrote:
> > Relocate the xe_engine_snapshot_print function from xe_guc_capture.c
> > into xe_hw_engine.c but split out the GuC-Err-Capture register printing
> > portion out into a separate
On Thu, 2025-01-30 at 17:43 -0500, Vivi, Rodrigo wrote:
> On Tue, Jan 28, 2025 at 10:36:50AM -0800, Alan Previn wrote:
alan:snip
> > @@ -55,8 +55,7 @@ void xe_hw_engine_handle_irq(struct xe_hw_engine *hwe,
> > u16 intr_vec);
> > void xe_hw_engine_enable_ring(struct xe_hw_engine *hwe);
> > u32 xe
On 1/29/2025 5:56 AM, Jacek Lawrynowicz wrote:
From: Karol Wachowski
Recovery work doesn't need to be bound to any specific CPU, so move it
to unbound workqueue to improve execution time and system latency.
Reviewed-by: Jacek Lawrynowicz
Signed-off-by: Karol Wachowski
Signed-off-by: Jacek La
On 1/29/2025 5:56 AM, Jacek Lawrynowicz wrote:
This commit introduces the capability to simulate hardware faults for
Nit - "This commit" is redundant.
testing purposes. The new `fail_hw` fault can be injected in
`ivpu_hw_reg_poll_fld()`, which is used in various parts of the driver
to wait fo
On 1/29/2025 5:56 AM, Jacek Lawrynowicz wrote:
From: Tomasz Rusinowicz
Recovery now works on fpga. JSM state dump timeout needs to
be really long for the new fpga model releases.
Enable punit on fpga.
Reviewed-by: Jacek Lawrynowicz
Signed-off-by: Tomasz Rusinowicz
Signed-off-by: Jacek Lawry
On 1/29/2025 5:56 AM, Jacek Lawrynowicz wrote:
From: Karol Wachowski
Hardware scheduling (HWS) is supposed to be supported on all existing
platform with recent FW including pre-silicon ones. Turn on HWS by
default.
Is there released firmware which does not have this enabled/supported?
Should
On 1/29/2025 5:56 AM, Jacek Lawrynowicz wrote:
From: Karol Wachowski
Move the ivpu_mmu_discard_events() function to the common portion of
the abort work function. This ensures it is called only once, even if
there are no faulty contexts in context_xa, to guarantee that MMU events
are discarded
> > +++ b/drivers/gpu/drm/xe/xe_guc_capture_snapshot_types.h
> > @@ -0,0 +1,53 @@
> > +/* SPDX-License-Identifier: MIT */
> > +/*
> > + * Copyright © 2021-2024 Intel Corporation
>
> 2025
>
> then
>
> Reviewed-by: Rodrigo Vivi
>
will do - thanks
On 1/29/2025 5:56 AM, Jacek Lawrynowicz wrote:
Call pm_runtime_mark_last_busy() in top half of IRQ handler to prevent
device from being runtime suspended before bottom half is executed on
a workqueue.
Reviewed-by: Karol Wachowski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Right now the only means by which we can write-protect a range using the
reverse mapping is via folio_mkclean().
However this is not always the appropriate means of doing so, specifically
in the case of the framebuffer deferred I/O logic (fb_defio enabled by
CONFIG_FB_DEFERRED_IO). There, kernel p
With the introduction of mapping_wrprotect_page() there is no need to use
folio_mkclean() in order to write-protect mappings of frame buffer pages,
and therefore no need to inappropriately set kernel-allocated page->index,
mapping fields to permit this operation.
Instead, store the pointer to the
in the fb_defio video driver, page dirty state is used to determine when
frame buffer pages have been changed, allowing for batched, deferred I/O to
be performed for efficiency.
This implementation had only one means of doing so effectively - the use of
the folio_mkclean() function.
However, this
In order to permit the traversal of the reverse mapping at a specified
mapping and offset rather than those specified by an input folio, we need
to separate out the portion of the rmap file logic which deals with this
traversal from those parts of the logic which interact with the folio.
This patc
On 1/29/2025 5:40 AM, Jacek Lawrynowicz wrote:
Disable runtime PM for the duration of reset/recovery so it is possible
to set the correct runtime PM state depending on the outcome of the
`ivpu_resume()`. Don’t suspend or reset the HW if the NPU is suspended
when the reset/recovery is requested. A
On 1/29/2025 5:40 AM, Jacek Lawrynowicz wrote:
pm_runtime_resume_and_get() sets dev->power.runtime_error that causes
all subsequent pm_runtime_get_sync() calls to fail.
Clear the runtime_error using pm_runtime_set_suspended(), so the driver
doesn't have to be reloaded to recover when the NPU fail
On 1/29/2025 5:40 AM, Jacek Lawrynowicz wrote:
Ensure IRQs and IPC are properly disabled if HW sched or DCT
initialization fails.
Fixes: cc3c72c7e610 ("accel/ivpu: Refactor failure diagnostics during boot")
Cc: # v6.13+
Reviewed-by: Karol Wachowski
Signed-off-by: Jacek Lawrynowicz
Reviewed-
Hello,
syzbot found the following issue on:
HEAD commit:9c5968db9e62 Merge tag 'mm-stable-2025-01-26-14-59' of git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1504511858
kernel config: https://syzkaller.appspot.com/x/.config?x=e0b04511e541daf8
das
On 1/24/2025 10:35 AM, Lizhi Hou wrote:
It is required by firmware to wait up to 2 seconds for pending commands
before sending the destroy hardware context command. After 2 seconds
wait, if there are still pending commands, driver needs to cancel them.
So the context destroy steps need to be:
On Thu, Jan 30, 2025 at 07:51:49PM +0100, Thomas Hellström wrote:
> On Thu, 2025-01-30 at 09:31 -0800, Matthew Brost wrote:
> > On Thu, Jan 30, 2025 at 04:56:39PM +, Matthew Auld wrote:
> > > On 30/01/2025 16:32, Matthew Brost wrote:
> > > > On Thu, Jan 30, 2025 at 02:22:55PM +, Matthew Aul
On Fri, Jan 31, 2025 at 11:14:06AM +1100, Alistair Popple wrote:
> On Thu, Jan 30, 2025 at 04:29:33PM +0100, David Hildenbrand wrote:
> > On 30.01.25 14:31, Simona Vetter wrote:
> > > On Thu, Jan 30, 2025 at 10:37:06AM +0100, David Hildenbrand wrote:
> > > > On 30.01.25 01:27, Alistair Popple wrote
Hi Quentin,
On Friday, 31 January 2025 11:38:34 EST Quentin Schulz wrote:
> Hi Detlev,
>
> On 1/30/25 5:45 PM, Detlev Casanova wrote:
> > Use the simple-audio-card driver with the hdmi0 QP node as CODEC and
> > the i2s5 device as CPU.
> >
> > The simple-audio-card,mclk-fs value is set to 128 as
On Thu, Jan 30, 2025 at 04:43:08PM +0100, David Hildenbrand wrote:
> > > Assume you have a THP (or any mTHP today). You can easily trigger the
> > > scenario that folio_mapcount() != 0 with active device-exclusive entries,
> > > and you start doing rmap walks and stumble over these device-exclusive
On Fri, Jan 31, 2025 at 02:02:14PM +0100, Louis Chauvet wrote:
> On 31/01/25 - 10:31, José Expósito wrote:
> > On Thu, Jan 30, 2025 at 02:48:10PM +0100, Louis Chauvet wrote:
> > > On 29/01/25 - 12:00, José Expósito wrote:
> > > > Hi everyone,
> > > >
> > > > In preparation for ConfigFS support, a
On 1/17/2025 10:09 AM, Jeffrey Hugo wrote:
Initial support to the driver to boot up AIC200. AIC200 uses BHIe
without BHI, which is something that the MHI bus has not supported until
now. While the MHI changes are listed first to facilitate cross-tree
merging, they are not needed until the last ch
On Thu, Jan 30, 2025 at 01:42:17PM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 30, 2025 at 05:09:44PM +0100, Simona Vetter wrote:
> > > > An optional callback is a lot less scary to me here (or redoing
> > > > hmm_range_fault or whacking the migration helpers a few times) looks a
> > > > lot
> > >
On Fri, Jan 31, 2025 at 02:02:14PM +0100, Louis Chauvet wrote:
> On 31/01/25 - 09:41, José Expósito wrote:
> > Hi Louis,
> >
> > > From: Arthur Grillo
> > >
> > > Create KUnit tests to test the conversion between YUV and RGB. Test each
> > > conversion and range combination with some common colo
On Fri, Jan 31, 2025 at 11:55:55AM +0100, David Hildenbrand wrote:
> On 31.01.25 00:06, Alistair Popple wrote:
> > On Thu, Jan 30, 2025 at 02:03:42PM +0100, Simona Vetter wrote:
> > > On Thu, Jan 30, 2025 at 10:58:51AM +0100, David Hildenbrand wrote:
> > > > On 30.01.25 10:51, Simona Vetter wrote:
+cc Kajtar, who has kindly smoke tested this series on real hardware and
confirmed things are working ostensibly the same as before.
On this basis I will be un-RFC'ing this and, if Kajtar can reply to
confirm, will add a Tested-by tag to patch 3/3.
Again to emphasise - there is some urgency here
On Thu, Jan 30, 2025 at 04:59:16PM +0100, David Hildenbrand wrote:
> > > > > > Note that the PTE is
> > > > > > always writable, and we can always create a
> > > > > > writable-device-exclusive
> > > > > > entry.
> > > > > >
> > > > > > With this change, device-exclusive is fully compatible with
I don't know this code at all, so this is likely just noise, but the
wait_event_timeout() usage in decon_wait_for_vblank() looks funny to
me.
decon_wait_for_vblank() waits on wait_vsync_queue for wait_vsync_event
to be cleared.
But decon_irq_handler() only clears wait_vsync_event and wakes up
wai
On Fri, Jan 31, 2025 at 02:02:14PM +0100, Louis Chauvet wrote:
> On 31/01/25 - 09:40, José Expósito wrote:
> > Hi Louis,
> >
> > Thanks a lot for the patches.
> >
> > I'm not well versed in YUV color formats, so I did my best reading the
> > kernel
> > documentation before reviewing this series.
On Fri, Jan 31, 2025 at 04:02:52PM +0100, Krzysztof Kozlowski wrote:
> PHY_CMN_CLK_CFG1 register has four fields being used in the driver: DSI
> clock divider, source of bitclk and two for enabling the DSI PHY PLL
> clocks.
>
> dsi_7nm_set_usecase() sets only the source of bitclk, so should leave
On Fri, Jan 31, 2025 at 04:02:51PM +0100, Krzysztof Kozlowski wrote:
> PHY_CMN_CLK_CFG1 register is updated by the PHY driver and by a mux
> clock from Common Clock Framework:
> devm_clk_hw_register_mux_parent_hws(). There could be a path leading to
> concurrent and conflicting updates between PHY
dsi/phy: Do not overwite PHY_CMN_CLK_CFG1 when choosing bitclk
> source
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 50
> ---
> 1 file changed, 33 insertions(+), 17 deletions(-)
> ---
> base-commit: 375ef7b3d85d8b0fa72092642582ca5b95a64
On 28/01/2025 19:48, Michal Wilczynski wrote:
> Add bindings for the PowerVR BXM-4-64 GPU integrated in the T-HEAD
> TH1520 SoC. This GPU requires two clocks.
None of the IMG Rogue GPUs use two clocks; they're all either one or
three. The TRM for the TH1520 I have shows the standard three (core,
On 28/01/2025 19:47, Michal Wilczynski wrote:
> The LicheePi 4A board, featuring the T-HEAD TH1520 SoC, includes an
> Imagination
> Technologies BXM-4-64 GPU. Initial support for this GPU was provided through a
> downstream driver [1]. Recently, efforts have been made to upstream support
> for
>
On 28/01/2025 19:48, Michal Wilczynski wrote:
> The T-Head TH1520 SoC integrates a variety of clocks for its subsystems,
> including the Application Processor (AP) and the Video Output (VO) [1].
> Up until now, the T-Head clock driver only supported AP clocks.
>
> This commit extends the driver to
On 28/01/2025 19:48, Michal Wilczynski wrote:
> The IMG BXM-4-64 GPU is integrated into the T-Head TH1520 SoC. This
> commit adds the compatible string "img,img-bxm" to the device tree match
> table in the drm/imagination driver, enabling support for this GPU.
>
> By including this GPU in the comp
On 28/01/2025 19:48, Michal Wilczynski wrote:
> Add reset controller driver for the T-HEAD TH1520 SoC that manages
> hardware reset lines for various subsystems. The driver currently
> implements support for GPU reset control, with infrastructure in place
> to extend support for NPU and Watchdog Ti
On 28/01/2025 19:48, Michal Wilczynski wrote:
> Many RISC-V boards featuring Imagination Technologies GPUs require a
> reset line to be de-asserted as part of the GPU power-up sequence. To
> support this, add a 'resets' property to the GPU device tree bindings.
> This ensures the GPU can be properl
On 28/01/2025 19:48, Michal Wilczynski wrote:
> Certain platforms, such as the T-Head TH1520 and Banana Pi BPI-F3,
> require a controlled GPU reset sequence during the power-up procedure
> to ensure proper initialization. Without this reset, the GPU may remain
> in an undefined state, potentially l
Use the simple-audio-card driver with the hdmi0 QP node as CODEC and
the i2s5 device as CPU.
The simple-audio-card,mclk-fs value is set to 128 as it is done in
the downstream driver.
The #sound-dai-cells value is set to 0 in the hdmi0 node so that it can be
used as an audio codec node.
Signed-of
From: Sugar Zhang
Register the dw-hdmi-qp bridge driver as an HDMI audio codec.
The register values computation functions (for n) are based on the
downstream driver, as well as the register writing functions.
The driver uses the generic HDMI Codec framework in order to implement
the HDMI audio
To support HDMI audio on the rk3588 based devices, the generic HDMI
Codec framework is used in the dw-hdmi-qp DRM bridge driver.
The implementation is mainly based on the downstream driver, ported to the
generic HDMI Codec framework [1] recently merged in the master branch.
The parameters computat
Am 30.01.25 um 11:13 schrieb Thomas Hellström:
Provide a standalone shmem backup implementation.
Given the ttm_backup interface, this could
later on be extended to providing other backup
implementation than shmem, with one use-case being
GPU swapout to a user-provided fd.
v5:
- Fix a UAF. (kerne
PHY_CMN_CLK_CFG1 register is updated by the PHY driver and by a mux
clock from Common Clock Framework:
devm_clk_hw_register_mux_parent_hws(). There could be a path leading to
concurrent and conflicting updates between PHY driver and clock
framework, e.g. changing the mux and enabling PLL clocks.
PHY_CMN_CLK_CFG1 register has four fields being used in the driver: DSI
clock divider, source of bitclk and two for enabling the DSI PHY PLL
clocks.
dsi_7nm_set_usecase() sets only the source of bitclk, so should leave
all other bits untouched. Use newly introduced
dsi_pll_cmn_clk_cfg1_update() t
PHY_CMN_CLK_CFG0 register is updated by the PHY driver and by two
divider clocks from Common Clock Framework:
devm_clk_hw_register_divider_parent_hw(). Concurrent access by the
clocks side is protected with spinlock, however driver's side in
restoring state is not. Restoring state is called from
tions(-)
---
base-commit: 375ef7b3d85d8b0fa72092642582ca5b95a64e67
change-id: 20250131-drm-msm-phy-pll-cfg-reg-7e5bf5aa9df6
Best regards,
--
Krzysztof Kozlowski
On Thu, Jan 30, 2025 at 12:00:40PM +0200, Kirill A. Shutemov wrote:
> Use folios instead of pages.
>
> This is preparation for removing PG_reclaim.
Well, this is a horrid little function. Rather than iterating just the
dirty folios, it iterates all folios, then locks them before checking
whether
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/vgg2432a4.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/vgg2432a4.c
b/drivers/video/backlight/vgg2432a4.c
index bfc1913e8b55e..3005eba6c82c7 1
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/locomolcd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/locomolcd.c
b/drivers/video/backlight/locomolcd.c
index 346d3e29a8435..1b493fb0516db 1
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/ep93xx_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/ep93xx_bl.c
b/drivers/video/backlight/ep93xx_bl.c
index 2387009d452d0..f59effc023528 1
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/hp680_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/hp680_bl.c
b/drivers/video/backlight/hp680_bl.c
index fa9a983533b2d..d8c2e4ada384b 1006
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/bd6107.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/bd6107.c b/drivers/video/backlight/bd6107.c
index 90764f83d2f12..74567af84e97f 100644
---
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/adp8870_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/adp8870_bl.c
b/drivers/video/backlight/adp8870_bl.c
index ad4bd4c8f441d..e09e20492e7c
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/wm831x_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/wm831x_bl.c
b/drivers/video/backlight/wm831x_bl.c
index c5aaee205bdfb..49027f04a1ecb 1
A number of backlight drivers include . None of them
requires anything from the header file, so remove the include
statements.
Thomas Zimmermann (16):
backlight: 88pm860x_bl: Do not include
backlight: adp5520_bl: Do not include
backlight: adp8860_bl: Do not include
backlight: adp8870_bl
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/adp5520_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/adp5520_bl.c
b/drivers/video/backlight/adp5520_bl.c
index aa5c15e8db86e..81c40d355aae
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/max8925_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/max8925_bl.c
b/drivers/video/backlight/max8925_bl.c
index e607ec6fd4bf4..4ac20a59e007
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/as3711_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/as3711_bl.c
b/drivers/video/backlight/as3711_bl.c
index e6f66bb35ef59..9f89eb19894e3 1
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/da903x_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/da903x_bl.c
b/drivers/video/backlight/da903x_bl.c
index 71f21bbc7a9fc..81ff42bec0ad4 1
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/tps65217_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/tps65217_bl.c
b/drivers/video/backlight/tps65217_bl.c
index d96d713fe7db3..8aa860350
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/88pm860x_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/88pm860x_bl.c
b/drivers/video/backlight/88pm860x_bl.c
index 720b5ada7fe85..0a1db2824
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/lv5207lp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/lv5207lp.c
b/drivers/video/backlight/lv5207lp.c
index 5f60989fa70f2..a205f004eab24 1006
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/da9052_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/da9052_bl.c
b/drivers/video/backlight/da9052_bl.c
index 5e13ef96b717c..f41523d78121b 1
This driver does not require . Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/adp8860_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/adp8860_bl.c
b/drivers/video/backlight/adp8860_bl.c
index f51ada4795e8e..d4bbd7a7406b
Hi Kirill,
On Thu, Jan 30, 2025 at 12:00:41PM +0200, Kirill A. Shutemov wrote:
> The recently introduced PG_dropbehind allows for freeing folios
> immediately after writeback. Unlike PG_reclaim, it does not need vmscan
> to be involved to get the folio freed.
>
> Instead of using folio_set_reclai
Hi Kirill,
On Thu, Jan 30, 2025 at 12:00:40PM +0200, Kirill A. Shutemov wrote:
> Use folios instead of pages.
>
> This is preparation for removing PG_reclaim.
>
> Signed-off-by: Kirill A. Shutemov
> Acked-by: David Hildenbrand
looks good:
Reviewed-by: Andi Shyti
Thanks,
Andi
I can't see patch #1 in my inbox for some reason, but I already know
what it does from your repository.
Feel free to add Reviewed-by: Christian König
to the entire series.
Regards,
Christian.
Am 31.01.25 um 12:02 schrieb Pierre-Eric Pelloux-Prayer:
Hi,
The initial goal of this series was
On Wed, 29 Jan 2025 10:51:48 +0100, Hans Verkuil wrote:
> If the hotplug detect of a display is low for longer than one second
> (configurable through drm_dp_cec_unregister_delay), then the CEC adapter
> is unregistered since we assume the display was disconnected. If the
> HPD went low for less th
On 31/01/25 - 09:40, José Expósito wrote:
> Hi Louis,
>
> Thanks a lot for the patches.
>
> I'm not well versed in YUV color formats, so I did my best reading the kernel
> documentation before reviewing this series... But I'll most likely ask some
> basic/dump questions.
>
> > From: Arthur Grill
On 31/01/25 - 09:41, José Expósito wrote:
> Hi Louis,
>
> > From: Arthur Grillo
> >
> > Create KUnit tests to test the conversion between YUV and RGB. Test each
> > conversion and range combination with some common colors.
> >
> > The code used to compute the expected result can be found in com
On 31/01/25 - 10:31, José Expósito wrote:
> On Thu, Jan 30, 2025 at 02:48:10PM +0100, Louis Chauvet wrote:
> > On 29/01/25 - 12:00, José Expósito wrote:
> > > Hi everyone,
> > >
> > > In preparation for ConfigFS support, a flexible way to configure VKMS
> > > device(s)
> > > is required.
> > > Th
Syzkaller found a case of dangerous call via drm_ioctl(). If user makes
object_count too large, WARN() is called when allocating memory:
[ cut here ]
WARNING: CPU: 0 PID: 5229 at mm/page_alloc.c:4709
__alloc_pages_noprof+0x3bd/0x710 mm/page_alloc.c:4709
Modules linked in:
* Dmitry Baryshkov (dmitry.barysh...@linaro.org) wrote:
> On Tue, Oct 29, 2024 at 11:47:05PM +, li...@treblig.org wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > drm_client_modeset_check() was explicitly added in 2020 by
> > commit 64593f2a6fc9 ("drm/client: Add drm_client_modeset_check()")
Hi Maxime
Am 29.01.25 um 15:31 schrieb Maxime Ripard:
Hi Thomas,
On Wed, Jan 29, 2025 at 02:06:15PM +0100, Thomas Zimmermann wrote:
Am 28.01.25 um 23:29 schrieb Anusha Srivatsa:
Remove the TODO now that this series addresses
the changes needed.
While your series is fine, this TODO item is u
On 1/29/25 20:11, Anusha Srivatsa wrote:
> On Wed, Jan 29, 2025 at 4:10 AM Raphael Gallais-Pou <
> raphael.gallais-...@foss.st.com> wrote:
>
>> On 1/28/25 23:29, Anusha Srivatsa wrote:
>>> Replace platform_get_resource/_byname + devm_ioremap
>>> with just devm_platform_ioremap_resource()
>>>
>>>
On 31.01.25 00:36, Alistair Popple wrote:
On Wed, Jan 29, 2025 at 12:54:05PM +0100, David Hildenbrand wrote:
It's unclear why they would be considered migration entries; they are
not.
Yeah, I agree that doesn't seem right. I suspect I was initially modelling
device exclusive entries similar to
This commit adds a document section in drm-uapi.rst about tracepoints,
and mark the events gpu_scheduler_trace.h as stable uAPI.
The goal is to explicitly state that tools can rely on the fields,
formats and semantics of these events.
Acked-by: Lucas Stach
Acked-by: Maíra Canal
Signed-off-by: P
For processes with multiple drm_file instances, the drm_client_id is
the only way to map jobs back to their unique owner.
It's even more useful if drm client_name is set, because now a tool
can map jobs to the client name instead of only having access to
the process name.
Signed-off-by: Pierre-Er
Trace the fence dependencies similarly to how we print fences:
... , dependencies:{fence=606:38006}
This allows tools to analyze the dependencies between the jobs (previously
it was only possible for fences traced by drm_sched_job_wait_dep).
Since drm_sched_job and drm_run_job use the same base
A fence uniquely identify a job, so this commits updates the places
where a kernel pointer was used as an identifier by:
"fence=%llu:%llu"
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 41 +++
1 file changed, 23 insertions(+), 1
This will be used in a later commit to trace the drm client_id in
some of the gpu_scheduler trace events.
This requires changing all the users of drm_sched_job_init to
add an extra parameter.
The newly added drm_client_id field in the drm_sched_fence is a bit
of a duplicate of the owner one. One
Since switching the scheduler from using kthreads to workqueues in
commit a6149f039369 ("drm/sched: Convert drm scheduler to use a work
queue rather than kthread") userspace applications cannot determine
the device from the PID of the threads sending the trace events
anymore.
Each queue had its ow
1 - 100 of 128 matches
Mail list logo
