On Thu Mar 13, 2025 at 5:02 PM CET, Rahul Rameshbabu wrote:
> Hello,
>
> I am a hobbyist developer who has been working on a project to create a new
> Rust
> HID device driver and the needed core abstractions for writing more HID device
> drivers in Rust. My goal is to support the USB Monitor Cont
Hi Maintainers,
There are some flake test reported for mediatek driver testing in drm-ci.
# Board Name: mt8183-kukui-jacuzzi-juniper-sku16
# Failure Rate: 20
# IGT Version: 1.30-g04bedb923
# Linux Version: 6.14.0-rc4
kms_atomic_transition@plane-toggle-modeset-transition
11:13:54.607: DEBUG - Be
On 13/03/25 11:43, Maíra Canal wrote:
The V3D driver still relies on `drm_sched_increase_karma()` and
`drm_sched_resubmit_jobs()` for resubmissions when a timeout occurs.
The function `drm_sched_increase_karma()` marks the job as guilty, while
`drm_sched_resubmit_jobs()` sets an error (-ECANCELED
On Thu, Mar 13, 2025 at 10:42 AM Maxime Ripard wrote:
> Hi Anusha,
>
> In addition to the feedback Luca already provided, I have a few comments
>
> On Wed, Mar 12, 2025 at 08:54:42PM -0400, Anusha Srivatsa wrote:
> > Introduce reference counted allocations for panels to avoid
> > use-after-free.
Add initial declarations for the drm_xe_vm_get_property ioctl.
Signed-off-by: Jonathan Cavitt
---
include/uapi/drm/xe_drm.h | 69 +++
1 file changed, 69 insertions(+)
diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
index 616916985e3f..0ed52
On Thu, 13 Mar 2025 11:31:12 -0700 Guenter Roeck wrote:
> On Thu, Mar 13, 2025 at 06:24:25PM +0100, Maxime Ripard wrote:
> > >
> > > Yeah, as with my prior review, I'm a fan of this. It makes a bunch of my
> > > very noisy tests much easier to deal with.
> >
> > And for the record, we're also a
On 3/13/25 11:34, Jonathan Cavitt wrote:
Add initial declarations for the drm_xe_vm_get_property ioctl.
Signed-off-by: Jonathan Cavitt
---
include/uapi/drm/xe_drm.h | 69 +++
1 file changed, 69 insertions(+)
diff --git a/include/uapi/drm/xe_drm.h b/inc
Add a basic test for exercising modifying the entities scheduler list at
runtime.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
Acked-by: Christian König
---
drivers/gpu/drm/scheduler/tests/tests_basic.c | 69 ++-
Add a very simple timeout test which submits a single job and verifies
that the timeout handling will run if the backend failed to complete the
job in time.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
Acked-by: Christian König
On Thursday, 13 March 2025 14:11:35 CET Krzysztof Niemiec wrote:
> Hi Janusz,
>
> On 2025-03-12 at 17:58:13 GMT, Janusz Krzysztofik wrote:
> > Hi Krzysztof,
> >
> > Thanks for looking at this.
> >
> > On Wednesday, 12 March 2025 16:06:15 CET Krzysztof Niemiec wrote:
> > > On 2025-03-11 at 21:04:
There has repeatedly been quite a bit of apprehension when any change to the DRM
scheduler is proposed, with two main reasons being code base is considered
fragile, not well understood and not very well documented, and secondly the lack
of systematic testing outside the vendor specific tests suites
Hi Janusz,
On 2025-03-12 at 17:58:13 GMT, Janusz Krzysztofik wrote:
> Hi Krzysztof,
>
> Thanks for looking at this.
>
> On Wednesday, 12 March 2025 16:06:15 CET Krzysztof Niemiec wrote:
> > On 2025-03-11 at 21:04:56 GMT, Janusz Krzysztofik wrote:
> > > Starting with commit ec3e00b4ee27 ("drm/i91
With the bridges switching over to drm_bridge_connector, the direct
association between a bridge driver and its connector was lost.
This is mitigated for atomic bridge drivers by the fact you can access
the encoder, and then call drm_atomic_get_old_connector_for_encoder() or
drm_atomic_get_new_con
Hi,
is there anything else I need to do, or can this patch now be applied?
The initial two patches that introduce property support have already
been merged, and the patch series that this patch depends on [1] has
also been applied.
[1] https://lore.kernel.org/all/Z7rZjdXwN2W+Y2Bd@dragon/
Be
We'll need the HDMI state tests light_up_connector() function in more
tests, so let's promote it to a helper.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 61 +++
include/drm/drm_kunit_helpers.h
Let's provide an helper to make it easier for bridge drivers to
power-cycle their bridge.
In order to avoid a circular dependency between that new helper and
drm_atomic_helper_reset_crtc(), this new helper will be in a
drm_bridge_helper.c file to follow the pattern we have for other
objects.
Revi
We introduced a new helper that supersedes the light_up_connector()
function in drm_hdmi_state_helper_test, so let's convert all our tests
to it.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 158 -
1 file
The TI sn65dsi86 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
Fortunately, the atomic hooks provide the drm_atomic_state and we can
access our current CRTC from that, going from the bridge to its encoder,
to its connector, and to its CRTC
The Cadence DSI driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
Fortunately, the atomic hooks provide the drm_atomic_state and we can
access our current CRTC from that, going from the bridge to its encoder,
to its connector, and to its CRTC.
We test for whether the bridge is atomic in several places in the source
code, so let's consolidate them.
Suggested-by: Dmitry Baryshkov
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_bridge.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
d
The tc358775 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
Fortunately, the atomic hooks provide the drm_atomic_state and we can
access our current CRTC from that, going from the bridge to its encoder,
to its connector, and to its CRTC.
L
Now that we have a helper for bridge drivers to call to reset the output
pipeline, let's use it.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Herve Codina
Tested-by: Herve Codina
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 28 +++-
1 file cha
Let's provide a bunch of kunit tests to make sure
drm_bridge_helper_reset_crtc() works as expected.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_bridge_test.c | 209 +++-
1 file changed, 208 insertions(+), 1 deletion(-)
di
The tc358768 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
Fortunately, the atomic hooks provide the drm_atomic_state and we can
access our current CRTC from that, going from the bridge to its encoder,
to its connector, and to its CRTC.
L
The tc358768 bridge driver, if enabling it fails, tries to disable it.
This is pretty uncommon in bridge drivers, and also stands in the way
for further reworks.
Worse, since pre_enable and enable aren't expected to fail, disable and
post_disable might be called twice: once to handle the failure,
Hello Maxime,
On Fri, 7 Feb 2025 12:47:51 +0100
Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 06, 2025 at 07:14:29PM +0100, Luca Ceresoli wrote:
> > DRM bridges are currently considered as a fixed element of a DRM card, and
> > thus their lifetime is assumed to extend for as long as the card
> > e
Hi, Christian
On Thu, 2025-03-13 at 11:19 +0100, Christian König wrote:
> Am 12.03.25 um 22:03 schrieb Thomas Hellström:
> > This RFC implements and requests comments for a way to handle SVM
> > with multi-device,
> > typically with fast interconnects. It adds generic code and helpers
> > in drm,
On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
> On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> > Hi everyone,
> >
> > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > >
> > > >
> > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > >
These abstractions enable the development of HID drivers in Rust by binding
with the HID core C API. They provide Rust types that map to the
equivalents in C. In this initial draft, only hid_device and hid_device_id
are provided direct Rust type equivalents. hid_driver is specially wrapped
with a c
In the ttm_bo_unreserve_bulk() test function, resv is allocated using
kunit_kzalloc(), but the subsequent assertion mistakenly verifies the
ttm_dev pointer instead of the resv pointer.
Fix the assertion to properly verify the resv pointer.
Signed-off-by: Qasim Ijaz
---
drivers/gpu/drm/ttm/tests
V3D 7.1 exposes a new register block, called V3D_SMS. As BCM2712 has a
V3D 7.1 core, add a new register item to its compatible. Similar to the
GCA, which is specific for V3D 3.3, SMS should only be added for V3D 7.1
variants (such as brcm,2712-v3d).
Signed-off-by: Maíra Canal
---
Documentation/d
On Thu, Mar 13, 2025 at 03:00:34PM +0900, Vincent Mailhol wrote:
On 13/03/2025 at 13:13, Lucas De Marchi wrote:
On Thu, Mar 06, 2025 at 08:29:56PM +0900, Vincent Mailhol via B4 Relay
wrote:
From: Vincent Mailhol
The definitions of GENMASK() and GENMASK_ULL() do not depend any more
on __GENMAS
On Thu, Mar 13, 2025 at 03:20:34PM +0100, Christian König wrote:
> Am 11.03.25 um 20:01 schrieb Qasim Ijaz:
> > In the ttm_bo_unreserve_bulk() test function, resv is allocated
> > using kunit_kzalloc(), but the subsequent assertion mistakenly
> > verifies the ttm_dev pointer instead of checking t
Hi Dave and Sima,
Here goes i915 fixes for this week.
The most interesting seems to be a bump in the MMAP_GTT_VERSION
to indicate a missing support for partial mmaps, which had
been previously introduced by commit 255fc1703e42 ("drm/i915/gem:
Calculate object page offset for partial memory mappin
On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote:
> On March 12, 2025 4:56:31 PM PDT, Jacob Keller
> wrote:
[...]
> >This is really a question of whether you expect odd or even parity as
> >the "true" value. I think that would depend on context, and we may not
> >reach a good cons
On Fri, Mar 07, 2025 at 11:33:40AM -0800, H. Peter Anvin wrote:
> On March 7, 2025 11:30:08 AM PST, Yury Norov wrote:
[...]
> >> Instead of "bool" think of it as "bit" and it makes more sense
> >
> >So, to help people thinking that way we can introduce a corresponding
> >type:
> >typedef
Boris,
On 3/11/25 5:06 AM, Boris Brezillon wrote:
On Mon, 10 Mar 2025 16:59:20 -0300
Ariel D'Alessandro wrote:
Now that Panfrost supports AARCH64_4K page table format, let's enable it
on Mediatek MT8188.
Can you maybe give more details on why this is needed
(legacy shareability/cacheability
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
On Thu, Mar 13, 2025 at 04:03:35PM +, Rahul Rameshbabu wrote:
> These abstractions enable the development of HID drivers in Rust by binding
> with the HID core C API. They provide Rust types that map to the
> equivalents in C. In this initial draft, only hid_device and hid_device_id
> are provi
This adds the UAPI for the Asahi driver targeting the GPU in the Apple
M1 and M2 series systems on chip. The UAPI design is based on other
modern Vulkan-capable drivers, including Xe and Panthor. Memory
management is based on explicit VM management. Synchronization is
exclusively explicit sync.
Th
On Wed, Mar 12, 2025 at 8:22 PM Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 12, 2025 at 5:00 PM Anusha Srivatsa
> wrote:
> >
> >
> >
> > On Wed, Mar 12, 2025 at 11:48 AM Doug Anderson
> wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Mar 12, 2025 at 8:06 AM Anusha Srivatsa
> wrote:
> >> >
> >> >> > @@ -
On Wed, Mar 12, 2025 at 04:12:14PM +0100, Krzysztof Kozlowski wrote:
> On 06/03/2025 19:11, Konrad Dybcio wrote:
> > From: Konrad Dybcio
> >
> > MSM8916 seems to reuse the same hardware as MSM8974 and friends (for
> > whom this binding document was created). Add a new compatible for it.
> >
> >
This code will eventually contain the logic needed to drive the backlight
of displays that implement the USB Monitor Control Class specification.
Examples include the Apple Studio Display and Apple Pro Display XDR
monitors. USB Monitor Control Class encompasses more than just backlight
control, so
On Thu, 06 Mar 2025, Thomas Zimmermann wrote:
> This series removes the remaining dependencies on fbdev from the
> backlight, lcd and led subsystems. Each depends on fbdev events to
> track display state. Make fbdev inform each subsystem via a dedicated
> interface instead.
>
> Patches 1 to 3 mak
On March 13, 2025 9:24:38 AM PDT, Yury Norov wrote:
>On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote:
>> On March 12, 2025 4:56:31 PM PDT, Jacob Keller
>> wrote:
>
>[...]
>
>> >This is really a question of whether you expect odd or even parity as
>> >the "true" value. I think that
On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
> On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
> > On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> > > Hi everyone,
> > >
> > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > > >
>
Hi,
On Thu, Mar 13, 2025 at 10:17:49AM -0700, Kees Cook wrote:
> On Thu, Mar 13, 2025 at 11:43:15AM +, Alessandro Carminati wrote:
> > Some unit tests intentionally trigger warning backtraces by passing bad
> > parameters to kernel API functions. Such unit tests typically check the
> > return
On Mar 13 2025, Rahul Rameshbabu wrote:
> This code will eventually contain the logic needed to drive the backlight
> of displays that implement the USB Monitor Control Class specification.
> Examples include the Apple Studio Display and Apple Pro Display XDR
> monitors. USB Monitor Control Class e
On Mar 13 2025, Rahul Rameshbabu wrote:
> This is a very basic "hello, world!" implementation to illustrate that the
> probe and remove callbacks are working as expected. I chose an arbitrary
> device I had on hand for populating in the HID device id table.
Nice to see this live :)
Though as I me
On Thu, Mar 13, 2025 at 11:48:32AM +0100, Petr Mladek wrote:
> So I am fine with this patch:
>
> Reviewed-by: Petr Mladek
> Tested-by: Petr Mladek
>
>
> Now, the question is how to get this patch into the mainline.
>
> Normally, it would make perfect sense to queue it via the DRM tree
> becau
Hi
> On 13 Mar 2025, at 11:10 PM, Kees Cook wrote:
>
> On Thu, Mar 13, 2025 at 11:48:32AM +0100, Petr Mladek wrote:
>> So I am fine with this patch:
>>
>> Reviewed-by: Petr Mladek
>> Tested-by: Petr Mladek
>>
>>
>> Now, the question is how to get this patch into the mainline.
>>
>> Normal
On Thu, Mar 13, 2025 at 06:24:25PM +0100, Maxime Ripard wrote:
> >
> > Yeah, as with my prior review, I'm a fan of this. It makes a bunch of my
> > very noisy tests much easier to deal with.
>
> And for the record, we're also affected by this in DRM and would very
> much like to get it merged in
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
Move the pagefault struct from xe_gt_pagefault.c to the
xe_gt_pagefault_types.h header file, along with the associated enum values.
v2:
- Normalize names for common header (Matt Brost)
v3:
- s/Migrate/Move (Michal W)
- s/xe_pagefault/xe_gt_pagefault (Michal W)
- Create new header file, xe_gt_page
Add a new field to the xe_pagefault struct, address_type, that tracks
the type of fault the pagefault incurred.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/xe_gt_pagefault.c | 3 +++
drivers/gpu/drm/xe/xe_gt_pagefault_types.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a
The page fault handler should reject write/atomic access to read only
VMAs. Add code to handle this in handle_pagefault after the VMA lookup.
Fixes: 3d420e9fa848 ("drm/xe: Rework GPU page fault handling")
Signed-off-by: Jonathan Cavitt
Suggested-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_gt_p
On Thu, Mar 13, 2025 at 11:43:15AM +, Alessandro Carminati wrote:
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
Than
On Mar 13 2025, Rahul Rameshbabu wrote:
> These abstractions enable the development of HID drivers in Rust by binding
> with the HID core C API. They provide Rust types that map to the
> equivalents in C. In this initial draft, only hid_device and hid_device_id
> are provided direct Rust type equiv
Hi,
On 06/03/2025 15:29, Devarsh Thakkar wrote:
Enable display for AM62L DSS [1] which supports only a single display
pipeline using a single overlay manager, single video port and a single
video lite pipeline which does not support scaling.
The output of video port is routed to SoC boundary vi
On Thu, Mar 13, 2025 at 12:56:56PM +0100, Luca Ceresoli wrote:
> Hello Maxime,
>
> On Fri, 7 Feb 2025 12:47:51 +0100
> Maxime Ripard wrote:
> > On Thu, Feb 06, 2025 at 07:14:29PM +0100, Luca Ceresoli wrote:
> > > DRM bridges are currently considered as a fixed element of a DRM card, and
> > > thu
Hi Dave, Sima,
here's the first PR from drm-misc-next-fixes for this release cycle.
Just one patch this week.
Best regards
Thomas
drm-misc-next-fixes-2025-03-13:
Short summary of fixes pull:
appletbdrm:
- Fix device refcount
The following changes since commit d65a27f95f6ab236b1a788d9bc463d24a8b
On Mon, Mar 10, 2025 at 06:44:51PM +, Robin Murphy wrote:
> On 2025-03-10 4:28 pm, Maxime Ripard wrote:
> > On Mon, Mar 10, 2025 at 02:56:37PM +, Robin Murphy wrote:
> > > On 2025-03-10 12:06 pm, Maxime Ripard wrote:
> > > > Consumers of the direct DMA API will have to know which region the
r_unload;
---
base-commit: f9f087d946266bc5da7c3a17bd8fd9d01969e3cf
change-id: 20250313-mxsfb_probe-fix-rollback-on-error-3074b9080f34
Best regards,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo
Apple GPUs support non-linear "GPU-tiled" image layouts. Add modifiers
for these layouts. Mesa requires these modifiers to share non-linear
buffers across processes, but no other userspace or kernel support is
required/expected.
These layouts are notably not used for interchange across hardware
bl
Hi Maintainers,
There are some flake test reported for vkms driver testing in drm-ci.
# Board Name: vkms
# Failure Rate: 20
# IGT Version: 1.30-g04bedb923
# Linux Version: 6.14.0-rc4
kms_flip@modeset-vs-vblank-race
DEBUG - Begin test kms_flip@modeset-vs-vblank-race
ERROR - Igt error: (kms_flip:
On 3/12/2025 5:14 PM, Krzysztof Kozlowski wrote:
> On Tue, Mar 11, 2025 at 05:54:37PM +0530, Ayushi Makhija wrote:
>> diff --git
>> a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
>> b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
>> index ffbd
On 12/03/2025 14:39, Maxime Ripard wrote:
> edid-decode gained recently support to check that infoframes are
> compliant and match the EDID the monitor exposes.
>
> Since the HDMI helpers provide those infoframes in debugfs, it makes it
> easy to check from userspace that the drivers (and helpers)
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
On Thu, Mar 13, 2025 at 6:10 AM Luca Ceresoli
wrote:
> Hello Anusha,
>
> On Wed, 12 Mar 2025 20:54:42 -0400
> Anusha Srivatsa wrote:
>
> > Introduce reference counted allocations for panels to avoid
> > use-after-free. The patch adds the macro devm_drm_bridge_alloc()
> > to allocate a new refcou
On 3/13/2025 9:36 AM, H. Peter Anvin wrote:
> On March 13, 2025 9:24:38 AM PDT, Yury Norov wrote:
>> On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote:
>>> On March 12, 2025 4:56:31 PM PDT, Jacob Keller
>>> wrote:
>>
>> [...]
>>
This is really a question of whether you expec
On March 13, 2025 10:42:10 AM PDT, Aditya Garg wrote:
>I already sent the 1st patch to DRM. I can rebase the test-printf bit to this
>tree. Sounds good?
Yeah, sounds good to me! Thanks :)
-Kees
--
Kees Cook
Hi Maxime and Simona,
At 2025-03-13 19:55:33, "Maxime Ripard" wrote:
>Hi,
>
>On Thu, Mar 13, 2025 at 04:09:54PM +0800, Andy Yan wrote:
>> At 2025-03-05 19:55:19, "Andy Yan" wrote:
>> >At 2025-03-04 19:10:47, "Maxime Ripard" wrote:
>> >>With the bridges switching over to drm_bridge_connector,
Hi,
On Mon, Mar 10, 2025 at 3:42 AM Damon Ding wrote:
>
> Move drm_of_find_panel_or_bridge() a little later and combine it with
> component_add() into a new function rockchip_dp_link_panel(). The function
> will serve as done_probing() callback of devm_of_dp_aux_populate_bus(),
> aiding to suppor
Hi,
On Mon, Mar 10, 2025 at 3:42 AM Damon Ding wrote:
>
> The main modification is moving the DP AUX initialization from function
> analogix_dp_bind() to analogix_dp_probe(). In order to get the EDID of
> eDP panel during probing, it is also needed to advance PM operations to
> ensure that eDP co
Hi,
On Mon, Mar 10, 2025 at 3:42 AM Damon Ding wrote:
>
> Add analogix_dpaux_wait_hpd_asserted() to help confirm the HPD state
> before doing AUX transfers.
>
> Signed-off-by: Damon Ding
> ---
> .../drm/bridge/analogix/analogix_dp_core.c| 21 +++
> 1 file changed, 21 inserti
> On 13 Mar 2025, at 2:27 PM, Andy Shevchenko
> wrote:
>
> On Thu, Mar 13, 2025 at 08:53:28AM +, Aditya Garg wrote:
On 13 Mar 2025, at 2:19 PM, Andy Shevchenko
wrote:
>>> On Thu, Mar 13, 2025 at 07:26:05AM +, Aditya Garg wrote:
>> On 13 Mar 2025, at 12:58 AM, Andy Shev
On Wed, 2025-03-05 at 16:53 +0100, Philipp Stanner wrote:
> The GPU scheduler's comments refer to a "thread" at various places.
> Those are leftovers from commit a6149f039369 ("drm/sched: Convert drm
> scheduler to use a work queue rather than kthread").
>
> Replace all references to kthreads.
>
The documentation for drm_sched_job_arm() and especially
drm_sched_job_cleanup() does not make it very clear why
drm_sched_job_arm() is a point of no return, which it indeed is.
Make the nature of drm_sched_job_arm() in the docu as clear as possible.
Suggested-by: Christian König
Signed-off-by:
Hi Maintainers,
There are some flake test reported for mediatek driver testing in drm-ci.
# Board Name: mt8173-elm-hana
# Failure Rate: 20
# IGT Version: 1.30-g04bedb923
# Linux Version: 6.14.0-rc4
kms_flip@flip-vs-wf_vblank-interruptible
command: cd "/igt/libexec/igt-gpu-tools" &&
"/igt/libex
On 3/12/2025 5:15 PM, Krzysztof Kozlowski wrote:
> On Tue, Mar 11, 2025 at 05:54:38PM +0530, Ayushi Makhija wrote:
>> Document DSI controller and phy on SA8775P platform.
>>
>> Signed-off-by: Ayushi Makhija
>> ---
>> .../display/msm/qcom,sa8775p-mdss.yaml| 188 ++
>> 1
Some drivers like virtio-gpu, don't map the scanout buffer in the
kernel. Calling vmap() in a panic handler is not safe, and writing an
atomic_vmap() API is more complex than expected [1].
So instead, pass the array of pages of the scanout buffer to the
panic handler, and map only one page at a tim
On Wed, 12 Mar 2025, Michał Winiarski wrote:
> Similar to regular resizable BAR, VF BAR can also be resized, e.g. by
> the system firmware or the PCI subsystem itself.
>
> Add the capability ID and restore it as a part of IOV state.
>
> See PCIe r4.0, sec 9.3.7.4.
>
> Signed-off-by: Michał Wini
Hi Maintainers,
There are some flake test reported for mediatek driver testing in drm-ci.
# Board Name: mt8183-kukui-jacuzzi-juniper-sku16
# Failure Rate: 20
# IGT Version: 1.30-g04bedb923
# Linux Version: 6.14.0-rc4
kms_flip@basic-flip-vs-modeset
09:59:50.792: DEBUG - Begin test kms_flip@basic
On Thu, 13 Mar 2025, Ilpo Järvinen wrote:
> On Wed, 12 Mar 2025, Michał Winiarski wrote:
>
> > Similar to regular resizable BAR, VF BAR can also be resized, e.g. by
> > the system firmware or the PCI subsystem itself.
> >
> > Add the capability ID and restore it as a part of IOV state.
> >
> >
clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter.Remove unneeded NULL check for clk here.
Signed-off-by: Chen Ni
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
Hi,
Running clang-analyzer[1] on the VOP2 driver in barebox[2], which was ported
from Linux reports that following variables:
dclk_out_div, if_pixclk_div, if_dclk_div
defined in rk3588_set_intf_mux() and passed to rk3588_calc_cru_cfg()
are given as uninitialized arguments to ilog2() and in som
On Wed, 2025-03-12 at 14:33 +, Tvrtko Ursulin wrote:
>
> On 12/03/2025 13:49, Philipp Stanner wrote:
>
> [snip]
>
> > > > > There I see a UAF. Do you have an idea what that might be? I
> > > > > would only
> > > > > expect memory leaks and the test assertions failing.
> > > >
> > > > It is
On Tue, 2025-03-11 at 14:02 +0800, Qianyi Liu wrote:
> From: qianyi liu
>
> The last_scheduled fence leaks when an entity is being killed and
> adding
> the cleanup callback fails.
>
> Decrement the reference count of prev when dma_fence_add_callback()
> fails, ensuring proper balance.
>
> Cc:
On Thu, Mar 13, 2025 at 12:29:13AM +0800, Kuan-Wei Chiu wrote:
> On Wed, Mar 12, 2025 at 11:51:12AM -0400, Yury Norov wrote:
> > On Tue, Mar 11, 2025 at 03:24:14PM -0700, H. Peter Anvin wrote:
> > > On March 11, 2025 3:01:30 PM PDT, Yury Norov wrote:
> > > >On Sun, Mar 09, 2025 at 11:48:26PM +0800
The header self-contained tests in drm may leave .hdrtest files in
include/drm/ and drivers/gpu/drm/. Omit them by adding .gitignore
Signed-off-by: Yo-Jung (Leo) Lin
---
drivers/gpu/drm/.gitignore | 1 +
include/drm/.gitignore | 1 +
2 files changed, 2 insertions(+)
create mode 100644 drive
clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter.Remove unneeded NULL check for clk here.
Signed-off-by: Chen Ni
---
drivers/gpu/drm/omapdrm/dss/venc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.
On Thu, Mar 13, 2025 at 07:26:05AM +, Aditya Garg wrote:
> > On 13 Mar 2025, at 12:58 AM, Andy Shevchenko
> > wrote:
> > On Wed, Mar 12, 2025 at 07:14:36PM +, Aditya Garg wrote:
> >>> On 12 Mar 2025, at 9:05 PM, Sven Peter wrote:
> >>> On Wed, Mar 12, 2025, at 13:03, Aditya Garg wrote:
> On 13 Mar 2025, at 12:58 AM, Andy Shevchenko
> wrote:
>
> On Wed, Mar 12, 2025 at 07:14:36PM +, Aditya Garg wrote:
>>> On 12 Mar 2025, at 9:05 PM, Sven Peter wrote:
>>> On Wed, Mar 12, 2025, at 13:03, Aditya Garg wrote:
>
> ...
>
>>> I don't have a strong opinion either way: for SMC I
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2025-03-13:
A null pointer check for gma500, two clippy fixes for panic, a fix for
an interaction between DPMS and atomic leading to dropped frames, and
a locking fix for dp_mst
The following changes since commit 80da96d735094ea22985c
Hi Maxime,
At 2025-03-05 19:55:19, "Andy Yan" wrote:
>
>
>Hi Maxime,
>
>At 2025-03-04 19:10:47, "Maxime Ripard" wrote:
>>With the bridges switching over to drm_bridge_connector, the direct
>>association between a bridge driver and its connector was lost.
>>
>>This is mitigated for atomic bridg
Hi Abhinav,
On 13/03/25 07:40, Vignesh Raman wrote:
Hi Abhinav,
On 05/12/24 01:29, Abhinav Kumar wrote:
From the jobs [1] and [2] of pipeline [3], its clear that
kms_cursor_legacy@torture-bo is most certainly a flake and
not a fail for apq8016. Mark the test accordingly to match the results.
On Wed, 12 Mar 2025, Michał Winiarski wrote:
> Similar to regular resizable BAR, VF BAR can also be resized.
>
> The structures are very similar, which means we can reuse most of the
> implementation.
>
> Extend the pci_resize_resource() function to accept IOV resources.
>
> See PCIe r4.0, sec
On 05/03/2025 15:53, Philipp Stanner wrote:
The kthread header doesn't need to be included anymore. It's a relict
from commit a6149f039369 ("drm/sched: Convert drm scheduler to use a
work queue rather than kthread").
Remove the unneeded includes.
Signed-off-by: Philipp Stanner
---
drivers/
On 13/03/2025 08:34, Philipp Stanner wrote:
On Wed, 2025-03-12 at 14:33 +, Tvrtko Ursulin wrote:
On 12/03/2025 13:49, Philipp Stanner wrote:
[snip]
There I see a UAF. Do you have an idea what that might be? I
would only
expect memory leaks and the test assertions failing.
It is expec
Am 12.03.25 um 22:03 schrieb Thomas Hellström:
> This RFC implements and requests comments for a way to handle SVM with
> multi-device,
> typically with fast interconnects. It adds generic code and helpers in drm,
> and
> device-specific code for xe.
>
> For SVM, devices set up maps of device-pri
101 - 200 of 220 matches
Mail list logo
