summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2018-02-05drm/i915: Optimize HDCP key loadRamalingam C1-2/+4
HDCP key need not be cleared on each hdcp disable. And HDCP key Load is skipped if key is already loaded. v2: No change. Added Reviewed-by tag. v3: No change. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-6-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Retry HDCP bksv readRamalingam C1-5/+13
HDCP specification says that when bksv is identified as invalid (not with 20 1s), bksv should be re-read and verified. This patch adds the above mentioned re-read for bksv. v2: Rephrased the commit msg [Seanpaul] v3: do-while to for-loop [Seanpaul] v4: retry only if bksv is invalid and no error msg on each attempt [Seanpaul] v5: Correcting the return value [Seanpaul]. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517851922-30547-1-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Connector info in HDCP debug msgsRamalingam C1-3/+11
When HDCP authentication is triggered on multiple connector, having connector name and ID in debug message will be more informative. v2: Added logs with connector info at the start of en/disable [Seanpaul] Added the connector info into Check link failure msgs too. v3: No Changes. Added Reviewed-by tag. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-4-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Stop encryption for repeater with no sinkRamalingam C1-2/+8
If a HDCP repeater is detected with zero downstream devices, HDCP spec approves either of below actions: 1. Dont continue on second stage authentication. Disable encryption. 2. Continue with second stage authentication excluding the KSV list and on success, continue encryption. Since disable encryption is agreed, repeater is not expected to have its own display. So there is no consumption of the display content in such setup. Hence, incase of repeater with zero device count, this patch fails the HDCP authentication and stops the HDCP encryption. v2: Rephrased commit msg and added comments in code [Seanpaul] v3: No changes. Added Reviewed-by tag. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-3-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Handle failure from 2nd stage HDCP authRamalingam C1-0/+3
We enable the HDCP encryption as a part of first stage authentication. So when second stage authentication fails, we need to disable the HDCP encryption and signalling. This patch ensures that, when hdcp authentication fails, HDCP encryption and signalling is turned off. v2: Dropped connector ref passing to auth [Seanpaul] Moved the call to disable_hdcp() to enable_hdcp() [Seanpaul] v3: No Changes. Added the Reveiwed-by tag. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-2-git-send-email-ramalingam.c@intel.com
2018-02-05drm/rockchip: lvds: Explicitly include pinctrl headersThierry Reding1-0/+1
The Rockchip LVDS driver fails to build after commit 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") because it relies on the pinctrl/consumer.h and pinctrl/devinfo.h being pulled in by the device.h header implicitly. Include these headers explicitly to avoid the build failure. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-05drm/i915: Skip post-reset request emission if the engine is not idleChris Wilson1-1/+1
Since commit 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") we submit a request following the engine reset. The intent is that we don't submit a request if the engine is busy (as it will restart active by itself) but we only checked to see if there were remaining requests in flight on the hardware and skipped checking to see if there were any ready requests that would be immediately submitted on restart (the same time as our new request would be). Having convinced the engine to appear idle in the previous patch, we can use intel_engine_is_idle() as a better test to only submit a new request if there are no pending requests. As it happens, this is tripping up igt/drv_selftest/live_hangcheck in CI as we overfill the kernel_context ringbuffer trigger an infinite recursion from within the reset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104786 References: 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-4-chris@chris-wilson.co.uk
2018-02-05drm/i915/execlists: Move the reset bits to a more natural homeChris Wilson1-5/+8
In preparation for the next patch, we want the engine to appear idle after a reset (if there are no requests in flight). For execlists, this entails clearing the active status on reset, it will be regenerated on restarting the engine after the reset. In the process, note that a couple of other status flags and checks could be moved into the describing function. 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/20180205152431.12163-3-chris@chris-wilson.co.uk
2018-02-05drm/i915/selftests: Use a sacrificial context for hang testingChris Wilson3-17/+36
Avoid injecting hangs in to the i915->kernel_context in case the GPU reset leaves corruption in the context image in its wake (leading to continual failures and system hangs after the selftests are ostensibly complete). Use a sacrificial kernel_context instead. v2: Closing a context is tricky; export a function (for selftests) from i915_gem_context.c to get it right. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-2-chris@chris-wilson.co.uk
2018-02-05drm/i915/selftests: Flush old resets between enginesChris Wilson1-3/+63
When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In practice, since we wait for each hanging batch to start before injecting the reset, this too-fast-reset condition can only be triggered when moving onto the next engine in the test, so we need only wait for the existing reset to complete before switching engines. v2: Wrap up the wait inside a safety net to bail out in case of angry hw. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-1-chris@chris-wilson.co.uk
2018-02-05drm/i915/breadcrumbs: Drop request reference for the signaler threadChris Wilson2-70/+86
If we remember to cancel the signaler on a request when retiring it (after we know that the request has been signaled), we do not need to carry an additional request in the signaler itself. This prevents an issue whereby the signaler threads may be delayed and hold on to thousands of request references, causing severe memory fragmentation and premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL and frequent use of inter-engine fences). v2: Rename first_signal(), document reads outside of locks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203101914.24880-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2018-02-05drm/i915: Remove unbannable context spam from resetChris Wilson1-12/+11
During testing, we trigger a lot of resets on an unbannable context leading to massive amounts of irrelevant debug spam. Remove the ban_score accounting and message for the unbannable context so that we improve the signal:noise in the log messages for when the unexpected occurs. 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/20180205092201.19476-7-chris@chris-wilson.co.uk
2018-02-05drm/i915/execlists: Remove the startup spamChris Wilson1-1/+0
Execlists is now enabled by default and included in the list of capabilities printed out to dmesg and beyond. We do not need to mention it again, every time we restart the engine, so kill the spam. 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/20180205092201.19476-6-chris@chris-wilson.co.uk
2018-02-05drm/i915: Show the GPU state when declaring wedgedChris Wilson1-0/+7
Dump each engine state when i915_gem_set_wedged() is called to give us some more clues as to why we had to terminate the GPU. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205092201.19476-5-chris@chris-wilson.co.uk
2018-02-05drm/crc: Add support for polling on the data fd.Maarten Lankhorst1-0/+19
This will make it possible for userspace to know whether reading will block, without blocking on the fd. This makes it possible to drain all queued CRC's in blocking mode, without having to reopen the fd. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202142743.68527-1-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [mlankhorst: Use POLLIN|POLLRDNORM, based on Ville's suggestion]
2018-02-05drm/i915: Always update the no_fbc_reason when disablingChris Wilson1-7/+10
Provide the reason why we call intel_fbc_deactivate() so that debugging issues with FBC being delayed is clearer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180125224122.27480-1-chris@chris-wilson.co.uk Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-02-05drm/i915: Add some newlines to intel_engine_dump() headersChris Wilson2-2/+2
The headers should be on a separate line for consistency, so add the missing trailing newline in a few intel_engine_dump() callers. Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> 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/20180205100618.11001-1-chris@chris-wilson.co.uk
2018-02-05drm/i915: Report if an unbannable context is involved in a GPU hangChris Wilson2-6/+16
Since unbannable contexts are special and supposed not to be causing GPU hangs in the first place, make it clear when they are implicated in said hang. In practice, most unbannable contexts are those created by igt for the express purpose of throwing untold thousands of hangs at the GPU and wish to keep doing so to finish the test. Normally they are cleaned up, but it's when they or the other unbannable kernel contexts stay stuck in an erroneous state that we need to worry and so need highlighting. Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205094139.10671-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2018-02-02drm/i915: Remove spurious DRM_ERROR for cancelled interruptsChris Wilson1-26/+9
As we ourselves cancel interrupts during reset by clearing the GTIIR, it is possible for the master IIR to indicate a pending IRQ for which we have already cleared from the GTIIR. In this case, the DRM_ERROR are intended and should not be flagged as an error. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202153448.23908-1-chris@chris-wilson.co.uk
2018-02-02drm/i915/execlists: Flush GTIIR on clearing CS interrupts during resetChris Wilson1-4/+9
Be paranoid and flush the GTIIR after clearing the CS interrupt to be sure it has taken before we re-enable the interrupt handler. We still see early interrupts following reset, the tasklet handling the mmio read before it has been written by the CS. This hopefully reduces the frequency to 0... References: https://bugs.freedesktop.org/show_bug.cgi?id=104262 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202145455.29876-1-chris@chris-wilson.co.uk
2018-02-02drm/i915: reduce indent in pch detectionJani Nikula1-93/+96
Save some horizontal space. Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202130416.18233-1-jani.nikula@intel.com
2018-02-02drm/sun4i: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä2-10/+8
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-2-ville.syrjala@linux.intel.com Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> #irc
2018-02-02drm/rcar-du: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-5/+4
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-1-ville.syrjala@linux.intel.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2018-02-02drm/i915: Enable inject_load_failure only in DEBUG configMichal Wajdeczko3-0/+12
We're using i915_inject_load_failure() to inject dummy faults during driver load, but since this is debug utility we shouldn't expose it in default config as it consumes both code and data. add/remove: 0/1 grow/shrink: 0/2 up/down: 0/-302 (-302) Function old new delta __i915_inject_load_failure 61 - -61 i915_gem_init 1331 1268 -63 i915_driver_load 5923 5745 -178 Total: Before=1177454, After=1177152, chg -0.03% add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-4 (-4) Data old new delta i915_load_fail_count 4 - -4 Total: Before=56762, After=56758, chg -0.01% add/remove: 4/8 grow/shrink: 0/1 up/down: 245/-591 (-346) RO Data old new delta __param_str_inject_load_failure 20 - -20 __UNIQUE_ID_inject_load_failuretype200 34 - -34 __param_inject_load_failure 40 - -40 __func__ 4998 4896 -102 __UNIQUE_ID_inject_load_failure201 150 - -150 Total: Before=119095, After=118749, chg -0.29% Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180201173248.3912-1-michal.wajdeczko@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-02-02drm/i915/dp: limit DP link rate based on VBT on CNL+Jani Nikula4-1/+35
We have the max DP link rate info available in VBT since BDB version 216, included in child device config since commit c4fb60b9aba9 ("drm/i915/bios: add DP max link rate to VBT child device struct"). Parse it and use it. 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a8b1364d1f2394fba3062b6ad11b474744ea4366.1517482774.git.jani.nikula@intel.com
2018-02-02drm/i915/dp: clean up source rate limiting for cnlJani Nikula1-7/+11
Make the limiting rate based instead of messing with the array size. 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cb03b9419191a7d6359bf371aacb2d3725c746de.1517482774.git.jani.nikula@intel.com
2018-02-02drm/i915/dp: abstract rate array length limitingJani Nikula1-16/+22
This will be useful later on. Also move the functions around to not need forward declarations in subsequent patches. No functional changes. 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/40f37f08cad33234cd86337d39e823ac6e55805f.1517482774.git.jani.nikula@intel.com
2018-02-02drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warningArnd Bergmann1-3/+6
gcc thinks that interpreting a multiplication result as a bool is confusing: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] Adding a temporary variable to contain the divisor helps make it clear what is going on and avoids that warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/mmu: Fix trailing semicolonLuis de Bethencourt1-1/+1
The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by: Luis de Bethencourt <luisbg@kernel.org> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Introduce NvPmEnableGating optionLyude Paul1-1/+3
This adds the NvPmEnableGating config option to nouveau, which can be used to enable or disable clockgating for supported chipsets. Enabling can be done by passing config=NvPmEnableGating=1 To nouveau. If your chipset supports it, you'll see a message in your kernel log indicating that clockgating is enabled. Since clockgating has only had limited testing thus far, we leave this option disabled by default for now. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Add support for SLCG for Kepler2Lyude Paul1-0/+93
That's right, there's still more power saving to go! Starting with kepler 2, nvidia hardware has an additional level of clockgating known as second level clockgating. The details of this are not exact, but it seems to work by waiting for a collection of dependent hardware blocks to be gated before taking affect. As with the previous series, this results in another noticeable drop in power consumption and is programmed in the same manner. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Add support for BLCG on Kepler2Lyude Paul5-4/+139
Same as the previous patch, but for Kepler2 now Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Add support for BLCG on Kepler1Lyude Paul14-1/+442
This enables BLCG optimization for kepler1. When using clockgating, nvidia's firmware has a set of registers which are initially programmed by the vbios with various engine delays and other mysterious settings that are safe enough to bring up the GPU. However, the values used by the vbios are more power hungry then they need to be, so the nvidia driver writes it's own more optimized set of BLCG settings before enabling CG_CTRL. This adds support for programming the optimized BLCG values during engine/subdev init, which enables rather significant power savings. This introduces the nvkm_therm_clkgate_init() helper, which we use to program the optimized BLCG settings before enabling clockgating with nvkm_therm_clkgate_enable. As well, this commit shares a lot more code with Fermi since BLCG is mostly the same there as far as we can tell. In the future, it's likely we'll reformat the clkgate_packs for kepler1 so that they share a list of mmio packs with Fermi. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Add support for basic clockgating on Kepler1Lyude Paul9-21/+301
This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after initializing the GPU fully nvkm_therm_clkgate_fini() - prepares clockgating for suspend or driver unload A lot of this code was originally going to be based off of fermi; however it turns out that while Fermi's the first line of GPUs that introduced this kind of power saving, Fermi requires more fine tuned control of the CG_CTRL registers from the driver while reclocking that we don't entirely understand yet. For the simple parts we will be sharing with Fermi for certain however, we at least add those into a new subdev/therm/gf100.h header. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/kms/nv50: fix handling of gamma since atomic conversionBen Skeggs1-53/+109
We've still been directly using the legacy crtc gamma_set() hook even after conversion to atomic modesetting. For userspace clients this was fine, however, fbcon will use the atomic property when it's running on an atomic driver, which means we miss its colormap updates - which is particularly bad for 8bpp framebuffers! This commit converts the driver to use the atomic property + the helper function implementing the legacy hook on top of atomic. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/kms/nv50: use INTERPOLATE_257_UNITY_RANGE LUT on newer chipsetsBen Skeggs1-4/+4
For some reason forgotten by history, we've been using a 1025-entry LUT mode, and sparsely filling it with the 256-entry LUT we're handed. Until we land support for the full atomic colour management properties, this commit switches to using the 257-entry mode to fix colour mapping with depth 30 framebuffers. Reported-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/kms/nv50: use "low res" lut for indexed modeIlia Mirkin1-2/+4
This is what was done prior to the big refactor in kernel 3.8, and what was done by xf86-video-nv. Experimentally, it seems like there's some sort of issue with the high-res lut to be used there. Tested on G92. This ends up mattering because fbcon/fbdev chooses the C8 fb format for low-vram systems, which can occur with some IGP-based configurations with little "stolen" vram. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/kms/nv50: prepare for double-buffered LUTsBen Skeggs2-23/+15
We need to double-buffer LUTs to handle their update atomically. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/bo: add helper functions for handling pinned+mapped buffersBen Skeggs1-0/+28
This is a common, awkward sequence. Let's wrap it up! Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/fbcon: add module parameter to select bits-per-pixelBen Skeggs1-8/+14
Useful for debugging. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/secboot/gp108: implement on top of acr_r370Ben Skeggs7-1/+78
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
2018-02-02drm/nouveau/secboot/r370: implement support for booting LS SEC2 ucodeBen Skeggs1-0/+39
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
2018-02-02drm/nouveau/secboot/r370: move a bunch of r375 stuff to a new implementationBen Skeggs5-86/+163
It's entirely possibly that the other r375 code is relevant to r370 too, but I've not confirmed this, so I'll leave it where it is for now. NVIDIA's copyright headers maintained, as it's still all their code. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
2018-02-02drm/nouveau: nouveau: use correct string lengthArnd Bergmann1-3/+3
gcc-8 reports drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c: In function 'nvkm_perfmon_mthd': include/linux/string.h:265:9: error: '__builtin_strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation] We need one less byte or call strlcpy() to make it a nul-terminated string. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/drm/nouveau/mmu: fix odd_ptr_err.cocci warningsChristoph Böhmwalder1-1/+2
The kbuild test bot complained about a new coccinelle warning nearby, which sparked a discussion about the assignment to 'memory' inside of the conditional expression. See Link below for the original post. Fix the assignment to silence the coccinelle warning and also make the code look a little nicer. Link: https://lists.freedesktop.org/archives/nouveau/2017-November/029242.html Signed-off-by: Christoph Böhmwalder <christoph@boehmwalder.at> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com>
2018-02-02drm/nouveau/pmu/fuc: don't use movw directly anymoreKarol Herbst4-1292/+1292
Fixes failure to compile with recent envyas as a result of the 'movw' alias being removed for v5. A bit of history: v3 only has a 16-bit sign-extended immediate mov op. In order to set the high bits, there's a separate 'sethi' op. envyas validates that the value passed to mov(imm) is between -0x8000 and 0x7fff. In order to simplify macros that load both the low and high word, a 'movw' alias was added which takes an unsigned 16-bit immediate. However the actual hardware op still sign extends. v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op is gone (loads 0 into the dst reg). However due to a bug in envyas, the movw alias still existed, and selected the no-longer-present v3 16-bit immediate mov op. As a result usage of movw on v5 is the same as mov with a 0x0 argument. The proper fix throughout is to only ever use the 'movw' alias in combination with 'sethi'. Anything else should get the sign-extended validation to ensure that the intended value ends up in the destination register. Changes in fuc3 binaries is the result of a different encoding being selected for a mov with an 8-bit value. v2: added commit message written by Ilia, thanks for that! v3: messed up rebasing, now it should apply Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-01Merge tag 'drm-for-v4.16' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds921-96024/+56211
Pull drm updates from Dave Airlie: "This seems to have been a comparatively quieter merge window, I assume due to holidays etc. The "biggest" change is AMD header cleanups, which merge/remove a bunch of them. The AMD gpu scheduler is now being made generic with the etnaviv driver wanting to reuse the code, hopefully other drivers can go in the same direction. Otherwise it's the usual lots of stuff in i915/amdgpu, not so much stuff elsewhere. Core: - Add .last_close and .output_poll_changed helpers to reduce driver footprints - Fix plane clipping - Improved debug printing support - Add panel orientation property - Update edid derived properties at edid setting - Reduction in fbdev driver footprint - Move amdgpu scheduler into core for other drivers to use. i915: - Selftest and IGT improvements - Fast boot prep work on IPS, pipe config - HW workarounds for Cannonlake, Geminilake - Cannonlake clock and HDMI2.0 fixes - GPU cache invalidation and context switch improvements - Display planes cleanup - New PMU interface for perf queries - New firmware support for KBL/SKL - Geminilake HW workaround for perforamce - Coffeelake stolen memory improvements - GPU reset robustness work - Cannonlake horizontal plane flipping - GVT work amdgpu/radeon: - RV and Vega header file cleanups (lots of lines gone!) - TTM operation context support - 48-bit GPUVM support for Vega/RV - ECC support for Vega - Resizeable BAR support - Multi-display sync support - Enable swapout for reserved BOs during allocation - S3 fixes on Raven - GPU reset cleanup and fixes - 2+1 level GPU page table amdkfd: - GFX7/8 SDMA user queues support - Hardware scheduling for multiple processes - dGPU prep work rcar: - Added R8A7743/5 support - System suspend/resume support sun4i: - Multi-plane support for YUV formats - A83T and LVDS support msm: - Devfreq support for GPU tegra: - Prep work for adding Tegra186 support - Tegra186 HDMI support - HDMI2.0 and zpos support by using generic helpers tilcdc: - Misc fixes omapdrm: - Support memory bandwidth limits - DSI command mode panel cleanups - DMM error handling exynos: - drop the old IPP subdriver. etnaviv: - Occlusion query fixes - Job handling fixes - Prep work for hooking in gpu scheduler armada: - Move closer to atomic modesetting - Allow disabling primary plane if overlay is full screen imx: - Format modifier support - Add tile prefetch to PRE - Runtime PM support for PRG ast: - fix LUT loading" * tag 'drm-for-v4.16' of git://people.freedesktop.org/~airlied/linux: (1471 commits) drm/ast: Load lut in crtc_commit drm: Check for lessee in DROP_MASTER ioctl drm: fix gpu scheduler link order drm/amd/display: Demote error print to debug print when ATOM impl missing dma-buf: fix reservation_object_wait_timeout_rcu once more v2 drm/amdgpu: Avoid leaking PM domain on driver unbind (v2) drm/amd/amdgpu: Add Polaris version check drm/amdgpu: Reenable manual GPU reset from sysfs drm/amdgpu: disable MMHUB power gating on raven drm/ttm: Don't unreserve swapped BOs that were previously reserved drm/ttm: Don't add swapped BOs to swap-LRU list drm/amdgpu: only check for ECC on Vega10 drm/amd/powerplay: Fix smu_table_entry.handle type drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig drm/radeon: fill in rb backend map on evergreen/ni. drm/amdgpu/gfx9: fix ngg enablement to clear gds reserved memory (v2) drm/ttm: only free pages rather than update global memory count together drm/amdgpu: fix CPU based VM updates drm/amdgpu: fix typo in amdgpu_vce_validate_bo ...
2018-02-01Merge tag 'clk-for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "The core framework has a handful of patches this time around, mostly due to the clk rate protection support added by Jerome Brunet. This feature will allow consumers to lock in a certain rate on the output of a clk so that things like audio playback don't hear pops when the clk frequency changes due to shared parent clks changing rates. Currently the clk API doesn't guarantee the rate of a clk stays at the rate you request after clk_set_rate() is called, so this new API will allow drivers to express that requirement. Beyond this, the core got some debugfs pretty printing patches and a couple minor non-critical fixes. Looking outside of the core framework diff we have some new driver additions and the removal of a legacy TI clk driver. Both of these hit high in the dirstat. Also, the removal of the asm-generic/clkdev.h file causes small one-liners in all the architecture Kbuild files. Overall, the driver diff seems to be the normal stuff that comes all the time to fix little problems here and there and to support new hardware. Summary: Core: - Clk rate protection - Symbolic clk flags in debugfs output - Clk registration enabled clks while doing bookkeeping updates New Drivers: - Spreadtrum SC9860 - HiSilicon hi3660 stub - Qualcomm A53 PLL, SPMI clkdiv, and MSM8916 APCS - Amlogic Meson-AXG - ASPEED BMC Removed Drivers: - TI OMAP 3xxx legacy clk (non-DT) support - asm*/clkdev.h got removed (not really a driver) Updates: - Renesas FDP1-0 module clock on R-Car M3-W - Renesas LVDS module clock on R-Car V3M - Misc fixes to pr_err() prints - Qualcomm MSM8916 audio fixes - Qualcomm IPQ8074 rounded out support for more peripherals - Qualcomm Alpha PLL variants - Divider code was using container_of() on bad pointers - Allwinner DE2 clks on H3 - Amlogic minor data fixes and dropping of CLK_IGNORE_UNUSED - Mediatek clk driver compile test support - AT91 PMC clk suspend/resume restoration support - PLL issues fixed on si5351 - Broadcom IProc PLL calculation updates - DVFS support for Armada mvebu CPU clks - Allwinner fixed post-divider support - TI clkctrl fixes and support for newer SoCs" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (125 commits) clk: aspeed: Handle inverse polarity of USB port 1 clock gate clk: aspeed: Fix return value check in aspeed_cc_init() clk: aspeed: Add reset controller clk: aspeed: Register gated clocks clk: aspeed: Add platform driver and register PLLs clk: aspeed: Register core clocks clk: Add clock driver for ASPEED BMC SoCs clk: mediatek: adjust dependency of reset.c to avoid unexpectedly being built clk: fix reentrancy of clk_enable() on UP systems clk: meson-axg: fix potential NULL dereference in axg_clkc_probe() clk: Simplify debugfs registration clk: Fix debugfs_create_*() usage clk: Show symbolic clock flags in debugfs clk: renesas: r8a7796: Add FDP clock clk: Move __clk_{get,put}() into private clk.h API clk: sunxi: Use CLK_IS_CRITICAL flag for critical clks clk: Improve flags doc for of_clk_detect_critical() arch: Remove clkdev.h asm-generic from Kbuild clk: sunxi-ng: a83t: Add M divider to TCON1 clock clk: Prepare to remove asm-generic/clkdev.h ...
2018-02-01Merge tag 'vfio-v4.16-rc1' of git://github.com/awilliam/linux-vfioLinus Torvalds1-5/+10
Pull VFIO updates from Alex Williamson: - Mask INTx from user if pdev->irq is zero (Alexey Kardashevskiy) - Capability helper cleanup (Alex Williamson) - Allow mmaps overlapping MSI-X vector table with region capability exposing this feature (Alexey Kardashevskiy) - mdev static cleanups (Xiongwei Song) * tag 'vfio-v4.16-rc1' of git://github.com/awilliam/linux-vfio: vfio: mdev: make a couple of functions and structure vfio_mdev_driver static vfio-pci: Allow mapping MSIX BAR vfio: Simplify capability helper vfio-pci: Mask INTx if a device is not capabable of enabling it
2018-02-01drm/i915/bxt, glk: Avoid long atomic poll during CDCLK changeImre Deak3-6/+9
There is no requirement for doing the PCODE request polling atomically, so do that only for a short time switching to sleeping poll afterwards. The specification requires a 150usec timeout for the change notification, so let's use that for the atomic poll. Do the extra 2ms poll - needed as a workaround on BXT/GLK - in sleeping mode. v2: - rebase on v2 of patchset dropping the sandybridge_pcode_read/write refactoring (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-2-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 10:46:01 +0000