summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_drv.h
AgeCommit message (Collapse)AuthorFilesLines
2020-04-30drm/i915: Update DRIVER_DATE to 20200430Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-04-22Merge tag 'drm-misc-next-2020-04-14' of ↵Dave Airlie1-0/+3
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.8: UAPI Changes: - drm: error out with EBUSY when device has existing master - drm: rework SET_MASTER and DROP_MASTER perm handling Cross-subsystem Changes: - mm: export two symbols from slub/slob - fbdev: savage: fix -Wextra build warning - video: omap2: Use scnprintf() for avoiding potential buffer overflow Core Changes: - Remove drm_pci.h - drm_pci_{alloc/free)() are now legacy - Introduce managed DRM resourcesA - Allow drivers to subclass struct drm_framebuffer - Introduce struct drm_afbc_framebuffer and helpers - fbdev: remove return value from generic fbdev setup - Introduce simple-encoder helper - vram-helpers: set fence on plane - dp_mst: ACT timeout improvements - dp_mst: Remove drm_dp_mst_has_audio() - TTM: ttm_trace_dma_{map/unmap}() cleanups - dma-buf: add flag for PCIP2P support - EDID: Various improvements - Encoder: cleanup semantics of possible_clones and possible_crtcs - VBLANK documentation updates - Writeback documentation updates Driver Changes: - Convert several drivers to i2c_new_client_device() - Drop explicit drm_mode_config_cleanup() calls from drivers - Auto-release device structures with drmm_add_final_kfree() - Init bfdev console after registering DRM device - Make various .debugfs functions return 0 unconditionally; ignore errors - video: Use scnprintf() to avoid buffer overflows - Convert drivers to simple encoders - drm/amdgpu: note that we can handle peer2peer DMA-buf - drm/amdgpu: add support for exporting VRAM using DMA-buf v3 - drm/kirin: Revert change to register connectors - drm/lima: Add optional devfreq and cooling device support - drm/lima: Various improvements wrt. task handling - drm/panel: nt39016: Support multiple modes and 50Hz - drm/panel: Support Leadtek LTK050H3146W - drm/rockchip: Add support for afbc - drm/virtio: Various cleanups - drm/hisilicon/hibmc: Enforce 128-byte stride alignment - drm/qxl: Fix notify port address of cursor ring buffer - drm/sun4i: Improvements to format handling - drm/bridge: dw-hdmi: Various improvements Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200414090738.GA16827@linux-uq9g
2020-04-17drm/i915: Update DRIVER_DATE to 20200417Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-04-15drm/i915/tgl: Add Wa_14010477008:tglMatt Roper1-0/+2
Media decompression support should not be advertised on any display planes for steppings A0-C0. Bspec: 53273 Fixes: 2dfbf9d2873a ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine") Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200414211118.2787489-3-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-04-03drm/i915: Store cpu_transcoder_mask in device infoVille Syrjälä1-1/+1
We have a bunch of code that would like to know which CPU transcoders are actually present in the hardware. Rather than use various ad-hoc methods let's just include a full bitmask in the device info, alongside pipe_mask. v2: Rebase Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318170235.15176-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-04-02drm/i915/gem: Drop cached obj->bind_countChris Wilson1-0/+1
We cached the number of vma bound to the object in order to speed up shrinker decisions. This has been superseded by being more proactive in removing objects we cannot shrink from the shrinker lists, and so we can drop the clumsy attempt at atomically counting the bind count and comparing it to the number of pinned mappings of the object. This will only get more clumsier with asynchronous binding and unbinding. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200401223924.16667-1-chris@chris-wilson.co.uk
2020-03-26drm/i915: Use drmm_add_final_kfreeDaniel Vetter1-0/+3
With this we can drop the final kfree from the release function. The mock device in the selftests needed it's pci_device split up from the drm_device. In the future we could simplify this again by allocating the pci_device as a managed allocation too. v2: I overlooked that i915_driver_destroy is also called in the unwind code of the error path. There we need a drm_dev_put. Similar for the mock object. Now the problem with that is that the drm_driver->release callbacks for both the real driver and the mock one assume everything has been set up. Hence going through that path for a partially set up driver will result in issues. Quickest fix is to disable the ->release() hook until the driver is fully initialized, and keep the onion unwinding. Long term would be cleanest to move everything over to drmm_ release actions, but that's a lot of work for a big driver like i915. Plus more core work needed first anyway. v3: Fix i915_drm pointer wrangling in mock_gem_device. Also switch over to start using drm_dev_put() to clean up even on the error path. Aside I think the current error path is leaking the allocation. v4: more fixes for intel-gfx-ci, some if it damage from v3 :-/ Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-9-daniel.vetter@ffwll.ch
2020-03-26drm/i915: Drop final few uses of drm_i915_private.engineChris Wilson1-1/+0
We've migrated all the heavy users over to the intel_gt, and can finally drop the last few users and with that the mirror in dev_priv->engine[]. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200325234803.6175-1-chris@chris-wilson.co.uk
2020-03-24drm/i915/display/fbc: Make fences a nice-to-have for GEN9+José Roberto de Souza1-0/+1
dGFX has local memory so it does not have aperture or support CPU fences but even for iGFX it have a small number of fences. As replacement for fences to track frontbuffer modifications by CPU we have a software tracking that is already in used by FBC and PSR. PSR don't support fences so it shows that this tracking is reliable. So lets make fences a nice-to-have to activate FBC for GEN9+, this will allow us to enable FBC for dGFXs and iGFXs even when there is no available fence. We do not set fences to rotated planes but FBC only have restrictions against 16bpp, so adding it here. Also adding a new check for the tiling format, fences are only set to X and Y tiled planes but again FBC don't have any restrictions against tiling so adding linear as supported as well, other formats should be added after tested but IGT only supports drawing in thse 3 formats. intel_fbc_hw_tracking_covers_screen() maybe can also have the same treatment as fences but BSpec is not clear if the size limitation is for hardware tracking or general use of FBC and I don't have a 5K display to test it, so keeping as is for safety. v2: - Added tiling and pixel format rotation checks - Changed the GEN version not requiring fences to 11 from 9, DDX needs some changes but it don't have support for GEN11+ v3: - Changed back to GEN9+ - Moved GEN test to inside of tiling_is_valid() v4: - moved rotation check to its own functions v5: - renamed rotations_is_valid to rotation_is_valid - moved pre-g4x rotation check to rotation_is_valid() Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200319211535.114625-1-jose.souza@intel.com
2020-03-16drm/i915: Remove manual save/resume of fence register stateChris Wilson1-1/+0
Since we always reload the fence register state on runtime resume, having it explicitly in the S0ix resume code is redundant. Indeed, it is not even being used! 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/20200316113846.4974-3-chris@chris-wilson.co.uk
2020-03-16drm/i915: Move GGTT fence registers under gt/Chris Wilson1-1/+0
Since the fence registers control HW detiling through the GGTT aperture, make them a part of the intel_ggtt under gt/ 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/20200316113846.4974-1-chris@chris-wilson.co.uk
2020-03-13drm/i915: Update DRIVER_DATE to 20200313Rodrigo Vivi1-2/+2
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-03-06drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v5)Vivek Kasireddy1-0/+7
On some platforms such as Elkhart Lake, although we may use DDI D to drive a connector, we have to use PHY A (Combo Phy PORT A) to detect the hotplug interrupts as per the spec because there is no one-to-one mapping between DDIs and PHYs. Therefore, use the function intel_port_to_phy() which contains the logic for such mapping(s) to find the correct hpd_pin. This change should not affect other platforms as there is always a one-to-one mapping between DDIs and PHYs. v2: - Convert the case statements to use PHYs instead of PORTs (Jani) v3: - Refactor the function to reduce the number of return statements by lumping all the case statements together except PHY_F which needs special handling (Jose) v4: - Add a comment describing how the HPD pin value associated with any port can be retrieved using port or phy enum value. (Jani) v5: - Use case ranges instead of individual labels and also normalize the return statement by adding -PHY_A to the expression (Ville) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200304234240.12062-1-vivek.kasireddy@intel.com
2020-03-06drm/i915/gem: Limit struct_mutex to eb_reserveChris Wilson1-6/+0
We only need to serialise the multiple pinning during the eb_reserve phase. Ideally this would be using the vm->mutex as an outer lock, or using a composite global mutex (ww_mutex), but at the moment we are using struct_mutex for the group. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1381 Fixes: 003d8b9143a6 ("drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctl") 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/20200306071614.2846708-3-chris@chris-wilson.co.uk
2020-03-03drm/i915/gvt: only include intel_gvt.h where neededJani Nikula1-2/+0
i915_drv.c is the only caller. 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/20200227144408.24345-3-jani.nikula@intel.com
2020-03-03drm/i915/gvt: make intel_gvt_active internal to intel_gvtJani Nikula1-5/+0
Nobody else uses it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-2-jani.nikula@intel.com
2020-03-03drm/i915/vgpu: improve vgpu abstractionsJani Nikula1-5/+0
Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to intel_vgpu_detect() to match other function naming, un-inline intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and intel_vgpu_has_huge_gtt() to reduce header interdependencies. The i915_vgpu.[ch] filename and intel_vgpu_ prefix discrepancy remains. Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20200227144408.24345-1-jani.nikula@intel.com
2020-03-03drm/i915: move watermark structs more towards usageJani Nikula1-40/+0
Shrink i915_drv.h a bit by moving watermark structs where they are 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/20200227170047.31089-3-jani.nikula@intel.com
2020-03-02drm/i915: Unify the DPLL ref clock frequency trackingImre Deak1-0/+5
All platforms using the shared DPLL framework use 3 reference clocks for their DPLLs: SSC, non-SSC and DSI. For a more unified way across platforms store the frequency of these ref clocks as part of the DPLL global state. This also allows us to keep the HW access reading out the ref clock value separate from the DPLL frequency calculation that depends on the ref clock. For now add only the SSC and non-SSC ref clocks, as the pre-ICL DSI code has its own logic for calculating DPLL parameters instead of the shared DPLL framework. v2: - Apply the ICL combo PHY PLL ref_clock/2 adjustment during the frequency->PLL param conversion direction as well. (CI shards) - s/kHZ/kHz/ (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228153328.17842-1-imre.deak@intel.com
2020-03-02drm/i915: Keep the global DPLL state in a DPLL specific structImre Deak1-10/+12
For clarity add a new DPLL specific struct to the i915 device struct and move all DPLL fields into it. Accordingly remove the dpll_ prefixes, as the new struct already provides the required namespacing. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-4-imre.deak@intel.com
2020-03-02drm/i915: remove unused orig_clock i915 memberJani Nikula1-2/+0
Unused since commit f97108d1d0fa ("drm/i915: add dynamic performance control support for Ironlake"). That's a little over ten years. Good riddance. 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/20200227170047.31089-2-jani.nikula@intel.com
2020-03-02drm/i915: add i915_ioc32.h for compatJani Nikula1-5/+0
Keep reducing i915_drv.h. 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/20200227170047.31089-1-jani.nikula@intel.com
2020-03-02drm/i915/dram: hide the dram structs betterJani Nikula1-10/+0
Finish the job started in d28ae3b28187 ("drm/i915: split out intel_dram.[ch] from i915_drv.c") by moving struct dram_dimm_info and dram_channel_info inside intel_dram.c, the only user of the structs. 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/20200227145359.17543-1-jani.nikula@intel.com
2020-03-02drm/i915/crc: move pipe_crc from drm_i915_private to intel_crtcJani Nikula1-30/+0
Having an array pipe_crc[I915_MAX_PIPES] in struct drm_i915_private should be an obvious clue this should be located in struct intel_crtc instead. Make it so. As a side-effect, fix some errors in indexing pipe_crc with both pipe and crtc index. And, of course, reduce the size of i915_drv.h. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227161253.15741-1-jani.nikula@intel.com
2020-02-28drm/i915: Add glk to intel_detect_preproduction_hw()Ville Syrjälä1-0/+2
Detect GLK pre-production steppings. Not 100% of A2 being pre-prod since the spec is a bit of a mess but feels more or less correct. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128155152.21977-4-ville.syrjala@linux.intel.com Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-02-25drm/i915: Update DRIVER_DATE to 20200225Rodrigo Vivi1-2/+2
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-02-24drm/i915: Update DRIVER_DATE to 20200224Rodrigo Vivi1-1/+1
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-02-24drm/i915: Update DRIVER_DATE to 20200224Rodrigo Vivi1-2/+2
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-02-24drm/i915/psr: Force PSR probe only after full initializationJosé Roberto de Souza1-1/+1
Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase once to enable PSR") was forcing the state compute too earlier causing errors because not everything was initialized, so here moving to the end of i915_driver_modeset_probe() when the display is all initialized. Also fixing the place where it disarm the force probe as during the atomic check phase errors could happen like the ones due locking and it would cause PSR to never be enabled if that happens. Leaving the disarm to the atomic commit phase, intel_psr_enable() or intel_psr_update() will be called even if the current state do not allow PSR to be enabled. v2: Check if intel_dp is null in intel_psr_force_mode_changed_set() v3: Check intel_dp before get dev_priv v4: - renamed intel_psr_force_mode_changed_set() to intel_psr_set_force_mode_changed() - removed the set parameter from intel_psr_set_force_mode_changed() - not calling intel_psr_set_force_mode_changed() from intel_psr_enable/update(), directly setting it after the same checks that intel_psr_set_force_mode_changed() does - moved intel_psr_set_force_mode_changed() arm call to i915_driver_modeset_probe() as it is a better for a PSR call, all the functions calls happening between the old and the new function call will cause issue Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute phase once to enable PSR") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151 Tested-by: Ross Zwisler <zwisler@google.com> Reported-by: Ross Zwisler <zwisler@google.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221212635.11614-1-jose.souza@intel.com
2020-02-20drm/i915/guc: Apply new uC status tracking to GuC submission as wellDaniele Ceraolo Spurio1-6/+0
To be able to differentiate the before and after of our commitment to GuC submission, which will be used in follow-up patches to early set-up the submission structures. v2: move functions to guc_submission.h (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-7-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/guc: Kill USES_GUC_SUBMISSION macroDaniele Ceraolo Spurio1-3/+0
use intel_uc_uses_guc_submission() directly instead, to be consistent in the way we check what we want to do with the GuC. v2: do not go through ctx->vm->gt, use i915->gt instead Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1 Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-3-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/guc: Kill USES_GUC macroDaniele Ceraolo Spurio1-1/+0
use intel_uc_uses_guc() directly instead, to be consistent in the way we check what we want to do with the GuC. v2: split guc_log_info changes to their own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-2-daniele.ceraolospurio@intel.com
2020-02-19drm/i915: Read rawclk_freq earlierChris Wilson1-1/+0
Read the rawclk_freq during runtime info probing, prior to its first use in computing the CS timestamp frequency. Then store it in the runtime info, and include it in the debug printouts. Closes: https://gitlab.freedesktop.org/drm/intel/issues/834 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200216163445.555786-1-chris@chris-wilson.co.uk
2020-02-17drm/i915: split out vlv/chv specific suspend/resume codeJani Nikula1-2/+0
i915_drv.c is a fairly big file, and having very specific vlv/chv suspend/resume code in it is a distraction. Split it out to a new vlv_suspend.[ch] 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/20200212144058.5686-1-jani.nikula@intel.com
2020-02-10drm/i915/dc3co: Add description of how it worksJosé Roberto de Souza1-1/+1
Add a basic description about how DC3CO works to help people not familiar with it. While at it, I also improved the delayed work handle and function names and removed a debug message that is ambiguous and not much useful, no changes in behavior here. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205214945.131012-1-jose.souza@intel.com
2020-02-05drm/i915: Manipulate DBuf slices properlyStanislav Lisovskiy1-1/+1
Start manipulating DBuf slices as a mask, but not as a total number, as current approach doesn't give us full control on all combinations of slices, which we might need(like enabling S2 only can't enabled by setting enabled_slices=1). Removed wrong code from intel_get_ddb_size as it doesn't match to BSpec. For now still just use DBuf slice until proper algorithm is implemented. Other minor code refactoring to get prepared for major DBuf assignment changes landed: - As now enabled slices contain a mask we still need some value which should reflect how much DBuf slices are supported by the platform, now device info contains num_supported_dbuf_slices. - Removed unneeded assertion as we are now manipulating slices in a more proper way. v2: Start using enabled_slices in dev_priv v3: "enabled_slices" is now "enabled_dbuf_slices_mask", as this now sits in dev_priv independently. v4: - Fixed debug print formatting to hex(Matt Roper) - Optimized dbuf slice updates to be used only if slice union is different from current conf(Matt Roper) - Fixed some functions to be static(Matt Roper) - Created a parameterized version for DBUF_CTL to simplify DBuf programming cycle(Matt Roper) - Removed unrequred field from GEN10_FEATURES(Matt Roper) v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä) - Started to use parameterized loop for hw readout to get slices (Ville Syrjälä) - Added back assertion checking amount of DBUF slices enabled after DC states 5/6 transition, also added new assertion as starting from ICL DMC seems to restore the last DBuf power state set, rather than power up all dbuf slices as assertion was previously expecting(Ville Syrjälä) v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä) - Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled back, as we really need to have a single unified assert here however currently enabling always slice 1 is enforced by BSpec, so we will have to OR enabled slices mask with 1 in order to be consistent with BSpec, that way we can unify that assertion and against the actual state from the driver, but not some hardcoded value.(concluded with Ville) - Remove parameterized DBUF_CTL version, to extract it to another patch.(Ville Syrjälä) v7: - Removed unneeded hardcoded return value for older gens from intel_enabled_dbuf_slices_mask - this now is handled in a unified manner since device info anyway returns max dbuf slices as 1 for older platforms(Matthew Roper) - Now using INTEL_INFO(dev_priv)->num_supported_dbuf_slices instead of intel_dbuf_max_slices function as it is trivial(Matthew Roper) v8: - Fixed icl_dbuf_disable to disable all dbufs still(Ville Syrjälä) v9: - Renamed _DBUF_CTL_S to DBUF_CTL_S(Ville Syrjälä) - Now using power_domain mutex to protect from race condition, which can occur because intel_dbuf_slices_update might be running in parallel to gen9_dc_off_power_well_enable being called from intel_dp_detect for instance, which causes assertion triggered by race condition, as gen9_assert_dbuf_enabled might preempt this when registers were already updated, while dev_priv was not. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-6-stanislav.lisovskiy@intel.com
2020-02-05drm/i915: Remove skl_ddl_allocation structStanislav Lisovskiy1-9/+2
Current consensus that it is redundant as we already have skl_ddb_values struct out there, also this struct contains only single member which makes it unnecessary. v2: As dirty_pipes soon going to be nuked away from skl_ddb_values, evacuating enabled_slices to safer in dev_priv. v3: Changed "enabled_slices" to be "enabled_dbuf_slices_num" (Matt Roper) v4: - Wrapped the line getting number of dbuf slices(Matt Roper) - Removed indeed redundant skl_ddb_values declaration(Matt Roper) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-2-stanislav.lisovskiy@intel.com
2020-01-31drm/i915/guc: Introduce guc_is_readyMichal Wajdeczko1-1/+1
We already have guc_is_running function, but it only reflects firmware status, while to fully use GuC we need to know if we've already established communication with it. v2: also s/intel_guc_is_running/intel_guc_is_fw_running (Chris) 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/20200131153706.109528-1-michal.wajdeczko@intel.com
2020-01-31drm/i915: Convert cdclk to global stateVille Syrjälä1-38/+7
Let's convert cdclk_state to be a proper global state. That allows us to use the regular atomic old vs. new state accessor, hopefully making the code less confusing. We do have to deal with a few more error cases in case the cdclk state duplication fails. But so be it. v2: Fix new plane min_cdclk vs. old crtc min_cdclk check Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121140353.25997-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-01-31drm/i915: Convert bandwidth state to global stateVille Syrjälä1-1/+1
Now that we have the more formal global state thing let's use if for memory bandwidth tracking. No real difference to the current private object usage since we already tried to avoid taking the single serializing lock needlessly. But since we're going to roll the global state out to more things probably a good idea to unify the approaches a bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-16-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-01-31drm/i915: Introduce better global state handlingVille Syrjälä1-0/+3
Our current global state handling is pretty ad-hoc. Let's try to make it better by imitating the standard drm core private object approach. The reason why we don't want to directly use the private objects is locking; Each private object has its own lock so if we introduce any global private objects we get serialized by that single lock across all pipes. The global state apporoach instead uses a read/write lock type of approach where each individual crtc lock counts as a read lock, and grabbing all the crtc locks allows one write access. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-15-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-01-31drm/i915: Extract intel_cdclk_stateVille Syrjälä1-19/+32
Use the same structure to store the cdclk state in both intel_atomic_state and dev_priv. First step towards proper old vs. new cdclk states. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-10-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-31drm/i915: s/cdclk_state/cdclk_config/Ville Syrjälä1-10/+10
I want to have a higher level cdclk state object so let's rename the current lower level thing to cdclk_config (because I lack imagination). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-8-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-31drm/i915: Collect more cdclk state under the same roofVille Syrjälä1-4/+5
Move the min_cdclk[] and min_voltage_level[] arrays under the rest of the cdclk state. And while at it provide a simple helper (intel_cdclk_clear_state()) to clear the state during the ww_mutex backoff dance. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-6-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-31drm/i915: Nuke skl wm.dirty_pipes bitmaskVille Syrjälä1-1/+0
The dirty_pipes bitmask is now unused. Get rid of it. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-4-ville.syrjala@linux.intel.com
2020-01-31drm/i915: Move linetime wms into the crtc stateVille Syrjälä1-1/+0
The linetime watermarks really have very little in common with the plane watermarks. It looks to be cleaner to simply track them in the crtc_state and program them from the normal modeset/fastset paths. The only dark cloud comes from the fact that the register is still supposedly single buffered. So in theory it might still need some form of two stage programming. Note that even though HSW/BDWhave two stage programming we never computed any special intermediate values for the linetime watermarks, and on SKL+ we don't even have the two stage stuff plugged in since everything else is double buffered. So let's assume it's all fine and continue doing what we've been doing. Actually on HSW/BDW the value should not even change without a full modeset since it doesn't account for pfit downscaling. Thus only fastboot might be affected. But on SKL+ the pfit scaling factor is take into consideration so the value may change during any fastset. As a bonus we'll plug this thing into the state checker/dump now. v2: Rebase due to bigjoiner prep v2: Only compute ips linetime for IPS capable pipes. Bspec says the register values is ignored for other pipes, but in fact it can't even be written so the state checker becomes unhappy if we don't compute it as zero. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2020-01-23drm/i915: add display engine uncore helpersJani Nikula1-14/+0
Add convenience helpers for the most common uncore operations with struct drm_i915_private * as context rather than struct intel_uncore *. The goal is to replace all instances of I915_READ(), I915_POSTING_READ(), I915_WRITE(), I915_READ_FW(), and I915_WRITE_FW() in display/ with these, to finally be able to get rid of the implicit dev_priv local parameter use. The idea is that any non-u32 reads or writes are special enough that they can use the intel_uncore_* functions directly. v2: - rename the file intel_de.h - move intel_de_wait_for_* there too - also add de fw helpers Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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/20200121113915.9813-1-jani.nikula@intel.com
2020-01-22drm/i915/gem: Convert vm idr to xarrayChris Wilson1-3/+1
Replace the vm_idr + vm_idr_mutex to an XArray. The XArray data structure is now used to implement IDRs, and provides its own locking. We can simply remove the IDR wrapper and in the process also remove our extra mutex. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200122161531.508903-1-chris@chris-wilson.co.uk
2020-01-14drm/i915: Update DRIVER_DATE to 20200114Jani Nikula1-2/+2
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-01-10drm/i915: Start chopping up the GPU error captureChris Wilson1-1/+1
In the near future, we will want to start a GPU error capture from a new context, from inside the softirq region of a forced preemption. To do so requires us to break up the monolithic error capture to provide new entry points with finer control; in particular focusing on one engine/gt, and being able to compose an error state from little pieces of HW capture. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Acked-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200110123059.1348712-1-chris@chris-wilson.co.uk