Hi,
On 12/09/2024 15:57, Andrew Kreimer wrote:
Fix typos in comments.
Reported-by: Matthew Wilcox
Signed-off-by: Andrew Kreimer
---
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 2 +-
drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --gi
Hi,
On 18/12/2024 04:01, li...@treblig.org wrote:
From: "Dr. David Alan Gilbert"
hdmi5_core_handle_irqs() is a function that was copied from omapdss by
commit f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
but it wasn't used in the original anyway.
Remove it.
Signed-off-by: Dr.
Hi,
On 24/01/2025 01:56, Sean Anderson wrote:
On 11/12/24 12:22, Sean Anderson wrote:
On 11/12/24 11:43, Laurent Pinchart wrote:
On Tue, Nov 12, 2024 at 09:41:58AM -0500, Sean Anderson wrote:
On 11/12/24 00:27, Laurent Pinchart wrote:
Hi Dan,
Thank you for the patch.
On Mon, Nov 11, 2024 a
Hi,
On 14/01/2025 16:58, Krzysztof Kozlowski wrote:
of_property_read_bool() should be used only on boolean properties.
Signed-off-by: Krzysztof Kozlowski
---
Changes in v2:
1. New patch - split from the next one.
---
drivers/gpu/drm/omapdrm/dss/dss.c | 2 +-
1 file changed, 1 insertion(+)
On 12/18/24 1:33 AM, Matthew Brost wrote:
From: Thomas Hellström
Introduce drm_pagemap ops to map and unmap dma to VRAM resources. In the
local memory case it's a matter of merely providing an offset into the
device's physical address. For future p2p the map and unmap functions may
encode as
On 12/18/24 1:33 AM, Matthew Brost wrote:
This patch introduces support for GPU Shared Virtual Memory (SVM) in the
Direct Rendering Manager (DRM) subsystem. SVM allows for seamless
sharing of memory between the CPU and GPU, enhancing performance and
flexibility in GPU computing tasks.
The pat
This was previously attempted as xe specific reset uevent but dropped
in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
as part of refactoring.
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
W
From: André Almeida
Use DRM's device wedged event to notify userspace that a reset had
happened. For now, only use `none` method meant for telemetry
capture.
In the future we might want to report a recovery method if the reset didn't
succeed.
Acked-by: Shashank Sharma
Signed-off-by: André Alme
Introduce device wedged event, which notifies userspace of 'wedged'
(hanged/unusable) state of the DRM device through a uevent. This is
useful especially in cases where the device is no longer operating as
expected and has become unrecoverable from driver context. Purpose of
this implementation is
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
With this in place, userspace will be notified of wedged device on
gt reset failure.
Signed-off-by: Raag Jadav
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/d
Add documentation for device wedged event in a new 'Device wedging'
chapter. The describes basic definitions, prerequisites and consumer
expectations along with an example.
v8: Improve documentation (Christian, Rodrigo)
v9: Add prerequisites section (Christian)
v10: Clarify mmap cleanup and cons
This series introduces device wedged event in DRM subsystem and uses it
in xe, i915 and amdgpu drivers. Detailed description in commit message.
This was earlier attempted as xe specific uevent in v1 and v2 on [1].
Similar work by André Almeida on [2].
Wedged event support for amdgpu by André Almei
eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 8 +++-
1 file changed, 7 insertions(+),
Check if we are capable of controlling brightness via Nits which
is dependant on PANEL_LUMINANCE_OVERRIDE and SMOOTH_BRIGHTNESS
capablility being set.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp_aux_backlight
Modify backlight setup function for VESA interface to take into
account the NITS based brightness.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 97 +++
1 file changed, 57 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display
Enable Nits based brightness by writing the PANEL_LUMINANCE_CONTROL
bit and set the correct register to change brightness.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/
Create a function that fills in the value for
PANEL_TARGET_LUMINANCE_VALUE which helps in changing the brightness in
NITS using VESA interface.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/
Modify vesa_get_brightness function to take into account nits_support
and based on that read the appropriate register and return the value.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 20 +++
1 file changed, 20 insertions(+)
diff --git a/driv
Add the eDP revision bit value for 1.5.
Spec: eDPv1.5 Table 16-5
Signed-off-by: Suraj Kandpal
---
include/drm/display/drm_dp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index a6f8b098c56f..76162ad3b152 100644
--- a/include/drm
>From eDP 1.5 we are supposed to use the VESA pathways to control
brightness. But still did not have the Nits brightness control coded
in. This series enables NITS based backlight control over AUX using
VESA pathways.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3669
Signed-off-by
On Thu, Jan 23, 2025 at 01:41:14PM -0800, Abhinav Kumar wrote:
>
>
> On 1/23/2025 1:32 PM, Abhinav Kumar wrote:
> >
> >
> > On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
> > > Continue migration to the MDSS-revision based checks and replace
> > > DPU_PINGPONG_DSC feature bit with the core_majo
On Thu, 2025-01-23 at 19:23 +0530, Vignesh Raman wrote:
> This patch series introduces "kci-gitlab," a GitLab CI pipeline
> specifically designed for kernel testing. It provides kernel
> developers with an integrated, efficient, and flexible testing
> framework using GitLab's CI/CD capabilities. Th
On Thu, Jan 23, 2025 at 05:28:06PM -0500, Detlev Casanova wrote:
> From: Sugar Zhang
>
> Register the dw-hdmi-qp bridge driver as an HDMI audio codec.
>
> The register values computation functions (for n) are based on the
> downstream driver, as well as the register writing functions.
>
> The d
Hi,
On Thu, Jan 23, 2025 at 7:54 PM Langyan Ye
wrote:
>
> Hi Doug,
> Your suggestion is very helpful to me, thank you.
One note: when responding on mailing lists, please don't "top post". I
personally don't care that much, but many others do. See, for
instance;
https://subspace.kernel.org/etiqu
On 1/23/2025 6:03 PM, Dmitry Baryshkov wrote:
> On Thu, Jan 23, 2025 at 05:34:00PM +0530, Ekansh Gupta wrote:
>>
>>
>> On 1/23/2025 4:43 PM, Dmitry Baryshkov wrote:
>>> On Thu, Jan 23, 2025 at 03:19:21PM +0530, Ekansh Gupta wrote:
On 1/23/2025 1:18 PM, Dmitry Baryshkov wrote:
> On
Hi Doug,
Your suggestion is very helpful to me, thank you.
I confirmed the controller chips of these two panels, and it turned
out that they use the HX83102 IC, so the correct approach is that I
should add these two MIPI panels to the binding file/driver of the
MIPI controller of HX83102.I would l
On Wed, Jan 22, 2025 at 01:15:31PM +0200, Giedrius Statkevičius wrote:
> Hello,
>
> On Mon, 4 Nov 2024 at 23:28, Rodrigo Vivi wrote:
> >
> > On Mon, Nov 04, 2024 at 02:09:46PM +0200, Giedrius Statkevičius wrote:
> > > Hello,
> > >
> > > Kind ping.
> >
> > There was a pipe underun in CI... I hones
Hi,
On Thu, Jan 23, 2025 at 3:25 AM Dmitry Baryshkov
wrote:
>
> On Thu, Jan 23, 2025 at 06:07:40PM +0800, 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 p
IT6505 supports HW auto link training which will write DPCD and check
training status automatically. Some DP device can not pass
HW auto link training and must set link training step by step.
when HW auto link training fail, it may trigger video FIFO error,
and link training process will reset to
From: Hermes Wu
IT6505 supports HW link training which will write DPCD and check
training status automatically.
In the case that driver set link rate at 2.7G and HW fail to training,
it will change link configuration and try 1.65G. And this will cause
INT_VID_FIFO_ERROR triggered when link clock
From: Hermes Wu
When connect to device which can only training done by
step training, skip auto training when link training restart,
usually happen when display resolution is changed.
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/ite-it6505.c | 36 +---
1
From: Hermes Wu
The DP link training work include auto training and after
auto training failed "auto_train_retry" times, it switch to
step training mode.
It will more efficiency that finish link auto training,
include retry, and step training in a work, rather than
re-schedule train work when ea
Hi,
On Thu, Jan 23, 2025 at 3:31 AM Dmitry Baryshkov
wrote:
>
> On Thu, Jan 23, 2025 at 06:07:45PM +0800, Damon Ding wrote:
> > The raw edid for LP079QX1-SP0V panel model is:
> >
> > 00 ff ff ff ff ff ff 00 16 83 00 00 00 00 00 00
> > 04 17 01 00 a5 10 0c 78 06 ef 05 a3 54 4c 99 26
> > 0f 50 54 0
On 11/12/24 12:22, Sean Anderson wrote:
> On 11/12/24 11:43, Laurent Pinchart wrote:
>> On Tue, Nov 12, 2024 at 09:41:58AM -0500, Sean Anderson wrote:
>>> On 11/12/24 00:27, Laurent Pinchart wrote:
>>> > Hi Dan,
>>> >
>>> > Thank you for the patch.
>>> >
>>> > On Mon, Nov 11, 2024 at 12:06:10PM +
This will display the sizes of kenrel BO's bound to an open file, which are
otherwise not exposed to UM through a handle.
The sizes recorded are as follows:
- Per group: suspend buffer, protm-suspend buffer, syncobjcs
- Per queue: ringbuffer, profiling slots, firmware interface
- For all heaps
On 1/22/2025 8:23 AM, Marijn Suijten wrote:
Some SoCs such as SC7280 (used in the Fairphone 5) have only a single
DSC "hard slice" encoder. The current hardcoded use of 2:2:1 topology
(2 LM and 2 DSC for a single interface) make it impossible to use
Display Stream Compression panels with main
On 1/17/2025 8:00 AM, Jun Nie wrote:
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 b
This change reflects de facto usage by amdgpu, as exemplified by commit
d6530c33a978 ("drm/amdgpu: expose more memory stats in fdinfo").
Signed-off-by: Adrián Larumbe
Cc: Tvrtko Ursulin
Acked-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 5 -
1 file changed, 4 insertions(+
A previous commit enabled display of driver-internal kernel BO sizes
through the device file's fdinfo interface.
Expand the description of the relevant driver-specific key:value pairs
with the definitions of the new panthor-*-memory ones.
Reviewed-by: Mihail Atanassov
Reviewed-by: Liviu Dudau
R
Commit e16635d88fa0 ("drm/panthor: add DRM fdinfo support") failed to
protect access to groups with an xarray lock, which could lead to
use-after-free errors.
Signed-off-by: Adrián Larumbe
Fixes: e16635d88fa0 ("drm/panthor: add DRM fdinfo support")
---
drivers/gpu/drm/panthor/panthor_sched.c | 2
This is motivated by the desire of some drivers (eg. Panthor) to print the
size of internal memory regions with a prefix that reflects the driver
name, as suggested in the previous documentation commit.
That means adding a new argument to print_size and making it available for
DRM users.
Signed-o
This patch series enables display of the size of driver-owned shmem BO's that
aren't
exposed to userspace through a DRM handle. Also fixes a use-after-free bug in
the
existing fdinfo implementation for Panthor.
Discussion of previous revision can be found here [1].
Changelog:
v9:
- Added prope
Use the simple-audio-card driver with the hdmi0 QP node as CODEC and
the i2s5 device as CPU.
The simple-audio-card,mclk-fs value is set to 128 as it is done in
the downstream driver.
The #sound-dai-cells value is set to 0 in the hdmi0 node so that it can be
used as an audio codec node.
Signed-of
To support HDMI audio on the rk3588 based devices, the generic HDMI
Codec framework is used in the dw-hdmi-qp DRM bridge driver.
The implementation is mainly based on the downstream driver, ported to the
generic HDMI Codec framework [1] recently merged in the DRM tree.
The parameters computation h
From: Sugar Zhang
Register the dw-hdmi-qp bridge driver as an HDMI audio codec.
The register values computation functions (for n) are based on the
downstream driver, as well as the register writing functions.
The driver uses the generic HDMI Codec framework in order to implement
the HDMI audio
On 1/23/2025 1:32 PM, Abhinav Kumar wrote:
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_PINGPONG_DSC feature bit with the core_major_ver < 7 check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/ca
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_PINGPONG_DSC feature bit with the core_major_ver < 7 check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_14_msm8937.h | 2 --
drivers/gpu
On Thu Jan 23, 2025 at 11:30 PM EET, Jarkko Sakkinen wrote:
> On Thu Jan 23, 2025 at 3:53 PM EET, Vignesh Raman wrote:
> > We are working towards creating a generic, upstream GitLab-CI pipeline
> > (kci-gitlab) that will replace DRM-CI [1]. The proposed GitLab-CI pipeline
> > is designed with a dis
On Thu Jan 23, 2025 at 3:53 PM EET, Vignesh Raman wrote:
> We are working towards creating a generic, upstream GitLab-CI pipeline
> (kci-gitlab) that will replace DRM-CI [1]. The proposed GitLab-CI pipeline
> is designed with a distributed infrastructure model, making it possible
> to run on any gi
On 2025-01-17 04:19, Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:49 -0700
> Alex Hung wrote:
>
>> From: Harry Wentland
>>
>> Add kernel doc for AMD color pipeline.
>>
>> Signed-off-by: Alex Hung
>> Signed-off-by: Harry Wentland
>> ---
>> .../amd/display/amdgpu_dm/amdgpu_dm_color.c
Dumb buffers were not being freed because the GEM reference that was
acquired in gb_surface_define was not dropped like it is in the 2D case.
Dropping this ref uncovered a few additional issues with freeing the
resources associated with dirty tracking in vmw_bo_free/release.
Additionally the TTM o
On Thursday, January 23rd, 2025 at 21:06, Harry Wentland
wrote:
> On 2025-01-15 03:00, Simon Ser wrote:
>
> > Is this 125 magic number something we can expect other hardware to
> > implement as well?
>
> It's based on MS's CCCS interpretation of 80 nits as 1.0f [1]. Based on
> this definition
On Wednesday, January 22nd, 2025 at 22:05, Harry Wentland
wrote:
> On 2025-01-15 02:56, Simon Ser wrote:
>
> > Is this "ignore" something we could do at the core DRM level, instead
> > of doing it in all drivers? e.g. by silently ignoring user-space requests
> > to set the property?
>
> I thin
On 2025-01-15 03:04, Simon Ser wrote:
>> The BT.709 and BT.2020 OETFs are the same, the only difference
>> being that the BT.2020 variant is defined with more precision
>> for 10 and 12-bit per color encodings.
>
> Just to make sure, the spec defines this precision, correct? It's
> not an AMD-s
On 2025-01-17 04:06, Pekka Paalanen wrote:
> On Thu, 16 Jan 2025 10:56:22 +0200
> Pekka Paalanen wrote:
>
>> On Thu, 19 Dec 2024 21:33:37 -0700
>> Alex Hung wrote:
>>
>>> From: Harry Wentland
>>>
>>> The BT.709 and BT.2020 OETFs are the same, the only difference
>>> being that the BT.2020 va
On 2025-01-17 04:04, Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:35 -0700
> Alex Hung wrote:
>
>> From: Harry Wentland
>>
>> The PQ function defines a mapping of code values to nits (cd/m^2).
>> The max code value maps to 10,000 nits.
>>
>> Windows DWM's canonical composition color spac
On 2025-01-15 03:00, Simon Ser wrote:
> Is this 125 magic number something we can expect other hardware to
> implement as well?
>
It's based on MS's CCCS interpretation of 80 nits as 1.0f [1]. Based on
this definition one needs to use 125.0f to represent 10,000 nits,
the maximum value PQ can r
On Thu, Jan 23, 2025 at 07:23:33PM +0530, Vignesh Raman wrote:
> Add a drm scenario that includes a job to run IGT tests for vkms.
> It also includes helper scripts to build deqp-runner and IGT,
> which are based on the mesa-ci project.
>
> The xfails are added from drm-ci (drivers/gpu/drm/ci/xfai
On Thu, Jan 23, 2025 at 05:09:10PM +0200, Jani Nikula wrote:
> The expectation is that the struct drm_device based logging helpers get
> passed an actual struct drm_device pointer rather than some random
> struct pointer where you can dereference the ->dev member.
>
> Convert drm_err(sched, ...) t
On 22/01/25 22:24, Maíra Canal wrote:
In commit e4b5ccd392b9 ("drm/v3d: Ensure job pointer is set to NULL
after job completion"), we introduced a change to assign the job pointer
to NULL after completing a job, indicating job completion.
However, this approach created a race condition between th
On Tue, 2025-01-21 at 18:15 -0500, Vivi, Rodrigo wrote:
> On Tue, Jan 21, 2025 at 11:09:34AM -0800, Alan Previn wrote:
>
>
> A 'series' of 1 patch is not a series. Cover letter is not needed.
>
> However, this patch is the size of a series and it should be
> split. I'm really surprised that some
Le jeudi 23 janvier 2025 à 07:46 -0800, Linus Torvalds a écrit :
> On Thu, 23 Jan 2025 at 05:56, Vignesh Raman
> wrote:
> >
> > Documentation/ci/gitlab-ci/images/drm-vkms.png | Bin 0 -> 73810 bytes
> > .../ci/gitlab-ci/images/job-matrix.png | Bin 0 -> 2 bytes
> > .../ci/gitlab-ci/
Hi,
On Wed, Jan 22, 2025 at 10:48 PM Langyan Ye
wrote:
>
> The kingdisplay-kd110n11-51ie is a 10.95" TFT panel.
> which fits in nicely with the existing panel-boe-tv101wum-nl6 driver.
> From the datasheet, MIPI needs to keep the LP11 state before the
> lcm_reset pin is pulled high, so increase lp
Hi,
On Wed, Jan 22, 2025 at 10:48 PM Langyan Ye
wrote:
>
> KINGDISPLAY KD110N11-51IE and STARRY 2082109QFH040022-50E are
> 10.95-inch WUXGA TFT LCD panels, which fits in nicely with the
> existing panel-boe-tv101wum-nl6 driver. Hence, we add a new
> compatible with panel specific config.
FWIW, t
Hi,
On Thu, Jan 23, 2025 at 3:21 AM Langyan Ye
wrote:
>
> Add support for the STA 116QHD024002, pleace the EDID here for
> subsequent reference.
>
> 00 ff ff ff ff ff ff 00 4e 81 09 00 00 00 00 00
> 26 21 01 04 a5 1a 0e 78 02 1e b5 9a 5f 57 94 26
> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
Hi Linus,
please pull three fixes and 9 cleanup patches for fbdev for this merge window.
This series prevents a possible crash and one memory leak in omapfb
and fixes possible misbehaviour in vga16fb.
Thanks,
Helge
The following c
From: Noralf Trønnes
Remove myself as maintainer for gud, mi0283qt, panel-mipi-dbi and repaper.
My fatigue illness has finally closed the door on doing development of
even moderate complexity so it's sad to let this go.
Signed-off-by: Noralf Trønnes
---
MAINTAINERS | 12
1 file ch
The purpose of synchronize_irq is to wait for any pending IRQ handlers for the
interrupt to complete, if synchronize_irq called before interrupt disabled, an
tiny timing window created, where no more pending IRQ, but interrupt not
disabled yet. Meanwhile, if the interrupt event happened in this tim
On Fri, Jan 24, 2025 at 12:14 AM Paul-pl Chen (陳柏霖)
wrote:
>
> On Thu, 2025-01-23 at 08:21 +0100, Krzysztof Kozlowski wrote:
> >
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> >
> >
> > On 23/01/2025 07:11, Paul-pl Chen (
Hi,
On 16/01/2025 13:16, Jayesh Choudhary wrote:
For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
Any idea if any other platform than K3 is using this driver? tidss
supports DRM_BRIDGE_ATTACH_NO_CONNECTOR, so if K3 is the only user, we
could drop the legacy !DRM_BRIDGE_ATTACH_N
Quoting Jani Nikula (2025-01-23 12:14:31-03:00)
>On Thu, 23 Jan 2025, Jani Nikula wrote:
>> From: Gustavo Sousa
>>
>> The header drm_print.h uses members of struct drm_device pointers, as
>> such, it should include drm_device.h to let the compiler know the full
>> type definition.
>>
>> Without s
On Thu, Jan 23, 2025 at 04:48:29PM +0100, Christian König wrote:
>No, no there are much more cases where drivers simply assume that they
>are in the same iommu domain for different devices.
This is an illegal assumption and invalid way to use the DMA API. Do
not do that, do not architect
Am 23.01.25 um 16:02 schrieb Jason Gunthorpe:
On Thu, Jan 23, 2025 at 03:35:21PM +0100, Christian König wrote:
Sending it as text mail once more.
Am 23.01.25 um 15:32 schrieb Christian König:
Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian Kön
On Thu, 23 Jan 2025 at 05:56, Vignesh Raman wrote:
>
> Documentation/ci/gitlab-ci/images/drm-vkms.png | Bin 0 -> 73810 bytes
> .../ci/gitlab-ci/images/job-matrix.png | Bin 0 -> 2 bytes
> .../ci/gitlab-ci/images/new-project-runner.png | Bin 0 -> 607737 bytes
> .../ci/gitlab-ci/image
On Thu, 23 Jan 2025, Jani Nikula wrote:
> From: Gustavo Sousa
>
> The header drm_print.h uses members of struct drm_device pointers, as
> such, it should include drm_device.h to let the compiler know the full
> type definition.
>
> Without such include, users of drm_print.h that don't explicitly
On Thu, 23 Jan 2025, Jani Nikula wrote:
> On Thu, 23 Jan 2025, Damon Ding wrote:
>> According to the comments in include/drm/drm_print.h, the DRM_...()
>> functions are deprecated in favor of drm_...() or dev_...() functions.
>>
>> Use drm_err()/drm_dbg_core()/drm_dbg_kms() instead of
>> DRM_DEV_
On Thu, Jan 23, 2025 at 03:35:21PM +0100, Christian König wrote:
> Sending it as text mail once more.
>
> Am 23.01.25 um 15:32 schrieb Christian König:
> > Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
> > > On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian König wrote:
> > > > > > For example w
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Add a static inline helper to convert struct drm_device to struct
device, with the main benefit bein
From: Gustavo Sousa
The header drm_print.h uses members of struct drm_device pointers, as
such, it should include drm_device.h to let the compiler know the full
type definition.
Without such include, users of drm_print.h that don't explicitly need
drm_device.h would bump into build errors and be
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(sched, ...) to dev_err(sched->dev, ...) and
similar. This matches current usage, as
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(hdmi, ...) to dev_err(hdmi->dev, ...). This matches
current usage, but drops "[drm]
Fix all cases that pass something other than struct drm_device to the
drm_device based logging helpers, and add strict type checking.
Gustavo Sousa (1):
drm/print: Include drm_device.h
Jani Nikula (4):
drm/mipi-dsi: stop passing non struct drm_device to drm_err() and
friends
drm/rockchi
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(host, ...) to dev_err(host->dev, ...). This matches
current usage, as struct drm_dev
On Thu, Jan 23, 2025 at 11:20:37AM +0100, David Hildenbrand wrote:
> Hi,
>
> I keep finding issues in our implementation of "device exclusive non-swap
> entries", and the way it messes with mapcounts is disgusting.
>
> As a reminder, what we do here is to replace a PTE pointing to an anonymous
>
On Wed, Jan 22, 2025 at 04:41:32PM +0200, Jani Nikula wrote:
> Add CONFIG_DRM_HEADER_TEST to ensure drm headers are self-contained and
> pass kernel-doc. And for starters, fix one header that this catches.
>
> Jani Nikula (2):
> drm/client: include types.h to make drm_client_event.h self-contain
On 10.01.2025 16:46, Krzysztof Karas wrote:
GuC code uses in_atomic() function to determine if the current
context is atomic. As noted by the function's description it
should not be used in driver code, as it is not guaranteed to
determine atomicity correctly in every instance. This is also
poin
Sending it as text mail once more.
Am 23.01.25 um 15:32 schrieb Christian König:
Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian König wrote:
For example we have cases with multiple devices are in the same IOMMU domain
and re-using their DMA ad
Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian König wrote:
For example we have cases with multiple devices are in the same IOMMU domain
and re-using their DMA address mappings.
IMHO this is just another flavour of "private" address flow betwee
On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian König wrote:
> > > For example we have cases with multiple devices are in the same IOMMU
> > > domain
> > > and re-using their DMA address mappings.
> > IMHO this is just another flavour of "private" address flow between
> > two cooperating drive
From: Helen Koike
Add documentation of kci-gitlab.
Signed-off-by: Shreeya Patel
Signed-off-by: Vignesh Raman
Signed-off-by: Helen Koike
---
Documentation/ci/gitlab-ci/gitlab-ci.rst | 471 +++
Documentation/index.rst | 7 +
2 files changed, 478 insertion
Add a drm scenario that includes a job to run IGT tests for vkms.
It also includes helper scripts to build deqp-runner and IGT,
which are based on the mesa-ci project.
The xfails are added from drm-ci (drivers/gpu/drm/ci/xfails)
Refer to Documentation/gpu/automated_testing.rst for details
regardin
Add ci automated testing entry to MAINTAINERS to
clarify the maintainers.
Signed-off-by: Vignesh Raman
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 33fe500bf3ae..874044e570f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5473,6 +54
From: Helen Koike
This patch introduces a .gitlab-ci file in the tools/ci/gitlab-ci/
folder and other yml and script files, defining a basic test pipeline
triggered by code pushes to a GitLab-CI instance. This initial
version includes static checks (checkpatch and smatch for now),
build tests acr
This patch series introduces "kci-gitlab," a GitLab CI pipeline
specifically designed for kernel testing. It provides kernel
developers with an integrated, efficient, and flexible testing
framework using GitLab's CI/CD capabilities. This patch includes
a .gitlab-ci file in the tools/ci/gitlab-ci/ f
The driver isn't supposed to consult crtc_state->active/active_check for
resource allocation. Instead all resources should be allocated if
crtc_state->enabled is set. Stop consulting active / active_changed in
order to determine whether the hardware resources should be
(re)allocated.
Fixes: ccc862
On Thu, Jan 23, 2025 at 03:41:58PM +0800, Xu Yilun wrote:
> I don't have a complete idea yet. But the goal is not to make any
> existing driver seamlessly work with secure device. It is to provide a
> generic way for bind/attestation/accept, and may save driver's effort
> if they don't care about
The MSM driver uses drm_atomic_helper_check() which mandates that none
of the atomic_check() callbacks toggles crtc_state->mode_changed.
Perform corresponding check before calling the drm_atomic_helper_check()
function.
Fixes: 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of
As a preparation for calling dpu_encoder_get_topology() from different
code paths, simplify its calling interface, obtaining some data pointers
internally instead passing them via arguments.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder
1 - 100 of 163 matches
Mail list logo
