- 17 Nov, 2015 19 commits
-
-
Ville Syrjälä authored
Introduce intel_display_port_aux_power_domain() which simply returns the appropriate AUX power domain for a specific port, and then replace the intel_display_port_power_domain() with calls to the new function in the DP code. As long as we're not actually enabling the port we don't need the lane power domains, and those are handled now purely from modeset_update_crtc_power_domains(). My initial motivation for this was to see if I could keep the DPIO power wells powered down while doing AUX on CHV, but turns out I can't so this doesn't change anything for CHV at least. But I think it's still a worthwile change. v2: Add case for PORT E. Default to POWER_DOMAIN_AUX_D for now. (Ville) Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447682467-6237-1-git-send-email-patrik.jakobsson@linux.intel.com
-
Patrik Jakobsson authored
Move call to gen9_set_dc_state_debugmask_memory_up() into gen9_set_dc_state() to prevent us missing it somewhere. Signed-off-by:
-
Patrik Jakobsson authored
Replaces "drm/i915: Force loading of csr program at boot" in the old series. Previously we called blindly into intel_csr_load_program() and depended on a check of whether the CSR program memory was cleared or not. This check is not reliable and no longer needed since we fixed the call-sites of intel_csr_load_program(). Signed-off-by:
-
Imre Deak authored
When this option is 0 (so the power well support is disabled) we are supposed to enable all power wells once and don't disable them unless we system suspend the device. Currently if the option is 0, we can call the power well enable handlers multiple times, whenever their refcount changes from 0->1. This may not be a problem for the HW, but it's not logical and may trigger some warnings in the power well code which doesn't expect this. So simply keep around a reference while we are not system suspended to solve this. For simplicity mark the module option read only, so we don't need to deal with re-enabling the feature during runtime. If someone really needs that it could be added later in a more proper way. v2: - fix typo in comment in intel_power_domains_suspend() (Patrik) Signed-off-by:
-
Imre Deak authored
We don't need to reinit DDI and IRQs during PW1 enabling any more, since we don't toggle PW1 on-demand any more. We enable PW1 only as part of the display core init sequence and after this we initialize both DDI and IRQs later in the init sequence. So remove these init steps from the power well code. Signed-off-by:
-
Imre Deak authored
Suppressing LCPLL disabling was added to avoid interfering with the DMC firmware. It is not needed any more since we uninit CDCLK now with the DMC deactivated (DC states disabled). We also must disable it during system suspend as part of the Bspec "Display uninit sequence". Signed-off-by:
-
Imre Deak authored
We need to disable the DC states during display core init to sanitize the HW state we inherit from the BIOS. We need to disable it during display core uninit too, since the power well framework will leave it enabled (since we get to the display core uninit step with all power domains disabled already). Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Imre Deak authored
With the DMC firmware installed we don't need to handle HW resources that are handled automatically by the firmware. Besides being redundant this can also interfere with the firmware, possibly getting it into a broken/blocked state. The on-demand handling of PW1 was already half-way removed, MISC IO was still handled in this way. After the last patch we init/uninit these HW resources manually as part of the display core init/uninit sequence, so we can now remove the on-demand handling for these completely. We still keep around the power wells (with no domains attached to them) since the manual toggling during display core init/uninit happens via the current API. Signed-off-by:
-
Imre Deak authored
We need to initialize the display core part early, before initializing the rest of the display power state. This is also described in the bspec termed "Display initialization sequence". Atm we run this sequence during driver loading after power domain HW state initialization which is too late and during runtime suspend/resume which is unneeded and can interere with DMC functionality which handles HW resources toggled by this init/uninit sequence automatically. The init sequence must be run as the first step of HW power state initialization and during system resume. The uninit sequence must be run during system suspend. To address the above move the init sequence to the initial HW power state setup and the uninit sequence to a new power domains suspend function called during system suspend. As part of the init sequence we also have to reprogram the DMC firmware as it's lost across a system suspend/resume cycle. After this change CD clock initialization during driver loading will happen only later after other dependent HW/SW parts are initialized, while during system resume it will get initialized as the last step of the init sequence. This distinction can be removed by some refactoring of platform independent parts. I left this refactoring out from this series since I didn't want to change non-SKL parts. This is a TODO for later. v2: - fix error path in i915_drm_suspend_late() - don't try to re-program the DMC firmware if it failed to load Signed-off-by:
-
Imre Deak authored
Give a more proper name to this function. Signed-off-by:
-
Damien Lespiau authored
Before this patch, we used the intel_display_power_{get,put} functions to make sure the PW1 and Misc I/O power wells were enabled all the time while LCPLL was enabled. We called a get() at intel_ddi_pll_init() when we discovered that LCPLL was enabled, then we would call put/get at skl_{un,}init_cdclk(). The problem is that skl_uninit_cdclk() is indirectly called by intel_runtime_suspend(). So it will only release its power well _after_ we already decided to runtime suspend. But since we only decide to runtime suspend after all power wells and refcounts are released, that basically means we will never decide to runtime suspend. So what this patch does to fix that problem is move the PW1 + Misc I/O power well handling out of the runtime PM mechanism: instead of calling intel_display_power_{get_put} - functions that touch the refcount -, we'll call the low level intel_power_well_{en,dis}able, which don't change the refcount. This way, it is now possible for the refcount to actually reach zero, and we'll now start runtime suspending/resuming. v2 (from Paulo): - Write a commit message since the original patch left it empty. - Rebase after the intel_power_well_{en,dis}able rename. - Use lookup_power_well() instead of hardcoded indexes. Testcase: igt/pm_rpm/rte (and every other rpm test) Signed-off-by:Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Imre Deak authored
The current lookup code wouldn't find a power well if it's not in any power domain. There wasn't any power wells before but an upcoming patch will detach the power domains from power well#1 and the MISC IO power wells, so fix things up accordingly. Signed-off-by:
-
Imre Deak authored
lookup_power_well() expects uniq power well IDs, but atm we have uninitialized IDs which would clash with those power wells with a 0 ID. This wasn't a problem so far since nothing looked up such a power well, but an upcoming patch will (Misc IO for SKL), so fix this up on platforms where this matters. Signed-off-by:
-
Imre Deak authored
After fixing the same issue in the set_caching IOCTL and Chris' request to check out the possibilities for an improved RPM ref handling I noticed that we have the same issue in the set_tiling IOCTL. Fix this up.I didn't see any bug reports about this one, but the GTT unbind operation on this path accesses the HW, which needs the ref. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447092986-11165-1-git-send-email-imre.deak@intel.com
-
Chris Wilson authored
When accessing through the GTT from one CPU whilst concurrently updating the GGTT PTEs in another thread, the hardware likes to return random data. As we have strong serialisation prevent us from modifying the PTE of an active GTT mmapping, we have to conclude that it whilst modifying other PTE's that error occurs. (I have not looked for any pattern such as modifying PTE within the same page or cacheline as active PTE - though checking whether revoking neighbouring objects should be enough to test that theory.) The corruption also seems restricted to Braswell and disappears with maxcpus=0. This patch stops all access through the GTT by other CPUs when we update any PTE by stopping the machine around the GGTT update. Note that splitting up the 64 bit write into two 32 bit writes was tried and found to fail too. Testcase: igt/gem_concurrent_blit Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89079Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Shubhangi Shrivastava authored
Compliance test 4.3.1.11 requires source to perform link training always if the automated test requests for it. This patch enforces this requirement. Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com Signed-off-by:
-
Shubhangi Shrivastava authored
Automated test data that is updated when a test is requested is not cleared till next automated test request is recevied which can cause various problems. This patch fixes this by clearing this during the next short pulse and on hot unplug. For example, when TEST_LINK_TRAINING is requested it is updated to appropriate variable inside intel_dp_handle_test_request but is also cleared only inside the same function. if the next short pulse does not have the AUTOMATED_TEST_REQUEST bits set the variable will not be cleared resulting in carrying incorrect test status in local variables. v2: Added comments and moved nack and defer variables before set_edid (Sonika) Signed-off-by:
-
Kumar, Mahesh authored
If ddb allocation for planes in current CRTC is changed, that doesn't lead to ddb allocation change for other CRTCs, because our DDB allocation is not dynamic according to plane parameters, ddb is allocated according to number of CRTC enabled, & divided equally among CTRC's. In current condition check during Watermark calculation, if number of plane/ddb allocation changes for current CRTC, Watermark for other pipes are recalculated. But there is no change in DDB allocation of other pipe so watermark is also not changed, This leads to warning messages. WARN_ON(!wm_changed) This patch corrects this and check if DDB allocation for pipes is changed, then only recalculate watermarks. v2 (by Matt): Rebased to latest -nightly and fixed a typo Signed-off-by:
Kumar, Mahesh <mahesh1.kumar@intel.com> Reviewed-by(v1): Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 16 Nov, 2015 7 commits
-
-
Ville Syrjälä authored
v2: Split up the ctl vs. data reg handling like in the normal AUX code Signed-off-by:
-
Ville Syrjälä authored
Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset under dev_priv, like we for DSI and GPIO for example. TODO: could probably move a bunch of this kind of stuff into the device info instead... v2: Drop the spurious whitespace change (Jani) Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Rather than computing on demand, store also the aux data reg offsets under intel_dp. v2: Duplicate some code to make things less magic (Jani) v3: Use PORT_B registers for invalid ports in g4x_aux_data_reg() Signed-off-by:
-
Ville Syrjälä authored
Currently we determine the location of the AUX registers in a confusing way. First we assume the PCH registers are used always, but then we override it for everything but HSW/BDW to use DP+0x10. Very confusing. Let's just make it straightforward and simply add a few functions to pick the right AUX_CTL based on the DP port. To deal with VLV/CHV we'll include the display_mmio_offset into the AUX register defines. v2: Reorder patches (Chris) Signed-off-by:
-
Ville Syrjälä authored
v2: Keep some MISSING_CASE() stuff (Jani) s/-1/-PIPE_B/ in the register macro Fix typo in patch subject v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani) v4: Reorder patches (Chris) Signed-off-by: -
Ville Syrjälä authored
Use kasprintf() to generate the "DPDDC-<port>" name for the aux helper. To deal with errors properly make intel_dp_aux_init() return something, and adjust the caller to match. It seems we were also missing a intel_dp_mst_encoder_cleanup() call on edp (non-port A) init failures, so add that too. The whole error/cleanup ordering doesn't feel entirely sane to me, but I'll leave that part alone for now. v2: Use kasprintf() instead of a table, reorder patches (Chis) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Instead of checking what aux_ch_ctl_reg is, we can simply check the port when determining the right timeout value to program. v2: Reorder patches to reduce churn (Chris) Signed-off-by:
-
- 13 Nov, 2015 2 commits
-
-
jim.bride@linux.intel.com authored
While comparing the B-Spec with the code I noticed that several values in these tables have been updated in the spec, so I changed the code to match.. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446852654-883-1-git-send-email-jim.bride@linux.intel.com
-
Ander Conselvan de Oliveira authored
The i_boost level in the DDI translation tables are stored per level. However, skl_ddi_set_iboos() would choose an entry of that table based on the port argument. Cc: Jim Bride <jim.bride@linux.intel.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
-
- 12 Nov, 2015 12 commits
-
-
Animesh Manna authored
As during disabling dc6 no need to check for csr firmware loading status, so removed the assert call (Requested by Damien). Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Signed-off-by:
-
Imre Deak authored
Currently during system s/r we enable/disable DC6, so before we do so make sure that the firmware loading is complete. Note that whether we need to enable DC6 for S3/S4 is still open. At least the firmware program is lost during S3 and we need to reprogram it after resuming. Until this is clarified we keep the current behavior and enable/disable DC6. Signed-off-by:
-
Animesh Manna authored
During driver unload to ensure we dont have any pending task, flush_work added to complete firmware loading task. v1: Initial version. v2: As per review comments from Daniel, Removed flush_work from skl_set_power_well. As we have taken power well refernece and rpm count during firmware loading by using display_power_domain_get/put - this will always ensure rpm will be blocked if firmware is not loaded. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
Daniel Vetter authored
Two benefits: - We can use FW_LOADER_USERSPACE_FALLBACK. - We can use flush_work to synchronize with the oustanding worker, which is a notch more obvious what it does than having a special completion. The next patch will properly synchronize against the async loader in the resume and unload code. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Daniel Vetter authored
The loader function will get a bit more complicated soon, extract the parsing code to make the control flow clearer. While doing that just use dev_priv->csr.dmc_payload as the indicator for whether it all suceeded or not. v2-v3: - unchanged v4: - rebased on top of latest drm-intel-nightly Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
Daniel Vetter authored
As all csr firmware related opertion are not using any any data structures of drm framework level, so better to use dev_priv instead of dev. it's a new style! :) Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
Daniel Vetter authored
We need to make sure we don't put garbage into the hw if dmc firmware loading failed mid-thru. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
Daniel Vetter authored
If we really want to we can be more verbose here, but we really don't need an entire function for this. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
Daniel Vetter authored
Standard is to align continuations of parameter lists and if conditions to the opening ( in i915 and drm code. Apply this across the entire file since it was sticking out a bit too much. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
Daniel Vetter authored
This removes two anti-patterns: - Locking shouldn't be used to synchronize with async work (of any form, whether callbacks, workers or other threads). This is what the mutex_lock/unlock seems to have been for in intel_csr_load_program. Instead ordering should be ensured with the generic wait_for_completion()/complete(). Or more specific functions provided by the core kernel like e.g. flush_work()/cancel_work_sync() in the case of synchronizing with a work item. - Don't invent own completion like the following code did with the (already removed) wait_for(csr_load_status_get()) pattern - it's really hard to get these right when you want them to be _really_ correct (and be fast) in all cases. Furthermore it's easier to read code using the well-known primitives than new ones using non-standard names. Before enabling/disabling DC6 check if the firmware is loaded successfully. This is guaranteed during runtime s/r, since otherwise we don't enable RPM, but not during system s/r. Note that it's still unclear whether we need to enable/disable DC6 during system s/r, until that's clarified, keep the current behavior and enable/disable DC6. Also after this patch there is a race during system s/r where the firmware may not be loaded yet, that's addressed in an upcoming patch. v2-v3: - unchanged v4: - rebased on latest drm-intel-nightly Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
Daniel Vetter authored
Avoids non-static functions since all the callers are in intel_rpm.c. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
Daniel Vetter authored
Grabbing a runtime pm reference with intel_runtime_pm_get will only prevent device D3. But dmc firmware is required even earlier (namely for the skl power well 2). Hence we need to grab a rpm reference higher up in the hierarchy. For simplicity just grab the _INIT display power well. That's a bit too much, but since the firmware loading task should completely fairly quickly this won't be a real problem really. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
-
