On 19/08/2025 07:52, Kumar, Udit wrote:
>
> I would expect driver changes as well, which should come before device tree.
Stop advising this nonsense.
Best regards,
Krzysztof
On 19/08/2025 06:54, Kumar, Udit wrote:
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
>> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
>> index 1ac1f0219079..65f486f2bc9d 100644
>> --- a/Documentation/devicetree/bindings/display/panel/p
On 18/08/2025 17:47, Harikrishna Shenoy wrote:
> Add RPi DSI panel[0] as a valid compatible for simple-panel.
>
> [0]: https://www.raspberrypi.com/products/raspberry-pi-touch-display/
>
> Signed-off-by: Harikrishna Shenoy
> ---
Please use subject prefixes matching the subsystem. You can get th
On Tue, 19 Aug 2025 07:31:14 +0200, Mike Looijmans wrote:
> Add DT binding document for TI TMDS181 and SN65DP159 HDMI retimers.
>
> Signed-off-by: Mike Looijmans
>
> ---
>
> Changes in v2:
> Document driver specific bindings like slew-rate and threshold
>
> .../bindings/display/bridge/ti,tm
On 8/18/2025 9:17 PM, Harikrishna Shenoy wrote:
From: Rahul T R
TI's J721E SoC supports a DPI to DSI video signal conversion bridge on
it's platform bus. The IP is from Cadence, and it has a custom TI
wrapper around it to facilitate integration.
This IP takes the DPI video signals from DSS a
On 8/19/2025 10:24 AM, Kumar, Udit wrote:
>
> On 8/18/2025 9:17 PM, Harikrishna Shenoy wrote:
>> Add RPi DSI panel[0] as a valid compatible for simple-panel.
>>
>> [0]: https://www.raspberrypi.com/products/raspberry-pi-touch-display/
$subject has typo s/dsiplay/display and s/dsi/DSI
(use a spe
From: Matthew Wilcox
Remove aux_idr_mutex by converting aux_idr to an XArray.
Signed-off-by: Matthew Wilcox
Signed-off-by: Sidhartha Kumar
---
drivers/gpu/drm/display/drm_dp_aux_dev.c | 38 ++--
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/dr
From: Matthew Wilcox
Remove syncobj_table_lock by converting the syncobj_idr to an XArray.
Signed-off-by: Matthew Wilcox
Signed-off-by: Sidhartha Kumar
---
drivers/gpu/drm/drm_syncobj.c | 64 +++
include/drm/drm_file.h| 6 ++--
2 files changed, 22 inse
From: Matthew Wilcox
Part of the mass conversion of IDR users to the XArray API.
Signed-off-by: Matthew Wilcox
Signed-off-by: Sidhartha Kumar
---
drivers/gpu/drm/drm_auth.c | 4 +---
drivers/gpu/drm/drm_lease.c | 15 ++-
include/drm/drm_auth.h | 4 ++--
3 files changed, 9
On 8/18/2025 9:17 PM, Harikrishna Shenoy wrote:
Add RPi DSI panel[0] as a valid compatible for simple-panel.
[0]: https://www.raspberrypi.com/products/raspberry-pi-touch-display/
Signed-off-by: Harikrishna Shenoy
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
On 8/19/2025 10:46 AM, Raghavendra, Vignesh wrote:
On 8/19/2025 10:24 AM, Kumar, Udit wrote:
On 8/18/2025 9:17 PM, Harikrishna Shenoy wrote:
Add RPi DSI panel[0] as a valid compatible for simple-panel.
[0]: https://www.raspberrypi.com/products/raspberry-pi-touch-display/
$subject has typo
On 8/18/2025 9:17 PM, Harikrishna Shenoy wrote:
Add support for R-Pi DSI Panel for BBAI64.
The RPi DSI panel[0] uses Toshiba TC358762 for decoding the DSI video
signals back to DPI for its consumption. It has an ATTINY88-based
regulator and backlight controller, and also features an EDT-FT5406
From: Matthew Wilcox
Convert tile_idr to an Xarray.
Signed-off-by: Matthew Wilcox
Signed-off-by: Sidhartha Kumar
---
drivers/gpu/drm/drm_connector.c | 26 ++
drivers/gpu/drm/drm_mode_config.c | 3 +--
include/drm/drm_mode_config.h | 12 ++--
3 files chan
From: Sidhartha
This series is part of a project to depcrecate the IDR in favor
of the Xarray. This simplifies the code as locking is handled by
the Xarray internally and removes the need for a seperate mutex to
proect the IDR.
The patches are from this tree and have been rebased to drm-next-202
From: Matthew Wilcox
It's not possible to replace object_name_lock as it protects more
code than should be reasonably be run under a spinlock, so the xa_lock
is nested under the object_name_lock.
Signed-off-by: Matthew Wilcox
Signed-off-by: Sidhartha Kumar
---
drivers/gpu/drm/drm_debugfs.c |
From: Matthew Wilcox
Part of the mass conversion of IDR users to the XArray API.
Signed-off-by: Matthew Wilcox
Signed-off-by: Sidhartha Kumar
---
drivers/gpu/drm/drm_auth.c | 18 --
include/drm/drm_auth.h | 5 ++---
2 files changed, 10 insertions(+), 13 deletions(-)
diff
On Mon, Aug 18, 2025 at 9:37 PM payne.lin wrote:
>
Start the patch title with "drm/mediatek: ".
> From: Bincai Liu
>
> Updated the definition of AUX_RX_UI_CNT_THR_AUX_FOR_26M from 13 to 14.
> No other code or logic changes were made; only the macro value was modified.
> This change affects the
Add DT binding document for TI TMDS181 and SN65DP159 HDMI retimers.
Signed-off-by: Mike Looijmans
---
Changes in v2:
Document driver specific bindings like slew-rate and threshold
.../bindings/display/bridge/ti,tmds181.yaml | 143 ++
1 file changed, 143 insertions(+)
create
The tmds181 and sn65dp159 are "retimers" and hence can be considered
HDMI-to-HDMI bridges. Typical usage is to convert the output of an
FPGA into a valid HDMI signal, and it will typically be inserted
between an encoder and hdmi-connector.
Signed-off-by: Mike Looijmans
---
Changes in v2:
Use ato
In the past I've seen (and contributed to) hacks that model the chips as
phy or even (really!) clock drivers. Since the chip usually sits between
a signal that is (almost) HDMI and a HDMI connector, I decided to stop
lying and write it as a DRM bridge driver.
Our experience with these chips is t
Replace calls of devm_kzalloc() with devm_kcalloc() in led_bl_get_leds()
and led_bl_parse_levels() for safer memory allocation with built-in
overflow protection.
Signed-off-by: Qianfeng Rong
---
drivers/video/backlight/led_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
The Qualcomm QCS8300 platform comes with one DisplayPort controller
with same base offset as SM8650. But it requires new compatible string
because QCS8300 controller supports 4 MST streams. 4 MST streams will
be enabled as part of MST feature support. Currently, using SM8650 as
fallback to enable S
Add Mobile Display Subsystem (MDSS) support for the QCS8300 platform.
Signed-off-by: Yongxing Mou
---
drivers/gpu/drm/msm/msm_mdss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index
2d0e3e784c044db8ac0c478446d211a982cf0350
The QCS8300 supports UBWC 4.0 and 4 channels LP5 memory interface. Use
the SC8280XP as fallback for QCS8300 according to the specification.
Acked-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Yongxing Mou
---
drivers/soc/qcom/ubwc_config.c | 1 +
1 file changed, 1 insertion(
Document the MDSS hardware found on the Qualcomm QCS8300 platform.
Signed-off-by: Yongxing Mou
---
.../bindings/display/msm/qcom,qcs8300-mdss.yaml| 282 +
1 file changed, 282 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,qcs8300-mdss.yaml
Add compatible string for the DisplayPort controller found on the
Qualcomm QCS8300 SoC.
The Qualcomm QCS8300 platform comes with one DisplayPort controller
with same base offset as SM8650. But it requires new compatible string
because QCS8300 controller supports 4 MST streams. 4 MST streams will
b
Document the DPU for Qualcomm QCS8300 platform. It use the same DPU
hardware with SA8775P and reuse it's driver.
Signed-off-by: Yongxing Mou
---
.../devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/Document
---
Changes in v7: Fixed review comments from Dmitry.
- Rebase to next-20250818 and 4 pixel stream series V6.
- Add more description for the dp-controller dt-bingding change.[Dmitry]
- Reorder the MDSS change and UBWC change.[Dmitry]
- Switch to the OSS email.
- Link to v6:
https://lore.kernel.org/r
Hello,
kernel test robot noticed "BUG:unable_to_handle_page_fault_for_address" on:
commit: 1ba20479196e5af3ebbedf9321de6b26f2a0cdd3 ("[PATCH 19/19] perf:
Garbage-collect event_init checks")
url:
https://github.com/intel-lab-lkp/linux/commits/Robin-Murphy/perf-arm-cmn-Fix-event-validation/202
To support high-resolution cases that exceed the width limitation of
a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate,
additional pipes are necessary to enable parallel data processing
within the SSPP width constraints and MDP clock rate.
Request 4 mixers and 4 DSCs for high-r
The content of every half of screen is sent out via one interface in
dual-DSI case. The content for every interface is blended by a LM
pair in quad-pipe case, thus a LM pair should not blend any content
that cross the half of screen in this case. Clip plane into pipes per
left and right half screen
Currently, SSPPs are assigned to a maximum of two pipes. However,
quad-pipe usage scenarios require four pipes and involve configuring
two stages. In quad-pipe case, the first two pipes share a set of
mixer configurations and enable multi-rect mode when certain
conditions are met. The same applies
Currently, only 2 pipes are used at most for a plane. A stage structure
describes the configuration for a mixer pair. So only one stage is needed
for current usage cases. The quad-pipe case will be added in future and 2
stages are used in the case. So extend the stage to an array with array
size ST
Currently MAX_CHANNELS_PER_ENC is defined as 2, because 2 channels are
supported at most in one encoder. The case of 4 channels per encoder is
to be added. To avoid breaking current WB usage case, use dedicated WB
definition before 4 WB usage case is supported in future.
Signed-off-by: Jun Nie
Re
The stage contains configuration for a mixer pair. Currently the plane
supports just one stage and 2 pipes. Quad-pipe support will require
handling 2 stages and 4 pipes at the same time. In preparation for that
add a separate define, PIPES_PER_PLANE, to denote number of pipes that
can be used by th
There are 2 pipes in a drm plane at most currently, while 4 pipes are
required for quad-pipe case. Generalize the handling to pipe pair and
ease handling to another pipe pair later. Store pipes in array with
removing dedicated r_pipe.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed
Add pipe as trace argument in trace_dpu_crtc_setup_mixer() to ease
converting pipe into pipe array later.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
Current code only supports usage cases with one pair of mixers at
most. To support quad-pipe usage case, two pairs of mixers need to
be reserved. The lm_count for all pairs is cleared if a peer
allocation fails in current implementation. Reset the current lm_count
to an even number instead of compl
There are 2 interfaces and 4 pingpong in quad pipe. Map the 2nd
interface to 3rd PP instead of the 2nd PP.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
1 file changed, 8 insertions(+), 2 deletio
Currently, only one pair of mixers is supported, so a non-zero counter
value is sufficient to identify the correct mixer within that pair.
However, future implementations may involve multiple mixer pairs. With
the current implementation, all mixers within the second pair would be
incorrectly select
Current code will validate current plane and previous plane to
confirm they can share a SSPP with multi-rect mode. The SSPP
is already allocated for previous plane, while current plane
is not associated with any SSPP yet. Null pointer is referenced
when validating the SSPP of current plane. Skip SS
It is more likely that resource allocation may fail in complex usage
case, such as quad-pipe case, than existing usage cases.
A resource type ID is printed on failure in the current implementation,
but the raw ID number is not explicit enough to help easily understand
which resource caused the fail
2 or more SSPPs and dual-DSI interface are need for super wide panel.
And 4 DSC are preferred for power optimal in this case due to width
limitation of SSPP and MDP clock rate constrain. This patch set
extends number of pipes to 4 and revise related mixer blending logic
to support quad pipe. All th
On Mon, Aug 18, 2025 at 09:17:44PM +0530, Harikrishna Shenoy wrote:
> Add RPi DSI panel[0] as a valid compatible for simple-panel.
>
> [0]: https://www.raspberrypi.com/products/raspberry-pi-touch-display/
>
> Signed-off-by: Harikrishna Shenoy
> ---
> .../devicetree/bindings/display/panel/panel-
On Mon, Aug 18, 2025 at 11:41:16AM +0200, Stephan Gerhold wrote:
> On Sat, Aug 16, 2025 at 04:55:00PM +0300, Dmitry Baryshkov wrote:
> > On Thu, Aug 14, 2025 at 02:38:45PM +0200, Stephan Gerhold wrote:
> > > On Thu, Aug 14, 2025 at 02:55:44PM +0300, Dmitry Baryshkov wrote:
> > > > On Thu, Aug 14, 2
Hi Matthew,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-xe/drm-xe-next]
[also build test ERROR on next-20250818]
[cannot apply to drm-exynos/exynos-drm-next linus/master v6.17-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.17-rc2 next-20250818]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
On 8/1/2025 8:07 AM, Jun Nie wrote:
The content of every half of screen is sent out via one interface in
dual-DSI case. The content for every interface is blended by a LM
pair in quad-pipe case, thus a LM pair should not blend any content
that cross the half of screen in this case. Clip plane
On 8/1/2025 8:07 AM, Jun Nie wrote:
The stage contains configuration for a mixer pair. Currently the plane
supports just one stage and 2 pipes. Quad-pipe support will require
handling 2 stages and 4 pipes at the same time. In preparation for that
add a separate define, PIPES_PER_PLANE, to deno
Update the bo_atomic_access based on user-provided input and determine
the migration to smem during a CPU fault
v2 (Matthew Brost)
- Avoid cpu unmapping if bo is already in smem
- check atomics on smem too for ioctl
- Add comments
v3
- Avoid migration in prefetch
v4 (Matthew Brost)
- make sanity
Introduce the DRM_IOCTL_XE_VM_QUERY_MEMORY_RANGE_ATTRS ioctl to allow
userspace to query memory attributes of VMAs within a user specified
virtual address range.
Userspace first calls the ioctl with num_mem_ranges = 0,
sizeof_mem_ranges_attr = 0 and vector_of_vma_mem_attr = NULL to retrieve
the nu
If a VMA within the madvise input range already has the same memory
attribute as the one requested by the user, skip PTE zapping for that
VMA to avoid unnecessary invalidation.
v2 (Matthew Brost)
- fix skip_invalidation for new attributes
- s/u32/bool
- Remove unnecessary assignment for kzalloc'e
Introduce a new helper function `xe_vma_has_default_mem_attrs()` to
determine whether a VMA's memory attributes are set to their default
values. This includes checks for atomic access, PAT index, and preferred
location.
Also, add a new field `default_pat_index` to `struct xe_vma_mem_attr`
to track
The PAT index determines how PTEs are encoded and can be modified by
madvise. Therefore, it is now part of the vma attributes.
Signed-off-by: Himal Prasad Ghimiray
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_pt.c | 2 +-
drivers/gpu/drm/xe/xe_vm.c | 6 +++---
drivers/gpu/
Restore default memory attributes for VMAs during garbage collection
if they were modified by madvise. Reuse existing VMA if fully overlapping;
otherwise, allocate a new mirror VMA.
v2 (Matthew Brost)
- Add helper for vma split
- Add retry to get updated vma
v3
- Rebase on gpuvm layer
Suggested-
If the platform does not support atomic access on system memory, and the
ranges are in system memory, but the user requires atomic accesses on
the VMA, then migrate the ranges to VRAM. Apply this policy for prefetch
operations as well.
v2
- Drop unnecessary vm_dbg
v3 (Matthew Brost)
- fix atomic
Ioctl enables setting up of memory attributes in user provided range.
Signed-off-by: Himal Prasad Ghimiray
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 3e
This driver-specific ioctl enables UMDs to control the memory attributes
for GPU VMAs within a specified input range. If the start or end
addresses fall within an existing VMA, the VMA is split accordingly. The
attributes of the VMA are modified as provided by the users. The old
mappings of the VMA
When the user sets the valid devmem_fd as a preferred location, GPU fault
will trigger migration to tile of device associated with devmem_fd.
If the user sets an invalid devmem_fd the preferred location is current
placement(smem) only.
v2(Matthew Brost)
- Default should be faulting tile
- remove
This attributes sets the pat_index for the svm used vma range, which is
utilized to ascertain the coherence.
v2 (Matthew Brost)
- Pat index sanity check
Cc: Matthew Brost
Signed-off-by: Himal Prasad Ghimiray
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_vm_madvise.c | 24 ++
When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC, prefetch svm
ranges to preferred location provided by madvise.
v2 (Matthew Brost)
- Fix region, devmem_fd usages
- consult madvise is applicable for other vma's too.
v3
- Fix atomic handling
v4
- Fix xe_svm_range_validate to check for
A single BO can be linked to multiple VMAs, making VMA attributes
insufficient for determining the placement and PTE update attributes
of the BO. To address this, an attributes field has been added to the
BO.
Signed-off-by: Himal Prasad Ghimiray
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/xe
Introduce flag DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC to ensure prefetching
in madvise-advised memory regions
v2 (Matthew Brost)
- Add kernel-doc
v3 (Matthew Brost)
- Fix kernel-doc
Cc: Matthew Brost
Signed-off-by: Himal Prasad Ghimiray
Reviewed-by: Matthew Brost
---
include/uapi/drm/xe_drm.h |
This change simplifies the logic by ensuring that remapped previous or
next VMAs are created with the same memory attributes as the original VMA.
By passing struct xe_vma_mem_attr as a parameter, we maintain consistency
in memory attributes.
-v2
*dst = *src (Matthew Brost)
-v3 (Matthew Brost)
D
Introduce xe_svm_ranges_zap_ptes_in_range(), a function to zap page table
entries (PTEs) for all SVM ranges within a user-specified address range.
-v2 (Matthew Brost)
Lock should be called even for tlb_invalidation
v3(Matthew Brost)
- Update comment
- s/notifier->itree.start/drm_gpusvm_notifier_s
The attribute of xe_vma will determine the migration policy and the
encoding of the page table entries (PTEs) for that vma.
This attribute helps manage how memory pages are moved and how their
addresses are translated. It will be used by madvise to set the
behavior of the vma.
v2 (Matthew Brost)
-
From: Boris Brezillon
We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](),
so, before we do that, let's pass arguments through a struct instead
of changing each call site every time a new optional argument is added.
Cc: Danilo Krummrich
Cc: Brendan King
Cc: Matt Coster
Cc:
The drm_gpusvm_for_each_notifier, drm_gpusvm_for_each_notifier_safe and
drm_gpusvm_for_each_range_safe macros are useful for locating notifiers
and ranges within a user-specified range. By making these macros public,
we enable broader access and utility for developers who need to leverage
them in t
In the case of the MADVISE ioctl, if the start or end addresses fall
within a VMA and existing SVM ranges are present, remove the existing
SVM mappings. Then, continue with ops_parse to create new VMAs by REMAP
unmapping of old one.
v2 (Matthew Brost)
- Use vops flag to call unmapping of ranges in
If the start or end of input address range lies within system allocator
vma split the vma to create new vma's as per input range.
v2 (Matthew Brost)
- Add lockdep_assert_write for vm->lock
- Remove unnecessary page aligned checks
- Add kerrnel-doc and comments
- Remove unnecessary unwind_ops and r
This commit introduces a new madvise interface to support
driver-specific ioctl operations. The madvise interface allows for more
efficient memory management by providing hints to the driver about the
expected memory usage and pte update policy for gpuvma.
v2 (Matthew/Thomas)
- Drop num_ops suppor
This ops is used to iterate over GPUVA's in the user-provided range
and split the existing sparse VMA's if the start or end of the input
range lies within it. The operations can create up to 2 REMAPS and 2 MAPs.
The primary use case is for drivers to assign attributes to GPU VAs in
the specified r
From: Boris Brezillon
drm_gpuva_init() only has one internal user, and given we are about to
add new optional fields, it only add maintenance burden for no real
benefit, so let's kill the thing now.
Cc: Danilo Krummrich
Cc: Rob Clark
Signed-off-by: Boris Brezillon
Acked-by: Danilo Krummrich
Provides a user API to assign attributes like pat_index, atomic
operation type, and preferred location for SVM ranges.
The Kernel Mode Driver (KMD) may split existing VMAs to cover input
ranges, assign user-provided attributes, and invalidate existing PTEs so
that the next page fault/prefetch can u
On 8/17/25 4:43 AM, Fedor Pchelkin wrote:
> 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
On Thu, Aug 14, 2025 at 3:32 AM Himal Prasad Ghimiray
wrote:
>
> From: Boris Brezillon
>
> We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](),
> so, before we do that, let's pass arguments through a struct instead
> of changing each call site every time a new optional argument
On Thu, Aug 14, 2025 at 04:29:26PM +0530, Himal Prasad Ghimiray wrote:
> -v8
> Define new function in gpuvm for madvise
> Fix tile check in ops_create
Please re-send this series again. But this time, ensure that dri-devel
is in the --to= of the series!
In 8 revisions, it looks like not a single t
Hi,
On Mon, Aug 18, 2025 at 4:50 AM Pin-yen Lin wrote:
>
> Introduce a new HID quirk to indicate that this device has to be enabled
> after the panel's backlight is enabled, and update the driver data for
> the elan devices to enable this quirk. This cannot be a I2C HID quirk
> because the kernel
Hi,
On Mon, Aug 18, 2025 at 4:50 AM Pin-yen Lin wrote:
>
> Some touch controllers have to be powered on after the panel's backlight
> is enabled. To support these controllers, introduce .panel_enabled() and
> .panel_disabling() to panel_follower_funcs and use them to power on the
> device after t
> @@ -858,7 +860,7 @@ long drm_gem_dma_resv_wait(struct drm_file *filep,
u32 handle,
>
> obj = drm_gem_object_lookup(filep, handle);
> if (!obj) {
> - DRM_DEBUG("Failed to look up GEM BO %d\n", handle);
> + drm_dbg_core(NULL, "Failed to look up GEM BO %d\
On 8/18/2025 9:20 PM, Athul Raj Kollareth wrote:
> Replace the DRM_* logging macros used in gem helper files with the appropriate
> ones specified in /include/drm/drm_print.h.
>
> Signed-off-by: Athul Raj Kollareth
> ---
> Changes in v2:
> - Change drm_gem_objects_lookup() to take a drm_de
The simple display pipe is obsolete and the atomic helpers allow for
more control over the rendering process. As such, this patch replaces
the old simple display pipe system with the newer atomic helpers.
As the code is mainly the same, merely replaced with the new atomic
system, there should be n
Replace the DRM_* logging macros used in gem helper files with the appropriate
ones specified in /include/drm/drm_print.h.
Signed-off-by: Athul Raj Kollareth
---
Changes in v2:
- Change drm_gem_objects_lookup() to take a drm_device* argument.
- Make appropriate changes to all calls of drm
Right now, the code checks the DMA_READ_ERROR state 2 times, while
I guess it was supposed to warn about both read and write errors.
Change the 2nd check to look at the write-error flag.
Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL")
Signed-off-by: Heiko Stuebner
---
drivers/acc
https://bugzilla.kernel.org/show_bug.cgi?id=46181
francisco278herr...@gmail.com changed:
What|Removed |Added
CC||francisco278herrera@gmail.c
On 8/16/2025 8:19 AM, Dmitry Baryshkov wrote:
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
---
drive
On 8/16/2025 8:19 AM, Dmitry Baryshkov wrote:
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Reviewed-by: Suraj Kandpal
Reviewed-by: Louis Chauvet
Signed-off-by: Dmitry Baryshkov
Hey Dmitr
On 18-08-2025 23:02, Danilo Krummrich wrote:
On Thu Aug 14, 2025 at 12:59 PM CEST, Himal Prasad Ghimiray wrote:
This ops is used to iterate over GPUVA's in the user-provided range
and split the existing sparse VMA's if the start or end of the input
range lies within it. The operations can cre
On 18-08-2025 22:57, Danilo Krummrich wrote:
On Thu Aug 14, 2025 at 12:59 PM CEST, Himal Prasad Ghimiray wrote:
From: Boris Brezillon
We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](),
so, before we do that, let's pass arguments through a struct instead
of changing each
On Mon, Aug 18, 2025 at 04:21:54PM +0100, Matthew Auld wrote:
> Handle the case where the hmm range partially covers a huge page (like
> 2M), otherwise we can potentially end up doing something nasty like
> mapping memory which is outside the range, and maybe not even mapped by
> the mm. Fix is bas
On Thu Aug 14, 2025 at 12:59 PM CEST, Himal Prasad Ghimiray wrote:
> This ops is used to iterate over GPUVA's in the user-provided range
> and split the existing sparse VMA's if the start or end of the input
> range lies within it. The operations can create up to 2 REMAPS and 2 MAPs.
>
> The primar
On Thu Aug 14, 2025 at 12:59 PM CEST, Himal Prasad Ghimiray wrote:
> From: Boris Brezillon
>
> We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](),
> so, before we do that, let's pass arguments through a struct instead
> of changing each call site every time a new optional argum
Hey there,
On Mon, 18 Aug 2025 at 16:03, Robert Mader wrote:
> On 14.08.25 11:57, Daniel Stone wrote:
> > On Wed, 13 Aug 2025 at 18:06, Robert Mader
> > wrote:
> >> + switch (format) {
> >> + case DRM_FORMAT_YVU420:
> >> + case DRM_FORMAT_YVU422:
> >> + case DRM_FORMAT_Y
On Mon, Aug 18, 2025 at 09:44:01AM -0700, Matthew Brost wrote:
> On Mon, Aug 18, 2025 at 01:36:17PM -0300, Jason Gunthorpe wrote:
> > On Mon, Aug 18, 2025 at 09:25:20AM -0700, Matthew Brost wrote:
> > > I think this choice makes sense: it allows embedding the wait state from
> > > the initial notif
On Mon, Aug 18, 2025 at 06:42:36PM +0200, Thomas Hellström wrote:
> On Mon, 2025-08-18 at 13:36 -0300, Jason Gunthorpe wrote:
> > On Mon, Aug 18, 2025 at 09:25:20AM -0700, Matthew Brost wrote:
> > > I think this choice makes sense: it allows embedding the wait state
> > > from
> > > the initial not
On Mon, Aug 18, 2025 at 01:36:17PM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 18, 2025 at 09:25:20AM -0700, Matthew Brost wrote:
> > I think this choice makes sense: it allows embedding the wait state from
> > the initial notifier call into the pass structure. Patch [6] shows this
> > by attaching
On Mon, 2025-08-18 at 13:36 -0300, Jason Gunthorpe wrote:
> On Mon, Aug 18, 2025 at 09:25:20AM -0700, Matthew Brost wrote:
> > I think this choice makes sense: it allows embedding the wait state
> > from
> > the initial notifier call into the pass structure. Patch [6] shows
> > this
> > by attachin
Applied to drm-misc-next
Thanks,
Lizhi
On 8/15/25 13:43, Limonciello, Mario wrote:
On 8/15/25 12:16 PM, Lizhi Hou wrote:
Walking hardware contexts created by a process is duplicated in multiple
spots. Add a function, amdxdna_hwctx_walk(), and replace all spots.
hwctx_srcu and dev_lock are go
On Mon, Aug 18, 2025 at 09:25:20AM -0700, Matthew Brost wrote:
> I think this choice makes sense: it allows embedding the wait state from
> the initial notifier call into the pass structure. Patch [6] shows this
> by attaching the issued TLB invalidation fences to the pass. Since a
> single notifie
On Mon, Aug 18, 2025 at 01:07:26PM -0300, Jason Gunthorpe wrote:
> On Sat, Aug 09, 2025 at 03:51:32PM +0200, Thomas Hellström wrote:
> > GPU use-cases for mmu_interval_notifiers with hmm often involve
> > starting a gpu operation and then waiting for it to complete.
> > These operations are typical
1 - 100 of 203 matches
Mail list logo
