From: Hermes Wu
For supporting audio form I2S to DP audio data sub stream.
Add hdmi_audio callbacks to drm_bridge_funcs for the HDMI codec
framework.
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/ite-it6505.c | 46 +
1 file changed, 46 insertions(+)
d
Hi,
On 05/02/2025 07:53, Devarsh Thakkar wrote:
Hi Tomi
Thanks for pointing out, I probably missed this since the use-case still
worked since VP interrupts were still enabled and those were sufficient to
drive the display
but the VID underflow interrupts and VID specific bits were probably not
From: Hermes Wu
Add DRM_BRIDGE_OP_HDMI to bridge.ops and implement necessary callback
functions.
The native AVI and AUDIO infoframe configuration API are removed.
In .atomic_enable use
drm_atomic_helper_connector_hdmi_update_infoframes().
for infoframe updates.
Signed-off-by: Hermes Wu
---
d
For supporting audio form I2S to DP audio data sub stream.
Add hdmi_audio callbacks to drm_bridge_funcs for the HDMI codec
framework.
The DRM_BRIDGE_OP_HDMI flag in bridge.ops must be set,
and implement necessary callbacks for the drm_bridge_connector
to enable the HDMI codec.
Signed-off-by:
The Falcon DMA engine allows queueing multiple operations for
improved performance. Do this to optimize firmware loading.
A performance improvement of 4x to 6x is observed.
Co-developed-by: Ivan Raul Guadarrama
Signed-off-by: Ivan Raul Guadarrama
Signed-off-by: Mikko Perttunen
---
drivers/gpu/
Hi Tomi,
Thanks for the review.
On 04/02/25 19:25, Tomi Valkeinen wrote:
>> description: |
>> - The AM625 and AM65x TI Keystone Display SubSystem with two output
>> + The AM625 and AM65x TI Keystone Display SubSystem has two output
>> ports and two video planes. In AM65x DSS, the first
Hi Tomi
>> Thanks for pointing out, I probably missed this since the use-case still
>> worked since VP interrupts were still enabled and those were sufficient to
>> drive the display
>> but the VID underflow interrupts and VID specific bits were probably not
>> enabled at-all due to above miss, so
On Tue, Feb 04, 2025 at 03:57:32PM +0100, Maxime Ripard wrote:
> It's pretty inconvenient to access the full atomic state from
> drm_bridges, so let's change the atomic_disable hook prototype to pass
> it directly.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/bridge/analogix/analogix
On Tue, Feb 04, 2025 at 03:57:30PM +0100, Maxime Ripard wrote:
> It's pretty inconvenient to access the full atomic state from
> drm_bridges, so let's change the atomic_pre_enable hook prototype to
> pass it directly.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/bridge/analogix/analo
On Tue, Feb 04, 2025 at 03:57:31PM +0100, Maxime Ripard wrote:
> It's pretty inconvenient to access the full atomic state from
> drm_bridges, so let's change the atomic_enable hook prototype to pass it
> directly.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/bridge/analogix/analogix_
On Tue, Feb 04, 2025 at 04:46:04PM +0100, Krzysztof Kozlowski wrote:
> On 04/02/2025 15:26, Dmitry Baryshkov wrote:
> > On Tue, Feb 04, 2025 at 10:21:25AM +0100, Krzysztof Kozlowski wrote:
> >> On 03/02/2025 18:41, Dmitry Baryshkov wrote:
> >>> On Mon, Feb 03, 2025 at 06:29:19PM +0100, Krzysztof Ko
On Tue, Feb 04, 2025 at 01:29:23PM -0800, Jessica Zhang wrote:
>
>
> On 1/29/2025 2:11 PM, Dmitry Baryshkov wrote:
> > On Tue, Jan 28, 2025 at 07:20:39PM -0800, Jessica Zhang wrote:
> > > Add support for RM to reserve dedicated CWB PINGPONGs and CWB muxes
> > >
> > > For concurrent writeback, ev
Hi Dmitry, Maxime,
On 12/30/2024, Liu Ying wrote:
> Add myself as the maintainer of i.MX8qxp Display Controller.
>
> Signed-off-by: Liu Ying
> ---
> v8:
> * No change.
>
> v7:
> * No change.
>
> v6:
> * No change.
>
> v5:
> * No change.
>
> v4:
> * No change.
>
> v3:
> * No change.
>
> v2:
Hi Detlev,
On 2/3/25 6:16 PM, Detlev Casanova wrote:
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 s
Hi Detlev,
Just some drive-by comment inline.
On 2/3/25 6:16 PM, 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 functi
On 2/4/25 7:22 AM, Maarten Lankhorst wrote:
> Ignore my previous series please, it should have been sent to intel-xe, was
> sent to intel-gfx.
>
> Instead of all this repetition of
>
> {
> unsigned fw_ref;
>
> fw_ref = xe_force_wake_get(fw, domain);
> if (!xe_force_wake_ref_ha
Hi Detlev,
On 2/3/25 6:16 PM, Detlev Casanova wrote:
HDMI audio is available on the Rock 5B HDMI TX port.
Enable it.
Signed-off-by: Detlev Casanova
Reviewed-by: Quentin Schulz
Will try to remember to send patches for RK3588 Tiger Haikou and RK3588
Jaguar once those patches get merged :)
Use an enum instead of #defines for panthor IOCTLs. This allows the
header to be used with Rust code as bindgen can't handle complex
defines.
Cc: Beata Michalska
Signed-off-by: Rob Herring (Arm)
---
include/uapi/drm/panthor_drm.h | 86 +-
1 file changed, 44 inser
On 2025-02-04 17:21, Mario Limonciello wrote:
> From: Mario Limonciello
>
> find_system_memory() pulls out two fields from an SMBIOS type 17
> device and sets them on KFD devices. This however is pulling from
> the middle of the field in the SMBIOS device and leads to an unaligned
> access.
>
On Tue, Feb 04, 2025 at 11:28:03PM +0100, Maarten Lankhorst wrote:
> Hey,
>
>
> On 2025-02-04 17:30, Michal Wajdeczko wrote:
> > Hi Maarten,
> >
> > On 04.02.2025 14:22, Maarten Lankhorst wrote:
> > > Instead of finding bugs where we may or may not release force_wake, I've
> > > decided to be in
Due to resource reprovisioning, sometimes a need arises to move
a living address space to a new area, preserving all the nodes
and holes stored within.
It is possible to do that by removing all nodes to a temporary list,
reiniting the drm_mm instance and re-adding everything while applying
a shift
This RFC asks for introduction of an interface which allows to shift
a range managed by drm_mm instance without repeating the node list
creation.
The long explanation:
Single Root I/O Virtualization is becoming a standard GFX feature
in server environments. Virtual Machines provided with direct a
Hey,
On 2025-02-04 17:30, Michal Wajdeczko wrote:
Hi Maarten,
On 04.02.2025 14:22, Maarten Lankhorst wrote:
Instead of finding bugs where we may or may not release force_wake, I've
decided to be inspired by the spinlock guards, and use the same ones to
do xe_force_wake handling.
You may wan
From: Mario Limonciello
find_system_memory() pulls out two fields from an SMBIOS type 17
device and sets them on KFD devices. This however is pulling from
the middle of the field in the SMBIOS device and leads to an unaligned
access.
Instead use a struct representation to access the members and
On Fri, Jan 31, 2025 at 09:47:52AM +0200, Gwan-gyeong Mun wrote:
>
>
> On 1/29/25 9:51 PM, Matthew Brost wrote:
> > Add migrate_device_pfns which prepares an array of pre-populated device
> > pages for migration. This is needed for eviction of known set of
> > non-contiguous devices pages to cpu
On Tue, 2025-02-04 at 15:16 -0400, Jason Gunthorpe wrote:
> On Tue, Feb 04, 2025 at 03:29:48PM +0100, Thomas Hellström wrote:
> > On Tue, 2025-02-04 at 09:26 -0400, Jason Gunthorpe wrote:
> > > On Tue, Feb 04, 2025 at 10:32:32AM +0100, Thomas Hellström wrote:
> > > >
> > >
> > > > 1) Existing use
On 1/29/2025 2:11 PM, Dmitry Baryshkov wrote:
On Tue, Jan 28, 2025 at 07:20:39PM -0800, Jessica Zhang wrote:
Add support for RM to reserve dedicated CWB PINGPONGs and CWB muxes
For concurrent writeback, even-indexed CWB muxes must be assigned to
even-indexed LMs and odd-indexed CWB muxes for
On Tue, Feb 4, 2025 at 1:46 PM Danilo Krummrich wrote:
>
> On Mon, Feb 03, 2025 at 03:24:10PM -0500, Joel Fernandes wrote:
> > Hi Danilo,
> >
> > On Fri, Jan 31, 2025 at 11:04:24PM +0100, Danilo Krummrich wrote:
> > > +#[pin_data]
> > > +pub(crate) struct NovaCore {
> > > +#[pin]
> > > +pu
Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain
could have been left as NULL. The NULL domain is specially recognized by
host1x_iommu_attach() as meaning it is not the DMA domain and
should be replaced with the special shared domain.
This happened prior to the below comm
On Tue, Feb 04, 2025 at 03:29:48PM +0100, Thomas Hellström wrote:
> On Tue, 2025-02-04 at 09:26 -0400, Jason Gunthorpe wrote:
> > On Tue, Feb 04, 2025 at 10:32:32AM +0100, Thomas Hellström wrote:
> > >
> >
> > > 1) Existing users would never use the callback. They can still rely
> > > on
> > > th
Add the initial documentation of the Nova project.
The initial project documentation consists out of a brief introduction
of the project, as well as project guidelines both general and nova-core
specific and a task list for nova-core specifically.
The task list is divided into tasks for general R
Add the initial nova-core driver stub.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova project, including nova-core and nova-drm, in
On Tue, Feb 04, 2025 at 06:42:46PM +, Timur Tabi wrote:
> On Fri, 2025-01-31 at 23:04 +0100, Danilo Krummrich wrote:
> > +/// Structure encapsulating the firmware blobs required for the GPU to
> > operate.
> > +#[allow(dead_code)]
> > +pub(crate) struct Firmware {
> > +booter_load: firmwar
On Tue, Feb 04, 2025 at 06:40:41PM +, Timur Tabi wrote:
> On Fri, 2025-01-31 at 23:04 +0100, Danilo Krummrich wrote:
> > +Rust abstraction for debugfs APIs.
> > +
> > +| Reference: Export GSP log buffers
> > +| Complexity: Beginner
>
> Seriously?
Well, that seems indeed a bit optimistic. :-)
On Tue, 4 Feb 2025 18:11:01 +0100
Maxime Ripard wrote:
> On Tue, Feb 04, 2025 at 04:34:04PM +0100, Herve Codina wrote:
> > On Tue, 4 Feb 2025 16:17:10 +0100
> > Maxime Ripard wrote:
> >
> > > Hi,
> > >
> > > On Fri, Jan 17, 2025 at 09:12:13AM +0100, Herve Codina wrote:
> > > > Hi Maxime,
>
On Mon, Feb 03, 2025 at 03:24:10PM -0500, Joel Fernandes wrote:
> Hi Danilo,
>
> On Fri, Jan 31, 2025 at 11:04:24PM +0100, Danilo Krummrich wrote:
> > +#[pin_data]
> > +pub(crate) struct NovaCore {
> > +#[pin]
> > +pub(crate) gpu: Gpu,
> > +}
>
> I am curious what is the need for pinning
On Fri, 2025-01-31 at 23:04 +0100, Danilo Krummrich wrote:
> +/// Structure encapsulating the firmware blobs required for the GPU to
> operate.
> +#[allow(dead_code)]
> +pub(crate) struct Firmware {
> +booter_load: firmware::Firmware,
> +booter_unload: firmware::Firmware,
> +gsp: firmw
On Fri, 2025-01-31 at 23:04 +0100, Danilo Krummrich wrote:
> +Rust abstraction for debugfs APIs.
> +
> +| Reference: Export GSP log buffers
> +| Complexity: Beginner
Seriously?
Le lundi 03 février 2025 à 16:43 +, Florent Tomasin a écrit :
> Hi Maxime, Nicolas
>
> On 30/01/2025 17:47, Nicolas Dufresne wrote:
> > Le jeudi 30 janvier 2025 à 17:38 +0100, Maxime Ripard a écrit :
> > > Hi Nicolas,
> > >
> > > On Thu, Jan 30, 2025 at 10:59:56AM -0500, Nicolas Dufresne wrot
On 2/4/2025 11:46, Lizhi Hou wrote:
On 2/4/25 09:40, Mario Limonciello wrote:
From: Mario Limonciello
Initramfs building tools such as dracut will look for a MODULE_FIRMWARE()
declaration to determine which firmware to include in the initramfs
when a driver is included in the initramfs.
As a
Hi Florent,
Le lundi 03 février 2025 à 13:36 +, Florent Tomasin a écrit :
>
> On 30/01/2025 13:28, Maxime Ripard wrote:
> > Hi,
> >
> > On Thu, Jan 30, 2025 at 01:08:57PM +, Florent Tomasin wrote:
> > > Introduce a CMA Heap dt-binding allowing custom
> > > CMA heap registrations.
> > >
On Mon, 30 Sep 2024 18:24:44 +0200
neil.armstr...@linaro.org wrote:
> On 30/09/2024 17:05, Hugo Villeneuve wrote:
> > On Mon, 30 Sep 2024 16:38:14 +0200
> > Neil Armstrong wrote:
> >
> >> Hi,
> >>
> >> On 27/09/2024 15:53, Hugo Villeneuve wrote:
> >>> From: Hugo Villeneuve
> >>>
> >>> In jadard
On Tue, Feb 04, 2025 at 03:33:53PM +, Biju Das wrote:
> Hi Thierry Reding,
>
> > -Original Message-
> > From: Thierry Reding
> > Sent: 04 February 2025 15:25
> > Subject: Re: [PATCH] drm/tegra: rgb: Simplify tegra_dc_rgb_probe()
> >
> > On Tue, Feb 04, 2025 at 09:07:05AM +, Biju
On 2/4/25 09:40, Mario Limonciello wrote:
From: Mario Limonciello
Initramfs building tools such as dracut will look for a MODULE_FIRMWARE()
declaration to determine which firmware to include in the initramfs
when a driver is included in the initramfs.
As amdxdna doesn't declare any firmware
Commit d3d6b1bf85ae ("drm: bridge: dw_hdmi: fix preference of RGB modes
over YUV420") changed the order of the output bus formats, but missed to
update accordingly the "Possible output formats" comment section above
dw_hdmi_bridge_atomic_get_output_bus_fmts().
Fix the misleading comment block and
From: Mario Limonciello
Initramfs building tools such as dracut will look for a MODULE_FIRMWARE()
declaration to determine which firmware to include in the initramfs
when a driver is included in the initramfs.
As amdxdna doesn't declare any firmware this causes the driver to fail
to load with -E
On 04/02/2025 17:24, Rodrigo Vivi wrote:
On Tue, Feb 04, 2025 at 12:35:27PM +0530, Raag Jadav wrote:
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 d
On Tue, Feb 04, 2025 at 12:35:27PM +0530, Raag Jadav wrote:
> 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
On Tue, Feb 04, 2025 at 12:35:26PM +0530, Raag Jadav wrote:
> 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 us
On Mo, 2025-02-03 at 19:15 +0100, Michal Wilczynski wrote:
>
> On 1/31/25 16:39, Matt Coster wrote:
> > On 28/01/2025 19:48, Michal Wilczynski wrote:
> > > Add reset controller driver for the T-HEAD TH1520 SoC that manages
> > > hardware reset lines for various subsystems. The driver currently
> >
On Tue, Feb 04, 2025 at 04:34:04PM +0100, Herve Codina wrote:
> On Tue, 4 Feb 2025 16:17:10 +0100
> Maxime Ripard wrote:
>
> > Hi,
> >
> > On Fri, Jan 17, 2025 at 09:12:13AM +0100, Herve Codina wrote:
> > > Hi Maxime,
> > >
> > > On Thu, 16 Jan 2025 09:38:45 +0100
> > > Maxime Ripard wrote:
>
This patchset is extracted from [1]. The goal is to introduce the YUV
support, thanks to Arthur's work.
- PATCH 1: Add the support of YUV formats
- PATCH 2: Add some drm properties to expose more YUV features
- PATCH 3: Cleanup the todo
- PATCH 4..6: Add some kunit tests
- PATCH 7: Add the support
This add the support for:
- R1/R2/R4/R8
R1 format was tested with [1] and [2].
[1]:
https://lore.kernel.org/r/20240313-new_rotation-v2-0-6230fd5ca...@bootlin.com
[2]:
https://lore.kernel.org/igt-dev/20240306-b4-kms_tests-v1-0-8fe451efd...@bootlin.com/
Reviewed-by: Pekka Paalanen
Signed-off-by
From: Arthur Grillo
Create KUnit tests to test the conversion between YUV and RGB. Test each
conversion and range combination with some common colors.
The code used to compute the expected result can be found in comment.
[Louis Chauvet:
- fix minor formating issues (whitespace, double line)
- c
From: Arthur Grillo
Now that we have KUnit tests, add instructions on how to run them.
Signed-off-by: Arthur Grillo
Reviewed-by: José Expósito
Acked-by: Pekka Paalanen
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git
The functions drm_get_color_encoding_name and drm_get_color_range_name
are useful for clarifying test results. Therefore, export them so they
can be used in tests built as modules.
Reviewed-by: José Expósito
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/drm_color_mgmt.c | 3 +++
1 file chang
From: Arthur Grillo
VKMS has support for YUV formats now. Remove the task from the TODO
list.
Signed-off-by: Arthur Grillo
Acked-by: Pekka Paalanen
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentatio
From: Arthur Grillo
Now that the driver internally handles these quantization ranges and YUV
encoding matrices, expose the UAPI for setting them.
Signed-off-by: Arthur Grillo
[Louis Chauvet: retained only relevant parts, updated the commit message]
Acked-by: Pekka Paalanen
Signed-off-by: Louis
From: Arthur Grillo
Add support to the YUV formats bellow:
- NV12/NV16/NV24
- NV21/NV61/NV42
- YUV420/YUV422/YUV444
- YVU420/YVU422/YVU444
The conversion from yuv to rgb is done with fixed-point arithmetic, using
32.32 fixed-point numbers and the drm_fixed helpers.
To do the conversion, a spec
crtc_set_mode() deals with calling the modeset related hooks for CRTC,
connectors and bridges if and when a new commit changes them. It takes
the drm_atomic_state being committed as a parameter.
However, that parameter name is called as old_state, which is pretty
confusing. Let's rename that varia
Hi Maarten,
On 04.02.2025 14:22, Maarten Lankhorst wrote:
> Instead of finding bugs where we may or may not release force_wake, I've
> decided to be inspired by the spinlock guards, and use the same ones to
> do xe_force_wake handling.
You may want to take a look at [1], which was based on [2], t
Am 03.02.25 um 16:30 schrieb Tvrtko Ursulin:
Add a very simple TDR test which submits a single job and verifies that
the TDR handling will run if the backend failed to complete the job in
time.
I think I said it before but I strongly suggest to not use TDR as name
in the scheduler at all.
Wh
The tc358768 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
This was due to the fact that we did't have any other alternative to
retrieve the CRTC pointer. Fortunately, the crtc pointer is now provided
in the bridge state, so we can move to
drm_atomic_helper_wait_for_dependencies() waits for all the dependencies
a commit has before going forward with it. It takes the drm_atomic_state
being committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that varia
On Tue, Feb 04, 2025 at 04:48:43PM +0100, Krzysztof Kozlowski wrote:
> On 04/02/2025 15:28, Dmitry Baryshkov wrote:
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 31
> --
> .../gpu/drm/msm/registers/display/dsi_phy_7nm.xml | 12 +++--
> 2 file
On Tue, 04 Feb 2025, Imre Deak wrote:
> On Thu, Dec 19, 2024 at 11:34:05PM +0200, Jani Nikula wrote:
>> Enable basic 128b/132b SST functionality without compression. Reuse
>> intel_dp_mtp_tu_compute_config() to figure out the TU after we've
>> determined we need to use an UHBR rate.
>>
>> It's sl
On 31/01/2025 11:03, Pierre-Eric Pelloux-Prayer wrote:
A fence uniquely identify a job, so this commits updates the places
where a kernel pointer was used as an identifier by:
"fence=%llu:%llu"
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h
Am 04.02.25 um 08:05 schrieb Raag Jadav:
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
On 04/02/2025 15:28, Dmitry Baryshkov wrote:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 31
--
.../gpu/drm/msm/registers/display/dsi_phy_7nm.xml | 12 +++--
2 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu
On 04/02/2025 15:26, Dmitry Baryshkov wrote:
> On Tue, Feb 04, 2025 at 10:21:25AM +0100, Krzysztof Kozlowski wrote:
>> On 03/02/2025 18:41, Dmitry Baryshkov wrote:
>>> On Mon, Feb 03, 2025 at 06:29:19PM +0100, Krzysztof Kozlowski wrote:
PHY_CMN_CLK_CFG1 register is updated by the PHY driver an
On 04/02/2025 15:27, Dmitry Baryshkov wrote:
struct dsi_pll_7nm *pll_7nm = to_pll_7nm(phy->vco_hw);
- void __iomem *base = phy->base;
u32 data = 0x0; /* internal PLL */
DBG("DSI PLL%d", pll_7nm->phy->id);
@@ -635,7 +634,7 @@ static int dsi_7nm_set_usecase(s
Hi Luca,
On Wed, Jan 29, 2025 at 12:51:46PM +0100, Luca Ceresoli wrote:
> > > > > For hotplugging we cannot use drmm and devm and instead we use
> > > > > get/put,
> > > > > to let the "next bridge" disappear with the previous one still
> > > > > present.
> > > > > So the trivial idea is to add
On Tue, Feb 04, 2025 at 02:22:34PM +0100, Maarten Lankhorst wrote:
---
drivers/gpu/drm/xe/xe_devcoredump.c | 36 ++---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c
b/drivers/gpu/drm/xe/xe_devcoredump.c
index 39fe485d20
On Thu, Dec 19, 2024 at 11:34:05PM +0200, Jani Nikula wrote:
> Enable basic 128b/132b SST functionality without compression. Reuse
> intel_dp_mtp_tu_compute_config() to figure out the TU after we've
> determined we need to use an UHBR rate.
>
> It's slightly complicated as the M/N computation is d
On Tue, Feb 04, 2025 at 04:10:37PM +0800, Pin-yen Lin wrote:
> Hi Hermes,
>
> On Tue, Feb 4, 2025 at 11:49 AM wrote:
> >
> > Hi
> > >
> > >-Original Message-
> > >From: Dmitry Baryshkov
> > >Sent: Tuesday, February 4, 2025 1:28 AM
> > >To: Hermes Wu (吳佳宏)
> > >Cc: Andrzej Hajda ; Neil A
On Tue, 4 Feb 2025 16:17:10 +0100
Maxime Ripard wrote:
> Hi,
>
> On Fri, Jan 17, 2025 at 09:12:13AM +0100, Herve Codina wrote:
> > Hi Maxime,
> >
> > On Thu, 16 Jan 2025 09:38:45 +0100
> > Maxime Ripard wrote:
> >
> > > On Tue, Jan 14, 2025 at 01:54:56PM +0100, Herve Codina wrote:
> > > >
Hi Thierry Reding,
> -Original Message-
> From: Thierry Reding
> Sent: 04 February 2025 15:25
> Subject: Re: [PATCH] drm/tegra: rgb: Simplify tegra_dc_rgb_probe()
>
> On Tue, Feb 04, 2025 at 09:07:05AM +, Biju Das wrote:
> > Hi Geert,
> >
> > Thanks for the feedback.
> >
> > > -O
Hi,
On 28/01/2025 15:16, Devarsh Thakkar wrote:
Hi Aradhya,
On 18/01/25 14:57, Aradhya Bhatia wrote:
Hi Devarsh,
Thanks for the patches.
Thanks for the review.
On 31/12/24 14:34, Devarsh Thakkar wrote:
Enable display for AM62L DSS [1] which supports only a single display
pipeline using
On 31/01/2025 11:03, Pierre-Eric Pelloux-Prayer wrote:
Trace the fence dependencies similarly to how we print fences:
... , dependencies:{fence=606:38006}
This allows tools to analyze the dependencies between the jobs (previously
it was only possible for fences traced by drm_sched_job_wait_
On Tue, Feb 04, 2025 at 02:22:32PM +0100, Maarten Lankhorst wrote:
Instead of finding bugs where we may or may not release force_wake, I've
decided to be inspired by the spinlock guards, and use the same ones to
do xe_force_wake handling.
Examples are added as documentation in xe_force_wake.c
S
On Tue, Feb 04, 2025 at 02:22:31PM +0100, Maarten Lankhorst wrote:
Those calls should be from xe_gt_init, not the diverse amount of places
they are called.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/xe/xe_gt.c | 31 ++-
1 file changed, 14 insertions(+), 17 d
On Tue, Feb 04, 2025 at 09:07:05AM +, Biju Das wrote:
> Hi Geert,
>
> Thanks for the feedback.
>
> > -Original Message-
> > From: dri-devel On Behalf Of
> > Geert Uytterhoeven
> > Sent: 03 February 2025 11:06
> > Subject: Re: [PATCH] drm/tegra: rgb: Simplify tegra_dc_rgb_probe()
> >
drm_atomic_bridge_chain_enable() enables all bridges affected by a new
commit. It takes the drm_atomic_state being committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Signed-off-by: Maxime
On Tue, 2025-02-04 at 09:26 -0400, Jason Gunthorpe wrote:
> On Tue, Feb 04, 2025 at 10:32:32AM +0100, Thomas Hellström wrote:
> >
>
> > 1) Existing users would never use the callback. They can still rely
> > on
> > the owner check, only if that fails we check for callback
> > existence.
> > 2) By
A bridge is considered atomic-enabled if it has an atomic_check
implementation. However, atomic_check is optional and thus a driver
might very well not provide an implementation, and yet still be atomic.
Switch to atomic_reset, which allocates the initial bridge state and is
thus a better candidat
Hi,
On Fri, Jan 17, 2025 at 09:12:13AM +0100, Herve Codina wrote:
> Hi Maxime,
>
> On Thu, 16 Jan 2025 09:38:45 +0100
> Maxime Ripard wrote:
>
> > On Tue, Jan 14, 2025 at 01:54:56PM +0100, Herve Codina wrote:
> > > Hi Maxime,
> > >
> > > On Tue, 14 Jan 2025 08:40:51 +0100
> > > Maxime Ripard
Now that connectors are no longer necessarily created by the bridges
drivers themselves but might be created by drm_bridge_connector, it's
pretty hard for bridge drivers to retrieve pointers to the connector and
CRTC they are attached to.
Indeed, the only way to retrieve the CRTC is to follow the
Other entities (drm_connector.crtc, drm_encoder.crtc, etc.) have
pointer to other currently bound entities. They are all considered
relevant only for non-atomic drivers, and generally perceived as
deprecated in favour of the equivalent pointers in the atomic states.
It used to be useful because we
drm_atomic_helper_update_legacy_modeset_state() updates all the legacy
modeset pointers a connector, encoder or CRTC might have with the ones
being setup by a given commit. It takes the drm_atomic_state being
committed as a parameter.
However, that parameter name is called (and documented) as old_
The tc358775 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
This was due to the fact that we did't have any other alternative to
retrieve the CRTC pointer. Fortunately, the crtc pointer is now provided
in the bridge state, so we can move to
The TI sn65dsi86 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
This was due to the fact that we did't have any other alternative to
retrieve the CRTC pointer. Fortunately, the crtc pointer is now provided
in the bridge state, so we can mov
The Cadence DSI driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
This was due to the fact that we did't have any other alternative to
retrieve the CRTC pointer. Fortunately, the crtc pointer is now provided
in the bridge state, so we can move
drm_atomic_helper_cleanup_planes() is one of the final part of a commit,
and will free up all plane resources used in the previous commit. It
takes the drm_atomic_state being committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing.
The drm_bridge structure contains an encoder pointer that is widely used
by bridge drivers. This pattern is largely documented as deprecated in
other KMS entities for atomic drivers.
However, one of the main use of that pointer is done in attach to just
call drm_bridge_attach on the next bridge to
The current bridge state is accessible from the drm_bridge structure,
but since it's fairly indirect it's not easy to figure out.
Provide a helper to retrieve it.
Signed-off-by: Maxime Ripard
---
include/drm/drm_bridge.h | 21 +
1 file changed, 21 insertions(+)
diff --git a
drm_atomic_helper_wait_for_flip_done() will wait for pages flips on all
CRTCs affected by a given commit. It takes the drm_atomic_state being
committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as sta
drm_atomic_helper_wait_for_dependencies() is the final part of a commit
and signals it completion. It takes the drm_atomic_state being committed
as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Si
drm_atomic_helper_fake_vblank() fake a vblank event if needed when a new
commit is being applied. It takes the drm_atomic_state being committed
as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Sig
drm_atomic_helper_commit_hw_done() signals hardware completion of a
given commit. It takes the drm_atomic_state being committed as a
parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Signed-off-by: Maxi
drm_atomic_helper_wait_for_vblanks() waits for vblank events on all the
CRTCs affected by a commit. It takes the drm_atomic_state being
committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
S
1 - 100 of 220 matches
Mail list logo
