summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_uncore.c
AgeCommit message (Collapse)AuthorFilesLines
2020-10-20drm/i915: Drop runtime-pm assert from vgpu io accessorsChris Wilson1-1/+26
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
2020-10-10drm/i915: Update gen12 forcewake tableMatt Roper1-30/+99
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>
2020-10-10drm/i915: Rename FORCEWAKE_BLITTER to FORCEWAKE_GTMatt Roper1-50/+50
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>
2020-10-07drm/i915/dg1: Increase mmio size to 4MBVenkata Sandeep Dhanalakota1-0/+4
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
2020-09-16drm/i915: Initialise outparam for error return from wait_for_registerChris Wilson1-1/+2
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
2020-08-06Merge tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drmLinus Torvalds1-14/+16
Pull drm updates from Dave Airlie: "New xilinx displayport driver, AMD support for two new GPUs (more header files), i915 initial support for RocketLake and some work on their DG1 (discrete chip). The core also grew some lockdep annotations to try and constrain what drivers do with dma-fences, and added some documentation on why the idea of indefinite fences doesn't work. The long list is below. I do have some fixes trees outstanding, but I'll follow up with those later. core: - add user def flag to cmd line modes - dma_fence_wait added might_sleep - dma-fence lockdep annotations - indefinite fences are bad documentation - gem CMA functions used in more drivers - struct mutex removal - more drm_ debug macro usage - set/drop master api fixes - fix for drm/mm hole size comparison - drm/mm remove invalid entry optimization - optimise drm/mm hole handling - VRR debugfs added - uncompressed AFBC modifier support - multiple display id blocks in EDID - multiple driver sg handling fixes - __drm_atomic_helper_crtc_reset in all drivers - managed vram helpers ttm: - ttm_mem_reg handling cleanup - remove bo offset field - drop CMA memtype flag - drop mappable flag xilinx: - New Xilinx ZynqMP DisplayPort Subsystem driver nouveau: - add CRC support - start using NVIDIA published class header files - convert all push buffer emission to new macros - Proper push buffer space management for EVO/NVD channels. - firmware loading fixes - 2MiB system memory pages support on Pascal and newer vkms: - larger cursor support i915: - Rocketlake platform enablement - Early DG1 enablement - Numerous GEM refactorings - DP MST fixes - FBC, PSR, Cursor, Color, Gamma fixes - TGL, RKL, EHL workaround updates - TGL 8K display support fixes - SDVO/HDMI/DVI fixes amdgpu: - Initial support for Sienna Cichlid GPU - Initial support for Navy Flounder GPU - SI UVD/VCE support - expose rotation property - Add support for unique id on Arcturus - Enable runtime PM on vega10 boards that support BACO - Skip BAR resizing if the bios already did id - Major swSMU code cleanup - Fixes for DCN bandwidth calculations amdkfd: - Track SDMA usage per process - SMI events interface radeon: - Default to on chip GART for AGP boards on all arches - Runtime PM reference count fixes msm: - headers regenerated causing churn - a650/a640 display and GPU enablement - dpu dither support for 6bpc panels - dpu cursor fix - dsi/mdp5 enablement for sdm630/sdm636/sdm66 tegra: - video capture prep support - reflection support mediatek: - convert mtk_dsi to bridge API meson: - FBC support sun4i: - iommu support rockchip: - register locking fix - per-pixel alpha support PX30 VOP mgag200: - ported to simple and shmem helpers - device init cleanups - use managed pci functions - dropped hw cursor support ast: - use managed pci functions - use managed VRAM helpers - rework cursor support malidp: - dev_groups support hibmc: - refactor hibmc_drv_vdac: vc4: - create TXP CRTC imx: - error path fixes and cleanups etnaviv: - clock handling and error handling cleanups - use pin_user_pages" * tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm: (1747 commits) drm/msm: use kthread_create_worker instead of kthread_run drm/msm/mdp5: Add MDP5 configuration for SDM636/660 drm/msm/dsi: Add DSI configuration for SDM660 drm/msm/mdp5: Add MDP5 configuration for SDM630 drm/msm/dsi: Add phy configuration for SDM630/636/660 drm/msm/a6xx: add A640/A650 hwcg drm/msm/a6xx: hwcg tables in gpulist drm/msm/dpu: add SM8250 to hw catalog drm/msm/dpu: add SM8150 to hw catalog drm/msm/dpu: intf timing path for displayport drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3 drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845 drm/msm/dpu: move some sspp caps to dpu_caps drm/msm/dpu: update UBWC config for sm8150 and sm8250 drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250 drm/msm/a6xx: set ubwc config for A640 and A650 drm/msm/adreno: un-open-code some packets drm/msm: sync generated headers drm/msm/a6xx: add build_bw_table for A640/A650 drm/msm/a6xx: fix crashstate capture for A650 ...
2020-07-16treewide: Remove uninitialized_var() usageKees Cook1-1/+1
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>
2020-07-08drm/i915: Move the engine mask to intel_gt_infoDaniele Ceraolo Spurio1-1/+1
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
2020-07-08drm/i915: Use the gt in HAS_ENGINEDaniele Ceraolo Spurio1-7/+9
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
2020-07-06drm/i915: Print caller when tainting for CIMichał Winiarski1-2/+2
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
2020-06-22drm/i915/params: switch to device specific parametersJani Nikula1-4/+4
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
2020-06-01drm/i915: Relinquish forcewake immediately after manual groupingChris Wilson1-1/+1
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
2020-05-11drm/i915: Remove unused HAS_FWTABLE macroPascal Terjan1-5/+0
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
2020-04-17drm/i915/icl: Update forcewake firmware rangesRadhakrishna Sripada1-14/+17
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
2020-04-08drm/i915/uncore: prefer struct drm_device based loggingJani Nikula1-1/+1
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
2020-03-25drm/i915/selftests: Measure the energy consumed while in RC6Chris Wilson1-0/+22
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
2020-01-22drm/i915: Make WARN* drm specific where uncore or stream ptr is availablePankaj Bharadiya1-25/+27
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
2020-01-22drm/i915: Make WARN* drm specific where drm_priv ptr is availablePankaj Bharadiya1-1/+1
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
2020-01-10drm/i915/uncore: use new struct drm_device based macros.Wambui Karuga1-12/+13
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
2019-09-13drm/i915/tgl: Introduce gen12 forcewake rangesMichel Thierry1-1/+74
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
2019-09-13drm/i915: Update Gen11 forcewake rangesMika Kuoppala1-14/+9
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
2019-08-09drm/i915: split out uncore_mmio_debugDaniele Ceraolo Spurio1-27/+64
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
2019-08-07drm/i915: remove unnecessary includes of intel_display_types.h headerJani Nikula1-2/+0
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
2019-08-07drm/i915: rename intel_drv.h to display/intel_display_types.hJani Nikula1-1/+2
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
2019-08-07drm/i915: avoid including intel_drv.h via i915_drv.h->i915_trace.hJani Nikula1-0/+1
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
2019-08-02drm/i915: Add i915 to i915_inject_probe_failureMichal Wajdeczko1-1/+1
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
2019-08-02drm/i915: Fix documentation for __intel_wait_for_register_fw*Michal Wajdeczko1-2/+2
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
2019-08-02drm/i915/tgl: allow the reg_read ioctl to read the RCS TIMESTAMP registerJordan Justen1-1/+1
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
2019-07-12drm/i915: Replace "_load" with "_probe" consequentlyJanusz Krzysztofik1-1/+1
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
2019-07-08drm/i915: Explicitly track active fw_domain timersChris Wilson1-7/+8
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
2019-07-07drm/i915: Pull assert_forcewake_active() underneath the lockChris Wilson1-0/+4
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
2019-07-05drm/i915: Order assert forcewake testChris Wilson1-4/+3
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
2019-07-04drm/i915: Check caller held wakerefs in assert_forcewakes_activeChris Wilson1-0/+24
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
2019-06-20drm/i915/gvt: decouple check_vgpu() from uncore_init()Daniele Ceraolo Spurio1-2/+0
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
2019-06-20drm/i915: dynamically allocate forcewake domainsDaniele Ceraolo Spurio1-28/+73
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
2019-06-20drm/i915: skip forcewake actions on forcewake-less uncoreDaniele Ceraolo Spurio1-56/+87
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
2019-06-20drm/i915: kill uncore_to_i915Daniele Ceraolo Spurio1-12/+12
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
2019-06-20drm/i915: kill uncore_sanitizeDaniele Ceraolo Spurio1-9/+0
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
2019-06-20drm/i915: use vfuncs for reg_read/write_fw_domainsDaniele Ceraolo Spurio1-104/+68
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
2019-06-14drm/i915: update with_intel_runtime_pm to use the rpm structureDaniele Ceraolo Spurio1-1/+1
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
2019-06-14drm/i915: make enable/disable rpm assert function use the rpm structureDaniele Ceraolo Spurio1-6/+6
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
2019-06-14drm/i915: Remove rpm asserts that use i915Daniele Ceraolo Spurio1-6/+6
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
2019-06-10drm/i915: Convert i915_reg_read_ioctl to use explicit mmio accessorsTvrtko Ursulin1-9/+14
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
2019-05-08drm/i915: Reboot CI if forcewake failsChris Wilson1-2/+6
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
2019-04-08drm/i915: extract intel_pm.h from intel_drv.hJani Nikula1-4/+5
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
2019-04-03drm/i915: rename init/fini/prune uncore functionsDaniele Ceraolo Spurio1-3/+3
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
2019-04-03drm/i915: add intel_uncore_init_earlyDaniele Ceraolo Spurio1-0/+4
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
2019-03-29drm/i915: move the edram detection out of uncore initDaniele Ceraolo Spurio1-46/+0
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
2019-03-26drm/i915: take a reference to uncore in the engine and use itDaniele Ceraolo Spurio1-1/+1
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
2019-03-26drm/i915: switch intel_wait_for_register to uncoreDaniele Ceraolo Spurio1-9/+8
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
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-24 12:36:33 +0300