On 13. 12. 24, 6:46, Yafang Shao wrote:
Since task->comm is guaranteed to be NUL-terminated, we can print it
directly without the need to copy it into a separate buffer. This
simplifies the code and avoids unnecessary operations.
Signed-off-by: Yafang Shao
Cc: Ofir Bitton
Cc: Oded Gabbay
Cc:
[AMD Official Use Only - AMD Internal Distribution Only]
Looks good to me as well, With Christian's comment accommodated:
Acked-by: Shashank Sharma
Regards
Shashank
From: Koenig, Christian
Sent: Friday, December 13, 2024 8:34 AM
To: André Almeida ; Raag Jadav ;
== Series Details ==
Series: PSR DSB support
URL : https://patchwork.freedesktop.org/series/142520/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15836 -> Patchwork_142520v1
Summary
---
**FAILURE**
Serious unknown
Am 12.12.24 um 20:09 schrieb 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.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
1 file changed, 3 inserti
== Series Details ==
Series: PSR DSB support
URL : https://patchwork.freedesktop.org/series/142520/
State : warning
== Summary ==
Error: dim checkpatch failed
934567a608a7 drm/i915/psr: Use PSR2_MAN_TRK_CTL CFF bit only to send full update
3ad4c4831274 drm/i915/psr: Rename psr_force_hw_trackin
== Series Details ==
Series: PSR DSB support
URL : https://patchwork.freedesktop.org/series/142520/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced
== Series Details ==
Series: Extended Wake Timeout
URL : https://patchwork.freedesktop.org/series/142517/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M] drivers/gpu/drm/i915/display/intel_dp_link_train
This patch set is doing necessary modifications to support PSR update
using DSB on LunarLake onwards
It is not necessary to wait for PSR1 to idle or PSR2 to exit DEEP
sleep at the begin of commit This is left out from DSB commit. There
might be room for optimization for non-DSB as well because suc
We are preparing for a change where only frontbuffer flush will use
single full frame bit of a new register (SFF_CTL) available on LunarLake
onwards.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
This is a clean-up and a preparation for adding own SFF and CFF registers
for LunarLake onwards.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 88 +---
1 file changed, 31 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/
Allow writing PSR2_MAN_TRK_CTL using DSB by using intel_de_write_dsb. Do
not check intel_dp->psr.lock being held when using DSB. This assertion
doesn't make sense as in case of using DSB the actual write happens later
and we are not taking intel_dp->psr.lock mutex over dsb commit.
Signed-off-by: J
Do needed changes to handle PSR2_MAN_TRK_CTL correctly when DSB is in use:
1. Write PSR2_MAN_TRK_CTL in commit_pipe_pre_planes only when not using
DSB.
2. Add PSR2_MAN_TRK_CTL writing into DSB commit in
intel_atomic_dsb_finish.
Taking PSR lock over DSB commit is not needed because PSR2_MAN_
Now as we have correct PSR2_MAN_TRK_CTL handling in place we can allow DSB
usage also when PSR is enabled for LunarLake onwards.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i9
We have different approach on how flip is considered being complete. We are
waiting for vblank on DSB and generate interrupt when it happens and this
interrupt is considered as indication of completion -> we definitely do not
want to skip vblank wait.
Also not skipping scanline wait shouldn't caus
Bspec says this for SFF/CFF:
"Hardware samples this bit on the start of every V. Blank Guardband
region. For deterministic behavior, Software should ensure it is not
changing this bit around the sample point."
This can be achieved by using intel_vblank_evade.
Signed-off-by: Jouni Högander
---
psr_force_hw_tracking_exit is misleading name as it is used for PSR1, PSR2
HW tracking and PSR2 selective fetch. Due to this rename it as
intel_psr_force_update.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 8
1 file changed, 4 insertions(+), 4 deletions(
In LunarLake we have SFF_CTL register which contains SFF bit ored with
respective SFF bit in PSR2_MAN_TRK_CTL register. Use this register instead
of the bit in PSR2_MAN_TRK_CTL on frontbuffer tracking callbacks. This
helps us avoiding taking psr mutex when performing atomic commit.
We don't need t
Add register definitions for SFF_CTL and CFF_CTL registers. Name them as
LNL_SFF_CTL and LNL_CFF_CTL.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr_regs.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_psr_regs.h
b/drive
On Wed, Nov 27, 2024 at 08:36:09PM +, Patchwork wrote:
Patch Details
Series: Fix some races/bugs in GuC engine busyness (rev4)
URL: [1]https://patchwork.freedesktop.org/series/141522/
State: failure
Details:
[2]https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_141522v4/index.html
Add DPCD registers required to configure Extended Wake Timeout
for LTTPR.
Signed-off-by: Suraj Kandpal
---
include/drm/display/drm_dp.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index a6f8b098c56f..480370bba1de
Usually retimers take around 30 to 40ms to exit all devices from
sleep state. Extended wake timeout request helps to give additional
time by reading the DPCD register through which sink requests the
minimal amount of time required to wake the sink up and giving the
same amount of wait requested by
Retimers in H/w usually takes 30 to 40ms to wake up all the devices. To
get this we use the Extended Wake Time feature in which the sink device
tells us the minimum amount of time it requires to wake up and we need
to do a write to grant this request else we need to wake up within 1ms
of low power
Dave, Simona
This week'd drm-xe-fixes PR.
Thanks,
Thomas
drm-xe-fixes-2024-12-12:
- Fix a KUNIT test error message (Mirsad Todorovac)
- Fix an invalidation fence PM ref leak (Daniele)
- Fix a register pool UAF (Lucas)
The following changes since commit 5dce85fecb87751ec94526e1ac516dd7871e2e0c:
== Series Details ==
Series: drm/{i915,xe}: Convert to DRM client setup
URL : https://patchwork.freedesktop.org/series/142498/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15832 -> Patchwork_142498v1
Summary
---
**S
== Series Details ==
Series: drm/{i915,xe}: Convert to DRM client setup
URL : https://patchwork.freedesktop.org/series/142498/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
The value preferred_bpp in struct intel_fbdev duplicates preferred_bpp
in struct drm_fb_helper. Remove the former.
Instead let intel_fbdev_init_bios() read the framebuffer from the
hardware. Then derive preferred_bpp from its format and initialize
struct drm_fb_helper with the value. The default i
Implement drm_client_dev_suspend() and drm_client_dev_resume() for
i915's fbdev emulation and call the helper via DRM client interfaces.
This is required to convert i915 and xe to DRM's generic fbdev client.
No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display
Rework fbdev probing to support fbdev_probe in struct drm_driver
and remove the old fb_probe callback. Provide an initializer macro
that sets the callback in struct drm_driver according to the kernel
configuration. Call drm_client_setup_with_color_mode() to run the
kernel's default client setup for
If fbdev support has been disabled, no output will be shown. Remove
the fbdev-related compile guard from the driver's debugfs code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/
The callback fb_probe in struct drm_fb_helper is unused. Remove it.
New drivers should set struct drm_driver.fbdev_probe instead and call
drm_client_setup() to instantiate in-kernel DRM clients.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 8
include/drm/drm_f
Move fbdev code around in the source file before switching to DRM's
generic fbdev client. This will make the conversion less intrusive.
No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 85 +++---
1 file changed, 44 insertion
i915 and xe are the last remaining drivers that still implement their
own fbdev client. All other clients have been mass converted to DRM's
client setup in in the series at [1]. As Intel drivers require more
effort than others, their changes have been moved into this separate
series.
With DRM's cl
If the fbdev buffer is backed by stolen memory, it has to be cleared
upon resume from hibernation. Move the code into the new callback
fb_set_suspend, so that it can run from DRM's generic fbdev client.
No functional change. Other drivers are not affected.
Signed-off-by: Thomas Zimmermann
---
dr
The DRM client code already tracks suspend status and hotplug events
for each client. Remove similar code from i915's fbdev client.
Allows for the removal of all hdp_* fields form struct intel_fbdev.
Calls to intel_fbdev_output_poll_changed() are reduced the shared
helper drm_fb_helper_hotplug_eve
Move client hotplug calls to drm_client_hotplug(). We'll need this
helper to send hotplug events after resuming.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_client_event.c | 32 ++
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gp
Store instances of drm_fb_helper and struct intel_fbdev separately.
This will allow i915 to use the common fbdev client, which allocates
its own instance of struct drm_fb_helper.
There is at most one instance of type each per DRM device, so both can
be referenced directly from the i915 and DRM dev
If a hotplug event arrives while the client has been suspended,
DRM's client code will deliver the event after resuming. The
functionality has been taken form i915, where it can be removed
by a later commit.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_client_event.c | 9 +
i
i915's fbdev contains code for restoring the client's framebuffer. It
is specific to i195 and cannot be ported to the common fbdev client.
Introduce the callback struct drm_fb_helper.fb_restore and implement
it for i915. The fbdev helpers invoke the callback after restoring the
fbdev client.
Sign
-Original Message-
From: Intel-xe On Behalf Of Nemesa Garg
Sent: Thursday, December 12, 2024 6:33 AM
To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
Cc: Garg, Nemesa
Subject: [PATCH 2/2] drm/i915/display: Initialize pipe_src in compute stage
>
> Add early pipe src ini
-Original Message-
From: Intel-gfx On Behalf Of Nemesa
Garg
Sent: Thursday, December 12, 2024 6:33 AM
To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
Cc: Garg, Nemesa
Subject: [PATCH 1/2] drm/i915/display: After joiner compute pfit_dst
>
> In panel fitter/pipe scaler
== Series Details ==
Series: Consider joiner calculation for panel fitting (rev6)
URL : https://patchwork.freedesktop.org/series/136561/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15831 -> Patchwork_136561v6
Summary
When memory stats is generated fresh everytime by going though all the
BOs, their active information is quite easy to get. But if the stats are
tracked with BO's state this becomes harder since the job scheduling
part doesn't really deal with individual buffers.
Make drm-active- optional to enable
== Series Details ==
Series: drm/display: use ERR_PTR on DP tunnel manager creation fail (rev3)
URL : https://patchwork.freedesktop.org/series/142423/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15831 -> Patchwork_142423v3
On Wed, 11 Dec 2024 at 02:25, Greg KH wrote:
>
> On Tue, Dec 10, 2024 at 06:19:00PM -0500, Rodrigo Vivi wrote:
> > On Sun, Dec 08, 2024 at 03:17:27PM +, Ed Maste wrote:
> > > These two files (i915_live_selftests.h, i915_mock_selftests.h) were
> > > introduced in commit 953c7f82eb89 ("drm/i915:
Hi Rodrigo,
On Fri, Dec 06, 2024 at 10:38:24AM -0500, Rodrigo Vivi wrote:
> On Thu, Dec 05, 2024 at 03:47:35PM +, Sebastian Brzezinka wrote:
> > `wa_verify`sporadically detects lost workaround on application; this
> > is unusual behavior since wa are applied at `intel_gt_init_hw` and
> > verif
Add early pipe src initialization for gmch and later
initialize the pipe src during compute_pipe_src.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_display.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/in
There is an issue when pch_pfit and joiner gets enabled together.
Compute final pfit dst after pipe_src width is adjusted for joiner.
Nemesa Garg (2):
drm/i915/display: After joiner compute pfit_dst
drm/i915/display: Initialize pipe_src in compute stage
drivers/gpu/drm/i915/display/intel_di
In panel fitter/pipe scaler scenario the pch_pfit configuration
currently takes place before accounting for pipe_src width for
joiner. This causes issue when pch_pfit and joiner get enabled
together.So once pipe src is computed adjust the pfit_dst.
It can be done by computing per pipe output area f
On Wed, Dec 11, 2024 at 07:32:08PM +0100, Maarten Lankhorst wrote:
> Hey Jani,
>
> I believe at least for the platforms xe cares about (gen12+), display is
> sufficiently separated that everything can be performed in a single init
> call before we enable interrupts.
>
> Because of the strict sepa
On 2024-12-12 at 11:51:58 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/display: use ERR_PTR on DP tunnel manager creation fail (rev2)
> URL : https://patchwork.freedesktop.org/series/142423/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_15830 -> Pat
== Series Details ==
Series: drm/dp: Rework LTTPR transparent mode handling and add support to msm
driver (rev2)
URL : https://patchwork.freedesktop.org/series/140804/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_hea
On Tue, 2024-12-10 at 16:18 +0100, Stanislaw Gruszka wrote:
>
> The problem will disappear after applying:
> https://lore.kernel.org/stable/20241209175416.59433-1-
> stanislaw.grus...@linux.intel.com/
> since the allocation will not longer fail.
>
> ...
> Regards
> Stanislaw
I confirm that (6.12
On 24-12-11 11:55:54, Dmitry Baryshkov wrote:
> On Wed, Dec 11, 2024 at 11:08:16AM +0200, Abel Vesa wrote:
> > On 24-10-31 18:54:25, Dmitry Baryshkov wrote:
> > > On Thu, Oct 31, 2024 at 05:12:48PM +0200, Abel Vesa wrote:
> > > > Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPo
According to the DisplayPort standard, LTTPRs have two operating
modes:
- non-transparent - it replies to DPCD LTTPR field specific AUX
requests, while passes through all other AUX requests
- transparent - it passes through all AUX requests.
Switching between this two modes is done by the DPT
On Tue, 2024-12-10 at 13:37 +0100, Greg Kroah-Hartman wrote:
> > t's a clue nonetheless.
>
> 'git bisect' would be nice to run if possible...
Done:
a) One (hopefully) small caveat :
the very first bisect hit the 6.12.2 bug of missing commit b23decf8ac91
("sched: Initialize idle tasks only once")
Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
1.4a specification. As the name suggests, these PHY repeaters are
capable of adjusting their output for link training purposes.
According to the DisplayPort standard, LTTPRs have two operating
modes:
- non-transparent - it re
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them, which
is handling the explicit disabling of non-transparent mode and its
disable->enable sequence mentioned in the DP Standard v2.0 section
3.6.6.1.
So use the new
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them, which
is handling the explicit disabling of non-transparent mode and its
disable->enable sequence mentioned in the DP Standard v2.0 section
3.6.6.1.
So use the new
On 24-10-31 18:44:55, Dmitry Baryshkov wrote:
> On Thu, Oct 31, 2024 at 05:12:46PM +0200, Abel Vesa wrote:
> > LTTPRs operating modes are defined by the DisplayPort standard and the
> > generic framework now provides a helper to switch between them.
> > So use the drm generic helper instead as it m
On 24-10-31 18:54:25, Dmitry Baryshkov wrote:
> On Thu, Oct 31, 2024 at 05:12:48PM +0200, Abel Vesa wrote:
> > Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
> > 1.4a specification. As the name suggests, these PHY repeaters are
> > capable of adjusting their output for link
Looking at both i915 and nouveau DP drivers, both are setting the first
LTTPR (if found) in transparent mode first and then in non-transparent
mode, just like the DP v2.0 specification mentions in section 3.6.6.1.
Being part of the standard, setting the LTTPR in a specific operation mode
can be ea
On Tue, 2024-12-10 at 16:18 +0100, Stanislaw Gruszka wrote:
>
> I've reproduced the issue. It's caused by 6.12.y commit:
>
> commit 6ac269abab9ca5ae910deb2d3ca54351c3467e99
> Author: Bingbu Cao
> Date: Wed Oct 16 15:53:01 2024 +0800
>
> media: ipu6: not override the dma_ops of device in d
On Thu, Dec 12, 2024 at 12:25:38PM +0200, Jani Nikula wrote:
> On Thu, 12 Dec 2024, Imre Deak wrote:
> > Follow the canonical way in intel_dp_mst.c, referencing a connector only
> > via a struct intel_connector pointer and naming this pointer 'connector'
> > instead of 'intel_connector', the only
On Thu, Dec 12, 2024 at 12:10:58PM +0200, Jani Nikula wrote:
> [...]
> On Thu, 12 Dec 2024, Imre Deak wrote:
> > @@ -863,9 +866,14 @@ EXPORT_SYMBOL(drm_connector_dynamic_register);
> > * drm_connector_unregister - unregister a connector
> > * @connector: the connector to unregister
> > *
> >
== Series Details ==
Series: drm/display: use ERR_PTR on DP tunnel manager creation fail (rev2)
URL : https://patchwork.freedesktop.org/series/142423/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15830 -> Patchwork_142423v2
On Thu, Dec 12, 2024 at 12:04:17PM +0200, Jani Nikula wrote:
> On Thu, 12 Dec 2024, Imre Deak wrote:
> > Atm when the connector is added to the drm_mode_config::connector_list,
> > the connector may not be fully initialized yet. This is not a problem
> > for static connectors initialized/added dur
Instead of returning a generic NULL on error from
drm_dp_tunnel_mgr_create(), use error pointers with informative codes
to align the function with stub that is executed when
CONFIG_DRM_DISPLAY_DP_TUNNEL is unset. This will also trigger IS_ERR()
in current caller (intel_dp_tunnerl_mgr_init()) instea
On Thu, 12 Dec 2024, Raag Jadav wrote:
> On Thu, Dec 12, 2024 at 09:36:00AM +0100, Andi Shyti wrote:
>> Hi Raag,
>>
>> On Thu, Dec 12, 2024 at 05:22:32AM +0200, Raag Jadav wrote:
>> > On Thu, Dec 12, 2024 at 12:40:07AM +0100, Andi Shyti wrote:
>> > > > Raag Jadav (4):
>> > > > drm/intel/pciids:
== Series Details ==
Series: drm/i915/display: Add WA_14018221282 (rev3)
URL : https://patchwork.freedesktop.org/series/141087/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15829 -> Patchwork_141087v3
Summary
---
**
On Wed, Dec 11, 2024 at 06:14:12PM +0100, Maxime Ripard wrote:
> On Wed, Dec 04, 2024 at 01:17:17PM +0200, Raag Jadav wrote:
> > + misc maintainers
> >
> > On Tue, Dec 03, 2024 at 11:18:00AM +0100, Christian König wrote:
> > > Am 03.12.24 um 06:00 schrieb Raag Jadav:
> > > > On Mon, Dec 02, 2024 a
On Thu, 12 Dec 2024, Luca Coelho wrote:
> On Tue, 2024-12-10 at 12:46 +0200, Jani Nikula wrote:
>> Going forward, struct intel_display is the main device data structure
>> for display. Switch to it internally in DP code.
>>
>> Signed-off-by: Jani Nikula
>> ---
>
> These huge mechanical changes a
On Tue, 2024-12-10 at 12:46 +0200, Jani Nikula wrote:
> Convert the final stragglers to struct intel_display now that we have
> platform identification via it too.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 +++--
> 1 file changed, 3 inse
On Thu, 12 Dec 2024, Imre Deak wrote:
> Follow the canonical way in intel_dp_mst.c, referencing a connector only
> via a struct intel_connector pointer and naming this pointer 'connector'
> instead of 'intel_connector', the only exception being the casting of
> a drm_connector function parameter p
On Wed, Dec 11, 2024 at 07:33:03PM -0500, Lyude Paul wrote:
> Coming in again with the good patches I see :D
>
> Apologies for not seeing these patches before, I really need to figure out a
> way to keep up with dri-devel outside of patches that are CC'd to me :S (if
> you ever need me to review s
On Tue, 2024-12-10 at 12:46 +0200, Jani Nikula wrote:
> Convert the intel_dp.[ch] external interfaces to struct intel_display.
>
> Signed-off-by: Jani Nikula
> ---
Reviewed-by: Luca Coelho
--
Cheers,
Luca.
On Tue, 2024-12-10 at 12:46 +0200, Jani Nikula wrote:
> Going forward, struct intel_display is the main device data structure
> for display. Switch to it internally in DP code.
>
> Signed-off-by: Jani Nikula
> ---
These huge mechanical changes are impossible to review fully with my
attention spa
On Thu, 12 Dec 2024, Imre Deak wrote:
> After an error during adding an MST connector the MST port and the
> intel_connector object could be leaked, fix this up.
>
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Imre Deak
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_ms
On Thu, 12 Dec 2024, Imre Deak wrote:
> All the drivers should be converted now to use
> drm_connector_dynamic_init() for MST connectors, hence
> drm_connector_dynamic_register()->drm_connector_add() can WARN now if
> this was not the case (for instance if a driver inited an MST connector
> with o
On Thu, 12 Dec 2024, Imre Deak wrote:
> After a connector is added to the drm_mode_config::connector_list, it's
> visible to any in-kernel users looking up connectors via the above list.
> Make sure that the connector is properly initialized before such
> look-ups, by initializing the connector wi
On Thu, 12 Dec 2024, Imre Deak wrote:
> After a connector is added to the drm_mode_config::connector_list, it's
> visible to any in-kernel users looking up connectors via the above list.
> Make sure that the connector is properly initialized before such
> look-ups, by initializing the connector wi
On Tue, 2024-12-10 at 12:46 +0200, Jani Nikula wrote:
> Use the contemporary naming convention of struct intel_connector
> *connector. Avoid struct drm_connector use altogether. In a few cases
> add local struct drm_display_info and struct intel_display pointers to
> help move away from struct drm_
On Thu, 12 Dec 2024, Imre Deak wrote:
> After a connector is added to the drm_mode_config::connector_list, it's
> visible to any in-kernel users looking up connectors via the above list.
> Make sure that the connector is properly initialized before such
> look-ups, by initializing the connector wi
On Thu, 12 Dec 2024, Imre Deak wrote:
> MST connectors should be initialized/registered by calling
> drm_connector_dynamic_init()/drm_connector_dynamic_register(). The
> previous patch adding these functions explains the issue with the
References to "previous patch" become meaningless after this
On Thu, 12 Dec 2024, Imre Deak wrote:
> Drivers should register/unregister only dynamic (MST) connectors
> manually using drm_connector_dynamic_register()/unregister().
> Static connectors are registered/unregistered by the DRM core
> automatically. Some drivers still call drm_connector_register()
On Tue, 2024-12-10 at 12:46 +0200, Jani Nikula wrote:
> Use the contemporary naming convention of struct intel_encoder *encoder.
>
> Signed-off-by: Jani Nikula
> ---
This is pretty straight-forward. Did you use any semantic-patch or
just manually changed them? This is so small that the latter i
On Thu, 12 Dec 2024, Imre Deak wrote:
> The connectors enumerated by the GETRESOURCES ioctl may not be fully
> initialized yet wrt. to the state set up during connector registration
> (for instance the connector's debugfs/sysfs interfaces may not exist
> yet). This can happen in two ways:
>
> 1. C
On Thu, 12 Dec 2024, Imre Deak wrote:
> Atm when the connector is added to the drm_mode_config::connector_list,
> the connector may not be fully initialized yet. This is not a problem
> for static connectors initialized/added during driver loading, for which
> the driver ensures that look-ups via
On Thu, Dec 12, 2024 at 09:36:00AM +0100, Andi Shyti wrote:
> Hi Raag,
>
> On Thu, Dec 12, 2024 at 05:22:32AM +0200, Raag Jadav wrote:
> > On Thu, Dec 12, 2024 at 12:40:07AM +0100, Andi Shyti wrote:
> > > > Raag Jadav (4):
> > > > drm/intel/pciids: Refactor DG2 PCI IDs into segment ranges
> > >
It was observed that the first write to DKL PHY DP Mode
register was not taking effect, hence rewrite this register.
v2: Rename function [Mitul]
v3: Rename function [Jani]
Signed-off-by: Nemesa Garg
Signed-off-by: Kulkarni, Vandita
---
drivers/gpu/drm/i915/display/intel_ddi.c | 15
On Tue, Dec 10, 2024 at 06:00:33PM -0600, Lucas De Marchi wrote:
> raw_spin_lock_init(&guc->timestamp.lock);
> raw_spin_lock_init(&pmu->lock);
> raw_spin_lock_init(&i915->mmio_debug.lock);
> raw_spin_lock_init(&uncore->lock);
>
> And it's still not sufficient, because inte
On Thu, Dec 12, 2024 at 11:36:29AM +0530, Vignesh Raman wrote:
> Hi Dmitry,
>
> On 12/12/24 03:09, Dmitry Baryshkov wrote:
> > On Wed, Dec 11, 2024 at 07:58:05PM +0530, Vignesh Raman wrote:
> > > Uprev IGT to the latest version and update expectation files.
> > >
> > > Signed-off-by: Vignesh Rama
> Please:
>
> 1. run checkpatch.pl before sending patches.
> 2. don't ignore previous reviews: I asked you to add the fixes
> tag and two Cc
> 3. run checkpatch.pl before sending patches.
> 4. Because this is a fix you should Cc also the stable mailing
> list (for real!).
> 5. Find th
On Thu, Dec 12, 2024 at 09:31:09AM +0100, neil.armstr...@linaro.org wrote:
> On 11/12/2024 15:42, Johan Hovold wrote:
> >> +EXPORT_SYMBOL(drm_dp_lttpr_set_transparent_mode);
> >
> > This appears to be what the driver currently uses, but why not
> > EXPORT_SYMBOL_GPL?
>
> drivers/gpu/drm/display/
Hi Raag,
On Thu, Dec 12, 2024 at 05:22:32AM +0200, Raag Jadav wrote:
> On Thu, Dec 12, 2024 at 12:40:07AM +0100, Andi Shyti wrote:
> > > Raag Jadav (4):
> > > drm/intel/pciids: Refactor DG2 PCI IDs into segment ranges
> > > drm/i915/dg2: Introduce DG2_D subplatform
> > > drm/i915: Introduce
On Thu, 12 Dec 2024, Raag Jadav wrote:
> On Thu, Dec 12, 2024 at 12:40:07AM +0100, Andi Shyti wrote:
>> Hi Raag,
>>
>> > Raag Jadav (4):
>> > drm/intel/pciids: Refactor DG2 PCI IDs into segment ranges
>> > drm/i915/dg2: Introduce DG2_D subplatform
>> > drm/i915: Introduce intel_cpu_info.c f
On 11/12/2024 15:42, Johan Hovold wrote:
On Wed, Dec 11, 2024 at 03:04:12PM +0200, Abel Vesa wrote:
+/**
+ * drm_dp_lttpr_set_transparent_mode - set the LTTPR in transparent mode
+ * @aux: DisplayPort AUX channel
+ * @enable: Enable or disable transparent mode
+ *
+ * Returns 0 on success or
On Wed, 11 Dec 2024, Dmitry Baryshkov wrote:
> On Wed, Dec 11, 2024 at 03:42:27PM +0100, Johan Hovold wrote:
>> On Wed, Dec 11, 2024 at 03:04:12PM +0200, Abel Vesa wrote:
>>
>> > +/**
>> > + * drm_dp_lttpr_set_transparent_mode - set the LTTPR in transparent mode
>> > + * @aux: DisplayPort AUX ch
97 matches
Mail list logo
