On 11.03.2024 11:02, Boris Brezillon wrote:
> On Wed, 6 Mar 2024 08:33:47 +
> Tvrtko Ursulin wrote:
>
> > On 06/03/2024 01:56, Adrián Larumbe wrote:
> > > Debugfs isn't always available in production builds that try to squeeze
> > > every single byte out of the kernel image, but we still need
On 2/16/24 12:03, Neil Armstrong wrote:
Add GPU nodes for the SM8650 platform.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 166 +++
1 file changed, 166 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
b/arch/arm
tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: 0e7dd6fe96020e6b7f5e068bf1c66078e0b145d3
commit: 9d9bb71f3e115b75ec5e38f087e159a87fc0413a [4/6] drm/i915: Extract
opregion vbt presence check
config: sparc64-allmodconfig
(https://download.01.org/0day-ci/archive/20240312/20240
Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP
DisplaypPort 1.2 MST hub (the same regression does not appear when using
a Cable Matters DisplayPort 1.4 MST hub). Trace:
divide error: [#1] PREEMPT SMP PTI
CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744
Hard
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: b33651a5c98dbd5a919219d8c129d0674ef74299
commit: 674dc7f61aefea81901c21402946074927e63f1a [3/3] drm/panthor: Fix
undefined panthor_device_suspend/resume symbol issue
config: x86_64-rhel-8.3-rust (attached as .config)
compiler
Hi,
On 2024/2/27 18:14, Thomas Zimmermann wrote:
Temporarily lock the fbdev buffer object during updates to prevent
memory managers from evicting/moving the buffer. Moving a buffer
object while update its content results in undefined behaviour.
Fbdev-generic updates its buffer object from a sh
On Mon, Mar 11, 2024 at 12:45:15PM +0100, Philipp Stanner wrote:
> Gentle ping because the Merge Window opened 8-)
Thanks; I'll look at this for v6.10. It's too late to add significant
changes for the v6.9 merge window since it's already open.
Bjorn
> On Fri, 2024-03-01 at 12:29 +0100, Philipp
Hi,
On 2024/2/27 18:14, Thomas Zimmermann wrote:
Acquire the buffer object's reservation lock in drm_gem_pin() and
remove locking the drivers' GEM callbacks where necessary. Same for
unpin().
DRM drivers and memory managers modified by this patch will now have
correct dma-buf locking semantics
Hi Dmitry,
kernel test robot noticed the following build errors:
[auto build test ERROR on 1843e16d2df9d98427ef8045589571749d627cf7]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/dt-bindings-display-fsl-imx-drm-drop-edid-property-support/20240311-192356
base
In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
rpm wakeref. That results in lock inversion:
<4> [197.079335] ==
<4> [197.085473] WARNING: possible circular locking dependency detected
<4> [197.091611] 6.8.0-rc7-Patchwo
Hi Thomas,
Thanks for the review and suggestions. My experience with the drm parts
of the kernel is limited to some weekends trying to fix the regression,
so I'm afraid I have some questions to check my understanding before
making a v2 of the patch.
Thomas Zimmermann writes:
> I suggest to swit
On Mon, Mar 11, 2024 at 05:43:00PM +, Tvrtko Ursulin wrote:
On 06/03/2024 19:36, Lucas De Marchi wrote:
Remove platforms that never had their PCI IDs added to the driver and
are of course marked with requiring force_probe. Note that most of the
code for those platforms is actually used by s
On Mon, Mar 11, 2024 at 07:14:09PM +0100, Janusz Krzysztofik wrote:
> On Monday, 11 March 2024 18:35:43 CET Guenter Roeck wrote:
> > On 3/11/24 09:58, Rodrigo Vivi wrote:
> > > On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> > >> In i915 hwmon sysfs getter path we now take a h
On Monday, 11 March 2024 18:35:43 CET Guenter Roeck wrote:
> On 3/11/24 09:58, Rodrigo Vivi wrote:
> > On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> >> In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
> >> rpm wakeref. That results in lock inversion
On 3/8/2024 1:45 PM, Abhinav Kumar wrote:
There are cases where the userspace might still send another
frame after the HPD disconnect causing a modeset cycle after
a disconnect. This messes the internal state machine of MSM DP driver
and can lead to a crash as there can be an imbalance between
Am 11.03.24 um 16:11 schrieb Sunil Khatri:
Add relevant ringbuffer information such as
rptr, wptr,rb mask, ring name, ring size and also
the rings content for each ring on a gpu reset.
Signed-off-by: Sunil Khatri
I think printing the mask still might be useful, but that's just a nit pick.
Wi
Hi Arnd.
On Mon, Mar 11, 2024 at 03:05:25PM +0100, Arnd Bergmann wrote:
> On Sat, Mar 9, 2024, at 19:15, Sam Ravnborg via B4 Relay wrote:
> > From: Sam Ravnborg
> >
> > The p9100 driver is only relevant for the Sparcbook 3 machine,
> > and with sun4m support removed this driver is no longer relev
On 06/03/2024 19:36, Lucas De Marchi wrote:
Remove platforms that never had their PCI IDs added to the driver and
are of course marked with requiring force_probe. Note that most of the
code for those platforms is actually used by subsequent ones, so it's
not a huge amount of code being removed.
On Mon, 11 Mar 2024 13:20:10 +0200, Dmitry Baryshkov wrote:
> The in-kernel DT files do not use ddc-i2c-bus property with the iMX LVDS
> Display Bridge. If in future a need arises to support such usecase, the
> panel-simple should be used, which is able to handle the DDC bus.
>
> Signed-off-by:
On Mon, 11 Mar 2024 13:20:09 +0200, Dmitry Baryshkov wrote:
> None of the in-kernel DT files ever used edid override with the
> fsl-imx-drm driver. In case the EDID needs to be specified manually, DRM
> core allows one to either override it via the debugfs or to load it via
> request_firmware by
On 3/11/24 09:58, Rodrigo Vivi wrote:
On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
rpm wakeref. That results in lock inversion:
<4> [197.079335]
Drop mmu models not used by LEON, including their header files.
This includes removal of unused includes in various files to fix the
build.
With this change SHMLBA is always PAGE_SIZE so use the
asm-generic variant of shmparam.h for sparc32.
__ARCH_FORCE_SHMLBA is then no longer defined, but
this
On Mon, 11 Mar 2024 at 19:06, Maxime Ripard wrote:
>
> On Mon, Mar 11, 2024 at 05:55:36PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 11 Mar 2024 at 17:46, Maxime Ripard wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Mar 09, 2024 at 12:31:32PM +0200, Dmitry Baryshkov wrote:
> > > > Setup the HDMI conn
On Mon, Mar 11, 2024 at 05:55:36PM +0200, Dmitry Baryshkov wrote:
> On Mon, 11 Mar 2024 at 17:46, Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Sat, Mar 09, 2024 at 12:31:32PM +0200, Dmitry Baryshkov wrote:
> > > Setup the HDMI connector on the MSM HDMI outputs. Make use of
> > > atomic_check hook a
When debugging functional issues with workload input processing, it is
useful to know if requests are backing up in the fifo, or perhaps
getting stuck elsewhere. To answer the question of how many requests are
in the fifo, implement a "queued" debugfs entry per-dbc that returns the
number of pendin
During the boot process of AIC100, the bootloaders (PBL and SBL) log
messages to device RAM. During SBL, if the host opens the QAIC_LOGGING
channel, SBL will offload the contents of the log buffer to the host,
and stream any new messages that SBL logs.
This log of the boot process can be very usef
Each DMA Bridge Channel (dbc) has a unique configured fifo size which is
specified by the userspace client of that dbc. Since the fifo is
circular, it is useful to know the configured size when debugging
issues.
Add a per-dbc subdirectory in debugfs and in each subdirectory add a
fifo_size entry t
Add 3 debugfs entries that can be useful in debugging a variety of
issues.
bootlog - output the device bootloader log
fifo_size - output the configured dbc fifo size
queued - output how many requests are queued in the dbc fifo
Bootlog is unique to the device, where as fifo_size/queued is per-db
On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
> rpm wakeref. That results in lock inversion:
>
> <4> [197.079335] ==
> <4> [197.085473] WARNING: po
On 3/11/2024 6:43 AM, Johan Hovold wrote:
On Sat, Mar 09, 2024 at 05:30:17PM +0100, Johan Hovold wrote:
On Fri, Mar 08, 2024 at 09:50:17AM -0800, Abhinav Kumar wrote:
On 3/8/2024 4:43 AM, Johan Hovold wrote:
For this last remaining reset with the stacktrace you have mentioned
below, I do
Am 11.03.24 um 15:48 schrieb Khatri, Sunil:
On 3/11/2024 7:29 PM, Christian König wrote:
Am 11.03.24 um 13:22 schrieb Sunil Khatri:
Add relevant ringbuffer information such as
rptr, wptr, ring name, ring size and also
the ring contents for each ring on a gpu reset.
Signed-off-by: Sunil Khat
On 3/6/2024 11:50 AM, Abhinav Kumar wrote:
There are cases where the userspace might still send another
frame after the HPD disconnect causing a modeset cycle after
a disconnect. This messes the internal state machine of MSM DP driver
and can lead to a crash as there can be an imbalance between
On Mon, Mar 11, 2024 at 10:35:20AM -0500, Lucas De Marchi wrote:
> On Mon, Mar 11, 2024 at 11:29:31AM -0400, Rodrigo Vivi wrote:
> > > @@ -2907,9 +2829,7 @@ engine_init_workarounds(struct intel_engine_cs
> > > *engine, struct i915_wa_list *wal
> > > if (engine->flags & I915_ENGINE_FIRST_RENDER_C
On Mon, Mar 11, 2024 at 10:29:45AM -0500, Lucas De Marchi wrote:
> On Mon, Mar 11, 2024 at 11:18:03AM -0400, Rodrigo Vivi wrote:
> > On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:
> > > With no platform declaring graphics/media IP_VER(12, 50),
> >
> > this is not true.
> > We sti
On Mon, Mar 11, 2024 at 06:09:29PM +0200, Imre Deak wrote:
> On Sat, Feb 10, 2024 at 09:24:59PM +, Chris Bainbridge wrote:
>
> Sorry for the delay.
>
> > The following trace occurs when using nouveau and unplugging a DP MST
> > adaptor:
> >
> > divide error: [#1] PREEMPT SMP PTI
> > C
On 11.03.24 17:09, Imre Deak wrote:
> On Sat, Feb 10, 2024 at 09:24:59PM +, Chris Bainbridge wrote:
> Sorry for the delay.
Happens, thx for looking onto this!
>> The following trace occurs when using nouveau and unplugging a DP MST
>> adaptor:
> [...]
>> +if (bpp_x16 == 0)
>> +
On Mon, Mar 11, 2024 at 05:52:59PM +0200, Jani Nikula wrote:
> On Mon, 11 Mar 2024, Liviu Dudau wrote:
> > On Mon, Mar 11, 2024 at 04:49:30PM +0200, Jani Nikula wrote:
> >> On Mon, 11 Mar 2024, Liviu Dudau wrote:
> >> > So with this revert we're OK with an undefined symbol if !CONFIG_PM, but
> >
On Sat, Feb 10, 2024 at 09:24:59PM +, Chris Bainbridge wrote:
Sorry for the delay.
> The following trace occurs when using nouveau and unplugging a DP MST
> adaptor:
>
> divide error: [#1] PREEMPT SMP PTI
> CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744
> Hardware name: Raze
On Thu, Mar 07, 2024 at 10:29:22AM +0200, Pekka Paalanen wrote:
> On Wed, 6 Mar 2024 17:42:09 +0100
> Sebastian Wick wrote:
>
> > On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote:
> > > On Tue, 5 Mar 2024 14:51:49 +0100
> > > Sebastian Wick wrote:
> > >
> > > > The initial idea
> -Original Message-
> From: Jani Nikula
> Sent: Monday, 11 March 2024 18.03
> To: Saarinen, Jani ; Linux regressions mailing list
> ; Deak, Imre
> Cc: Chris Bainbridge ; intel-gfx g...@lists.freedesktop.org>; David Airlie ; Daniel Vetter
> ; ML dri-devel
> Subject: RE: [REGRESSION] D
On Mon, 11 Mar 2024, "Saarinen, Jani" wrote:
> Hi,
>
>> -Original Message-
>> From: Intel-gfx On Behalf Of Linux
>> regression tracking (Thorsten Leemhuis)
>> Sent: Monday, 11 March 2024 17.53
>> To: Deak, Imre
>> Cc: regressi...@lists.linux.dev; Chris Bainbridge
>> ; intel-gfx ;
>> Dav
When extending support for a driver-specific KMS property to additional
drivers, we should apply all the requirements for new properties and
make sure the semantics are the same and documented.
v2: devs of the driver which introduced property shall help and ack
Signed-off-by: Sebastian Wick
---
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of Linux
> regression tracking (Thorsten Leemhuis)
> Sent: Monday, 11 March 2024 17.53
> To: Deak, Imre
> Cc: regressi...@lists.linux.dev; Chris Bainbridge
> ; intel-gfx ;
> David Airlie ; Daniel Vetter ; ML dri-devel
>
> Subject: Re
On Mon, 11 Mar 2024 at 17:46, Maxime Ripard wrote:
>
> Hi,
>
> On Sat, Mar 09, 2024 at 12:31:32PM +0200, Dmitry Baryshkov wrote:
> > Setup the HDMI connector on the MSM HDMI outputs. Make use of
> > atomic_check hook and of the provided Infoframe infrastructure.
> >
> > Note: for now only AVI Info
On 07.03.24 18:58, Chris Bainbridge wrote:
> - Forwarded message from Chris Bainbridge
> -
>
> Date: Sat, 10 Feb 2024 21:24:59 +
Hmm, it looks like nobody is looking into this regression. Is there a
good reason?
Imre, or did you maybe just miss that Chris' regression seems to be
ca
On Mon, 11 Mar 2024, Liviu Dudau wrote:
> On Mon, Mar 11, 2024 at 04:49:30PM +0200, Jani Nikula wrote:
>> On Mon, 11 Mar 2024, Liviu Dudau wrote:
>> > So with this revert we're OK with an undefined symbol if !CONFIG_PM, but
>> > we're not happy
>> > with a recursive dependency that is only trigg
Hi,
On Sat, Mar 09, 2024 at 12:31:32PM +0200, Dmitry Baryshkov wrote:
> Setup the HDMI connector on the MSM HDMI outputs. Make use of
> atomic_check hook and of the provided Infoframe infrastructure.
>
> Note: for now only AVI Infoframes are enabled. Audio Infoframes are
> currenly handled separa
Hi,
On Sat, Mar 09, 2024 at 12:31:27PM +0200, Dmitry Baryshkov wrote:
> This patchset sits on top Maxime's HDMI connector patchset ([1]).
>
> Currently this is an RFC exploring the interface between HDMI bridges
> and HDMI connector code. This has been lightly verified on the Qualcomm
> DB820c, w
Hi,
On Sat, Mar 09, 2024 at 12:31:29PM +0200, Dmitry Baryshkov wrote:
> To support connectors which do all the management on their own (like
> drm_bridge_connector), add drm_connector_hdmi_init() in addition to
> drmm_connector_hdmi_init().
>
> Signed-off-by: Dmitry Baryshkov
That's only slight
On Mon, Mar 11, 2024 at 04:49:30PM +0200, Jani Nikula wrote:
> On Mon, 11 Mar 2024, Liviu Dudau wrote:
> > On Mon, Mar 11, 2024 at 02:26:50PM +0200, Jani Nikula wrote:
> >> On Mon, 11 Mar 2024, Boris Brezillon wrote:
> >> > On Mon, 11 Mar 2024 13:51:46 +0200
> >> > Jani Nikula wrote:
> >> >
> >>
On Mon, Mar 11, 2024 at 11:29:31AM -0400, Rodrigo Vivi wrote:
@@ -2907,9 +2829,7 @@ engine_init_workarounds(struct intel_engine_cs *engine,
struct i915_wa_list *wal
if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE)
general_render_compute_wa_init(engine, wal);
-
On Mon, Mar 11, 2024 at 11:18:03AM -0400, Rodrigo Vivi wrote:
On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:
With no platform declaring graphics/media IP_VER(12, 50),
this is not true.
We still have
#define XE_HPM_FEATURES \
.__runtime.media.ip.ver = 12, \
.__
On Wed, Mar 06, 2024 at 11:36:42AM -0800, Lucas De Marchi wrote:
> PCI IDs for PVC were never added and platform always marked with
> force_probe. Drop what's not used and rename some places as needed.
>
> The registers not used anymore are also removed.
>
> Signed-off-by: Lucas De Marchi
> ---
On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:
> With no platform declaring graphics/media IP_VER(12, 50),
this is not true.
We still have
#define XE_HPM_FEATURES \
.__runtime.media.ip.ver = 12, \
.__runtime.media.ip.rel = 50
replace the
> checks throughout the
On Mon, Mar 11, 2024 at 02:43:24PM +0100, Johan Hovold wrote:
> So, while it may still be theoretically possible to hit the resets after
> the revert, the HPD notify revert effectively "fixed" the regression in
> 6.8-rc1 by removing the preconditions that now made us hit it (i.e. the
> half-initia
On Wed, Mar 06, 2024 at 11:36:40AM -0800, Lucas De Marchi wrote:
> PCI IDs for XEHPSDV were never added and platform always marked with
> force_probe. Drop what's not used and rename some places to either be
> xehp or dg2, depending on the platform/IP checks.
>
> The registers not used anymore are
From: Prike Liang
[ Upstream commit c671ec01311b4744b377f98b0b4c6d033fe569b3 ]
Currently, GPU resets can now be performed successfully on the Raven
series. While GPU reset is required for the S3 suspend abort case.
So now can enable gpu reset for S3 abort cases on the Raven series.
Signed-off-b
From: Prike Liang
[ Upstream commit c671ec01311b4744b377f98b0b4c6d033fe569b3 ]
Currently, GPU resets can now be performed successfully on the Raven
series. While GPU reset is required for the S3 suspend abort case.
So now can enable gpu reset for S3 abort cases on the Raven series.
Signed-off-b
From: Prike Liang
[ Upstream commit c671ec01311b4744b377f98b0b4c6d033fe569b3 ]
Currently, GPU resets can now be performed successfully on the Raven
series. While GPU reset is required for the S3 suspend abort case.
So now can enable gpu reset for S3 abort cases on the Raven series.
Signed-off-b
From: Christian König
[ Upstream commit 9d3f8a723c7950e56e0b95ab84b572caee29e065 ]
At least the device test requires that no other driver using TTM is
loaded. So make those unit tests depend on UML || COMPILE_TEST to
prevent people from trying them on bare metal.
Signed-off-by: Christian König
From: Matthew Auld
[ Upstream commit 2986314aa811c8a23aeb292edd30315495d54966 ]
Likely not a big deal for real users, but for consistency we should
respect the min_page_size here. Main issue is that bias allocations
turns into normal range allocation if the range and size matches
exactly, and in
From: Prike Liang
[ Upstream commit c671ec01311b4744b377f98b0b4c6d033fe569b3 ]
Currently, GPU resets can now be performed successfully on the Raven
series. While GPU reset is required for the S3 suspend abort case.
So now can enable gpu reset for S3 abort cases on the Raven series.
Signed-off-b
From: Christian König
[ Upstream commit 9d3f8a723c7950e56e0b95ab84b572caee29e065 ]
At least the device test requires that no other driver using TTM is
loaded. So make those unit tests depend on UML || COMPILE_TEST to
prevent people from trying them on bare metal.
Signed-off-by: Christian König
On Mon, 26 Feb 2024 16:10:22 -0500
Harry Wentland wrote:
> v4:
> - Drop IOCTL docs since we dropped the IOCTLs (Pekka)
> - Clarify reading and setting of COLOR_PIPELINE prop (Pekka)
> - Add blurb about not requiring to reject a pipeline due to
>incompatible ops, as long as op can be bypass
Add relevant ringbuffer information such as
rptr, wptr,rb mask, ring name, ring size and also
the rings content for each ring on a gpu reset.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drive
On Mon, 11 Mar 2024 14:41:42 +
Liviu Dudau wrote:
> On Mon, Mar 11, 2024 at 02:26:50PM +0200, Jani Nikula wrote:
> > On Mon, 11 Mar 2024, Boris Brezillon wrote:
> >
> > > On Mon, 11 Mar 2024 13:51:46 +0200
> > > Jani Nikula wrote:
> > >
> > >> On Mon, 11 Mar 2024, Boris Brezillon
> >
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++
1
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git a/d
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner
Acked-by: Heiko Stuebner
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 143 +--
The vc4_dummy_plane structure was introduced as a mean to add
mock-specific fields.
However, we never really used it and it's still strictly equivalent to
vc4_plane (which is in the same situation vs drm_plane), so we can
simply remove the vc4_dummy_plane structure and make the mock code
cleaner.
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 638 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
drivers/gpu/drm/vc4/vc4_hdmi_phy.c
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the h
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions(+)
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can gen
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus th
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 504 +
drivers/gp
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atom
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_state_h
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 65
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_tes
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 323 +
1 fil
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime R
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it f
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 32 +++
drivers/gpu/drm/tests/drm_connector_tes
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 2 ++
drivers/gpu/drm/drm_atom
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.
Reviewed-by: Dave Stevenson
Signe
Now that we're tracking the output bpc count in the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/Makefile | 1 +
.../gpu/drm/tests/drm_atomic_state_helper_test.c
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 5 +
drivers/gpu/drm/drm_atomic_state_helper.c | 20 +++
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +
1 file changed, 123 insertions(+)
A lot of the various HDMI drivers duplicate some logic that depends on
the HDMI spec itself and not really a particular hardware
implementation.
Output BPC or format selection, infoframe generation are good examples
of such areas.
This creates a lot of boilerplate, with a lot of variations, which
Hi,
Here's a series that creates some extra infrastructure specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some decent
On Mon, 11 Mar 2024, Liviu Dudau wrote:
> On Mon, Mar 11, 2024 at 02:26:50PM +0200, Jani Nikula wrote:
>> On Mon, 11 Mar 2024, Boris Brezillon wrote:
>> > On Mon, 11 Mar 2024 13:51:46 +0200
>> > Jani Nikula wrote:
>> >
>> >> On Mon, 11 Mar 2024, Boris Brezillon
>> >> wrote:
>> >> > On Mon, 11
On 3/11/2024 7:29 PM, Christian König wrote:
Am 11.03.24 um 13:22 schrieb Sunil Khatri:
Add relevant ringbuffer information such as
rptr, wptr, ring name, ring size and also
the ring contents for each ring on a gpu reset.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/amdgpu_
Hi Felix,
On 06/12/2023 21:23, Felix Kuehling wrote:
Executive Summary: We need to add CRIU support to DRM render nodes in
order to maintain CRIU support for ROCm application once they start
relying on render nodes for more GPU memory management. In this email
I'm providing some background w
On Mon, Mar 11, 2024 at 02:26:50PM +0200, Jani Nikula wrote:
> On Mon, 11 Mar 2024, Boris Brezillon wrote:
> > On Mon, 11 Mar 2024 13:51:46 +0200
> > Jani Nikula wrote:
> >
> >> On Mon, 11 Mar 2024, Boris Brezillon wrote:
> >> > On Mon, 11 Mar 2024 13:16:19 +0200
> >> > Jani Nikula wrote:
> >>
On Sat, Mar 9, 2024, at 19:15, Sam Ravnborg via B4 Relay wrote:
> From: Sam Ravnborg
>
> The p9100 driver is only relevant for the Sparcbook 3 machine,
> and with sun4m support removed this driver is no longer relevant.
>
> Signed-off-by: Sam Ravnborg
> Acked-by: Arnd Bergmann
> Acked-by: Thomas
On Mon, 11 Mar 2024 14:59:39 +0100
Boris Brezillon wrote:
> On Mon, 11 Mar 2024 14:58:37 +0100
> Boris Brezillon wrote:
>
> > On Mon, 11 Mar 2024 13:46:23 +
> > Steven Price wrote:
> >
> > > On 11/03/2024 13:36, Robin Murphy wrote:
> > > > On 2024-03-11 1:22 pm, Boris Brezillon wrot
1 - 100 of 183 matches
Mail list logo