From: Ville Syrjälä
Decouple .get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use .get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just for this
From: Ville Syrjälä
Plumb the format info from .fb_create() all the way to
drm_helper_mode_fill_fb_struct() to avoid the redundant
lookup.
Cc: Alex Deucher
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Thomas Zimmermann
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_disp
From: Ville Syrjälä
Soon all drivers should have the format info already available in the
places where they call drm_helper_mode_fill_fb_struct(). Allow it to
be passed along into drm_helper_mode_fill_fb_struct() instead of doing
yet another redundant lookup.
Start by always passing in NULL and
From: Ville Syrjälä
Decouple drm_get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use drm_get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just fo
From: Ville Syrjälä
Pass along the format information from the top to .fb_create()
so that we can avoid redundant (and somewhat expensive) lookups
in the drivers.
Done with cocci (with some manual fixups):
@@
identifier func =~ ".*create.*";
identifier dev, file, mode_cmd;
@@
struct drm_framebuf
From: Ville Syrjälä
Pass along the format information from the top to .fb_create()
so that we can avoid redundant (and somewhat expensive) lookups
in the drivers.
Done with cocci (with some manual fixups):
@@
identifier func =~ ".*create.*";
identifier dev, file, mode_cmd;
@@
struct drm_framebuf
From: Ville Syrjälä
Decouple drm_get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use drm_get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just fo
From: Ville Syrjälä
Decouple .get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use .get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just for this
From: Ville Syrjälä
Soon all drivers should have the format info already available in the
places where they call drm_helper_mode_fill_fb_struct(). Allow it to
be passed along into drm_helper_mode_fill_fb_struct() instead of doing
yet another redundant lookup.
Start by always passing in NULL and
From: Ville Syrjälä
Plumb the format info from .fb_create() all the way to
drm_helper_mode_fill_fb_struct() to avoid the redundant
lookup.
Cc: Alex Deucher
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +++--
1 file changed,
From: Ville Syrjälä
Pass long the format information from the top to .fb_create()
so that we can avoid redundant (and somewhat expensive) lookups
in the drivers.
Done with cocci (with some manual fixups):
@@
identifier func =~ ".*create.*";
identifier dev, file, mode_cmd;
@@
struct drm_framebuff
From: Ville Syrjälä
Decouple drm_get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use drm_get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just fo
From: Ville Syrjälä
Decouple .get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use .get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just for this
From: Ville Syrjälä
Include the encoder itself in its possible_clones bitmask.
In the past nothing validated that drivers were populating
possible_clones correctly, but that changed in commit
74d2aacbe840 ("drm: Validate encoder->possible_clones").
Looks like radeon never got the memo and is stil
From: Ville Syrjälä
Atomic drivers shouldn't be using the legacy state stored
directly under drm_crtc. Move that junk into a 'legacy' sub
structure to highlight the offenders, of which there are
quite a few unfortunately.
I'm hoping we could get all these fixed and then declare
the legacy state
From: Ville Syrjälä
Hide the plane->fb/etc. footguns better by stashing them inside
a "legacy" sub struct.
Eventually maybe we could turn 'legacy' into a pointer
that only exists on legacy drivers to completely prevent
any abuse by atomic drivers...
Side note: _dpu_plane_set_danger_state() look
From: Ville Syrjälä
An attempt to hide the drm_plane/crtc legacy state better.
This also highlights the fact that a lot of supposedly
atomic drivers are poking around in the legacy crtc state,
which is rather questionable. For planes we did force the
legacy state to NULL already to force drivers
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 ++--
drivers/gpu/drm/
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
Re
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
Si
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ä
---
.../gpu/drm/amd/display/amdgpu_d
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: amd-gfx@lists.freedeskto
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 destinat
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 destinat
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 list
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 qu
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 t
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: Ville
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 qu
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: Ville
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) Z
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: Da
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: Da
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: amd-gfx@lists.freedesktop.o
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: amd-gfx@lists.freedesktop.o
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 fb_helpe
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
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Harry Wen
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. Just missing a bit of review...
C
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
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Harry Wen
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
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
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 and so far it's looking
good. Eve
49 matches
Mail list logo
