[PATCH 2/5] drm/amdgpu: Use drm_crtc_vblank_crtc()

2024-04-08 Thread Ville Syrjala
From: Ville Syrjälä Replace the open coded drm_crtc_vblank_crtc() with the real thing. Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 8 ++--

[PATCH v2 1/7] drm/amdgpu: Use drm_mode_init() for on-stack modes

2022-11-07 Thread Ville Syrjala
From: Ville Syrjälä Initialize on-stack modes with drm_mode_init() to guarantee no stack garbage in the list head, or that we aren't copying over another mode's list head. Based on the following cocci script, with manual fixups: @decl@ identifier M; expression E; @@ - struct drm_display_mode M

[PATCH v2 9/9] drm/edid: s/monitor_rage/vrr_range/

2022-09-27 Thread Ville Syrjala
From: Ville Syrjälä Rename info->monitor_range to info->vrr_range to actually reflect its usage. Cc: Nicholas Kazlauskas Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Manasi Navare Acked-by: Jani Nikula Signed-off-by: Ville Syrjälä ---

[PATCH v2 3/9] drm/edid: Only parse VRR range for continuous frequency displays

2022-09-27 Thread Ville Syrjala
From: Ville Syrjälä Since we only use the parsed vrefresh range to determine if VRR should be supported we should only accept continuous frequency displays here. Cc: Manasi Navare Cc: Nicholas Kazlauskas Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: amd-gfx@lists.freedesktop.org

[PATCH v2 1/9] drm/edid: Clarify why we only accept the "range limits only" descriptor

2022-09-27 Thread Ville Syrjala
From: Ville Syrjälä The current comment fails to clarify why we only accept the "range limits only" variant of the range descriptor. Reword it to make some actual sense. Cc: Nicholas Kazlauskas Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: amd-gfx@lists.freedesktop.org Reviewed-by:

[PATCH 05/11] drm/edid: Only parse VRR range for continuous frequency displays

2022-08-26 Thread Ville Syrjala
From: Ville Syrjälä Since we only use the parsed vrefresh range to determine if VRR should be supported we should only accept continuous frequency displays here. Cc: Manasi Navare Cc: Nicholas Kazlauskas Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: amd-gfx@lists.freedesktop.org

[PATCH 03/11] drm/edid: s/monitor_rage/vrr_range/

2022-08-26 Thread Ville Syrjala
From: Ville Syrjälä Rename info->monitor_range to info->vrr_range to actually reflect its usage. Cc: Manasi Navare Cc: Nicholas Kazlauskas Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Ville Syrjälä ---

[PATCH 02/11] drm/edid: Clarify why we only accept the "range limits only" descriptor

2022-08-26 Thread Ville Syrjala
From: Ville Syrjälä The current comment fails to clarify why we only accept the "range limits only" variant of the range descriptor. Reword it to make some actual sense. Cc: Manasi Navare Cc: Nicholas Kazlauskas Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc:

[PATCH 04/22] drm/amdgpu: Use drm_mode_copy()

2022-02-18 Thread Ville Syrjala
From: Ville Syrjälä struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the

[PATCH 05/22] drm/radeon: Use drm_mode_copy()

2022-02-18 Thread Ville Syrjala
From: Ville Syrjälä struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the

[PATCH 03/22] drm/amdgpu: Use drm_mode_init() for on-stack modes

2022-02-18 Thread Ville Syrjala
From: Ville Syrjälä Initialize on-stack modes with drm_mode_init() to guarantee no stack garbage in the list head, or that we aren't copying over another mode's list head. Based on the following cocci script, with manual fixups: @decl@ identifier M; expression E; @@ - struct drm_display_mode M

[PATCH 02/22] drm/amdgpu: Remove pointless on stack mode copies

2022-02-18 Thread Ville Syrjala
From: Ville Syrjälä These on stack copies of the modes appear to be pointless. Just look at the originals directly. Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: Nikola Cornij Cc: Aurabindo Pillai Signed-off-by: Ville Syrjälä

[PATCH 00/22] drm: Review of mode copies

2022-02-18 Thread Ville Syrjala
From: Ville Syrjälä I might be taking this a bit too far, but the lack of consistency in our methods to copy drm_display_mode structs around is bugging me. The main worry is the embedded list head, which if clobbered could lead to list corruption. I'd also prefer to make sure even the valid

[PATCH 2/3] drm/amdgpu/powerplay: Use swap() where appropriate

2019-10-10 Thread Ville Syrjala
From: Ville Syrjälä @swap@ identifier TEMP; expression A,B; @@ - TEMP = A; - A = B; - B = TEMP; + swap(A, B); @@ type T; identifier swap.TEMP; @@ ( - T TEMP; | - T TEMP = {...}; ) ... when != TEMP Cc: Rex Zhu Cc: Evan Quan Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou"

[PATCH 1/3] drm/amd/display: Use swap() where appropriate

2019-10-10 Thread Ville Syrjala
From: Ville Syrjälä Mostly a cocci-job, but it flat out refused to remove the declaration in drivers/gpu/drm/amd/display/dc/core/dc.c so had to do that part manually. @swap@ identifier TEMP; expression A,B; @@ - TEMP = A; - A = B; - B = TEMP; + swap(A, B); @@ type T; identifier swap.TEMP; @@ (

[PATCH 3/4] drm/radeon: Use drm_hdmi_avi_infoframe_quant_range()

2019-01-08 Thread Ville Syrjala
From: Ville Syrjälä Fill out the AVI infoframe quantization range bits using drm_hdmi_avi_infoframe_quant_range() instead of hand rolling it. This changes the behaviour slightly as drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit even when QS==0 iff the Q bit matched the default

[PATCH 1/4] drm/edid: Pass connector to AVI infoframe functions

2019-01-08 Thread Ville Syrjala
From: Ville Syrjälä Make life easier for drivers by simply passing the connector to drm_hdmi_avi_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range(). That way drivers don't need to worry about is_hdmi2_sink mess. v2: Make is_hdmi2_sink() return true for sil-sii8620 Adapt

[PATCH 4/4] drm/edid: Add display_info.rgb_quant_range_selectable

2019-01-08 Thread Ville Syrjala
From: Ville Syrjälä Move the CEA-861 QS bit handling entirely into the edid code. No need to bother the drivers with this. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-gfx@lists.freedesktop.org Cc: Eric Anholt (supporter:DRM DRIVERS FOR VC4) Signed-off-by:

[PATCH 3/4] drm/radeon: Use drm_hdmi_avi_infoframe_quant_range()

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Fill out the AVI infoframe quantization range bits using drm_hdmi_avi_infoframe_quant_range() instead of hand rolling it. This changes the behaviour slightly as drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit even when QS==0 iff the Q bit matched the default

[PATCH 4/4] drm/edid: Add display_info.rgb_quant_range_selectable

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Move the CEA-861 QS bit handling entirely into the edid code. No need to bother the drivers with this. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-gfx@lists.freedesktop.org Cc: Eric Anholt (supporter:DRM DRIVERS FOR VC4) Signed-off-by:

[PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Make life easier for drivers by simply passing the connector to drm_hdmi_avi_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range(). That way drivers don't need to worry about is_hdmi2_sink mess. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing)

[PATCH v2 6/9] drm/radeon: Use drm_connector_for_each_possible_encoder()

2018-06-28 Thread Ville Syrjala
From: Ville Syrjälä Use drm_connector_for_each_possible_encoder() for iterating connector->encoder_ids[]. A bit more convenient not having to deal with the implementation details. v2: Replace drm_for_each_connector_encoder_ids() with drm_connector_for_each_possible_encoder() (Daniel) Cc:

[PATCH v2 4/9] drm/amdgpu: Use drm_connector_for_each_possible_encoder()

2018-06-28 Thread Ville Syrjala
From: Ville Syrjälä Use drm_connector_for_each_possible_encoder() for iterating connector->encoder_ids[]. A bit more convenient not having to deal with the implementation details. v2: Replace drm_for_each_connector_encoder_ids() with drm_connector_for_each_possible_encoder() (Daniel) Cc:

[PATCH v2 0/9] drm: Third attempt at fixing the fb-helper .best_encoder() mess

2018-06-28 Thread Ville Syrjala
From: Ville Syrjälä Changes from the previous version mainly involve Danoie's suggestion of hiding the drm_encoder_find() in the iterator macro. I also polished the msm and tilcdc cases a bit more with another small helper. Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: Ben Skeggs Cc:

[PATCH 4/8] drm/amdgpu: Use drm_for_each_connector_encoder_ids()

2018-06-26 Thread Ville Syrjala
From: Ville Syrjälä Use drm_for_each_connector_encoder_ids() for iterating connector->encoder_ids[]. A bit more convenient not having to deal with the implementation details. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: Harry Wentland Cc:

[PATCH 7/8] drm/radeon: Use drm_for_each_connector_encoder_ids()

2018-06-26 Thread Ville Syrjala
From: Ville Syrjälä Use drm_for_each_connector_encoder_ids() for iterating connector->encoder_ids[]. A bit more convenient not having to deal with the implementation details. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: Harry Wentland Cc:

[PATCH] drm: Pass crtc to .best_encoder()

2018-06-15 Thread Ville Syrjala
From: Ville Syrjälä To pick the correct MST encoder i915 wants to know which crtc is going to be feeding us. To that end let's pass the crtc to the .best_encoder() hook. The atomic variant already knows the crtc via the connector state, but the non-atomic hooks is still being used by the

[PATCH v2 07/13] drm/amdgpu/dc: Stop updating plane->fb

2018-05-25 Thread Ville Syrjala
From: Ville Syrjälä We want to get rid of plane->fb on atomic drivers. Stop setting it. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: Harry Wentland

[PATCH v2 00/13] drm: Eliminate plane->fb/crtc usage for atomic drivers

2018-05-25 Thread Ville Syrjala
From: Ville Syrjälä Here are again the last (?) bits of eliminating the plane->fb/crtc usage for atomic drivers. I've pushed everything else (thanks to everyone who reviewed them). Deepak said he'd tested the vmwgfx stuff, so I think it should be safe to land.

[PATCH 04/13] drm/amdgpu/dc: Stop updating plane->fb

2018-04-05 Thread Ville Syrjala
From: Ville Syrjälä We want to get rid of plane->fb on atomic drivers. Stop setting it. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: Harry Wentland

[PATCH 16/23] drm/amdgpu/dc: Stop updating plane->fb

2018-03-22 Thread Ville Syrjala
From: Ville Syrjälä We want to get rid of plane->fb on atomic drivers. Stop setting it. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: Harry Wentland

[PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

2018-03-22 Thread Ville Syrjala
From: Ville Syrjälä I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes