summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_drv.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/tgl: Add Wa_14010477008:tglMatt Roper2020-04-201-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> (cherry picked from commit dbff5a8db9c630f61a892ab41a283445e01270f5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915: Update DRIVER_DATE to 20200313Rodrigo Vivi2020-03-141-2/+2
| | | | Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v5)Vivek Kasireddy2020-03-061-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
* drm/i915/gem: Limit struct_mutex to eb_reserveChris Wilson2020-03-061-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
* drm/i915/gvt: only include intel_gvt.h where neededJani Nikula2020-03-031-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
* drm/i915/gvt: make intel_gvt_active internal to intel_gvtJani Nikula2020-03-031-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
* drm/i915/vgpu: improve vgpu abstractionsJani Nikula2020-03-031-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
* drm/i915: move watermark structs more towards usageJani Nikula2020-03-031-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
* drm/i915: Unify the DPLL ref clock frequency trackingImre Deak2020-03-021-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
* drm/i915: Keep the global DPLL state in a DPLL specific structImre Deak2020-03-021-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
* drm/i915: remove unused orig_clock i915 memberJani Nikula2020-03-021-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
* drm/i915: add i915_ioc32.h for compatJani Nikula2020-03-021-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
* drm/i915/dram: hide the dram structs betterJani Nikula2020-03-021-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
* drm/i915/crc: move pipe_crc from drm_i915_private to intel_crtcJani Nikula2020-03-021-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
* drm/i915: Add glk to intel_detect_preproduction_hw()Ville Syrjälä2020-02-281-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>
* drm/i915: Update DRIVER_DATE to 20200225Rodrigo Vivi2020-02-251-2/+2
| | | | Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915: Update DRIVER_DATE to 20200224Rodrigo Vivi2020-02-251-1/+1
| | | | Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915: Update DRIVER_DATE to 20200224Rodrigo Vivi2020-02-251-2/+2
| | | | Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915/psr: Force PSR probe only after full initializationJosé Roberto de Souza2020-02-241-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
* drm/i915/guc: Apply new uC status tracking to GuC submission as wellDaniele Ceraolo Spurio2020-02-201-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
* drm/i915/guc: Kill USES_GUC_SUBMISSION macroDaniele Ceraolo Spurio2020-02-201-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
* drm/i915/guc: Kill USES_GUC macroDaniele Ceraolo Spurio2020-02-201-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
* drm/i915: Read rawclk_freq earlierChris Wilson2020-02-191-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
* drm/i915: split out vlv/chv specific suspend/resume codeJani Nikula2020-02-171-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
* drm/i915/dc3co: Add description of how it worksJosé Roberto de Souza2020-02-101-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
* drm/i915: Manipulate DBuf slices properlyStanislav Lisovskiy2020-02-051-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
* drm/i915: Remove skl_ddl_allocation structStanislav Lisovskiy2020-02-051-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
* drm/i915/guc: Introduce guc_is_readyMichal Wajdeczko2020-02-011-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
* drm/i915: Convert cdclk to global stateVille Syrjälä2020-01-311-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>
* drm/i915: Convert bandwidth state to global stateVille Syrjälä2020-01-311-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>
* drm/i915: Introduce better global state handlingVille Syrjälä2020-01-311-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>
* drm/i915: Extract intel_cdclk_stateVille Syrjälä2020-01-311-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>
* drm/i915: s/cdclk_state/cdclk_config/Ville Syrjälä2020-01-311-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>
* drm/i915: Collect more cdclk state under the same roofVille Syrjälä2020-01-311-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>
* drm/i915: Nuke skl wm.dirty_pipes bitmaskVille Syrjälä2020-01-311-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
* drm/i915: Move linetime wms into the crtc stateVille Syrjälä2020-01-311-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>
* drm/i915: add display engine uncore helpersJani Nikula2020-01-231-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
* drm/i915/gem: Convert vm idr to xarrayChris Wilson2020-01-221-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
* drm/i915: Update DRIVER_DATE to 20200114Jani Nikula2020-01-141-2/+2
| | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Start chopping up the GPU error captureChris Wilson2020-01-101-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
* drm/i915/display: Force the state compute phase once to enable PSRJosé Roberto de Souza2020-01-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent improvements in the state tracking in i915 caused PSR to not be enabled when reusing firmware/BIOS modeset, this is due to all initial commits returning ealier in intel_atomic_check() as needs_modeset() is always false. To fix that here forcing the state compute phase in CRTC that is driving the eDP that supports PSR once. Enable or disable PSR do not require a fullmodeset, so user will still experience glitch free boot process plus the power savings that PSR brings. It was tried to set mode_changed in intel_initial_commit() but at this point the connectors are not registered causing a crash when computing encoder state. v2: - removed function return - change arguments to match intel_hdcp_atomic_check v3: - replaced drm includes in intel_psr.h by forward declaration(Jani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112253 Reported-by: <s.zharkoff@gmail.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200106152128.195171-1-jose.souza@intel.com
* drm/i915/gem: Extend mmap support for lmemAbdiel Janulgue2020-01-041-3/+3
| | | | | | | | | | | | | Local memory objects are similar to our usual scatterlist, but instead of using the struct page stored therein, we need to use the sg->dma_address. Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@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/20200103204137.2131004-1-chris@chris-wilson.co.uk
* drm/i915/gem: Drop local vma->vm_file referenceChris Wilson2020-01-011-0/+10
| | | | | | | | | | | | | | | | We use the global device inode, shared amongst all files, and not the user's device filp to provide the backing storage for the mmap. The vma->vm_file provides a redundant reference that breaks existing expected behaviour that closing the user's device fd will release the resources bound to it, if a mmap persists. (Even without the vma->vm_file, the mmap will persist past the user's fd as the storage is bound to the device, i.e. our reference is on the object not file.) Fixes: cc662126b413 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET") Closes: https://gitlab.freedesktop.org/drm/intel/issues/919 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200101141007.755429-1-chris@chris-wilson.co.uk
* drm/i915/gt: Restore coarse power gatingChris Wilson2020-01-011-2/+4
| | | | | | | | | | | | | | | | | | | The coarse power gating was disabled as part of commit 2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA") as a prelude to recover from the context corruption; the power gating itself has no direct impact on the RC6 context corruption. However, that recovery scheme was never implemented due to difficult corner cases, and so we no longer need to keep the power gating disabled. Fixes: 2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA") Closes: https://gitlab.freedesktop.org/drm/intel/issues/846 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191231122708.4025916-1-chris@chris-wilson.co.uk
* drm/i915: Introduce remap_io_sg() to prefault discontiguous objectsAbdiel Janulgue2019-12-311-0/+3
| | | | | | | | | | | | | | Provide a way to set the PTE within apply_page_range for discontiguous objects in addition to the existing method of just incrementing the pfn for a page range. Fixes: cc662126b413 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET") Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@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/20191231200356.409475-1-chris@chris-wilson.co.uk
* drm/i915: Switch context id allocation directly to xarrayTvrtko Ursulin2019-12-241-3/+3
| | | | | | | | | | IDR internally uses xarray so we can use it directly which simplifies our code by removing the need to do external locking. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@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/20191224095920.2386297-1-chris@chris-wilson.co.uk
* drm/i915: Update DRIVER_DATE to 20191223Jani Nikula2019-12-231-2/+2
| | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Remove i915->kernel_contextChris Wilson2019-12-211-3/+0
| | | | | | | | | | | | | | | | | | Allocate only an internal intel_context for the kernel_context, forgoing a global GEM context for internal use as we only require a separate address space (for our own protection). Now having weaned GT from requiring ce->gem_context, we can stop referencing it entirely. This also means we no longer have to create random and unnecessary GEM contexts for internal use. GEM contexts are now entirely for tracking GEM clients, and intel_context the execution environment on the GPU. 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/20191221160324.1073045-1-chris@chris-wilson.co.uk
* drm/i915/gem: Prepare gen7 cmdparser for async executionChris Wilson2019-12-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gen7 cmdparser is primarily a promotion-based system to allow access to additional registers beyond the HW validation, and allows fallback to normal execution of the user batch buffer if valid and requires chaining. In the next patch, we will do the cmdparser validation in the pipeline asynchronously and so at the point of request construction we will not know if we want to execute the privileged and validated batch, or the original user batch. The solution employed here is to execute both batches, one with raised privileges and one as normal. This is because the gen7 MI_BATCH_BUFFER_START command cannot change privilege level within a batch and must strictly use the current privilege level (or undefined behaviour kills the GPU). So in order to execute the original batch, we need a second non-priviledged batch buffer chain from the ring, i.e. we need to emit two batches for each user batch. Inside the two batches we determine which one should actually execute, we provide a conditional trampoline to call the original batch. Implementation-wise, we create a single buffer and write the shadow and the trampoline inside it at different offsets; and bind the buffer into both the kernel GGTT for the privileged execution of the shadow and into the user ppGTT for the non-privileged execution of the trampoline and original batch. One buffer, two batches and two vma. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191211230858.599030-1-chris@chris-wilson.co.uk
* drm/i915: Remove redundant parameters from intel_engine_cmd_parserChris Wilson2019-12-111-6/+4
| | | | | | | | | Declutter the calling interface by reducing the parameters to the i915_vma and associated offsets. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191211110437.4082687-2-chris@chris-wilson.co.uk
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-07 18:33:25 +0100