- 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 2 次提交
-
-
由 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>
-
由 Jesse Barnes 提交于
Looks like it was introduced in: commit 650ad970 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddf "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9c "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. [airlied: I messed up a merge - readd this] References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NDarren Hart <dvhart@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # c9c52e24: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 08 5月, 2015 3 次提交
-
-
由 Jesse Barnes 提交于
Looks like it was introduced in: commit 650ad970 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddf "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9c "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NDarren Hart <dvhart@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # c9c52e24: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com> [danvet: Repick this commit from 5df0582b becuase Dave Airlie lost it in his merge commit e1dee197.] Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Suketu Shah 提交于
Add triggers for DC6 as per details provided in skl_enable_dc6 and skl_disable_dc6 implementations. Also Call POSTING_READ for every write to a register to ensure it is written to immediately v1: Remove POSTING_READ and intel_prepare_ddi calls as they've been added in previous patches. v2: 1] Remove check for backlight disabled as it should be the case by that time. 2] Mark DC5 as disabled when enabling DC6. 3] Return from DC5-disabling function early if DC5 is already be disabled which can happen due to DC6-enabling earlier. 3] Ensure CSR firmware is loaded after resume from DC6 as corresponding memory contents won't be retained after runtime-suspend. 4] Ensure that CSR isn't identified as loaded before CSR-loading program is called during runtime-resume. v3: Rebase to latest Modified as per review comments from Imre and after discussion with Art: 1] DC6 should be preferably enabled when PG2 is disabled by SW as the check for PG1 being disabled is taken of by HW to enter DC6, and disabled when PG2 is enabled respectively. This helps save more power, especially in the case when display is disabled but GT is enabled. Accordingly, replacing DC5 trigger sequence with DC6 for SKL. 2] DC6 could be enabled from intel_runtime_suspend() function, if DC5 is already enabled. 3] Move CSR-load-status setting code from intel_runtime_suspend function to a new function. v4: 1] Enable/disable DC6 only when toggling the power-well using a newly defined macro ENABLE_DC6. v5: 1] Load CSR on system resume too as firmware may be lost on system suspend preventing enabling DC5, DC6. 2] DDI buffers shouldn't be programmed during driver-load/resume as it's already done during modeset initialization then and also that the encoder list is still uninitialized by then. Therefore, call intel_prepare_ddi function right after disabling DC6 but outside skl_disable_dc6 function and not during driver-load/resume. v6: 1] Rebase to latest. 2] Move SKL_ENABLE_DC6 macro definition from intel_display.c to intel_runtime_pm.c. v7: 1) Refactored the code for removing the warning got from checkpatch. 2) After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v8: - Reverted the changes done in v7. - Removed the condition check in skl_prepare_resune(). (Animesh) Issue: VIZ-2819 Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: NSuketu Shah <suketu.j.shah@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NAnimesh Manna <animesh.manna@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw->size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw->data used directly for parsing the header info & memory allocation only done separately for payload. (Animesh) v16: - No need for out_regs label in i915_driver_load(), so removed it. - Changed the firmware name as skl_dmc_ver1.bin, followed naming convention <platform>_dmc_<api-version>.bin (Animesh) Issue: VIZ-2569 Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NAnimesh Manna <animesh.manna@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 4月, 2015 1 次提交
-
-
由 Imre Deak 提交于
Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0 Author: Imre Deak <imre.deak@intel.com> Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Cc: stable@vger.kernel.org Signed-off-by: NImre Deak <imre.deak@intel.com> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 16 4月, 2015 1 次提交
-
-
由 Suketu Shah 提交于
Add triggers for DC9 as per details provided in bxt_enable_dc9 and bxt_disable_dc9 implementations. v1: - Add SKL check in gen9_disable_dc5 as it is possible for DC5 to remain disabled only for SKL. - Add additional checks for whether DC5 is already disabled during DC5-disabling only for BXT. v2: - rebase to latest. - Load CSR during DC9 disabling in the beginning before DC9 is disabled. - Make gen9_disable_dc5 function non-static as it's being called by functions in i915_drv.c. - Enable DC9-related functionality using a macro. v3: (imre) - remove BXT_ENABLE_DC9, we want DC9 always, and it's only valid on BXT - remove DC5 disabling and CSR FW loaded check, these are nop atm - squash in Vandana's "Do ddi_phy_init always" patch v4: - add TODO to re-enable DC5 during resume if CSR FW is available (sagar) Signed-off-by: NSuketu Shah <suketu.j.shah@intel.com> Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> (v2) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NSagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 4月, 2015 2 次提交
-
-
由 Daisy Sun 提交于
Enable FBC feature on Broxton Issue: VIZ-3784 Signed-off-by: NDaisy Sun <daisy.sun@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NAntti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
v2: Switch to info->ring_mask and add VEBOX support. v3: Fold in update from Damien. v4: Add GEN_DEFAULT_PIPEOFFSETS and IVB_CURSOR_OFFSETS v5: set no-LLC (imre) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1,v4) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v4) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NAntti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 4月, 2015 3 次提交
-
-
由 Jesse Barnes 提交于
Looks like it was introduced in: commit 650ad970 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddf "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9c "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NDarren Hart <dvhart@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # c9c52e24: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Deepak S 提交于
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a sticky bit and it will always be set. So ignore Check for previous Gfx force off during suspend and allow the force clk as part S0ix Sequence Signed-off-by: NDeepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jesse Barnes 提交于
Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NDarren Hart <dvhart@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 31 3月, 2015 1 次提交
-
-
由 Deepak S 提交于
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a sticky bit and it will always be set. So ignore Check for previous Gfx force off during suspend and allow the force clk as part S0ix Sequence Signed-off-by: NDeepak S <deepak.s@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 3月, 2015 2 次提交
-
-
由 Ville Syrjälä 提交于
CHV should be in a good enough shape now, so let's drop the .is_preliminary flag. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
With the two-step reset counter increments which braket the actual reset code and the subsequent wake-up we're guaranteeing that all the lockless waiters _will_ be woken up. And since we unconditionally bail out of waits with -EAGAIN (or -EIO) in that case there is not risk of lost interrupt enabling bits when the lockless wait code races against a gpu reset. Let's remove this FIXME as resolved then. Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 3月, 2015 1 次提交
-
-
由 Imre Deak 提交于
Bjørn reported that his machine hang during hibernation and eventually bisected the problem to the following commit: commit da2bc1b9 Author: Imre Deak <imre.deak@intel.com> Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler The problem seems to be that after the kernel puts the device into D3 the BIOS still tries to access it, or otherwise assumes that it's in D0. This is clearly bogus, since ACPI mandates that devices are put into D3 by the OSPM if they are not wake-up sources. In the future we want to unify more of the driver's runtime and system suspend paths, for example by skipping all the system suspend/hibernation hooks if the device is runtime suspended already. Accordingly for all other platforms the goal is still to properly power down the device during hibernation. v2: - Another GEN4 Lenovo laptop had the same issue, while platforms from other vendors (including mobile and desktop, GEN4 and non-GEN4) seem to work fine. Based on this apply the workaround on all GEN4 Lenovo platforms. - add code comment about failing platforms (Ville) Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.htmlReported-and-bisected-by: NBjørn Mork <bjorn@mork.no> Cc: stable@vger.kernel.org # v3.19 Signed-off-by: NImre Deak <imre.deak@intel.com> Acked-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 27 2月, 2015 2 次提交
-
-
由 Daniel Vetter 提交于
Again, good riddance to UMS! Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
UMS is dead, yay! Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 2月, 2015 2 次提交
-
-
由 Andreas Ruprecht 提交于
Commit 03dae59c ("drm/i915: Ditch UMS config option") removed CONFIG_DRM_I915_UMS from the Kconfig file, but i915_drv.c still references this option in two #ifndef statements. As an undefined config option will always be 'false', we can drop the #ifndefs alltogether and adapt the printed error message. This inconsistency was found with the undertaker tool. Signed-off-by: NAndreas Ruprecht <rupran@einserver.de> [danvet: Undo logging change as requested by Jani.] Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
v2: leave intel_skylake_info alone (Rodrigo, Daniel) Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 29 1月, 2015 1 次提交
-
-
由 Chris Wilson 提交于
When run as a timer, i915_hangcheck_elapsed() must adhere to all the rules of running in a softirq context. This is advantageous to us as we want to minimise the risk that a driver bug will prevent us from detecting a hung GPU. However, that is irrelevant if the driver bug prevents us from resetting and recovering. Still it is prudent not to rely on mutexes inside the checker, but given the coarseness of dev->struct_mutex doing so is extremely hard. Give in and run from a work queue, i.e. outside of softirq. v2: Use own workqueue to avoid deadlocks (Daniel) Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <dnaiel.vetter@ffwll.chm> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> [danvet: Remove accidental kerneldoc comment starter, to appease the 0 day builder.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 1月, 2015 3 次提交
-
-
由 Matt Roper 提交于
We don't have full atomic modeset support yet, but the "nuclear pageflip" subset of functionality (i.e., plane operations only) should be ready. Allow the user to force atomic on for debug purposes, or for fixed-purpose embedded devices that will only use atomic for plane updates. The term 'nuclear' is used here instead of 'atomic' to make it clear that this doesn't allow full atomic modeset support, just a (very useful) subset of the atomic functionality. We'll drop the kernel parameter and unconditionally enable atomic in a future patch once all of the necessary pieces are in. v2: - Use module_param_named_unsafe() (Daniel) - Simplify comment on DRIVER_ATOMIC guard (Daniel) v3: - Make the parameter "nuclear_pageflip" rather than just "nuclear" for clarity. (Ander) v4: - Make the internal variable "nuclear_pageflip" as well as the command-line option. (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
We have multiple forcewake domains now on recent gens. Change the function naming to reflect this. v2: More verbose names (Chris) v3: Rebase v4: Rebase v5: Add documentation for forcewake_get/put Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Calling intel_runtime_pm_put() is illegal from a soft-irq context, so revert the crude hack commit aa0b3b5b Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Apr 1 14:55:07 2014 -0300 drm/i915: don't schedule force_wake_timer at gen6_read and apply the single line corrective instead. v2: assert forcewake is off after the forcewake_reset (Paulo) References: https://bugs.freedesktop.org/show_bug.cgi?id=80913 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v1) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 1月, 2015 1 次提交
-
-
由 Rodrigo Vivi 提交于
It seems in the past we have BDW with PCH not been propperly identified and we force it to be LPT and we were warning !IS_HASWELL on propper identification. Now that products are out there we are receiveing logs with this incorrect WARN. And also according to local tests on all production BDW here ULT or HALO we don't need this force anymore. So let's clean this block for real. v2: Fix LPT_LP WARNs to avoid wrong warns on BDW_ULT (By Jani). Reference: https://bugs.freedesktop.org/attachment.cgi?id=110972 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Xion Zhang <xiong.y.zhang@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 12 1月, 2015 1 次提交
-
-
由 Imre Deak 提交于
This will be needed by later patches, so factor it out. No functional change. v2: - s/dev_to_i915_priv/dev_to_i915/ (Jani) - don't use the helper in i915_pm_suspend (Chris) - simplify the helper (Chris) v3: - remove redundant upcasting in the helper (Daniel) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 12月, 2014 1 次提交
-
-
由 Dave Airlie 提交于
This reverts commit 355a7018. This had some bad side effects under normal operation, and should have been dropped earlier. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 16 12月, 2014 2 次提交
-
-
由 Deepak S 提交于
With cherryview onwards, Gunit hardware itself save and restore all the Gunit registers. Skipping the "vlv_save_gunit_s0ix_state" & "vlv_restore_gunit_s0ix_state" for cherryview in S3/S0ix sequence. Signed-off-by: NDeepak S <deepak.s@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
Atm, we don't disable RPS interrupts and related work items before resetting the GPU. This may interfere with the following GPU initialization and cause RPS interrupts to show up in PM_IIR too early before calling gen6_enable_rps_interrupts() (triggering a WARN there). Solve this by disabling RPS interrupts and flushing any related work items before resetting the GPU. v2: - split out the common parts of the gt suspend and the new gt reset functions (Paulo) v3: - remove the check for UMS, it's a NOP nowadays (Daniel) Reported-by: NHe, Shuang <shuang.he@intel.com> Testcase: igt/gem_reset_stats/ban-render Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86644Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-