> From: Jason Gunthorpe
> Sent: Saturday, November 8, 2025 12:50 AM
>
> +enum batch_kind {
> + BATCH_CPU_MEMORY = 0,
> + BATCH_MMIO,
> +};
with 'CPU_MEMORY' (instead of plain 'MEMORY') implies future
support of 'DEV_MEMORY'?
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Saturday, November 8, 2025 12:50 AM
>
> When connected to VFIO, the only DMABUF exporter that is accepted, the
> move_notify callback will be made when VFIO wants to remove access to the
> MMIO. This is being called revoke.
>
> Wire up revoke to go through all the
> From: Jason Gunthorpe
> Sent: Saturday, November 8, 2025 12:50 AM
>
>
> @@ -2031,7 +2155,10 @@ int iopt_pages_rw_access(struct iopt_pages
> *pages, unsigned long start_byte,
> if ((flags & IOMMUFD_ACCESS_RW_WRITE) && !pages->writable)
> return -EPERM;
>
> - if (pages->
> From: Jason Gunthorpe
> Sent: Saturday, November 8, 2025 12:50 AM
>
> Once a DMABUF is revoked the domain will be unmapped under the pages
> mutex. Double unmapping will trigger a WARN, and mapping while revoked
> will fail.
>
> Check for revoked DMABUFs along all the map and unmap paths to re
On 11/20/25 08:41, Leon Romanovsky wrote:
> On Thu, Nov 20, 2025 at 08:08:27AM +0100, Christian König wrote:
>> On 11/19/25 20:31, Jason Gunthorpe wrote:
>>> On Wed, Nov 19, 2025 at 02:42:18PM +0100, Christian König wrote:
>>>
>>> + case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
>>> +
On 11/20/25 03:25, Matt Smith wrote:
Documentation/gpu/todo.rst lists to transition away from using
deprecated methods in drm_mipi_dsi.c, so migrating from
mipi_dsi_turn_on_peripheral to mipi_dsi_turn_on_peripheral_multi.
Used commit e139c0eb22ce ("drm/panel: mantix-mlaf057we51: transition
to mi
> From: Jason Gunthorpe
> Sent: Saturday, November 8, 2025 12:50 AM
>
> This function is used to establish the "private interconnect" between the
> VFIO DMABUF exporter and the iommufd DMABUF importer. This is
> intended to
> be a temporary API until the core DMABUF interface is improved to nativ
On 18/11/25 21:50, Maxime Ripard wrote:
On Tue, Nov 18, 2025 at 04:52:49PM +0200, Tomi Valkeinen wrote:
Hi,
On 18/11/2025 14:40, Maxime Ripard wrote:
Hi,
On Tue, Nov 18, 2025 at 05:22:49PM +0530, Harikrishna Shenoy wrote:
With the DBANC framework, the connector is no longer initialized in
On Thu, Nov 20, 2025 at 08:08:27AM +0100, Christian König wrote:
> On 11/19/25 20:31, Jason Gunthorpe wrote:
> > On Wed, Nov 19, 2025 at 02:42:18PM +0100, Christian König wrote:
> >
> > + case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
> > + dma->state = kzalloc(sizeof(*dma->stat
On Thu, Nov 20, 2025 at 08:03:09AM +0100, Christian König wrote:
> On 11/19/25 17:33, Leon Romanovsky wrote:
> > On Wed, Nov 19, 2025 at 03:53:30PM +0100, Christian König wrote:
> >
> > <...>
> >
> >>> +struct sg_table *dma_buf_map(struct dma_buf_attachment *attach,
> >>
> >> That is
On 9/26/2025 7:23 PM, Dmitry Baryshkov wrote:
On Fri, Sep 26, 2025 at 02:29:54PM +0530, Mani Chandana Ballary Kuntumalla
wrote:
Add device tree nodes for the mdss1 DPTX0 and DPTX1 controllers
with their corresponding PHYs.
Signed-off-by: Mani Chandana Ballary Kuntumalla
---
arch/arm64/bo
On 9/26/2025 7:21 PM, Dmitry Baryshkov wrote:
On Fri, Sep 26, 2025 at 02:29:53PM +0530, Mani Chandana Ballary Kuntumalla
wrote:
The Qualcomm SA8775P platform comes with 2 DisplayPort controllers
for each mdss. Update controller id for DPTX0 and DPTX1 of mdss1.
Signed-off-by: Mani Chandana B
On 10/18/2025 4:21 AM, Bjorn Andersson wrote:
On Fri, Sep 26, 2025 at 02:29:52PM +0530, Mani Chandana Ballary Kuntumalla
wrote:
This series adds the DPTX0 and DPTX1 nodes, as a part of mdss1
on Qualcomm lemans SoC. It also enables Display Port on Qualcomm
lemans-ride platform.
---
The Devic
On 11/19/25 20:31, Jason Gunthorpe wrote:
> On Wed, Nov 19, 2025 at 02:42:18PM +0100, Christian König wrote:
>
> + case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
> + dma->state = kzalloc(sizeof(*dma->state), GFP_KERNEL);
> + if (!dma->state) {
> + ret = -ENOM
On 11/19/25 17:33, Leon Romanovsky wrote:
> On Wed, Nov 19, 2025 at 03:53:30PM +0100, Christian König wrote:
>
> <...>
>
>>> +struct sg_table *dma_buf_map(struct dma_buf_attachment *attach,
>>
>> That is clearly not a good name for this function. We already have
>> overloaded the
Dear Kuba,
Thanks for your efforts.
On 11/16/25 2:47 PM, Kuba Szczodrzyński wrote:
> Some Allwinner chips (notably the D1s/T113 and the A100) have a "combo
> MIPI DSI D-PHY" which is required when using single-link LVDS0.
>
> In this mode, the DSI peripheral is not used and the PHY is not
> conf
On 11/20/25 16:53, Matthew Brost wrote:
> On Thu, Nov 20, 2025 at 02:58:58PM +1100, Balbir Singh wrote:
>> On 11/20/25 14:15, Matthew Brost wrote:
>>> On Thu, Nov 20, 2025 at 01:59:09PM +1100, Balbir Singh wrote:
On 11/20/25 13:50, Balbir Singh wrote:
> On 11/20/25 13:40, Matthew Brost wro
On Thu, Nov 20, 2025 at 02:58:58PM +1100, Balbir Singh wrote:
> On 11/20/25 14:15, Matthew Brost wrote:
> > On Thu, Nov 20, 2025 at 01:59:09PM +1100, Balbir Singh wrote:
> >> On 11/20/25 13:50, Balbir Singh wrote:
> >>> On 11/20/25 13:40, Matthew Brost wrote:
> On Wed, Nov 12, 2025 at 10:52:43
[...]>>>
>>> How'd it go?
>>>
>
> My apologies for the delay—I got distracted by other tasks in Xe (my
> driver) and was out for a bit. Unfortunately, this series breaks
> something in the existing core MM code for the Xe SVM implementation. I
> have an extensive tes
On Thu, Nov 20, 2025 at 10:58:07AM +1100, Balbir Singh wrote:
> On 11/19/25 23:32, Dan Carpenter wrote:
> > Hi Balbir,
> >
> > kernel test robot noticed the following build warnings:
> >
> > url:
> > https://github.com/intel-lab-lkp/linux/commits/Balbir-Singh/mm-huge_memory-c-introduce-folio_
On Thu, Nov 20, 2025 at 11:09:09AM +0900, Byungchul Park wrote:
> On Wed, Nov 19, 2025 at 02:37:17PM +, Matthew Wilcox wrote:
> > On Wed, Nov 19, 2025 at 07:53:12PM +0900, Byungchul Park wrote:
> > > On Thu, Oct 02, 2025 at 05:12:44PM +0900, Byungchul Park wrote:
> > > > False positive reports
On 11/20/25 14:15, Matthew Brost wrote:
> On Thu, Nov 20, 2025 at 01:59:09PM +1100, Balbir Singh wrote:
>> On 11/20/25 13:50, Balbir Singh wrote:
>>> On 11/20/25 13:40, Matthew Brost wrote:
On Wed, Nov 12, 2025 at 10:52:43AM +1100, Balbir Singh wrote:
> On 11/12/25 10:43, Andrew Morton wro
Thermal zone devices currently have no parent device, potentially
causing issues with suspend ordering and making it impossible for
user space appications to associate a given thermal zone device with
its parent device.
Extend the functions used to register thermal zone devices to also
accept a pa
The thermal core will soon automatically create sysfs links between
the cooling device and its parent device. Stop manually creating
the "device" sysfs link between the cooling device and the parent
device to avoid a name collision. The "thermal_cooling" sysfs link
however stays for backwards compa
Extend thermal_cooling_device_register() to allow users to specify
the parent device of the cooling device to be created.
Signed-off-by: Armin Wolf
---
Documentation/driver-api/thermal/sysfs-api.rst | 5 -
drivers/acpi/acpi_video.c | 2 +-
drivers/acpi/
The thermal core will soon automatically create sysfs links between
the thermal zone device and its parent device. Stop manually creating
the "device" sysfs link between the thermal zone device and the parent
device to avoid a name collision. The "thermal_zone" sysfs link
however stays for backward
The thermal core will soon automatically create sysfs links between
the cooling device and its parent device. Stop manually creating
the "device" sysfs link between the cooling device and the parent
device to avoid a name collision. The "thermal_cooling" sysfs link
however stays for backwards compa
Drivers registering thermal zone/cooling devices are currently unable
to tell the thermal core what parent device the new thermal zone/
cooling device should have, potentially causing issues with suspend
ordering and making it impossible for user space appications to
associate a given thermal zone
Currently, cooling devices have no parent device, potentially causing
issues with suspend ordering and making it impossible for consumers
(thermal zones and userspace appications) to associate a given cooling
device with its parent device.
Extend __thermal_cooling_device_register() to also accept
The thermal core will soon automatically create sysfs links between
the cooling device and its parent device. Stop manually creating
the "device" sysfs link between the cooling device and the parent
device to avoid a name collision. The "thermal_cooling" sysfs link
however stays for backwards compa
Extend thermal_of_cooling_device_register() to allow users to specify
the parent device of the cooling device to be created.
Signed-off-by: Armin Wolf
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 ++--
drivers/thermal/cpufreq_cooling.c | 2 +-
drivers/thermal/cpuidle_cooling.c | 2 +-
d
On Thu, Nov 20, 2025 at 01:59:09PM +1100, Balbir Singh wrote:
> On 11/20/25 13:50, Balbir Singh wrote:
> > On 11/20/25 13:40, Matthew Brost wrote:
> >> On Wed, Nov 12, 2025 at 10:52:43AM +1100, Balbir Singh wrote:
> >>> On 11/12/25 10:43, Andrew Morton wrote:
> On Thu, 9 Oct 2025 03:33:33 -070
On Tue, Nov 18, 2025 at 01:18:41PM -0700, Jim Cromie wrote:
> diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst
> b/Documentation/admin-guide/dynamic-debug-howto.rst
> index 1ceadf4f28f9..adac32a5cd23 100644
> --- a/Documentation/admin-guide/dynamic-debug-howto.rst
> +++ b/Documentati
Code refactoring of __folio_split() via helper
__folio_freeze_and_split_unmapped() caused a regression with clang-20
with CONFIG_SHMEM=n, the compiler was not able to optimize away the
call to shmem_uncharge() due to changes in nr_shmem_dropped.
Fix this by checking for shmem_mapping() prior to cal
On 11/20/25 13:50, Balbir Singh wrote:
> On 11/20/25 13:40, Matthew Brost wrote:
>> On Wed, Nov 12, 2025 at 10:52:43AM +1100, Balbir Singh wrote:
>>> On 11/12/25 10:43, Andrew Morton wrote:
On Thu, 9 Oct 2025 03:33:33 -0700 Matthew Brost
wrote:
This patch series introduces
On 11/20/25 13:40, Matthew Brost wrote:
> On Wed, Nov 12, 2025 at 10:52:43AM +1100, Balbir Singh wrote:
>> On 11/12/25 10:43, Andrew Morton wrote:
>>> On Thu, 9 Oct 2025 03:33:33 -0700 Matthew Brost
>>> wrote:
>>>
>>> This patch series introduces support for Transparent Huge Page
>>> (THP
On Wed, Nov 19, 2025 at 12:41:52PM +0200, Tomi Valkeinen wrote:
> On 19/11/2025 11:19, Maxime Ripard wrote:
> > On Tue, Nov 18, 2025 at 07:10:47PM +0100, Linus Walleij wrote:
> >> On Tue, Nov 18, 2025 at 4:44 PM Maxime Ripard wrote:
> >>> On Tue, Nov 18, 2025 at 05:01:28PM +0200, Laurent Pinchart
On Wed, Nov 12, 2025 at 10:52:43AM +1100, Balbir Singh wrote:
> On 11/12/25 10:43, Andrew Morton wrote:
> > On Thu, 9 Oct 2025 03:33:33 -0700 Matthew Brost
> > wrote:
> >
> > This patch series introduces support for Transparent Huge Page
> > (THP) migration in zone device-private memory.
On Thu, Nov 20, 2025 at 11:09:09AM +0900, Byungchul Park wrote:
> On Wed, Nov 19, 2025 at 02:37:17PM +, Matthew Wilcox wrote:
> > On Wed, Nov 19, 2025 at 07:53:12PM +0900, Byungchul Park wrote:
> > > On Thu, Oct 02, 2025 at 05:12:44PM +0900, Byungchul Park wrote:
> > > > False positive reports
From: Chaoyi Chen
The RK3399 EVB IND board has a Type-C interface DisplayPort.
It use fusb302 chip as Type-C controller.
fusb302 chip ---> USB/DP PHY0 <> CDN-DP controller
Signed-off-by: Chaoyi Chen
---
(no changes since v10)
Changes in v9:
- Add usb role switch for Type-C.
- Remove USB2
From: Chaoyi Chen
Let's make the ports nodes of cdn_dp in the same style as the other
display interface, and match the style of ports's yaml.
Signed-off-by: Chaoyi Chen
---
(no changes since v5)
Changes in v4:
- Remove unnecessary #address/#size-cells
(no changes since v1)
arch/arm64/boot/
From: Chaoyi Chen
The drm_aux_bridge_register() uses the device->of_node as the
bridge->of_node.
This patch adds drm_aux_bridge_register_from_node() to allow
specifying the of_node corresponding to the bridge.
Signed-off-by: Chaoyi Chen
---
drivers/gpu/drm/bridge/aux-bridge.c | 24 +++
From: Chaoyi Chen
The RK3399 has two USB/DP combo PHY and one CDN-DP controller. And
the CDN-DP can be switched to output to one of the PHYs. If both ports
are plugged into DP, DP will select the first port for output.
This patch adds support for multiple bridges, enabling users to flexibly
sele
From: Chaoyi Chen
This patch add support for Type-C Port Controller Manager. Each PHY
will register typec_mux and typec_switch when external Type-C
controller is present. Type-C events are handled by TCPM without
extcon.
The extcon device should still be supported.
Signed-off-by: Chaoyi Chen
-
From: Chaoyi Chen
The HPD function of Type-C DP is implemented through
drm_connector_oob_hotplug_event(). For embedded DP, it is required
that the DRM connector fwnode corresponds to the Type-C port fwnode.
To describe the relationship between the DP controller and the Type-C
port device, we usu
From: Chaoyi Chen
This series focuses on adding Type-C DP support for USBDP PHY and DP
driver. The USBDP PHY and DP will perceive the changes in cable status
based on the USB PD and Type-C state machines provided by TCPM. Before
this, the USBDP PHY and DP controller of RK3399 sensed cable state
c
From: Chaoyi Chen
Some other part of kernel may want to know the event of typec bus.
This patch add common notifier function to notify these event.
Signed-off-by: Chaoyi Chen
---
Changes in v10:
- Notify TYPEC_ALTMODE_UNREGISTERED when altmode removed.
Changes in v9:
- Remove redundant head
On Wed, Nov 19, 2025 at 02:37:17PM +, Matthew Wilcox wrote:
> On Wed, Nov 19, 2025 at 07:53:12PM +0900, Byungchul Park wrote:
> > On Thu, Oct 02, 2025 at 05:12:44PM +0900, Byungchul Park wrote:
> > > False positive reports have been observed since dept works with the
> > > assumption that all t
On Wed, Nov 19, 2025 at 01:12:08AM -0700, [email protected] wrote:
> On Tue, Nov 18, 2025 at 6:35 PM Bagas Sanjaya wrote:
> > What commit/tree this series is based on?
> >
>
> this is on top of v6.17
> dynamic-debug has been unchanged since then
Pulled for review, thanks!
--
An old man doll
On Wed, Nov 19, 2025 at 06:00:55PM +0100, Marek Vasut wrote:
> On 11/16/25 1:20 PM, Shawn Guo wrote:
> > On Sun, Nov 02, 2025 at 05:09:07PM +0100, Marek Vasut wrote:
> > > The instance of the GPU populated in i.MX95 is the G310, describe this
> > > GPU in the DT. Include dummy GPU voltage regulator
On Wed, 19 Nov 2025 22:40:56 + [email protected] wrote:
> I've had to trim the 124 maintainers/lists that get_maintainer.pl finds
> from 124 to under 100 to be able to send the cover letter.
> The individual patches only go to the addresses found for the associated
> files.
> That r
Hi Dmitry,
> -Original Message-
> From: Dmitry Osipenko
> Sent: Friday, November 14, 2025 5:16 AM
> To: Kim, Dongwon ; dri-
> [email protected]
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH v6 3/3] drm/virtio: Add PM notifier to restore ob
Hi,
On Tue, Nov 18, 2025 at 5:41 AM Konrad Dybcio
wrote:
>
> > Yes, there is only one firmware, which crosshatch has different, but all
> > listed in the initial bringup are used for both.
> >
> > To add, crosshatch was somehow not that popular device, so as I've been
> > suggested in u-boot di
On 19 Nov 2025, at 18:58, Balbir Singh wrote:
> On 11/19/25 23:32, Dan Carpenter wrote:
>> Hi Balbir,
>>
>> kernel test robot noticed the following build warnings:
>>
>> url:
>> https://github.com/intel-lab-lkp/linux/commits/Balbir-Singh/mm-huge_memory-c-introduce-folio_split_unmapped/20251114
Userptr resides in host memory, and PCIe writes involve cache coherence.
By using SDMA to copy GTT to VRAM and then verifying the values in VRAM, we can
validate GTT cache coherence.
Bo(Userptr) > SDMA ---> Bo(userptr) sdma-> VRAM
Signed-off-by: zhangzhijie
---
tests/amdgpu/basic_t
From: Guido Günther
With other probing issues out of the way (by marking LCD_1V8 always on)
it turns out we can't use either touch or DSI until we pulled both RESX
and TP_RSTN¹ so instead of guessing wait until the panel is up.
This replaces one hack (probe defers) by another (more reliable) one
Hello, good morning. I'm trying to get my old tablet working properly on
Debian, but I've had to add some fixes.
Here's a commit I created to like the Acer Switch One 10 S1003, for which
there already is a quirk, the Acer Switch 10 (SW1-011) has a 800x1280
portrait screen mounted in the tablet part
From: Martin Kepplinger
and use that header in the touchscreen driver. This avoids:
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c:45:6: error: no previous
prototype for 'mantix_panel_prepared' [-Werror=missing-prototypes]
45 | bool mantix_panel_prepared(void)
| ^~~~
From: Guido Günther
This will be used by the touch controller.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-man
hi,
When there's a panel/touchscreen combination that is sold as a combinded
module (with the reset line shared even), how would I connect the 2
drivers and make sure the touchscreen driver probes after the panel is ready?
I have the feeling there is https://docs.kernel.org/driver-api/device_link
Hi Piotr,
On 11/18/2025 10:50 PM, Piotr Oniszczuk wrote:
[You don't often get email from [email protected]. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
[ EXTERNAL EMAIL ]
Ao,
Is there any chance to get this s4 drm hdmi series for current 6.18?
(i
From: Martin Kepplinger
Until we have a better solution, we need the touchscreen driver to
wait for the panel to be prepared, before it can continue to
execute probe().
A better driver is needed, so this is marked as a hack.
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 1 +
1 file ch
From: Shaurya Rane
syzbot reported a vmalloc-out-of-bounds write in fb_imageblit. The crash
occurs when drawing an image at the very end of the framebuffer memory.
The current bounds check in fb_imageblit limits the drawing height (max_y)
by dividing the screen size by the line length. However,
On 11/19/25 23:32, Dan Carpenter wrote:
> Hi Balbir,
>
> kernel test robot noticed the following build warnings:
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Balbir-Singh/mm-huge_memory-c-introduce-folio_split_unmapped/20251114-093541
> base: https://git.kernel.org/pub/scm/linu
Hi, Dave & Sima:
This includes:
1. Fix probe resource leaks
2. Add support for MT8195/88 HDMIv2 and DDCv2
3. Fix CCORR mtk_ctm_s31_32_to_s1_n function issue
4. Fix device node reference leak in mtk_dp_dt_parse()
Regards,
Chun-Kuang.
The following changes since commit 3a8660878839faadb4f1a6dd72c3
Hi Chris,
On Tue, 18 Nov 2025 21:27:43 -0500
Chris Brandt wrote:
> Convert the limited MIPI clock calculations to a full range of settings
> based on math including H/W limitation validation.
> Since the required DSI division setting must be specified from external
> sources before calculations,
From: David Laight
It in not uncommon for code to use min_t(uint, a, b) when one of a or b
is 64bit and can have a value that is larger than 2^32;
This is particularly prevelant with:
uint_var = min_t(uint, uint_var, uint64_expression);
Casts to u8 and u16 are very likely to discard sign
From: David Laight
min_t(unsigned int, a, b) casts an 'unsigned long' to 'unsigned int'.
Use min(a, b) instead as it promotes any 'unsigned int' to 'unsigned long'
and so cannot discard significant bits.
min_t(u8, a, b) is particularly likely to be problematic
In this case I think the values ar
From: Chris Morgan
Add support for the HDMI port for the Gameforce Ace. The HDMI port
has no HPD pin present (the manufacturer's devicetree states the pin
is reused for an additional face button) so add the attribute of
no-hpd to poll for connected devices.
Signed-off-by: Chris Morgan
---
.../
From: Chris Morgan
Add an attribute of "no-hpd" for the Rockchip dw-hdmi-qp controller.
This is used to describe implementations where the HPD pin is not
connected or used for other purposes, such as in the RK3588S based
Gameforce Ace which repurposed the GPIO for an additional face
button.
The
From: Chris Morgan
Add support for the dw-hdmi-qp driver to handle devices with missing
HPD pins.
Since in this situation we are now polling for the EDID data via i2c
change the error message to a rate limited debug message when we are
unable to complete an i2c read, as a disconnected device wou
From: Chris Morgan
Add support for the micro HDMI port for the Gameforce Ace. This port does
not have a HPD pin so it requires making changes to the HDMI controller
to support this configuration.
Changes since v1:
- Simplified checking of no-hpd parameter and changed to
device_property_read_
Use new pending job list iterator and new helper functions in Xe to
avoid reaching into DRM scheduler internals.
Part of this change involves removing pending jobs debug information
from debugfs and devcoredump. As agreed, the pending job list should
only be accessed when the scheduler is stopped.
If the firmware is not running during TDR (e.g., when the driver is
unloading), there's no need to toggle scheduling in the GuC. In such
cases, skip this step.
v4:
- Bail on wait UC not running (Niranjana)
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_guc_submit.c | 3 ++-
1 file chan
We now have proper infrastructure to accurately check the LRC timestamp
without toggling the scheduling state for non-VFs. For VFs, it is still
possible to get an inaccurate view if the context is on hardware. We
guard against free-running contexts on VFs by banning jobs whose
timestamps are not mo
Now that LR jobs are tracked by the DRM scheduler, there's no longer a
need to special-case LR queues. This change removes all LR
queue-specific handling, including dedicated TDR logic, reference
counting schemes, and other related mechanisms.
v4:
- Remove xe_exec_queue_lr_cleanup tracepoint (Nir
Stop open coding pending job list in drivers. Add pending job list
iterator which safely walks DRM scheduler list asserting DRM scheduler
is stopped.
v2:
- Fix checkpatch (CI)
v3:
- Drop locked version (Christian)
v4:
- Reorder patch (Niranjana)
Signed-off-by: Matthew Brost
---
include/drm/g
At XDC, we discussed that drivers should avoid accessing DRM scheduler
internals, misusing DRM scheduler locks, and adopt a well-defined
pending job list iterator. This series proposes the necessary changes to
the DRM scheduler to bring Xe in line with that agreement and updates Xe
to use the new D
Deregistering queues in the TDR introduces unnecessary complexity,
requiring reference-counting techniques to function correctly,
particularly to prevent use-after-free (UAF) issues while a
deregistration initiated from the TDR is in progress.
All that's needed in the TDR is to kick the queue off
Stop abusing DRM scheduler job list lock for messages, add dedicated
message lock.
Signed-off-by: Matthew Brost
Reviewed-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/xe/xe_gpu_scheduler.c | 5 +++--
drivers/gpu/drm/xe/xe_gpu_scheduler.h | 4 ++--
drivers/gpu/drm/xe/xe_gpu_sched
Add helpers to see if scheduler is stopped and a jobs signaled state.
Expected to be used driver side on recovery and debug flows.
v4:
- Reorder patch to first in series (Niranjana)
- Also check parent fence for signaling (Niranjana)
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/
Hello!
> This patch replaces the insufficient check with a more precise one. It
> calculates the effective width in bytes of the image (accounting for
> clipping against xres_virtual) and ensures that the last byte of the
> operation falls within the screen buffer. Specifically, it checks if
> '(d
Hi Kamil,
On 11/19/25 3:21 PM, Kamil Konieczny wrote:
> Hi Cristian,
> On 2025-11-10 at 15:18:05 +0200, Cristian Ciocaltea wrote:
>> Provide test to verify the behavior of BACKGROUND_COLOR DRM CRTC
>> property.
>>
>> This is done by filling a full-screen primary plane with a given color
>> and com
On Wed, Nov 19, 2025 at 03:31:14PM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 19, 2025 at 02:42:18PM +0100, Christian König wrote:
<...>
> So thanks, we can take the Acked-by and progress here. Interested
> parties can pick it up from this point when time allows.
Christian,
Can you please prov
On Wed, Nov 19, 2025 at 03:41:20PM -0400, Jason Gunthorpe wrote:
> On Tue, Nov 18, 2025 at 11:56:14PM +, Tian, Kevin wrote:
> > > > > + down_write(&vdev->memory_lock);
> > > > > + list_for_each_entry_safe(priv, tmp, &vdev->dmabufs, dmabufs_elm)
> > > > > {
> > > > > + if (!g
On Wed, Nov 19, 2025 at 03:45:06PM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 19, 2025 at 03:06:18PM +0100, Christian König wrote:
> > On 11/19/25 14:35, Jason Gunthorpe wrote:
> > > On Wed, Nov 19, 2025 at 10:18:08AM +0100, Christian König wrote:
> > >>> +As this is not well-defined or well-suppo
Hi Chris,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dd30a345f284e0d9b1755e3538f8257cf4deb79f]
url:
https://github.com/intel-lab-lkp/linux/commits/Chris-Brandt/clk-renesas-rzg2l-Remove-DSI-clock-rate-restrictions/20251119-103032
base
Add initial declarations for the drm_xe_vm_get_property ioctl.
v2:
- Expand kernel docs for drm_xe_vm_get_property (Jianxun)
v3:
- Remove address type external definitions (Jianxun)
- Add fault type to xe_drm_fault struct (Jianxun)
v4:
- Remove engine class and instance (Ivan)
v5:
- Add declare
Add additional information to each VM so they can report up to the first
50 seen faults. Only pagefaults are saved this way currently, though in
the future, all faults should be tracked by the VM for future reporting.
Additionally, of the pagefaults reported, only failed pagefaults are
saved this
Add support for userspace to request a list of observed faults
from a specified VM.
v2:
- Only allow querying of failed pagefaults (Matt Brost)
v3:
- Remove unnecessary size parameter from helper function, as it
is a property of the arguments. (jcavitt)
- Remove unnecessary copy_from_user (Jain
The page fault handler should reject write/atomic access to read only
VMAs. Add code to handle this in xe_pagefault_service after the VMA
lookup.
Fixes: fb544b844508 ("drm/xe: Implement xe_pagefault_queue_work")
Signed-off-by: Jonathan Cavitt
Suggested-by: Matthew Brost
Cc: Shuicheng Lin
---
Add additional information to each VM so they can report up to the first
50 seen faults. Only pagefaults are saved this way currently, though in
the future, all faults should be tracked by the VM for future reporting.
Additionally, of the pagefaults reported, only failed pagefaults are
saved this
te
of_drm_find_bridge() and replace it with a function that increments the
refcount, then let the various callers move to the new function over time.
Earlier today I sent a series doing that, and converting lots of users
[1]. If/when that approach will be accepted, you can update your driver to
use t
On Wed, Nov 19, 2025 at 03:06:18PM +0100, Christian König wrote:
> On 11/19/25 14:35, Jason Gunthorpe wrote:
> > On Wed, Nov 19, 2025 at 10:18:08AM +0100, Christian König wrote:
> >>> +As this is not well-defined or well-supported in real HW the kernel
> >>> defaults to
> >>> +blocking such routin
On Tue, Nov 18, 2025 at 11:56:14PM +, Tian, Kevin wrote:
> > > > + down_write(&vdev->memory_lock);
> > > > + list_for_each_entry_safe(priv, tmp, &vdev->dmabufs, dmabufs_elm)
> > > > {
> > > > + if (!get_file_active(&priv->dmabuf->file))
> > > > +
On Wed, Nov 19, 2025 at 03:11:01PM +0100, Christian König wrote:
> I miss interpreted the call to pci_p2pdma_map_type() here in that
> now the DMA-buf code decides if transactions go over the root
> complex or not.
Oh, that's not it at all. I think you get it, but just to be really
clear:
This c
On Wed, Nov 19, 2025 at 02:42:18PM +0100, Christian König wrote:
> >>> + case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
> >>> + dma->state = kzalloc(sizeof(*dma->state), GFP_KERNEL);
> >>> + if (!dma->state) {
> >>> + ret = -ENOMEM;
> >>> + goto err_free_dma;
On Tue, Nov 11, 2025 at 05:43:55PM +0100, Thomas Hellström wrote:
> Pagemaps are costly to set up and tear down, and they consume a lot
> of system memory for the struct pages. Ideally they should be
> created only when needed.
>
> Add a caching mechanism to allow doing just that: Create the drm_p
> This function gets a device_node reference via
> of_graph_get_remote_port_parent() and stores it in encoder_node, but necer
never?
> puts that reference. Add it.
…
> +++ b/drivers/gpu/drm/tiny/arcpgu.c
> @@ -250,7 +250,8 @@
On Wed, Nov 19, 2025 at 07:49:23PM +0200, Cristian Ciocaltea wrote:
> On 11/19/25 6:24 PM, Chris Morgan wrote:
> > On Wed, Nov 19, 2025 at 10:02:23AM +0100, Maxime Ripard wrote:
> >> On Tue, Nov 18, 2025 at 02:36:09PM -0600, Chris Morgan wrote:
> >>> On Tue, Nov 18, 2025 at 09:46:04AM +0100, Maxime
1 - 100 of 238 matches
Mail list logo
