- 12 11月, 2015 5 次提交
-
-
由 Imre Deak 提交于
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: NImre Deak <imre.deak@intel.com> Reviewed-by: NAnimesh Manna <animesh.manna@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-13-git-send-email-imre.deak@intel.com
-
由 Animesh Manna 提交于
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: NAnimesh Manna <animesh.manna@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-12-git-send-email-imre.deak@intel.com
-
由 Daniel Vetter 提交于
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: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NAnimesh Manna <animesh.manna@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-9-git-send-email-imre.deak@intel.com
-
由 Daniel Vetter 提交于
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: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NAnimesh Manna <animesh.manna@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-7-git-send-email-imre.deak@intel.com
-
由 Daniel Vetter 提交于
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: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NAnimesh Manna <animesh.manna@intel.com> [imre: added code and note about checking if the firmware loaded ok, before enabling/disabling it] Reviewed-by: NAnimesh Manna <animesh.manna@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447341037-2623-1-git-send-email-imre.deak@intel.com
-
- 29 10月, 2015 5 次提交
-
-
由 Deepak S 提交于
v2: (Rodrigo) Rebase after commit 3cb27f38 ("drm/i915: remove an extra level of indirection in PCI ID list") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDeepak S <deepak.s@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446060072-19489-1-git-send-email-rodrigo.vivi@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Deepak S 提交于
v2: separate out device info into different GT (Damien) v3: Add is_kabylake to the KBL gt3 structuer (Damien) Sort the platforms in older -> newer order (Damien) v4: Split platform definition since is_skylake=1 on kabylake structure was Nacked. (Rodrigo) v5: (Rodrigo) Rebase after commit 3cb27f38 ("drm/i915: remove an extra level of indirection in PCI ID list") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDeepak S <deepak.s@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446059991-17033-1-git-send-email-rodrigo.vivi@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Rodrigo Vivi 提交于
Kabylake is a Intel® Processor containing Intel® HD Graphics following Skylake. It is Gen9p5, so it inherits everything from Skylake. Let's start by adding the platform separated from Skylake but reusing most of all features, functions etc. Later we rebase the PCI-ID patch without is_skylake=1 so we don't replace what original Author did there. Few IS_SKYLAKEs if statements are not being covered by this patch on purpose: - Workarounds: Kabylake is derivated from Skylake H0 so no W/As apply here. - GuC: A following patch removes Kabylake support with an explanation: No firmware available yet. - DMC/CSR: Done in a separated patch since we need to be carefull and load the version for revision 7 since Kabylake is Skylake H0. v2: relative cleaner commit message and added the missed IS_KABYLAKE to intel_i2c.c as pointed out by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Rodrigo Vivi 提交于
Kabylake will also be defined as gen9 and !is_skylake. So we need start by creating a proper Broxton definition, otherwise we will break broxton with the introduction of Kabylake. Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445966099-1640-2-git-send-email-rodrigo.vivi@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
Add the PCI IDs directly in the pciidlist array instead of defining an extra macro. The minor benefit from this is neater diffs when adding to the end of the list. v2: drop the "aka" comment (Ville) Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446053589-21283-1-git-send-email-jani.nikula@intel.com
-
- 19 10月, 2015 1 次提交
-
-
由 Animesh Manna 提交于
Mmio register access after dc6/dc5 entry is not allowed when DC6 power states are enabled according to bspec (bspec-id 0527), so enabling dc6 as the last call in suspend flow. Addtional note from Imre: Currently we keep DC6 enabled during modesets and DPAUX transfers, which is not allowed according to the specification. This can lead at least to PLL locking failures, DPAUX timeouts and prevent deeper package power states (PC9/10). Fix this for now by enabling DC6 only when we know the above events (modeset, DPAUX) can't happen. This a temporary solution as some issues are still unsolved as described in [1] and [2], we'll address those as a follow-up. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077669.html [2] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077787.html v1: Initial version. v2: Based on review comment from Daniel, - created a seperate patch for csr uninitialization set call. v3: Rebased on top of latest code. 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: NAnimesh Manna <animesh.manna@intel.com> Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com> Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Acked-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 10月, 2015 1 次提交
-
-
由 Alex Dai 提交于
Add host2guc interface to notify GuC power state changes when enter or resume from power saving state. v3: Move intel_guc_suspend to i915_drm_suspend for consistency. v2: Add GuC suspend/resume to runtime suspend/resume too v1: Change to a more flexible way when fill host to GuC scratch data in order to remove hard coding. Signed-off-by: NAlex Dai <yu.dai@intel.com> Reviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 9月, 2015 2 次提交
-
-
由 Animesh Manna 提交于
This patch remove the function call to set the firmware loading status as uninitialized during suspend. Dmc firmware will restore the firmware in normal suspend. In previous patch added a check to directly read the hardware status and load the firmware if got reset during resume from suspend-hibernation. Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: NAnimesh Manna <animesh.manna@intel.com> Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by: NA.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Robert Beckett 提交于
Virtualized systems often use a virtual P2X4 south bridge. Detect this in intel_detect_pch and make a best guess as to which PCH we should be using. This was seen on vmware esxi hypervisor. When passing the graphics device through to a guest, it can not pass through the PCH. Instead it simulates a P2X4 southbridge. Signed-off-by: NRobert Beckett <robert.beckett@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 23 9月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 9月, 2015 2 次提交
-
-
由 Ville Syrjälä 提交于
Runtime suspends disabled all interrupts, so in order to get them back fully we need to also do the HPD irq setup on runtime resume. Except on VLV/CHV where the display interrupt initialization is part of the display power well powerup. Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Maarten Lankhorst 提交于
The driver doesn't support UMS any more, so set DRIVER_MODESET by default, remove the legacy s/r callbacks, and rename the s/r functions to make it more clear they're only in use by switcheroo now. Also remove an obsolete comment about atomic. Normal updates are supported only async updates aren't yet. v2: Don't unconditionally set DRIVER_ATOMIC, we're not yet there. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 31 8月, 2015 1 次提交
-
-
由 Imre Deak 提交于
commit da2bc1b9 Author: Imre Deak <imre.deak@intel.com> Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler introduced a regression on old platforms during hibernation. A workaround was added in commit ab3be73f Author: Imre Deak <imre.deak@intel.com> Date: Mon Mar 2 13:04:41 2015 +0200 drm/i915: gen4: work around hang during hibernation using an explicit blacklist for the GENs/BIOS vendors where the issue was reported. Later there we had reports of the same failure on platforms not on this list. To my best knowledge the correct thing to do is still to put the device to PCI D3 state during hibernation, see [1] and [2] for the reasons. This also aligns with our future plans to unify more the runtime and system suspend/resume paths. Since an exact blacklist seems to be impractical (multiple GENs and BIOS vendors are affected) apply the workaround on everything pre GEN6. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html [2] https://lkml.org/lkml/2015/6/22/274 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061Reported-by: NIlya Tumaykin <itumaykin@gmail.com> Reported-by: NDirk Griesbach <spamthis@freenet.de> Reported-by: NPavel Machek <pavel@ucw.cz> Reported-by: NMikko Rapeli <mikko.rapeli@iki.fi> Tested-by: NMikko Rapeli <mikko.rapeli@iki.fi> Reported-by: NPaul Bolle <pebolle@tiscali.nl> CC: stable@vger.kernel.org Signed-off-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 26 8月, 2015 2 次提交
-
-
由 Maarten Lankhorst 提交于
This partially reverts commit 74c090b1. The DRIVER_ATOMIC cap cannot yet be exported because i915 lacks async support. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
Dear git bisect user, Even though this is the patch that introduced the WARN() you're bisecting, please notice that it's very likely that the problem you're facing was already present before this commit. In other words: this commit adds code to detect errors and give WARN()s about them, but the errors were already there. In order to continue your debug, please use the i915.mmio_debug option, check the backtraces and try to discover which read or write operation is causing the error message. Then check if this is happening because the register does not exist or because its power well is down when the operation is being done. On my SKL machine, if I use i915.mmio_debug=999, this patch triggers 42 WARNs just by booting. I didn't investigate them yet. Normal users are only going to get a single WARN due to the default i915.mmio_debug setting. Thank you for your comprehension, Paulo Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 8月, 2015 1 次提交
-
-
由 Paulo Zanoni 提交于
I was told that the "repurposed D1 definition" is still valid for SKL. It is BDW that is special due to its hotplug bug, so let's special-case BDW instead of HSW. Cc: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 28 7月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
Remove the leftovers, yay! AGP for i915 kms died long ago with commit 3bb6ce66 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Nov 13 22:14:16 2013 +0100 drm/i915: Kill legeacy AGP for gen3 kms and with ums now gone to there's really no users any more. Note that device_is_agp is only called when DRIVER_USE_AGP is set and since we've unconditionally cleared that since a while there are really no users left for i915_driver_device_is_agp. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 27 7月, 2015 1 次提交
-
-
由 Peter Zijlstra 提交于
Replace the deprecated atomic_{set,clear}_mask() usage with the now ubiquous atomic_{or,andnot}() functions. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 17 7月, 2015 1 次提交
-
-
由 Damien Lespiau 提交于
Time to light a candle and remove the preliminary_hw_support flag. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 15 7月, 2015 1 次提交
-
-
由 Maarten Lankhorst 提交于
Huzzah! \o/ Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NDaniel Stone <daniels@collabora.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 7月, 2015 1 次提交
-
-
由 Maarten Lankhorst 提交于
Instead of all the ad-hoc updating, duplicate the old state first before reading out the hw state, then restore it. intel_display_resume is a new function that duplicates the sw state, then reads out the hw state, and commits the old state. intel_display_setup_hw_state now only reads out the atomic state. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NDaniel Stone <daniels@collabora.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 23 6月, 2015 2 次提交
-
-
由 Chris Wilson 提交于
If the user disables the GPU reset using the i915.reset parameter and one occurs, report that we failed to reset the GPU. If we return early, as we currently do, then we leave all state intact (with a hung GPU) and clients block forever waiting for their requests to complete. Testcase: igt/gem_eio Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: Mark i915.reset as an unsafe modoption, as discussed with Chris.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
The module pciid list got lost, but somehow most distros seem to force-load drm drivers early and no one noticed for a while. Bug introduced in commit fd930478 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jun 19 20:27:27 2015 +0100 drm/i915: Remove KMS Kconfig option Reported-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 22 6月, 2015 2 次提交
-
-
由 Chris Wilson 提交于
Since we only support modesetting by default (disabling modesetting on the command line prevents i915.ko from loading), having a parameter to disable modesstting by default is superfluous, i.e. saying CONFIG_DRM_I915_KMS=n is equivalent to CONFIG_DRM_I915=n. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Veter <daniel.vetter@ffwll.ch> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
We have enough generic hotplug functions sprinkled all over i915_irq.c to warrant moving them to a file of their own. This should further underline the distinction between generic code in the new file and platform specific hotplug and irq code that remains in i915_irq.c. Add new intel_hpd_init_work to keep work functions static, and rename get_port_from_pin to intel_hpd_pin_to_port while increasing its visibility, but keep everything else the same. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 6月, 2015 3 次提交
-
-
由 Maarten Lankhorst 提交于
This reverts commit 490f400db5d886fc28566af69b02f6497f31be4b. We're not ready yet to make it atomic, we calculate some state in advance, but without atomic plane support atomic the hw readout will fail. It's required to revert this commit to revert the atomic hw state readout patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Maarten Lankhorst 提交于
Calculate all state using a normal transition, but afterwards fudge crtc->state->active back to its old value. This should still allow state restore in setup_hw_state to work properly. Calling intel_set_mode will cause intel_display_set_init_power to be called, make sure init_power gets set again afterwards. Changes since v1: - Fix to compile with v2 of the patch that adds intel_display_suspend. - Add intel_display_set_init_power. - Set return value to int to allow error checking. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Maarten Lankhorst 提交于
This is a function used to disable all crtc's. This makes it clearer to distinguish between when mode needs to be preserved and when it can be trashed. Changes since v1: - Copy power changes from intel_crtc_control. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 29 5月, 2015 1 次提交
-
-
由 Jani Nikula 提交于
There are plenty of hotplug related fields in struct drm_i915_private scattered all around. Group them under one hotplug struct. Clean up naming while at it. No functional changes. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 5月, 2015 1 次提交
-
-
由 Damien Lespiau 提交于
We need to re-init the display hardware when going out of suspend. This includes: - Hooking the PCH to the reset logic - Restoring CDCDLK - Enabling the DDB power Among those, only the CDCDLK one is a bit tricky. There's some complexity in that: - DPLL0 (which is the source for CDCLK) has two VCOs, each with a set of supported frequencies. As eDP also uses DPLL0 for its link rate, once DPLL0 is on, we restrict the possible eDP link rates the chosen VCO. - CDCLK also limits the bandwidth available to push pixels. So, as a first step, this commit restore what the BIOS set, until I can do more testing. In case that's of interest for the reviewer, I've unit tested the function that derives the decimal frequency field: #include <stdio.h> #include <stdint.h> #include <assert.h> #define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x))) static const struct dpll_freq { unsigned int freq; unsigned int decimal; } freqs[] = { { .freq = 308570, .decimal = 0b01001100111}, { .freq = 337500, .decimal = 0b01010100001}, { .freq = 432000, .decimal = 0b01101011110}, { .freq = 450000, .decimal = 0b01110000010}, { .freq = 540000, .decimal = 0b10000110110}, { .freq = 617140, .decimal = 0b10011010000}, { .freq = 675000, .decimal = 0b10101000100}, }; static void intbits(unsigned int v) { int i; for(i = 10; i >= 0; i--) putchar('0' + ((v >> i) & 1)); } static unsigned int freq_decimal(unsigned int freq /* in kHz */) { return (freq - 1000) / 500; } static void test_freq(const struct dpll_freq *entry) { unsigned int decimal = freq_decimal(entry->freq); printf("freq: %d, expected: ", entry->freq); intbits(entry->decimal); printf(", got: "); intbits(decimal); putchar('\n'); assert(decimal == entry->decimal); } int main(int argc, char **argv) { int i; for (i = 0; i < ARRAY_SIZE(freqs); i++) test_freq(&freqs[i]); return 0; } v2: - Rebase on top of -nightly - Use (freq - 1000) / 500 for the decimal frequency (Ville) - Fix setting the enable bit of HSW_NDE_RSTWRN_OPT (Ville) - Rename skl_display_{resume,suspend} to skl_{init,uninit}_cdclk to be consistent with the BXT code (Ville) - Store boot CDCLK in ddi_pll_init (Ville) - Merge dev_priv's skl_boot_cdclk into cdclk_freq - Use LCPLL_PLL_LOCK instead of (1 << 30) (Ville) - Replace various '0' by SKL_DPLL0 to be a bit more explicit that we're programming DPLL0 - Busy poll the PCU before doing the frequency change. It takes about 3/4 cycles, each separated by 10us, to get the ACK from the CPU (Ville) v3: - Restore dev_priv->skl_boot_cdclk, leaving unification with dev_priv->cdclk_freq for a later patch (Daniel, Ville) Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 5月, 2015 4 次提交
-
-
由 Damien Lespiau 提交于
The macros we use there are the magic ones that can take either dev or dev_priv. We'd like to move as much as possible towards dev_priv though. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Couldn't let it go! Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Currently bxt_resume_prepare() is only used in the runtime-resume path. Add it to the full S3/S4 path as well. v2: Rebase on top of the vlv_resume_prepare() shuffling around Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 11 5月, 2015 1 次提交
-
-
由 Peter Antoine 提交于
This patch fixes a timing issue that causes a GPU hang when the system comes out of power saving. During pm_resume, We are submitting batchbuffers before enabling Interrupts this is causing us to miss the context switch interrupt, and in consequence intel_execlists_handle_ctx_events is not triggered. This patch is based on a patch from Deepak S <deepak.s@intel.com> from another platform. The patch fixes an issue introduced by: commit e7778be1 drm/i915: Fix startup failure in LRC mode after recent init changes The above patch added a call to init_context() to fix an issue introduced by a previous patch. But, it then opened up a small timing window for the batches being added by the init_context (basically setting up the context) to complete before the interrupts have been turned on, thus hanging the GPU. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89600 Cc: stable@vger.kernel.org # 4.0+ Signed-off-by: NPeter Antoine <peter.antoine@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> [Jani: fixed typo in subject, massaged the comments a bit] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-