On Fri, Nov 21, 2025 at 02:06:41PM -0800, Matthew Brost wrote:
On Thu, Nov 20, 2025 at 11:48:13AM -0800, Niranjana Vishwanathapura wrote:
On Wed, Nov 19, 2025 at 02:41:03PM -0800, Matthew Brost wrote:
> If the firmware is not running during TDR (e.g., when the driver is
> unloading), there's no
On Fri, Nov 21, 2025 at 01:25:58PM -0800, Matthew Brost wrote:
On Thu, Nov 20, 2025 at 11:50:32AM -0800, Niranjana Vishwanathapura wrote:
On Wed, Nov 19, 2025 at 02:41:04PM -0800, Matthew Brost wrote:
> Deregistering queues in the TDR introduces unnecessary complexity,
> requiring reference-coun
On Thu, Nov 20, 2025 at 11:48:13AM -0800, Niranjana Vishwanathapura wrote:
> On Wed, Nov 19, 2025 at 02:41:03PM -0800, Matthew Brost wrote:
> > 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, ski
On Thu, Nov 20, 2025 at 12:33:12PM -0800, Umesh Nerlige Ramappa wrote:
> On Wed, Nov 19, 2025 at 02:41:06PM -0800, Matthew Brost wrote:
> > We now have proper infrastructure to accurately check the LRC timestamp
> > without toggling the scheduling state for non-VFs. For VFs, it is still
> > possibl
On Thu, Nov 20, 2025 at 11:50:32AM -0800, Niranjana Vishwanathapura wrote:
> On Wed, Nov 19, 2025 at 02:41:04PM -0800, Matthew Brost wrote:
> > Deregistering queues in the TDR introduces unnecessary complexity,
> > requiring reference-counting techniques to function correctly,
> > particularly to p
On Fri, Nov 21, 2025 at 04:48:02PM +0100, Maxime Ripard wrote:
> On Tue, Oct 14, 2025 at 07:02:03PM +0300, Dmitry Baryshkov wrote:
> > On Tue, Oct 14, 2025 at 02:43:58PM +0200, Maxime Ripard wrote:
> > > On Fri, Oct 03, 2025 at 06:41:58PM +0300, Dmitry Baryshkov wrote:
> > > > On 03/10/2025 17:23,
On Tue, Oct 14, 2025 at 07:02:03PM +0300, Dmitry Baryshkov wrote:
> On Tue, Oct 14, 2025 at 02:43:58PM +0200, Maxime Ripard wrote:
> > On Fri, Oct 03, 2025 at 06:41:58PM +0300, Dmitry Baryshkov wrote:
> > > On 03/10/2025 17:23, Maxime Ripard wrote:
> > > > On Thu, Sep 25, 2025 at 05:55:06PM +0300,
Hi,
On Thu, 30 Oct 2025 20:46:35 +0530, Devarsh Thakkar wrote:
> The sii902x driver was caching HDMI detection state in a sink_is_hdmi field
> and checking it in mode_set() to determine whether to set HDMI or DVI
> output mode. This approach had two problems:
>
> 1. With DRM_BRIDGE_ATTACH_NO_CONN
commit c9b1150a68d9362a0827609fc0dc1664c0d8bfe1
"drm/atomic-helper: Re-order bridge chain pre-enable and post-disable"
caused regressions in all bridges that e.g. send DSI commands in
their .prepare() and .unprepare() callbacks when used with R-Car DU.
This is needed on R-Car DU, where the CRTC pr
commit c9b1150a68d9362a0827609fc0dc1664c0d8bfe1
"drm/atomic-helper: Re-order bridge chain pre-enable and post-disable"
caused a series of regressions in all panels that send
DSI commands in their .prepare() and .unprepare()
callbacks when used with MCDE.
As the CRTC is no longer online at bridge_p
Export and namespace those not prefixed with drm_* so
it becomes possible to write custom commit tail functions
in individual drivers using the helper infrastructure.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/drm_atomic_helper.c | 54 +
include/drm/drm_
This fixes two regressions experienced in the MCDE and
R-Car DU DRM drivers after
commit c9b1150a68d9362a0827609fc0dc1664c0d8bfe1
"drm/atomic-helper: Re-order bridge chain pre-enable and post-disable"
caused a series of regressions in all panels that send
DSI commands in their .prepare() and .unpre
On Wed, Nov 19, 2025 at 02:41:06PM -0800, Matthew Brost wrote:
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-ru
On Wed, Nov 19, 2025 at 02:41:04PM -0800, Matthew Brost wrote:
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
On Wed, Nov 19, 2025 at 02:41:03PM -0800, Matthew Brost wrote:
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 Bro
On Wed, Nov 19, 2025 at 02:41:05PM -0800, Matthew Brost wrote:
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 me
On Wed, Nov 19, 2025 at 02:41:02PM -0800, Matthew Brost wrote:
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 pendin
On Wed, Nov 19, 2025 at 02:41:00PM -0800, Matthew Brost wrote:
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
On Wed, Nov 19, 2025 at 02:40:59PM -0800, Matthew Brost wrote:
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)
On Wed, Nov 19, 2025 at 01:41:18PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 19 November 2025 10:09:12 Central European Standard Time Maxime
> Ripard wrote:
> > Hi,
> >
> > On Mon, Nov 17, 2025 at 08:11:51PM +0100, Nicolas Frattaroli wrote:
> > > With the introduction of the "color format"
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
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/
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 and OPP tables.
The commit log seems need an update for the regulator par
> From: Gert Wollny
>
> v2: Check for feature PIPE_3D when forcing PPU flop reset (Lucas)
>
> v3: - drop use of ppu_flop_reset enum (Christian Gmeiner)
> - don't initialize module parameter to zero (checkpatch)
> - avoid multi-line string in warning message (checkpatch)
>
> Signed-off-by:
On Tuesday, 18 November 2025 21:14:31 Central European Standard Time Cristian
Ciocaltea wrote:
> On 11/17/25 9:11 PM, Nicolas Frattaroli wrote:
> > With the introduction of the supported_formats member in the
> > dw-hdmi-qp platform data struct, drivers that have access to this
> > information sho
On Tuesday, 18 November 2025 21:00:08 Central European Standard Time Cristian
Ciocaltea wrote:
> Hi Nicolas,
>
> On 11/17/25 9:11 PM, Nicolas Frattaroli wrote:
> > The drm_bridge "supported_formats" member stores a bitmask of supported
> > HDMI output formats if the bridge is in fact an HDMI brid
On Wednesday, 19 November 2025 05:32:46 Central European Standard Time Laurent
Pinchart wrote:
> On Mon, Nov 17, 2025 at 08:11:48PM +0100, Nicolas Frattaroli wrote:
> > The new DRM color format property allows userspace to request a specific
> > color format on a connector. In turn, this fills the
On Wednesday, 19 November 2025 05:16:48 Central European Standard Time Laurent
Pinchart wrote:
> On Mon, Nov 17, 2025 at 08:11:47PM +0100, Nicolas Frattaroli wrote:
> > From: Marius Vlad
> >
> > This would please the compiler to have a enum transformation from one to
> > another even though the
On Wednesday, 19 November 2025 10:09:12 Central European Standard Time Maxime
Ripard wrote:
> Hi,
>
> On Mon, Nov 17, 2025 at 08:11:51PM +0100, Nicolas Frattaroli wrote:
> > With the introduction of the "color format" DRM property, which allows
> > userspace to request a specific color format, th
On Mon, Nov 17, 2025 at 08:11:54PM +0100, Nicolas Frattaroli wrote:
> From: Derek Foreman
>
> Register the color format property in the dw_hdmi_qp-rockchip driver,
> and act on requested format changes as part of the connector state in
> the vop2 video output driver.
>
> Signed-off-by: Derek For
Hi,
On Mon, Nov 17, 2025 at 08:11:51PM +0100, Nicolas Frattaroli wrote:
> With the introduction of the "color format" DRM property, which allows
> userspace to request a specific color format, the HDMI state helper
> should implement this.
>
> Implement it by checking whether the property is set
On Mon, Nov 17, 2025 at 08:11:48PM +0100, Nicolas Frattaroli wrote:
> The new DRM color format property allows userspace to request a specific
> color format on a connector. In turn, this fills the connector state's
> color_format member to switch color formats.
>
> Make drm_bridges consider the c
On Mon, Nov 17, 2025 at 08:11:50PM +0100, Nicolas Frattaroli wrote:
> With the introduction of the supported_formats member in the
> dw-hdmi-qp platform data struct, drivers that have access to this
> information should now set it.
>
> Set it in the rockchip dw_hdmi_qp glue driver, where such a bi
On Mon, Nov 17, 2025 at 08:11:49PM +0100, Nicolas Frattaroli wrote:
> The drm_bridge "supported_formats" member stores a bitmask of supported
> HDMI output formats if the bridge is in fact an HDMI bridge.
It would be nice to convert the supported_formats field to a bitmask of
DRM_MODE_COLOR_FORMAT
On Mon, Nov 17, 2025 at 08:11:47PM +0100, Nicolas Frattaroli wrote:
> From: Marius Vlad
>
> This would please the compiler to have a enum transformation from one to
> another even though the values are the same. It should also make things
The hdmi_colorspace enumerators are defined as (with comm
On Mon, Nov 17, 2025 at 08:11:46PM +0100, Nicolas Frattaroli wrote:
> From: Andri Yngvason
>
> Adds a new general DRM property named "color format" which can be used by
s/Adds/Add/
> userspace to force the display driver output a particular color format.
>
> Possible options are:
> - auto
On 11/17/25 9:11 PM, Nicolas Frattaroli wrote:
> With the introduction of the supported_formats member in the
> dw-hdmi-qp platform data struct, drivers that have access to this
> information should now set it.
>
> Set it in the rockchip dw_hdmi_qp glue driver, where such a bitmask of
> supported
Hi Nicolas,
On 11/17/25 9:11 PM, Nicolas Frattaroli wrote:
> The drm_bridge "supported_formats" member stores a bitmask of supported
> HDMI output formats if the bridge is in fact an HDMI bridge.
>
> However, until now, the synopsys dw-hdmi-qp driver did not set this
> member in the bridge it cre
On 11/18/2025 9:26 PM, Connor Abbott wrote:
> On Tue, Nov 18, 2025 at 3:53 AM Akhil P Oommen
> wrote:
>>
>> AQE (Applicaton Qrisc Engine) is a dedicated core inside CP which aides
>> in Raytracing related workloads. Add support for loading the AQE firmware
>> and initialize the necessary register
On Tue, Nov 18, 2025 at 3:53 AM Akhil P Oommen wrote:
>
> AQE (Applicaton Qrisc Engine) is a dedicated core inside CP which aides
> in Raytracing related workloads. Add support for loading the AQE firmware
> and initialize the necessary registers.
>
> Since AQE engine has dependency on preemption
On 11/18/25 9:50 AM, Akhil P Oommen wrote:
> Crashdec doesn't require SCRATCH registers anymore for a6xx and newer
> architectures. So skip dumping them during recovery.
>
> Suggested-by: Rob Clark
> Signed-off-by: Akhil P Oommen
> ---
Reviewed-by: Konrad Dybcio
Konrad
base: d1d18879e01e4c9efcb85a96d188a8e4326136dd
patch link:
https://lore.kernel.org/r/20251117-color-format-v4-2-0ded72bd1b00%40collabora.com
patch subject: [PATCH v4 02/10] drm: Add new general DRM property "color format"
config: arm-randconfig-001-20251118
(https://download.01.o
[email protected]
>> Cc: Kandpal, Suraj ; Manna, Animesh
>> ; Hogander, Jouni
>>
>> Subject: Re: [PATCH v4 02/10] drm/i915/alpm: alpm_init() for DP2.1
>>
>> On Thu, 13 Nov 2025, Animesh Manna wrote:
>> > Initialize ALPM for DP2.1 and separate out
, Jouni
>
> Subject: Re: [PATCH v4 02/10] drm/i915/alpm: alpm_init() for DP2.1
>
> On Thu, 13 Nov 2025, Animesh Manna wrote:
> > Initialize ALPM for DP2.1 and separate out ALPM mutex-init from
> > alpm-init.
>
> I thought I said you're going to need multiple init
On 11/18/25 9:50 AM, Akhil P Oommen wrote:
> AQE (Applicaton Qrisc Engine) is a dedicated core inside CP which aides
> in Raytracing related workloads. Add support for loading the AQE firmware
> and initialize the necessary registers.
>
> Since AQE engine has dependency on preemption context recor
On 11/18/25 9:50 AM, Akhil P Oommen wrote:
> REG_A6XX_GMU_AO_AHB_FENCE_CTRL register falls under GMU's register
> range. So, use gmu_write() routines to write to this register.
>
> Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
> Cc: [email protected]
> Signed-off-by: Akhil P Oommen
Adreno 840 GPU supports UBWC v6. Add support for this.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a8xx_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
index 30de078e9dfd..5a320f5bde41 1
Document Adreno X2-85 GMU found in Glymur chipsets in the
dt-binding specification. It is very similar to Adreno 840
GMU with the additional requirement of RSCC HUB clock.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Akhil P Oommen
---
.../devicetree/bindings/display/msm/gmu.yaml | 30 +++
Document Adreno 840 GMU in the dt-binding specification.
Acked-by: Rob Herring (Arm)
Signed-off-by: Akhil P Oommen
---
.../devicetree/bindings/display/msm/gmu.yaml | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/
Update the devicetree bindings to document the GPU SMMUs present in
Kaanapali and Glymur chipsets.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Akhil P Oommen
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree
Adreno X2-85 GPU is found in the next generation of Qualcomm's compute
series chipset called Snapdragon X2 Elite (a.k.a Glymur). It is based
on the new A8x slice architecture and features up to 4 slices. Due to
the wider 12 channel DDR support, there is higher DDR bandwidth available
than previous
GMU lies on the CX domain and accesses CX GBIF. So do CX GBIF
configurations before GMU wakes up. This was not a problem so far, but
A840 GPU is very sensitive to this requirement. Also, move these
registers to the catalog.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_catalo
Adreno 840 present in Kaanapali SoC is the second generation GPU in
A8x family. It comes in 2 variants with either 2 or 3 Slices. This is
in addition to the SKUs supported based on the GPU FMAX.
Add the necessary register configurations to the catalog and enable
support for it.
Reviewed-by: Dmitr
AQE (Applicaton Qrisc Engine) is a dedicated core inside CP which aides
in Raytracing related workloads. Add support for loading the AQE firmware
and initialize the necessary registers.
Since AQE engine has dependency on preemption context records, expose
Raytracing support to userspace only when
A8x is the next generation of Adreno GPUs, featuring a significant
hardware design change. A major update to the design is the introduction
of Slice architecture. Slices are sort of mini-GPUs within the GPU which
are more independent in processing Graphics and compute workloads. Also,
in addition t
A8x GMU firmwares expect a separate vote table which describes the
relationship between the Gx rail and MxA rail (and possibly Cx rail).
Create this new vote table and implement the new HFI message which
allows passing vote tables to send this data to GMU.
Signed-off-by: Akhil P Oommen
---
drive
Current logic assumes that the voltage corners in both MxG and MxA are
always same. This is not true for recent targets. So, rework the rpmh init
sequence to probe and calculate the votes with the respective rails, ie,
GX rails should use MxG as secondary rail and Cx rail should use MxA as
the seco
A8x GMU configurations are very similar to A7x. Unfortunately, there are
minor shuffling in the register offsets in the GMU CX register region.
So, update the driver to use the correct register offsets on A8x hw.
Some A8x GPUs have more than 16 powerlevels on GX domain and 4 on CX
domain. To accom
GMU registers are always at a fixed offset from the GPU base address,
a consistency maintained at least within a given architecture generation.
In A8x family, the base address of the GMU has changed, but the offsets
of the gmu registers remain largely the same. To enable reuse of the gmu
code for A
Move MMU fault handler for each generation to adreno function list. This
will help to use common code for mmu pagefault handler registration between
a6x/a7x and a8x layer.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 5 -
drivers/
Move the gbif halt fn to adreno_gpu_func so that we can call different
implementation from common code. This will come handy when we implement
A8x layer.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 ++--
drivers/gpu/drm/msm/adreno/
In A6x family (which is a pretty big one), there are separate
adreno_func definitions for each sub-generations. To streamline the
identification of the correct struct for a gpu, move it to the
catalogue and move the gpu_init routine to struct adreno_gpu_funcs.
Signed-off-by: Akhil P Oommen
---
d
Newer gen's introduce pipe enums which do not exist on older gens, but
the numeric values do not conflict. IOW, they are backward compatible.
So move its definition to adreno_common.xml.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
Crashdec doesn't require SCRATCH registers anymore for a6xx and newer
architectures. So skip dumping them during recovery.
Suggested-by: Rob Clark
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/dri
Correct the register offset and enable this workaround for all A7x
and newer GPUs to match the recommendation. Also, downstream does this
w/a after moving the fence to allow mode. So do the same.
Fixes: dbfbb376b50c ("drm/msm/a6xx: Add A621 support")
Reviewed-by: Konrad Dybcio
Signed-off-by: Akhi
As per the recommendation, A7x and newer GPUs should flush the LRZ cache
before switching the pagetable. Update a6xx_set_pagetable() to do this.
While we are at it, sync both BV and BR before issuing a
CP_RESET_CONTEXT_STATE command, to match the downstream sequence.
Fixes: af66706accdf ("drm/msm
REG_A6XX_GMU_AO_AHB_FENCE_CTRL register falls under GMU's register
range. So, use gmu_write() routines to write to this register.
Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
Cc: [email protected]
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2
This series adds the A8xx HWL along with Adreno 840 GPU support to the
drm-msm driver. A8x is the next generation in the Adreno family,
featuring a significant hardware design change. A major update to the
design is the introduction of 'Slice' architecture. Slices are sort of
mini-GPUs within the G
nder, Jouni
>
> Subject: RE: [PATCH v4 05/10] drm/i915/alpm: Auxless wake time calculation
> for Xe3p
>
> > Subject: [PATCH v4 05/10] drm/i915/alpm: Auxless wake time calculation
> > for Xe3p
> >
> > Add support for auxless waketime calculation for DP2.1 ALPM
nder, Jouni
>
> Subject: RE: [PATCH v4 06/10] drm/i915/alpm: Half LFPS cycle calculation
>
> > Subject: [PATCH v4 06/10] drm/i915/alpm: Half LFPS cycle calculation
> >
> > Add support for half LFPS cycle calculation for DP2.1 ALPM as
> > dependent parameter
From: Derek Foreman
Register the color format property in the dw_hdmi_qp-rockchip driver,
and act on requested format changes as part of the connector state in
the vop2 video output driver.
Signed-off-by: Derek Foreman
Signed-off-by: Marius Vlad
Signed-off-by: Nicolas Frattaroli
---
drivers/
The "color format" DRM property allows userspace to explicitly pick a
color format to use. If an unsupported color format is requested,
userspace will be given an error instead of silently having its request
disobeyed.
The default case, in which the property is either unset or set to Auto,
picks Y
This includes RGB, YUV420, YUV444 and Auto. Auto will pick RGB, unless
the mode being asked for is YUV420-only, in which case it picks YUV420,
with a fallback for RGB in place just as a last-ditch attempt.
Should the explicitly requested color format not be supported by the
sink, then an error is
With the introduction of the "color format" DRM property, which allows
userspace to request a specific color format, the HDMI state helper
should implement this.
Implement it by checking whether the property is set and set to
something other than auto. If so, pass the requested color format, and
o
With the introduction of the supported_formats member in the
dw-hdmi-qp platform data struct, drivers that have access to this
information should now set it.
Set it in the rockchip dw_hdmi_qp glue driver, where such a bitmask of
supported color formats already exists. It just needs to be converted
The drm_bridge "supported_formats" member stores a bitmask of supported
HDMI output formats if the bridge is in fact an HDMI bridge.
However, until now, the synopsys dw-hdmi-qp driver did not set this
member in the bridge it creates.
Set it based on the platform data's supported_formats member, a
Hello,
this is a follow-up to
https://lore.kernel.org/all/[email protected]/
which in of itself is a follow-up to
https://lore.kernel.org/dri-devel/[email protected]/
where
a new DRM connector property has been added allowing users to
force a
The new DRM color format property allows userspace to request a specific
color format on a connector. In turn, this fills the connector state's
color_format member to switch color formats.
Make drm_bridges consider the color_format set in the connector state
during the atomic bridge check. Specifi
From: Marius Vlad
This would please the compiler to have a enum transformation from one to
another even though the values are the same. It should also make things
obvious that we use different enums.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/drm_connector.c | 18 ++
includ
From: Andri Yngvason
Adds a new general DRM property named "color format" which can be used by
userspace to force the display driver output a particular color format.
Possible options are:
- auto (setup by default, driver internally picks the color format)
- rgb
- ycbcr444
- ycbc
From: Werner Sembach
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB whe
On Thu, 13 Nov 2025, Animesh Manna wrote:
> Initialize ALPM for DP2.1 and separate out ALPM mutex-init
> from alpm-init.
I thought I said you're going to need multiple init functions. Don't
move the alpm mutex init away from alpm code. It needs to stay in alpm
code.
And now the whole patch and s
On 31/10/2025 10:05, Iker Pedrosa wrote:
> +
> +static void st7920_hw_reset(struct st7920_device *st7920)
> +{
> + if (!st7920->reset_gpio)
> + return;
> +
> + gpiod_set_value_cansleep(st7920->reset_gpio, 0);
> + usleep_range(15, 20);
> + gpiod_set_value_cansleep(st7920-
Am 31.10.25 um 10:05 schrieb Iker Pedrosa:
Add Iker as ST7920 driver maintainer.
Signed-off-by: Iker Pedrosa
Reviewed-by: Thomas Zimmermann
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
5ddf37f0acc960039422ef988cadfa717697
Hi,
please see my review below. The overall driver looks good. There are
some points that need to be discussed.
Am 31.10.25 um 10:05 schrieb Iker Pedrosa:
Add a new DRM/KMS driver for displays using the Sitronix ST7920
controller connected via the SPI bus. This provides a standard
framebuffer
> Subject: [PATCH v4 06/10] drm/i915/alpm: Half LFPS cycle calculation
>
> Add support for half LFPS cycle calculation for DP2.1 ALPM as dependent
> parameters got changed.
>
> v1: Initial version.
> v2: Avoid returning early. [Jani]
> v3: Use intel_crtc_has_type()
> Subject: [PATCH v4 07/10] drm/i915/alpm: Program LTTPR count for DP 2.1
> ALPM
>
> Issue a AUX write transaction to DPCD DP_TOTAL_LTTPR_CNT (0xf000a) with
> total number of LTTPR before link training.
>
> v2: Cosmetic changes. [Suraj]
>
> Cc: Jouni Högander
>
> Subject: [PATCH v4 05/10] drm/i915/alpm: Auxless wake time calculation for
> Xe3p
>
> Add support for auxless waketime calculation for DP2.1 ALPM as dependent
> parameter got changed.
>
> v1: Initial version.
> v2: Use intel_dp_is_uhbr(). [Jani]
>
Add Bspec no.
> From: Gert Wollny
>
> The PPU flop reset is required on some hardware to clear the
> temporary registers. This code follows the implementation
> of the PPU flop reset as found in the public galcore kernel
> module. Compared to that code some superfluous parts were
> removed and only the code pat
> From: Gert Wollny
>
> v2: fix formatting and remove superfluous masking (Lucas)
>
> Signed-off-by: Gert Wollny
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etna
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 and OPP tables.
The commit log seems need an update for the regulator part?
Shawn
>
> Reviewed-by: Frank Li
Hi Karunika,
This series doesn't seem to cleanly apply on drm-misc-next (and I can't
figure out what base you used). Would you mind doing a rebase and resend?
Thanks,
Steve
On 07/11/2025 14:24, Karunika Choo wrote:
> This patch series extends the Panthor driver with basic support for
> Mali-G1 G
1 - 100 of 5508 matches
Mail list logo
