#
6d46d09a |
|
19-Jan-2024 |
Vinay Belgaumkar <vinay.belgaumkar@intel.com> |
drm/i915/mtl: Wake GT before sending H2G message Instead of waiting until the interrupt reaches GuC, we can grab a forcewake while triggering the H2G interrupt. GEN11_GUC_HOST_INTERRUPT is inside sgunit and is not affected by forcewakes. However, there could be some delays when platform is entering/exiting some higher level platform sleep states and a H2G is triggered. A forcewake ensures those sleep states have been fully exited and further processing occurs as expected. The hysteresis timers for C6 and higher sleep states will ensure there is no unwanted race between the wake and processing of the interrupts by GuC. This will have an official WA soon so adding a FIXME in the comments. v2: Make the new ranges watertight to address BAT failures and update commit message (Matt R). Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240119193513.221730-1-vinay.belgaumkar@intel.com
|
#
d823445b |
|
01-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/uncore: fix race around i915->params.mmio_debug Only check the conditions for unclaimed reg debug once to avoid locking problems when i915->params.mmio_debug changes between header and footer. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8749 Cc: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a53fb0fd84c4627398ccd4304b35db05603b89b6.1690886109.git.jani.nikula@intel.com
|
#
7afe2340 |
|
01-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/uncore: split unclaimed_reg_debug() to header and footer Make it easier to have different logic for the two for follow-up. Cc: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8a0a93f08314f8d7e222a907d9aa5e0b89cb969e.1690886109.git.jani.nikula@intel.com
|
#
fdd9b7dc |
|
27-Mar-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Check for unreliable MMIO during forcewake Although we now sanitycheck MMIO access during driver load to make sure the MMIO BAR isn't returning all 0xFFFFFFFF, there have been a few cases where (temporarily?) unreliable MMIO access has happened after GPU resets or power events. We'll often notice this on our next GT register access since forcewake handling will fail; let's change our handling slightly so that when this happens we print a more meaningful message clarifying that the problem is the MMIO access, not forcewake specifically. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230327195547.356584-3-andi.shyti@linux.intel.com
|
#
de414973 |
|
27-Mar-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Sanitycheck MMIO access early in driver load We occasionally see the PCI device in a non-accessible state at the point the driver is loaded. When this happens, all BAR accesses will read back as 0xFFFFFFFF. Rather than reading registers and misinterpreting their (invalid) values, let's specifically check for 0xFFFFFFFF in a register that cannot have that value to see if the device is accessible. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230327195547.356584-2-andi.shyti@linux.intel.com
|
#
95ccb25e |
|
01-Mar-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: remove unnecessary intel_pm.h includes As intel_pm.[ch] used to contain much more, intel_pm.h was included in a lot of places. Many of them are now unnecessary. Remove. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ab9a7147b0cd63d95b9f27ed40615b9c9be18f84.1677678803.git.jani.nikula@intel.com
|
#
0591bdad |
|
23-Feb-2023 |
Alan Previn <alan.previn.teres.alexis@intel.com> |
drm/i915/gsc: Fix the Driver-FLR completion The Driver-FLR flow may inadvertently exit early before the full completion of the re-init of the internal HW state if we only poll GU_DEBUG Bit31 (polling for it to toggle from 0 -> 1). Instead we need a two-step completion wait-for-completion flow that also involves GU_CNTL. See the patch and new code comments for detail. This is new direction from HW architecture folks. v2: - Add error message for the teardown timeout (Anshuman) - Don't duplicate code in comments (Jani) v3: - Add get/put runtime-pm for this function. Though not functionally required during unload, its so the uncore doesn't complain. v4: - Remove the get/put runtime-pm - that was for a prior version of this patch (not needed for drm-managed callback). - Remove the fixes tag since this is only for MTL and MTL still needs force probe (Daniele). - Bit 31 of GU_CNTL should be DRIVERFLR instead of DRIVERFLR_STATUS (Daniele). Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Tested-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230224001758.544817-1-alan.previn.teres.alexis@intel.com
|
#
70994bec |
|
07-Feb-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/uncore: cast iomem to avoid sparse warning drmm_add_action_or_reset() is unaware of __iomem and the pointer needs to be a plain void *. Cast __iomem away and back while the pointer goes through drmm. drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2463:17: expected void volatile [noderef] __iomem *addr drivers/gpu/drm/i915/intel_uncore.c:2463:17: got void *regs drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in argument 3 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2494:16: expected void *data drivers/gpu/drm/i915/intel_uncore.c:2494:16: got void [noderef] __iomem *regs Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-2-jani.nikula@intel.com
|
#
6b7cbdbe |
|
08-Dec-2022 |
Jonathan Cavitt <jonathan.cavitt@intel.com> |
drm/i915/gsc: Disable GSC engine and power well if FW is not selected The GSC CS is only used for communicating with the GSC FW, so no need to initialize it if we're not going to use the FW. If we're not using neither the engine nor the microcontoller, then we can also disable the power well. IMPORTANT: lack of GSC FW breaks media C6 due to opposing requirements between CS setup and forcewake idleness. See in-code comment for detail. Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: John C Harrison <John.C.Harrison@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221208200521.2928378-6-daniele.ceraolospurio@intel.com
|
#
5a44fcd7 |
|
08-Dec-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded If the GSC was loaded, the only way to stop it during the driver unload flow is to do a driver-FLR. The driver-initiated FLR is not the same as PCI config space FLR in that it doesn't reset the SGUnit and doesn't modify the PCI config space. Thus, it doesn't require a re-enumeration of the PCI BARs. However, the driver-FLR does cause a memory wipe of graphics memory on all discrete GPU platforms or a wipe limited to stolen memory on the integrated GPU platforms. We perform the FLR as the last action before releasing the MMIO bar, so that we don't have to care about the consequences of the reset on the unload flow. v2: rename FLR function, add comment to explain FLR impact (Rodrigo), better explain why GSC needs FLR (Alan) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221208200521.2928378-5-daniele.ceraolospurio@intel.com
|
#
955f4d71 |
|
07-Dec-2022 |
Miaoqian Lin <linmq006@gmail.com> |
drm/i915: Fix documentation for intel_uncore_forcewake_put__locked intel_uncore_forcewake_put__locked() is used to release a reference. Fixes: a6111f7b6604 ("drm/i915: Reduce locking in execlist command submission") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221207112909.2655251-1-linmq006@gmail.com
|
#
449a0ef5 |
|
07-Dec-2022 |
Miaoqian Lin <linmq006@gmail.com> |
drm/i915: Fix documentation for intel_uncore_forcewake_put__locked intel_uncore_forcewake_put__locked() is used to release a reference. Fixes: a6111f7b6604 ("drm/i915: Reduce locking in execlist command submission") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221207112909.2655251-1-linmq006@gmail.com (cherry picked from commit 955f4d7176eb154db587ae162ec2b392dc8d5f27) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
801543b2 |
|
09-Nov-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: stop including i915_irq.h from i915_trace.h Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h -> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h, makes sense to drop it, but that requires adding quite a few new includes all over the place. Prefer including i915_reg.h where needed instead of adding another implicit include, because eventually we'll want to split up i915_reg.h and only include the specific registers at each place. Also some places actually needed i915_irq.h too. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
|
#
a10234fd |
|
09-Nov-2022 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Partial abandonment of legacy DRM logging macros Convert some usages of legacy DRM logging macros into versions which tell us on which device have the events occurred. v2: * Don't have struct drm_device as local. (Jani, Ville) v3: * Store gt, not i915, in workaround list. (John) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221109104633.2579245-1-tvrtko.ursulin@linux.intel.com
|
#
2d3093fd |
|
14-Oct-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/pvc: Update forcewake domain for CCS register ranges The bspec was just updated with a correction to the forcewake domain required when accessing registers in the CCS engine ranges (0x1a000 - 0x1ffff and 0x26000 - 0x27fff) on PVC; these ranges require a wake on the RENDER domain, not the GT domain. Bspec: 67609 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014233004.1053678-1-matthew.d.roper@intel.com
|
#
14f2f9bf |
|
09-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/mtl: Add MTL forcewake support MTL has separate forcewake tables for the primary/render GT and the media GT; each GT's intel_uncore will use a separate forcewake table and should only initialize the domains that are relevant to that GT. The GT ack register also moves to a new location of (GSI base + 0xDFC) on this platform. Note that although our uncore handlers take care of transparently redirecting all register accesses in the media GT's GSI range to their new offset at 0x380000, the forcewake ranges listed in the table should use the final, post-translation offsets. NOTE: There are two ranges in the media IP that have multicast registers where the two register instances reside in different power wells (either VD0 or VD2). We don't have an easy way to deal with this today (and in fact we don't even access these register ranges in the driver today), so for now we just mark those ranges as FORCEWAKE_ALL which will cause all of the media power wells to be grabbed, ensuring proper operation. If we start reading/writing in those ranges in the future, we can re-visit whether it's worth adding extra steering complexity into our forcewake support. Bspec: 67788, 67789, 52077 Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220910001631.1986601-1-matthew.d.roper@intel.com
|
#
eefac38a |
|
08-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: Add GSI offset to uncore GT non-engine registers (referred to as "GSI" registers by the spec) have the same relative offsets on standalone media as they do on the primary GT, just with an additional "GSI offset" added to their MMIO address. If we store this GSI offset in the standalone media's intel_uncore structure, it can be automatically applied to all GSI reg reads/writes that happen on that GT, allowing us to re-use our existing GT code with minimal changes. Forcewake and shadowed register tables for the media GT (which will be added in a future patch) are listed as final addresses that already include the GSI offset, so we also need to add the GSI offset before doing lookups of registers in one of those tables. v2: - Add comment on raw_reg_*() macros explaining why we don't bother with GSI offsets in them. (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908224550.821257-1-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
cfb0fa42 |
|
06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Initialize MMIO access for each GT In a multi-GT system we need to initialize MMIO access for each GT, not just the primary GT. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-9-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
9ebb80e8 |
|
06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Drop intel_gt_tile_cleanup() Unmapping of the MMIO range can be done as a DRM-managed action, which will take care of the unmapping on device teardown and error paths. This will also ensure proper ordering with respect to other DRM-managed actions that we'll be using to clean up non-primary GTs in upcoming patches. We have not yet enabled any non-root GTs in the driver yet, so the kfree() of the GT structure is effectively dead code. When we do start enabling non-root GTs in upcoming patches, those are going to be using DRM-managed allocations tied to the device lifetime, so we don't need to explicitly free them (and kfree would be incorrect anyway). Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-5-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
639e30ee |
|
06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Only hook up uncore->debug for primary uncore The original intent of intel_uncore_mmio_debug as described in commit 0a9b26306d6a ("drm/i915: split out uncore_mmio_debug") was to be a singleton structure that could be shared between multiple GTs' uncore objects in a multi-tile system. Somehow we went off track and started allocating separate instances of this structure for each GT, which defeats that original goal. But in reality, there isn't even a need to share the mmio_debug between multiple GTs; on all modern platforms (i.e., everything after gen7) unclaimed register accesses are something that can only be detected for display registers. There's no point in grabbing the debug spinlock and checking for unclaimed accesses on an uncore used by an xehpsdv or pvc remote tile GT, or the uncore used by a mtl standalone media GT since all of the display accesses go through the primary intel_uncore. The simplest solution is to simply leave uncore->debug NULL on all intel_uncore instances except for the primary one. This will allow us to avoid the pointless debug spinlock acquisition we've been doing on MMIO accesses coming in through these intel_uncores. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-3-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
f16bfc1d |
|
06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume} Moving the locking for MMIO debug (and the final check for unclaimed accesses when resuming debug after a userspace-initiated forcewake) will make it simpler to completely skip MMIO debug handling on uncores that don't support it in future patches. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-2-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
da30390b |
|
18-Aug-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/mtl: MMIO range is now 4MB Previously only dgfx platforms had a 4MB MMIO range, but starting with MTL we now use the larger range for all platforms. Bspec: 63834, 63830 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220818234202.451742-4-radhakrishna.sripada@intel.com
|
#
6509dd11 |
|
17-Aug-2022 |
Radhakrishna Sripada <radhakrishna.sripada@intel.com> |
drm/i915: Skip Bit12 fw domain reset for gen12+ Bit12 of the Forcewake request register should not be cleared post gen12. Do not touch this bit while clearing during fw domain reset. v2: Tweak the comment to drop older platforms(MattR) Bspec: 52542 Signed-off-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817224304.255767-1-radhakrishna.sripada@intel.com
|
#
488e29fe |
|
19-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move platform_engine_mask to runtime info If it's modified runtime, it's runtime info. mock_gem_device() is the only one that modifies it. If that could be fixed, we wouldn't have to do this. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Maarten Lankhort <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1261406b373998c1a171ee9ed91f7f562826eba6.1660910433.git.jani.nikula@intel.com
|
#
e7858254 |
|
14-Jun-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/gt: Move multicast register handling to a dedicated file Handling of multicast/replicated registers is spread across intel_gt.c and intel_uncore.c today. As multicast handling and the related steering logic gets more complicated with the addition of new platforms and new rules it makes sense to centralize it all in one place. For now the existing functions have been moved to the new .c/.h as-is. Function renames and updates to operate in a more consistent manner will be done in subsequent patches. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220615001019.1821989-2-matthew.d.roper@intel.com
|
#
fb289464 |
|
11-May-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/pvc: Add forcewake support Add PVC's forcewake ranges. v2: - Drop replicated comment completely; move general cleanup of the documentation to a separate patch. Bspec: 67609 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220511060228.1179450-3-matthew.d.roper@intel.com
|
#
d32e8ed9 |
|
11-May-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: Reorganize and document shadow and forcewake tables Let's reorganize some of the forcewake/shadow handling in intel_uncore.c and consolidate the cargo-cult comments on each table into more general comments that apply to all tables. We'll probably move forcewake handling to its own dedicated file in the near future and further enhance this with true kerneldoc. But this is a good intermediate step to help clarify the behavior a bit. Cc: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220511060228.1179450-2-matthew.d.roper@intel.com
|
#
618f5df1 |
|
08-Apr-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/uncore: Warn only if unclaimed access remains flagged Commit 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed accesses") tried to improve our report of unclaimed register access, however it unveiled cases that were not previously causing any harm. Downgrade the first message to debug so we can still see them and eventually fix, but don't warn. Fixes: 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed accesses") Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220408164837.3845786-1-lucas.demarchi@intel.com
|
#
4b276ed3 |
|
04-Apr-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/uncore: Warn on previous unclaimed accesses Since gen6 we use FPGA_DBG register to detect unclaimed MMIO registers. This register is in the display engine IP and can only ever detect unclaimed accesses to registers in this area. However sometimes there are reports of this triggering for registers in other areas, which should not be possible. Right now we always warn after the read/write of registers going through unclaimed_reg_debug(). However places using __raw_uncore_* may be triggering the unclaimed access and those being later accounted to a different register. Let's warn both before and after the read/write with a slightly different message, so it's clear if the register reported in the warning is actually the culprit. Commit dda960335e02 ("drm/i915: Just clear the mmiodebug before a register access") attempted to solve the same issue by removing the warning when if FPGA_DBG flags before the mmio read/write. However, it doesn't solve it completely as FPGA_DBG may remain set when reading registers outside display. So in the end the check after the mmio read/write triggers the warning pointing to the wrong register. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405001149.2675226-1-lucas.demarchi@intel.com
|
#
bec68cc9 |
|
18-Mar-2022 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Prepare for multiple GTs On a multi-tile platform, each tile has its own registers + GGTT space, and BAR 0 is extended to cover all of them. Up to four GTs are supported in i915->gt[], with slot zero shadowing the existing i915->gt0 to enable source compatibility with legacy driver paths. A for_each_gt macro is added to iterate over the GTs and will be used by upcoming patches that convert various parts of the driver to be multi-gt aware. Only the primary/root tile is initialized for now; the other tiles will be detected and plugged in by future patches once the necessary infrastructure is in place to handle them. Signed-off-by: Abdiel Janulgue <abdiel.janulgue@gmail.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220318233938.149744-4-andi.shyti@linux.intel.com
|
#
31a86f00 |
|
14-Mar-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Add support for steered register writes Upcoming patches will need to steer writes to multicast registers as well as reading them. Although the setting of the 'multicast' bit should only really matter for write operations (reads always operate in a unicast manner and give us the result from one specific instance), Wa_22013088509 suggests that we leave the multicast bit enabled when performing read operations, so we follow suit here. Cc: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220314234203.799268-4-matthew.d.roper@intel.com
|
#
ab9e00a3 |
|
08-Feb-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/gt: Use parameterized RING_MI_MODE We have both a parameterized RING_MI_MODE() macro and an RCS-specific MI_MODE; drop the latter and use the former everywhere. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209051140.1599643-4-matthew.d.roper@intel.com
|
#
0d6419e9 |
|
27-Jan-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Move GT registers to their own header file This is a huge, chaotic mass of registers copied over as-is without any real cleanup. We'll come back and organize these better, align on consistent coding style, remove dead code, etc. in separate patches later that will be easier to review. v2: - Add missing include in intel_pxp_irq.c v3: - Correct a few indentation errors (Lucas) - Minor conflict resolution Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-6-matthew.d.roper@intel.com
|
#
198bca93 |
|
20-Jan-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: split out i915_reg_read_ioctl() to i915_ioctl.[ch] Add new files i915_ioctl.[ch] to hold small ioctls that are out of place everywhere else, and not big enough to warrant a file of their own. For starters, it's just for i915_reg_read_ioctl() that's a bit high level for a low level implementation that intel_uncore.[ch] is. Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120113346.3214745-1-jani.nikula@intel.com
|
#
202b1f4c |
|
10-Jan-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/gt: Move engine registers to their own header Let's continue breaking up and cleaning up the massive i915_reg.h file by moving all registers that are defined in relation to an engine base to their own header. There are probably a bunch of other "engine registers" that we haven't moved yet (especially those that belong to the render engine in the 0x2??? range), but this is a relatively straightforward first step. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220111051600.3429104-8-matthew.d.roper@intel.com
|
#
7938d615 |
|
19-Oct-2021 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Flush TLBs before releasing backing store We need to flush TLBs before releasing backing store otherwise userspace is able to encounter stale entries if a) it is not declaring access to certain buffers and b) it races with the backing store release from a such undeclared execution already executing on the GPU in parallel. The approach taken is to mark any buffer objects which were ever bound to the GPU and to trigger a serialized TLB flush when their backing store is released. Alternatively the flushing could be done on VMA unbind, at which point we would be able to ascertain whether there is potential a parallel GPU execution (which could race), but essentially it boils down to paying the cost of TLB flushes potentially needlessly at VMA unbind time (when the backing store is not known to be going away so not needed for safety), versus potentially needlessly at backing store relase time (since we at that point cannot tell whether there is anything executing on the GPU which uses that object). Thereforce simplicity of implementation has been chosen for now with scope to benchmark and refine later as required. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
030def2c |
|
14-Dec-2021 |
Michał Winiarski <michal.winiarski@intel.com> |
drm/i915: Store backpointer to GT in uncore We now support a per-gt uncore, yet we're not able to infer which GT we're operating upon. Let's store a backpointer for now. At this point the early initialization of the gt needs to be broken in two parts where the first is needed to assign to the gt the i915 private data pointer and the uncore. A temporary function has been made and the two parts are __intel_gt_init_early() and intel_gt_init_early(). This split will be fixed in the future with the multitile patch. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-2-andi.shyti@linux.intel.com
|
#
498f02b6 |
|
28-Oct-2021 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: split general MMIO setup from per-GT uncore init In coming patches we'll be doing the actual tile initialization between these two uncore init phases. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211029032817.3747750-3-matthew.d.roper@intel.com
|
#
f0e204e0 |
|
22-Oct-2021 |
Mullati, Siva <siva.mullati@intel.com> |
drm/i915: abstraction for iosf to compile on all archs The asm/iosf_mbi.h header is x86-only. Let's make IOSF_MBI kconfig selection conditional to x86 and provide a header with stubs for other architectures. This helps getting i915 available for other architectures in future. Signed-off-by: Mullati, Siva <siva.mullati@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022192756.1228354-1-siva.mullati@intel.com
|
#
5def925d |
|
03-Oct-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: fix regression with uncore refactoring. This was causing infinite recursion on snb/ivb. Fixes: 5716c8c6f4b6 ("drm/i915/uncore: split the fw get function into separate vfunc") Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004003133.2279446-1-airlied@gmail.com
|
#
5716c8c6 |
|
28-Sep-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915/uncore: split the fw get function into separate vfunc constify it while here. drop the put function since it was never overloaded and always has done the same thing, no point in indirecting it for show. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/41c3e1896162fc08e22e40b00642791365a8c00e.1632869550.git.jani.nikula@intel.com
|
#
54fc4f13 |
|
22-Sep-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: fwtable read handlers are now used on all forcewake platforms With the recent refactor of the uncore mmio handling, all forcewake-based platforms (i.e., graphics version 6 and beyond) now use the 'fwtable' read handlers. Let's pull the assignment out of the per-platform if/else ladder to make this more obvious. Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210923003029.2194375-1-matthew.d.roper@intel.com
|
#
c74e66d4 |
|
10-Sep-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/dg2: Add DG2-specific shadow register table We thought the DG2 table of shadowed registers would be the same as the gen12/xehp table, but it turns out that there are a few minor differences that require us to define a new DG2-specific table: * One register is removed (0xC4D4) * One register is added (0xC4E0) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-7-matthew.d.roper@intel.com
|
#
e5b32ae3 |
|
10-Sep-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: Drop gen11 mmio read handlers Consolidate down to just a single 'fwtable' implementation. For reads we don't need to worry about shadow tables. While consolidating the functions, gen11/gen12 pick up a NEEDS_FORCE_WAKE() check that they didn't have before, allowing them to bypass a lot of forcewake/shadow checking for non-GT registers (e.g., display). v2: - Restore NEEDS_FORCE_WAKE() check. (Chris, Tvrtko) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-6-matthew.d.roper@intel.com
|
#
aef02736 |
|
10-Sep-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: Drop gen11/gen12 mmio write handlers Now that the reference to the shadow table is stored within the uncore, we don't need to generate separate fwtable, gen11_fwtable, and gen12_fwtable variants of the register write functions; a single 'fwtable' implementation will work for all of those platforms now. While consolidating the functions, gen11/gen12 pick up a NEEDS_FORCE_WAKE() check that they didn't have before, allowing them to bypass a lot of forcewake/shadow checking for non-GT registers (e.g., display). However since these later platforms also introduce media engines at higher MMIO offsets, the definition of NEEDS_FORCE_WAKE() is extended to also consider register offsets above GEN11_BSD_RING_BASE. v2: - Restore NEEDS_FORCE_WAKE(), but extend it for compatibility with the gen11+ platforms by also passing offsets above GEN11_BSD_RING_BASE. (Chris, Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-5-matthew.d.roper@intel.com
|
#
09b2a597 |
|
10-Sep-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: Replace gen8 write functions with general fwtable Now that we have both a standard forcewake table (albeit a single-entry table) and the shadow table stored in the uncore, we can drop the gen8-specific write handlers in favor of the general fwtable version. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-4-matthew.d.roper@intel.com
|
#
6cdbb101 |
|
10-Sep-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: Associate shadow table with uncore Store a reference to a platform's shadow table inside the uncore, the same as we do with the forcewake table. This will allow us to use a single set of functions that operate on the shadow table reference rather than generating lots of nearly-identical functions via macros that differ only in terms of the table that they reference. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-3-matthew.d.roper@intel.com
|
#
1ab2b4cd |
|
10-Sep-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/uncore: Convert gen6/gen7 read operations to fwtable On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we simply check whether the register offset is < 0x40000, and return FORCEWAKE_RENDER if it is. To prepare for upcoming refactoring, let's define a single-entry forcewake table from [0x0, 0x3ffff] and switch these platforms over to use the fwtable reader functions. v2: - Drop __gen6_reg_read_fw_domains which is no longer used. (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-2-matthew.d.roper@intel.com
|
#
5c5c40e2 |
|
28-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/xehp: Xe_HP shadowed registers are a strict superset of gen12 The list of shadowed registers on XeHP is identical to the set for earlier gen12 platforms, with additional ranges added for the new VCS and VECS engines. Since those register ranges were reserved on earlier gen12 platforms, it's safe to consolidate to a single gen12 table rather than tracking Xe_HP separately. Bspec: 52077 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729054118.2458523-7-matthew.d.roper@intel.com
|
#
5798a769 |
|
28-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/gen12: Update shadowed register table The bspec lists many shadowed registers (i.e., registers for which we don't need to grab forcewake when writing) that we weren't tracking in the driver. Although we may not actually use all of these registers right now, it's best to just match the bspec list exactly. Note that the bspec also lists registers that are shadowed for various HW-internal accesses; we can ignore those and just list the ones that are shadowed for accesses from the IA/CPU. Bspec: 52077 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729054118.2458523-6-matthew.d.roper@intel.com
|
#
0bb50de1 |
|
28-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/gen11: Update shadowed register table The bspec lists many shadowed registers (i.e., registers for which we don't need to grab forcewake when writing) that we weren't tracking in the driver. Although we may not actually use all of these registers right now, it's best to just match the bspec list exactly. Note that the bspec also lists registers that are shadowed for various HW-internal accesses; we can ignore those and just list the ones that are shadowed for accesses from the IA/CPU. Bspec: 18333 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729054118.2458523-5-matthew.d.roper@intel.com
|
#
f9d56cd6 |
|
29-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Make shadow tables range-based Rather than defining our shadow tables as a list of individual registers, provide them as a list of register ranges; we'll have some ranges of multiple registers being added soon (and we already have a couple adjacent registers that we can squash into a single range now). This change also defines the table with hex literal values rather than symbolic register names; since that's how the tables are defined in the bspec, this change will make it easier to review the tables overall. v2: - Force signed comparison on range overlap sanity check Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729152158.2646246-1-matthew.d.roper@intel.com
|
#
39afa410 |
|
28-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Re-use gen11 forcewake read functions on gen12 The forcewake read logic is identical between gen11 and gen12, only the forcewake table data (which is tracked separately) differs; there's no need to generate a separate set of gen12 read functions when the gen11 functions will work just as well. We'll keep the separate write functions for now since the generated code directly references different shadow tables between the two platforms. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729054118.2458523-3-matthew.d.roper@intel.com
|
#
bc33e71f |
|
28-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: correct name of GT forcewake domain in error messages For historical reasons, the GT forcewake domain used to be referred to as the "blitter" domain; that name is no longer accurate since the GT domain contains a lot of additional registers and functionality besides just the blitter. Although we renamed the domain in the driver in commit 55e3c170950f ("drm/i915: Rename FORCEWAKE_BLITTER to FORCEWAKE_GT"), we neglected to update the string that gets printed in driver error messages; let's do that now to avoid confusion. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729054118.2458523-2-matthew.d.roper@intel.com
|
#
e0531636 |
|
29-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/dg2: Add forcewake table The DG2 forcewake table is very similar to the one used by XeHP SDV (and both platforms are even presented as a single table in the bspec). For the most part DG2 starts using a few additional ranges that were 'reserved' on XeHP SDV and stops using some others. However there is a single range (0xd800-0xd87f) that needs to be handled differently between the two platforms (it needs GT wake on XeHP SDV, but render wake on DG2) so unless we want to wake both domains (which could waste power) or define new types of forcewake domains for this special case we need to have separate tables for the two platforms. Let's define the ranges for both platforms with a parameterized macro so that we don't actually need to duplicate everything in the code. It should be fine for DG2 to re-use the Xe_HP shadow register list so we can continue to use the 'xehpsdv' MMIO write functions and don't need to spin up a separate DG2 instance. Bspec: 66534 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729170008.2836648-4-matthew.d.roper@intel.com
|
#
bfac1e2b |
|
23-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/xehp: Xe_HP forcewake support Implement Xe_HP forcewake handling. While we're at it, let's reorder to the forcewake assignment if/else ladder to match our usual driver conventions. Co-authored-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723174239.1551352-6-matthew.d.roper@intel.com
|
#
d70cc074 |
|
07-Jul-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: finish INTEL_GEN and friends conversion Commit 161058fb899e ("drm/i915: Add remaining conversions to GRAPHICS_VER") did the last conversions to the new macros for version checks, but left one instance behind and some other changes sneaked in to use INTEL_GEN. Remove the last users so we can remove the macros. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707181325.2130821-3-lucas.demarchi@intel.com
|
#
932641f0 |
|
17-Jun-2021 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: extract steered reg access to common function New steering cases will be added in the follow-up patches, so prepare a common helper to avoid code duplication. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210617211425.1943662-2-matthew.d.roper@intel.com
|
#
651e7d48 |
|
05-Jun-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: replace IS_GEN and friends with GRAPHICS_VER This was done by the following semantic patch: @@ expression i915; @@ - INTEL_GEN(i915) + GRAPHICS_VER(i915) @@ expression i915; expression E; @@ - INTEL_GEN(i915) >= E + GRAPHICS_VER(i915) >= E @@ expression dev_priv; expression E; @@ - !IS_GEN(dev_priv, E) + GRAPHICS_VER(dev_priv) != E @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + GRAPHICS_VER(dev_priv) == E @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_GRAPHICS_VER(dev_priv, from, until) @def@ expression E; identifier id =~ "^gen$"; @@ - id = GRAPHICS_VER(E) + ver = GRAPHICS_VER(E) @@ identifier def.id; @@ - id + ver It also takes care of renaming the variable we assign to GRAPHICS_VER() so to use "ver" rather than "gen". Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210606045050.103862-2-lucas.demarchi@intel.com
|
#
c256af0d |
|
20-Apr-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/lmem: Fail driver init if LMEM training failed Boot firmware performs memory training and health assessment during startup. If the memory training fails, the firmware will consider the GPU unusable and will instruct the punit to keep the GT powered down. If this happens, our driver will be unable to communicate with the GT (all GT registers will read back as 0, forcewake requests will timeout, etc.) so we should abort driver initialization if this happens. We can confirm that LMEM was initialized successfully via sgunit register GU_CNTL. Bspec: 53111 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Cc: Caz Yokoyama <Caz.Yokoyama@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210420131842.164163-5-matthew.auld@intel.com
|
#
33adf482 |
|
12-Apr-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/selftests: eliminate use of gen_mask Remove the remaining uses of INTEL_GEN_MASK() and the correspondent gen_mask in struct intel_device_info. This will allow the removal of gen_mask later since it's incompatible with the new per-IP versioning scheme. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-8-lucas.demarchi@intel.com
|
#
29b6f88d |
|
12-Feb-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Try to detect sudden loss of MMIO access In rare circumstances bugs in PCI programming, broken BIOS, or failing hardware can cause the CPU to lose access to the MMIO BAR on dgfx platforms. This is a pretty catastrophic failure since all register reads come back with values of 0xFFFFFFFF. Let's check for this special case while doing our usual checks for unclaimed registers; the FPGA_DBG register we use for those checks on modern platforms has some unused bits that will always read back as 0 when things are behaving properly; we can use them as canaries to detect when MMIO itself has suddenly broken and try to print a more informative error message in the logs. v2: Let the detection function still return 'true' if we've lost our MMIO access. We'll still get an extra false positive message about an unclaimed register access, but we'll still honor the 'mmio_debug' limit and not spam the log. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210212211925.3418280-2-matthew.d.roper@intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
#
8ff5446a |
|
28-Jan-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Remove references to struct drm_device.pdev Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. v6: * also remove assignment in selftests/ in a later patch (Chris) v5: * remove assignment in later patch (Chris) v3: * rebased v2: * move gt/ and gvt/ changes into separate patches Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: 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> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-2-tzimmermann@suse.de
|
#
54b3f0e6 |
|
30-Nov-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: remove last traces of I915_READ(), I915_WRITE() and POSTING_READ() Good riddance! Remove the macros and their remaining references in comments. The following functions should be used instead, depending on the use case: - intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read() - intel_de_read(), intel_de_write(), intel_de_posting_read() Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130111601.2817-10-jani.nikula@intel.com
|
#
669f3f2b |
|
30-Nov-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: remove last traces of I915_READ_FW() and I915_WRITE_FW() Good riddance! Remove the macros and their remaining references in comments. intel_uncore_read_fw() and intel_uncore_write_fw() should be used instead. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130111601.2817-2-jani.nikula@intel.com
|
#
5c6c13cd |
|
11-Aug-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Drop runtime-pm assert from vgpu io accessors The "mmio" writes into vgpu registers are simple memory traps from the guest into the host. We do not need to assert in the guest that the device is awake for the io as we do not write to the device itself. However, over time we have refactored all the mmio accessors with the result that the vgpu reuses the gen2 accessors and so inherits the assert for runtime-pm of the native device. The assert though has actually been there since commit 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps"). References: 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200811092532.13753-1-chris@chris-wilson.co.uk (cherry picked from commit 0e65ce24a33c1d37da4bf43c34e080334ec6cb60) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
0e65ce24 |
|
11-Aug-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Drop runtime-pm assert from vgpu io accessors The "mmio" writes into vgpu registers are simple memory traps from the guest into the host. We do not need to assert in the guest that the device is awake for the io as we do not write to the device itself. However, over time we have refactored all the mmio accessors with the result that the vgpu reuses the gen2 accessors and so inherits the assert for runtime-pm of the native device. The assert though has actually been there since commit 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps"). References: 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200811092532.13753-1-chris@chris-wilson.co.uk
|
#
92f5df0d |
|
09-Oct-2020 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Update gen12 forcewake table The bspec's forcewake page was very stale and out of date for recent platforms. The hardware team finally provided us with an updated gen12 table (which applies to TGL, RKL, and DG1) and there are a lot of changes. v2: - Add comments showing the subregions of ranges that we've combined for ease of code review. (Jose) - Rebase on the s/FORCEWAKE_BLITTER/FORCEWAKE_GT/ patch Bspec: 66696 Cc: Caz Yokoyama <caz.yokoyama@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201009194442.3668677-3-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
55e3c170 |
|
09-Oct-2020 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Rename FORCEWAKE_BLITTER to FORCEWAKE_GT The power well that we've been referring to as the 'blitter' well is actually more of a general GT power well which contains a lot of things other than the blitter engine registers. The FORCEWAKE_BLITTER name in the code was used for historic reasons, but no longer matches how the bspec describes this power well and just causes confusion for people not familiar with this area of the code. Let's rename it to FORCEWAKE_GT to more accurately describe the role of the power well and match how the modern bspec refers to it. v2: - Add a comment noting that the GT power well includes the blitter engine. (Jose) Bspec: 66696, 66534, 67609 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201009194442.3668677-2-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
eafeb204 |
|
06-Oct-2020 |
Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> |
drm/i915/dg1: Increase mmio size to 4MB On DGFX the register range has been extended to go up to 8MB. However we only actually use up to address 280000h, so let's increase it to 4MB. v2 (Lucas): add bspec reference and reword commit message to explain the 4 vs 8 MB used (requested by Matt Roper) Bspec: 53616 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-4-lucas.demarchi@intel.com
|
#
b79ffa91 |
|
16-Sep-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Initialise outparam for error return from wait_for_register Just in case the caller passes in 0 for both slow&fast timeouts, make sure we initialise the stack value returned. Add an assert so that we don't make the mistake of passing 0 timeouts for the wait. drivers/gpu/drm/i915/intel_uncore.c:2011 __intel_wait_for_register_fw() error: uninitialized symbol 'reg_value'. References: 3f649ab728cd ("treewide: Remove uninitialized_var() usage") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200916105022.28316-1-chris@chris-wilson.co.uk
|
#
3f649ab7 |
|
03-Jun-2020 |
Kees Cook <keescook@chromium.org> |
treewide: Remove uninitialized_var() usage Using uninitialized_var() is dangerous as it papers over real bugs[1] (or can in the future), and suppresses unrelated compiler warnings (e.g. "unused variable"). If the compiler thinks it is uninitialized, either simply initialize the variable or make compiler changes. In preparation for removing[2] the[3] macro[4], remove all remaining needless uses with the following script: git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \ xargs perl -pi -e \ 's/\buninitialized_var\(([^\)]+)\)/\1/g; s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;' drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid pathological white-space. No outstanding warnings were found building allmodconfig with GCC 9.3.0 for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64, alpha, and m68k. [1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/ [2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/ [3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/ [4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/ Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5 Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
792592e7 |
|
07-Jul-2020 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: Move the engine mask to intel_gt_info Since the engines belong to the GT, move the runtime-updated list of available engines to the intel_gt struct. The original mask has been renamed to indicate it contains the maximum engine list that can be found on a matching device. In preparation for other info being moved to the gt in follow up patches (sseu), introduce an intel_gt_info structure to group all gt-related runtime info. v2: s/max_engine_mask/platform_engine_mask (tvrtko), fix selftest Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200708003952.21831-5-daniele.ceraolospurio@intel.com
|
#
242613af |
|
07-Jul-2020 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: Use the gt in HAS_ENGINE A follow up patch will move the engine mask under the gt structure, so get ready for that. v2: switch the remaining gvt case using dev_priv->gt to gvt->gt (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200708003952.21831-3-daniele.ceraolospurio@intel.com
|
#
65706203 |
|
06-Jul-2020 |
Michał Winiarski <michal.winiarski@intel.com> |
drm/i915: Print caller when tainting for CI We can add taint from multiple places, printing the caller allows us to have a better overview of what exactly caused us to do the tainting. v2: Tweak format and print the device (Chris) v3: Move things around (Chris) Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Petri Latvala <petri.latvala@intel.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/20200706144107.204821-2-michal@hardline.pl
|
#
8a25c4be |
|
18-Jun-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/params: switch to device specific parameters Start using device specific parameters instead of module parameters for most things. The module parameters become the immutable initial values for i915 parameters. The device specific parameters in i915->params start life as a copy of i915_modparams. Any later changes are only reflected in the debugfs. The stragglers are: * i915.force_probe and i915.modeset. Needed before dev_priv is available. This is fine because the parameters are read-only and never modified. * i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and I915_STATE_WARN_ON would result in massive and ugly churn. This is handled by not exposing the parameter via debugfs, and leaving the parameter writable in sysfs. This may be fixed up in follow-up work. * i915.inject_probe_failure. Only makes sense in terms of the module, not the device. This is handled by not exposing the parameter via debugfs. v2: Fix uc i915 lookup code (Michał Winiarski) Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com
|
#
03c10f47 |
|
01-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Relinquish forcewake immediately after manual grouping Our forcewake utilisation is split into categories: automatic and manual. Around bare register reads, we look up the right forcewake domain and automatically acquire and release [upon a timer] the forcewake domain. For other access, where we know we require the forcewake across a group of register reads, we manually acquire the forcewake domain and release it at the end. Again, this currently arms the domain timer for a later release. However, looking at some energy utilisation profiles, we have tried to avoid using forcewake [and rely on the natural wake up to post register updates] due to that even keep the fw active for a brief period contributes to a significant power draw [i.e. when the gpu is sleeping with rc6 at high clocks]. But as it turns out, not posting the writes immediately also has unintended consequences, such as not reducing the clocks and so conserving power while busy. As a compromise, let us only arm the domain timer for automatic forcewake usage around bare register access, but immediately release the forcewake when manually acquired by intel_uncore_forcewake_get/_put. The corollary to this is that we may instead have to take forcewake more often, and so incur a latency penalty in doing so. For Sandybridge this was significant, and even on the latest machines, taking forcewake at interrupt frequency is a huge impact. [So we don't do that anymore! Hopefully, this will spare us from still needing the mitigation of the timer for steady state execution.] 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/20200601072446.19548-13-chris@chris-wilson.co.uk
|
#
a1b2eeac |
|
10-May-2020 |
Pascal Terjan <pterjan@google.com> |
drm/i915: Remove unused HAS_FWTABLE macro It has been unused since commit ccb2aceaaa5f ("drm/i915: use vfuncs for reg_read/write_fw_domains"). Signed-off-by: Pascal Terjan <pterjan@google.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/20200510212521.128869-1-pterjan@google.com
|
#
c4310def |
|
16-Apr-2020 |
Radhakrishna Sripada <radhakrishna.sripada@intel.com> |
drm/i915/icl: Update forcewake firmware ranges Some workarounds are not sticking across suspend resume cycles. The forcewake ranges table has been updated and would reflect the hardware appropriately. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1222 v2: Simplify the table and use 0 for some unused ranges(Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200416164610.15422-1-radhakrishna.sripada@intel.com
|
#
19b5b50f |
|
02-Apr-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/uncore: prefer struct drm_device based logging Prefer struct drm_device based logging over struct device based logging. No functional changes. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200402114819.17232-14-jani.nikula@intel.com
|
#
032d992d |
|
25-Mar-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/selftests: Measure the energy consumed while in RC6 Measure and compare the energy consumed, as reported by the rapl MSR, by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not at least halve the energy consumption of RC0, as this more than likely means we failed to enter RC0 correctly. If we can't measure the energy draw with the MSR, then it will report 0 for both measurements. Since the measurement works on all gen6+, this seems worth flagging as an error. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200325101502.12591-1-chris@chris-wilson.co.uk
|
#
a9f236d1 |
|
14-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915: Make WARN* drm specific where uncore or stream ptr is available drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where intel_uncore/i915_perf_stream struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @@ identifier func, T; @@ func(...) { ... struct intel_uncore *T = ...; <... ( -WARN( +drm_WARN(&T->i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->i915->drm, ...) ) ...> } @@ identifier func, T; @@ func(struct intel_uncore *T,...) { <... ( -WARN( +drm_WARN(&T->i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->i915->drm, ...) ) ...> } @@ identifier func, T; @@ func(struct i915_perf_stream *T,...) { +struct drm_i915_private *i915 = T->perf->i915; <+... ( -WARN( +drm_WARN(&i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&i915->drm, ...) ) ...+> } command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file <script> \ --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-11-pankaj.laxminarayan.bharadiya@intel.com
|
#
48a1b8d4 |
|
14-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915: Make WARN* drm specific where drm_priv ptr is available drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \ <script> --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-10-pankaj.laxminarayan.bharadiya@intel.com
|
#
d0208cfa |
|
07-Jan-2020 |
Wambui Karuga <wambui.karugax@gmail.com> |
drm/i915/uncore: use new struct drm_device based macros. Convert to the use of new struct drm_device based logging macros to replace the use of the printk based macros in i915/intel_uncore.c Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7142083e727ab400797c8a90a2196ee37a22c201.1578409433.git.wambui.karugax@gmail.com
|
#
cf82d9dd |
|
13-Sep-2019 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915/tgl: Introduce gen12 forcewake ranges The media ranges extend beyond what gen11 gives so we can't piggypack on gen11 ranges, even on read side. Introduce a table for gen12 and accessors for it. v2: correctly implement gen12_fwtable_write/read (Daniele) v3: update with ranges from bspec. v4: avoid GEN11_NEEDS_FORCEWAKE (Mika) v5: bspec ref (Daniele) BSpec: 52078 Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190913141652.27958-2-mika.kuoppala@linux.intel.com
|
#
c9f8d187 |
|
13-Sep-2019 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Update Gen11 forcewake ranges Daniele noticed new render ranges in Gen11 fw table. Bspec: 18331 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190913141652.27958-1-mika.kuoppala@linux.intel.com
|
#
0a9b2630 |
|
09-Aug-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: split out uncore_mmio_debug Multiple uncore structures will share the debug infrastructure, so move it to a common place and add extra locking around it. Also, since we now have a separate object, it is cleaner to have dedicated functions working on the object to stop and restart the mmio debug. Apart from the cosmetic changes, this patch introduces 2 functional updates: - All calls to check_for_unclaimed_mmio will now return false when the debug is suspended, not just the ones that are active only when i915_modparams.mmio_debug is set. If we don't trust the result of the check while a user is doing mmio access then we shouldn't attempt the check anywhere. - i915_modparams.mmio_debug is not save/restored anymore around user access. The value is now never touched by the kernel while debug is disabled so no need for save/restore. v2: squash mmio_debug patches, restrict mmio_debug lock usage (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: 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/20190809063116.7527-1-chris@chris-wilson.co.uk
|
#
6da4a2c4 |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: remove unnecessary includes of intel_display_types.h header With its original name intel_drv.h the intel_display_types.h header was superfluously cargo-cult included all over the place, while it's really mostly about display internals. Remove the unnecessary includes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e3d737f0ab87c55969e62c1e077e15c04c238297.1565085692.git.jani.nikula@intel.com
|
#
1d455f8d |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: rename intel_drv.h to display/intel_display_types.h Everything about the file is about display, and mostly about types related to display. Move under display/ as intel_display_types.h to reflect the facts. There's still plenty to clean up, but start off with moving the file where it logically belongs and naming according to contents. v2: fix the include guard name in the renamed file Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com
|
#
a09d9a80 |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: avoid including intel_drv.h via i915_drv.h->i915_trace.h Disentangle i915_drv.h from intel_drv.h, which gets included via i915_trace.h. This necessitates including i915_trace.h wherever it's needed. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ed82bf259d3b725a1a1a3c3e9d6fb5c08bc4d489.1565085691.git.jani.nikula@intel.com
|
#
50d84418 |
|
02-Aug-2019 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Add i915 to i915_inject_probe_failure With i915 added to i915_inject_probe_failure we can use dedicated printk when injecting artificial load failure. Also make this function look like other i915 functions that return error code and make it more flexible to return any provided error code instead of previously assumed -ENODEV. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: 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/20190802184055.31988-2-michal.wajdeczko@intel.com
|
#
e4661f14 |
|
01-Aug-2019 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Fix documentation for __intel_wait_for_register_fw* Use section name "Return" and proper error code -ETIMEDOUT Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.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/20190802124739.12548-1-michal.wajdeczko@intel.com
|
#
2b92a82f |
|
25-Jul-2019 |
Jordan Justen <jordan.l.justen@intel.com> |
drm/i915/tgl: allow the reg_read ioctl to read the RCS TIMESTAMP register This enables the Mesa driver to advertise support for ARB_timer_query, and thus an OpenGL version higher than 3.2. Based on the ICL patch by Paulo Zanoni and CNL patch by Nanley Chery. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190726002412.5827-3-lucas.demarchi@intel.com
|
#
f2db53f1 |
|
12-Jul-2019 |
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> |
drm/i915: Replace "_load" with "_probe" consequently Use the "_probe" nomenclature not only in i915_driver_probe() helper name but also in other related function / variable names for consistency. Only the userspace exposed name of a related module parameter is left untouched. Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.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/20190712112429.740-4-janusz.krzysztofik@linux.intel.com
|
#
77adbd8f |
|
08-Jul-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Explicitly track active fw_domain timers Stop guessing over whether we have an extra wakeref held by the delayed fw put, and track it explicitly for the sake of debug. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190708154914.26850-1-chris@chris-wilson.co.uk
|
#
15e7facb |
|
07-Jul-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Pull assert_forcewake_active() underneath the lock Make no assumption that something in the background is not acquiring the fw_domain -- but we still do not track owner so assume that any active domain is intended by the caller. 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/20190707151135.11700-1-chris@chris-wilson.co.uk
|
#
badf1f27 |
|
05-Jul-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Order assert forcewake test Read the current value before computing the expected to ensure that if the timer does complete early (against our will), it should not cause a false positive. v2: The local irq disable did not prevent the timer from running. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111074 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/20190705074604.16496-1-chris@chris-wilson.co.uk
|
#
b7dc9395 |
|
04-Jul-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Check caller held wakerefs in assert_forcewakes_active The intent of the assert is to document that the caller took the appropriate wakerefs for the function. However, as Tvrtko pointed out, we simply check whether the fw_domains are active and may be confused by the auto wakeref which may be dropped between the check and use. Let's be more careful in the assert and check that each fw_domain has an explicit caller wakeref above and beyond the automatic wakeref. v2: Fix spelling for config DRM_I915_DEBUG_RUNTIME_PM v3: Timer may still be active after we drop the autowakeref, we need to check domain->active instead. v4: The timer checks domain->active, but we still need to check the timer. (This is starting to look weird...) Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> 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: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704102048.6436-1-chris@chris-wilson.co.uk
|
#
9e138ea1 |
|
19-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/gvt: decouple check_vgpu() from uncore_init() With multiple uncore to initialize (GT vs Display), it makes little sense to have the vgpu_check inside uncore_init(). We also have a catch-22 scenario where the uncore is required to read the vgpu capabilities while the vgpu capabilities are required to decide if we need to initialize forcewake support. To remove this circular dependency, we can perform the required MMIO access by mmapping just the vgtif shared page in mmio space and use raw accessors. v2: rename check_vgpu to detect_vgpu (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620010021.20637-7-daniele.ceraolospurio@intel.com
|
#
f833cdb0 |
|
19-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: dynamically allocate forcewake domains We'd like to introduce a display uncore with no forcewake domains, so let's avoid wasting memory and be ready to allocate only what we need. Even without multiple uncore, we still don't need all the domains on all gens. v2: avoid hidden control flow, improve checks (Tvrtko), fix IVB special case, add failure injection point Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620010021.20637-6-daniele.ceraolospurio@intel.com
|
#
2e81bc61 |
|
19-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: skip forcewake actions on forcewake-less uncore We always call some of the setup/cleanup functions for forcewake, even if the feature is not actually available. Skipping these operations if forcewake is not available saves us some operations on older gens and prepares us for having a forcewake-less display uncore. v2: do not make suspend/resume functions forcewake-specific (Chris, Tvrtko), use GEM_BUG_ON in internal forcewake-only functions (Tvrtko) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620010021.20637-5-daniele.ceraolospurio@intel.com
|
#
01385758 |
|
19-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: kill uncore_to_i915 Let's get rid of it before it proliferates, since with split GT/Display uncores the container_of won't work anymore. I've kept the rpm pointer as well to minimize the pointer chasing in the MMIO accessors. v2: swap parameter order for intel_uncore_init_early (Tvrtko) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620010021.20637-4-daniele.ceraolospurio@intel.com
|
#
19e0a8d4 |
|
19-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: kill uncore_sanitize uncore_sanitize performs no action on the uncore structure and just calls intel_sanitize_gt_powersave, so we can just call the latter directly. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620010021.20637-3-daniele.ceraolospurio@intel.com
|
#
ccb2acea |
|
19-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: use vfuncs for reg_read/write_fw_domains Instead of going through the if-else chain every time, let's save the function in the uncore structure. Note that the new functions are purposely not used from the reg read/write functions to keep the inlining there. While at it, use the new macro to call the old ones to clean the code a bit. v2: Rename macros for no-forcewake function assignment (Tvrtko) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620010021.20637-2-daniele.ceraolospurio@intel.com
|
#
c447ff7d |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: update with_intel_runtime_pm to use the rpm structure Matching the underlying get/put functions. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-8-daniele.ceraolospurio@intel.com
|
#
9102650f |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: make enable/disable rpm assert function use the rpm structure With this all the rpm assert-related functions consistently work on the i915_runtime_pm structure Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-4-daniele.ceraolospurio@intel.com
|
#
87b391b9 |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: Remove rpm asserts that use i915 Quite a few of the call points have already switched to the version working directly on the runtime_pm structure, so let's switch over the rest and kill the i915-based asserts. v2: rebase Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-3-daniele.ceraolospurio@intel.com
|
#
8ed3a623 |
|
10-Jun-2019 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Convert i915_reg_read_ioctl to use explicit mmio accessors No excuse for code located in intel_uncore.c to not use intel_uncore_ helpers. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610120608.15477-2-tvrtko.ursulin@linux.intel.com
|
#
18ecc6c5 |
|
07-May-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reboot CI if forcewake fails If the HW fails to ack a change in forcewake status, the machine is as good as dead -- it may recover, but in reality it missed the mmio updates and is now in a very inconsistent state. If it happens, we can't trust the CI results (or at least the fails may be genuine but due to the HW being dead and not the actual test!) so reboot the machine (CI checks for a kernel taint in between each test and reboots if the machine is tainted). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190508115245.27790-1-chris@chris-wilson.co.uk
|
#
696173b0 |
|
05-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_pm.h from intel_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: gen6_rps_reset_ei() is in i915_irq.c not intel_pm.c. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/adc6463b95eef3440fba9826793f7d1c5f3b0b4a.1554461791.git.jani.nikula@intel.com
|
#
3de6f852 |
|
02-Apr-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: rename init/fini/prune uncore functions Add "_mmio" postfix to be consistent from the init/fini phase they're called from. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.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/20190402201032.15841-2-daniele.ceraolospurio@intel.com
|
#
6cbe8830 |
|
02-Apr-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: add intel_uncore_init_early Encapsulate the uncore early init and be consistent with the "_early" naming. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.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/20190402201032.15841-1-daniele.ceraolospurio@intel.com
|
#
f6ac993f |
|
28-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: move the edram detection out of uncore init edram is not part of uncore and there is no requirement for the detection to be done before we initialize the uncore functions. The first check on HAS_EDRAM is in the ggtt_init path, so move it to i915_driver_init_hw, where other dram-related detection happens. While at it, save the size in MB instead of the capabilities because the size is the only thing we look at outside of the init function. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: 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/20190328174533.31532-1-daniele.ceraolospurio@intel.com
|
#
baba6e57 |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: take a reference to uncore in the engine and use it A few advantages: - Prepares us for the planned split of display uncore from GT uncore - Improves our engine-centric view of the world in the engine code and allows us to avoid jumping back to dev_priv. - Allows us to wrap accesses to engine register in nice macros that automatically pick the right mmio base. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-10-daniele.ceraolospurio@intel.com
|
#
97a04e0d |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: switch intel_wait_for_register to uncore The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-9-daniele.ceraolospurio@intel.com
|
#
d2d551c0 |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: intel_wait_for_register_fw to uncore The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-8-daniele.ceraolospurio@intel.com
|
#
4319382e |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: switch intel_uncore_forcewake_for_reg to intel_uncore The intel_uncore structure is the owner of FW, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-7-daniele.ceraolospurio@intel.com
|
#
a2b4abfc |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: switch uncore mmio funcs to use intel_uncore The full read/write ops can now work on the intel_uncore struct. Introduce intel_uncore_read/write functions working on intel_uncore and switch the I915_READ/WRITE macro to internally call those. v2: no change v3: add intel_uncore_read/write functions (Chris), update commit msg Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-6-daniele.ceraolospurio@intel.com
|
#
eb17af67 |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: take a ref to the rpm in the uncore structure Remove a bit of pointer dancing in the reg access path. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-5-daniele.ceraolospurio@intel.com
|
#
2cf7bf6f |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: add uncore flags for unclaimed mmio Save the HW capabilities to avoid having to jump back to dev_priv every time. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-4-daniele.ceraolospurio@intel.com
|
#
5a0ba777 |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: add HAS_FORCEWAKE flag to uncore We have several cases where we don't have forcewake (older gens, GVT and planned display-only uncore), so, instead of checking every time against the various condition, save the info in a flag and use that. Note that this patch also change the behavior for gen5 with vpgu enabled, but this is not an issue since we don't support vgpu on gen5. v2: split out from previous path, fix check for missing case (Paulo) v3: Inline helper for clarity in testing flags Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-3-daniele.ceraolospurio@intel.com
|
#
6cc5ca76 |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: rename raw reg access functions They now work on uncore, so use raw_uncore_ prefix. Also move them to uncore.h Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-2-daniele.ceraolospurio@intel.com
|
#
6ebc9692 |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: make raw access function work on uncore This allows us to ditch i915 in some more places. v2: use local var in check_vgpu (Paulo) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-9-daniele.ceraolospurio@intel.com
|
#
25286aac |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: move regs pointer inside the uncore structure This will allow futher simplifications in the uncore handling. v2: move register access setup under uncore (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-8-daniele.ceraolospurio@intel.com
|
#
272c7e52 |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: reduce the dev_priv->uncore dance in uncore.c Use a local variable where it makes sense. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-7-daniele.ceraolospurio@intel.com
|
#
cb7ee690 |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: make find_fw_domain work on intel_uncore Remove unneeded usage of dev_priv from 1 extra function. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-6-daniele.ceraolospurio@intel.com
|
#
f7de5027 |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: make more uncore function work on intel_uncore Move the init, fini, prune, suspend, resume function to work on intel_uncore instead of dev_priv. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-5-daniele.ceraolospurio@intel.com
|
#
3ceea6a1 |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: use intel_uncore for all forcewake get/put Now that the internal code all works on intel_uncore, flip the external-facing interface. v2: fix GVT. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-4-daniele.ceraolospurio@intel.com
|
#
f568eeee |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: use intel_uncore in fw get/put internal paths Get/put functions used outside of uncore.c are updated in the next patch for a nicer split. v2: use dev_priv where we still have it (Paulo) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-3-daniele.ceraolospurio@intel.com
|
#
159367bb |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: always use masks on FW regs Upper bits are reserved on gen6, so no issue if we write them. Note that we're already doing this in the non-MT case of IVB, which uses the same register. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.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/20190320122732.14512-1-chris@chris-wilson.co.uk
|
#
535d8d27 |
|
16-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: do not pass dev_priv to low-level forcewake functions The only usage we have for it is for the regs pointer. Save a pointer to the set and ack registers instead of the register offsets to remove this requirement v2: Keep passing uncore down to the lowest levels to avoid repeated pointer chasing in the innermost loops: add/remove: 0/0 grow/shrink: 3/15 up/down: 33/-155 (-122) Function old new delta fw_domain_init 320 351 +31 hdmi_port_clock_valid 319 320 +1 g4x_pre_enable_dp 364 365 +1 ring_request_alloc 1852 1851 -1 intel_engine_lookup_user 50 49 -1 gen11_irq_handler 738 737 -1 __intel_uncore_forcewake_get 115 112 -3 intel_uncore_fw_release_timer 198 194 -4 i915_forcewake_domains 154 150 -4 fw_domain_fini 172 168 -4 __intel_uncore_forcewake_put 163 159 -4 ___force_wake_auto 138 134 -4 fw_domains_put 98 92 -6 __err_print_to_sgl 4058 4052 -6 intel_uncore_forcewake_reset 459 444 -15 fw_domains_get 563 548 -15 fw_domain_wait_ack_with_fallback 490 450 -40 fw_domains_get_with_fallback 875 828 -47 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.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/20190313231319.711-2-daniele.ceraolospurio@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20190316100045.20240-1-chris@chris-wilson.co.uk
|
#
39806c3f |
|
04-Feb-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Include register polling in reg_rw traces We generally omit register polling from the i915_reg_rw tracepoint. Understandable since polling could generate a lot of noise in the trace. The downside is that the trace is incomplete. As a compromise let's trace the final register value observed while polling. That should be generally sufficient to observe what the code should be doing next. I suppose in some cases it might make sense to also trace the initial register value, and maybe the number of times we polled. But that would require a separate tracepoint so let's leave it for the future. The other users of _NOTRACE() are i915_pmu and i2c bitbanging, which I decided to leave alone. Next we should do something to claw back the tracepoints for planes and whatnot which were switched to _FW() a while back. I guess just new macros for raw_rw+trace. The question is what to call it? Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190204211644.21967-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
9f58892e |
|
16-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Pull all the reset functionality together into i915_reset.c Currently the code to reset the GPU and our state is spread widely across a few files. Pull the logic together into a common file. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190116153304.787-1-chris@chris-wilson.co.uk
|
#
d4225a53 |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Syntatic sugar for using intel_runtime_pm Frequently, we use intel_runtime_pm_get/_put around a small block. Formalise that usage by providing a macro to define such a block with an automatic closure to scope the intel_runtime_pm wakeref to that block, i.e. macro abuse smelling of python. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-15-chris@chris-wilson.co.uk
|
#
538ef96b |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gem: Track the rpm wakerefs Keep track of the temporary rpm wakerefs used for user access to the device, so that we can cancel them upon release and clearly identify any leaks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-10-chris@chris-wilson.co.uk
|
#
16e4dd03 |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Markup paired operations on wakerefs The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). For regular builds, the compiler should be able to eliminate the unused local variables and the program growth should be minimal. Fwiw, it came out as a net improvement as gcc was able to refactor rpm_get and rpm_get_if_in_use together, v2: Just s/rpm_put/rpm_put_unchecked/ everywhere, leaving the manual mark up for smaller more targeted patches. v3: Mention the cookie in Returns Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@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/20190114142129.24398-2-chris@chris-wilson.co.uk
|
#
a0f04cc2 |
|
31-Dec-2018 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: always use INTEL_INFO() to access device info Hide the way device info is stored, in preparation of making device info a pointer to the const rodata in i915_pci.c. No functional changes. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3cd626f248c0d6638f1288938bbb577a12286050.1546267488.git.jani.nikula@intel.com
|
#
0258404f |
|
31-Dec-2018 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: start moving runtime device info to a separate struct First move the low hanging fruit, the fields that are only initialized runtime. Use RUNTIME_INFO() exclusively to access the fields. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c24fe7a4b0492a888690c46814c0ff21ce2f12b1.1546267488.git.jani.nikula@intel.com
|
#
f513ac76 |
|
13-Dec-2018 |
Oscar Mateo <oscar.mateo@intel.com> |
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
|
#
f3ce44a0 |
|
12-Dec-2018 |
Lucas De Marchi <lucas.demarchi@intel.com> |
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
|
#
cf819eff |
|
12-Dec-2018 |
Lucas De Marchi <lucas.demarchi@intel.com> |
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
|
#
00690008 |
|
12-Dec-2018 |
Lucas De Marchi <lucas.demarchi@intel.com> |
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
|
#
ac128918 |
|
22-Oct-2018 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: uncore_fw_domains_init sort platforms newer-to-older No functional change. Just sorting this "if" statement from newer to older platform. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181022171526.15641-5-rodrigo.vivi@intel.com
|
#
a167b1e1 |
|
04-Sep-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Pull intel_uncore_arm_unclaimed_mmio_detection() under the spinlock Elsewhere we manipulate uncore.unclaimed_mmio_check and i915_param.mmio_debug under the irq lock (e.g. preserving the current value across a user forcewake grab), but do not protect the manipulation inside intel_uncore_arm_unclaimed_mmio_detection() from concurrent access, even from itself. This is an issue as we do call arm_unclaimed_mmio_detection from multiple threads without coordination. Suggested-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intelcom> Link: https://patchwork.freedesktop.org/patch/msgid/20180904131207.17563-1-chris@chris-wilson.co.uk
|
#
7ef4ac6e |
|
03-Sep-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Double check we didn't miss an unclaimed register access Currently, if the user has enabled mmio-debug around each register access, we presume that we have then checked them all. However, it is still possible through omission (raw register access) or external interaction that the unclaimed access was not highlighted. 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/20180904111732.24266-1-chris@chris-wilson.co.uk
|
#
3af71f64 |
|
08-Aug-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Restore user forcewake domains across suspend On suspend, we cancel the automatic forcewake and clear all other sources of forcewake so the machine can sleep before we do suspend. However, we expose the forcewake to userspace (only via debugfs, but nevertheless we do) and want to restore that upon resume or else our accounting will be off and we may not acquire the forcewake before we use it. So record which domains we cleared on suspend and reacquire them early on resume. v2: Hold the spinlock to appease our sanitychecks v3: s/fw_domains_user/fw_domains_saved/ to convey intent more clearly Reported-by: Imre Deak <imre.deak@linux.intel.com> Fixes: b8473050805f ("drm/i915: Fix forcewake active domain tracking") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Imre Deak <imre.deak@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180808210842.3555-1-chris@chris-wilson.co.uk (cherry picked from commit d60996ab430c8a6033a0944c068edc5ec5becb9b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
f4e60c5c |
|
13-Aug-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Force reset on unready engine If engine reports that it is not ready for reset, we give up. Evidence shows that forcing a per engine reset on an engine which is not reporting to be ready for reset, can bring it back into a working order. There is risk that we corrupt the context image currently executing on that engine. But that is a risk worth taking as if we unblock the engine, we prevent a whole device wedging in a case of full gpu reset. Reset individual engine even if it reports that it is not prepared for reset, but only if we aim for full gpu reset and not on first reset attempt. v2: force reset only on later attempts, readability (Chris) v3: simplify with adequate caffeine levels (Chris) v4: comment about risks and migitations (Chris) 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/20180813130116.7250-1-mika.kuoppala@linux.intel.com
|
#
e02e6500 |
|
10-Aug-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Expose retry count to per gen reset logic There is a possibility for per gen reset logic to be more nasty if the softer approach on resetting does not bear fruit. Expose retry count to per gen reset logic if it wants to take such tough measures. 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/20180810140036.24240-1-mika.kuoppala@linux.intel.com
|
#
d60996ab |
|
08-Aug-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Restore user forcewake domains across suspend On suspend, we cancel the automatic forcewake and clear all other sources of forcewake so the machine can sleep before we do suspend. However, we expose the forcewake to userspace (only via debugfs, but nevertheless we do) and want to restore that upon resume or else our accounting will be off and we may not acquire the forcewake before we use it. So record which domains we cleared on suspend and reacquire them early on resume. v2: Hold the spinlock to appease our sanitychecks v3: s/fw_domains_user/fw_domains_saved/ to convey intent more clearly Reported-by: Imre Deak <imre.deak@linux.intel.com> Fixes: b8473050805f ("drm/i915: Fix forcewake active domain tracking") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Imre Deak <imre.deak@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180808210842.3555-1-chris@chris-wilson.co.uk
|
#
a5b22b5e |
|
19-Jul-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Show stack (by WARN) for hitting forcewake errors On Sandybridge, we need a workaround to wait for the CPU thread to wake up before we are sure that we have enabled the GT power well. However, we do see the errors being reported and failed reads returning spurious results. To try and capture more details as it fails, promote the error into a WARN so we grab the stacktrace, and to try and reduce the frequency of error increase the timeout from 500us to 5ms. 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/20180720111102.11549-1-chris@chris-wilson.co.uk
|
#
39e78234 |
|
07-Jun-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Add WaKBLVECSSemaphoreWaitPoll There is a problem with kbl up to rev E0 where a heavy memory/fabric traffic from adjacent engine(s) can cause an engine reset to fail. This traffic can be from normal memory accesses or it can be from heavy polling on a semaphore wait. For engine hogging causing a fail, we already fallback to full reset. Which effectively stops all engines and thus we only add a workaround documentation. For the semaphore wait loop poll case, we add one microsecond poll interval to semaphore wait to guarantee bandwidth for the reset preration. The side effect is that we make semaphore completion latencies also 1us longer. v2: Let full reset handle the adjacent engine idling (Chris) v3: Skip render engine (Joonas), please checkpatch on define (Mika) References: https://bugs.freedesktop.org/show_bug.cgi?id=106684 References: VTHSD#2227190, HSDES#1604216706, BSID#0917 Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180607172444.17080-1-mika.kuoppala@linux.intel.com
|
#
c30acb04 |
|
05-Jun-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Cancel reset preparations on failed resets Our reset handling has a retry layer further up in the chain. As we have told the engine to prepare for reset, and failed it, make sure to remove that preparation so that the next attempted reset has a clean slate by triggering another full prepare cycle for the engines. v2: ret as int, simplified cleanup (Chris) 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/20180605160357.32591-1-mika.kuoppala@linux.intel.com
|
#
3f6e9822 |
|
16-May-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Stop parking the signaler around reset We cannot call kthread_park() from softirq context, so let's avoid it entirely during the reset. We wanted to suspend the signaler so that it would not mark a request as complete at the same time as we marked it as being in error. Instead of parking the signaling, stop the engine from advancing so that the GPU doesn't emit the breadcrumb for our chosen "guilty" request. v2: Refactor setting STOP_RING so that we don't have the same code thrice Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michałt Winiarski <michal.winiarski@intel.com> CC: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-8-chris@chris-wilson.co.uk
|
#
cc38cae7 |
|
08-May-2018 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/icl: Introduce initial Icelake Workarounds Inherit workarounds from previous platforms that are still valid for Icelake. v2: GEN7_ROW_CHICKEN2 is masked v3: - Since it has been fixed already in upstream, removed the TODO comment about WA_SET_BIT for WaInPlaceDecompressionHang. - Squashed with this patch: drm/i915/icl: add icelake_init_clock_gating() from Paulo Zanoni <paulo.r.zanoni@intel.com> - Squashed with this patch: drm/i915/icl: WaForceEnableNonCoherent from Oscar Mateo <oscar.mateo@intel.com> - WaPushConstantDereferenceHoldDisable is now Wa_1604370585 and applies to B0 as well. - WaPipeControlBefore3DStateSamplePattern WABB was being applied to ICL incorrectly. v4: - Wrap the commit message - s/dev_priv/p to please checkpatch v5: Rebased on top of the WA refactoring v6: Rebased on top of further whitelist registers refactoring (Michel) v7: Added WaRsForcewakeAddDelayForAck v8: s/ICL_HDC_CHICKEN0/ICL_HDC_MODE (Mika) v9: - C, not lisp (Chris) - WaIncreaseDefaultTLBEntries is the same for GEN > 9_LP (Tvrtko) Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-2-git-send-email-oscar.mateo@intel.com
|
#
e34b0345 |
|
05-Apr-2018 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915/icl: Add reset control register changes The bits used to reset the different engines/domains have changed in GEN11, this patch maps the reset engine mask bits with the new bits in the reset control register. v2: Use shift-left instead of BIT macro to match the file style (Paulo). v3: Reuse gen8_reset_engines (Daniele). v4: Do not call intel_uncore_forcewake_reset after reset, we may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. bspec: 19212 Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-1-mika.kuoppala@linux.intel.com
|
#
3df82dd4 |
|
29-Mar-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only warn for might_sleep() before a slow wait_for_register As intel_wait_for_register_fw() may use, and if successful only use, a busy-wait loop, the might_sleep() warning is a little over-zealous. Restrict it to a might_sleep_if() a slow timeout is specified (and so the caller authorises use of a usleep). 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/20180329224519.13598-2-chris@chris-wilson.co.uk
|
#
5807e1c2 |
|
29-Mar-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid sleeping inside per-engine reset Only sleep and repeat when asked for a full device reset (ALL_ENGINES) and avoid using sleeping waits when asked for a per-engine reset. The goal is to be able to use a per-engine reset from hardirq/softirq/timer context. A consequence is that our individual wait timeouts are a thousand times shorter, on the order of a hundred microseconds rather than hundreds of millisecond. This may make hitting the timeouts more common, but hopefully the fallover to the full-device reset will be sufficient to pick up the pieces. Note, that the sleeps inside older gen (pre-gen8) have been left as they are only used in full device reset mode. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> CC: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180329224519.13598-1-chris@chris-wilson.co.uk
|
#
0f36a85c |
|
22-Mar-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Flush pending interrupt following a GPU reset After resetting the GPU (or subset of engines), call synchronize_irq() to flush any pending irq before proceeding with the cleanup. For a device level reset, we disable the interupts around the reset, but when resetting just one engine, we have to avoid such global disabling. This leaves us open to an interrupt arriving for the engine as we try to reset it. We already do try to flush the IIR following the reset, but we have to ensure that the in-flight interrupt does not land after we start cleaning up after the reset; enter synchronize_irq(). As it current stands, we very rarely, but fatally, see sequences such as: 2.... 57964564us : execlists_reset_prepare: rcs0 2.... 57964613us : execlists_reset: rcs0 seqno=424 0d.h1 57964615us : gen8_cs_irq_handler: rcs0 CS active=1 2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- global_seqno 1060 2.... 57964703us : execlists_reset_finish: rcs0 0..s. 57964705us : execlists_submission_tasklet: rcs0 awake?=1, active=0, irq-posted?=1 v2: Move the sync into the execlists reset handler so that we coordinate the flush with disabling the interrupt handling and canceling the pending interrupt. v3: Just use synchronize_hardirq() to avoid the might_sleep(), we do not yet have threaded-irq to worry about. 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: Michał Winiarski <michal.winiarski@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322073533.5313-4-chris@chris-wilson.co.uk Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>
|
#
26376a7e |
|
16-Mar-2018 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/icl: Check for fused-off VDBOX and VEBOX instances In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD) and the Video Enhancement engines (aka VEBOX, aka VECS) could be fused off. Also, each VDBOX and VEBOX has its own power well, which only exist if the related engine exists in the HW. Unfortunately, we have a Catch-22 situation going on: we need the blitter forcewake to read the register with the fuse info, but we cannot initialize the forcewake domains without knowin about the engines present in the HW. We workaround this problem by allowing the initialization of all forcewake domains and then pruning the fused off ones, as per the fuse information. Bspec: 20680 v2: We were shifting incorrectly for vebox disable (Vinay) v3: Assert mmio is ready and warn if we have attempted to initialize forcewake for fused-off engines (Paulo) v4: - Use INTEL_GEN in new code (Tvrtko) - Shorter local variable (Tvrtko, Michal) - Keep "if (!...) continue" style (Tvrtko) - No unnecessary BUG_ON (Tvrtko) - WARN_ON and cleanup if wrong mask (Tvrtko, Michal) - Use I915_READ_FW (Michal) - Use I915_MAX_VCS/VECS macros (Michal) v5: Rebased by Rodrigo fixing conflicts on top of: "drm/i915: Simplify intel_engines_init" v6: Fix v5. Remove info->num_rings. (by Oscar) v7: Rebase (Rodrigo). v8: - s/intel_device_info_fused_off_engines/ intel_device_info_init_mmio (Chris) - Make vdbox_disable & vebox_disable local variables (Chris) v9: - Move function declaration to intel_device_info.h (Michal) - Missing indent in bit fields definitions (Michal) - When RC6 is enabled by BIOS, the fuse register cannot be read until the blitter powerwell is awake. Shuffle where the fuse is read, prune the forcewake domains after the fact and change the commit message accordingly (Vinay, Sagar, Chris). v10: - Improved commit message (Sagar) - New line in header file (Sagar) - Specify the message in fw_domain_reset applies to ICL+ (Sagar) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316121456.11577-1-mika.kuoppala@linux.intel.com [Mika: soothe checkpatch on commit msg] Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
a89a70a8 |
|
02-Mar-2018 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/icl: Gen11 forcewake support The main difference with previous GENs is that starting from Gen11 each VCS and VECS engine has its own power well, which only exist if the related engine exists in the HW. The fallback forcewake request workaround is only needed on gen9 according to the HSDES WA entry (1604254524), so we can go back to using the simpler fw_domains_get/put functions. BSpec: 18331 v2: fix fwtable, use array to test shadow tables, create new accessors to avoid check on every access (Tvrtko) v3 (from Paulo): Rebase. v4: - Range 09400-097FF should be FORCEWAKE_ALL (Daniele) - Use the BIT macro for forcewake domains (Daniele) - Add a comment about the range ordering (Oscar) - Updated commit message (Oscar) v5: Rebased v6: Use I915_MAX_VCS/VECS (Michal) v7: translate FORCEWAKE_ALL to available domains v8: rebase, add clarification on fallback ack in commit message. v9: fix rebase issue, change check in fw_domains_init from IS_GEN11 to GEN >= 11 v10: Generate is_genX_shadowed with a macro (Daniele) Include gen11_fw_ranges in the selftest (Michel) v11: Simplify FORCEWAKE_ALL, new line between NEEDS_FORCEWAKEs (Tvrtko) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-6-mika.kuoppala@linux.intel.com Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
c56b89f1 |
|
09-Feb-2018 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Use INTEL_GEN everywhere Coccinelle patch: @@ identifier p; @@ -INTEL_INFO(p)->gen +INTEL_GEN(p) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180208130606.15556-12-tvrtko.ursulin@linux.intel.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/20180209215847.6660-1-chris@chris-wilson.co.uk
|
#
a1ab7dcf |
|
07-Feb-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Wait for gen3 reset status to be asserted After we assert the reset request (and wait for 20us), when the device has been fully reset it asserts the reset-status bit. Before we stop requesting the reset and allow the device to return to normal, we should wait for the reset to be completed. (Similar to how we wait for the device to return to normal after deasserting the reset request.) v2: Rename i915_reset_completed() probe to not cause as much confusion. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180207222824.29864-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
bc8f2f5d |
|
08-Feb-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Be paranoid and post the writes to stop the rings Although the mmio are uncached and so should be flushed on every write, be paranoid and do a mmio read after setting the ring head/tail to be sure they have taken effect before moving on. v2: post tail to be pleasing to the eye 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> Link: https://patchwork.freedesktop.org/patch/msgid/20180208072800.595-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
164daaf2 |
|
30-Jan-2018 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/icl: allow the reg_read ioctl to read the RCS TIMESTAMP register This enables the Mesa driver to advertise support for ARB_timer_query, and thus an OpenGL version higher than 3.2. Based on the CNL patch by Nanley Chery. v2: Rebase. Cc: Anuj Phogat <anuj.phogat@intel.com> Cc: Nanley Chery <nanley.g.chery@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Requested-by: Anuj Phogat <anuj.phogat@intel.com> Tested-by: Anuj Phogat <anuj.phogat@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-10-paulo.r.zanoni@intel.com
|
#
23fdbdd7 |
|
08-Jan-2018 |
Sean Paul <seanpaul@chromium.org> |
drm/i915: Add more control to wait_for routines This patch adds a little more control to a couple wait_for routines such that we can avoid open-coding read/wait/timeout patterns which: - need the value of the register after the wait_for - run arbitrary operation for the read portion This patch also chooses the correct sleep function (based on timers-howto.txt) for the polling interval the caller specifies. Changes in v2: - Added to the series Changes in v3: - Rebased on drm-intel-next-queued and the new Wmin/max _wait_for - Removed msleep option Changes in v4: - Removed ; for OP in _wait_for (Chris) - Moved reg_value definition above ret (Chris) Changes in v4: - checkpatch whitespace fix Changes in v5: - None Changes in v6: - None Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-3-seanpaul@chromium.org
|
#
6f25d0be |
|
02-Jan-2018 |
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> |
drm/i915/guc : GEM_BUG_ON on invoking GuC reset function Instead of returning -EINVAL, GEM_BUG_ON when GuC reset is invoked for platforms not supporting as we don't expect to invoke it. v2: re-wording commit message and subject (Sagar) Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1514928025-29659-2-git-send-email-sujaritha.sundaresan@intel.com
|
#
fb6db0f5 |
|
01-Dec-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove unsafe i915.enable_rc6 It has been many years since the last confirmed sighting (and fix) of an RC6 related bug (usually a system hang). Remove the parameter to stop users from setting dangerous values, as they often set it during triage and end up disabling the entire runtime pm instead (the option is not a fine scalpel!). Furthermore, it allows users to set known dangerous values which were intended for testing and not for production use. For testing, we can always patch in the required setting without having to expose ourselves to random abuse. v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document the lack of ilk support better. v3: Clear intel_info->rc6p if we don't support rc6 itself. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171201113030.18360-1-chris@chris-wilson.co.uk
|
#
294cf1af |
|
14-Nov-2017 |
Hans de Goede <j.w.r.degoede@gmail.com> |
drm/i915: Re-register PMIC bus access notifier on runtime resume intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier and call that on runtime resume. Cc: stable@vger.kernel.org Reported-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com (cherry picked from commit bedf4d79c3654921839b62246b0965ddb308b201) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
f4359ced |
|
10-Nov-2017 |
Hans de Goede <j.w.r.degoede@gmail.com> |
drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(kdev); pm_runtime_put_autosuspend(kdev); And pm_runtime_put_autosuspend calls intel_runtime_suspend from a workqueue, so there is ample of time between the atomic_dec() and intel_runtime_suspend() unregistering the notifier. If the notifier gets called in this windowd assert_rpm_wakelock_held falsely triggers (at this point we're not runtime-suspended yet). This commit adds disable_rpm_wakeref_asserts and enable_rpm_wakeref_asserts calls around the intel_uncore_forcewake_get(FORCEWAKE_ALL) call in i915_pmic_bus_access_notifier fixing the false-positive WARN_ON. Changes in v2: -Reword comment explaining why disabling the wakeref asserts is ok and necessary Cc: stable@vger.kernel.org Reported-by: FKr <bugs-freedesktop@ubermail.me> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com (cherry picked from commit ce30560c80dead91e98a03d90fb8791e57a9b69d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
bedf4d79 |
|
14-Nov-2017 |
Hans de Goede <j.w.r.degoede@gmail.com> |
drm/i915: Re-register PMIC bus access notifier on runtime resume intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier and call that on runtime resume. Cc: stable@vger.kernel.org Reported-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
|
#
ce30560c |
|
10-Nov-2017 |
Hans de Goede <j.w.r.degoede@gmail.com> |
drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(kdev); pm_runtime_put_autosuspend(kdev); And pm_runtime_put_autosuspend calls intel_runtime_suspend from a workqueue, so there is ample of time between the atomic_dec() and intel_runtime_suspend() unregistering the notifier. If the notifier gets called in this windowd assert_rpm_wakelock_held falsely triggers (at this point we're not runtime-suspended yet). This commit adds disable_rpm_wakeref_asserts and enable_rpm_wakeref_asserts calls around the intel_uncore_forcewake_get(FORCEWAKE_ALL) call in i915_pmic_bus_access_notifier fixing the false-positive WARN_ON. Changes in v2: -Reword comment explaining why disabling the wakeref asserts is ok and necessary Cc: stable@vger.kernel.org Reported-by: FKr <bugs-freedesktop@ubermail.me> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
|
#
ce453b3e |
|
10-Nov-2017 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915: Clear per-engine fault register as early as possible From gen6, the hardware tracks address lookup failures and we should clear those registers upon startup to prevent false positives. However, this was happening before we have the engines defined (intel_uncore_init()) and the for_each_engine loop was just a nop. The earliest we can call this is inside intel_engines_init_mmio(). Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171111004448.12360-1-michel.thierry@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
a5266db4 |
|
19-Oct-2017 |
Hans de Goede <j.w.r.degoede@gmail.com> |
drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset() intel_uncore_forcewake_reset() does forcewake puts and gets as such we need to make sure that no-one tries to access the PUNIT->PMIC bus (on systems where this bus is shared) while it runs, otherwise bad things happen. Normally this is taken care of by the i915_pmic_bus_access_notifier() which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other driver tries to access the PMIC bus, so that later forcewake gets are no-ops (for the duration of the bus access). But intel_uncore_forcewake_reset gets called in 3 cases: 1) Before registering the pmic_bus_access_notifier 2) After unregistering the pmic_bus_access_notifier 3) To reset forcewake state on a GPU reset In all 3 cases the i915_pmic_bus_access_notifier() protection is insufficient. This commit fixes this race by calling iosf_mbi_punit_acquire() before calling intel_uncore_forcewake_reset(). In the case where it is called directly after unregistering the pmic_bus_access_notifier, we need to hold the punit-lock over both calls to avoid a race where intel_uncore_fw_release_timer() may execute between the 2 calls. Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019111620.26761-3-hdegoede@redhat.com
|
#
71306303 |
|
02-Nov-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Use fallback forcewake if primary ack missing There is a possibility on gen9 hardware to miss the forcewake ack message. The recommended workaround is to use another free bit and toggle it until original bit is successfully acknowledged. Some future gen9 revs might or might not fix the underlying issue but using fallback forcewake bit dance can be considered as harmless: without the ack timeout we never reach the fallback bit forcewake. Thus as of now we adopt a blanket approach for all gen9 and leave the bypassing the fallback bit approach for future patches if corresponding hw revisions do appear. Commit 83e3337204b2 ("drm/i915: Increase maximum polling time to 50ms for forcewake request/clear ack") did increase the forcewake timeout. If the issue was a delayed ack, future work could include finding a suitable timeout value both for primary ack and reserve toggle to reduce the worst case latency. v2: use bit 15, naming, comment (Chris), only wait fallback ack v3: fix return on fallback, backoff after fallback write (Chris) v4: udelay on first pass, grammar (Chris) v4: s/reserve/fallback References: HSDES #1604254524 References: https://bugs.freedesktop.org/show_bug.cgi?id=102051 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> 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/20171102094836.2506-1-mika.kuoppala@linux.intel.com
|
#
6acbea89 |
|
31-Oct-2017 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915/guc: Add support for reset engine using GuC commands This patch adds per engine reset and recovery (TDR) support when GuC is used to submit workloads to GPU. In the case of i915 directly submission to ELSP, driver manages hang detection, recovery and resubmission. With GuC submission these tasks are shared between driver and GuC. i915 is still responsible for detecting a hang, and when it does it only requests GuC to reset that Engine. GuC internally manages acquiring forcewake and idling the engine before resetting it. Once the reset is successful, i915 takes over again and handles the resubmission. The scheduler in i915 knows which requests are pending so after resetting a engine, pending workloads/requests are resubmitted again. v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the non-guc function names. v3: Removed debug message about engine restarting from which request, since the new baseline do it regardless of submission mode. (Chris) v4: Rebase. v5: Do not pass unnecessary reporting flags to the fw (Jeff); tasklet_schedule(&execlists->irq_tasklet) handles the resubmit; rebase. v6: Rename the existing reset engine function and share a similar interface between guc and non-guc paths (Chris). Signed-off-by: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171031225309.10888-1-michel.thierry@intel.com Reviewed-by: Jeff McGee <jeff.mcgee@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
cb20a3c0 |
|
30-Oct-2017 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915/guc: Rename the function that resets the GuC intel_guc_reset sounds more like the microcontroller is the one performing a reset, while in this case is the opposite. intel_reset_guc not only makes it clearer, it follows the other intel_reset functions available. v2: Print error message in English (Tvrtko). Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171030185616.32836-2-michel.thierry@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
11caf551 |
|
27-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Empty the ring before disabling An interesting snippet from Sandybridge's prm: "Although a Ring Buffer can be enabled in the non-empty state, it must not be disabled unless it is empty. Attempting to disable a Ring Buffer in the non-empty state is UNDEFINED." Let's avoid the undefined behaviour as we disable the rings prior to reset and resume. v2: Tell HEAD to catch up to TAIL (empty ring) first, then reset both to 0 (supposedly while stopped). 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/20171027094311.30380-1-chris@chris-wilson.co.uk
|
#
5896a5c8 |
|
13-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Always stop the rings before a missing GPU reset Always try to stop the rings, even if the GPU reset itself has been disabled (via modparam i915.reset). This should at least stop the hw from spinning in the background consuming resources (e.g. power and memory bandwidth) letting the system rest-in-peace. References: https://bugs.freedesktop.org/show_bug.cgi?id=103260 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171013131218.18013-2-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
67e64564 |
|
08-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Provide an assert for when we expect forcewake to be held Add assert_forcewakes_active() (the complementary function to assert_forcewakes_inactive) that documents the requirement of a function for its callers to be holding the forcewake ref (i.e. the function is part of a sequence over which RC6 must be prevented). One such example is during ringbuffer reset, where RC6 must be held across the whole reinitialisation sequence. v2: Include debug information in the WARN so we know which fw domain is missing. 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> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20171009110301.21705-5-chris@chris-wilson.co.uk
|
#
4f044a88 |
|
19-Sep-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Rename global i915 to i915_modparams Our global struct with params is named exactly the same way as new preferred name for the drm_i915_private function parameter. To avoid such name reuse lets use different name for the global. v5: pure rename v6: fix Credits-to: Coccinelle @@ identifier n; @@ ( - i915.n + i915_modparams.n ) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170919193846.38060-1-michal.wajdeczko@intel.com
|
#
87de8d56 |
|
19-Sep-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Stop engines before reset On kbl evidence indicates that even if the hardware happily tells us to proceed with reset, it really isn't ready. Resetting a freely running batchbuffer after we have ack for readiness, still can cause a system hang. We also have similar experiences on older gens. So now attempt to stop engines before proceeding for reset, on all gens where we have a gpu reset. This has shown to improve reset reliability and reduce the risk of losing the machine. v2: Add fixme for wa (Joonas) Testcase: igt/prime_busy/hang-* # kbl Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170919144128.25506-1-mika.kuoppala@intel.com
|
#
3fd3a6ff |
|
13-Sep-2017 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
drm/i915: Simplify i915_reg_read_ioctl Convert to use the freshly available made INTEL_GEN_MASK for easier grepping and improve function readability and clarify the UABI documentation. No functional changes. v2: - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) - Retain -EINVAL on bad flags behavior (Chris) v3: - Extract flags with 'entry->size - 1' (Chris) v4: - Add GEM_BUG_ON on for flags vs entry offset (Chris) v5: - Use 'u16' to match 'dev_priv' (Ville) v6: - Fix checkpatch.pl errors Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170913115255.13851-2-joonas.lahtinen@linux.intel.com
|
#
d7a133d8 |
|
07-Sep-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Disable mmio debugging during user access If the user bypasses i915 and accesses mmio directly, that easily confuses our automatic mmio debugging (any error we then detect is likely to be as a result of the user). Since we expect userspace to open debugfs/i915_forcewake_user if i915.ko is loaded and they want mmio access, that makes the opportune time to disable our debugging for duration of the bypass. v2: Move the fiddling of uncore internals to uncore.c References: https://bugs.freedesktop.org/show_bug.cgi?id=102543 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/20170907134441.12881-1-chris@chris-wilson.co.uk
|
#
f1294585 |
|
05-Sep-2017 |
Nanley Chery <nanley.g.chery@intel.com> |
drm/i915/cnl: Allow the reg_read ioctl to read the RCS TIMESTAMP register This enables the Mesa driver to advertise support for ARB_timer_query, and thus an OpenGL version higher than 3.2. Suggested-by: Ben Widawsky <ben@bwidawsk.net> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Nanley Chery <nanley.g.chery@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/20170905184507.30046-1-nanley.g.chery@intel.com
|
#
4055dc75 |
|
17-Aug-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Stop touching forcewake following a gen6+ engine reset Forcewake is not affected by the engine reset on gen6+. Indeed the reason why we added intel_uncore_forcewake_reset() to gen6_reset_engines() was to keep the bookkeeping intact because the reset did not touch the forcewake bit (yet we cancelled the forcewake consumers)! This was done in commit 521198a2e7095: Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. That futzing of the forcewake bookkeeping was dropped in commit 0294ae7b44bb ("drm/i915: Consolidate forcewake resetting to a single function"), but it did not make the realisation that the remaining intel_uncore_forcewake_reset() was redundant. The new danger with using intel_uncore_forcewake_reset() with per-engine resets is that the driver and hw are still in an active state as we perform the reset. We may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. Reported-by: Michel Thierry <michel.thierry@intel.com> Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang recovery") 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> Link: https://patchwork.freedesktop.org/patch/msgid/20170817173229.20324-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
3d16ca58 |
|
05-Jul-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Add force wake for gen10+. By spec there is no change on force wake registers for Cannonlake. Let's reuse gen9 one. v2: Adding missing case for the write part. (Tvrtko) v3: Rebase on recent tree. v4: Make it for gen9+ instead adding gen10 only. (by Joonas). Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499302831-17773-1-git-send-email-rodrigo.vivi@intel.com
|
#
142bc7d9 |
|
20-Jun-2017 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915: Modify error handler for per engine hang recovery This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function where applicable (which fails at this point because core implementation is lacking) and continue recovery using legacy full gpu reset. A helper function is also added to query the availability of engine reset. A subsequent patch will add the capability to query which type of reset is present (engine -> full -> no-reset) via the get-param ioctl. It has been decided that the error events that are used to notify user of reset will only be sent in case if full chip reset. In case of just single (or multiple) engine resets, userspace won't be notified by these events. Note that this implementation of engine reset is for i915 directly submitting to the ELSP, where the driver manages the hang detection, recovery and resubmission. With GuC submission these tasks are shared between driver and firmware; i915 will still responsible for detecting a hang, and when it does it will have to request GuC to reset that Engine and remind the firmware about the outstanding submissions. This will be added in different patch. v2: rebase, advertise engine reset availability in platform definition, add note about GuC submission. v3: s/*engine_reset*/*reset_engine*/. (Chris) Handle reset as 2 level resets, by first going to engine only and fall backing to full/chip reset as needed, i.e. reset_engine will need the struct_mutex. v4: Pass the engine mask to i915_reset. (Chris) v5: Rebase, update selftests. v6: Rebase, prepare for mutex-less reset engine. v7: Pass reset_engine mask as a function parameter, and iterate over the engine mask for reset_engine. (Chris) v8: Use i915.reset >=2 in has_reset_engine; remove redundant reset logging; add a reset-engine-in-progress flag to prevent concurrent resets, and avoid dual purposing of reset-backoff. (Chris) v9: Support reset of different engines in parallel (Chris) v10: Handle reset-engine flag locking better (Chris) v11: Squash in reporting of per-engine-reset availability. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Ian Lister <ian.lister@intel.com> Signed-off-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-4-michel.thierry@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-5-chris@chris-wilson.co.uk
|
#
d8197317 |
|
23-May-2017 |
Kai Chen <kai.chen@intel.com> |
drm/i915: Remove decoupled MMIO code This is a follow-up patch to the previous patch ([PATCH[1/2] drm/i915: Disable decoupled MMIO) to remove the dead code for decoupled MMIO implementation, as it won't be used any longer on GEN9LP. Therefore, this patch reverts: commit 85ee17ebeedd1af0dccd98f82ab4e644e29d84c0 Author: Praveen Paneri <praveen.paneri@intel.com> Date: Tue Nov 15 22:49:20 2016 +0530 drm/i915/bxt: Broxton decoupled MMIO Signed-off-by: Kai Chen <kai.chen@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170523215812.18328-3-kai.chen@intel.com
|
#
c9e0c6da |
|
26-May-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Keep the forcewake timer alive for 1ms past the most recent use Currently the timer is armed for 1ms after the first use and is killed immediately, dropping the forcewake as early as possible. However, for very frequent operations the forcewake dance has a large impact on latency and keeping the timer alive until we are idle is preferred. To achieve this, if we call intel_uncore_forcewake_get whilst the timer is alive (repeated use), then set a flag to restart the timer on expiry rather than drop the forcewake usage count. The timer is racy, the consequence of the race is to expire the timer earlier than is now desired but does not impact on correct behaviour. The offset the race slightly, we set the active flag again on intel_uncore_forcewake_put. The effect should be to reduce the jitter of reacquiring the fw every 1ms on a busy system. However, the cost is to keep the timer alive for an extra 1ms on a nearly idle system. We chose to incur the jitter previously to keep the timer off for as much as possible. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170526132209.14640-1-chris@chris-wilson.co.uk
|
#
48f1fc3a |
|
21-May-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/g33: Improve reset reliability We improved the reset reliablity on gen4 with stopping all engines before commencing reset, in commit 2c80353f3cd0 ("drm/i915/g4x: Improve gpu reset reliability") Evidence indicates that this same trick works with g33. v2: proper gen naming, comment readability (Chris) Testcase: igt/gem_busy/*-hang #blb-e6850 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170522090244.2557-1-mika.kuoppala@intel.com
|
#
2c80353f |
|
18-May-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/g4x: Improve gpu reset reliability ELK seems to very picky about the preconditions to reset. Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does not like if reset occurs when there is active ring. Ville found out that there is workaround with name 'WaMediaResetMainRingCleanup' which suggests that we need to cleanup rings before resetting. It is unclear what cleanup exactly means but evidence shows that stopping the ring does have an effect on reset reliability. This patch makes reset successful on hangs induced by chained batches (the igt ones). Note that if the hang is inside a shader, it is possible that our attempts to stop the ring achieves anything. v2: zero ctl,head,tail also. bug ref. use driver debugs (Chris) v3: specify platform on testcases, comment tidyup (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100942 Testcase: igt/gem_busy/*-hang #elk Testcase: igt/gem_ringfill/hang-* #elk Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170519091340.21439-1-mika.kuoppala@intel.com
|
#
44e1e7ba |
|
18-May-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reorder media/render reset on g4x Ville found a reference to WaMediaResetBeforeFullReset which we presume means that we should simply do the media reset first. References: https://bugs.freedesktop.org/show_bug.cgi?id=100942 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170518204811.7408-2-chris@chris-wilson.co.uk
|
#
9593a657 |
|
18-May-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Try harder to reset the GPU Repeat the reset a couple of times if at first we do not succeed. v2: differentiate which path/engine failed with a debug message Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170513083726.502-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170518204811.7408-1-chris@chris-wilson.co.uk
|
#
ff26ffa8 |
|
10-May-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fix __intel_wait_for_register_fw to not sleep in atomic The unconditionally fallback to the blocking wait_for resulted in impressive fireworks at boot-up on my snb here. Make sure if we set the slow timeout to 0 that we never ever sleep. The tail of the callchain was intel_wait_for_register -> __intel_wait_for_register_fw -> usleep_range -> BOOM It blew up in intel_crt_detect load detection code on the ADPA_CRT_HOTPLUG_FORCE_TRIGGER in the ADPA register. v2: Shut up gcc. v3: Use uninitialized_var() (Chris). Fixes: 0564654340e2 ("drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1494429572-15118-1-git-send-email-daniel.vetter@ffwll.ch
|
#
16586fcd |
|
09-May-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Move uncore definitions into a separate header In order to allow use of e.g. forcewake_domains in a other feature headers included from the top of i915_drv.h, move all uncore related definitions into their own header. v2: move __mask_next_bit macro to utils header (Mika) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
6b07b6d2 |
|
02-May-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Use wait_for_atomic_us when waiting for gt fifo Replace the handcrafter loop when checking for fifo slots with atomic wait for. This brings this wait in line with the other waits on register access. We also get a readable timeout constraint, so make it to fail after 10ms. Chris suggested that we should fail silently as the fifo debug handler, now attached to unclaimed mmio handling, will take care of the possible errors at later stage. Note that the decision to wait was changed so that we avoid allocating the first reserved entry. Nor do we reduce the count if we fail the wait, removing the possiblity to wrap the count if the hw fifo returned zero. v2: remove unclaimed check on timeout (Chris) v3: use void return (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=100247 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1491493182-31540-1-git-send-email-mika.kuoppala@intel.com
|
#
a338908c |
|
06-Apr-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Move the GTFIFODBG to the common mmio dbg framework Remove the per-mmio checking of the FIFO debug register into the common conditional mmio debug handling. Based on patch from Chris Wilson. v2: postpone warn on fifodbg for unclaimed reg debugs Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
a3662830 |
|
12-Apr-2017 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915/guc: Fix sleep under spinlock during reset Looks like intel_guc_reset had the ability to sleep under the uncore spinlock since forever but it wasn't detected until the recent changes annotated the wait for register with might_sleep. I have fixed it by removing holding of the uncore spinlock over the call to gen6_hw_domain_reset, since I do not see that is really needed. But there is always a possibility I am missing some nasty detail so please double check. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Acked-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
e3895af8 |
|
18-Apr-2017 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915: Rename gen8_(un)request_engine_reset to gen8_reset_engine_start/cancel As all other functions related to resetting engines are using reset_engine. v2: remove _request_ and use start/cancel instead (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170418202335.35232-3-michel.thierry@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
0757ac8f |
|
12-Apr-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Add stub mmio read/write routines to mock device Provide dummy function pointers for the mock device in case we do hit mmio during testing. v2: Use ASSIGN_READ/WRITE_MMIO_FUNCS macros Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170412092143.3822-1-chris@chris-wilson.co.uk
|
#
05646543 |
|
11-Apr-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register() We acquire the forcewake and use I915_READ_FW instead for the atomic wait within intel_uncore_wait_for_register. However, this still leaves us vulnerable to concurrent mmio access to the register, which can cause system hangs on gen7. The protection is to acquire uncore.lock around each register, so lets add it back. v2: Wrap __intel_wait_for_register_fw() to re-use its atomic wait_for loop and spare adding another for ourselves. v3: Add might_sleep() annotation Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170411101340.31994-3-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
84d84cb7 |
|
10-Apr-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() Allow the caller to use the fast_timeout_us to specify how long to wait within the atomic section, rather than transparently switching to a sleeping loop for larger values. This is required as some callsites may need a long wait and are in an atomic section. v2: Reinforce kerneldoc fast_timeout_us limit with a GEM_BUG_ON Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170411112705.12656-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
6976e74b |
|
09-Apr-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Don't allow overuse of __intel_wait_for_register_fw() This function should not be called with long timeouts in atomic context. Annotate it as might_sleep if timeout is longer than 10us. v2: fix comment (Michal) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170410121747.209200-1-michal.wajdeczko@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3fc7d86b |
|
10-Apr-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Drop const qualifiers from params in wait_for_register() These params are passed by value, const qualifiers are ignored any way. While around, unify timeout_ms type from long to int. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170410093817.151280-1-michal.wajdeczko@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
1d1a9774 |
|
07-Apr-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Extend intel_wait_for_register_fw() with fast timeout In some cases we may want to spend more time in atomic wait than hardcoded 2us. Let's add additional fast timeout parameter to allow flexible configuration of atomic timeout before switching into heavy wait. Add also possibility to return registry value to avoid extra read. v2: use explicit fast timeout (Tvrtko/Chris) allow returning register value (Chris) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170407160145.181328-1-michal.wajdeczko@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
d769ab18 |
|
07-Apr-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Fix type of timeout_ms parameter in intel_wait_for_register_fw() There is no need to specify timeout as unsigned long since this parameter will be consumed by usecs_to_jiffies() which expects unsigned int only. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170407133212.174608-1-michal.wajdeczko@intel.com Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
6e3955a5 |
|
23-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: All fw_domains share the same set/clear/reset values Since we reuse the same values for each fw_domain, move them onto uncore. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-6-chris@chris-wilson.co.uk
|
#
0f966aaf |
|
23-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove posting-read for forcewake put We can relax the requirement upon ourselves that the forcewake is released immediately and just allow it to occur naturally following our mmio request. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-5-chris@chris-wilson.co.uk
|
#
d2dc94bc |
|
23-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Skip unused fw_domains Use find-first-set bitop to quickly scan through the fw_domains mask and skip iterating over unused domains. v2: Move the WARN into the caller, to prevent compiler warnings in normal builds. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-4-chris@chris-wilson.co.uk
|
#
cb3600db |
|
23-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use correct fw_domains during reset In the next patch we will begin to sanity check that we do not attempt to obtain the forcewake on an unsupport domain. However, that is exactly what we do during reset of the fw_domains - rectify it before it explodes. 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: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-3-chris@chris-wilson.co.uk
|
#
bd527504 |
|
23-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use correct fw_domains during initialisation In the next patch we will begin to sanity check that we do not attempt to obtain the forcewake on an unsupport domain. However, that is exactly what we do during our actual initialisation of fw_domains - rectify it before it explodes. 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: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-2-chris@chris-wilson.co.uk
|
#
577ac4bd |
|
23-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Eliminate per-fw_domain i915 backpointer Pass along the drm_i915_private pointer from the caller, rather than looking it up from each fw_domain during fw_domains_get/_put. This allows us to then eliminate the backpointer, in exchange for a more complicated unwrapping procedure in the rare intel_uncore_fw_release_timer(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-1-chris@chris-wilson.co.uk
|
#
e3b1895f |
|
10-Mar-2017 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915/vgpu: Neuter forcewakes for VGPU more thoroughly If we avoid initializing forcewake domains when running as a guest, and also use gen2 mmio accessors in that case, we can avoid the timer traffic and any looping through the forcewake code which is currently just so it can end up in the no-op forcewake implementation. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Weinan Li <weinan.z.li@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Terrence Xu <terrence.xu@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170310095747.12258-1-tvrtko.ursulin@linux.intel.com [tursulin: commit spelling fix]
|
#
6aef6603 |
|
10-Mar-2017 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Fix forcewake active domain tracking In commit 003342a50021 ("drm/i915: Keep track of active forcewake domains in a bitmask") I forgot to adjust the newly introduce fw_domains_active state across reset. This caused the assert_forcewakes_inactive to trigger during suspend and resume if there were user held forcewakes. v2: Bitmask checks are required since vfuncs are not always present. v3: Move bitmask tracking to get/put vfunc for simplicity. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 003342a50021 ("drm/i915: Keep track of active forcewake domains in a bitmask") Testcase: igt/drv_suspend/forcewake Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: "Paneri, Praveen" <praveen.paneri@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: v4.10+ <stable@vger.kernel.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170310093249.4484-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit b8473050805f35add97f3ff57570d55a01808df5) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
b8473050 |
|
10-Mar-2017 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Fix forcewake active domain tracking In commit 003342a50021 ("drm/i915: Keep track of active forcewake domains in a bitmask") I forgot to adjust the newly introduce fw_domains_active state across reset. This caused the assert_forcewakes_inactive to trigger during suspend and resume if there were user held forcewakes. v2: Bitmask checks are required since vfuncs are not always present. v3: Move bitmask tracking to get/put vfunc for simplicity. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 003342a50021 ("drm/i915: Keep track of active forcewake domains in a bitmask") Testcase: igt/drv_suspend/forcewake Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: "Paneri, Praveen" <praveen.paneri@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: v4.10+ <stable@vger.kernel.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170310093249.4484-1-tvrtko.ursulin@linux.intel.com
|
#
67520415 |
|
02-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: s/assert_spin_locked/lockdep_assert_held/ assert_spin_locked() becomes an unconditionally compiled BUG_ON(), adding debug code right into the heart of critical routines like interrupt handlers. text data bss dec hex 1296480 19944 2272 1318696 141f28 before (lockdep disabled) 1295984 19944 2272 1318200 141d38 after 1336261 21139 3208 1360608 14c2e0 before (lockdep enabled) 1339920 21139 3208 1364267 14d12b after Small saving for release; hopefully more instructive in debug. 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170302132801.599-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
264ec1a8 |
|
10-Feb-2017 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: Listen for PMIC bus access notifications Listen for PMIC bus access notifications and get FORCEWAKE_ALL while the bus is accessed to avoid needing to do any forcewakes, which need PMIC bus access, while the PMIC bus is busy: This fixes errors like these showing up in dmesg, usually followed by a gfx or system freeze: [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request. [drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake ack request. i2c_designware 808622C1:06: punit semaphore timed out, resetting i2c_designware 808622C1:06: PUNIT SEM: 2 i2c_designware 808622C1:06: couldn't acquire bus ownership Downside of this approach is that it causes wakeups whenever the PMIC bus is accessed. Unfortunately we cannot simply wait for the PMIC bus to go idle when we hit a race, as forcewakes may be done from interrupt handlers where we cannot sleep to wait for the i2c PMIC bus access to finish. Note that the notifications and thus the wakeups will only happen on baytrail / cherrytrail devices using PMICs with a shared i2c bus for P-Unit and host PMIC access (i2c busses with a _SEM method in their APCI node), e.g. an axp288 PMIC. I plan to write some patches for drivers accessing the PMIC bus to limit their bus accesses to a bare minimum (e.g. cache registers, do not update battery level more often then 4 times a minute), to limit the amount of wakeups. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: tagorereddy <tagore.chandan@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Wiggle in conflicts.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
68f60946 |
|
10-Feb-2017 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: Add intel_uncore_suspend / resume functions Rename intel_uncore_early_sanitize to intel_uncore_resume, dropping the (always true) restore_forcewake argument and add a new intel_uncore_resume function to replace the intel_uncore_forcewake_reset(dev_priv, false) calls done from the suspend / runtime_suspend functions and make intel_uncore_forcewake_reset private. This is a preparation patch for adding PMIC bus access notifier support. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: tagorereddy <tagore.chandan@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170210102802.20898-12-hdegoede@redhat.com
|
#
26e7a2a1 |
|
13-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move uncore selfchecks to live selftest infrastructure Now that the kselftest infrastructure exists, put it to use and add to it the existing consistency checks on the fw register lookup tables. v2: s/tabke/table/ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170213171558.20942-22-chris@chris-wilson.co.uk
|
#
ccfceda2 |
|
03-Feb-2017 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: refactor register fw read/write macros for recent GENs The only difference for the more recent of those macros is the version of the *_reg_<read/write>_fw_domains function. Passing the function prefix in allows us to re-use the same macro to generate functions for different GENs and will make it easier to add new accessors in the future Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1486171409-21542-1-git-send-email-daniele.ceraolospurio@intel.com Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
9b51b105 |
|
25-Jan-2017 |
Weinan Li <weinan.z.li@intel.com> |
drm/i915: clean up unused vgpu_read/write Having converted the force_wake_get/_put routines for a vGPU to be no-op, we can use the common mmio accessors and remove our specialised routines that simply skipped the calls to control force_wake. Signed-off-by: Weinan Li <weinan.z.li@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1485408228-12932-1-git-send-email-weinan.z.li@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
517f188c |
|
25-Jan-2017 |
Weinan Li <weinan.z.li@intel.com> |
drm/i915: noop forcewake get/put when vgpu activated For a virtualized GPU, the host maintains the forcewake state on the real device. As we don't control forcewake ourselves, we can simply set force_wake_get() and force_wake_put() to be no-ops. By setting the vfuncs, we adjust both the manual control of forcewake and around the mmio accessors (making our vgpu specific mmio routines redundant and to be removed in the next patch). Signed-off-by: Weinan Li <weinan.z.li@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1485408013-12780-1-git-send-email-weinan.z.li@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
8b0e1953 |
|
24-Dec-2016 |
Thomas Gleixner <tglx@linutronix.de> |
ktime: Cleanup ktime_set() usage ktime_set(S,N) was required for the timespec storage type and is still useful for situations where a Seconds and Nanoseconds part of a time value needs to be converted. For anything where the Seconds argument is 0, this is pointless and can be replaced with a simple assignment. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org>
|
#
99191427 |
|
07-Dec-2016 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
drm/i915: Catch non-existent registers in find_fw_domain Add WARN_ON to find_fw_domain to registers related to uninitialized hardware. v2: - Print the uninitialized domains and register (Chris) Cc: Imre Deak <imre.deak@intel.com> Cc: Wang Elaine <elaine.wang@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1481120559-17413-1-git-send-email-joonas.lahtinen@linux.intel.com
|
#
73f67aa8 |
|
07-Dec-2016 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: distinguish G33 and Pineview from each other Pineview deserves to use its own platform enum (which was already added, unused, previously). IS_G33() no longer matches Pineview, and gets replaced by IS_G33() || IS_PINEVIEW() or equivalent. Pineview is no longer an outlier among platform definitions. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481143689-19672-1-git-send-email-jani.nikula@intel.com
|
#
a3f79ca6 |
|
24-Nov-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Don't sanitize has_decoupled_mmio if platform is not broxton The check in __intel_uncore_early_sanitize() to disable decoupled mmio would disable it for every platform that is not broxton. While that's not a problem now since only broxton supports that, simply setting .has_decoupled_mmio in a new platform's device info wouldn't suffice. So avoid future confusion and change the workaround to only change the value of has_decoupled_mmio for broxton. v2: git add compile fix. (Ander) Cc: Praveen Paneri <praveen.paneri@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479993807-29353-1-git-send-email-ander.conselvan.de.oliveira@intel.com
|
#
a194b8cb |
|
17-Nov-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Waterproof verification of gen9 forcewake table ranges We have to make sure there are no holes in the table in Gen9. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1479388435-12062-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
66478475 |
|
16-Nov-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Assorted INTEL_INFO(dev) cleanups A bunch of source files with just a few instances of the incorrect INTEL_INFO use. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
78424c92 |
|
17-Nov-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Fix gen9 forcewake range table Commit 0dd356bb6ff5 ("drm/i915: Eliminate Gen9 special case") accidentaly dropped a MMIO range between 0xc000 to 0xcfff out of the blitter forcewake domain. Fix it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 0dd356bb6ff5 ("drm/i915: Eliminate Gen9 special case") Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1479373363-16528-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
85ee17eb |
|
15-Nov-2016 |
Praveen Paneri <praveen.paneri@intel.com> |
drm/i915/bxt: Broxton decoupled MMIO Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles for a single read/write and avoids frequent software forcewake. This certainly gives advantage over the forcewake as this new mechanism “decouples” CPU cycles and allow them to complete even when GT is in a CPD (frequency change) or C6 state. This can co-exist with forcewake and we will continue to use forcewake as appropriate. E.g. 64-bit register writes to avoid writing 2 dwords separately and land into funny situations. v2: - Moved platform check out of the function and got rid of duplicate functions to find out decoupled power domain (Chris) - Added a check for forcewake already held and skipped decoupled access (Chris) - Skipped writing 64 bit registers through decoupled MMIO (Chris) v3: - Improved commit message with more info on decoupled mmio (Tvrtko) - Changed decoupled operation to enum and used u32 instead of uint_32 data type for register offset (Tvrtko) - Moved HAS_DECOUPLED_MMIO to device info (Tvrtko) - Added lookup table for converting fw_engine to pd_engine (Tvrtko) - Improved __gen9_decoupled_read and __gen9_decoupled_write routines (Tvrtko) v4: - Fixed alignment and variable names (Chris) - Write GEN9_DECOUPLED_REG0_DW1 register in just one go (Zhe Wang) v5: - Changed HAS_DECOUPLED_MMIO() argument name to dev_priv (Tvrtko) - Sanitize info->had_decoupled_mmio at init (Chris) Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Signed-off-by: Praveen Paneri <praveen.paneri@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479230360-22395-1-git-send-email-praveen.paneri@intel.com
|
#
f856f847 |
|
03-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Just clear the mmiodebug before a register access When we enable the per-register access mmiodebug, it is to detect which access is illegal. Reporting on earlier untraced access outside of the mmiodebug does not help debugging (as the suspicion is immediately put upon the current register which is not at fault)! References: https://bugs.freedesktop.org/show_bug.cgi?id=97985 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-1-chris@chris-wilson.co.uk (cherry picked from commit dda960335e020835f7f1c12760e7f0b525b451e2) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
9480dbf0 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Inline binary search Instead of using bsearch library function make a local generator macro out of it so the comparison callback can be inlined. 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> Link: http://patchwork.freedesktop.org/patch/msgid/1475569769-31108-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
5a659383 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Use binary search when looking for shadowed registers Simply replace the linear search with the kernel's binary search implementation. There is only six registers currently in that table so this may not be that interesting. It adds a function call so hopefully remains performance neutral for now. v2: No need for manual conversion to bool for return. (Joonas Lahtinen) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
47188574 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Sort the shadow register table Also verify the order at runtime. This was we can start using binary search on it in a following patch. v2: Add comment on the sorted array and only check it when debug option is enabled. v3: Use IS_ENABLED. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v1) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
22d48c55 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove identical write mmmio functions We notice two identical copies of the shadow register table and following from that removal can also unify CHV and Gen9 write mmio functions and macros into a single implementation. v2: Name fwtable consistently and use HAS_FWTABLE. (Joonas Lahtinen) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
6044c4a3 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove identical mmio read functions It is now obvious VLV, CHV and Gen9 mmio read fcuntions are completely identical so we can remove the three copies and just keep the newly named generic implementation. v2: Use fwtable naming consistently. (Joonas Lahtinen) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
895833bd |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove identical macros Remove some macros which are now obviously identical. v2: Added HAS_FWTABLE macro and simplified intel_uncore_forcewake_for_read. (Joonas Lahtinen) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
15157970 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Store the active forcewake range table pointer If we store this in the uncore structure we are on a good way to show more commonality between the per-platform implementations. v2: Constify table pointer and correct coding style. (Chris Wilson) v3: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
0dd356bb |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Eliminate Gen9 special case If we insert blitter forcewake domain entries in the range table we can eliminate that special case and simplify the code in a few macros. This will enable more unification later. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
91e630b9 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Use binary search when looking up forcewake domains Instead of the existing linear seach, now that we have sorted range tables, we can do a binary search on them for some potential miniscule performance gain, but more importantly for elegance and code size. Hopefully the perfomance gain is sufficient to offset the function calls which were not there before. v2: Removed const cast away. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b0081239 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Sort forcewake mapping tables Sorting the tables (verified at runtime to help during development) is another prerequisite for interesting work which will follow. v2: * Remove const away cast and improve comments. (Chris Wilson) * Check tables only when debug option is enabled. v3: Use IS_ENABLED. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
9fc1117c |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Data driven register to forcewake domains lookup Move finding the correct forcewake domains to take for register access from code to a mapping table. This will allow more interesting work in the following patches and is easier to review if singled out early. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
c521b0c8 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Do not inline forcewake taking in mmio accessors Once we know we need to take new forcewakes, that being a slow operation, it does not make sense to inline that code into every mmio accessor. Move it to a separate function and save some code. v2: Be explicit with noinline and remove stale comment. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
003342a5 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Keep track of active forcewake domains in a bitmask There are current places in the code, and there will be more in the future, which iterate the forcewake domains to find out which ones are currently active. To save them from doing this iteration, we can cheaply keep a mask of active domains in dev_priv->uncore.fw_domains_active. This has no cost in terms of object size, even manages to shrink it overall by 368 bytes on my config. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: "Paneri, Praveen" <praveen.paneri@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e9b825f4 |
|
04-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove redundant hsw_write* mmio functions They are completely identical to gen6_write* ones. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
dda96033 |
|
03-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Just clear the mmiodebug before a register access When we enable the per-register access mmiodebug, it is to detect which access is illegal. Reporting on earlier untraced access outside of the mmiodebug does not help debugging (as the suspicion is immediately put upon the current register which is not at fault)! References: https://bugs.freedesktop.org/show_bug.cgi?id=97985 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-1-chris@chris-wilson.co.uk
|
#
b18c1bb4 |
|
06-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove 64b mmio write vfuncs We don't have safe 64-bit mmio writes as they are really split into 2x32-bit writes. This tearing is dangerous as the hardware *will* operate on the intermediate value, requiring great care when assigning. (See, for example, i965_write_fence_reg.) As such we don't currently use them and strongly advise not to us them. Go one step further and remove the 64-bit write vfuncs. v2: Add some more details to the comment about why WRITE64 is absent, and why you need to think twice before using READ64. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160906144538.4204-1-chris@chris-wilson.co.uk
|
#
bafb0fce |
|
27-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Make for_each_engine_masked() more compact and quicker Rather than walk the full array of engines checking whether each is in the mask in turn, we can use the mask to jump to the right engines. This should quicker for a sparse array of engines or mask, whilst generating smaller code: text data bss dec hex filename 1251010 4579 800 1256389 132bc5 drivers/gpu/drm/i915/i915.ko 1250530 4579 800 1255909 1329e5 drivers/gpu/drm/i915/i915.ko The downside is that we have to pass in a temporary, alas no C99 iterators yet. [P.S. Joonas doesn't like having to pass extra temporaries into the macro, and even less that I called them tmp. As yet, we haven't found a macro that avoids passing in a temporary that is smaller. We probably will get C99 iterators first!] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160827075401.16470-2-chris@chris-wilson.co.uk
|
#
54b4f68f |
|
21-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
Revert "drm/i915: Enable RC6 immediately" This reverts commit b12e0ee2080c ("drm/i915: Enable RC6 immediately"), as it was never meant to be sent anywhere other than the bug report for experimentation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1469132179-4052-1-git-send-email-chris@chris-wilson.co.uk Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b12e0ee2 |
|
21-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Enable RC6 immediately Now that PCU communication is reasonably fast, we do not need to defer RC6 initialisation to a workqueue. References: https://bugs.freedesktop.org/show_bug.cgi?id=97017 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3d466cd6 |
|
15-Jul-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fixup kerneldoc code snippets in intel_uncore.c We need :: before, blank lines around and indentation with 4 _additional_ spaces to make it work. Also, don't use @param in code snippets, it results in confusion. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1468612088-9721-8-git-send-email-daniel.vetter@ffwll.ch
|
#
b7137e0c |
|
13-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Defer enabling rc6 til after we submit the first batch/context Some hardware requires a valid render context before it can initiate rc6 power gating of the GPU; the default state of the GPU is not sufficient and may lead to undefined behaviour. The first execution of any batch will load the "golden render state", at which point it is safe to enable rc6. As we do not forcibly load the kernel context at resume, we have to hook into the batch submission to be sure that the render state is setup before enabling rc6. However, since we don't enable powersaving until that first batch, we queued a delayed task in order to guarantee that the batch is indeed submitted. v2: Rearrange intel_disable_gt_powersave() to match. v3: Apply user specified cur_freq (or idle_freq if not set). v4: Give in, and supply a delayed work to autoenable rc6 v5: Mika suggested a couple of better names for delayed_resume_work v6: Rebalance rpm_put around the autoenable task Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468397438-21226-7-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
91c8a326 |
|
05-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm Since drm_i915_private is now a subclass of drm_device we do not need to chase the drm_i915_private->dev backpointer and can instead simply access drm_i915_private->drm directly. text data bss dec hex filename 1068757 4565 416 1073738 10624a drivers/gpu/drm/i915/i915.ko 1066949 4565 416 1071930 105b3a drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ struct drm_i915_private *d; identifier i; @@ ( - d->dev->i + d->drm.i | - d->dev + &d->drm ) and for good measure the dev_priv->dev backpointer was removed entirely. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467711623-2905-4-git-send-email-chris@chris-wilson.co.uk
|
#
fac5e23e |
|
04-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Mass convert dev->dev_private to to_i915(dev) Since we now subclass struct drm_device, we can save pointer dances by noting the equivalence of struct drm_device and struct drm_i915_private, i.e. by using to_i915(). text data bss dec hex filename 1073824 4562 416 1078802 107612 drivers/gpu/drm/i915/i915.ko 1068976 4562 416 1073954 106322 drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ expression E; identifier p; @@ - struct drm_i915_private *p = E->dev_private; + struct drm_i915_private *p = to_i915(E); Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467628477-25379-1-git-send-email-chris@chris-wilson.co.uk
|
#
556ab7a6 |
|
03-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Hold irq uncore.lock when initialising fw_domains Acquiring the forcewake domain asserts that it is in an atomic section (as we always expect to be under the uncore.lock). This is true except for initialising the domains on Ivybridge, and so we generate a warning. Wrap the manual usage of fw_domains inside the spin_lock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467566973-13596-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
4a17fe13 |
|
30-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register() By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-61-git-send-email-chris@chris-wilson.co.uk
|
#
87273b71 |
|
30-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register() By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-60-git-send-email-chris@chris-wilson.co.uk
|
#
1758b90e |
|
30-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use a hybrid scheme for fast register waits Ville Syrjälä reported that in the majority of wait_for(I915_READ()) he inspect, most completed within the first couple of reads and that the delay between those wait_for() reads was the ratelimiting step for many code paths. For example, __gen6_update_ring_freq() was blamed for slowing down boot by many milliseconds, but under Ville's scrutiny the issue was just excessive delay waiting for sandybridge_pcode_write(). We can eliminate the wait by initially using a busyspin upon the register read and only fallback to the sleeping loop in cases where the hardware is indeed too slow. A threshold of 2 microseconds is used as the initial ballpark. To avoid excessive code bloating from converting every wait_for() into a hybrid busy/sleep loop, we extend wait_for_register_fw() and export it for use by other callers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-1-git-send-email-chris@chris-wilson.co.uk
|
#
1a3d1898 |
|
13-May-2016 |
Dave Gordon <david.s.gordon@intel.com> |
drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED For now, anything with a GuC requires uCode loading, and then supports command submission once loaded. But these are logically distinct from simply "having a GuC", so we need a separate macro for the latter. Then, various tests should use this new macro rather than HAS_GUC_UCODE() or testing enable_guc_submission. v4: Added a couple more uses of the new macro. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
d538704b |
|
13-May-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move get-reset-stats ioctl from intel_uncore.c to i915_gem_context.c The get-reset-stats ioctl reports upon the statistics (number of hangs, be it as a victim or the guilty party) of a particular context. It is semantically better as being part of i915_gem_context.c user interface, as opposed to the hardware level access of intel_uncore.c Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463137042-9669-1-git-send-email-chris@chris-wilson.co.uk
|
#
ae5702d2 |
|
10-May-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_GENx macros work on a mask If instead of numerical comparison me make these test a bitmask, we enable the compiler to optimize all instances of IS_GENx || IS_GENy. v2: Make bit zero of gen mask mean gen 1. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
dc97997a |
|
10-May-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use drm_i915_private as the native pointer for intel_uncore.c Pass drm_i915_private to the uncore init/fini routines and their subservients as it is their native type. text data bss dec hex filename 6309978 3578778 696320 10585076 a183f4 vmlinux 6309530 3578778 696320 10584628 a18234 vmlinux a modest 400 bytes of saving, but 60 lines of code deleted! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462885804-26750-1-git-send-email-chris@chris-wilson.co.uk
|
#
c033666a |
|
06-May-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Store a i915 backpointer from engine, and use it text data bss dec hex filename 6309351 3578714 696320 10584385 a18141 vmlinux 6308391 3578714 696320 10583425 a17d81 vmlinux Almost 1KiB of code reduction. v2: More s/INTEL_INFO()->gen/INTEL_GEN()/ and IS_GENx() conversions text data bss dec hex filename 6304579 3578778 696320 10579677 a16edd vmlinux 6303427 3578778 696320 10578525 a16a5d vmlinux Now over 1KiB! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-3-git-send-email-chris@chris-wilson.co.uk
|
#
31318a92 |
|
14-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use fw_domains_put_with_fifo() on HSW HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Deepak S <deepak.s@linux.intel.com> Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460633942-24013-1-git-send-email-ville.syrjala@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (cherry picked from commit 3d7d0c85e41afb5a05e98b3a8a72c38357f02594) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
3d7d0c85 |
|
14-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use fw_domains_put_with_fifo() on HSW HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Deepak S <deepak.s@linux.intel.com> Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460633942-24013-1-git-send-email-ville.syrjala@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
c02e85a0 |
|
13-Apr-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Calculate edram size With gen9+ the edram capabilities are defined so that we can calculate the edram (ellc) size accordingly. Note that there are undefined combinations for some subset of edram capability bits. Return the closest size for undefined indexes. Even if we get it wrong with beginning of future gen enabling, the size information is currently only used for boot message and in debugfs entry. v2: Use function instead of hard to read macro (Daniel) v3: s/INTEL_INFO/INTEL_GEN (Matthew) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460557604-7126-2-git-send-email-mika.kuoppala@intel.com
|
#
3accaf7e |
|
13-Apr-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Store and use edram capabilities Store the edram capabilities instead of only the size of edram. This is preparatory patch to allow edram size calculation based on edram capability bits for gen9+. With gen9 the edram is behind llc and is a separate entity. With hsw/bdw it was more of a victim cache for LLC so the name 'eLLC' might be warranted. Regardless, rename all mentions of eLLC to EDRAM to clear the confusion. v2: return bytes for edram size (Chris) s/eLLC/eDRAM in output if we are gen > 8 v3: rebase, INTEL_GEN (Chris) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
522bad5b |
|
11-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv" Enable the unclaimd register detection stuff on vlv/chv since we've now fixed the known problems during suspend. This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
3756685a |
|
12-Apr-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Only grab correct forcewake for the engine with execlists Rather than blindly waking up all forcewake domains on command submission, we can teach each engine what is (or are) the correct one to take. On platforms with multiple forcewake domains like VLV, CHV, SKL and BXT, this has the potential of lowering the GPU and CPU power use and submission latency. To implement it we add a function named intel_uncore_forcewake_for_reg whose purpose is to query which forcewake domains need to be taken to read or write a specific register with raw mmio accessors. These enables the execlists engine setup to query which forcewake domains are relevant per engine on the currently running platform. v2: * Kerneldoc. * Split from intel_uncore.c macro extraction, WARN_ON, no warns on old platforms. (Chris Wilson) v3: * Single domain per engine, mention all registers, bi-directional function and a new name, fix handling of gen6 and gen7 writes. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460468251-14069-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
a70ecc16 |
|
12-Apr-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove forcewake request registers from the shadowed table Chris Wilson points out that we can remove them from the array since they are always written to with raw accessors. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
6863b76c |
|
12-Apr-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Extract knowledge of register forcewake domains Knowledge of which register per platform belonds in which forcewake domain was embedded in the MMIO accessors themselves. Extract it into standalone macros so they can be used from new code in the following patches. This causes GCC to compile some of the MMIO accessors slightly differently and grows the code a tiny amount. But none of the growth is on the fast-path so it does not matter hugely. Affected sizes before: 00000000000026f0 00000000000001a5 t gen6_read16 0000000000002390 00000000000001a5 t gen6_read32 00000000000028a0 00000000000001a5 t gen6_read64 00000000000061d0 000000000000019e t gen8_write16 0000000000006510 000000000000019d t gen8_write32 0000000000006370 000000000000019d t gen8_write64 00000000000021f0 000000000000019d t gen8_write8 Affected sizes after: 0000000000002840 00000000000001aa t gen6_read16 00000000000024e0 00000000000001a9 t gen6_read32 00000000000029f0 00000000000001a9 t gen6_read64 0000000000004f20 00000000000001b5 t gen8_write16 0000000000004ba0 00000000000001b4 t gen8_write32 00000000000050e0 00000000000001b4 t gen8_write64 0000000000004d60 00000000000001b4 t gen8_write8 Other MMIO accessors are not affected in size. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
4e1176dd |
|
07-Apr-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Do not serialize forcewake acquire across domains On platforms with multiple forcewake domains it seems more efficient to request all desired ones and then to wait for acks to avoid needlessly serializing on each domain. v2: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460045074-1006-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
33c582c1 |
|
07-Apr-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Simplify for_each_fw_domain iterators As the vast majority of users do not use the domain id variable, we can eliminate it from the iterator and also change the latter using the same principle as was recently done for for_each_engine. For a couple of callers which do need the domain mask, store it in the domain array (which already has the domain id), then both can be retrieved thence. Result is clearer code and smaller generated binary, especially in the tight fw get/put loops. Also, relationship between domain id and mask is no longer assumed in the macro. v2: Improve grammar in the commit message and rename the iterator to for_each_fw_domain_masked for consistency. (Dave Gordon) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
|
#
a57a4a67 |
|
07-Apr-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Use consistent forcewake auto-release timeout across kernel configs Because it is based on jiffies, current implementation releases the forcewake at any time between straight away and between 1ms and 10ms, depending on the kernel configuration (CONFIG_HZ). This is probably not what has been desired, since the dynamics of keeping parts of the GPU awake should not be correlated with this kernel configuration parameter. Change the auto-release mechanism to use hrtimers and set the timeout to 1ms with a 1ms of slack. This should make the GPU power consistent across kernel configs, and timer slack should enable some timer coalescing where multiple force-wake domains exist, or with unrelated timers. For GlBench/T-Rex this decreases the number of forcewake releases from ~480 to ~300 per second, and for a heavy combined OGL/OCL test from ~670 to ~360 (HZ=1000 kernel). Even though this reduction can be attributed to the average release period extending from 0-1ms to 1-2ms, as discussed above, it will make the forcewake timeout consistent for different CONFIG_HZ values. Real life measurements with the above workload has shown that, with this patch, both manage to auto-release the forcewake between 2-4 times per 10ms, even though the number of forcewake gets is dramatically different. T-Rex requests between 5-10 explicit gets and 5-10 implict gets in each 10ms period, while the OGL/OCL test requests 250 and 380 times in the same period. The two data points together suggest that the nature of the forwake accesses is bursty and that further changes and potential timeout extensions, or moving the start of timeout from the first to the last automatic forcewake grab, should be carefully measured for power and performance effects. v2: * Commit spelling. (Dave Gordon) * More discussion on numbers in the commit. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
2d1fe073 |
|
07-Apr-2016 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
drm/i915: Do not use {HAS_*, IS_*, INTEL_INFO}(dev_priv->dev) dev_priv is what the macro works hard to extract, pass it directly. > sed 's/\([A-Z].*(dev_priv\)->dev)/\1)/g' v2: - Include all wrapper macros too (Chris) v3: - Include sed cmdline (Chris) v4: - Break long line - Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460016485-8089-1-git-send-email-joonas.lahtinen@linux.intel.com
|
#
6b332fa2 |
|
04-Apr-2016 |
Arun Siluvery <arun.siluvery@linux.intel.com> |
drm/i915/guc: reset GuC and retry on firmware load failure Due to timing issues in the HW, some of the status bits required for GuC authentication occasionally don't get set; when that happens, the GuC cannot be initialized and we will be left with a wedged GPU. The W/A suggested is to perform a soft reset of the GuC and attempt to reload the F/W again for few times before giving up. As the failure is dependent on timing, tests performed by triggering manual full gpu reset (i915_wedged) showed that we could sometimes hit this after several thousand iterations, but sometimes tests ran even longer without any issues. Reset and reload mechanism proved helpful when we indeed hit f/w load failure, so it is better to include this to improve driver stability. This change implements the following WAs, WaEnableuKernelHeaderValidFix:skl,bxt WaEnableGuCBootHashCheckNotSet:skl,bxt Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
b208ba8e |
|
24-Mar-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rename __force_wake_get to __force_wake_auto __force_wake_get() only acquires a temporary wakeref on forcewake that is automatically released when a timer expires. When reading the code again, I confused __intel_uncore_forcewake_get() for __force_wake_get() and to my shame thought I found a bug in unbalanced wake_count handling. I claim that if the function had been called __force_wake_auto() instead I would not have embarrassed myself. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458829907-26596-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
ee4b6faf |
|
16-Mar-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Modify reset func to handle per engine resets In full gpu reset we prime all engines and reset domains corresponding to each engine. Per engine reset is just a special case of this process wherein only a single engine is reset. This change is aimed to modify relevant functions to achieve this. There are some other steps we carry out in case of engine reset which are addressed in later patches. Reset func now accepts a mask of all engines that need to be reset. Where per engine resets are supported, error handler populates the mask accordingly otherwise all engines are specified. v2: ALL_ENGINES mask fixup, better for_each_ring_masked (Chris) v3: Whitespace fixes (Chris) v4: Rebase due to s/ring/engine Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458143640-20563-1-git-send-email-mika.kuoppala@intel.com
|
#
666796da |
|
16-Mar-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: More intel_engine_cs renaming Some trivial ones, first pass done with Coccinelle: @@ @@ ( - I915_NUM_RINGS + I915_NUM_ENGINES | - intel_ring_flag + intel_engine_flag | - for_each_ring + for_each_engine | - i915_gem_request_get_ring + i915_gem_request_get_engine | - intel_ring_idle + intel_engine_idle | - i915_gem_reset_ring_status + i915_gem_reset_engine_status | - i915_gem_reset_ring_cleanup + i915_gem_reset_engine_cleanup | - init_ring_lists + init_engine_lists ) But that didn't fully work so I cleaned it up with: for f in *.[hc]; do sed -i -e s/I915_NUM_RINGS/I915_NUM_ENGINES/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_request_get_ring/i915_gem_request_get_engine/ $f; done for f in *.[hc]; do sed -i -e s/intel_ring_flag/intel_engine_flag/ $f; done for f in *.[hc]; do sed -i -e s/intel_ring_idle/intel_engine_idle/ $f; done for f in *.[hc]; do sed -i -e s/init_ring_lists/init_engine_lists/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_cleanup/i915_gem_reset_engine_cleanup/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_status/i915_gem_reset_engine_status/ $f; done v2: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
d431440c |
|
02-Mar-2016 |
Tomas Elf <tomas.elf@intel.com> |
drm/i915: Generalise common GPU engine reset request/unrequest code GPU engine reset handshaking is something that is applicable to both full GPU reset and engine reset, which is something that is part of the upcoming TDR per-engine hang recovery patches. Break out the common engine reset request/unrequest code (originally written by Mika Kuoppala) for reuse later in the TDR enablement patch series. v2: correct indentation and drop unused returned value (Mika) v3: We have forcewake during reset so use *_FW reg access (Mika) Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Tomas Elf <tomas.elf@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> [Mika: Fixed format warning] Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456929984-16323-1-git-send-email-mika.kuoppala@intel.com
|
#
274008e8 |
|
05-Feb-2016 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915/bxt: Check BIOS RC6 setup before enabling RC6 RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 setup registers. If those are not setup Driver should not enable RC6. For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values to know if BIOS has enabled HW/SW RC6. This will also enable user to control RC6 using BIOS settings alone. RC6 related instability can be avoided by disabling via BIOS settings till driver fixes it. v2: Had placed logic in gen8 function by mistake. Fixed it. Ensuring RPM is not enabled in case BIOS disabled RC6. v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel) Runtime PM enabling happens before gen9_enable_rc6. Moved the updation of enable_rc6 parameter in intel_uncore_sanitize. v4: Added elaborate check for BIOS RC6 setup. Prepared check_pctx for bxt. (Imre) v5: Caching reserved stolen base and size in the driver private data. Reorganized RC6 setup check. Moved from gen9_enable_rc6 to intel_uncore_sanitize. (Imre) v6: Rebasing on the patch submitted by Imre that moves gem_init_stolen earlier in the load. v7: Removed PWRCTX_MAXCNT_VCSUNIT1 check as it applies to SKL. (Imre) v8: Fixed formatting and checkpatch issues. Fixed functional issue where RC6 ctx size check was missing. (Imre) Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454697809-22113-1-git-send-email-sagar.a.kamble@intel.com
|
#
c81eeea6 |
|
19-Jan-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Limit the auto arming of mmio debugs on vlv/chv The capability to detect unclaimed register access was recently introduced for vlv/chv platforms. Apparently there are plenty of unclaimed access on these platforms, resulting in new dmesg warns. But as we are trying to form a beachhead for CI/Bat, all new warns are adding to the noise and thus not desirable at this point in time. Make it so that if in these platforms the automatic arming was responsible for mmio_debug enabling, ignore the warns. If user/dev wants to fix these, he can still do so by i915.mmio_debug=1234. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1453285943-24614-1-git-send-email-mika.kuoppala@intel.com
|
#
bc3b9346 |
|
08-Jan-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Arm the unclaimed mmio debugs on suspend path If we go into suspend with unclaimed access detected, it would be nice to catch that access on a next suspend path. So instead of just notifying about it, arm the unclaimed mmio checks on suspend side. We want to keep the asymmetry on resume, as if it was on resume path, it was not driver that is responsible so no point in arming mmio debugs. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452261080-6979-2-git-send-email-mika.kuoppala@intel.com
|
#
9c053501 |
|
08-Jan-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Enable mmio_debug for vlv/chv With commit 8ac3e1bb76cc ("drm/i915: Add non claimed mmio checking for vlv/chv") we now have chv/vlv support in place for detecting unclaimed access. Also the perf hit of extra mmio read is now only suffered if mmio_debug is set. This allows us to stuff the macro for unclaimed reg detection inside a generic gen6 register access, as now all gens using these macros uses also unclaimed debugs, the one exception being snb. We gain more clean and generic macros and only downside is that snb will suffer one branch perf hit without upside. Note that the hsw write path debug register check now happens before fifo check, but this should not make any real difference. As vlv/chv use the generic gen6 access macros, the consequence is that they gain the mmio_debug feature. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452261080-6979-1-git-send-email-mika.kuoppala@intel.com
|
#
8ac3e1bb |
|
15-Dec-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Add non claimed mmio checking for vlv/chv Imre mentioned that chv might also have capability to track unclaimed mmio accesses. Ville added that both chv and vlv has this capability and he had already made this way back [1]. Mimic what Ville's patch does but adapt on top of less frequent mmio accesses by omitting checking always on reg writes. This patch is untested as of now. v2: overflow handling and posting omitted (Ville) References: [1] http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450201542-22918-1-git-send-email-mika.kuoppala@intel.com
|
#
4bd0a25d |
|
15-Dec-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Streamline unclaimed reg debug trace Remove char* assignments and add branching hint and also constify the parameters. This results in a 35 bytes shorter fast path, so author boldly assumes it helps without doing in-depth assembly analysis. v2: use WARN's branching (Chris), commit name (Joonas) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450189512-30360-5-git-send-email-mika.kuoppala@intel.com
|
#
75714940 |
|
16-Dec-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Do one shot unclaimed mmio detection less frequently We have done unclaimed register access check in normal (mmio_debug=0) mode once per write. This adds probability of finding the exact sequence where we did the bad access, but also adds burden to each write. As we have mmio_debug available for more fine grained analysis, give up accuracy of detecting correct spot at the first occurrence by doing the one shot detection and arming of mmio_debug in hangcheck and in modeset. This removes the write path performance burden. v2: Remove gratuitous DRM_DEBUG and return value, comments (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450250808-14864-1-git-send-email-mika.kuoppala@intel.com
|
#
fc97618b |
|
15-Dec-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Introduce intel_uncore_unclaimed_mmio Currently interrupt code is the only place checking for the unclaimed register access prior to actual register macros using the same functionality. Rename the function and make it return bool so that the possible error message context is clear in the caller side. The motivation is to allow usage of unclaimed detection on arbitrary places. v2: rebase, s/access/mmio, s/dev/dev_priv Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450189512-30360-2-git-send-email-mika.kuoppala@intel.com
|
#
8a47eb19 |
|
15-Dec-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Consolidate unclaimed mmio detection Access the unclaimed reg detection register through one helper which also does cleanup. Note that we now access the register only if the platform has the actual non claimed access bit. This prevents reading the register with gens that doesn't have the register or the unclaimed bit, when debug_mmio > 0. Note that we post after clearing the bit. This makes sure that the next unclaimed write access would get detected also if it happened right after clearing, and not fold into the previous detection. v2: s/unclaimed_reg_access/check_for_unclaimed_mmio (Chris) debug log on unclaimed detection on uncore init (Joonas) v3: remove posting read (Ville) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450200287-24080-1-git-send-email-mika.kuoppala@intel.com
|
#
c9b8846a |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: use assert_rpm_wakelock_held instead of opencoding it Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-7-git-send-email-imre.deak@intel.com
|
#
da5827c3 |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: add assert_rpm_wakelock_held helper As a preparation for follow-up patches add a new helper that checks whether we hold an RPM reference, since this is what we want most of the cases. Atm this helper will only check for the HW suspended state, a follow-up patch will do the actual change to check the refcount instead. One exception is the forcewake release timer function, where it's guaranteed that the HW is on even though the RPM refcount drops to zero. This guarantee is provided by flushing the timer in the runtime suspend handler. So leave the assert_device_not_suspended check in place there. Also rename assert_device_suspended for consistency and export these helpers as a preparation for the follow-up patches. No functional change. v3: - change the assert warning message to be more meaningful (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-6-git-send-email-imre.deak@intel.com
|
#
7f233235 |
|
17-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers We don't really need to check this flag in the get/put/assert helpers, as on platforms without RPM support we won't ever enable RPM. That means pm.suspend will be always false and the assert will be always true. Do this to simplify the code and to let us extend the RPM asserts to all platforms for a better coverage. Motivated by Ville. v2-v3: - unchanged v4: - remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too made possible by the previous two patches v5: - rebased on the previous new patch in the series that keeps HAS_RUNTIME_PM() in intel_runtime_pm_enable() with a permanent reference taken there Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450352931-16498-1-git-send-email-imre.deak@intel.com
|
#
666a4537 |
|
09-Dec-2015 |
Wayne Boyer <wayne.boyer@intel.com> |
drm/i915: Separate cherryview from valleyview The cherryview device shares many characteristics with the valleyview device. When support was added to the driver for cherryview, the corresponding device info structure included .is_valleyview = 1. This is not correct and leads to some confusion. This patch changes .is_valleyview to .is_cherryview in the cherryview device info structure and simplifies the IS_CHERRYVIEW macro. Then where appropriate, instances of IS_VALLEYVIEW are replaced with IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent. v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro. Also add followup patches to fix issues discovered during the first review. (Ville) v3: Fix some style issues and one gen check. Remove CRT related changes as CRT is not supported on CHV. (Imre, Ville) v4: Make a few more optimizations. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449692975-14803-1-git-send-email-wayne.boyer@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
f0f59a00 |
|
18-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Type safe register read/write Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
|
#
0670c5a6 |
|
06-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add 'offset' to uncore funcs Add 'u32 offset' to the uncore register access functions. For now it's the same as 'reg', but once type safety gets added 'reg' will be the type safe register variable and 'offset' the raw offset. v2: s/uint32_t/u32/ (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446839236-20035-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
8a74db7a |
|
04-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pull the vgpu uncore funcs apart from the rest of gen6+ I need to add a new variable into GEN6_{READ,WRITE}_HEADER, but the vgpu won't need it, so let's avoid an unused variable warning by splitting the vgpu stuff to use its own macros. Cc: Eddie Dong <eddie.dong@intel.com> Cc: Jike Song <jike.song@intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Yu Zhang <yu.c.zhang@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-26-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Zhiyuan Lv <zhiyuan.lv@intel.com>
|
#
8697600b |
|
06-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make the high dword offset more explicit in i915_reg_read_ioctl Store the upper dword of the register offset in the whitelist as well. This would allow it to read register where the two halves aren't sitting right next to each other, and it'll make it easier to make register access type safe. While at it change the register offsets to u32 from u64. Our register space isn't quite that big, yet :) v2: Use ldw/udw as the suffixes, and add a note about 64bit wide split regs (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446839021-18599-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
99106bc1 |
|
05-Nov-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Do graphics device reset under forcewake We have a timed release of a forcewake when using I915_READ/WRITE macros. wait_for() macro will go to quite long sleep if the first read doesn't satisfy the condition for successful exit. With these two interacting, it is possible that we lose the forcewake during the wait_for() and the subsequent read will reaquire forcewake. Further experiments with skl shows that when we lose forcewake, we lose the reset request we submitted. So reset request register is not power context saved. Grab forcewakes for all engines before starting the reset/request dance so that all requests stay valid for the duration of reset requisition across all the engines. v2: Add comment on power well sleeps. Wrap the reset handling under forcewake instead of just reset requests (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92774 Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> (v1, v2) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446721898-1450-1-git-send-email-mika.kuoppala@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
e97d8fbe |
|
22-Oct-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add NEEDS_FORCEWAKE() checks for vlv/chv Include an early NEEDS_FORCEWAKE() check for vlv and chv. Hopefully that will avoid doing so many range checks in for many register accesses (at least for all display registers). Note that vlv already had the check in the write path since it shares the gen6+ code for that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-6-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
6a42d0f4 |
|
22-Oct-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Respin vlv/chv reagister access to look more like SKL Change the fw domain handling in the vlv/chv register read/write functions to look more like the SKL code, ie. have a single __force_wake_get() get call instead of multiple ones. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-5-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
0c8bfe52 |
|
22-Oct-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Minor style nits in intel_uncore.c Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
40181697 |
|
22-Oct-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Read FORCEWAKE registers with I915_READ_FW() Change FORCEWAKE & co. reads for the error state to use I915_READ_FW(). Reading a FORCEWAKE register using a function that can frob forcewake just seems wrong. There is a check to skip grabbing the forcewake for accessing FORCEWAKE in intel_uncore.c, but there's no such check for FORCEWAKE_MT. So no idea what is currently happening with FORCEWAKE_MT reads. FORCEWAKE_VLV is fortunately outside the forcewake range anyway, so no actual issue with that one. So let's just make the rule that you can't access FORCEWAKE registers with the normal I915_READ() stuff, and we can drop the extra FORCEWAKE check from NEEDS_FORCEWAKE(). While at it use NEEDS_FORCEWAKE() on BDW, where it was skipped for whatever bikeshed reason that I've already forgotten. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
75aa3f63 |
|
22-Oct-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Turn __raw_i915_read8() & co. in to inline functions There's no need for __raw_i915_read8() & co. to be macros, so make them inline functions. To avoid typo mistakes generate the inline functions using preprocessor templates. We have a few users of the raw register acces functions outside intel_uncore.c, so let's also move the functions into intel_drv.h. While doing that switch I915_READ_FW() & co. to use the __raw_i915_read() functions, and use the _FW macros everywhere outside intel_uncore.c where we want to read registers without grabbing forcewake and whatnot. The only exception is i915_check_vgpu() which itself gets called from intel_uncore.c, so using the __raw_i915_read stuff there seems appropriate. v2: Squash in the intel_uncore.c->i915_drv.h move Convert I915_READ_FW() to use __raw_i915_read(), and use I915_READ_FW() outside of intel_uncore.c (Chris) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
ded17493 |
|
18-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c039b7f2 |
|
18-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Include MCHBAR_MIRROR_BASE in ILK_GDSR Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
83e33372 |
|
23-Aug-2015 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Increase maximum polling time to 50ms for forcewake request/clear ack On BXT, We Observe timeout for forcewake request completion with 2ms polling period as given here: [drm:fw_domains_get] ERROR render: timed out waiting for forcewake ack request. Polling for 50ms is recommended to avoid these timeouts. Change-Id: Ie715b0069a3049606e9602bc5e97a6511890864d Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed by: Alex Dai <yu.dai@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
22cc27bb |
|
03-Sep-2015 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Future proof uncore_init. Unless future specs tells otherwise we can assume future gens inherit some stuff from the previous so let's handle missed cases when we know tehy should't be there and assume default equals newest one. No functional changes. v2: Remove useless case as pointed out by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6c908bf4 |
|
25-Aug-2015 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: gen 9 can check for unclaimed registers too Dear git bisect user, Even though this is the patch that introduced the WARN() you're bisecting, please notice that it's very likely that the problem you're facing was already present before this commit. In other words: this commit adds code to detect errors and give WARN()s about them, but the errors were already there. In order to continue your debug, please use the i915.mmio_debug option, check the backtraces and try to discover which read or write operation is causing the error message. Then check if this is happening because the register does not exist or because its power well is down when the operation is being done. On my SKL machine, if I use i915.mmio_debug=999, this patch triggers 42 WARNs just by booting. I didn't investigate them yet. Normal users are only going to get a single WARN due to the default i915.mmio_debug setting. Thank you for your comprehension, Paulo Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
53abb679 |
|
21-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use ARRAY_SIZE() instead of hand rolling it A couple of hand rolled ARRAY_SIZE()s caught my eye. Get rid of them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
648a9bc5 |
|
15-Jul-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use two 32bit reads for select 64bit REG_READ ioctls Since the hardware sometimes mysteriously totally flummoxes the 64bit read of a 64bit register when read using a single instruction, split the read into two instructions. Since the read here is of automatically incrementing timestamp counters, we also have to be very careful in order to make sure that it does not increment between the two instructions. However, since userspace tried to workaround this issue and so enshrined this ABI for a broken hardware read and in the process neglected that the read only fails in some environments, we have to introduce a new uABI flag for userspace to request the 2x32 bit accurate read of the timestamp. v2: Fix alignment check and include details of the workaround for userspace. Reported-by: Karol Herbst <freedesktop@karolherbst.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91317 Testcase: igt/gem_reg_read Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: stable@vger.kernel.org Tested-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b1330fbb |
|
18-Jun-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Report an error when i915.reset prevents a reset If the user disables the GPU reset using the i915.reset parameter and one occurs, report that we failed to reset the GPU. If we return early, as we currently do, then we leave all state intact (with a hung GPU) and clients block forever waiting for their requests to complete. Testcase: igt/gem_eio Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Mark i915.reset as an unsafe modoption, as discussed with Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7fd2d269 |
|
17-Jun-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Reset request handling for gen8+ In order for gen8+ hardware to guarantee that no context switch takes place during engine reset and that current context is properly saved, the driver needs to notify and query hw before commencing with reset. There are gpu hangs where the engine gets so stuck that it never will report to be ready for reset. We could proceed with reset anyway, but with some hangs with skl, the forced gpu reset will result in a system hang. By inspecting the unreadiness for reset seems to correlate with the probable system hang. We will only proceed with reset if all engines report that they are ready for reset. If root cause for system hang is found and can be worked around with another means, we can reconsider if we can reinstate full reset for unreadiness case. v2: -EIO, Recovery, gen8 (Chris, Tomas, Daniel) v3: updated commit msg v4: timeout_ms, simpler error path (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=89959 References: https://bugs.freedesktop.org/show_bug.cgi?id=90854 Testcase: igt/gem_concurrent_blit/prw-blt-overwrite-source-read-rcs-forked Testcase: igt/gem_concurrent_blit/gtt-blt-overwrite-source-read-rcs-forked Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tomas Elf <tomas.elf@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
49e4d842 |
|
14-Jun-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Report to userspace if we have a (presumed) working GPU reset In igt, we want to test handling of GPU hangs, both for recovery purposes and for reporting. However, we don't want to inject a genuine GPU hang onto a machine that cannot recover and so be permenantly wedged. Rather than embed heuristics into igt, have the kernel report exactly when it expects the GPU reset to work. This can also be usefully extended in future to indicate different levels of fine-grained resets. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tim Gore <tim.gore@intel.com> Cc: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a04f90a3 |
|
15-Apr-2015 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915/chv: Implement WaDisableShadowRegForCpd This WA is avoid problem between shadow vs wake FIFO unload problem during CPD/RC6 transactions on CHV. v2: Define individual bits GTFIFOCTL (Ville) v3: move WA to uncore_early_sanitize (ville) Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [Jani: fixed some whitespace issues while applying] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
a6111f7b |
|
07-Apr-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reduce locking in execlist command submission This eliminates six needless spin lock/unlock pairs when writing out ELSP. v2: Respin with my preferred colour. v3: Mostly back to the original colour Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [v1] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
48572edd |
|
18-Dec-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Disable the mmio.debug WARN after it fires If we have a single unclaimed register, we will have lots. A WARN for each one makes the machine unusable and does not aid debugging. Convert the i915.mmio_debug option to a counter for how many WARNs to fire before shutting up. Even when i915.mmio_debug was disabled it would continue to shout an *ERROR* for every interrupt, without any information at all for debugging. The massive verbiage was added in commit 5978118c39c2f72fd8b39ef9c086723542384809 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Wed Jul 16 17:49:29 2014 -0300 drm/i915: reorganize the unclaimed register detection code v2: Automatically enable invalid mmio reporting for the *next* invalid access if mmio_debug is disabled by default. This should give us clearer debug information without polluting the logs too much. v3: Compile fixes, rebase. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Update modparam text per the thread.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6ea2556f |
|
27-Feb-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Do both mt and gen6 style forcewake reset on ivb probe commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code") failed to take into account that we have used to reset both the gen6 style and the multithreaded style forcewake registers. This is due to fact that ivb can use either, depending on how the bios has set up the machine. Mimic the old semantics before we have determined the correct variety and reset both before the ecobus probe. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Huang Ying <ying.huang@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0cd0caad |
|
27-Feb-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Do both mt and gen6 style forcewake reset on ivb probe commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code") failed to take into account that we have used to reset both the gen6 style and the multithreaded style forcewake registers. This is due to fact that ivb can use either, depending on how the bios has set up the machine. Mimic the old semantics before we have determined the correct variety and reset both before the ecobus probe. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Huang Ying <ying.huang@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
c32e3788 |
|
10-Dec-2014 |
Dave Gordon <david.s.gordon@intel.com> |
drm/i915: FIFO space query code refactor When querying the GTFIFOCTL register to check the FIFO space, the read value must be masked. The operation is repeated explicitly in several places. This change refactors the read-and-mask code into a function call. v2: rebased on top of Mika's forcewake patch set, specifically: [PATCH 8/8] drm/i915: Enum forcewake domains and domain identifiers Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8543747c |
|
09-Feb-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Document that we implement WaRsClearFWBitsAtReset Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e25dca86 |
|
03-Feb-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Also detect eDRAM on SKL Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2db59d53 |
|
03-Feb-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Detect eDRAM with the enabled bit only At the moment we compare the whole EDRAM_PRESENT/EDRAMCAP register value to 1 while EDRAM_PRESENT is only bit 0 (the rest may be used to describe eDRAM capabilities). To be more future proof, only look at bit 0 to detect eDRAM presence. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3be0bf5a |
|
10-Feb-2015 |
Yu Zhang <yu.c.zhang@linux.intel.com> |
drm/i915: Create vGPU specific MMIO operations to reduce traps In the virtualized environment, forcewake operations are not necessary for the driver, because mmio accesses will be trapped and emulated by the host side, and real forcewake operations are also done in the host. New mmio access handlers are added to directly call the __raw_i915_read/write, therefore will reduce many traps and increase the overall performance for drivers running in the VM with Intel GVT-g enhancement. v2: take Chris' comments: - register the mmio hooks in intel_uncore_init() v3: take Daniel's comments: - use macros to assign mmio write functions for vGPU v4: take Tvrtko's comments: - also use mmio hooks for read operations Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Kevin Tian <kevin.tian@intel.com>k Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cf9d2890 |
|
10-Feb-2015 |
Yu Zhang <yu.c.zhang@linux.intel.com> |
drm/i915: Introduce a PV INFO page structure for Intel GVT-g. Introduce a PV INFO structure, to facilitate the Intel GVT-g technology, which is a GPU virtualization solution with mediated pass-through. This page contains the shared information between i915 driver and the host emulator. For now, this structure utilizes an area of 4K bytes on HSW GPU's unused MMIO space. Future hardware will have the reserved window architecturally defined, and layout of the page will be added in future BSpec. The i915 driver load routine detects if it is running in a VM by reading the contents of this PV INFO page. Thereafter a flag, vgpu.active is set, and intel_vgpu_active() is used by checking this flag to conclude if GPU is virtualized with Intel GVT-g. By now, intel_vgpu_active() will return true, only when the driver is running as a guest in the Intel GVT-g enhanced environment on HSW platform. v2: take Chris' comments: - call the i915_check_vgpu() in intel_uncore_init() - sanitize i915_check_vgpu() by adding BUILD_BUG_ON() and debug info take Daniel's comments: - put the definition of PV INFO into a new header - i915_vgt_if.h other changes: - access mmio regs by readq/readw in i915_check_vgpu() v3: take Daniel's comments: - move the i915/vgt interfaces into a new i915_vgpu.c - update makefile - add kerneldoc to functions which are non-static - add a DOC: section describing some of the high-level design - update drm docbook other changes: - rename i915_vgt_if.h to i915_vgpu.h v4: take Tvrtko's comments: - fix a typo in commit message - add debug message when vgt version mismatches - rename low_gmadr/high_gmadr to mappable/non-mappable in PV INFO structure Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Eddie Dong <eddie.dong@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3225b2f9 |
|
05-Feb-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Squelch overzealous uncore reset WARN_ON We added this WARN_ON to guard against using uninitialized forcewake domains. But forgot blissfully that not all gens have forcewake domains in the first place. v2: Move WARN_ON to fw_domains_init (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88911 Tested-by: Ding Heng <hengx.ding@intel.com> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [Jani: add comment above WARN_ON as suggested by Chris] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
07859504 |
|
28-Jan-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Don't do posting reads on getting forcewake The checking for ack and also any subsequent mmio access will serialize with setting the forcewake bit. Drop the posting read as superfluous. Note that in the put side we still want to keep the posting read as it will ensure that the hw sees our forcewake release in a timely manner and doesn't keep the hw powered up. Comment from Chris: On Wed, Jan 28, 2015 at 05:54:14PM +0200, Mika Kuoppala wrote: > Ville Syrjälä <ville.syrjala@linux.intel.com> writes: > > IIRC the posting read from same cache line actually fixed real bugs. So > > I'm a bit worried about dropping them. But I suppose it's possible only > > the _put side was important for those bugs. > > I found these: > > commit 6af2d180f82151cf3d58952e35a4f96e45bc453a > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Thu Jul 26 16:24:50 2012 +0200 > > drm/i915: fix forcewake related hangs on snb > > commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd > Author: Ben Widawsky <ben@bwidawsk.net> > Date: Sat Sep 1 22:59:50 2012 -0700 > > drm/i915: Never read FORCEWAKE > > https://bugs.freedesktop.org/show_bug.cgi?id=51738 > https://bugs.freedesktop.org/show_bug.cgi?id=52424 > > The snb here seems to survive gem_dummy_reloc_loop and > gem_ring_sync_loop in here with the get side posting removed. Note that we kept the once associated with #52424, but judging by my comments in #51738 the posting read is just a band aid anyway as a full mb() itself was not adequate. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: paste relevant review discussion in.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f9b3927a |
|
28-Jan-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Do uncore early sanitize after domain init intel_uncore_early_sanitize() will reset the forcewake registers. When forcewake domains were introduced, the domain init was done after the sanitization of the forcewake registers. And as the resetting of registers use the domain accessors, we tried to reset the forcewake registers with unitialized forcewake domains and failed. Fix this by sanitizing after all the domains have been initialized. Do per domain clearing of forcewake register on domain init so that IVB can do early access to ECOBUS do determine the final configuration. This regression was introduced in commit 05a2fb157e44a53c79133805d30eaada43911941 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Mon Jan 19 16:20:43 2015 +0200 drm/i915: Consolidate forcewake code v2: Carve out ellc detect, fw_domain_reset for ivb/ecobus (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88805 Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Darren Hart <dvhart@linux.intel.com> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
48c1026a |
|
16-Jan-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Enum forcewake domains and domain identifiers Make the domains and domain identifiers enums. To emphasize the difference in order to avoid mistakes. v2: s/fw_domain/forcewake_domain (Jani) v3: rebase Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
59bad947 |
|
16-Jan-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Rename the forcewake get/put functions We have multiple forcewake domains now on recent gens. Change the function naming to reflect this. v2: More verbose names (Chris) v3: Rebase v4: Rebase v5: Add documentation for forcewake_get/put Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
756c349d |
|
16-Jan-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Make vlv and chv forcewake put generic. These two were using a fw dance logic where posting read was done after both domain bit were set. When in other gens, the posting read is done immediately after setting the forcewake bit for each domain. Now bring these in line with other gens. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
05a2fb15 |
|
19-Jan-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Consolidate forcewake code As we now have forcewake domains, take advantage of it by putting the differences in gen fw handling in data rather than in code. In past we have opencoded this quite extensively as the fw handling is in the fast path. There has also been a lot of cargo-culted copy'n'pasting from older gens to newer ones. Now when the releasing of the forcewake is done by deferred timer, it gives chance to consolidate more. Due to the frequency of actual hw access being significantly less. Take advantage of this and generalize the fw handling code as much as possible. But we still aim to keep the forcewake sequence particularities for each gen intact. So the access pattern to fw engines should remain the same. v2: - s/old_ack/clear_ack (Chris) - s/post_read/posting_read (Chris) - less polite commit msg (Chris) v3: - rebase - check and clear wake_count in init v4: - fix posting reads for gen8 (PRTS) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b2cff0db |
|
16-Jan-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reduce duplicated forcewake logic Introduce a structure to track the individual forcewake domains and use that to eliminate duplicate logic. v2: - Rebase on latest dinq (Mika) - for_each_fw_domain macro (Mika) - Handle reset atomically, keeping the timer running (Mika) - for_each_fw_domain parameter ordering (Chris) - defer timer on new register access (Mika) v3: - Fix forcewake_reset/get race by waiting pending timers v4: - cond_resched and verbose warning on timer deletion (Chris) - need to run pending timers manually on reset Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Acked-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
51f67885 |
|
16-Jan-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Skip uncore lock on earlier gens With gen < 6 we don't need to take uncore lock as we don't have anything to protect from concurrent access. v2: rebase and account for gen9 changes Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6daccb0b |
|
16-Jan-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Assert that runtime pm is active on user fw access On user forcewake access, assert that runtime pm reference is held. Fix and cleanup the callsites accordingly. v2: Remove intel_runtime_pm_get() rebasehap (Deepak) v3: use drivers own runtime state tracking as pm_runtime_active() will return wrong results when we are in resume callchain (Mika) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
dc9fb09c |
|
16-Jan-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rebalance runtime pm vs forcewake Calling intel_runtime_pm_put() is illegal from a soft-irq context, so revert the crude hack commit aa0b3b5bb8768c1a6a6788869d9c7015eae7e80c Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Apr 1 14:55:07 2014 -0300 drm/i915: don't schedule force_wake_timer at gen6_read and apply the single line corrective instead. v2: assert forcewake is off after the forcewake_reset (Paulo) References: https://bugs.freedesktop.org/show_bug.cgi?id=80913 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
db5ff4ac |
|
11-Dec-2014 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915: Forcewake Register Range changes for CHV According to updated BSpec, Render/Common/media Wells register range changed. Updating the same to match the spec and avoid extra forcewake for none forcewake range. v2: Update media forcewake range (Ville) Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5f77eeb0 |
|
08-Dec-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON Faster feedback to errors is always better. This is inspired by the addition to WARN_ONs to mask/enable helpers for registers to make sure callers have the arguments ordered correctly: Pretty much always the arguments are static. We use WARN_ON(1) a lot in default switch statements though where we should always handle all cases. So add a new macro specifically for that. The idea to use __builtin_constant_p is from Chris Wilson. v2: Use the ({}) gcc-ism to avoid the static inline, suggested by Dave. My first attempt used __cond as the temp var, which is the same used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so sprinkle i915 into the name. Also use a temporary variable to only evaluate the condition once, suggested by Damien. v3: It's crazy but apparently 32bit gcc can't compile out the BUILD_BUG_ON in a lot of cases and just falls over. I have no idea why, but until clue grows just disable this nifty idea on 32bit builds. Reported by 0-day builder. v4: Got it all wrong, apparently its the gcc version. We need 4.9+. Now reported by Imre. v5: Chris suggested to add the case to MISSING_CASE for speedier debug. v6: Even some gcc 4.9 versions don't see through the maze, so give up for now. Keep the skeleton and MISSING_CASE stuff though. Cc: Imre Deak <imre.deak@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
8ee558d8 |
|
24-Nov-2014 |
Akash Goel <akash.goel@intel.com> |
drm/i915/skl: Update in Gen9 multi-engine forcewake range Updates in forcewake range for Render/Media/Common power wells for Gen9. Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f98ce92f |
|
21-Nov-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disable crtcs gracefully before GPU reset on gen3/4 The GPU reset also resets the display on gen3/4. The g33 docs say we should disable all planes before flipping the reset switch. Just disable all the crtcs instead. That seems a nicer thing to do anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
408d4b9e |
|
21-Nov-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement GPU reset for g33 g33 seems to sit somewhere between the 915/945/965 style and the g4x style. The bits look like g4x, but we still need to do a full reset including display. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
59ea9054 |
|
21-Nov-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement GPU reset for 915/945 915/945 have the same reset registers as 965, so share the code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
73bbf6bd |
|
21-Nov-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix gen4 GPU reset On pre-ctg the reset bit directly controls the reset signal. We must assert it for >=20usec and then deassert it. Bit 1 is a RO status bit which should also go down when the reset is no longer asserted. Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2b387059 |
|
24-Nov-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only warn the first time we attempt to mmio whilst suspended In all likelihood we will do a few hundred errnoneous register operations if we do a single invalid register access whilst the device is suspended. As each instance causes a WARN, this floods the system logs and can make the system unresponsive. The warning was first introduced in commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 21 13:52:25 2014 -0300 drm/i915: call assert_device_not_suspended at gen6_force_wake_work and despite the claims the WARN is still encountered in the wild today. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7c859007 |
|
20-Nov-2014 |
Zhe Wang <zhe1.wang@intel.com> |
drm/i915: Gen9 shadowed registers For MMIO registers which are shadowed, force wake is not needed to write to these registers. v2: Rebase on top of nightly (Damien) v3: Rebase on top of "Gen9 multiple-engine forcewake" changes v4: (Mika, Bob, done by Damien) - Reorder the shadowed registers by popularity Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4597a88a |
|
20-Nov-2014 |
Zhe Wang <zhe1.wang@intel.com> |
drm/i915/skl: Gen9 multi-engine forcewake Enable multi-engine forcewake for Gen9. v2: (Damien) - Rebase on top of nightly - Move the register range definitions to intel_uncore.c - Whitespace fixes v3: (Addressing Mika's comment, done by Damien) - Use REG_RANGE() (introduced after the patch was written) - Add a SKL_NEEDS_FORCE_WAKE() macro that gets rid of a useless comparison to FORCEWAKE (reg 0xa18c is not used on SKL) v4: (Damien) - Use newly introduced ASSIGN_READ/WRITE_MMIO_VFUNCS() macros Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2fe486c7 |
|
13-Nov-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Drop WaRsForcewakeWaitTC0:vlv GEN6_GT_THREAD_STATUS_REG doesn't seem to exist on VLV. Reads just give 0x0 no matter what the state of the render and media wells. There was also some hint in the Gunit HAS that thread status not being needed on VLV, and hence dropped when bringing stuff over from the IVB design. Not really a definite comment about the specific register itself though. Also the w/a itself is no longer listed for VLV in the database. It was there some time ago in the past, but I guess someone figured out the mistake and dropped it. So let's just drop it from the code as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
eb88bd1b |
|
13-Nov-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Drop the HSW special case from __gen6_gt_wait_for_thread_c0() Bits [18:16] of GEN6_GT_THREAD_STATUS_REG have always had the same meaning since SNB. So treating them as something special for HSW doesn't make sense to me. Also the bits *seem* to work exactly the same way on IVB, HSW GT2 and HSW GT3. At least intel_reg_read gives the identical results on all platforms with and without forcewake. Also the HSW PM guide rev 0.99 (ww05 2013) doesn't say anything about those bits. It just says to poll for bits [2:0]. As does the more recent BDW PM guide. So just drop the HSW special case and treat all platforms the same way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c549f738 |
|
10-Nov-2014 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Wait thread status on gen8+ fw sequence As per latest pm guide, we need to do this also on past hsw. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
95009861 |
|
05-Nov-2014 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
Revert "drm/i915/vlv: Remove check for Old Ack during forcewake" This reverts commit 5cb13c07dae73380d8b3ddc792740487b8742938. While the relevance for WaRsDontPollForAckOnClearingFWBits is under investigation, revert this as regression. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85684 Tested-by: Tested-by: lu hua <huax.lu@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: S, Deepak <deepak.s@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
38cff0b1 |
|
04-Nov-2014 |
Zhe Wang <zhe1.wang@intel.com> |
drm/i915/skl: Gen9 Forcewake Implement common forcewake functions shared by Gen9 features. v2: Make the focewake_{get,put} functions static (Mika) Small coding style fix in the function definition (Damien) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v2) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ed493883 |
|
23-Oct-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: check for GT faults in all resume handlers and driver load time Checking for GT faults is not specific in any way to S4 thaw, so do it also during S3 resume, S4 restore and driver load time. This allows us to unify the Sx handlers in an upcoming patch. v2: - move the check to intel_uncore_early_sanitize(), so we check at driver load time too (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
43d942a7 |
|
23-Oct-2014 |
Yu Zhang <yu.c.zhang@linux.intel.com> |
drm/i915: use macros to assign mmio access functions This is beautification prep work since vgt will add even more special cases. With these macros it's much easier to see what's going on really. Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> [danvet: #undef the temporary macros after the function again. And write a commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c3f59a67 |
|
30-Mar-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Allow the reg_read ioctl to return RCS_TIMESTAMP Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5cb13c07 |
|
18-Sep-2014 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915/vlv: Remove check for Old Ack during forcewake Based on the HW team inputs. We can should not wait for the old ack, Waiting for old ack might fail, when other forcewake came before the present one is desserted. for example, if forcewake bit 0 was set and before it could get cleared forcewake bit 1 got set, HW eventually clear bit 0, when the bit 1 is cleared. i.e, bit 1 is still sent then forcewake bit 0 will still be set. Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Add comment Ville requested.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f98cd096 |
|
03-Sep-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use IS_BROADWELL() instead of IS_GEN8() in forcewake code IS_GEN8() is a bad check in the forcewake code due to bdw vs. chv differences. Use IS_BROADWELL() instead. The only actual bug here is that we currently call __gen7_gt_force_wake_mt_reset() on chv. On the other places we have checked for chv before using IS_GEN8(), but change them to use IS_BROADWELL() anyway to reduce the chance of accidents in the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
66bc2cab |
|
16-Jul-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: BDW can also detect unclaimed registers By the time I wrote this patch, it allowed me to catch some problems. But due to patch reordering - in order to prevent fake "regression" reports - this patch may be merged after the fixes of the problems identified by this patch. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5978118c |
|
16-Jul-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: reorganize the unclaimed register detection code The current code only runs when we do an I915_WRITE operation. It checks if the unclaimed register flag is set before we do the operation, and then it checks it again after we do the operation. This double check allows us to find out if the I915_WRITE operation in question is the bad one, or if some previous code is the bad one. When it finds a problem, our code uses DRM_ERROR to signal it. The good thing about the current code is that it detects the problem, so at least we can know we did something wrong. The problem is that even though we find the problem, we don't really have much information to actually debug it. So whenever I see one of these DRM_ERROR messages on my systems, the first thing I do is apply a patch to change the DRM_ERROR to a WARN and also check for unclaimed registers on I915_READ operations. This local patch makes things even slower, but it usually helps a lot in finding the bad code. The first point here is that since the current code is only useful to detect whether we have a problem or not, but it is not really good to find the cause of the problem, I don't think we should be checking both before and after every I915_WRITE operation: just doing the check once should be enough for us to quickly detect problems. With this change, the code that runs by default for every single user will only do 1 read operation for every single I915_WRITE, instead of 2. This patch does this change. The second point is that the local patch I have should be upstream, but since it makes things slower it should be disabled by default. So I added the i915.mmio_debug option to enable it. So after this patch, this is what will happen: - By default, we will try to detect unclaimed registers once after every I915_WRITE operation. Previously we tried twice for every I915_WRITE. - When we find an unclaimed register we will still print a DRM_ERROR message, but we will now tell the user to try again with i915.mmio_debug=1. - When we use i915.mmio_debug=1 we will try to find unclaimed registers both before and after every I915_READ and I915_WRITE operation, and we will print stack traces in case we find them. This should really help locating the exact point of the bad code (or at least finding out that i915.ko is not the problem). This commit also opens space for really-slow register debugging operations on other platforms. In theory we can now add lots and lots of debug code behind i915.mmio_debug, enable this option on our tests, and catch more problems. v2: - Remove not-so-useful comments (Daniel) - Fix the param definition macros (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
821d66dd |
|
03-Jul-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915: Emphasize that ctx->id is merely a user handle This is an Execlists preparatory patch, since they make context ID become an overloaded term: - In the software, it was used to distinguish which context userspace was trying to use. - In the BSpec, the term is used to describe the 20-bits long field the hardware uses to it to discriminate the contexts that are submitted to the ELSP and inform the driver about their current status (via Context Switch Interrupts and Context Status Buffers). Initially, I tried to make the different meanings converge, but it proved impossible: - The software ctx->id is per-filp, while the hardware one needs to be globally unique. - Also, we multiplex several backing states objects per intel_context, and all of them need unique HW IDs. - I tried adding a per-filp ID and then composing the HW context ID as: ctx->id + file_priv->id + ring->id, but the fact that the hardware only uses 20-bits means we have to artificially limit the number of filps or contexts the userspace can create. The ctx->user_handle renaming bits are done with this Cocci patch (plus manual frobbing of the struct declaration): @@ struct intel_context c; @@ - (c).id + c.user_handle @@ struct intel_context *c; @@ - (c)->id + c->user_handle Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE and change the type to unsigned 32 bits. v2: s/handle/user_handle and change the type to uint32_t as suggested by Chris Wilson. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
10018603 |
|
05-Jun-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: preserve user forcewake over system suspend/resume Atm, the forcewake refcount will be incorrectly set to zero during system suspend if there is any reference held via the i915_forcewake_user debugfs entry. Fix this by simply not zeroing the sw counters during suspend and restoring the original state using them. Note that the only other places where we zeroed the counters were driver load and unload time, where it was redundant anyway. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78059 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9e31c2a5 |
|
06-Jun-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix possible refcount leak when resetting forcewake If the timer putting the last forcewake refcount was pending and we canceled it, we'll leak the corresponding forcewake and RPM references. v2: - do the ptr casting at the caller instead of adding a separate helper for this (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
156c7ca0 |
|
12-Jun-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: leave rc6 enabled at suspend time v4 This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
542c184f |
|
03-Jun-2014 |
Robert Beckett <robert.beckett@intel.com> |
drm/i915: Simplify intel_gpu_reset Replaced ever growing switch for gen version with chained conditionals. Futre gen's only need to add a new one if they require something different. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Robert Beckett <robert.beckett@intel.com> [danvet: Picked from internal tree and white-wash commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ab53c267 |
|
23-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/chv: Skip gen6_gt_check_fifodbg() on CHV CHV uses the gen8 shadow register mechanism so we shouldn't be checking the GT FIFO status. This effectively removes the posting read, so add an explicit posting read using FORCEWAKE_ACK_VLV (which is what use in vlv_forcewake_reset()). Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3f4e3495 |
|
23-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/chv: CHV doesn't need WaRsForcewakeWaitTC0 Skip __gen6_gt_wait_for_thread_c0() on CHV. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1938e59a |
|
23-May-2014 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915/chv: Added CHV specific register read and write and Streamline CHV forcewake stuff Support to individually control Media/Render well based on the register access. Add CHV specific write function to habdle difference between registers that are sadowed vs those that need forcewake even for writes. Streamline the CHV forcewake functions just like was done for VLV. This will also fix a bug in accessing the common well registers, where we'd end up trying to wake up the wells too many times since we'd call force_wake_get/put twice per register access, with FORCEFAKE_ALL both times. v2: Drop write FIFO for CHV and add comman well forcewake (Ville) Re-factor CHV/VLV Forcewake offsets (Ben) v3: Fix for decrementing fw count in chv read/write. (Deepak) v4: Squash the patches (Mika) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [vsyrjala: Move the register range macros into intel_uncore.c] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
329ff963 |
|
06-Jun-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix possible refcount leak when resetting forcewake If the timer putting the last forcewake refcount was pending and we canceled it, we'll leak the corresponding forcewake and RPM references. v2: - do the ptr casting at the caller instead of adding a separate helper for this (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
de076046 |
|
23-May-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915/vlv: drop power well enable in uncore_sanitize We do this at runtime and later on now. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
85ab3998 |
|
22-May-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Disable gpu reset on i965g/gm Ville figured out that it needs a full display reset since apparently a lot more goes down than just the GT. Until that's address it's better to just diable gpu reset. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
273497e5 |
|
22-May-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915: s/i915_hw_context/intel_context Up until now, contexts had one (and only one) backing object that was used by the hardware to save/restore render ring contexts (via the MI_SET_CONTEXT command). Other rings did not have or need this, so our i915_hw_context struct had a 1:1 relationship with a a real HW context. With Logical Ring Contexts and Execlists, this is not possible anymore: all rings need a backing object, and it cannot be reused. To prepare for that, rename our contexts to the more generic term intel_context. No functional changes. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fa4f53c4 |
|
19-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement WaVcpClkGateDisableForMediaReset:ctg, elk Apparently we need to disable VCP unit clock gating around media reset on g4x. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9aa7250f |
|
19-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clear GDSR after reset on ILK Clear the reset domain after a succesful GPU reset on ilk. We already do that on gen4, so let's try to be a bit more consistent. And if ether render or media reset fails, we might use the leftover value in the register to pinpoint the culprit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0f08ffd6 |
|
19-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Kill RMW from ILK reset code All the other bits in the GDSR register are read-only, so we don't have to preserve them when we perform a GPU reset. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b3a3f03d |
|
19-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix ILK GPU reset domain bits We're using the reset domains bits for g4x on ilk. But on ilk those bits actually shifted by one bit. Fix it up so that we use the correct bits. We were actually always writing 0x2 to the reset domain bits, which is a reserved value. In practice it looks like the hardware ignores that value since nothing happens if I write that value when there's a 3D workload running. Writing the _correct_ render domain value actually makes the GPU stop. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f67deb72 |
|
19-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix ILK reset wait We should be waiting for the reset bit to clear, not remain set. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a83d87fd |
|
19-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Drop bogus comments about display reset There are comments in the gen4-5 reset functions stating that we can't reset render and media without also doing a display reset. But that's exactly what the code does, ie. we don't perform a display reset. Drop the bogus comments. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
05adaf1f |
|
09-May-2014 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/vlv: reset VLV media force wake request register Media force wake get hangs the machine when the system is booted without displays attached. The assumption is that (at least some versions of) the firmware has skipped some initialization in that case. Empirical evidence suggests we need to reset the media force wake request register in addition to the render one to avoid hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895 Reported-by: Imre Deak <imre.deak@intel.com> Reported-by: Darren Hart <dvhart@linux.intel.com> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
1d2866ba |
|
18-Apr-2014 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915/bdw: enable eDRAM. The same register exists for querying and programming eDRAM AKA eLLC. So we can simply use it. For now, use all the same defaults as we had for Haswell, since like Haswell, I have no further details. I do not actually have a part with eDRAM, so I cannot test this. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
af76ae44 |
|
31-Mar-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Use a macro to express the range of valid gens for reg_read The reg_read whitelist has a gen bitmask to code the gens we're allowing the register to be read on. Until now, it was a literal, but we can be a bit more expressive. To ease the review, a small test program: $ cat bit-range.c #include <stdio.h> #include <stdint.h> #define U32_C(x) x ## U #define GENMASK(h, l) (((U32_C(1) << ((h) - (l) + 1)) - 1) << (l)) #define GEN_RANGE(l, h) GENMASK(h, l) int main(int argc, char **argv) { printf("0x%08x\n", GEN_RANGE(1, 1)); printf("0x%08x\n", GEN_RANGE(1, 2)); printf("0x%08x\n", GEN_RANGE(4, 4)); printf("0x%08x\n", GEN_RANGE(4, 5)); printf("0x%08x\n", GEN_RANGE(1, 31)); printf("0x%08x\n", GEN_RANGE(4, 8)); return 0; } $ ./bit-range 0x00000002 0x00000006 0x00000010 0x00000030 0xfffffffe 0x000001f0 Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
38fb6a40 |
|
28-Mar-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Hide the per forcewake-engine register ranges These defines are only used in intel_uncore.c. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b88b23d9 |
|
28-Mar-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Hide vlv_force_wake_{get, put}() in intel_uncore.c That function isn't used outside this file anymore. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cf67c70f |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: get runtime PM at i915_reg_read_ioctl To avoid WARNs when we call it. Testcase: igt/pm_pc8/reg-read-ioctl Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75693 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
aa0b3b5b |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't schedule force_wake_timer at gen6_read So far force_wake_timer was only used by gen6_gt_force_wake_put. Since we always had balanced gen6_gt_force_wake_get/put calls, we could guarantee balanced calls to intel_runtime_pm_get/put. Commit 8232644ccf099548710843e97360a3fcd6d28e04, "drm/i915: Convert the forcewake worker into a timer func" started scheduling the force_wake_timer at gen6_read, which resulted in an unbalanced runtime_pm refcount. So this commit just reverts to the old behavior until we can find a proper way to used delayed force_wake from the register read/write macros without leaving the runtime_pm refcounts unbalanced and without runtime suspending the driver while forcewake is active. Testcase: igt/pm_pc8/rte Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76544 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3123fcaf |
|
15-Mar-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: catch forcewake reference underruns Without this the new drv_suspend/forcewake subtest I've created doesn't result in immediately visible failures. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
05efeebd |
|
18-Mar-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fix up the forcewake timer initialization This is a regression introduced in commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Mar 13 12:00:29 2014 +0000 drm/i915: Consolidate forcewake resetting to a single function The reordered setup sequence ended up calling del_timer_sync before the timer was set up correctly, resulting in endless hilarity when loading the driver. Compared to Ben's patch (which moved around the setup_timer call to sanitize_early) this moves the sanitize_early call around in the driver load call. This way we avoid calling setup_timer again in the resume code (where we also call sanitize_early). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76242 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0294ae7b |
|
12-Mar-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Consolidate forcewake resetting to a single function We have two paths that try to reset the forcewake registers back to known good values, with slightly different semantics and levels of paranoia. Combine the two by passing a parameter to either restore the forcewake status or to clear our bookkeeping, and raise the paranoia level to max. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
28d85cd3 |
|
13-Mar-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reset forcewake before suspend Now that we regularly defer the forcewake dance to a timer func, it is likely to fire after we disable the device during suspend. This generates an oops as we detect inconsistency in the hardware state. So before suspend, we want to complete the outstanding dance and generally sanitize the registers before handing back to the BIOS. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a30180a5 |
|
04-Mar-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: sanitize PUNIT register macro definitions In the upcoming patches we'll need to access the rest of the fields in the punit power gating register, so prepare for that. v2: - add doc reference for the power well subsystem IDs (Jesse) - remove IDs for non-existant DPIO_RX[23] subsystems (Jesse) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5babf0fc |
|
05-Mar-2014 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: No need to put forcewake after a reset As we now have intel_uncore_forcewake_reset() no need to do explicit put after reset. v2: rebase Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6a68735a |
|
21-Feb-2014 |
Mika Kuoppala <mika.kuoppala@intel.com> |
drm/i915: Don't access fifodbg registers on gen8 as they don't exists. v2: rename gen6_*_mt_* to gen7_*_mt_* as they never get called with gen6 (Chris) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0a089e33 |
|
21-Feb-2014 |
Mika Kuoppala <mika.kuoppala@intel.com> |
drm/i915: Do forcewake reset on gen8 When we get control from BIOS there might be mt forcewake bits already set. This causes us to do double mt get without proper clear/ack sequence. Fix this by clearing mt forcewake register on init, like we do with older gens. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6fe72865 |
|
27-Feb-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Streamline VLV forcewake handling It occured to me that when we're trying to wake up both render and media wells on VLV, we might end up calling the low level force_wake_get/put two times even though one call would be enough. Make that happen by figuring out which wells really need to be woken up based on the forcewake counts. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:Deepak S <deepak.s@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fc9d83f7 |
|
24-Feb-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Drop the forcewake count inc/dec around register read on VLV VLV is the only platform where we increment/decrement the forcewake count around register access. Drop the inc/dec on VLV to make the forcewake code a bit more unified. The inc/dec are not necessary since we hold the uncore lock around the whole operation. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ee7fa12c |
|
24-Feb-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix VLV forcewake after reset Use the render/media specific forcewake counts to properly restore the forcewake status after a GPU reset on VLV. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6f0ea9e2 |
|
21-Feb-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: assert we're not runtime suspended when accessing registers I could swear this was already happening in the current code... Also, put the reads and writes in a generic place, so we don't forget it again when we add runtime PM support to new platforms. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e998c40f |
|
21-Feb-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: assert force wake is disabled when we runtime suspend Just to be sure... Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b2ec142c |
|
21-Feb-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: call assert_device_not_suspended at gen6_force_wake_work Because we shouldn't be runtime suspended when forcewake is supposed to be enabled. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Update commit message - no WARN expected since the bugfix for issues hit with this assert is already in. And resolve conflicts with the change from worker to timer for the delayed fw release.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6d88064e |
|
21-Feb-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: put runtime PM only when we actually release force_wake When we call gen6_gt_force_wake_put we don't actually put force_wake, we just schedule gen6_force_wake_work through mod_delayed_work, and that will eventually release force_wake. The problem is that we call intel_runtime_pm_put directly at gen6_gt_force_wake_put, so most of the times we put our runtime PM reference before the delayed work happens, so we may runtime suspend while force_wake is still supposed to be enabled if the graphics autosuspend_delay_ms is too small. Now the nice thing about the current code is that after it triggers the delayed work function it gets a refcount, and it only triggers the delayed work function if refcount is zero. This guarantees that when we schedule the funciton, it will run before we try to schedule it again, which simplifies the problem and allows for the current solution to work properly (hopefully!). v2: - Keep the VLV refcounts balanced (Jesse) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8232644c |
|
04-Mar-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert the forcewake worker into a timer func We don't want to suffer scheduling delay when turning off the GPU after waking it up to touch registers. Ideally, we only want to keep the GPU awake for the register access sequence, with a single forcewake dance on the first access and release immediately after the last. We set a timer on the first access so that we only dance once and on the next scheduler tick, we drop the forcewake again. This moves the cleanup routine from the common i915 workqueue to a timer func so that we don't anger powertop, and drop the forcewake again quicker. v2: Enable the deferred force_wake_put for regular register reads as well. v3: Beautification and make sure we disable forcewake when shutting down. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e9dbd2b2 |
|
18-Feb-2014 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Fix forcewake counts for gen8 Sometimes generic driver code gets forcewake explicitly by gen6_gt_force_wake_get(), which check forcewake_count before accessing hardware. However the register access with gen8_write function access low level hw accessors directly, ignoring the forcewake_count. This leads to nested forcewake get from hardware, in ring init and possibly elsewhere, causing forcewake ack clear errors and/or hangs. Fix this by checking the forcewake count also in gen8_write v2: Read side doesn't care about shadowed registers, Remove __needs_put funkiness from gen8_write. (Ville) Improved commit message. References: https://bugs.freedesktop.org/show_bug.cgi?id=74007 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
43181011 |
|
21-Jan-2014 |
Kenneth Graunke <kenneth@whitecape.org> |
drm/i915: Allow reading the TIMESTAMP register on Gen8. Nothing's changed here; we just need to bump the generation check. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
41bde553 |
|
06-Dec-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Get context early in execbuf We need to have the address space when reserving space for the objects. Since the address space and context are tied together, and reserve occurs before context switch (for good reason), we must lookup our context earlier in the process. This leaves some room for optimizations where we no longer need to use ctx_id in certain places. This will be addressed in a subsequent patch. Important tricky bit: Because slow relocations during execbuffer drop struct_mutex Perhaps it would be best to acquire the reference when we get the context, but I'll save that for another day (note I have written the patch before, and I found the changes required to be uglier than this). Note that since we currently access everything via context id, and not the data structure this is fine, though not desirable. The next change attempts to get the context only once via the context ID idr lookup, and as such, the following can happen: CTX-A is created, refcount = 1 CTX-A execbuf, mutex dropped close IOCTL called on CTX-A, refcount = 0 CTX-A resumes in execbuf. v2: Rebased on top of commit b6359918b885da7c7b58c050674278dbd06020ab Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Wed Oct 30 15:44:16 2013 +0200 drm/i915: add i915_get_reset_stats_ioctl v3: Rebased on top of commit 25b3dfc87bff80317d67ddd2cd4cfb91e6fe7d79 Author: Mika Westerberg <mika.westerberg@linux.intel.com> Date: Tue Nov 12 11:57:30 2013 +0200 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Tue Nov 26 16:14:33 2013 +0200 drm/i915: check context reset stats before relocations Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a3564d2b |
|
13-Dec-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/bdw: Don't use forcewake needlessly Not all registers need forcewake even if they're not shadowed. Add the missing check to gen8_writeX() to avoid needless forcewake usage when writing eg. display registers. v2: Use straight up <0x40000 check instead of NEEDS_FORCE_WAKE() Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
97058870 |
|
03-Dec-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clear out old GT FIFO errors in intel_uncore_early_sanitize() The BIOS or someone else might have done something bad and there might be old GT FIFO erros reported in GTFIFODBG. Clear those out in intel_uncore_early_sanitize() to make sure we don't mistake them for our problems. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c8c8fb33 |
|
27-Nov-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add some runtime PM get/put calls These are needed when we cat the debugfs and sysfs files. V2: - Rebase V3: - Rebase V4: - Rebase Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8a187455 |
|
06-Dec-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add initial Runtime PM functions This patch adds the initial infrastructure to allow a Runtime PM implementation that sets the device to its D3 state. The patch just adds the necessary callbacks and the initial infrastructure. We still don't have any platform that actually uses this infrastructure, we still don't call get/put in all the places we need to, and we don't have any function to save/restore the state of the registers. This is not a problem since no platform uses the code added by this patch. We have a few people simultaneously working on runtime PM, so this initial code could help everybody make their plans. V2: - Move some functions to intel_pm.c - Remove useless pm_runtime_allow() call at init - Remove useless pm_runtime_mark_last_busy() call at get - Use pm_runtime_get_sync() instead of 2 calls - Add a WARN to check if we're really awake V3: - Rebase. V4: - Don't need to call pci_{save,restore}_state and pci_set_power_sate, since they're already called by the PCI layer - Remove wrong pm_runtime_enable() call at init_runtime_pm Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c461562e |
|
08-Dec-2013 |
Deepak S <deepak.s@intel.com> |
drm/i915: Remove duplicate intel_uncore_forcewake_reset. Since early sanitize and uncore sanitize are called one after the other, I think, we can remove second forcewake reset which was are calling twice in both the functions. Note that this is merge fallout between commit ef46e0d247da0a7a408573aa15870e231bbd4af2 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Nov 16 16:00:09 2013 +0100 drm/i915: restore the early forcewake cleanup and commit 521198a2e7095c8c7daa8d7d3a76a110c346be6f Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset Signed-off-by: Deepak S <deepak.s@intel.com> [danvet: Explain how this came to be.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5135d64b |
|
29-Nov-2013 |
Deepak S <deepak.s@intel.com> |
drm/i915/vlv: Update Wait for FIFO and wait for 20 free entries. v3 On VLV, FIFO will be shared by both SW and HW. So, we read the free entries through register and update dev_priv variable and wait for only 20 entries to be free From Deepak's follow-up mail explaining why vlv is special: "On SB, Out of 64 FIFO Entries, 20 Entries will be used by HW and remaining 44 will be used by the SW,. I think due to this reason, we have a threshold of 20 Entries." "On VLV, HW and SW can access all 64 fifo entries, I don't think having a threshold of 20 Entries is mandatory on VLV. Also, since both SW and HW can access all 64 Entries. I think on VLV, we need to update the fifo_count before waiting for the FIFO." v2: Apply mask when we read the number of free FIFO entries (Ville). v3: Mask applied after reading the register (Deepak). Signed-off-by: Deepak S <deepak.s@intel.com> [danvet: Add further explanation from Deepak to commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0d965301 |
|
02-Dec-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add REG_WRITE_FOOTER Add a REG_WRITE_FOOTER macro as a counterpart to the REG_WRITE_HEADER. The current code has the spin_lock() in the HEADER, but the spin_unlock() is open coded, which looks rather confusing on the first glance. A bit of additional symmetry might help. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5bc0e85c |
|
27-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: make sparse happy for the new vlv mmio read function It doesn't like that we assign 0 to a pointer, it wants the real NULL. On closer look that initialization is actually bogus, and the compiler can easily see that we never use it unitialized. So let's just drop this. Cc: Deepak S <deepak.s@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
084054fc |
|
27-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: drop the right force-wake engine in the vlv mmio funcs This was fumbled in the conversion to per-engine forcewake. Cc: Deepak S <deepak.s@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
46520e2b |
|
13-Nov-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix GT wake FIFO free entries for VLV On VLV the GTFIFOCTL register has other bits besides the number of free entries in the GT wake FIFO. Apply a mask when we read th register to make sure we don't misinterpret the number of free FIFO entries. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: There's some unclarity about hsw, but brushed off as todays' Bspec just acting up a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
90f256b5 |
|
13-Nov-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Report all GTFIFODBG errors On VLV GTFIFODBG has more bits. Just report them all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
940aece4 |
|
23-Nov-2013 |
Deepak S <deepak.s@intel.com> |
drm/i915/vlv: Valleyview support for forcewake Individual power wells. Split vlv force wake routines to help individually control Media/Render well based on the register access. We've seen power savings in the lower sub-1W range on workloads that only need on of the power wells, e.g. glbenchmark, media playback Note: The same split isn't there for the forcewake queue, only the forcwake domains are split. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Rebase on top of the removed forcewake hack in the ring irq get/put code and add a note to add Deepak's answer to Chris question.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c8d9a590 |
|
23-Nov-2013 |
Deepak S <deepak.s@intel.com> |
drm/i915: Add power well arguments to force wake routines. Added power well arguments to all the force wake routines to help us individually control power well based on the scenario. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict with the removed forcewake hack and drop one spurious hunk Jesse noticed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f671d117 |
|
16-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: remove intel_uncore_clear_errors This was forgotten in commit 9d1cb9147dbe45f6e94dc796518ecf67cb64b359 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Nov 1 13:32:08 2013 -0200 drm/i915: avoid unclaimed registers when capturing the error state Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ef46e0d2 |
|
16-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: restore the early forcewake cleanup Some BIOS just leak the forcewak bits, which we clean up. Unfortunately this has been broken in commit 521198a2e7095c8c7daa8d7d3a76a110c346be6f Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset To make this work both for resets and for BIOS takeover just add the forcewake clearing call back to intel_uncore_early_sanitize. We need to clear the forcewake in early sanitize so that the forcewak dance in intel_uncore_init (to figure out whether we have mt or legacy forcewake on ivb) works. That cleanup fits in nicely with the general topic of early_sanitize to prepare for the very first mmio ops. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Jörg Otte <jrg.otte@gmail.com> Cc: Jörg Otte <jrg.otte@gmail.com> References: https://lkml.org/lkml/2013/11/16/40 Cc: stable@vger.kernel.org (for 3.12 only) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
935e8de9 |
|
07-Nov-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915/bdw: Do gen6 style reset for gen8 This patch existed before, but was lost over time. Note that reset is still somewhat problematic in my limited testing (ie. module_reload will not pass) but it can be disabled with a module parameter, and support should be considered preliminary anyway. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
661df041 |
|
12-Nov-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: check i915_get_reset_stats_ioctl args Insist that flags and pad fields are zero, so that we can safely extend the interface in future. Testcase: igt/gem_reset_stats/params Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b6359918 |
|
30-Oct-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: add i915_get_reset_stats_ioctl This ioctl returns reset stats for specified context. The struct returned contains context loss counters. reset_count: all resets across all contexts batch_active: active batches lost on resets batch_pending: pending batches lost on resets v2: get rid of state tracking completely and deliver only counts. Idea from Chris Wilson. v3: fix commit message v4: default context handled inside i915_gem_context_get_hang_stats v5: reset_count only for priviledged process v6: ctx=0 needs CAP_SYS_ADMIN for batch_* counters (Chris Wilson) v7: context hang stats never returns NULL v8: rebased on top of reworked context hang stats DRM_RENDER_ALLOW for ioctl v9: use DEFAULT_CONTEXT_ID. Improve comments for ioctl struct members Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ian Romanick <idr@freedesktop.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0f161f70 |
|
02-Nov-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915/bdw: Don't wait for c0 threads on forcewake It's no longer a required workaround on BDW. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Move compile fix from a later patch to this one.] Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
43d1b647 |
|
07-Nov-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915/bdw: Initialize BDW forcewake vfuncs Somehow this got missed or dropped during development. The simulator does not use forcewake, so it's entirely possible it never worked correctly. After the mmio rework, this will end up in an OOPs, and the system will not boot. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Use IS_GEN8 instead of IS_BROADWELL.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ab2aa47e |
|
02-Nov-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915/bdw: Handle forcewake for writes on gen8 GEN8 removes the GT FIFO which we've all come to know and love. Instead it offers a wider range of optimized registers which always keep a shadowed copy, and are fed to the GPU when it wakes. How this is implemented in hardware is still somewhat of a mystery. As far as I can tell, the basic design is as follows: If the register is not optimized, you must use the old forcewake mechanism to bring the GT out of sleep. [1] If register is in the optimized list the write will signal that the GT should begin to come out of whatever sleep state it is in. While the GT is coming out of sleep, the requested write will be stored in an intermediate shadow register. Do to the fact that the implementation details are not clear, I see several risks: 1. Order is not preserved as it is with GT FIFO. If we issue multiple writes to optimized registers, where order matters, we may need to serialize it with forcewake. 2. The optimized registers have only 1 shadowed slot, meaning if we issue multiple writes to the same register, and those values need to reach the GPU in order, forcewake will be required. [1] We could implement a SW queue the way the GT FIFO used to work if desired. NOTE: Compile tested only until we get real silicon. v2: - Use a default case to make future platforms also work. - Get rid of IS_BROADWELL since that's not yet defined, but we want to MMIO as soon as possible. v3: Apply suggestions from Mika's review: - s/optimized/shadowed/ - invert the logic of the helper so that it does what it says (the code itself was correct, just confusing to read). v4: - Squash in lost break. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ab484f8f |
|
05-Oct-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Remove gen specific checks in MMIO Now that MMIO has been split up into gen specific functions it is obvious when HAS_FPGA_DBG_UNCLAIMED, HAS_FORCE_WAKE are needed. As such, we can remove this extraneous condition. As a result of this, as well as previously existing function pointers for forcewake, we no longer need the has_force_wake member in the device specific data structure. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4032ef43 |
|
04-Oct-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Create GEN specific write MMIO Similar to the previous patch which implemented GEN specific reads; this patch does the same for writes. Writes have a bit of adding complexity due to the FPGA_DBG feature of HSW plus: gen[2-4]: nothing special gen5: ILK dummy write gen[6-7]: forcewake shenanigans gen[HSW}: forcewake shenanigans + FPGA_DBG I was a bit torn about whether or not to combine 6-HSW as one function, since the FPGA_DBG is cleanly separated, and it wouldn't make the 6-7 MMIO too messy. In the end, I chose the clearest possible solution which splits out HSW. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3967018e |
|
04-Oct-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Create GEN specific read MMIO Extracting the MMIO read functionality makes per gen handling a bit simpler, and the overall function a lot easier to read. The increasing complexity of reads doesn't get too bad as the generation number increases: gen[2-4]: Nothing special gen5: ILK dummy write workaround gen6+: forcewake shenanigans Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5d738795 |
|
04-Oct-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Extract common MMIO lines Just to make the churn and code duplication in upcoming patches a bit less, turn code which is common to all GEN MMIO functions into a macro. v2: Fix typo in subject Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0b274481 |
|
04-Oct-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Create MMIO virtual functions In preparation for having per GEN MMIO functions, create, and start using MMIO functions in our uncore data structure. This simply makes the transition easier by allowing us to just plug in the per GEN stuff later. For simplicity, I moved the intel_uncore_init() function down since those rely on static functions defined lower in the file. This is most of the churn in this patch. I made one unrelated change here by using off_t datatype for the offset of the register to write. I like the clarity that this brings to the code. If I did it as a separate patch, I am pretty certain it would get bikeshedded to oblivion. Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
18ce3994 |
|
04-Oct-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Move edram detection early_sanitize In order to be able to have virtual functions for the MMIO, we need to use the raw access function. To keep things simple, just move this to our early_sanitize code in uncore. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e252d07a |
|
07-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: rip out gen2 reset code At least on my i830M here it reliably results in hard system hangs nowadays. This is much worse than falling back to software rendering, so I think we should simply rip this out. After all we don't have any gpu reset for gen3 either, and there are a lot more of those still around. Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
02f4c9e0 |
|
03-Oct-2013 |
Chon Ming Lee <chon.ming.lee@intel.com> |
drm/i915/vlv: Turn off power gate for BIOS-less system. During system boot up, by default, the power gate for render, media and display well still power gated. Normally, BIOS will turn off the power gate. In the BIOS-less system, the driver need to turn off the power gate very early during driver load. v2: Move this to intel_uncore_sanitize to allow it to get call during resume path. (Daniel) v3: Remove redundant write 0 to DPIO_CTL, and use DPIO_RESET instead of just 0x1 (Ville) Add turn of power gate for display 2d/render well/media well. v4: Remove toggle cmnreset in intel_uncore_sanitize. Cmnreset should toggle after CRI clock source has been selected. Jesse DPIO reset patch which toggle the cmnreset in intel_modeset_init_hw() should handle it. (Ville) Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
aec347ab |
|
26-Aug-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Delay the release of the forcewake by a jiffie Obtaining the forcwake requires expensive and time consuming serialisation. And we often try to obtain the forcewake multiple times in very quick succession. We can reduce the overhead of these sequences by delaying the forcewake release, and so not hammer the hw quite so hard. I was hoping this would help with the spurious [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. found on Haswell. Alas not. v2: Fix teardown ordering - unmap the regs after turning off forcewake, and make sure we do turn off forcewake - both found by Ville. v3: As we introduce intel_uncore_fini(), use it to make sure everything is disabled before we hand back to the BIOS. Note: I have no claims for improved performance, stablity or power comsumption for this patch. We should not be hitting the registers often enough for this to improve benchmarks, but given the nature of our hw it is likely to improve long term stability. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
521198a2 |
|
23-Aug-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: sanitize forcewake registers on reset In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. Use same mechanism as intel_uncore_sanitize() does when loading driver to reset the forcewake bits, right after the chip has been reset. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ed71f1b4 |
|
19-Jul-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert the register access tracepoint to be conditional The TRACE_EVENT_CONDITION is supposed to generate more efficient code than if (cond) trace(), which is what we are currently using inside the register access functions. v2: Rebase onto uncore Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a7f31ee0 |
|
19-Jul-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Squash gen lookup through multiple indirections inside GT access The INTEL_INFO() macro extracts the dev_private pointer from the device, so passing in the dev_private->dev is a long winded circumlocution. v2: rebase onto uncore Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
dba8e41f |
|
19-Jul-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use the common register access functions for NOTRACE variants Detangle the confusion that NOTRACE variants of the register read/write routines were directly using the raw register access. We need for those routines to reuse the common code for serializing register access and ensuring the correct register power states. This is only possible now that the only routines that required raw access use their own API. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6af5d92f |
|
19-Jul-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use a private interface for register access within GT The GT functions for enabling register access also need to occasionally write to and read from registers. To avoid the potential recursion as we modify the public interface to be stricter, introduce a private register access API for the GT functions. v2: Rebase v3: Rebase onto uncore v4: Use raw interfaces consistently so that we only use the low-level readN functions from a single location. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
907b28c5 |
|
19-Jul-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Colocate all GT access routines in the same file Currently, the register access code is split between i915_drv.c and intel_pm.c. It only bares a superficial resemblance to the reset of the powermanagement code, so move it all into its own file. This is to ease further patches to enforce serialised register access. v2: Scan for random abuse of I915_WRITE_NOTRACE v3: Take the opportunity to rename the GT functions as uncore. Uncore is the term used by the hardware design (and bspec) for all functions outside of the GPU (and CPU) cores in what is also known as the System Agent. v4: Rebase onto SNB rc6 fixes Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Wrestle patch into applying and inline intel_uncore_early_sanitize (plus move the old comment to the new function). Also keep the _santize postfix for intel_uncore_sanitize.] [danvet: Squash in fixup spotted by Chris on irc: We need to call intel_pm_init before intel_uncore_sanitize since the later will call cancel_work on the delayed rps setup work the former initializes.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|