From: Ville Syrjälä
Fix a div-by-zero on gen2, and make the L-shaped memory detection
actually work on cl/ctg. Atm the SWIZZLE_UNKNOWN stuff just trips
some GEM_BUG_ONs. This doesn't fix those but since I populate all
my memory channels symmetrically I get to avoid the GEM_BUG_ONs
by correctly de
From: Ville Syrjälä
Gen2 tiles are 2KiB in size so i915_gem_object_get_tile_row_size()
can in fact return <4KiB, which leads to div-by-zero here.
Avoid that.
Not sure i915_gem_object_get_tile_row_size() is entirely
sane anyway since it doesn't account for the different tile
layouts on i8xx/i915.
From: Ville Syrjälä
We've defined C0DRB3/C0DRB3 as 16 bit registers, so access them
as such.
Fixes: 1c8242c3a4b2 ("drm/i915: Use unchecked writes for setting up the fences")
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
1 fil
From: Ville Syrjälä
These are the 965g/g45/g33 specific DRB registers. Give them
a suitable suffix so we can add their counterparts for other
platforms.
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
drivers/gpu/drm/i915/i915_
From: Ville Syrjälä
Currently we try to detect a symmetric memory configurations
using a magic DCC2_MODIFIED_ENHANCED_DISABLE bit. That bit is
either only set on a very specific subset of machines or it
just does not exist (it's not mentioned in any public chipset
datasheets I've found). As it ha
From: Ville Syrjälä
drm_vblank_restore() exists because certain power saving states
can clobber the hardware frame counter. The way it does this is
by guesstimating how many frames were missed purely based on
the difference between the last stored timestamp vs. a newly
sampled timestamp.
If we s
From: Ville Syrjälä
drm_vblank_restore() exists because certain power saving states
can clobber the hardware frame counter. The way it does this is
by guesstimating how many frames were missed purely based on
the difference between the last stored timestamp vs. a newly
sampled timestamp.
If we s
From: Ville Syrjälä
Replace the open coded drm_mode_is_420_only() with the real thing.
No functional changes.
Cc: Werner Sembach
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_
From: Ville Syrjälä
While staring at some DRM_MODESET_LOCK_ALL_{BEGIN,END}() conversions
I decided I don't really like what those macros do.
The main problems that I see:
- the magic goto inside limits their usefulness to baically
a single statement, unless you're willing to look inside and
From: Ville Syrjälä
Quite a few places are hand rolling the modeset lock backoff dance.
Let's suck that into a helper macro that is easier to use without
forgetting some steps.
The main downside is probably that the implementation of
drm_with_modeset_lock_ctx() is a bit harder to read than a han
From: Ville Syrjälä
Layer drm_modeset_lock_all_ctx_retry() on top of
drm_modeset_lock_ctx_retry() to make the fairly common
"let's lock everything" pattern nicer.
Currently we have DRM_MODESET_LOCK_ALL_{BEGIN,END}() for this
but I don't really like it due to the magic gotos within,
which makes i
From: Ville Syrjälä
Extract intel_crtc_initial_commit() from intel_initial_commit().
Should make subsequent changes a bit less convoluted.
Cc: Sean Paul
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 96 +++-
1 file changed,
From: Ville Syrjälä
We have the modeset lock dance hand rolled in quite a few places.
Use drm_modeset_lock_ctx_retry() and drm_modeset_lock_all_ctx_retry()
to simplify our lives.
Cc: Sean Paul
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c |
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ä
Add a variant of drm_mode_copy() that explicitly clears out
the list head of the destination mode. Helpful to guarantee
we don't have stack garbage left in there for on-stack modes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 17 +
include
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-...@lists.freedesktop.org
Cc: Nikola Cornij
Cc: Aurabindo Pillai
Signed-off-by: Ville Syrjälä
---
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ä
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ä
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.
Cc: Xinliang Liu
Cc: Tian Tao
Cc: John Stultz
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +-
1 file chang
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ä
This on stack middle man mode looks entirely pointless.
Just duplicate the original mode directly.
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/dp/
From: Ville Syrjälä
Replace the hand rolled drm_mode_duplicate() with the
real thing.
@is_dup@
@@
drm_mode_duplicate(...)
{ ... }
@depends on !is_dup@
expression dev, oldmode;
identifier newmode;
@@
- newmode = drm_mode_create(dev);
+ newmode = drm_mode_duplicate(dev, oldmode);
...
- drm_mode
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ä
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.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;
@@
identifier decl.M;
e
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ä
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ä
Replace the hand rolled drm_mode_duplicate() with the
real thing.
@is_dup@
@@
drm_mode_duplicate(...)
{ ... }
@depends on !is_dup@
expression dev, oldmode;
identifier newmode;
@@
- newmode = drm_mode_create(dev);
+ newmode = drm_mode_duplicate(dev, oldmode);
...
- drm_mode
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ä
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ä
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ä
Fix the bad copy-pasta in the scaling_mode docs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e0a30e0ee86a..3b
From: Ville Syrjälä
Fix a pile of regression on older machines which just oops the driver
on load.
Cc: Dave Airlie
Cc: Jani Nikula
Cc: Maarten Lankhorst
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Mika Kuoppala
Ville Syrjälä (4):
drm/i915: Replace the unconditional clflush with
drm_cl
From: Ville Syrjälä
Not all machines have clflush, so don't go assuming they do.
Not really sure why the clflush is even here since hwsp
is supposed to get snooped I thought.
Although in my case we're talking about a i830 machine where
render/blitter snooping is definitely busted. But it might
w
From: Ville Syrjälä
This one is apparently a "clflush for good measure", so bit more
justification (if you can call it that) than some of the others.
Convert to drm_clflush_virt_range() again so that machines without
clflush will survive the ordeal.
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhor
From: Ville Syrjälä
We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
Let's not oops when loading the driver on one those machines.
Cc: Dave Airlie
Cc: Jani Nikula
Fixes: cd030c7c11a4 ("drm/i915: constify hotplug function vtable.")
Signed-off-by: Ville Syrjälä
---
drive
From: Ville Syrjälä
Replace the unconditional clflush() with drm_clflush_virt_range()
which does the wbinvd() fallback when clflush is not available.
This time no justification is given for the clflush in the
offending commit.
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Thomas Hellstr
From: Ville Syrjälä
Remove the counterproductive CONFIG_DEBUG_FS ifdef and just include
the debugfs dentry in drm_crtc always. This way we don't need
annoying ifdefs in the actual code with DEBUGFS=n. Also we don't
have these ifdefs around any of the other debugfs dentries either
so can't see why
From: Ville Syrjälä
Replace the slightly odd "#define NULL" thing with
a standard static inline stub.
Cc: Noralf Trønnes
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
include/drm/drm_mipi_dbi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_mipi_dbi.
From: Ville Syrjälä
CH7511 doesn't update SINK_COUNT properly so in order to detect
the device as connected we have to ignore SINK_COUNT.
In order to have access to the quirk list early enough we
must move the drm_dp_read_desc() call to happen earlier.
We can also skip re-reading this on eDP sin
From: Ville Syrjälä
CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly
causing i915 to detect it as disconnected. Add a quirk to ignore
SINK_COUNT on these devices.
Cc: David S.
Cc: Peteris Rudzusiks
Tested-by: Peteris Rudzusiks
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi
From: Ville Syrjälä
Give the "DFP 1.x" bit a proper name, and clean up the rest
of the bits defines as well.
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
include/drm/drm_edid.h | 32 +---
2 files changed, 18 insertions(
From: Ville Syrjälä
From VESA EDID implementation guide v1.0:
"For EDID version 1 revision 2 or earlier data structures when offset 14h
bit 7 is set to one, the value of bits 6-0 are undefined, and therefore
cannot be interpreted to mean anything."
And since EDID 1.4 redefines that bit let's c
From: Ville Syrjälä
Logs can get confusing when some operations are done multiple times
due to the ww mutex backoff. Add a debug print into
drm_modeset_backoff() so that at least the reason for the odd
looking logs will be obvious.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modeset_l
From: Ville Syrjälä
Only some of the drm mode object lookups have a corresponding debug
print for the lookup failure. That makes logs a bit hard to parse
when you can't see where the bad object ID is being used. Add a bunch
more debug prints, and unify their appearance.
Signed-off-by: Ville Syrj
From: Ville Syrjälä
Use ENOENT consistently for the case where the requested property
isn't found, and EINVAL for the case where the object has no
properties whatsoever. Currenrly these are handled differently
in the atomic and legacy codepaths.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm
From: Ville Syrjälä
Decode the NAK reply fields to make it easier to parse the logs.
v2: s/STR/DP_STR/ to avoid conflict with some header stuff (0day)
Use drm_dp_mst_req_type_str() more (DK)
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_dp_mst_topo
From: Ville Syrjälä
Make the code a bit easier to read by providing symbolic names
for the reply_type (ACK vs. NAK). Also clean up some brace stuff
while at it.
v2: s/DP_REPLY/DP_SIDEBAND_REPLY/ (DK)
Fix some checkpatch issues
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
From: Ville Syrjälä
drm_color_lut_check() doens't modify the passed in blob so
let's make it const.
Also s/uint32_y/u32/ while at it.
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_color_mgmt.c | 6 +++---
include/drm/drm_color_mgmt.h | 4 ++--
2 files changed, 5 ins
From: Ville Syrjälä
The fuzzy drm_calc_{h,v}scale_relaxed() helpers are no longer used.
Throw them in the bin.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 108 -
include/drm/drm_rect.h | 6 ---
2 files changed, 114 deletions(-)
diff
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ä
Fill out the AVI infoframe quantization range bits using
drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.
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-...@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ä
Some monitors apparently forget to mark any mode as preferred in the
EDID. In this particular case we have a very generic looking ID
"PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
doesn't seem particularly wise. Also the quirk we have
(EDID_QUIRK_FIRST_DETA
From: Ville Syrjälä
Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.
Assuming that another preferred mode didn't sneak in somehow
(is that even po
From: Ville Syrjälä
drm_mode_create_from_cmdline_mode() can return NULL, so the caller
should check for that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/dr
From: Ville Syrjälä
Respect the user's choice of depth/bpp for the fbdev framebuffer
and throw out the fb we inherited from the BIOS if it doesn't
match.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fbdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers
From: Ville Syrjälä
i915 will now refuse to enable a C8 plane unless the gamma_lut
is already enabled (to avoid scanning out whatever garbage got
left in the hw LUT previously). So in order to make the fbdev
code work with C8 we need to program the gamma_lut already
during restore_fbdev_mode_atom
From: Ville Syrjälä
If the user specifies zero width/height cmdline mode i915 will
blow up as the fbdev path will bypass the regular fb sanity
check that would otherwise have refused to create a framebuffer
with zero width/height.
The reason I thought to try this is so that I can force a specifi
From: Ville Syrjälä
The PATH blob is already being parsed by userspace for MST connectors
so the layout of the blob is now uabi. Let's document what it should
look like.
Also add a clear note saying non-MST connectors can have a PATH prop
too.
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Ilia Mir
From: Ville Syrjälä
Here's a possible apporoach for providing userspace with
some stable connector identifiers. Combine with the bus
name of the GPU and you should have some kind of real
physical path description. Unfortunately the ship has
sailed for MST connectors because userspace is already
p
From: Ville Syrjälä
Userspace may want stable identifiers for connectors. Let's try to
provide that via the PATH prop. I tried to make these somewhat abstract
by using just "port_type:index" type of approach, where we derive the
index from the physical instance of that hw block, so it should rema
From: Ville Syrjälä
Ilia pointed out some oddball crap in the i915 aspect ratio handling.
While looking at that I noticed a bunch of fail in the core as well.
This series aims to fix it all.
Cc: Ilia Mirkin
Ville Syrjälä (5):
drm: Do not use bitwise OR to set picure_aspect_ratio
drm: Do no
From: Ville Syrjälä
enum hdmi_picture_aspect is not a bitmask, so don't use bitwise OR
to populate it.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers
From: Ville Syrjälä
Don't let userspace feed us any old garbage in the mode aspect ratio
flags.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm
From: Ville Syrjälä
WARN if the incoming drm_display_mode has an illegal aspect ratio
when converting it to a user mode. This should never happen unless
the driver made a mistake and put an invalid value into the aspect
ratio.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/d
From: Ville Syrjälä
HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d
so no need to initialize conn_state->picture_aspect_ratio with it.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 1 -
drivers/gpu/drm/i915/display/intel_s
From: Ville Syrjälä
HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that
selected we should keep whatever aspect ratio the mode already has.
Also no point in checking for connector->is_hdmi in the SDVO code
since we only attach the property to HDMI connectors.
Cc: Ilia Mirkin
S
From: Ville Syrjälä
Currently the logs show nothing about the mode's aspect ratio.
Include that information in the normal mode dump.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c| 3 ++-
include/drm/drm_modes.h | 4 ++--
include/linux/hdmi.h| 3 +++
3 files cha
From: Ville Syrjälä
Currently the logs show nothing about the mode's aspect ratio.
Include that information in the normal mode dump.
v2: Don't print anything for NONE (Ilia)
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c| 3 ++-
include/drm/drm_modes.h | 6 --
From: Ville Syrjälä
Decode the mode flags when printing the modeline so that I
no longer have to decode the hex number myself.
To do this neatly I made the caller provide a temporary
on stack buffer where we can produce the results. I choce 64
bytes as a reasonable size for this. The worst case
From: Ville Syrjälä
The end of the series is just a reposting of the fp16 stuff for gen4+.
The start of the series is new stuff to allow planes to dictate the
minimum cdclk, which is sometimes needed for downscaling or fp16
(and sometimes even for other pixel formats). Thanks to that new code
the
From: Ville Syrjälä
Add a small wrapper around lockdep_assert_held() to make
it a bit more conventinet to use with modeset locks.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modeset_lock.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_modeset_lock.h b/includ
From: Ville Syrjälä
Allow drivers to call drm_atomic_helper_check_modeset() without
having the crtc helper funcs specified. i915 doesn't need those
anymore.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
From: Ville Syrjälä
i915 doesn't use the crtc_state->plane_changed flag for anything,
so setting it is pointless.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
From: Ville Syrjälä
There's a helper in drm_fourcc.h these days to check of we're dealing
with a two plane YUV format. Make use if it.
Also s/plane/color_plane/ in skl_plane_relative_data_rate() to reduce
the confusion.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_pl
From: Ville Syrjälä
Bspec says that glk+ max downscale factor is <3.0 for all pixel formats.
Older platforms had a max of <2.0 for NV12. Update the code to deal with
this.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 9 ++---
1 file changed, 6 insertions(
From: Ville Syrjälä
Clean up the mess with the drm vs. intel types in
intel_crtc_atomic_check() and rename varibles accordingly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 54 ++--
1 file changed, 26 insertions(+), 28 deletions(-)
diff --gi
From: Ville Syrjälä
Exfiltrate the cdclk code from intel_modeset_checks() into
intel_modeset_calc_cdclk().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 135 ++-
drivers/gpu/drm/i915/display/intel_cdclk.h | 6 +-
drivers/gpu/drm/i915/displa
From: Ville Syrjälä
So far we've sort of protected the global state under dev_priv with
the connection_mutex. I wan to change that so that we can change the
cdclk even for pure plane updates. To that end let's formalize the
protection of the global state to follow what I started with the cdclk
co
From: Ville Syrjälä
While not all platforms allow us to change the cdclk frequency
we should still verify that the fixed cdclk frequency isn't
too low. To that end let's cook up a .modeset_calc_cdclk()
implementation that only does the min_cdclk vs. actual cdclk
frequency check for such platforms
From: Ville Syrjälä
We need to insert stuff between the plane and crtc .atomic_check()
drm_atomic_helper_check_planes() doesn't allow us to do that so
stop using it and hand roll the loops instead.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 10 +---
.../gp
From: Ville Syrjälä
Various pixel formats and plane scaling impose additional constraints
on the cdclk frequency. Provide a new plane->min_cdclk() hook that
will be used to compute the minimum acceptable cdclk frequency for
each plane.
Annoyingly on some platforms the numer of active planes affe
From: Ville Syrjälä
The normal cdclk handling now takes care of making sure the
plane's pixel rate doesn't exceed the spec appointed percentage
of the cdclk frequency. Thus we can nuke
skl_check_pipe_max_pixel_rate().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.
From: Ville Syrjälä
check_digital_port_conflicts() is done needlessly late. Move it earlier.
This will be needed as later on we want to set any_ms=true a bit later
for non-modesets too and we can't call this guy without the
connection_mutex held.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/dr
From: Ville Syrjälä
To make the logs a bit less confusing let's toss in some
debug prints to indicate whether the cdclk reprogramming
is going to happen with a single pipe active or whether we
need to turn all pipes off for the duration.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/di
From: Ville Syrjälä
Now that the planes declare their minimum cdclk requirements properly
we don't need to check the cdclk in skl_max_scale() anymore. Just check
against the maximum downscale ratio, and move the code next to it's
only caller.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i9
From: Ville Syrjälä
skl+ supports fp16 pixel formats on all universal planes. Add the
necessary bits to expose that capability. The main different to
icl is that we can't scale fp16, so need to add the relevant
checks.
v2: Rebase on top of icl fp16
Split skl+ bits into a separate patch
Revi
From: Ville Syrjälä
gen4+ supports fp16 pixel formats on the primary planes. Add the
relevant code.
On ivb fp16 scanout is slightly busted. The output from the plane will
have 1/4 the expected value. For the primary plane we would have to
use the pipe gamma or pipe csc to correct that which woul
From: Ville Syrjälä
ivb+ supports fp16 pixel formats on the sprite planes planes. Expose
that capability.
On ivb/hsw fp16 scanout is slightly busted. The output from the plane
will have 1/4 the expected value. For the sprite plane we can fix that
up with the plane gamma unit. This was fixed on b
From: Ville Syrjälä
snb supports fp16 pixel formats on the sprite planes. Expose that
capability. Nothing special needs to be done, it just works.
v2: Rebase on top of icl fp16
Split snb+ sprite bits into a separate patch
Reviewed-by: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
dr
From: Ville Syrjälä
Resurrecting my possible_clones/crtcs cleanup from ~1 year ago.
Some prep work from the previous posting did get merged in the
meantime.
I have a feeling the WARNs from the new validation code may end up
triggering on some drivers, but I don't imagine this stuff would
get fix
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into drm_encoder_i
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
1 - 100 of 1472 matches
Mail list logo
