meson_vclk_vic_supported_freq() has a debug print which includes the
pixel freq. However, within the whole function the pixel freq is
irrelevant, other than checking the end of the params array. Switch to
printing the vclk_freq which is being compared / matched against the
inputs to the function to
The "phy" and "vclk" frequency labels were swapped, making it more
difficult to debug driver errors. Swap the label order to make them
match with the actual frequencies printed to correct this.
Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup")
Signed-off-by: Martin Blumenstingl
The pull request you sent on Fri, 6 Jun 2025 17:27:48 +0200:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-06-06
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5fc6c6f258b34fd0d2ff2a63b8a407a4dcbca750
Thank you!
--
Deet-doot-dot, I am a bot.
ht
The pull request you sent on Fri, 6 Jun 2025 16:04:25 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2025-06-06
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e332935a540eb76dd656663ca908eb0544d96757
Thank you!
--
Deet-doot-dot, I am a bot.
htt
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 7247efca0dcbc8ac6147db9200ed1549c0662465]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-i915-fbdev-Add-intel_fbdev_get_map/20250606-200804
base
Add a callback function for uring_cmd to support the io_uring
interface in DRM devices. The drm_uring_cmd() function allows
for dispatching ioctls to DRM devices. If the uring_cmd
callback is specified in the device's file_operations structure,
the SQE cmd_op field can be set to DRM_URING_CMD_IOCTL
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 27a06d7359c7..2211365827d7 100644
--- a/drivers/gpu/drm/xe/Kconfig
+++ b/drivers/gpu/drm/xe/Kconfig
@@ -45,6 +45,7 @@ confi
From: Rodrigo Vivi
Xe PCODE FWCTL implements the generic FWCTL IOCLTs to allow limited
access from user space (as admin) to some very specific PCODE
Mailboxes only related to hardware configuration.
PCODE is a Firmware in Intel GPUs which is the main responsible
component for power and thermal a
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.
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/xe/xe_debugfs.c| 42 +
Load late binding firmware
v2:
- s/EAGAIN/EBUSY/
- Flush worker in suspend and driver unload (Daniele)
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/xe/xe_late_bind_fw.c | 121 -
drivers/gpu/drm/xe/xe_late_bind_fw.h | 1 +
drivers/gpu/drm/xe/xe_late_bind_f
Reload late binding fw during S2Idle/S3 resume.
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/xe/xe_pm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
index af6f6e63ca9c..2fa3d4f1b192 100644
--- a/drivers/gpu/drm/xe/xe_pm.c
+++
Reload late binding fw during runtime resume.
v2: Flush worker during runtime suspend
Signed-off-by: Badal Nilawar
---
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 | 6 ++
3 files changed, 8 insertions(+), 1 de
Search for late binding firmware binaries and populate the meta data of
firmware structures.
v2:
- drm_err if firmware size is more than max pay load size (Daniele)
- s/request_firmware/firmware_request_nowarn/ as firmware will
not be available for all possible cards (Daniele)
Signed-off-by:
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 late binding component to enable firmware lo
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
---
v2:
- Use generic naming (J
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
From: Alexander Usyskin
Allow to bus client to obtain client mtu.
Signed-off-by: Alexander Usyskin
Signed-off-by: Badal Nilawar
---
drivers/misc/mei/bus.c | 13 +
include/linux/mei_cl_bus.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/misc/mei/bus.c b/driver
On 6/6/25 11:02, Johannes Berg wrote:
From: Johannes Berg
Now that ARCH=um no longer has IO port accesses, this driver
can no longer build as-is. Make the IO port calls not just
conditional on i386 but also !UML.
Reported-by: Arnd Bergmann
Signed-off-by: Johannes Berg
---
drivers/video/fbd
On 6/5/2025 10:20 AM, Maciej Falkowski wrote:
From: Andrzej Kacprowski
Introduces a new parameter to the DRM_IVPU_CMDQ_CREATE ioctl,
Introduce
enabling turbo mode for jobs submitted via the command queue.
Turbo mode allows jobs to run at higher frequencies,
potentially improving performance
On 5/28/2025 3:13 AM, Simona Vetter wrote:
Handles are per-file, not global, so this makes no sense. Plus it's
set only after calling drm_gem_handle_create(), and drivers are not
allowed to further intialize a bo after that function has published it
already.
It is also entirely unused, which hel
On 6/5/2025 10:19 AM, Maciej Falkowski wrote:
Add support for Wildcat Lake (WCL) CPUs.
Wildcat Lake contains NPU5 just like Panther Lake
hence the initial support is very simple and adds
only PCI IDs.
Signed-off-by: Maciej Falkowski
Reviewed-by: Jeff Hugo
On June 6, 2025, 9:05, Jani Nikula wrote:
>If the panel is enabled at probe, and we take over the hardware state, the
>drm_panel prepared state will be out of sync. We'll need to notify drm_panel
>framework about the state at probe, so it can in turn notify the panel
>followers.
>
>Cc: Lee Shaw
On June 6, 2025, 9:05, Jani Nikula wrote:
>Allocate and register a drm_panel so that drm_panel_followers can find the
>panel. Pass the drm_connector::kdev device to drm_panel allocation for
>matching. That's only available after drm_sysfs_connector_add(), so we need to
>postpone the drm_panel a
On June 6, 2025, 9:05, Jani Nikula wrote:
>Add panel register/unregister functions, and handle backlight
>register/unregister from there. This is in preparation for adding more panel
>specific register/unregister functionality.
>
>Cc: Lee Shawn C
>Signed-off-by: Jani Nikula
>---
This patch se
On June 6, 2025, 9:05, Jani Nikula wrote:
>Use firmware node based lookups for panel followers, to make the code
>independent of OF and device tree, and make it work also for ACPI with an
>appropriate _DSD.
>
>ASL example:
>
> Package (0x02)
> {
> "panel", \_SB.PCI0.GFX
On Fri, Jun 06, 2025 at 01:45:51PM +0200, Stefan Eichenberger wrote:
> The Winstar wf40eswaa6mnn0 panel is a square 4.0" TFT LCD with a
> resolution of 480x480 pixels.
>
> Signed-off-by: Stefan Eichenberger
Acked-by: Conor Dooley
signature.asc
Description: PGP signature
ta, 384);
OFFSET_CHECK(struct rogue_fwif_sync_checkpoint, state, 0);
---
base-commit: 217f80acfcf126b7d7d7b818c9bfea3c96fa85ec
change-id: 20250606-sprase-reasoning-comments-e48064532709
Best regards,
--
Alexandru Dadu
On 2025/5/14 07:30:00, Dmitry Baryshkov wrote:
Turn on the switch and use virtual planes by default, enhancing
utilisation of the display pipelines. It is still possible to use legacy
implementation by using `msm.dpu_use_virtual_planes=false` kernel boot
parameter.
Signed-off-by: Dmitry Baryshko
Hi Linus,
Another small batch of drm fixes, this time with a different baseline and
hence separate. Also due to this context conflict in ivpu with what you
have already, linux-next resolution matches what I have:
https://lore.kernel.org/dri-devel/20250606094711.4b990...@canb.auug.org.au/
Cheers,
On Tue, Jun 03, 2025 at 01:43:58PM +0530, Riana Tauro wrote:
> Add a helper function to set recovery method. The recovery
> method has to be set before declaring the device wedged and sending the
> drm wedged uevent. If no method is set, default unbind/re-bind method
> will be set
>
> Signed-off-b
On Fri, Jun 06, 2025 at 04:50:03PM +0300, Imre Deak wrote:
> On Fri, Jun 06, 2025 at 04:44:37PM +0300, Jani Nikula wrote:
> > On Thu, 05 Jun 2025, Imre Deak wrote:
> > > Reading DPCD registers has side-effects and some of these can cause a
> > > problem for instance during link training. Based on
On 6/6/25 15:14, Jocelyn Falempe wrote:
> On 06/06/2025 14:28, Christian König wrote:
>> On 6/6/25 13:48, Jocelyn Falempe wrote:
>>> If the ttm bo is backed by pages, then it's possible to safely kmap
>>> one page at a time, using kmap_try_from_panic().
>>
>> I strongly assume that we don't care ab
On Fri, Jun 06, 2025 at 05:04:36PM +0300, Jani Nikula wrote:
> On Fri, 06 Jun 2025, Imre Deak wrote:
> > On Fri, Jun 06, 2025 at 04:50:03PM +0300, Imre Deak wrote:
> >> On Fri, Jun 06, 2025 at 04:44:37PM +0300, Jani Nikula wrote:
> >> > On Thu, 05 Jun 2025, Imre Deak wrote:
> >> > > Reading DPCD
The following error has been reported sporadically by CI when a test
unbinds the i915 driver on a ring submission platform:
<4> [239.330153] [ cut here ]
<4> [239.330166] i915 :00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)
<4> [239.330196] WARNING: CPU: 1 PID: 1
On Wed, Jun 04, 2025 at 10:10:21AM -0700, Matthew Brost wrote:
> On Wed, Jun 04, 2025 at 06:53:44PM +0200, Danilo Krummrich wrote:
> > On Wed, Jun 04, 2025 at 09:45:00AM -0700, Matthew Brost wrote:
> > > On Wed, Jun 04, 2025 at 05:07:15PM +0200, Simona Vetter wrote:
> > > > We should definitely doc
On Fri, 06 Jun 2025, Imre Deak wrote:
> On Fri, Jun 06, 2025 at 04:50:03PM +0300, Imre Deak wrote:
>> On Fri, Jun 06, 2025 at 04:44:37PM +0300, Jani Nikula wrote:
>> > On Thu, 05 Jun 2025, Imre Deak wrote:
>> > > Reading DPCD registers has side-effects and some of these can cause a
>> > > problem
On Fri, 06 Jun 2025 10:41:18 +0200, Luca Ceresoli wrote:
> This small series adds a few kunit tests for the new DRM bridge allocation
> flow, based on the recently introduced devm_drm_bridge_alloc() [0].
>
> It is part of the work towards removal of bridges from a still existing DRM
> pipeline wit
On Fri, Jun 06, 2025 at 04:44:37PM +0300, Jani Nikula wrote:
> On Thu, 05 Jun 2025, Imre Deak wrote:
> > Reading DPCD registers has side-effects and some of these can cause a
> > problem for instance during link training. Based on this it's better to
> > avoid the probing quirk done before each DP
On 08-05-2025 01:19, Rodrigo Vivi wrote:
+static int xe_pcode_fwctl_uctx_open(struct fwctl_uctx *uctx)
+{
+ struct xe_pcode_fwctl_dev *fwctl_dev =
+ container_of(uctx->fwctl, struct xe_pcode_fwctl_dev, fwctl);
+ struct xe_device *xe = fwctl_dev->xe;
+
+ xe_pm_runt
On 06-05-2025 23:43, Jason Gunthorpe wrote:
+/**
+ * struct fwctl_rpc_xe_pcode - FWCTL Remote Procedure Calls for Xe PCODE
+ */
+struct fwctl_rpc_xe_pcode {
+ /** @command: The main Mailbox command */
+ __u8 command;
+ /** @param1: A subcommand or a parameter of the main comman
On Thu, 05 Jun 2025, Imre Deak wrote:
> Reading DPCD registers has side-effects and some of these can cause a
> problem for instance during link training. Based on this it's better to
> avoid the probing quirk done before each DPCD register read, limiting
> this to the monitor which requires it. T
On Fri, 06 Jun 2025, Jocelyn Falempe wrote:
> Implement both functions for i915 and xe, they prepare the work for
> drm_panic support.
> They both use kmap_try_from_panic(), and map one page at a time, to
> write the panic screen on the framebuffer.
>
> Signed-off-by: Jocelyn Falempe
> ---
>
>
>
On 06/06/2025 15:24, Jani Nikula wrote:
On Fri, 06 Jun 2025, Jocelyn Falempe wrote:
Implement both functions for i915 and xe, they prepare the work for
drm_panic support.
They both use kmap_try_from_panic(), and map one page at a time, to
write the panic screen on the framebuffer.
Signed-off-b
On 06/06/2025 14:28, Christian König wrote:
On 6/6/25 13:48, Jocelyn Falempe wrote:
If the ttm bo is backed by pages, then it's possible to safely kmap
one page at a time, using kmap_try_from_panic().
I strongly assume that we don't care about locking anything in this case, don't
we?
Yes, n
On Fri, Jun 06, 2025 at 09:28:53AM +0200, Thomas Zimmermann wrote:
> Hi Dave, Sima,
>
> here's the PR from drm-misc-fixes for this week. It's a bit later
> due to merge-window confusion. The fixes for sysfb and video also
> affect fbdev.
>
> Best regards
> Thomas
>
> drm-misc-fixes-2025-06-06:
>
Make drm_wait_on_vblank() static. The function is an internal interface
and not invoked directly by drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_vblank.c | 14 +-
include/drm/drm_vblank.h | 1 -
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/
ase-commit: b3bded85d838336326ce78e394e7818445e11f20
change-id: 20250606-mtk_dpi-mt8195-fix-wrong-color-5aab0f6d2d27
Best regards,
--
Louis-Alexis Eyraud
On Wed, May 28, 2025 at 05:35:50PM +0200, Thomas Zimmermann wrote:
> Hi Dave, Sima,
>
> this is the weekly PR for drm-misc-fixes. Besides DRM, the bugfix
> for dummycon possibly affects fbcon and fbdev output as well.
>
> Best regards
> Thomas
>
> drm-misc-fixes-2025-05-28:
> Short summary of fi
On 6/6/25 13:48, Jocelyn Falempe wrote:
> If the ttm bo is backed by pages, then it's possible to safely kmap
> one page at a time, using kmap_try_from_panic().
I strongly assume that we don't care about locking anything in this case, don't
we?
> Unfortunately there is no way to do the same with
On Thu, 05 Jun 2025 22:45:20 +0530, Aradhya Bhatia wrote:
> This series re-orders the sequences in which the drm CRTC and the drm
> Bridge get enabled and disabled with respect to each other.
>
> The bridge pre_enable calls have been shifted before the crtc_enable and
> the bridge post_disable cal
On Fri, Jun 06, 2025 at 03:02:49PM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe writes:
>
> > On Thu, Jun 05, 2025 at 09:47:01PM +0530, Aneesh Kumar K.V wrote:
> >> Jason Gunthorpe writes:
> >>
> >> > On Thu, Jun 05, 2025 at 05:33:52PM +0530, Aneesh Kumar K.V wrote:
> >> >
> >> >> > +
> >>
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
This assumes that the alignment restriction is always smaller in
linear than in tiled.
It also assumes that the linear framebuffer size is alwa
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
This assumes that the alignment restriction is always smaller in
linear than in tiled.
It also assumes that the linear framebuffer size is alw
On Alder Lake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements Y-Tiling support, to still be able to draw
the panic screen.
Signed-off-by: Jocelyn Falempe
---
v8:
* Pass the tiling function to intel_bo_panic_setup()
.../gpu/drm/i915/display/intel_a
When the panic handler is called, configure the psr to send the full
framebuffer to the monitor, otherwise the panic screen is only
partially visible.
Signed-off-by: Jocelyn Falempe
---
v8:
* Added in v8
.../gpu/drm/i915/display/intel_atomic_plane.c | 7 +++
drivers/gpu/drm/i915/display/
On Alder Lake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements 4-Tiling support, to still be able to draw
the panic screen.
Signed-off-by: Jocelyn Falempe
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 20 +++
1 file changed, 20 i
Implement both functions for i915 and xe, they prepare the work for
drm_panic support.
They both use kmap_try_from_panic(), and map one page at a time, to
write the panic screen on the framebuffer.
Signed-off-by: Jocelyn Falempe
---
v5:
* Use iosys_map for intel_bo_panic_map().
v7:
* Return
This adds drm_panic support for a wide range of Intel GPU. I've
tested it only on 4 laptops, Haswell (with 128MB of eDRAM),
Comet Lake, Raptor Lake, and Lunar Lake.
For hardware using DPT, it's not possible to disable tiling, as you
will need to reconfigure the way the GPU is accessing the
framebuf
If the ttm bo is backed by pages, then it's possible to safely kmap
one page at a time, using kmap_try_from_panic().
Unfortunately there is no way to do the same with ioremap, so it
only supports the kmap case.
This is needed for proper drm_panic support with xe driver.
Signed-off-by: Jocelyn Fale
The vaddr of the fbdev framebuffer is private to the struct
intel_fbdev, so this function is needed to access it for drm_panic.
Also the struct i915_vma is different between i915 and xe, so it
requires a few functions to access fbdev->vma->iomap.
Signed-off-by: Jocelyn Falempe
---
v2:
* Add int
This is a draft of drm_panic support for i915.
I've tested it on the 4 intel laptops I have at my disposal.
* Haswell with 128MB of eDRAM.
* Comet Lake i7-10850H
* Raptor Lake i7-1370P (with DPT, and Y-tiling).
* Lunar Lake Ultra 5 228V (with DPT, and 4-tiling, and using the Xe driver.
I tes
On Wed, Jun 04, 2025 at 10:45:11PM -0500, Anusha Srivatsa wrote:
> Put the panel reference back when driver is no
> longer using it.
>
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/s
On 6/6/25 11:52, wangtao wrote:
>
>
>> -Original Message-
>> From: Christoph Hellwig
>> Sent: Tuesday, June 3, 2025 9:20 PM
>> To: Christian König
>> Cc: Christoph Hellwig ; wangtao
>> ; sumit.sem...@linaro.org; kra...@redhat.com;
>> vivek.kasire...@intel.com; v...@zeniv.linux.org.uk; b
The Tegra X1 chip contains a NVJPG accelerator capable of
encoding/decoding JPEG files in hardware, so add its DT node.
Signed-off-by: Diogo Ivo
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegr
Add support for booting and using NVJPG on Tegra210 to the Host1x
and TegraDRM drivers. This driver only supports the new TegraDRM uAPI.
Signed-off-by: Diogo Ivo
---
drivers/gpu/drm/tegra/Makefile | 1 +
drivers/gpu/drm/tegra/drm.c| 2 +
drivers/gpu/drm/tegra/drm.h| 1 +
drivers/gp
Add the NVJPG power-domain node in order to support the NVJPG
accelerator.
Signed-off-by: Diogo Ivo
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index
4
Hello,
This series adds support for the NVJPG hardware accelerator found in the
Tegra210 SoC.
The kernel driver is essentially a copy of the NVDEC driver as both
engines are Falcon-based.
For the userspace part I have written a Mesa Gallium backend [1] that,
while still very much experimental, w
On Fri, 6 Jun 2025 10:09:30 +0200
Boris Brezillon wrote:
> Hello,
>
> This is an attempt a couple bugs exposed by FEX-Emu. The first one
> is pretty trivial and should be uncontroversial, since it's just
> a missing padding field in one of our uAPI structs. We are getting
> away with it on arm3
On Fri, 6 Jun 2025 12:18:33 +0200
Boris Brezillon wrote:
> Hi all,
>
> This patch series adds support for 64-bit and poll register accessors in
> the Panthor DRM driver and performs a cleanup of the 64-bit register
> definitions.
>
> The first patch introduces new accessor functions to simplif
From: Karunika Choo
With the introduction of 64-bit register accessors, the separate *_HI
definitions are no longer necessary. This change removes them and
renames the corresponding *_LO entries for cleaner and more consistent
register definitions.
Reviewed-by: Liviu Dudau
Reviewed-by: Steven P
Hi all,
This patch series adds support for 64-bit and poll register accessors in
the Panthor DRM driver and performs a cleanup of the 64-bit register
definitions.
The first patch introduces new accessor functions to simplify and
standardize 64-bit and polling register operations. The second patch
From: Karunika Choo
This patch adds 64-bit register accessors to simplify register access in
Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout.
This patch also updates Panthor to use the new 64-bit accessors and poll
functions.
Reviewed-by: Liviu Dudau
Reviewed-by: Steven
> -Original Message-
> From: Christoph Hellwig
> Sent: Wednesday, June 4, 2025 12:02 AM
> To: Christian König
> Cc: Christoph Hellwig ; wangtao
> ; sumit.sem...@linaro.org; kra...@redhat.com;
> vivek.kasire...@intel.com; v...@zeniv.linux.org.uk; brau...@kernel.org;
> hu...@google.com;
> -Original Message-
> From: Christoph Hellwig
> Sent: Tuesday, June 3, 2025 9:20 PM
> To: Christian König
> Cc: Christoph Hellwig ; wangtao
> ; sumit.sem...@linaro.org; kra...@redhat.com;
> vivek.kasire...@intel.com; v...@zeniv.linux.org.uk; brau...@kernel.org;
> hu...@google.com; a..
From: Johannes Berg
Now that ARCH=um no longer has IO port accesses, this driver
can no longer build as-is. Make the IO port calls not just
conditional on i386 but also !UML.
Reported-by: Arnd Bergmann
Signed-off-by: Johannes Berg
---
drivers/video/fbdev/nvidia/nv_local.h | 2 +-
1 file chang
Jason Gunthorpe writes:
> On Thu, Jun 05, 2025 at 09:47:01PM +0530, Aneesh Kumar K.V wrote:
>> Jason Gunthorpe writes:
>>
>> > On Thu, Jun 05, 2025 at 05:33:52PM +0530, Aneesh Kumar K.V wrote:
>> >
>> >> > +
>> >> > + /* To ensure no host side MMIO access is possible */
>> >> > + re
On Fri, 06 Jun 2025, Maxime Ripard wrote:
> Thanks for working on that. Your two patches (the one you sent here, and
> the one in the other subthread) look good to me. So if that works, it
> looks like we have a way forward.
Coincidentally, I just posted the first non-draft patches [1]. Thanks
fo
Hi Tomeu,
On Friday, 6 June 2025 08:28:30 Central European Summer Time Tomeu Vizoso wrote:
> From: Nicolas Frattaroli
>
> The NPU on the ROCK5B uses the same regulator for both the sram-supply
> and the npu's supply. Add this regulator, and enable all the NPU bits.
> Also add the regulator as a
Le 05/06/2025 à 17:24, Thomas Zimmermann a écrit :
Replace vkms' vblank timer with the DRM implementation. The DRM
code is mostly identical.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Louis Chauvet
Tested-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_crtc.c | 49 +++-
Allocate and register a drm_panel so that drm_panel_followers can find
the panel. Pass the drm_connector::kdev device to drm_panel allocation
for matching. That's only available after drm_sysfs_connector_add(), so
we need to postpone the drm_panel allocation until .late_register()
hook.
The drm_pa
Hi all -
This series expands panel follower to ACPI, and enables drm_panel on
i915.
Patch 1 makes panel follower matching independent of DT, making it also
work with ACPI. Similar to DT, you can use a _DSD "panel" property to
describe the dependency.
Patches 2-4 add drm_panel support to i915 DSI
If the panel is enabled at probe, and we take over the hardware state,
the drm_panel prepared state will be out of sync. We'll need to notify
drm_panel framework about the state at probe, so it can in turn notify
the panel followers.
Cc: Lee Shawn C
Signed-off-by: Jani Nikula
---
drivers/gpu/dr
Add panel register/unregister functions, and handle backlight
register/unregister from there. This is in preparation for adding more
panel specific register/unregister functionality.
Cc: Lee Shawn C
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_connector.c| 23 +-
Use firmware node based lookups for panel followers, to make the code
independent of OF and device tree, and make it work also for ACPI with
an appropriate _DSD.
ASL example:
Package (0x02)
{
"panel", \_SB.PCI0.GFX0.LCD0
}
Suggested-by: Heikki Krogerus
Cc
The __mock_request_alloc() implements the smoketest->request_alloc()
function pointer. It's called from __igt_breadcrumbs_smoketest().
It's supposed to return error pointers, and returning NULL will lead to
a NULL pointer dereference.
Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs wit
Le 05/06/2025 à 17:24, Thomas Zimmermann a écrit :
The vblank timer simulates a vblank interrupt for hardware without
support. Rate-limits the display update frequency.
DRM drivers for hardware without vblank support apply display updates
ASAP. A vblank event informs DRM clients of the comple
Some users of DRM bridges may need to execute specific code just before
deallocation.
As of now the only known user would be KUnit tests.
Suggested-by: Maxime Ripard
Acked-by: Maxime Ripard
Signed-off-by: Luca Ceresoli
---
Changes in v9:
- move .destroy before .detach in struct drm_bridge_fun
Add KUnit tests for the newly introduced devm_drm_bridge_alloc().
Signed-off-by: Luca Ceresoli
---
Changed in v9:
- fold drm_bridge_alloc_test_ctx into drm_bridge_init_priv (do not
introduce another test context struct specific to alloc tests)
- use the existing func sets for .destroy (do
Use the new DRM bridge allocation API, which is the only supported now, for
the kunit tests.
This change is more massive than for the typical DRM bridge driver because
struct drm_bridge_init_priv currently embeds a struct drm_bridge, which is
not supported anymore. We now have to use devm_drm_brid
This small series adds a few kunit tests for the new DRM bridge allocation
flow, based on the recently introduced devm_drm_bridge_alloc() [0].
It is part of the work towards removal of bridges from a still existing DRM
pipeline without use-after-free.
The steps in the grand plan [1] are:
1. ➜ a
From: Baihan Li
When hibmc loaded failed, the driver use hibmc_unload to free the
resource, but the mutexes in mode.config are not init, which will
access an NULL pointer.
Fixes: b3df5e65cc03 ("drm/hibmc: Drop drm_vblank_cleanup")
Reported-by:oushixiong1...@163.com
Signed-off-by: Baihan Li
---
Currently, we pick the MMIO offset based on the size of the pgoff_t
type seen by the process that manipulates the FD, such that a 32-bit
process can always map the user MMIO ranges. But this approach doesn't
work well for emulators like FEX, where the emulator is a 64-bit binary
which might be exec
Hello,
This is an attempt a couple bugs exposed by FEX-Emu. The first one
is pretty trivial and should be uncontroversial, since it's just
a missing padding field in one of our uAPI structs. We are getting
away with it on arm32 because of the alignment rules provided by
the Arm ABI, but x86 has re
drm_panthor_gpu_info::shader_present is currently automatically offset
by 4 byte to meet Arm's 32-bit/64-bit field alignment rules, but those
constraints don't stand on 32-bit x86 and cause a mismatch when running
an x86 binary in a user emulated environment like FEX. It's also
generally agreed tha
On Tue, Jun 03, 2025 at 02:26:03PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 02, 2025 at 01:13:29PM +0200, Maxime Ripard wrote:
>
> > > I can't operate kunit
> >
> > Why not?
>
> Too complicated. People have even wrecked tools/testing/selftests/ to
> the point that it is now nearly impossible t
Jason Gunthorpe writes:
>> tsm_unbind in vdevice_destroy:
>>
>> vdevice_destroy() ends up calling tsm_unbind() while holding only the
>> vdev_lock. At first glance, this seems unsafe. But in practice, it's
>> fine because the corresponding iommufd_device has already been destroyed
>> when
On Wed, 4 Jun 2025 17:45:44 +0200, Thomas Zimmermann wrote:
> Only sysfb drivers use drm_fb_build_fourcc_list(). Move the function
> to sysfb helpers and rename it accordingly. Update drivers and tests.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Wed, Jun 04, 2025 at 05:45:43PM +0200, Thomas Zimmermann wrote:
> Only sysfb drivers use drm_fb_build_fourcc_list(). The helper will
> be moved from format helpers to sysfb helpers. Moving the related
> tests to their own test suite.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/g
On Wed, Jun 04, 2025 at 05:45:42PM +0200, Thomas Zimmermann wrote:
> Export additional helpers from the format-helper library and open-code
> drm_fb_blit() in tests. Prepares for the removal of drm_fb_blit(). Only
> sysfb drivers use drm_fb_blit(). The function will soon be removed from
> format he
On Tue, May 27, 2025 at 10:40:49PM +0300, Jani Nikula wrote:
> On Tue, 27 May 2025, Maxime Ripard wrote:
> > On Tue, May 20, 2025 at 01:09:47PM +0300, Jani Nikula wrote:
> >>
> >> Maxime -
> >>
> >> I'm cutting a lot of context here. Not because I don't think it deserves
> >> an answer, but beca
1 - 100 of 102 matches
Mail list logo
