Chris Wilson [Fri, 28 Dec 2018 14:07:35 +0000 (14:07 +0000)]
drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation
The writing is on the wall for the existence of a single execution queue
along each engine, and as a consequence we will not be able to track
dependencies along the HW queue itself, i.e. we will not be able to use
HW semaphores on gen7 as they use a global set of registers (and unlike
gen8+ we can not effectively target memory to keep per-context seqno and
dependencies).
On the positive side, when we implement request reordering for gen7 we
also can not presume a simple execution queue and would also require
removing the current semaphore generation code. So this bring us another
step closer to request reordering for ringbuffer submission!
The negative side is that using interrupts to drive inter-engine
synchronisation is much slower (4us -> 15us to do a nop on each of the 3
engines on ivb). This is much better than it was at the time of introducing
the HW semaphores and equally important userspace weaned itself off
intermixing dependent BLT/RENDER operations (the prime culprit was glyph
rendering in UXA). So while we regress the microbenchmarks, it should not
impact the user.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108888
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/20181228140736.32606-2-chris@chris-wilson.co.uk
Chris Wilson [Fri, 28 Dec 2018 14:07:34 +0000 (14:07 +0000)]
drm/i915: Restrict PSMI context load w/a to Haswell GT1
After we found a workaround for a hang on context load, Ben Widawsky
found confirmation that it was for an issue with waking from rc6 and
loading a context image.
The workaround from on high suggests that we should
I915_WRITE(RING_WAIT_FOR_RC6_EXIT(engine->mmio_base),
_MASKED_FIELD(RING_RC6_SEL_WRITE_ADDR_MASK,
RING_RC6_SEL_WRITE_ADDR_UPPER_LEFT));
in our rc6 setup for Haswell GT1, but on applying that we find instead
that the machine encounters a GT forcewake error and locks up.
As we are removing HW semaphore usage in the next patch, and the
suggested workaround is no improvement, we need to
decouple the PSMI workaround from HAS_SEMAPHORES to IS_HSW_GT1.
References:
2c550183476d ("drm/i915: Disable PSMI sleep messages on all rings around context switches")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181228140736.32606-1-chris@chris-wilson.co.uk
Young Xiao [Mon, 17 Dec 2018 12:23:03 +0000 (12:23 +0000)]
drm/i915: avoid division by zero on skl_calc_wrpll_link
If for some unexpected reason the registers all read zero it's better
to WARN and return instead of dividing by zero and completely freezing
the machine.
See commit
0e005888b833 ("drm/i915: avoid division by zero on
cnl_calc_wrpll_link") for detail.
Signed-off-by: Young Xiao <YangX92@hotmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/SG2PR01MB2169F6E95BC8BB5E29477042ADBC0@SG2PR01MB2169.apcprd01.prod.exchangelabs.com
Brajeswar Ghosh [Tue, 25 Dec 2018 13:30:56 +0000 (19:00 +0530)]
drm/intel_dsi_vbt: Remove duplicate header
Remove video/mipi_display.h which is included more than once
Signed-off-by: Brajeswar Ghosh <brajeswar.linux@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181225133055.GA2628@hp-pavilion-15-notebook-pc-brajeswar
Chris Wilson [Thu, 27 Dec 2018 12:15:49 +0000 (12:15 +0000)]
drm/i915: Remove debugfs/i915_ppgtt_info
The information presented here is not relevant to current development.
We can either use the context information, but more often we want to
inspect the active gpu state.
The ulterior motive is to eradicate dev->filelist.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181227121549.29139-1-chris@chris-wilson.co.uk
Brajeswar Ghosh [Tue, 25 Dec 2018 13:23:40 +0000 (18:53 +0530)]
drm/i915: Remove duplicate header from i915_request.h
Remove i915_scheduler.h which is included more than once
Signed-off-by: Brajeswar Ghosh <brajeswar.linux@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181225132340.GA2584@hp-pavilion-15-notebook-pc-brajeswar
Hans de Goede [Thu, 20 Dec 2018 13:21:20 +0000 (14:21 +0100)]
drm/i915: DDI: call intel_psr_ and _edp_drrs_enable() on pipe updates (v2)
Call intel_psr_enable() and intel_edp_drrs_enable() on pipe updates to make
sure that we enable PSR / DRRS (when applicable) on fastsets.
Note calling these functions when PSR / DRRS has already been enabled is a
no-op, so it is safe to do this on every encoder->update_pipe callback.
Changes in v2:
-Merge the patches adding the intel_psr_enable() and intel_edp_drrs_enable()
calls into a single patch
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181220132120.15318-3-hdegoede@redhat.com
Hans de Goede [Thu, 20 Dec 2018 13:21:19 +0000 (14:21 +0100)]
drm/i915: Allow calling intel_edp_drrs_enable twice
Do not make it an error to call intel_edp_drrs_enable while drrs has
already been enabled, instead exit silently in this case.
This is a preparation patch for ensuring that DRRS is enabled on fastsets.
Note that the removed WARN_ON could also be triggered from userspace
through the i915_drrs_ctl debugfs entry which was added by
commit
35954e88bc50 ("drm/i915: Runtime disable for eDP DRRS")
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181220132120.15318-2-hdegoede@redhat.com
Hans de Goede [Thu, 20 Dec 2018 13:21:18 +0000 (14:21 +0100)]
drm/i915: Add an update_pipe callback to intel_encoder and call this on fastsets (v2)
When we are doing a fastset (needs_modeset=false, update_pipe=true) we
may need to update some encoder-level things such as checking that PSR
is enabled.
This commit adds an update_pipe callback to intel_encoder and a new
intel_encoders_update_pipe helper which calls this for all encoders
connected to a crtc. The new intel_encoders_update_pipe helper is called
from intel_update_crtc when doing a fastset.
Changes in v2:
-Name the new encoder callback update_pipe instead of just update
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181220132120.15318-1-hdegoede@redhat.com
Chris Wilson [Sat, 22 Dec 2018 03:06:23 +0000 (03:06 +0000)]
drm/i915: Unwind failure on pinning the gen7 ppgtt
If we fail to pin the ggtt vma slot for the ppgtt page tables, we need
to unwind the locals before reporting the error. Or else on subsequent
attempts to bind the page tables into the ggtt, we will already believe
that the vma has been pinned and continue on blithely. If something else
should happen to be at that location, choas ensues.
Fixes: a2bbf7148342 ("drm/i915/gtt: Only keep gen6 page directories pinned while active")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: <stable@vger.kernel.org> # v4.19+
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181222030623.21710-1-chris@chris-wilson.co.uk
Rodrigo Vivi [Fri, 21 Dec 2018 20:04:38 +0000 (12:04 -0800)]
drm/i915: Update DRIVER_DATE to
20181221
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rodrigo Vivi [Fri, 21 Dec 2018 19:12:44 +0000 (11:12 -0800)]
drm/i915: Update DRIVER_DATE to
20181221
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Paulo Zanoni [Wed, 14 Nov 2018 01:24:32 +0000 (17:24 -0800)]
drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+
BSpec does not show these WAs as applicable to GLK, and for CNL it
only shows them applicable for a super early pre-production stepping
we shouldn't be caring about anymore. Remove these so we can avoid
them on ICL too.
v2: Change how we check for gen9 display platforms (Ville).
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114012432.21809-1-paulo.r.zanoni@intel.com
Maarten Lankhorst [Thu, 20 Dec 2018 15:17:19 +0000 (16:17 +0100)]
drm/i915: Disable FBC on fastset if necessary, v2.
Without this, we will get a dmesg-warn when enable_fbc is cleared on a fastset:
WARN_ON(!crtc_state->enable_fbc)
WARNING: CPU: 0 PID: 1090 at drivers/gpu/drm/i915/intel_fbc.c:1091 intel_fbc_enable+0x2ce/0x580 [i915]
RIP: 0010:intel_fbc_enable+0x2ce/0x580 [i915]
Call Trace:
? __mutex_unlock_slowpath+0x46/0x2b0
intel_update_crtc+0x6f/0x2b0 [i915]
skl_update_crtcs+0x1d1/0x2b0 [i915]
intel_atomic_commit_tail+0x1ea/0xdb0 [i915]
intel_atomic_commit+0x244/0x330 [i915]
drm_mode_atomic_ioctl+0x85d/0x950
? drm_atomic_set_property+0x970/0x970
drm_ioctl_kernel+0x81/0xf0
drm_ioctl+0x2de/0x390
? drm_atomic_set_property+0x970/0x970
? __handle_mm_fault+0x81b/0xfc0
do_vfs_ioctl+0xa0/0x6e0
? __do_page_fault+0x2a5/0x550
ksys_ioctl+0x35/0x60
__x64_sys_ioctl+0x11/0x20
do_syscall_64+0x55/0x190
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Changes since v1:
- Move intel_fbc_disable to intel_update_crtc() (Hans)
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181220151719.30586-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Manasi Navare [Wed, 19 Dec 2018 23:51:20 +0000 (15:51 -0800)]
drm/i915/dsc: Fix the deadlock in dsc debugfs node
The DSC debugfs node causes a possible deadlock situation. This patch
resets the try_again at the beginning of loop to fix this.
Fixes: e845f099f1c6 ('drm/i915/dsc: Add Per connector debugfs node for DSC support/enable')
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109097
Cc: Lyude Paul <lyude@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181219235120.21816-1-manasi.d.navare@intel.com
Imre Deak [Fri, 14 Dec 2018 18:27:03 +0000 (20:27 +0200)]
drm/i915/icl: Add fallback detection method for TypeC legacy ports
Add a fallback detection method for TypeC legacy ports in case the
VBT port information used to detect normally such ports is
incorrect.
For the fallback method we use the TypeC legacy mode specific HPD
interrupt flag which should only be raised for a legacy port.
WARN if the VBT port info is incorrect.
In a case where we'd detect the port in a contradicting way both as a
legacy and also as a USB DP and/or TBT alternate port treat the port
as legacy (by also emitting a WARN from icl_update_tc_port_type).
v2:
- Repurpose the detection as a fallback method instead of using
it only for the DP legacy case. By now we should normally use VBT to
detect DP legacy ports as well.
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> (v1)
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-5-imre.deak@intel.com
Imre Deak [Fri, 14 Dec 2018 18:27:02 +0000 (20:27 +0200)]
drm/i915/icl: Fix HPD handling for TypeC legacy ports
Atm HPD disconnect events on TypeC ports will break things, since we'll
switch the TypeC mode (between legacy and disconnected modes as well as
among USB DP alternate, Thunderbolt alternate and disconnected modes) on
the fly from the HPD disconnect interrupt work while the port may be
still active.
Even if the port happens to be not active during the disconnect we'd
still have a problem during a subsequent modeset or AUX transfer that
could happen regardless of the port's connected state. For instance the
system resume display mode restore code and userspace could perform a
modeset on the port or userspace could start an AUX transfer even if the
port is in disconnected state.
To fix this keep TypeC legacy ports in legacy mode whenever we're not
suspended. This mode is a static configuration as opposed to the
Thunderbolt and USB DP alternate modes between which we can switch
dynamically.
We determine if a TypeC port is legacy (wired to a legacy HDMI or a
legacy DP connector) via the VBT DDI port specific USB-TypeC and
Thunderbolt flags. If both these flags are cleared then the port is
configured for legacy mode.
On such legacy ports we'll run the TypeC PHY connect sequence explicitly
during driver loading and system resume (vs. running the sequence during
HPD processing). The connect will succeed even if the display is not
connected to begin with (or disappears during the suspended state) since
for legacy ports the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED
flag is always set (as opposed to the USB DP alternate mode where it
gets set only when a display is connected).
Correspondingly run the TypeC PHY disconnect sequence during system
suspend and driver unloading. For the unloading case I had to split
up intel_dp_encoder_destroy() to be able to have the 1. flush any
pending encoder work, 2. disconnect TC PHY, 3. call DRM core cleanup and
kfree on the encoder object.
For now run the PHY disconnect during suspend only for TypeC legacy
ports. We will need to disconnect even in USB DP alternate mode in the
future, but atm we don't have a way to reconnect the port in this mode
during resume if the display disappears while being suspended. So for
now punt on this case.
Note that we do not disconnect the port during runtime suspend; in
legacy mode there are no shared HW resources (PHY lanes) with other HW
blocks (USB), so no need to release / reacquire these resources as with
USB DP alternate mode. The only reason to disconnect legacy ports during
system suspend is that the PORT_TX_DFLEXDPPMS /
DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
connected again during system resume. We'll also have to turn the check
for this flag into a poll, after figuring out what's the proper timeout
value for it.
v2:
- Remove the redundant special casing of legacy mode when doing a
disconnect in icl_tc_port_connected(). It's guaranteed already that we
won't disconnect legacy ports in that function.
- Add a note about the new intel_ddi_encoder_destroy() hook.
- Reword the commit message after switching to the VBT based detection.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
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/20181214182703.18865-4-imre.deak@intel.com
Imre Deak [Fri, 14 Dec 2018 18:27:01 +0000 (20:27 +0200)]
drm/i915/bios: Parse the VBT TypeC and Thunderbolt port flags
This is needed by the next patch to determine if a DDI TypeC port is
physically wired to a legacy DP or legacy HDMI connector or if the port
is wired to a USB-C/Thunderbolt connector.
Cc: Jani Nikula <jani.nikula@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>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-3-imre.deak@intel.com
Imre Deak [Fri, 14 Dec 2018 18:27:00 +0000 (20:27 +0200)]
drm/i915/icl: Add a debug print for TypeC port disconnection
It's useful to see at which point a TypeC port gets disconnected, so add
a debug print for it.
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/20181214182703.18865-2-imre.deak@intel.com
Chris Wilson [Tue, 18 Dec 2018 10:27:12 +0000 (10:27 +0000)]
drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Having completed a test run of gem_eio across all machines in CI we also
observe the phenomenon (of lost interrupts after resetting the GPU) on
gen3 machines as well as the previously sighted gen6/gen7. Let's apply
the same HWSTAM workaround that was effective for gen6+ for all, as
although we haven't seen the same failure on gen4/5 it seems prudent to
keep the code the same.
As a consequence we can remove the extra setting of HWSTAM and apply the
register from a single site.
v2: Delazy and move the HWSTAM into its own function
v3: Mask off all HWSP writes on driver unload and engine cleanup.
v4: And what about the physical hwsp?
v5: No, engine->init_hw() is not called from driver_init_hw(), don't be
daft. Really scrub HWSTAM as early as we can in driver_init_mmio()
v6: Rename set_hwsp as it was setting the mask not the hwsp register.
v7: Ville pointed out that although vcs(bsd) was introduced for g4x/ilk,
per-engine HWSTAM was not introduced until gen6!
References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181218102712.11058-1-chris@chris-wilson.co.uk
Clint Taylor [Mon, 17 Dec 2018 22:13:47 +0000 (14:13 -0800)]
drm/i915/icl: combo port vswing programming changes per BSPEC
In August 2018 the BSPEC changed the ICL port programming sequence to
closely resemble earlier gen programming sequence. Restrict combo phy to
HBR max rate unless eDP panel is connected to port.
v2: remove debug code that Imre found
v3: simplify translation table if-else
v4: edp translation table now based on link rate and low_swing
v5: Misc review comments + r-b
BSpec: 21257
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1545084827-5776-1-git-send-email-clinton.a.taylor@intel.com
Hans de Goede [Mon, 17 Dec 2018 14:19:03 +0000 (15:19 +0100)]
drm/i915: Update crtc scaler settings when update_pipe is set
When the pipe_config's update_pipe flag is set we may need to update the
panel fitting settings. On GEN9+ this means we need to update the crtc's
scaler settings.
This fixes the following WARN_ON, during i915 loading on an Asrock
B150M Pro4S/D3 board with an i5-6500 CPU / graphics:
[drm:pipe_config_err [i915]] *ERROR* mismatch in pch_pfit.enabled
(expected no, found yes)
pipe state doesn't match!
WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_display.c:12084
With line 12084 being the I915_STATE_WARN call inside the
"if (!intel_pipe_config_compare())" block in verify_crtc_state().
On this board with 2 1920x1080 monitors connected over HDMI the GOP
initializes both monitors at 1920x1080 and despite no scaling being
necessary configures a scaler for one of them.
When booting with fastboot=1 on the initial modeset needs_modeset will
be false while update_pipe is true. Since we were not calling
skl_update_scaler_crtc() in this case we would leave the scaler enabled
causing this error.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181217141903.4182-1-hdegoede@redhat.com
Anusha Srivatsa [Fri, 7 Dec 2018 18:28:39 +0000 (10:28 -0800)]
drm/i915/huc: Update the HuC version for BXT
We have an update for HuC for BXT.
Load the latest version.
v2: Change the subject.
Cc: Rodrigo Vivi <rodrigo.vivi@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>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207182840.9292-2-anusha.srivatsa@intel.com
Manasi Navare [Thu, 6 Dec 2018 00:54:07 +0000 (16:54 -0800)]
drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
DSC can be supported per DP connector. This patch adds a per connector
debugfs node to expose DSC support capability by the kernel.
The same node can be used from userspace to force DSC enable.
force_dsc_en written through this debugfs node is used to force
DSC even for lower resolutions.
Credits to Ville Syrjala for suggesting the proper locks to be used
and to Lyude Paul for explaining how to use them in this context
v8:
* Add else if (ret) for drm_modeset_lock (Lyude)
v7:
* Get crtc, crtc_state from connector atomic state
and add proper locks and backoff (Ville, Chris Wilson, Lyude)
(Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>)
* Use %zu for printing size_t variable (Lyude)
v6:
* Read fec_capable only for non edp (Manasi)
v5:
* Name it dsc sink support and also add
fec support in the same node (Ville)
v4:
* Add missed connector_status check (Manasi)
* Create i915_dsc_support node only for Gen >=10 (manasi)
* Access intel_dp->dsc_dpcd only if its not NULL (Manasi)
v3:
* Combine Force_dsc_en with this patch (Ville)
v2:
* Use kstrtobool_from_user to avoid explicit error checking (Lyude)
* Rebase on drm-tip (Manasi)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181206005407.4698-1-manasi.d.navare@intel.com
Chris Wilson [Thu, 13 Dec 2018 16:12:41 +0000 (16:12 +0000)]
drm/i915: Fix Cherryview oops on boot
Do not dereference the LUT blob before checking whether that blob
exists. Or else,
<1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at
0000000000000048
<6>[ 13.978718] PGD 0 P4D 0
<4>[ 13.978733] Oops: 0000 [#1] PREEMPT SMP PTI
<4>[ 13.978750] CPU: 0 PID: 282 Comm: modprobe Not tainted 4.20.0-rc5-CI-CI_DRM_5294+ #1
<4>[ 13.978773] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016
<4>[ 13.978932] RIP: 0010:cherryview_load_csc_matrix+0x1e6/0x210 [i915]
<4>[ 13.978953] Code: 41 5c 41 5d e9 7b 83 aa e1 41 c1 e4 0d 48 83 bd 00 02 00 00 00 48 8b 85 10 02 00 00 45 89 e5 74 09 ba 01 00 00 00 31 c9 eb 9d <48> 8b 50 48 48 c1 ea 03 81 fa 00 01 00 00 75 07 31 d2 48 85 c0 75
<4>[ 13.979001] RSP: 0018:
ffffc9000026f840 EFLAGS:
00010246
<4>[ 13.979018] RAX:
0000000000000000 RBX:
ffff888165500000 RCX:
7885fe6200000000
<4>[ 13.979039] RDX:
0000000000000020 RSI:
ffff88816553a008 RDI:
ffff888165464a88
<4>[ 13.979060] RBP:
ffff888165464a88 R08:
000000000ed0e429 R09:
0000000000000001
<4>[ 13.979080] R10:
0000000000000000 R11:
0000000000000000 R12:
0000000000004000
<4>[ 13.979101] R13:
0000000000004000 R14:
ffff888165500000 R15:
ffff888165464a88
<4>[ 13.979122] FS:
00007fb69c4f3540(0000) GS:
ffff88817ba00000(0000) knlGS:
0000000000000000
<4>[ 13.979146] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4>[ 13.979163] CR2:
0000000000000048 CR3:
000000016d7fa000 CR4:
00000000001006f0
<4>[ 13.979184] Call Trace:
<4>[ 13.979302] intel_update_crtc+0x18f/0x2b0 [i915]
<4>[ 13.979421] intel_update_crtcs+0x49/0x60 [i915]
<4>[ 13.979538] intel_atomic_commit_tail+0x1ea/0xd70 [i915]
<4>[ 13.979657] ? intel_atomic_commit_ready+0x3f/0x50 [i915]
<4>[ 13.979762] ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
<4>[ 13.979884] intel_atomic_commit+0x244/0x330 [i915]
<4>[ 13.980002] intel_initial_commit+0xb6/0x140 [i915]
<4>[ 13.980127] intel_modeset_init+0x7a1/0x1880 [i915]
<4>[ 13.980235] i915_driver_load+0xcbb/0x15c0 [i915]
<4>[ 13.980257] ? __pm_runtime_resume+0x4f/0x80
<4>[ 13.980277] ? _raw_spin_unlock_irqrestore+0x4c/0x60
<4>[ 13.980296] ? lockdep_hardirqs_on+0xe0/0x1b0
<4>[ 13.980401] i915_pci_probe+0x29/0xa0 [i915]
<4>[ 13.980421] pci_device_probe+0xa1/0x130
<4>[ 13.980440] really_probe+0xf3/0x3e0
<4>[ 13.980456] driver_probe_device+0x10a/0x120
<4>[ 13.980474] __driver_attach+0xdb/0x100
<4>[ 13.980489] ? driver_probe_device+0x120/0x120
<4>[ 13.980505] ? driver_probe_device+0x120/0x120
<4>[ 13.980522] bus_for_each_dev+0x74/0xc0
<4>[ 13.980539] bus_add_driver+0x15f/0x250
<4>[ 13.980554] ? 0xffffffffa0348000
<4>[ 13.980568] driver_register+0x56/0xe0
<4>[ 13.980583] ? 0xffffffffa0348000
<4>[ 13.980597] do_one_initcall+0x58/0x2e0
<4>[ 13.980615] ? do_init_module+0x1d/0x1ea
<4>[ 13.980631] ? rcu_read_lock_sched_held+0x6f/0x80
<4>[ 13.980649] ? kmem_cache_alloc_trace+0x264/0x290
<4>[ 13.980668] do_init_module+0x56/0x1ea
<4>[ 13.980685] load_module+0x227a/0x29c0
<4>[ 13.980715] ? __se_sys_finit_module+0xd3/0xf0
<4>[ 13.980731] __se_sys_finit_module+0xd3/0xf0
<4>[ 13.980756] do_syscall_64+0x55/0x190
<4>[ 13.980772] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 13.980789] RIP: 0033:0x7fb69c019839
<4>[ 13.980804] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
<4>[ 13.980851] RSP: 002b:
00007ffdc112e3a8 EFLAGS:
00000246 ORIG_RAX:
0000000000000139
<4>[ 13.980875] RAX:
ffffffffffffffda RBX:
000055c689fe0b30 RCX:
00007fb69c019839
<4>[ 13.980895] RDX:
0000000000000000 RSI:
000055c689a05d2e RDI:
0000000000000000
<4>[ 13.980916] RBP:
000055c689a05d2e R08:
0000000000000000 R09:
0000000000000000
<4>[ 13.980936] R10:
0000000000000000 R11:
0000000000000246 R12:
0000000000000000
<4>[ 13.980957] R13:
000055c689fe0c60 R14:
0000000000040000 R15:
000055c689fe0b30
<4>[ 13.980986] Modules linked in: i915(+) snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers
<4>[ 13.981027] CR2:
0000000000000048
Fixes: 302da0cdf784 ("drm/i915: Use intel_ types more consistently for color management code (v2)")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213161241.3461-1-chris@chris-wilson.co.uk
Oscar Mateo [Thu, 13 Dec 2018 09:15:22 +0000 (09:15 +0000)]
drm/i915/icl: Mind the SFC units when resetting VD or VEBox engines
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
They also happen to have separate reset bits. So, whenever we want to reset
one or more of the media engines, we have to make sure the SFCs do not
change owner in the process and, if this owner happens to be one of the
engines being reset, we need to reset the SFC as well.
This happens in 4 steps:
1) Tell the engine that a software reset is going to happen. The engine
will then try to force lock the SFC (if currently locked, it will
remain so; if currently unlocked, it will ignore this and all new lock
requests).
2) Poll the ack bit to make sure the hardware has received the forced
lock from the driver. Once this bit is set, it indicates SFC status
(lock or unlock) will not change anymore (until we tell the engine it
is safe to unlock again).
3) Check the usage bit to see if the SFC has ended up being locked to
the engine we want to reset. If this is the case, we have to reset
the SFC as well.
4) Unlock all the SFCs once the reset sequence is completed.
Obviously, if we are resetting the whole GPU, we don't have to worry
about all of this.
BSpec: 10989
BSpec: 10990
BSpec: 10954
BSpec: 10955
BSpec: 10956
BSpec: 19212
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-4-chris@chris-wilson.co.uk
Oscar Mateo [Thu, 13 Dec 2018 09:15:21 +0000 (09:15 +0000)]
drm/i915/icl: Record the valid VDBoxes with SFC capability
In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC
(Scaler & Format Converter) unit. We will use this information to decide
when the SFC units need to be reset.
BSpec: 20189
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-3-chris@chris-wilson.co.uk
Chris Wilson [Thu, 13 Dec 2018 09:15:20 +0000 (09:15 +0000)]
drm/i915/selftests: Verify we can perform resets from atomic context
We currently require that our per-engine reset can be called from any
context, even hardirq, and in the future wish to perform the device
reset without holding struct_mutex (which requires some lockless
shenanigans that demand the lowlevel intel_reset_gpu() be able to be
used in atomic context). Test that we meet the current requirements by
calling i915_reset_engine() from under various atomic contexts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 13 Dec 2018 09:15:19 +0000 (09:15 +0000)]
drm/i915/selftests: Check we can recover a wedged device
After declaring a terminally wedged device, we allow ourselves to
recover on the next GPU reset (manually triggered), or resume. Check
that resetting a wedged device does work.
v2: Add rpm (taken explicitly in the subtest in case we remove the outer
wakeref) and early warning to i915_reset() for missed wakerefs
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-1-chris@chris-wilson.co.uk
Lucas De Marchi [Wed, 12 Dec 2018 18:10:44 +0000 (10:10 -0800)]
drm/i915: merge gen checks to use range
Instead of using IS_GEN() for consecutive gen checks, let's pass the
range to IS_GEN_RANGE(). By code inspection these were the ranges deemed
necessary for spatch:
@@
expression e;
@@
(
- IS_GEN(e, 3) || IS_GEN(e, 2)
+ IS_GEN_RANGE(e, 2, 3)
|
- IS_GEN(e, 3) || IS_GEN(e, 4)
+ IS_GEN_RANGE(e, 3, 4)
|
- IS_GEN(e, 5) || IS_GEN(e, 6)
+ IS_GEN_RANGE(e, 5, 6)
|
- IS_GEN(e, 6) || IS_GEN(e, 7)
+ IS_GEN_RANGE(e, 6, 7)
|
- IS_GEN(e, 7) || IS_GEN(e, 8)
+ IS_GEN_RANGE(e, 7, 8)
|
- IS_GEN(e, 8) || IS_GEN(e, 9)
+ IS_GEN_RANGE(e, 8, 9)
|
- IS_GEN(e, 10) || IS_GEN(e, 9)
+ IS_GEN_RANGE(e, 9, 10)
|
- IS_GEN(e, 9) || IS_GEN(e, 10)
+ IS_GEN_RANGE(e, 9, 10)
)
After conversion, checking we don't have any missing IS_GEN_RANGE() ||
IS_GEN() was also done.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-3-lucas.demarchi@intel.com
Lucas De Marchi [Wed, 12 Dec 2018 18:10:43 +0000 (10:10 -0800)]
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
Lucas De Marchi [Wed, 12 Dec 2018 18:10:42 +0000 (10:10 -0800)]
drm/i915: Rename IS_GEN to IS_GEN_RANGE
RANGE makes it longer, but clearer. We are also going to add a macro to
check an individual gen, so add the _RANGE prefix here.
Diff generated with:
sed 's/IS_GEN(/IS_GEN_RANGE(/g' drivers/gpu/drm/i915/{*/,}*.{c,h} -i
v2: use IS_GEN rather than GT_GEN
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-1-lucas.demarchi@intel.com
Matt Roper [Wed, 12 Dec 2018 19:17:20 +0000 (11:17 -0800)]
drm/i915: Don't forget to reset blocks when testing lower wm levels
During DDB allocation, we try to distribute enough blocks for each plane
to hit the highest watermark level; if that fails, we retry each lower
level (which should require fewer blocks) until we find one that's
possible (or until the whole commit is rejected as impossible). We need
to reset our running block count when trying each lower level, otherwise
all lower levels will fail as well.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: d8e8749802 ("drm/i915: Switch to level-based DDB allocation algorithm (v5)")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212191720.3706-1-matthew.d.roper@intel.com
Bob Paauwe [Tue, 11 Dec 2018 19:25:45 +0000 (11:25 -0800)]
drm/i915: DFSM pipe disable is valid from gen9 onwards (v2)
It's not just GEN9 platforms that allow for pipes to be disabled via
the DFSM register, but all later platforms as well.
v2: drop pointless parentheses (Ville)
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181211192545.140081-1-bob.j.paauwe@intel.com
Matt Roper [Tue, 11 Dec 2018 17:31:07 +0000 (09:31 -0800)]
drm/i915: Switch to level-based DDB allocation algorithm (v5)
The DDB allocation algorithm currently used by the driver grants each
plane a very small minimum allocation of DDB blocks and then divies up
all of the remaining blocks based on the percentage of the total data
rate that the plane makes up. It turns out that this proportional
allocation approach is overly-generous with the larger planes and can
leave very small planes wthout a big enough allocation to even hit their
level 0 watermark requirements (especially on APL, which has a smaller
DDB in general than other gen9 platforms). Or there can be situations
where the smallest planes hit a lower watermark level than they should
have been able to hit with a more equitable division of DDB blocks, thus
limiting the overall system sleep state that can be achieved.
The bspec now describes an alternate algorithm that can be used to
overcome these types of issues. With the new algorithm, we calculate
all plane watermark values for all wm levels first, then go back and
partition a pipe's DDB space second. The DDB allocation will calculate
what the highest watermark level that can be achieved on *all* active
planes, and then grant the blocks necessary to hit that level to each
plane. Any remaining blocks are then divided up proportionally
according to data rate, similar to the old algorithm.
There was a previous attempt to implement this algorithm a couple years
ago in
bb9d85f6e9d ("drm/i915/skl: New ddb allocation algorithm"), but
some regressions were reported, the patch was reverted, and nobody
ever got around to figuring out exactly where the bug was in that
version. Our watermark code has evolved significantly in the meantime,
but we're still getting bug reports caused by the unfair proportional
algorithm, so let's give this another shot.
v2:
- Make sure cursor allocation stays constant and fixed at the end of
the pipe allocation.
- Fix some watermark level iterators that weren't handling the max
level.
v3:
- Ensure we don't leave any DDB blocks unused by using DIV_ROUND_UP+min
to calculate the extra blocks for each plane. (Ville)
- Replace a while() loop with a for() loop to be more consistent with
surrounding code. (Ville)
- Clean unattainable watermark levels with memset rather than directly
clearing the member fields. Also do the same for the transition
watermark values if they can't be achieved. (Ville)
- Drop min_disp_buf_needed calculations in skl_compute_plane_wm() since
the results are no longer needed or used. (Ville)
- Drop skl_latency[0] != 0 sanity check; both watermark methods already
account for an invalid 0 latency by returning FP_16_16_MAX. (Ville)
v4:
- Break DDB allocation loop when total_data_rate=0 rather than
alloc_size=0. If total_data_rate has dropped to 0, all remaining
planes are disabled, which isn't true for alloc_size (we might just
have not had any remaining blocks to hand out). Plus
total_data_rate=0 is the case we need to avoid to a prevent a
div-by-0. (Ville)
- s/DIV_ROUND_UP/DIV64_U64_ROUND_UP/ to prevent 32-bit breakage (Ville)
v5:
- Don't forget to move 'start' pointer forward for UV surface when
setting plane DDB boundaries. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181211173107.11068-2-matthew.d.roper@intel.com
Matt Roper [Tue, 11 Dec 2018 17:31:06 +0000 (09:31 -0800)]
drm/i915: Don't use DDB allocation when choosing gen9 watermark method
The bspec gives an if/else chain for choosing whether to use "method 1"
or "method 2" for calculating the watermark "Selected Result Blocks"
value for a plane. One of the branches of the if chain is:
"Else If ('plane buffer allocation' is known and (plane buffer
allocation / plane blocks per line) >=1)"
Since our driver currently calculates DDB allocations first and the
actual watermark values second, the plane buffer allocation is known at
this point in our code and we include this test in our driver's logic.
However we plan to soon move to a "watermarks first, ddb allocation
second" sequence where we won't know the DDB allocation at this point.
Let's drop this arm of the if/else statement (effectively considering
the DDB allocation unknown) as an independent patch so that any
regressions can be more accurately bisected to either the different
watermark value (in this patch) or the new DDB allocation (in the next
patch).
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181211173107.11068-1-matthew.d.roper@intel.com
Clint Taylor [Mon, 10 Dec 2018 22:52:54 +0000 (14:52 -0800)]
drm/i915/hdmi: SCDC Scrambling enable without CTS mode
Setting the SCDC scrambling CTS mode causes HDMI Link Layer protocol tests
HF1-12 and HF1-13 to fail.
V2: Removed "Source Shall" entries to a new patch
V3: Rebase to drm-tip
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107895
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107896
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1544482374-26507-1-git-send-email-clinton.a.taylor@intel.com
Matt Roper [Mon, 10 Dec 2018 21:54:15 +0000 (13:54 -0800)]
drm/i915: Use intel_ types more consistently for color management code (v2)
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions. While we're at it, let's also be more
consistent with state variable naming (half of the platforms use the
name 'state' whereas the other half used 'crtc_state').
While we're touching these variables, let's also be more consistent
about always naming the intel_crtc_state's "crtc_state" rather than
"state" so that different platform types aren't using different naming
conventions.
v2:
- s/state/crtc_state/ for consistency between platform types (Ville)
- Drop the crtc parameter to intel_color_check(); we can just pull that
out of the state object.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181210215415.19854-2-matthew.d.roper@intel.com
Matt Roper [Mon, 10 Dec 2018 21:54:14 +0000 (13:54 -0800)]
drm/i915: Use intel_ types more consistently for watermark code (v2)
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions.
v2:
- Also drop the intel_crtc parameter from compute_intermediate_wm()
since we can just extract it from the crtc_state parameter. (Ville)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181210215415.19854-1-matthew.d.roper@intel.com
Ville Syrjälä [Tue, 13 Nov 2018 17:23:30 +0000 (19:23 +0200)]
drm/i915: Remove dead update_wm_pre assignment from SKL wm code
SKL+ do not use crtc_state->update_wm_pre, so there is absolutely no
point it setting it. crtc_state->update_wm_pre only exists as a
temporary hack for pre-g4x platforms until we redo their
watermarks to be be atomic.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181113172330.26069-3-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Tue, 13 Nov 2018 17:23:29 +0000 (19:23 +0200)]
drm/i915: Remove bogus FIXME from SKL wm computation
We do return an error when the watermark calculation fails, so
the FIXME claiming otherwise is outdated. Remove it.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181113172330.26069-2-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Tue, 13 Nov 2018 17:23:28 +0000 (19:23 +0200)]
drm/i915: Use explicit old crtc state in skl_compute_wm()
skl_compute_wm() wants to compare the old and new watermarks. Currently
it gets at the old watermarks via crtc->state, which is confusing since
it can point at either the old or the new state depending on where
in the sequence we are. In this case it is correct since we have not yet
swapped the states, but let's make it super clear what this is doing
by using the explicit old state.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181113172330.26069-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Fri, 7 Dec 2018 13:40:37 +0000 (13:40 +0000)]
drm/i915: Flush GPU relocs harder for gen3
Adding an extra MI_STORE_DWORD_IMM to the gpu relocation path for gen3
was good, but still not good enough. To survive 24+ hours under test we
needed to perform not one, not two but three extra store-dw. Doing so
for each GPU relocation was a little unsightly and since we need to
worry about userspace hitting the same issues, we should apply the dummy
store-dw into the EMIT_FLUSH.
Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
References:
7fa28e146994 ("drm/i915: Write GPU relocs harder with gen3")
Testcase: igt/gem_tiled_fence_blits # blb/pnv
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207134037.11848-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 7 Dec 2018 11:05:54 +0000 (11:05 +0000)]
drm/i915: Skip the ERR_PTR error state
Although commit
fb6f0b64e455 ("drm/i915: Prevent machine hang from
Broxton's vtd w/a and error capture") applied cleanly after a 24 month
hiatus, the code had moved on with new methods for peeking and fetching
the captured gpu info. Make sure we catch all uses of the stashed error
state and avoid dereferencing the error pointer.
v2: Move error pointer determination into i915_gpu_capture_state
v3: Restore early check to avoid capturing and then throwing away
subsequent GPU error states.
Fixes: fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207110554.19897-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 7 Dec 2018 09:02:13 +0000 (09:02 +0000)]
drm/i915: Pipeline PDP updates for Braswell
Currently we face a severe problem on Braswell that manifests as invalid
ppGTT accesses. The code tries to maintain the PDP (page directory
pointers) inside the context in two ways, direct write into the context
and a pipelined LRI update. The direct write into the context is
fundamentally racy as it is unserialised with any access (read or write)
the GPU is doing. By asserting that Braswell is not used with vGPU
(currently an unsupported platform) we can eliminate the dangerous
direct write into the context image and solely use the pipelined update.
However, the LRI of the PDP fouls up the GPU, causing it to freeze and
take out the machine with "forcewake ack timeouts". This seems possible
to workaround by preventing the GPU from sleeping (via means of
disabling the power-state management interface, i.e. forcing each ring
to remain awake) around the update. Equally, it seems an EMIT_INVALIDATE
before the LRI is sufficient to prevent the forcewake errors.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656
References: https://bugs.freedesktop.org/show_bug.cgi?id=108714
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207090213.14352-3-chris@chris-wilson.co.uk
Chris Wilson [Fri, 7 Dec 2018 09:02:12 +0000 (09:02 +0000)]
drm/i915/ringbuffer: EMIT_INVALIDATE after switch context
The recommend procedure was to switch contexts (and mm) then invalidate
the TLBs. Make it so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207090213.14352-2-chris@chris-wilson.co.uk
Chris Wilson [Fri, 7 Dec 2018 09:02:11 +0000 (09:02 +0000)]
drm/i915: Push EMIT_INVALIDATE at request start to backends
Move the common engine->emit_flush(EMIT_INVALIDATE) back to the backends
(where it was once previously) as we seek to specialise it in future
patches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207090213.14352-1-chris@chris-wilson.co.uk
Mika Kuoppala [Wed, 5 Dec 2018 13:46:12 +0000 (15:46 +0200)]
drm/i915/icl: Forcibly evict stale csb entries
Gen11 fails to deliver wrt global observation point on
tail/entry updates and we sometimes see old entry.
Use clflush to forcibly evict our possibly stale copy
of the cacheline in hopes that we get fresh one from gpu.
Obviously there is something amiss in the coherency protocol so
this can be consired as a workaround until real cause
is found.
The working hardware will do the evict without our cue anyways,
so the cost in there should be ameliorated by that fact.
v2: for next pass, s/flush/evict, add reset (Chris)
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=108315
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181205134612.24822-1-mika.kuoppala@linux.intel.com
Chris Wilson [Thu, 6 Dec 2018 08:44:31 +0000 (08:44 +0000)]
drm/i915/execlists: Apply a full mb before execution for Braswell
Braswell is really picky about having our writes posted to memory before
we execute or else the GPU may see stale values. A wmb() is insufficient
as it only ensures the writes are visible to other cores, we need a full
mb() to ensure the writes are in memory and visible to the GPU.
The most frequent failure in flushing before execution is that we see
stale PTE values and execute the wrong pages.
References:
987abd5c62f9 ("drm/i915/execlists: Force write serialisation into context image vs execution")
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>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181206084431.9805-3-chris@chris-wilson.co.uk
Chris Wilson [Thu, 6 Dec 2018 18:07:13 +0000 (18:07 +0000)]
drm/i915/execlists: Move RCS mmio workaround to new common wa_list
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
v2: INSTPM_FORCE_ORDERING is already part of gen8_ctx_workarounds, and
as confirmed by the mmio verification is a part of the context image!
v3: MI_MODE is already part of gen8_ctx_workarounds...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181206180713.6827-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 6 Dec 2018 18:07:12 +0000 (18:07 +0000)]
drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be still useful to later verify
the registers retain their magic values across rpm suspend/resume.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181206180713.6827-1-chris@chris-wilson.co.uk
Ramalingam C [Wed, 5 Dec 2018 11:44:43 +0000 (17:14 +0530)]
drm/i915: Increase timeout for Encrypt status change
At enable/disable of the HDCP encryption, for encryption status change
we need minimum one frame duration. And we might program this bit any
point(start/End) in the previous frame.
With 20mSec, observed the timeout for change in encryption status.
Since this is not time critical operation and we need to hold on
until the status is changed, fixing the timeout to 50mSec. (Based on
trial and error method!)
v2:
%s/TIME_FOR_ENCRYPT_STATUS_CHANGE/ENCRYPT_STATUS_CHANGE_TIMEOUT_MS
[Sean Paul]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-5-git-send-email-ramalingam.c@intel.com
Ramalingam C [Wed, 5 Dec 2018 11:44:42 +0000 (17:14 +0530)]
drm/i915: debug log for REPLY_ACK missing
Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing
for aksv write. This helps to locate the possible non responding
DP HDCP sinks.
v2:
Rewritten for readability [Sean Paul]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-4-git-send-email-ramalingam.c@intel.com
Ramalingam C [Wed, 5 Dec 2018 11:44:41 +0000 (17:14 +0530)]
drm/i915: Fix platform coverage for HDCP1.4
HDCP1.4 is enabled and validated only on GEN9+ platforms.
v2:
Removed the unnecessary parens [Ville]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-3-git-send-email-ramalingam.c@intel.com
Ramalingam C [Wed, 5 Dec 2018 11:44:40 +0000 (17:14 +0530)]
drm/i915: Fix GEN9 HDCP1.4 key load process
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using
the GT Driver Mailbox interface. So all GEN9_BC platforms will use
the GT Driver Mailbox interface for HDCP1.4 key load.
v2:
Using the IS_GEN9_BC for filtering the platforms [Ville]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-2-git-send-email-ramalingam.c@intel.com
José Roberto de Souza [Wed, 5 Dec 2018 00:48:23 +0000 (16:48 -0800)]
drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking area
GLK and CNL+ supports a bigger FBC tracking area.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181205004823.30823-1-jose.souza@intel.com
José Roberto de Souza [Wed, 5 Dec 2018 18:48:50 +0000 (10:48 -0800)]
drm: Fix documentation generation for DP_DPCD_QUIRK_NO_PSR
The DP_DPCD_QUIRK_NO_PSR comment is missing colon causing this
warning when generating kernel documentation.
./include/drm/drm_dp_helper.h:1374: warning: Incorrect use of kernel-doc format: * @DP_DPCD_QUIRK_NO_PSR
Fixes: 7c5c641a930e (drm/i915: Disable PSR in Apple panels)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181205184850.13218-1-jose.souza@intel.com
Matt Atwood [Thu, 29 Nov 2018 22:00:58 +0000 (14:00 -0800)]
drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
According to DP spec (2.9.3.1 of DP 1.4) if
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
02200h through 0220Fh shall contain the DPRX's true capability. These
values will match 00000h through 0000Fh, except for DPCD_REV,
MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
Read from DPCD once for all 3 values as this is an expensive operation.
Spec mentions that all of address space 02200h through 0220Fh should
contain the right information however currently only 3 values can
differ.
There is no address space in the intel_dp->dpcd struct for addresses
02200h through 0220Fh, and since so much of the data is a identical,
simply overwrite the values stored in 00000h through 0000Fh with the
values that can be overwritten from addresses 02200h through 0220Fh.
This patch helps with backward compatibility for devices pre DP1.3.
v2: read only dpcd values which can be affected, remove incorrect check,
split into drm include changes into separate patch, commit message,
verbose debugging statements during overwrite.
v3: white space fixes
v4: make path dependent on DPCD revision > 1.2
v5: split into function, removed DPCD rev check
v6: add debugging prints for early exit conditions
v7 (From Manasi):
* Memcpy, memcmp and debig logging based on sizeof(dpcd_ext) (Jani N)
* Exit early (Jani N)
v8 (From Manasi):
* Get rid of superfluous debug prints (Jani N)
* Print entire base DPCD before memcpy (Jani N)
v9 (From Manasi):
* Add uniform newlines (Rodrigo)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Tested-by: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181129220058.19636-1-manasi.d.navare@intel.com
Pedro Tammela [Wed, 5 Dec 2018 11:06:08 +0000 (09:06 -0200)]
Makefile: fix mixed tab and spaces
Fixes a comestic issue where spaces were being used
instead of mixed tab and spaces.
Signed-off-by: Pedro Tammela <pctammela@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181205110608.5513-1-pctammela@gmail.com
José Roberto de Souza [Tue, 4 Dec 2018 00:34:03 +0000 (16:34 -0800)]
drm/i915/psr: Check if source supports sink specific SU granularity
According to eDP spec, sink can required specific selective update
granularity that source must comply.
Here caching the value if required and checking if source supports
it.
v3:
- Returning the default granularity in case DPCD read fails(Dhinakaran)
- Changed DPCD error message level(Dhinakaran)
v4:
- Setting granularity to defaul when granularity read is equal to
0(Dhinakaran)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-9-jose.souza@intel.com
José Roberto de Souza [Tue, 4 Dec 2018 00:34:02 +0000 (16:34 -0800)]
drm/i915/psr: Check if resolution is supported by default SU granularity
Selective updates have a default granularity requirements as stated
by eDP spec(PSR2 SELECTIVE UPDATE X GRANULARITY CAPABILITY register
definition), so check if HW can match those requirements before
enabling PSR2.
v3:
- Changes in the comments and commit message(Dhinakaran)
- Printing the hdisplay that do not match with default granularity
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@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/20181204003403.23361-8-jose.souza@intel.com
José Roberto de Souza [Tue, 4 Dec 2018 00:34:01 +0000 (16:34 -0800)]
drm: Add the PSR SU granularity registers offsets
Source is required to comply to sink SU granularity when
DP_PSR2_SU_GRANULARITY_REQUIRED is set in DP_PSR_CAPS,
so adding the registers offsets.
v2: Also adding DP_PSR2_SU_Y_GRANULARITY(Rodrigo)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@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/20181204003403.23361-7-jose.souza@intel.com
José Roberto de Souza [Tue, 4 Dec 2018 00:34:00 +0000 (16:34 -0800)]
drm/i915: Remove old PSR2 FIXME about frontbuffer tracking
Our frontbuffer tracking improved over the years + the WA #0884
helped us keep PSR2 enabled while triggering screen updates when
necessary so this FIXME is not valid anymore.
Acked-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-6-jose.souza@intel.com
José Roberto de Souza [Tue, 4 Dec 2018 00:33:59 +0000 (16:33 -0800)]
drm/i915/icl: Do not change reserved registers related to PSR2
For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not
touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already
unset in gen10 + GLK we can just drop it and fix for both gens.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-5-jose.souza@intel.com
José Roberto de Souza [Tue, 4 Dec 2018 00:33:58 +0000 (16:33 -0800)]
drm/i915/psr: Enable sink to trigger a interruption on PSR2 CRC mismatch
eDP spec states 2 different bits to enable sink to trigger a
interruption when there is a CRC mismatch.
DP_PSR_CRC_VERIFICATION is for PSR only and
DP_PSR_IRQ_HPD_WITH_CRC_ERRORS is for PSR2 only.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-4-jose.souza@intel.com
José Roberto de Souza [Tue, 4 Dec 2018 00:33:57 +0000 (16:33 -0800)]
drm/i915/psr: Set PSR CRC verification bit in sink inside PSR1 block
As we have a else block for the 'if (dev_priv->psr.psr2_enabled) {'
and this bit is only set for PSR1 move it to that block to make it
more easy to read.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@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/20181204003403.23361-3-jose.souza@intel.com
José Roberto de Souza [Tue, 4 Dec 2018 00:33:56 +0000 (16:33 -0800)]
drm/i915/psr: Don't tell sink that main link will be active while is active PSR2
For PSR2 there is no register to tell HW to keep main link enabled
while PSR2 is active, so don't configure sink DPCD with a
misleading value.
v2: Moving the set of DP_PSR_CRC_VERIFICATION to the else block
of 'if (dev_priv->psr.psr2_enabled)' to another patch. (Rodrigo)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@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/20181204003403.23361-2-jose.souza@intel.com
José Roberto de Souza [Tue, 4 Dec 2018 00:33:55 +0000 (16:33 -0800)]
drm/i915: Disable PSR in Apple panels
i915 yet don't support PSR in Apple panels, so lets keep it disabled
while we work on that.
v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
DP_DPCD_QUIRK_NO_PSR (Ville)
v3:
Adding documentation to DP_DPCD_QUIRK_NO_PSR(Dhinakaran and Jani)
Fixed typo in comment of the new quirk entry(Jani)
Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
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/20181204003403.23361-1-jose.souza@intel.com
Tvrtko Ursulin [Tue, 4 Dec 2018 17:15:30 +0000 (17:15 +0000)]
drm/i915: Dial down workaround debug messages
For selftests like live_hangcheck, which does thousands of reset per
second, it is too verbose to log every time we re-apply the workarounds.
Remove those messages since, coupled with the dedicated selftest, it is
sufficient to only log the number of recorded workarounds at init time.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204171530.28583-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Tue, 4 Dec 2018 14:15:18 +0000 (14:15 +0000)]
drm/i915/selftests: Reorder request allocation vs vma pinning
Impose a restraint that we have all vma pinned for a request prior to
its allocation. This is to simplify request construction, and should
facilitate unravelling the lock interdependencies later.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204141522.13640-3-chris@chris-wilson.co.uk
Jani Nikula [Tue, 4 Dec 2018 17:26:17 +0000 (19:26 +0200)]
drm/i915: Update DRIVER_DATE to
20181204
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Tue, 4 Dec 2018 10:19:26 +0000 (12:19 +0200)]
drm/i915/icl: fix transcoder state readout
Commit
2ca711caeca2 ("drm/i915/icl: Consider DSI for getting transcoder
state") clobbers the previously read TRANS_DDI_FUNC_CTL_EDP register
contents with TRANS_DDI_FUNC_CTL_DSI0 contents. Fix the state readout,
and handle DSI 1 while at it.
Use a bitmask for iterating and logging transcoders, because the allowed
combinations are a bit funky.
Fixes: 2ca711caeca2 ("drm/i915/icl: Consider DSI for getting transcoder state")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108928
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204101926.17174-1-jani.nikula@intel.com
Chris Wilson [Tue, 4 Dec 2018 14:15:16 +0000 (14:15 +0000)]
drm/i915: Allocate a common scratch page
Currently we allocate a scratch page for each engine, but since we only
ever write into it for post-sync operations, it is not exposed to
userspace nor do we care for coherency. As we then do not care about its
contents, we can use one page for all, reducing our allocations and
avoid complications by not assuming per-engine isolation.
For later use, it simplifies engine initialisation (by removing the
allocation that required struct_mutex!) and means that we can always rely
on there being a scratch page.
v2: Check that we allocated a large enough scratch for I830 w/a
Fixes: 06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5") # v4.18.20
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108850
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204141522.13640-1-chris@chris-wilson.co.uk
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.18.20+
Tvrtko Ursulin [Mon, 3 Dec 2018 12:50:14 +0000 (12:50 +0000)]
drm/i915: Trim unused workaround list entries
The new workaround list allocator grows the list in chunks so will end up
with some unused space. Trim it when the initialization phase is done to
free up a tiny bit of slab.
v2:
* Simplify with kmemdup. (Chris Wilson)
v3:
* Refactor for __size removal.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-8-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Mon, 3 Dec 2018 13:33:57 +0000 (13:33 +0000)]
drm/i915: Fuse per-context workaround handling with the common framework
Convert the per context workaround handling code to run against the newly
introduced common workaround framework and fuse the two to use the
existing smarter list add helper, the one which does the sorted insert and
merges registers where possible.
This completes migration of all four classes of workarounds onto the
common framework.
Existing macros are kept untouched for smaller code churn.
v2:
* Rename to list name ctx_wa_list and move from dev_priv to engine.
v3:
* API rename and parameters tweaking. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203133357.10341-1-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Mon, 3 Dec 2018 12:50:12 +0000 (12:50 +0000)]
drm/i915: Move register white-listing to the common workaround framework
Instead of having a separate list of white-listed registers we can
trivially move this to the common workarounds framework.
This brings us one step closer to the goal of driving all workaround
classes using the same code.
v2:
* Use GEM_DEBUG_WARN_ON for the sanity check. (Chris Wilson)
v3:
* API rename. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-6-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Mon, 3 Dec 2018 12:50:11 +0000 (12:50 +0000)]
drm/i915/selftests: Add tests for GT and engine workaround verification
Two simple selftests which test that both GT and engine workarounds are
not lost after either a full GPU reset, or after the per-engine ones.
(Including checks that one engine reset is not affecting workarounds not
belonging to itself.)
v2:
* Rebase for series refactoring.
* Add spinner for actual engine reset!
* Add idle reset test as well. (Chris Wilson)
* Share existing global_reset_lock. (Chris Wilson)
v3:
* intel_engine_verify_workarounds can be static.
* API rename. (Chris Wilson)
* Move global reset lock out of the loop. (Chris Wilson)
v4:
* Add missing rpm puts. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-5-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Mon, 3 Dec 2018 12:50:10 +0000 (12:50 +0000)]
drm/i915: Verify GT workaround state after GPU init
Since we now have all the GT workarounds in a table, by adding a simple
shared helper function we can now verify that their values are still
applied after some interesting events in the lifetime of the driver.
Initially we only do this after GPU initialization.
v2:
Chris Wilson:
* Simplify verification by realizing it's a simple xor and and.
* Remove verification from engine reset path.
* Return bool straight away from the verify API.
v3:
* API rename. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-4-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Mon, 3 Dec 2018 13:33:41 +0000 (13:33 +0000)]
drm/i915: Introduce per-engine workarounds
We stopped re-applying the GT workarounds after engine reset since commit
59b449d5c82a ("drm/i915: Split out functions for different kinds of
workarounds").
Issue with this is that some of the GT workarounds live in the MMIO space
which gets lost during engine resets. So far the registers in 0x2xxx and
0xbxxx address range have been identified to be affected.
This losing of applied workarounds has obvious negative effects and can
even lead to hard system hangs (see the linked Bugzilla).
Rather than just restoring this re-application, because we have also
observed that it is not safe to just re-write all GT workarounds after
engine resets (GPU might be live and weird hardware states can happen),
we introduce a new class of per-engine workarounds and move only the
affected GT workarounds over.
Using the framework introduced in the previous patch, we therefore after
engine reset, re-apply only the workarounds living in the affected MMIO
address ranges.
v2:
* Move Wa_1406609255:icl to engine workarounds as well.
* Rename API. (Chris Wilson)
* Drop redundant IS_KABYLAKE. (Chris Wilson)
* Re-order engine wa/ init so latest platforms are first. (Rodrigo Vivi)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=107945
Fixes: 59b449d5c82a ("drm/i915: Split out functions for different kinds of workarounds")
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203133341.10258-1-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Mon, 3 Dec 2018 13:33:19 +0000 (13:33 +0000)]
drm/i915: Record GT workarounds in a list
To enable later verification of GT workaround state at various stages of
driver lifetime, we record the list of applicable ones per platforms to a
list, from which they are also applied.
The added data structure is a simple array of register, mask and value
items, which is allocated on demand as workarounds are added to the list.
This is a temporary implementation which later in the series gets fused
with the existing per context workaround list handling. It is separated at
this stage since the following patch fixes a bug which needs to be as easy
to backport as possible.
Also, since in the following patch we will be adding a new class of
workarounds (per engine) which can be applied from interrupt context, we
straight away make the provision for safe read-modify-write cycle.
v2:
* Change dev_priv to i915 along the init path. (Chris Wilson)
* API rename. (Chris Wilson)
v3:
* Remove explicit list size tracking in favour of growing the allocation
in power of two chunks. (Chris Wilson)
v4:
Chris Wilson:
* Change wa_list_finish to early return.
* Copy workarounds using the compiler for static checking.
* Do not bother zeroing unused entries.
* Re-order struct i915_wa_list.
v5:
* kmalloc_array.
* Whitespace cleanup.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203133319.10174-1-tvrtko.ursulin@linux.intel.com
Jonathan Gray [Thu, 29 Nov 2018 01:30:51 +0000 (12:30 +1100)]
drm/i915: change i915_sw_fence license to MIT
Change the license of the i915_sw_fence files to MIT matching
most of the other i915 files. This makes it possible to use them
in a new port of i915 to OpenBSD.
Besides some mechanical tree wide changes Chris Wilson is the sole
author of these files with Intel holding the copyright.
Intel's legal team have given permission to change the license according
to Joonas Lahtinen.
v2: expand commit message and note permission from Intel legal
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181129013051.17525-1-jsg@jsg.id.au
Chris Wilson [Mon, 3 Dec 2018 11:36:55 +0000 (11:36 +0000)]
drm/i915: Complete the fences as they are cancelled due to wedging
We inspect the requests under the assumption that they will be marked as
completed when they are removed from the queue. Currently however, in the
process of wedging the requests will be removed from the queue before they
are completed, so rearrange the code to complete the fences before the
locks are dropped.
<1>[ 354.473346] BUG: unable to handle kernel NULL pointer dereference at
0000000000000250
<6>[ 354.473363] PGD 0 P4D 0
<4>[ 354.473370] Oops: 0000 [#1] PREEMPT SMP PTI
<4>[ 354.473380] CPU: 0 PID: 4470 Comm: gem_eio Tainted: G U 4.20.0-rc4-CI-CI_DRM_5216+ #1
<4>[ 354.473393] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018
<4>[ 354.473480] RIP: 0010:__i915_schedule+0x311/0x5e0 [i915]
<4>[ 354.473490] Code: 49 89 44 24 20 4d 89 4c 24 28 4d 89 29 44 39 b3 a0 04 00 00 7d 3a 41 8b 44 24 78 85 c0 74 13 48 8b 93 78 04 00 00 48 83 e2 fc <39> 82 50 02 00 00 79 1e 44 89 b3 a0 04 00 00 48 8d bb d0 03 00 00
<4>[ 354.473515] RSP: 0018:
ffffc900001bba90 EFLAGS:
00010046
<4>[ 354.473524] RAX:
0000000000000003 RBX:
ffff8882624c8008 RCX:
f34a737800000000
<4>[ 354.473535] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffff8882624c8048
<4>[ 354.473545] RBP:
ffffc900001bbab0 R08:
000000005963f1f1 R09:
0000000000000000
<4>[ 354.473556] R10:
ffffc900001bba10 R11:
ffff8882624c8060 R12:
ffff88824fdd7b98
<4>[ 354.473567] R13:
ffff88824fdd7bb8 R14:
0000000000000001 R15:
ffff88824fdd7750
<4>[ 354.473578] FS:
00007f44b4b5b980(0000) GS:
ffff888277e00000(0000) knlGS:
0000000000000000
<4>[ 354.473590] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4>[ 354.473599] CR2:
0000000000000250 CR3:
000000026976e000 CR4:
0000000000340ef0
<4>[ 354.473611] Call Trace:
<4>[ 354.473622] ? lock_acquire+0xa6/0x1c0
<4>[ 354.473677] ? i915_schedule_bump_priority+0x57/0xd0 [i915]
<4>[ 354.473736] i915_schedule_bump_priority+0x72/0xd0 [i915]
<4>[ 354.473792] i915_request_wait+0x4db/0x840 [i915]
<4>[ 354.473804] ? get_pwq.isra.4+0x2c/0x50
<4>[ 354.473813] ? ___preempt_schedule+0x16/0x18
<4>[ 354.473824] ? wake_up_q+0x70/0x70
<4>[ 354.473831] ? wake_up_q+0x70/0x70
<4>[ 354.473882] ? gen6_rps_boost+0x118/0x120 [i915]
<4>[ 354.473936] i915_gem_object_wait_fence+0x8a/0x110 [i915]
<4>[ 354.473991] i915_gem_object_wait+0x113/0x500 [i915]
<4>[ 354.474047] i915_gem_wait_ioctl+0x11c/0x2f0 [i915]
<4>[ 354.474101] ? i915_gem_unset_wedged+0x210/0x210 [i915]
<4>[ 354.474113] drm_ioctl_kernel+0x81/0xf0
<4>[ 354.474123] drm_ioctl+0x2de/0x390
<4>[ 354.474175] ? i915_gem_unset_wedged+0x210/0x210 [i915]
<4>[ 354.474187] ? finish_task_switch+0x95/0x260
<4>[ 354.474197] ? lock_acquire+0xa6/0x1c0
<4>[ 354.474207] do_vfs_ioctl+0xa0/0x6e0
<4>[ 354.474217] ? __fget+0xfc/0x1e0
<4>[ 354.474225] ksys_ioctl+0x35/0x60
<4>[ 354.474233] __x64_sys_ioctl+0x11/0x20
<4>[ 354.474241] do_syscall_64+0x55/0x190
<4>[ 354.474251] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 354.474260] RIP: 0033:0x7f44b3de65d7
<4>[ 354.474267] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
<4>[ 354.474293] RSP: 002b:
00007fff974948e8 EFLAGS:
00000246 ORIG_RAX:
0000000000000010
<4>[ 354.474305] RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
00007f44b3de65d7
<4>[ 354.474316] RDX:
00007fff97494940 RSI:
00000000c010646c RDI:
0000000000000007
<4>[ 354.474327] RBP:
00007fff97494940 R08:
0000000000000000 R09:
00007f44b40bbc40
<4>[ 354.474337] R10:
0000000000000000 R11:
0000000000000246 R12:
00000000c010646c
<4>[ 354.474348] R13:
0000000000000007 R14:
0000000000000000 R15:
0000000000000000
v2: Avoid floating requests.
v3: Can't call dma_fence_signal() under the timeline lock!
v4: Can't call dma_fence_signal() from inside another fence either.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203113701.12106-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 20 Nov 2018 20:24:39 +0000 (20:24 +0000)]
drm/i915/dp: Fix inconsistent indenting
Always show the FEC capability as it is initialised to 0 before error.
Fixing,
drivers/gpu/drm/i915/intel_dp.c:3846 intel_dp_get_dsc_sink_cap() warn: inconsistent indenting
Fixes: 08cadae8e157 ("i915/dp/fec: Cache the FEC_CAPABLE DPCD register")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181120202439.13017-2-chris@chris-wilson.co.uk
José Roberto de Souza [Fri, 30 Nov 2018 23:20:48 +0000 (15:20 -0800)]
drm/i915: Move display device info capabilities to its own struct
This helps separate what capabilities are display capabilities.
v3: Moving display struct right after flags (Lucas)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181130232048.14216-2-jose.souza@intel.com
José Roberto de Souza [Fri, 30 Nov 2018 23:20:47 +0000 (15:20 -0800)]
drm/i915: Add HAS_DISPLAY() and use it
Right now it is decided if GEN has display by checking the num_pipes,
so lets make it explicit and use a macro.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181130232048.14216-1-jose.souza@intel.com
Manasi Navare [Sat, 1 Dec 2018 01:04:12 +0000 (17:04 -0800)]
drm/i915/dp: Fix link compute m_n calc for DSC
Fix the intel_link_compute_m_n in case of display stream
compression. This patch passes the compressed_bpp to
intel_link_compute_m_n if compression is enabled.
Fixes: a4a157777c80 ("drm/i915/dp: Compute DSC pipe config in atomic check")
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181201010412.32372-1-manasi.d.navare@intel.com
Jani Nikula [Thu, 4 Oct 2018 14:37:50 +0000 (17:37 +0300)]
drm/i915/sysfs: make attrs arrays const
They don't need to be modified.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181004143750.30880-2-jani.nikula@intel.com
Jani Nikula [Thu, 4 Oct 2018 14:37:49 +0000 (17:37 +0300)]
sysfs: constify sysfs create/remove files harder
Let the passed in array be const (and thus placed in rodata) instead of
a mutable array of const pointers.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181004143750.30880-1-jani.nikula@intel.com
Chris Wilson [Fri, 30 Nov 2018 12:59:54 +0000 (12:59 +0000)]
drm/i915/vgpu: Disallow loading on old vGPU hosts
Since commit
fd8526e50902 ("drm/i915/execlists: Trust the CSB") we
actually broke the force-mmio mode for our execlists implementation. No
one noticed, so ergo no one is actually using an old vGPU host (where we
required the older method) and so can simply remove the broken support.
v2: csb_read can go as well (Mika)
Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Fixes: fd8526e50902 ("drm/i915/execlists: Trust the CSB")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181130125954.11924-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 3 Dec 2018 11:36:54 +0000 (11:36 +0000)]
drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
Change the on-cpu check to on-runqueue to catch if the waiter has been
woken (and reset its current_state back to TASK_UNINTERRUPTIBLE to
perform the seqno check) but is sleeping due to being preempted off the
cpu.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203113701.12106-1-chris@chris-wilson.co.uk
Jani Nikula [Mon, 3 Dec 2018 09:43:26 +0000 (11:43 +0200)]
drm/i915/icl: add pll mapping for DSI
Add encoder specific pll mapping for DSI. The differences with the DDI
version are big enough to warrant a separate function.
v2: add posting read (Madhav)
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203094326.28294-1-jani.nikula@intel.com
Madhav Chauhan [Thu, 29 Nov 2018 14:12:34 +0000 (16:12 +0200)]
drm/i915/icl: Ungate DSI clocks
Ungate the clocks on the selected port.
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2a01b3158feda624f98581b780854fe3df8c328d.1543500286.git.jani.nikula@intel.com
Madhav Chauhan [Thu, 29 Nov 2018 14:12:33 +0000 (16:12 +0200)]
drm/i915/icl: Gate clocks for DSI
As per BSPEC, depending on the DSI transcoder being used,
DDI clock for the associated port should be gated. This
patch does the same.
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e032bc3d8fff91b8c2631c73121268214615a7e8.1543500286.git.jani.nikula@intel.com
Jani Nikula [Thu, 29 Nov 2018 14:12:32 +0000 (16:12 +0200)]
drm/i915/icl: add dummy DSI GPIO element execution function
Add dummy debug logging GPIO element execution function for ICL.
Reviewed-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f59009ea0a0ebc489a5ec66f387d9dcf7264141f.1543500286.git.jani.nikula@intel.com
Madhav Chauhan [Thu, 29 Nov 2018 14:12:31 +0000 (16:12 +0200)]
drm/i915/icl: Define display GPIO pins for DSI
Display Pins are the only GPIOs that need to be used by
driver for DSI panels. So driver should now have its own
implementation to toggle these pins based on GPIO info
received from VBT sequences.
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e7e3bb05d4f48b1876169a69f495bcf6d511fda5.1543500286.git.jani.nikula@intel.com
Madhav Chauhan [Thu, 29 Nov 2018 14:12:30 +0000 (16:12 +0200)]
drm/i915/icl: Define Panel power ctrl register
There are two panel power sequencers. Each register
has two addressable instances. This patch defines
both the instances of Panel power control register
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/99bb687b17a9165527a6210a79271c8175c8a4e3.1543500286.git.jani.nikula@intel.com
Madhav Chauhan [Thu, 29 Nov 2018 14:12:29 +0000 (16:12 +0200)]
drm/i915/icl: Define missing bitfield for shortplug reg
This patch define missing bitfield for shortplug ctl ddi
register which will be used for ICL DSI GPIO programming.
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4b9feb75eb6c303556b91c8a23c505a4593a99a1.1543500286.git.jani.nikula@intel.com
Madhav Chauhan [Thu, 29 Nov 2018 14:12:28 +0000 (16:12 +0200)]
drm/i915/icl: Get pipe timings for DSI
Transcoder timings for Gen11 DSI encoder
is available at pipe level unlike in older platform
where port specific registers need to be accessed.
v2 by Jani:
- get timings for (!dsi || icl) instead of (dsi && icl).
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f60e0c1aee08248e758da3219d3239898b43ba41.1543500286.git.jani.nikula@intel.com
Madhav Chauhan [Thu, 29 Nov 2018 14:12:27 +0000 (16:12 +0200)]
drm/i915/icl: Consider DSI for getting transcoder state
For Gen11 DSI, we use similar registers like for eDP
to find if DSI encoder is connected or not to a pipe.
This patch refactors existing hsw_get_transcoder_state()
to handle this.
v2 by Jani:
- Add WARN_ON(dsi && edp) (Ville)
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2e10b977dfc7aa985a8559d6cd59ed0981848e95.1543500286.git.jani.nikula@intel.com
Madhav Chauhan [Thu, 29 Nov 2018 14:12:26 +0000 (16:12 +0200)]
drm/i915/icl: Configure DSI Dual link mode
This patch configures DSI video mode dual link by
programming DSS_CTL registers.
v2: Use new bitfield definitions from Anusha's patch
Correct register to be programmed and use max
depth buffer value (James)
v3 by Jani:
- checkpatch fixes
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d8962f4e1beffc2099b8bef8cb5a5191aa1d9efd.1543500286.git.jani.nikula@intel.com
projects / openwrt / staging / blogic.git / log