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 ++--
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
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ä
---
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
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:
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
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ä
---
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:
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
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
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
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ä
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
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"
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;
@@
(
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
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
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:
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
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:
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)
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:
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:
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:
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:
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:
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
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
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.
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
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
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
32 matches
Mail list logo