Paulo Zanoni [Mon, 12 Nov 2018 23:23:13 +0000 (15:23 -0800)]
drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()
I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.
I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.
v2: Switch numerator to 1 from 1000 and adjust calculations
accordingly (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-3-paulo.r.zanoni@intel.com
Paulo Zanoni [Mon, 12 Nov 2018 23:23:12 +0000 (15:23 -0800)]
drm/i915: rename CNP_RAWCLK_FRAC to CNP_RAWCLK_DEN
Although CNP names this field "Counter Fraction", what we write to the
register is really the denominator for the fractional part of the
divider, not the fractional part (and the field description even says
that). The ICP spec renamed the field to "Counter Fraction
Denominator", which makes a lot more sense. Use the more complete ICL
naming because we will merge the CNP and ICP functions into a single
one, which will introduce the concept of the numerator. That will make
a lot more sense when you read the "num/frac = den" calculation.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-2-paulo.r.zanoni@intel.com
Paulo Zanoni [Mon, 12 Nov 2018 23:23:11 +0000 (15:23 -0800)]
drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations
BSpec was updated and now there's no more "subtract 1" to the
Microsecond Counter Divider field.
It seems this should help fixing some GMBUS issues. I'm not aware of
any specific open bug that could be solved by this patch.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-1-paulo.r.zanoni@intel.com
Ville Syrjälä [Mon, 22 Oct 2018 14:20:15 +0000 (17:20 +0300)]
drm/i915: Determine DSI panel orientation from VBT
VBT appears to have two (or possibly three) ways to indicate the panel
rotation. The first is in the MIPI config block, but that apparenly
usually (maybe always?) indicates 0 degrees despite the actual panel
orientation. The second way to indicate this is in the general features
block, which can just indicate whether 180 degress rotation is used.
The third might be a separate rotation data block, but that is not
at all documented so who knows what it may contain.
Let's try the first two. We first try the DSI specicic VBT
information, and it it doesn't look trustworthy (ie. indicates
0 degrees) we fall back to the 180 degree thing. Just to avoid too
many changes in one go we shall also keep the hardware readout path
for now.
If this works for more than just my VLV FFRD the question becomes
how many of the panel orientation quirks are now redundant?
v2: Move the code into intel_dsi.c (Jani)
Cc: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022142015.4026-1-ville.syrjala@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Ville Syrjälä [Mon, 22 Oct 2018 14:19:53 +0000 (17:19 +0300)]
drm/i915: Fix the VLV/CHV DSI panel orientation hw readout
Let's make sure the DSI port is actually on before we go
poking at the plane register to determine which way
it's rotated. Otherwise we could be looking at a plane
that is feeding a HDMI port for instance.
And in order to read the plane register we need the power
well to be on. Make sure that is indeed the case. We'll
also make sure the plane is actually enabled before we
trust the rotation bit to tell us the truth.
v2: s/intel_dsi/vlv_dsi/
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022141953.3889-1-ville.syrjala@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Ville Syrjälä [Thu, 8 Nov 2018 15:10:13 +0000 (17:10 +0200)]
drm/i915: Move skip_intermediate_wm handling into ilk_compute_intermediate_wm()
No point in cluttering the common codepaths with the
skip_intermediate_wm handling. Just move it into
ilk_compute_intermediate_wm() as those are the only
platforms using this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108151013.24064-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Ville Syrjälä [Mon, 29 Oct 2018 18:18:20 +0000 (20:18 +0200)]
drm/i915: Account for scale factor when calculating initial phase
To get the initial phase correct we need to account for the scale
factor as well. I forgot this initially and was mostly looking at
heavily upscaled content where the minor difference between -0.5
and the proper initial phase was not readily apparent.
And let's toss in a comment that tries to explain the formula
a little bit.
v2: The initial phase upper limit is 1.5, not 24.0!
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 0a59952b24e2 ("drm/i915: Configure SKL+ scaler initial phase correctly")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029181820.21956-1-ville.syrjala@linux.intel.com
Tested-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Ville Syrjälä [Thu, 8 Nov 2018 15:09:55 +0000 (17:09 +0200)]
drm/i915: Always write both TILEOFF and LINOFF plane registers
Reduce the clutter in the sprite update functions by writing
both TILEOFF and LINOFF registers unconditionally. We already
did this for primary planes so might as well do it for the
sprites too.
There is no harm in writing both registers. Which one gets
used depends on the tilimg mode selected in the plane control
registers.
It might even make sense to clear the register that won't
get used. That could make register dumps a little easier to
parse. But I'm not sure it's worth the extra hassle.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108150955.23948-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Ville Syrjälä [Wed, 7 Nov 2018 17:18:21 +0000 (19:18 +0200)]
drm/i915: Switch LSPCON to PCON mode if it's in LS mode
We no longer change LSPCON into PCON mode if it boots up in
LS mode. This was broken by some code shuffling in
commit
96e35598cead ("drm/i915: Check LSPCON vendor OUI").
I actually can't see a reason why that code shuffling had
to be done. The commit msg notes it but doesn't justify it
in any way. But I guess we'll keep the code in its current
place anyway and just make the "switch to PCON mode" part
effective once again.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Tested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Fixes: 96e35598cead ("drm/i915: Check LSPCON vendor OUI")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107171821.27862-1-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Lionel Landwerlin [Mon, 12 Nov 2018 12:39:31 +0000 (12:39 +0000)]
drm/i915: fix broadwell EU computation
subslice_mask is an array indexed by slice, not subslice.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 8cc7669355136f ("drm/i915: store all subslice masks")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108712
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112123931.2815-1-lionel.g.landwerlin@intel.com
Ville Syrjälä [Wed, 7 Nov 2018 21:35:22 +0000 (23:35 +0200)]
drm/i915: Clean up the baseline bpp computation
Pass on the errno all the way from connected_sink_max_bpp(),
and make the base_bpp handling in intel_modeset_pipe_config()
a bit less ugly. We'll also rename connected_sink_max_bpp()
to not give the impression that it return the bpp value,
and we'll pimp up the debug message within to include the
connector name/id.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107213522.17590-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Wed, 7 Nov 2018 21:35:21 +0000 (23:35 +0200)]
drm/i915: Remove pointless goto fail
We just 'return ret' immediately after jumping to the label. Let's
return directly instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107213522.17590-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Wed, 7 Nov 2018 21:35:20 +0000 (23:35 +0200)]
drm/i915: Handle -EDEADLK from ironlake_check_fdi_lanes()
ironlake_check_fdi_lanes() may try to grab some extra crtc locks.
If that fails we need to propagate the -EDEADLK all the way up,
and we shouldn't dump out the crtc state or other debug messages
either since it wasn't the crtc state that caused the failure.
Just hit this on my IVB:
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 3
[drm:intel_atomic_check [i915]] only 2 lanes on pipe C: required 3 lanes
[drm:intel_atomic_check [i915]] fdi link bw constraint, reducing pipe bpp to 18
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 2
[drm:intel_atomic_check [i915]] CRTC bw constrained, retrying
[drm:intel_dp_compute_config [i915]] DP link computation with max lane count 4 max rate 270000 max bpp 18 pixel clock 185580KHz
[drm:intel_dp_compute_config [i915]] DP lane count 4 clock 162000 bpp 18
[drm:intel_dp_compute_config [i915]] DP link rate required 417555 available 648000
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 2
WARNING: CPU: 4 PID: 25115 at ../drivers/gpu/drm/drm_modeset_lock.c:241 drm_modeset_lock+0xbc/0xd0 [drm]
...
WARNING: CPU: 4 PID: 25115 at ../drivers/gpu/drm/drm_modeset_lock.c:223 drm_modeset_drop_locks+0x4a/0x50 [drm]
The warnings are from 'WARN_ON(ctx->contended)'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107213522.17590-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Daniele Ceraolo Spurio [Fri, 9 Nov 2018 00:40:13 +0000 (16:40 -0800)]
drm/i915/query: fix subslice length
We dump the info as an array of u8, so we want to know the length
in number of bytes. Current code is still safe because the
variable we use BITS_PER_TYPE on is a u8.
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109004013.34394-1-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 6 Nov 2018 18:29:18 +0000 (10:29 -0800)]
drm/i915: fix subslice mask array size
We have a subslice mask per slice, not per subslice.
MAX_SUBSLICES > MAX_SLICES, so the wrong size didn't cause any issue
apart from using extra memory.
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106182918.5748-1-daniele.ceraolospurio@intel.com
José Roberto de Souza [Tue, 6 Nov 2018 19:08:43 +0000 (11:08 -0800)]
drm/i915/psr: Move intel_psr_disable_source() code to intel_psr_disable_locked()
In the past we had hooks to configure HW for VLV/CHV too, in the drop
of VLV/CHV support the intel_psr_disable_source() code was not moved
to the caller, so doing it here.
Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-4-jose.souza@intel.com
José Roberto de Souza [Tue, 6 Nov 2018 19:08:42 +0000 (11:08 -0800)]
drm/i915/icl: Reset PSR interruptions
All other interruptions gen11 interruptions are reset in
gen11_irq_reset() also it is done for other gens that supports PSR.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-3-jose.souza@intel.com
José Roberto de Souza [Tue, 6 Nov 2018 19:08:41 +0000 (11:08 -0800)]
drm/i915/psr: Always wait for idle state when disabling PSR
It should always wait for idle state when disabling PSR because PSR
could be inactive due a call to intel_psr_exit() and while PSR is
still being disabled asynchronously userspace could change the
modeset causing a call to psr_disable() that will not wait for PSR
idle and then PSR will be enabled again while PSR is still not idle.
v2: rebased on top of the patch reusing psr_exit()
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-2-jose.souza@intel.com
José Roberto de Souza [Tue, 6 Nov 2018 19:08:40 +0000 (11:08 -0800)]
drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()
Both functions have the same code to disable PSR, so let's reuse that
code instead of duplicate.
Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-1-jose.souza@intel.com
Ville Syrjälä [Thu, 1 Nov 2018 15:05:59 +0000 (17:05 +0200)]
drm/i915: Generalize skl_ddb_allocation_overlaps()
Make skl_ddb_allocation_overlaps() useful for other callers
besides skl_update_crtcs(). We'll need it to do plane updates
as well.
And while we're here we can reduce the stack utilization a
bit by noting that each struct skl_ddb_entry is 4 bytes whereas
a pointer to one is 8 bytes (on 64bit). So we'll switch to an
array of structs from the array of pointers we used before.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-9-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Thu, 1 Nov 2018 15:05:56 +0000 (17:05 +0200)]
drm/i915: Clean up skl+ PLANE_POS vs. scaler handling
On skl+ the scaler (when enabled) will take care of the plane output
position. Make the code less ugly by just setting crtc_x/y to 0
when the scaler is enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-6-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Wed, 7 Nov 2018 18:41:38 +0000 (20:41 +0200)]
drm/i915: Polish the skl+ plane keyval/msk/max register setup
Due to the constant alpha we're going to have to program two of
the the tree keying registers anyway, so might as well always
program all three.
And parametrize the plane constant alpha define while at it.
v2: Rebase due to input CSC
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107184138.31359-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Thu, 1 Nov 2018 15:05:54 +0000 (17:05 +0200)]
drm/i915: Remove the PS_PWR_GATE write from skl_program_scaler()
If we don't need the PS_PWR_GATE write when programming the
pipe scaler I don't see why we'd need it for plane scalers either.
Just remove it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-4-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
José Roberto de Souza [Wed, 7 Nov 2018 23:54:49 +0000 (15:54 -0800)]
drm/i915/mst: Drop pre_pll_enable null check
MST is only supported in DDI ports that have this hook, so the null
check can be dropped.
Suggested-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-3-jose.souza@intel.com
José Roberto de Souza [Wed, 7 Nov 2018 23:54:48 +0000 (15:54 -0800)]
drm/i915: Release DDI power well references in MST ports
MST ports did not had the post_pll_disable() hook causing the
references get in pre_pll_enable() never being released causing
DDI and AUX CH being enabled all the times.
v2: renamed intel_mst_post_pll_disable_dp() parameters
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-2-jose.souza@intel.com
José Roberto de Souza [Wed, 7 Nov 2018 23:54:47 +0000 (15:54 -0800)]
drm/i915: Reuse the aux_domain cached
intel_dp_detect() caches the aux_domain in the beginning of the
function as it is used twice, so lets also use it as the aux_domain
don't change in runtime.
v3: returning intel_dp_retrain_link() error insted of
connector_status_disconnected
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-1-jose.souza@intel.com
Ville Syrjälä [Thu, 8 Nov 2018 14:36:35 +0000 (16:36 +0200)]
drm/i915: Sanitize PCH port transcoder select on IBX
IBX has a documented workaround which states that when we disable the
port we must change its transcoder select to A, otherwise it will
prevent the other port (DP vs. HDMI/SDVO) from using transcoder A.
We implement the workaround during encoder disable, but looks like
some BIOSen leave transcoder B selected even when the port wasn't
actually enabled by the BIOS. That will trip up our asserts
that attempt to make sure we never forget this w/a.
Sanitize the transcoder select to A for all disabled PCH
DP/HDMI/SDVO ports. We assume that the port was never enabled
by the BIOS on transcoder B, because if it had we'd actually have
to toggle the port on and back off to properly switch it back to
transcoder A. That would cause some display flicker if transcoder A
is already enabled on some other port, so it's better not to do it
unless absolutely necessary. Since we have no indication that the
transcoder select is misbehaving on the affected machines we can
assume the port was never actually enabled by the BIOS.
This cures warning like this during driver load:
IBX PCH DP C still using transcoder B
WARNING: CPU: 2 PID: 172 at drivers/gpu/drm/i915/intel_display.c:1279 assert_pch_dp_disabled+0x9e/0xb0 [i915]
v2: Add comments to remind the reader that SDVOB==HDMIB (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108143635.9556-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Ville Syrjälä [Thu, 8 Nov 2018 20:04:24 +0000 (22:04 +0200)]
drm/i915: Fix hpd handling for pins with two encoders
In my haste to remove irq_port[] I accidentally changed the
way we deal with hpd pins that are shared by multiple encoders
(DP and HDMI for pre-DDI platforms). Previously we would only
handle such pins via ->hpd_pulse(), but now we queue up the
hotplug work for the HDMI encoder directly. Worse yet, we now
count each hpd twice and this increment the hpd storm count
twice as fast. This can lead to spurious storms being detected.
Go back to the old way of doing things, ie. delegate to
->hpd_pulse() for any pin which has an encoder with that hook
implemented. I don't really like the idea of adding irq_port[]
back so let's loop through the encoders first to check if we
have an encoder with ->hpd_pulse() for the pin, and then go
through all the pins and decided on the correct course of action
based on the earlier findings.
I have occasionally toyed with the idea of unifying the pre-DDI
HDMI and DP encoders into a single encoder as well. Besides the
hotplug processing it would have the other benefit of preventing
userspace from trying to enable both encoders at the same time.
That is simply illegal as they share the same clock/data pins.
We have some testcases that will attempt that and thus fail on
many older machines. But for now let's stick to fixing just the
hotplug code.
Cc: stable@vger.kernel.org # 4.19+
Cc: Lyude Paul <lyude@redhat.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: b6ca3eee18ba ("drm/i915: Nuke dev_priv->irq_port[]")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108200424.28371-1-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Imre Deak [Wed, 7 Nov 2018 20:08:36 +0000 (22:08 +0200)]
drm/i915/icl: Fix PLL mapping sanitization for DP ports
We shouldn't consider an encoder inactive if it doesn't have a CRTC
linked, but has virtual MST encoders with a crtc linked. Fix this.
Also we should not sanitize the mapping for MST encoders, as it's always
their primary encoder (which could be even in SST mode) whose active
state determines if we need the clock being enabled for the
corresponding physical port. Fix this too.
This fixes at least an existing breakage where we incorrectly disabled
the clock for an active DP encoder when sanitizing its MST virtual
encoders. Not sure if there are BIOSes that enable an output in MST
mode, but our HW readout is mostly missing for it anyway, so just warn
for that case.
Fixes: 70332ac539c5 ("drm/i915/icl+: Sanitize port to PLL mapping")
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reported-by: Antonio Argenziano <antonio.argenziano@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107200836.10191-2-imre.deak@intel.com
Imre Deak [Wed, 7 Nov 2018 20:08:35 +0000 (22:08 +0200)]
drm/i915/ddi: Add more sanity check to the encoder HW readout
Check for reserved register field values and conflicting
transcoder->port mappings (both MST and non-MST mappings or multiple SST
mappings).
This is also needed for the next patch to determine if a port is in MST
mode during sanitization after HW readout.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107200836.10191-1-imre.deak@intel.com
Chris Wilson [Thu, 8 Nov 2018 09:21:01 +0000 (09:21 +0000)]
drm/i915: Track rcu_head for our idle worker
While our little rcu worker might be able to be replaced now by the
dedicated rcu_work, in the meantime we should mark up the rcu_head for
correct debugobjects tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108092101.27598-2-chris@chris-wilson.co.uk
Chris Wilson [Fri, 9 Nov 2018 09:03:11 +0000 (09:03 +0000)]
drm/i915: Initialise the obj->rcu head
Make the rcu_head known to the system, in particular for debugobjects.
And having declared it for debugobjects, we need to tidy up afterwards.
v2: mark the obj->rcu as being destroyed when we reuse its location for
the freed list.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108691
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109090311.15321-1-chris@chris-wilson.co.uk
José Roberto de Souza [Thu, 8 Nov 2018 00:16:47 +0000 (16:16 -0800)]
drm/i915: Keep overlay functions naming consistent
All other overlay functions(almost all other functions in i915)
follow intel_overlay_verb, so renaming overlay ones that do not match
that.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-4-jose.souza@intel.com
José Roberto de Souza [Thu, 8 Nov 2018 00:16:46 +0000 (16:16 -0800)]
drm/i915: Move intel_init_ipc() call to i915_load_modeset_init()
IPC is a display feature, so i915_load_modeset_init() is the right
place to initialize it.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-3-jose.souza@intel.com
José Roberto de Souza [Thu, 8 Nov 2018 00:16:45 +0000 (16:16 -0800)]
drm/i915: Move FBC init and cleanup calls to modeset functions
Although FBC helps save power it do not belongs to power management
also the cleanup was placed in i915_driver_unload() also not a good
place. intel_modeset_init()/intel_modeset_cleanup() are better places
also this will help make easy disable features that depends in
display being enabled in driver.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-2-jose.souza@intel.com
José Roberto de Souza [Thu, 8 Nov 2018 00:16:44 +0000 (16:16 -0800)]
drm/i915: Move drm_vblank_init() to i915_load_modeset_init()
i915_load_modeset_init() is a more suitable place than
i915_driver_load() as vblank is part of modeset.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-1-jose.souza@intel.com
Paulo Zanoni [Tue, 16 Oct 2018 22:01:24 +0000 (15:01 -0700)]
drm/i915: remove padding from struct skl_wm_level
This reduces the size of struct skl_wm_level from 6 to 4, which
reduces the size of struct skl_plane_wm from 104 to 70, which reduces
the size of struct skl_pipe_wm from 524 to 356. A reduction of 168
padding bytes per pipe. This will increase even more the next time we
bump I915_MAX_PLANES.
v2: Paste the pahole output provided by Lucas:
$ pahole -s -C skl_wm_level drivers/gpu/drm/i915/i915.o
struct skl_wm_level {
bool plane_en; /* 0 1 */
/* XXX 1 byte hole, try to pack */
uint16_t plane_res_b; /* 2 2 */
uint8_t plane_res_l; /* 4 1 */
/* size: 6, cachelines: 1, members: 3 */
/* sum members: 4, holes: 1, sum holes: 1 */
/* padding: 1 */
/* last cacheline: 6 bytes */
};
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016220133.26991-3-paulo.r.zanoni@intel.com
Chris Wilson [Thu, 8 Nov 2018 14:00:39 +0000 (14:00 +0000)]
drm/i915: Set MI_INVALIDATE_BSD for all video-decode engines
We have multiple instances of VCS but only remember to invalidate the
BSD caches on the first, ignoring the stale caches of any other engine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108140039.12254-1-chris@chris-wilson.co.uk
Imre Deak [Tue, 6 Nov 2018 16:06:21 +0000 (18:06 +0200)]
drm/i915/icl: Fix port B combo PHY context loss after DC transitions
On ICL DMC/PCODE retains the HW context only for port A across DC
transitions, for the other port B combo PHY, it doesn't. So we need to
do this manually after exiting from DC6. Do the reinit even after
exiting from DC5, it won't hurt since we only reinit the PHY in case
it's needed (in case it was disabled to begin with).
As can be guessed from the bugzilla report leaving the PHY uninited will
lead to a later timeout during the port B specific AUX and DDI_IO power
well enabling.
v2:
- Apply the fix on all GEN>=11 platforms. (Rodrigo)
Bspec: 21257
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-6-imre.deak@intel.com
Imre Deak [Tue, 6 Nov 2018 16:06:20 +0000 (18:06 +0200)]
drm/i915/icl: Skip init for an already enabled combo PHY
Bspec says we should skip the initialization of combo PHYs that are
already initialized. We'll need to reinit the PHYs more frequently
when exiting from DC6 (after the next patch), so let's make sure the
uninit sequence complies with the spec. For safety skip the init only if
all the PHY register fields have their expected values.
v2:
- Print 'Port X' as we do elsewhere instead of 'Port-X'. (Jose)
Bspec: 21257
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-5-imre.deak@intel.com
Imre Deak [Tue, 6 Nov 2018 16:06:19 +0000 (18:06 +0200)]
drm/i915/cnl+: Verify combo PHY HW state during PHY uninit
Verify on CNL, ICL that the combo PHY HW state stayed intact after PHY
initialization.
v2:
- Print 'Port X' as we do elsewhere instead of 'Port-X'. (Jose)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-4-imre.deak@intel.com
Imre Deak [Tue, 6 Nov 2018 16:06:18 +0000 (18:06 +0200)]
drm/i915/cnl+: Move the combo PHY init/uninit code to a new file
Similarly to the GEN9_LP DPIO PHY code keep the CNL+ combo PHY code in a
separate file.
No functional change.
v2:
- Use SPDX license tag instead of boilerplate. (Rodrigo)
v3:
- Use MIT instead of GPL-2.0 license. (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-3-imre.deak@intel.com
Imre Deak [Tue, 6 Nov 2018 16:06:17 +0000 (18:06 +0200)]
drm/i915/icl: Fix combo PHY uninit
BSpec says to clear the comp init HW flag too during combo PHY uninit,
so do that. The lack of this could badly interact with the PHY reinit
after a DC6/9 transition at least, where (after a follow-up patch fixing
the init code) we'd skip the initialization incorrectly due to this flag
being set.
BSpec: 21257
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-2-imre.deak@intel.com
Chris Wilson [Thu, 8 Nov 2018 08:17:38 +0000 (08:17 +0000)]
drm/i915/execlists: Force write serialisation into context image vs execution
Ensure that the writes into the context image are completed prior to the
register mmio to trigger execution. Although previously we were assured
by the SDM that all writes are flushed before an uncached memory
transaction (our mmio write to submit the context to HW for execution),
we have empirical evidence to believe that this is not actually the
case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656
References: https://bugs.freedesktop.org/show_bug.cgi?id=108315
References: https://bugs.freedesktop.org/show_bug.cgi?id=106887
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108081740.25615-1-chris@chris-wilson.co.uk
Cc: stable@vger.kernel.org
Imre Deak [Fri, 2 Nov 2018 18:22:00 +0000 (20:22 +0200)]
drm/i915/icl: Fix power well 2 wrt. DC-off toggling order
To enable DC5/6 power well 2 has to be disabled as for previous
platforms, so fix things up.
Bspec: 4234
Fixes: 67ca07e7ac10 ("drm/i915/icl: Add power well support")
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102182200.17219-1-imre.deak@intel.com
Lyude Paul [Tue, 6 Nov 2018 21:30:16 +0000 (16:30 -0500)]
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
Lyude Paul [Tue, 6 Nov 2018 21:30:15 +0000 (16:30 -0500)]
drm/i915: Clarify flow for disabling IRQs on storms
This is rather confusing to look at as-is:
dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler()
handles disabling the actual HPD IRQ, while
intel_hpd_irq_storm_disable() handles moving the HPD pin state over from
MARK_DISABLED to DISABLED along with enabling polling for it.
Changes since v3:
- Rename i915_hpd_irq_storm_disable() to
i915_hpd_irq_storm_switch_to_polling() - Rodrigo Vivi
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-5-lyude@redhat.com
Lyude Paul [Tue, 6 Nov 2018 21:30:14 +0000 (16:30 -0500)]
drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()
Currently in intel_hpd_irq_storm_detect() when we detect that the last
recorded hotplug wasn't within the period defined by
HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count
to 0 without incrementing it. This results in us only enabling storm
detection when we go +2 above the threshold, e.g. an HPD threshold of 5
would not trigger a storm until we reach a total of 7 hotplugs.
So: rework the code a bit so we reset the HPD count when
HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards.
Also, clean things up a bit to make it easier to undertand.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-4-lyude@redhat.com
Lyude Paul [Tue, 6 Nov 2018 21:30:13 +0000 (16:30 -0500)]
drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00000000000000ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750] Oops: 0000 [#1] SMP PTI
[ 332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G O 4.18.0-rc3short-hpd-storm+ #2
[ 332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35 ) 09/14/2018
[ 332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
[ 332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86 [i915]
[ 332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73 62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80 ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
[ 332.354286] RSP: 0018:
ffffc90000147e48 EFLAGS:
00010006
[ 332.356344] RAX:
0000000000000005 RBX:
ffff8802c226c9d4 RCX:
0000000000000006
[ 332.358404] RDX:
0000000000000000 RSI:
0000000000000082 RDI:
ffff88032dc95570
[ 332.360466] RBP:
0000000000000005 R08:
0000000000000000 R09:
ffff88031b3dc840
[ 332.362528] R10:
0000000000000000 R11:
000000031a069602 R12:
ffff8802c226ca20
[ 332.364575] R13:
ffff8802c2268000 R14:
ffff880310661000 R15:
000000000000000a
[ 332.366615] FS:
0000000000000000(0000) GS:
ffff88032dc80000(0000) knlGS:
0000000000000000
[ 332.368658] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 332.370690] CR2:
00000000000000ec CR3:
000000000200a003 CR4:
00000000003606e0
[ 332.372724] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 332.374773] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 332.376798] Call Trace:
[ 332.378809] process_one_work+0x1a1/0x350
[ 332.380806] worker_thread+0x30/0x380
[ 332.382777] ? wq_update_unbound_numa+0x10/0x10
[ 332.384772] kthread+0x112/0x130
[ 332.386740] ? kthread_create_worker_on_cpu+0x70/0x70
[ 332.388706] ret_from_fork+0x35/0x40
[ 332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915]
[ 332.394963] CR2:
00000000000000ec
This appears to be due to the fact that with an MST topology, not all
intel_connector structs will have ->encoder set. So, fix this by
skipping connectors without encoders in
intel_hpd_irq_storm_reenable_work().
For those wondering, this bug was found on accident while simulating HPD
storms using a Chamelium connected to a ThinkPad T450s (Broadwell).
Changes since v1:
- Check intel_connector->mst_port instead of intel_connector->encoder
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-3-lyude@redhat.com
Lyude Paul [Tue, 6 Nov 2018 21:30:12 +0000 (16:30 -0500)]
drm/i915: Fix possible race in intel_dp_add_mst_connector()
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering the connector but before
having written it's value.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-2-lyude@redhat.com
Ville Syrjälä [Thu, 1 Nov 2018 15:17:36 +0000 (17:17 +0200)]
drm/i915: Clean up skl_program_scaler()
Remove the "sizes are 0 based" stuff that is not even true for the
scaler.
v2: Rebase
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101151736.20522-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Thu, 1 Nov 2018 15:05:52 +0000 (17:05 +0200)]
drm/i915: Nuke posting reads from plane update/disable funcs
No need for the posting reads in the plane update/disable hooks.
If we need a posting read for something then a single one at the
very end would be sufficient. We have that anyway in the form
of eg. scanline/frame counter reads.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-2-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Colin Ian King [Wed, 7 Nov 2018 10:22:11 +0000 (10:22 +0000)]
drm/i915/csr: fix spelling mistake "firmare" -> "firmware"
Trivial fix to spelling mistake in DRM_INFO message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107102211.19758-1-colin.king@canonical.com
Chris Wilson [Mon, 5 Nov 2018 09:43:05 +0000 (09:43 +0000)]
drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5
Exercising the gpu reloc path strenuously revealed an issue where the
updated relocations (from MI_STORE_DWORD_IMM) were not being observed
upon execution. After some experiments with adding pipecontrols (a lot
of pipecontrols (32) as gen4/5 do not have a bit to wait on earlier pipe
controls or even the current on), it was discovered that we merely
needed to delay the EMIT_INVALIDATE by several flushes. It is important
to note that it is the EMIT_INVALIDATE as opposed to the EMIT_FLUSH that
needs the delay as opposed to what one might first expect -- that the
delay is required for the TLB invalidation to take effect (one presumes
to purge any CS buffers) as opposed to a delay after flushing to ensure
the writes have landed before triggering invalidation.
Testcase: igt/gem_tiled_fence_blits
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105094305.5767-1-chris@chris-wilson.co.uk
Kuo-Hsin Yang [Tue, 6 Nov 2018 13:23:24 +0000 (13:23 +0000)]
mm, drm/i915: mark pinned shmemfs pages as unevictable
The i915 driver uses shmemfs to allocate backing storage for gem
objects. These shmemfs pages can be pinned (increased ref count) by
shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan
wastes a lot of time scanning these pinned pages. In some extreme case,
all pages in the inactive anon lru are pinned, and only the inactive
anon lru is scanned due to inactive_ratio, the system cannot swap and
invokes the oom-killer. Mark these pinned pages as unevictable to speed
up vmscan.
Export pagevec API check_move_unevictable_pages().
This patch was inspired by Chris Wilson's change [1].
[1]: https://patchwork.kernel.org/patch/
9768741/
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Kuo-Hsin Yang <vovoy@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.com> # mm part
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ville Syrjälä [Mon, 5 Nov 2018 19:46:04 +0000 (21:46 +0200)]
drm/i915: Don't oops during modeset shutdown after lpe audio deinit
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already be gone when it comes time to shut down the crtc.
As we don't know when the last reference to the platform
device gets dropped by the audio driver we can't assume that
the device and its data are still around when turning off the
crtc. Mark the platform device as gone as soon as we do the
audio deinit.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105194604.6994-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Mon, 5 Nov 2018 17:06:40 +0000 (17:06 +0000)]
drm/i915: Break long iterations for get/put shmemfs pages
As we may have to iterate a few thousand elements to acquire and release
the shmemfs backing storage for a GPU object, we need to break up the
long loop with cond_resched() to retain a modicum of low latency for
other processes.
Testcase: igt/benchmarks/gem_syslatency
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kuo-Hsin Yang <vovoy@chromium.org>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105170640.26905-1-chris@chris-wilson.co.uk
Uma Shankar [Thu, 1 Nov 2018 19:10:20 +0000 (00:40 +0530)]
drm/i915/icl: Enable Plane Input CSC for YUV to RGB Conversion
Plane input CSC needs to be enabled to convert frambuffers from
YUV to RGB. This is needed for bottom 3 planes on ICL, rest of
the planes have hardcoded conversion and taken care by the legacy
code.
This patch defines the co-efficient values for YUV to RGB conversion
in BT709 and BT601 formats. It programs the coefficients and enables
the plane input csc unit in hardware.
This has been verified and tested by Maarten and the change is working
as expecpted.
v2: Addressed Maarten's and Ville's review comments and added the
coefficients in a 2D array instead of independent Macros.
v3: Added individual coefficient matrix (9 values) instead of 6
register values as per Maarten's comment. Also addresed a shift
issue with B channel coefficient.
v4: Added support for Limited Range Color Handling
v5: Fixed Matt and Maarten's review comments.
v6: Added human readable matrix values for YUV to RGB Conversion along
with just the bspec register values, as per Matt's suggestion.
v7: Refactored the code, move csc coefficient programming function to
intel_sprite.c and made it static as per Ville's review comment.
v8: Addressed Ville's review comment. Called the coefficient programming
from within the skl_program_plane and used I915_WRITE_FW instead of
I915_WRITE.
v9: Fixed Ville's review comments.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541099420-12419-3-git-send-email-uma.shankar@intel.com
Uma Shankar [Thu, 1 Nov 2018 19:10:19 +0000 (00:40 +0530)]
drm/i915/icl: Define Plane Input CSC Coefficient Registers
Defined the plane input csc coefficient registers and macros.
6 registers are used to program a total of 9 coefficients,
added macros to define each of them for all the planes
supporting the feature on pipes. On ICL, bottom 3 planes
have this capability.
v2: Segregated the register macro definition as separate patch
as per Maarten's suggestion.
v3: Removed a redundant 3rd Pipe register definition and
simplified the equally spaced register definition by adding an
offset as per Matt's comment.
v4: No Change
v5: Renamed the register Macro as per Matt's suggestion.
v6: No Change
v7: No Change
v8: No Change
v9: No Change
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541099420-12419-2-git-send-email-uma.shankar@intel.com
Ville Syrjälä [Thu, 25 Oct 2018 13:05:36 +0000 (16:05 +0300)]
drm/i915: Fix ilk+ watermarks when disabling pipes
We're no longer programming any watermarks when we're disabling
a pipe. That means ilk_wm_merge() & co. will keep considering
the any pipe that is getting disabled as still enabled. Thus we
either get no LP1+ watermakrs (ilk-ivb), or we get suboptimal
ones (hsw-bdw).
This seems to have been broken by commit
b6b178a77210 ("drm/i915:
Calculate ironlake intermediate watermarks correctly, v2."). Before
that we apparently had some difference between the intermediate
and optimal watermarks and so we would program the optiomal ones.
Now intermediate and optimal are identical for disabled pipes
and so we don't program either.
Fix this by programming the intermediate watermarks even for
disabled pipes. We were already doing that for skl+. We'll
leave out gmch platforms for now since those do the merging
in a different manner and should work as is. We'll want to
unify this eventually, but play it safe for now and just put
in a FIXME.
Cc: stable@vger.kernel.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025130536.29024-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Imre Deak [Wed, 31 Oct 2018 20:02:20 +0000 (22:02 +0200)]
drm/i915/gen9_lp: Fix DMC DC counter debugfs output
On GEN9 LP (BXT/GLK) DC6 is not supported, so don't print the counter
on those platforms. So far we did this on GLK too.
While at it warn if we forgot to adjust the printout properly for a
new platform. (Rodrigo)
Testcase: igt/pm_dc/dc6-dpms
Cc: Jyoti Yadav <jyoti.r.yadav@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031200220.11608-1-imre.deak@intel.com
Imre Deak [Fri, 2 Nov 2018 19:26:56 +0000 (21:26 +0200)]
drm/i915/icl: Configure MG DP mode for HDMI ports too
The MG DP mode needs to be configured for Type C static/fixed/legacy
HDMI ports too, the same way as it's configured for Type C
static/fixed/legacy, fix this.
Bspec: 4232, 21735
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102192656.4472-3-imre.deak@intel.com
Imre Deak [Fri, 2 Nov 2018 19:26:55 +0000 (21:26 +0200)]
drm/i915/icl: Configure MG PHY gating for HDMI ports too
The MG PHY clock gating needs to be configured for Type C
static/fixed/legacy HDMI ports the same way it's configured for Type C
static/fixed/legacy and aternate mode DP ports, fix this.
Bspec: 4232, 21735
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102192656.4472-2-imre.deak@intel.com
Anusha Srivatsa [Fri, 2 Nov 2018 04:14:55 +0000 (21:14 -0700)]
drm/dp/fec: DRM helper for Forward Error Correction
DP 1.4 has Forward Error Correction Support(FEC).
Add helper function to check if the sink device
supports FEC.
v2: Separate the helper and the code that uses the helper into
two separate patches. (Manasi)
v3:
- Move the code to drm_dp_helper.c (Manasi)
- change the return type, code style changes (Gaurav)
- Use drm_dp_dpcd_readb instead of drm_dp_dpcd_read. (Jani)
v4:
- Avoid aux reads everytime, instead read cached
values of dpcd register (jani)
- Move helper to drm_dp_helper.h like other dsc
helpers.(Anusha)
v5: rebased. Change the helper parameter suitably.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102041455.15818-2-anusha.srivatsa@intel.com
Anusha Srivatsa [Fri, 2 Nov 2018 04:14:54 +0000 (21:14 -0700)]
i915/dp/fec: Cache the FEC_CAPABLE DPCD register
Similar to DSC DPCD registers, let us cache
FEC_CAPABLE register to avoid using stale
values. With this we can avoid aux reads
everytime and instead read the cached values.
v2: Avoid using memset and array for a single
field. (Manasi,Jani)
v3: Print FEC CAPABILITY value. (Manasi)
Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102041455.15818-1-anusha.srivatsa@intel.com
Chris Wilson [Fri, 2 Nov 2018 16:12:09 +0000 (16:12 +0000)]
drm/i915: Mark pin flags as u64
Since the flags are being used to operate on a u64 variable, they too
need to be marked as such so that the inverses are full width (and not
zero extended on 32b kernels and bdw+).
Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102161232.17742-2-chris@chris-wilson.co.uk
Anusha Srivatsa [Thu, 1 Nov 2018 18:55:57 +0000 (11:55 -0700)]
drm/i915/fia: FIA registers offset implementation.
The registers DPCSSS,DPSP,DPMLE1 and DPPMS are all at an offset
from the base - which is the FLexi IO Adaptor. Lets follow the
offset calculation while accessing these registers.
v2:
- Follow spec for numbering - s/0/1(Lucas)
- s/FIA_1/FIA1_BASE (Anusha)
v3:
- Remove register offset defines. (Jani)
- Update comment. (Anusha)
v4: rebase. Remove comment.(Lucas)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101185557.29585-1-anusha.srivatsa@intel.com
Ville Syrjälä [Wed, 24 Oct 2018 15:48:25 +0000 (18:48 +0300)]
ALSA: x86: Rip out the lpe audio runtime suspend/resume hooks
Ever since commit
46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime
pm as "no callbacks"") the runtime suspend/resume hooks are no longer
used. Inline them into the system suspend hooks.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Takashi Iwai <tiwai@suse.de>
Ville Syrjälä [Wed, 24 Oct 2018 15:48:24 +0000 (18:48 +0300)]
ALSA: x86: Fix runtime PM for hdmi-lpe-audio
Commit
46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as
"no callbacks"") broke runtime PM with lpe audio. We can no longer
runtime suspend the GPU since the sysfs power/control for the
lpe-audio device no longer exists and the device is considered
always active. We can fix this by not marking the device as
active.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Fixes: 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks"")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Takashi Iwai <tiwai@suse.de>
Radhakrishna Sripada [Tue, 23 Oct 2018 01:44:00 +0000 (18:44 -0700)]
drm/i915: Allow "max bpc" property to limit pipe_bpp
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
V12: Fix debug message(Ville)
V13: Remove the redundant check and simplify the check logic(Stan)
V14: Fix the check in connected_sink_max_bpp(Stan)
v15 (From Manasi): Add missing break (Stan)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Kishore Kadiyala <kishore.kadiyala@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023014400.16055-1-manasi.d.navare@intel.com
Radhakrishna Sripada [Fri, 12 Oct 2018 18:42:32 +0000 (11:42 -0700)]
drm: Add connector property to limit max bpc
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.
Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.
V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
V8: Simplify the connector check code(Ville)
V9: Const display_info(Ville)
V10,V11: Fix CI issues.
V12: Add the Kernel documentation(Daniel)
V14: Crossreference the function name in the doc(Daniel)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kishore Kadiyala <kishore.kadiyala@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Sunpeng Li <sunpeng.li@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181012184233.29250-1-radhakrishna.sripada@intel.com
Jani Nikula [Fri, 2 Nov 2018 10:04:11 +0000 (12:04 +0200)]
drm/i915: Update DRIVER_DATE to
20181102
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Wed, 31 Oct 2018 11:04:53 +0000 (13:04 +0200)]
drm/i915: also group device info array helper macros with others
Keep the register choosing macros together. No functional changes.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031110453.12722-4-jani.nikula@intel.com
Jani Nikula [Wed, 31 Oct 2018 11:04:52 +0000 (13:04 +0200)]
drm/i915: reorder and reindent the register choosing helper wrappers
Try to make it slightly less of an eye sore. No functional changes.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031110453.12722-3-jani.nikula@intel.com
Jani Nikula [Wed, 31 Oct 2018 11:04:51 +0000 (13:04 +0200)]
drm/i915: define _MMIO_PLANE() in terms of _PLANE() not _MMIO_PIPE()
Minor semantic nit, no functional changes.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031110453.12722-2-jani.nikula@intel.com
Jani Nikula [Wed, 31 Oct 2018 11:04:50 +0000 (13:04 +0200)]
drm/i915: remove palette_offsets from device info in favor of _PICK()
The device info offset arrays for unevenly spaced register offsets is
great for widely used registers. However, the palette registers are only
used in one function, i9xx_load_luts_internal(), and only for GMCH
platforms, wasting device info. Replace palette_offsets with _PICK() in
palette register definition.
While the use of _PICK() does not check for pipe C existence, neither
does the current offset array usage, and leads to bogus address when
pipe C is passed to PALETTE() on non-CHV. Using _PICK() at least leads
to a sensible register offset, just non-existing on non-CHV. Either way,
this shouldn't happen anyway.
Remove unused old palette macros while at it.
Bloat-o-meter results below for completeness.
add/remove: 0/0 grow/shrink: 3/6 up/down: 94/-278 (-184)
Function old new delta
i9xx_load_luts_internal 394 483 +89
i915_driver_load 5103 5107 +4
g4x_pre_enable_dp 378 379 +1
intel_engines_init_mmio 1117 1116 -1
intel_engine_lookup_user 47 46 -1
hdmi_port_clock_valid 310 309 -1
gen11_irq_handler 707 706 -1
intel_device_info_dump_runtime 329 311 -18
intel_device_info_runtime_init 5166 4910 -256
Total: Before=918650, After=918466, chg -0.02%
add/remove: 0/0 grow/shrink: 0/48 up/down: 0/-576 (-576)
Data old new delta
intel_valleyview_info 200 188 -12
intel_skylake_gt4_info 200 188 -12
intel_skylake_gt3_info 200 188 -12
intel_skylake_gt2_info 200 188 -12
intel_skylake_gt1_info 200 188 -12
intel_sandybridge_m_gt2_info 200 188 -12
intel_sandybridge_m_gt1_info 200 188 -12
intel_sandybridge_d_gt2_info 200 188 -12
intel_sandybridge_d_gt1_info 200 188 -12
intel_pineview_info 200 188 -12
intel_kabylake_gt3_info 200 188 -12
intel_kabylake_gt2_info 200 188 -12
intel_kabylake_gt1_info 200 188 -12
intel_ivybridge_q_info 200 188 -12
intel_ivybridge_m_gt2_info 200 188 -12
intel_ivybridge_m_gt1_info 200 188 -12
intel_ivybridge_d_gt2_info 200 188 -12
intel_ivybridge_d_gt1_info 200 188 -12
intel_ironlake_m_info 200 188 -12
intel_ironlake_d_info 200 188 -12
intel_icelake_11_info 200 188 -12
intel_i965gm_info 200 188 -12
intel_i965g_info 200 188 -12
intel_i945gm_info 200 188 -12
intel_i945g_info 200 188 -12
intel_i915gm_info 200 188 -12
intel_i915g_info 200 188 -12
intel_i865g_info 200 188 -12
intel_i85x_info 200 188 -12
intel_i845g_info 200 188 -12
intel_i830_info 200 188 -12
intel_haswell_gt3_info 200 188 -12
intel_haswell_gt2_info 200 188 -12
intel_haswell_gt1_info 200 188 -12
intel_gm45_info 200 188 -12
intel_geminilake_info 200 188 -12
intel_g45_info 200 188 -12
intel_g33_info 200 188 -12
intel_coffeelake_gt3_info 200 188 -12
intel_coffeelake_gt2_info 200 188 -12
intel_coffeelake_gt1_info 200 188 -12
intel_cherryview_info 200 188 -12
intel_cannonlake_info 200 188 -12
intel_broxton_info 200 188 -12
intel_broadwell_rsvd_info 200 188 -12
intel_broadwell_gt3_info 200 188 -12
intel_broadwell_gt2_info 200 188 -12
intel_broadwell_gt1_info 200 188 -12
Total: Before=195529, After=194953, chg -0.29%
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031110453.12722-1-jani.nikula@intel.com
Jani Nikula [Fri, 2 Nov 2018 07:00:55 +0000 (09:00 +0200)]
Merge drm/drm-next into drm-intel-next-queued
Although there's nothing crucial missing, it's been a long time since
the last backmerge. Catch up with drm-next.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Dave Airlie [Fri, 2 Nov 2018 05:17:56 +0000 (15:17 +1000)]
Merge tag 'drm-intel-next-fixes-2018-10-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- Fix to avoid link retraining workaround on eDP (the other is a comment change)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025131836.GA2296@jlahtine-desk.ger.corp.intel.com
Anusha Srivatsa [Thu, 1 Nov 2018 21:42:16 +0000 (14:42 -0700)]
drm/i915/icl: Fix DSS_CTL register names
This patch fixes the naming of the registers:
s/PIPE_DSS_CTL/ICL_PIPE_DSS_CTL
And also fix the hex values to lower case, to match
rest of the definitions.
Manasi noticed this with the patch that was merged.
v2: fix "Fixes" tag.
Fixes: 8b1b558d690a ("drm/i915/icl: Add DSS_CTL Registers")
Suggested-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101214216.8958-1-anusha.srivatsa@intel.com
Dave Airlie [Fri, 2 Nov 2018 02:56:24 +0000 (12:56 +1000)]
Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next
- Fix flickering at low backlight levels on some systems
- Fix some overclocking regressions
- Vega20 updates for
- GPU recovery fixes
- Disable gfxoff on RV as some sbios/fw combinations are not stable yet
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101151939.2828-1-alexander.deucher@amd.com
Dave Airlie [Fri, 2 Nov 2018 01:53:48 +0000 (11:53 +1000)]
Merge tag 'drm-misc-next-fixes-2018-10-31' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
- Properly label Innolux TV123WAM as P120ZDG-BF1 (Doug)
- Add optional delay for panels without hpd hooked up (which solves the
mystery delay for TI SN65DSI86 bridge) (Doug)
- Another 6bpc quirk for BOE panel 0x0771 (Shawn)
Cc: Doug Anderson <dianders@chromium.org>
Cc: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031201944.GA262020@art_vandelay
Imre Deak [Thu, 1 Nov 2018 14:04:27 +0000 (16:04 +0200)]
drm/i915/icl+: Sanitize port to PLL mapping
BIOS can leave the PLL to port mapping enabled, even if the
corresponding encoder is disabled. Disable the port mapping in this
case.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-9-imre.deak@intel.com
Imre Deak [Thu, 1 Nov 2018 14:04:26 +0000 (16:04 +0200)]
drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain
Most of the AUX_CH_CTL flags are concerned with DP AUX transfer
parameters. As opposed to this the flag specifying the thunderbolt vs.
non-thunderbolt mode of the port is not related to AUX transfers at all
(rather it's repurposed to enable either TBT or non-TBT PHY HW blocks).
The programming has to be done before enabling the corresponding AUX
power well, so make it part of the power well code.
v3:
- Use existing enable/disable helpers instead of opencoding. (Jose)
- Fix type of is_tc_tbt to remain a bitfield. (Lucas)
- Add comment describing the is_tc_tbt power well flag. (Lucas)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108548
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-8-imre.deak@intel.com
Imre Deak [Thu, 1 Nov 2018 14:04:25 +0000 (16:04 +0200)]
drm/i915: Enable AUX power for HDMI DDI/TypeC main link too
DDI/TypeC ports need the AUX power domain for main link functionality
even when they operate in HDMI static mode, so enable the power domain
for these ports too.
v4:
- Rebase on the upstream ICL pre_pll_enable change.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-7-imre.deak@intel.com
Imre Deak [Thu, 1 Nov 2018 14:04:24 +0000 (16:04 +0200)]
drm/i915: Enable AUX power earlier
For DDI/TypeC ports the AUX power domain needs to be enabled before the
port's PLL is enabled, so move the enabling earlier accordingly.
v2:
- Preserve the pre_pll hook for GEN9_LP. (Ville)
v3:
- Add related BSpec entries to commit log. (Jose)
v4:
- Rebase on the upstream ICL pre_pll_enable change.
BSpec: 21750, 22243
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-6-imre.deak@intel.com
Imre Deak [Thu, 1 Nov 2018 14:04:23 +0000 (16:04 +0200)]
drm/i915: Use a helper to get the aux power domain
From ICL onwards the AUX power domain may change dynamically based on
whether a DDI/TypeC port is in thunderbolt or non-thunderbolt mode, so
use a helper function instead of a static field to get the current
domain.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-5-imre.deak@intel.com
Imre Deak [Thu, 1 Nov 2018 14:04:22 +0000 (16:04 +0200)]
drm/i915: Init aux_ch for HDMI ports too
From ICL onwards DDI/TypeC ports - even in HDMI static mode - need to know
which AUX CH belongs to them, so initialize aux_ch for those ports too.
For consistency do this for all HDMI ports, not only for DDI/TypeC ones.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-4-imre.deak@intel.com
Imre Deak [Thu, 1 Nov 2018 14:04:21 +0000 (16:04 +0200)]
drm/i915: Move aux_ch to intel_digital_port
From ICL onwards all DDI/TypeC ports - even working in HDMI mode - need
to know their corresponding AUX CH, so move the field to a common
struct.
No functional change.
v3:
- Add code comment about which ports aux_ch is used for. (Jose)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-3-imre.deak@intel.com
Imre Deak [Thu, 1 Nov 2018 14:04:20 +0000 (16:04 +0200)]
drm/i915: Move intel_aux_ch() to intel_bios.c
From ICL onwards all the DDI/TypeC ports - even working in HDMI mode -
need to know their corresponding AUX channel, so move the corresponding
helper to a common place.
No functional change.
v4:
- Fix 'no space is necessary after a cast' checkpatch warn.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-2-imre.deak@intel.com
Oscar Mateo [Tue, 30 Oct 2018 08:45:04 +0000 (01:45 -0700)]
drm/i915/icl: WaAllowUMDToModifySamplerMode
Required for Bindless samplers.
Userspace consumer: mesa
V2: Rebase
V3: Update commit message
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030084504.21537-4-radhakrishna.sripada@intel.com
Oscar Mateo [Tue, 30 Oct 2018 08:45:03 +0000 (01:45 -0700)]
drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken7
Required to dinamically set 'Trilinear Filter Quality Mode'
Userpsace consumer is mesa.
V2: Rebase
V3: Update commit message
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030084504.21537-3-radhakrishna.sripada@intel.com
Radhakrishna Sripada [Tue, 30 Oct 2018 08:45:02 +0000 (01:45 -0700)]
drm/i915/icl: Implement Display WA_1405510057
Display WA_1405510057 asks to not enable YUV 420 HDMI
10bpc when horizontal blank size mod 8 reminder is 2.
V2: Rebase(r-b: Anusha)
V3: crtc_state->s/ycbcr420/output_format/
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030084504.21537-2-radhakrishna.sripada@intel.com
Radhakrishna Sripada [Tue, 30 Oct 2018 08:45:01 +0000 (01:45 -0700)]
drm/i915/icl: Add WaEnable32PlaneMode
Gen11 Display suports 32 planes in total. Enable the new format in context
status to be used and expanded to 32 planes.
V2: Move the WA to display WA's(Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030084504.21537-1-radhakrishna.sripada@intel.com
Rodrigo Vivi [Wed, 31 Oct 2018 16:28:45 +0000 (09:28 -0700)]
drm/i915: Remove CNL from WA 827
CNL A stepping was the only affected there.
But also it is time to clean old pre-production
CNL Workarounds, so let's just remove and clean
this W/A.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031162845.12419-4-rodrigo.vivi@intel.com
Rodrigo Vivi [Wed, 31 Oct 2018 16:28:44 +0000 (09:28 -0700)]
drm/i915: Define WA 0870 and kill dead code.
Let's introduce the WA number that is the
cause of having NV12 disabled on both SLK and BXT.
According to Spec:
WA 0870: "Display flickers with NV12 video playback in
Y tiling mode.
WA: Use YUV422 surface format instead of NV12."
v2: remove the useless dead code and consequently
avoiding device info flag. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031162845.12419-3-rodrigo.vivi@intel.com
Rodrigo Vivi [Wed, 31 Oct 2018 16:28:43 +0000 (09:28 -0700)]
drm/i915: Kill WA 0826
According to BSpec this is not needed anymore:
"This workaround is no longer needed since NV12
support is dropped for the affected projects.
"
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031162845.12419-2-rodrigo.vivi@intel.com
Rodrigo Vivi [Wed, 31 Oct 2018 16:28:42 +0000 (09:28 -0700)]
drm/i915: Kill WA 0528
First of all I believe this WA as written here was wrong.
Because it is listed on BSpec only for SKL and BXT, exactly
the only 2 platforms skipped here.
But also it is written there that we don't need this WA
anymore:
"This workaround is no longer needed since NV12 support is
dropped for the affected projects in #0870."
SO, let's kill it.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031162845.12419-1-rodrigo.vivi@intel.com
Anusha Srivatsa [Wed, 31 Oct 2018 20:27:26 +0000 (13:27 -0700)]
drm/i915/icl: Fix DC9 Suspend for ICL.
Add missing block that takes care of inline intel_suspend_complete
for DC9 on ICL.
Daniele noticed this was part of original patch but missed on
on merged commit ("drm/i915/icl: Enable DC9 as lowest possible
state during screen-off").
Fixes: 3e68928b7d4c ("drm/i915/icl: Enable DC9 as lowest possible state during screen-off")
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo added a commit message while merging]
Link: https://patchwork.freedesktop.org/patch/msgid/20181031202726.4021-1-anusha.srivatsa@intel.com
Anusha Srivatsa [Tue, 30 Oct 2018 11:56:35 +0000 (13:56 +0200)]
drm/i915/icl: Add DSS_CTL Registers
Add defines for DSS_CTL registers.
These registers specify the big joiner, splitter,
overlap pixels and info regarding
compression enabled on left or right branch.
v2:
- rebase. Remove overlapping defines(James Ausmus)
- Rename the register to ICL_DSS_CTL1/2_PIPE_ (manasi)
- take pixels as an argument for overlap.(Manasi)
v3:
- rebase. merge DSS_CTL1/2 introduced in Madhav's patch
to avoid confusion (madhav chauhan)
- Rename registers in accordance to BSpec (Madhav, Rodrigo)
- Add define to conditionally check the buffer target depth (James Ausmus)
v4:
- remove redundant definitions.(madhav)
v5:
- Add mask for overlap pixels.
- Code Style changes.(Madhav)
v6:
- Code style changes. (Madhav)
Suggested-by: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Gaurav Singh <gaurav.k.singh@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/07021336cb87d09e8f97fbff709c4e686d7de536.1540900289.git.jani.nikula@intel.com
Christian König [Wed, 24 Oct 2018 12:59:10 +0000 (14:59 +0200)]
drm/amdgpu: revert "enable gfxoff in non-sriov and stutter mode by default"
This is still completely breaking my Raven system.
This reverts commit
cdf2f910fa969adca1b0e3ad2b487821233dc038.
Revert until we sort out the sbios and firmware combinations that work
correctly.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=108606
Cc: stable@vger.kernel.org # v4.19
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
projects / openwrt / staging / blogic.git / log