- 25 Apr, 2016 3 commits
-
-
Joonas Lahtinen authored
Move the better constructs/comments from i915_gem_stolen.c to early-quirks.c and increase readability in preparation of only having one set of functions. - intel_stolen_base -> gen3_stolen_base - use phys_addr_t instead of u32 for address for future proofing v2: - Print the invalid register values (Chris) (Omitting the register prefix as it's visible from backtrace.) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Tim Gore authored
This patch applies a performance enhancement workaround based on analysis of DX and OCL S-Curve workloads. We increase the General Priority Credits for L3SQ from the hardware default of 56 to the max value 62, and decrease the High Priority credits from 8 to 2. v2: Only apply to B0 onwards v3: Move w/a to per engine init, ie bxt_init_workarounds Signed-off-by:
Tim Gore <tim.gore@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com>
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 Apr, 2016 3 commits
-
-
Akash Goel authored
As a part of WaGsvDisableTurbo, Driver makes an early exit from the Gen9 Turbo enabling function, so doesn't program the Turbo Control register. But BIOS could leave the Hw Turbo as enabled, so need to explicitly clear out the Control register just to avoid inconsitency with debugfs interface, which will show Turbo as enabled only and that is not expected after adding the WaGsvDisableTurbo. Apart from this there is no problem even if the Turbo is left enabled in the Control register, as the Up/Down interrupts would remain masked. v2: Add explicit clearing of Turbo Control register to *_disable_rps() also for the similar consistency (Chris) Reviewed-by:Akash Goel <akash.goel@intel.com> Signed-off-by:
-
Akash Goel authored
There are certain registers, which captures the time elapsed in the in current Up/Down EI, for how long GT has been Idle/Busy/Avg in the current Up/Down EI and also in the previous Up/Down EI. These register values are reported by the i915_frequency_info debugfs interface. The Driver prints the 'us' suffix after the values, albeit they are actually in raw form & not in microsecond units. This patch removes the 'us' suffix so that its clear to User that values are indeed in raw form. v2: Present the values in microseconds unit also, after platform specific conversion (Chris) v3: Add a space between raw & microsecond value (Chris) Reviewed-by: -
Akash Goel authored
Added a new GT_PM_INTERVAL_TO_US macro to perform the platform specific conversion of PM time interval values to microseconds unit. Reviewed-by:
-
- 22 Apr, 2016 10 commits
-
-
Ville Syrjälä authored
Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around GPU hangs if the RPS EI/thresholds aren't suitably aligned. It seems like scheduling/timer interupts stop working somehow and things get stuck eg. in usleep_range(). I bisected the problem down to commit 8a586437 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function") I observed that before all the values were at least multiples of 25, but afterwards they are not. And rounding things up to the next multiple of 25 does seem to help, so lets' do that. I also tried roundup(..., 5) but that wasn't sufficient. Also I have no idea if we might need this sort of thing on gen9+ as well. These are the original EI/thresholds: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11800 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10250 GEN6_RP_UP_THRESHOLD 9225 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 8000 GEN6_RP_UP_THRESHOLD 6800 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 These are after 8a586437: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11875 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10156 GEN6_RP_UP_THRESHOLD 9140 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 7812 GEN6_RP_UP_THRESHOLD 6640 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 And these are what we have after this patch: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11875 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10175 GEN6_RP_UP_THRESHOLD 9150 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 7825 GEN6_RP_UP_THRESHOLD 6650 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 Cc: stable@vger.kernel.org Cc: Akash Goel <akash.goel@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B Fixes: 8a586437 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461159836-9108-1-git-send-email-ville.syrjala@linux.intel.comAcked-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
-
Shashank Sharma authored
This patch does the following: - Fakes live status of HDMI as connected (even if that's not). While testing certain (monitor + cable) combinations with various intel platforms, it seems that live status register doesn't work reliably on some older devices. So limit the live_status check for HDMI detection, only for platforms from gen7 onwards. V2: restrict faking live_status to certain platforms V3: (Ville) - keep the debug message for !live_status case - fix indentation of comment - remove "warning" from the debug message (Jani) - Change format of fix details in the commit message Fixes: 237ed86c ("drm/i915: Check live status before reading edid") Cc: stable@vger.kernel.org # v4.4 Suggested-by:Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461237606-16491-1-git-send-email-shashank.sharma@intel.comSigned-off-by:
-
Imre Deak authored
It's possible that BIOS enables PHY0, but it programmes only the first channel on it. Since we program the PHYs only during driver loading this is an incorrect configuration from the driver's point of view, since we may use both channels eventually. Detect this scenario and force reprogramming the PHY in this case. The actual scenario for me was that the lane optimization for the second channel in PHY0 was not setup by BIOS and so a state verification warning was triggered. Everything else was setup properly. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
If we skipped PHY0 initialization because it was already enabled by BIOS, we still have to wait for the PHY1 GRC calibration as that is done as part of the PHY0 init. v2: - Use the actual PHY index in the debug message in broxton_phy_wait_grc_done() (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
It's possible that BIOS enables PHY1 only to read out the GRC value from it to be used in PHY0 and then disables PHY1. In this case we can't use the PHY1 GRC value for state verification, so use instead the one in PHY0 always. Signed-off-by:
-
Matthew Auld authored
Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt. v2: use dev_priv directly for QUESTION_MACROS (Joonas Lahtinen) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Imre Deak authored
Right after runtime resume we know that we can re-enable DC5, since we just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly instead of delaying this until the next time we disable power well 2. Signed-off-by:
Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-5-git-send-email-imre.deak@intel.com
-
Imre Deak authored
After suspend-to-ram or -disk we don't know what power state the display HW will be, DC0 or DC9 are both possible states, so reset the software DC state tracking in these cases. This gets rid of 'DC state mismatch' error messages during resuming from ram or disk where we expected to be in DC9 (as set by the suspend handler) but we are in DC0. v2: - Remove extra WS in gen9_sanitize_dc_state() (Bob) Signed-off-by:
-
Imre Deak authored
Atm, we run the BSpec display core uninit/init sequences twice during system suspend/resume. While this shouldn't cause any problem, it's redundant, so get rid of the duplicate call. Signed-off-by:
-
Imre Deak authored
Initially we thought that the platform specific suspend/resume sequences can be shared between the runtime and system suspend/resume handlers. This turned out to be not true, we have quite a few differences on most of the platforms. This was realized already earlier by Paulo who inlined the platform specific resume_prepare handlers. We have the same problem with the corresponding suspend_complete handlers, there are platform differences that make it unfeasible to share the code between the runtime and system suspend paths. Also now we call functions that need to be paired like hsw_enable_pc8()/hsw_disable_pc8() from different levels of the call stack, which is confusing. Fix this by inlining the suspend_complete handlers too. This is also needed by the next patch that removes a redundant uninit/init call during system suspend/resume on BXT. No functional change. CC: Paulo Zanoni <przanoni@gmail.com> Signed-off-by:
-
- 21 Apr, 2016 1 commit
-
-
Imre Deak authored
In commit 5f304c87 ("drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMR") I forgot about the fact that SKL==KBL most of the time and that a secondary MISC IO power well request left on by the DMC is "expected". Tune down the corresponding WARN to be a debug message. This was caught by CI suspend tests. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
- 20 Apr, 2016 11 commits
-
-
Mika Kahola authored
It was noticed on bug #94087 that module parameter i915.edp_vswing=2 that should override the VBT setting to use default voltage swing (400 mV) was not applied for Broadwell. This patch provides a fix for this by checking if default i.e. higher voltage swing is requested to be used and applies the DDI translations table for DP instead of eDP (low vswing) table. v2: Combine two if statements into one (Jani) v3: Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461155942-7749-1-git-send-email-mika.kahola@intel.com Cc: stable@vger.kernel.org Signed-off-by:
-
Dave Gordon authored
The newly-introduced function i915_gem_object_pin_map() returns an ERR_PTR (not NULL) if the pin-and-map opertaion fails, so that's what we must check for. And it's nicer not to assign such a pointer-or-error to a structure being filled in until after it's been validated, so we should keep it local and avoid exporting a bogus pointer. Also, for clarity and symmetry, we should clear 'virtual_start' along with 'vma' when unmapping a ringbuffer. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Dave Gordon authored
Tidying up guc_init_proc_desc() and adding commentary to the client structure after the recent change in GuC page mapping strategy. Signed-off-by:
-
Alex Dai authored
Now that we keep the GuC client process descriptor permanently mapped, we don't really need to keep a local copy of the GuC's work-queue-head. So we can simplify the code a little by not doing this. Signed-off-by:
Alex Dai <yu.dai@intel.com> Signed-off-by:
-
Dave Gordon authored
Don't use kmap_atomic() for doorbell & process descriptor access. This patch fixes the BUG shown below, where the thread could sleep while holding a kmap_atomic mapping. In order not to need to call kmap_atomic() in this code path, we now set up a permanent kernel mapping of the shared doorbell and process-descriptor page, and use that in all doorbell and process-descriptor related code. BUG: scheduling while atomic: gem_close_race/1941/0x00000002 Modules linked in: hid_generic usbhid i915 asix usbnet libphy mii i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea drm coretemp i2c_hid hid video pinctrl_sunrisepoint pinctrl_intel acpi_pad nls_iso8859_1 e1000e ptp psmouse pps_core ahci libahci CPU: 0 PID: 1941 Comm: gem_close_race Tainted: G U 4.4.0-160121+ #123 Hardware name: Intel Corporation Skylake Client platform/Skylake AIO DDR3L RVP10, BIOS SKLSE2R1.R00.X100.B01.1509220551 09/22/2015 0000000000013e40 ffff880166c27a78 ffffffff81280d02 ffff880172c13e40 ffff880166c27a88 ffffffff810c203a ffff880166c27ac8 ffffffff814ec808 ffff88016b7c6000 ffff880166c28000 00000000000f4240 0000000000000001 Call Trace: [<ffffffff81280d02>] dump_stack+0x4b/0x79 [<ffffffff810c203a>] __schedule_bug+0x41/0x4f [<ffffffff814ec808>] __schedule+0x5a8/0x690 [<ffffffff814ec927>] schedule+0x37/0x80 [<ffffffff814ef3fd>] schedule_hrtimeout_range_clock+0xad/0x130 [<ffffffff81090be0>] ? hrtimer_init+0x10/0x10 [<ffffffff814ef3f1>] ? schedule_hrtimeout_range_clock+0xa1/0x130 [<ffffffff814ef48e>] schedule_hrtimeout_range+0xe/0x10 [<ffffffff814eef9b>] usleep_range+0x3b/0x40 [<ffffffffa01ec109>] i915_guc_wq_check_space+0x119/0x210 [i915] [<ffffffffa01da47c>] intel_logical_ring_alloc_request_extras+0x5c/0x70 [i915] [<ffffffffa01cdbf1>] i915_gem_request_alloc+0x91/0x170 [i915] [<ffffffffa01c1c07>] i915_gem_do_execbuffer.isra.25+0xbc7/0x12a0 [i915] [<ffffffffa01cb785>] ? i915_gem_object_get_pages_gtt+0x225/0x3c0 [i915] [<ffffffffa01d1fb6>] ? i915_gem_pwrite_ioctl+0xd6/0x9f0 [i915] [<ffffffffa01c2e68>] i915_gem_execbuffer2+0xa8/0x250 [i915] [<ffffffffa00f65d8>] drm_ioctl+0x258/0x4f0 [drm] [<ffffffffa01c2dc0>] ? i915_gem_execbuffer+0x340/0x340 [i915] [<ffffffff8111590d>] do_vfs_ioctl+0x2cd/0x4a0 [<ffffffff8111eac2>] ? __fget+0x72/0xb0 [<ffffffff81115b1c>] SyS_ioctl+0x3c/0x70 [<ffffffff814effd7>] entry_SYSCALL_64_fastpath+0x12/0x6a ------------[ cut here ]------------ v4: Only tear down doorbell & kunmap() client object if we actually succeeded in allocating a client object (Tvrtko Ursulin) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93847Original-version-by: -
Chris Wilson authored
Since we can only swap out shmemfs objects, those are the only ones that can influence the ability of the shrinker to free pages. Currently, all non-shmemfs objects have a raised pages_pin_count to protect them from the shrinker, so this just makes the logic for can_release_pages() clearer (and safer in future so that we don't over estimate our ability to free up pages from future non-swappable objects). Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Chris Wilson authored
Inside the shrinker we call can_release_pages() to indicate whether or not we can make forward progress in freeing up memory by unbinding that object. When adding our report to oom, we should be using the same logic. Whilst here, change the reporting from bytes to pages so that it looks smaller to the user!, is consistent with the neighbouring oom report itself which displays counts in pages, and makes the unsigned long overflow less likely. v2: Split oversized format string into two lines Signed-off-by:
-
Chris Wilson authored
When iterating over the bound list, we expect all objects there to have their pages pinned (by the bound VMA). So only report those objects with additional pin count on their pages as "pinned". These should be those objects used for display and hardware access. Reported-by:
-
Tvrtko Ursulin authored
Just two WARN_ONs followed by pointer dereference I spotted by accident. v2: Remove some more of the same. Signed-off-by:
-
Tvrtko Ursulin authored
Looks like DPF was not implemented for gen8+ but the IER and IMR are still enabled on initialization. Since there is no code to handle this interrupt, gate the irq enablement behind HAS_L3_DPF in case the feature gets enabled in the future. Signed-off-by:
-
Tim Gore authored
WaEnableSamplerGPGPUPreemptionSupport fixes a problem related to mid thread pre-emption. Signed-off-by:
-
- 19 Apr, 2016 12 commits
-
-
Shubhangi Shrivastava authored
Since commit 30d9aa42 ("drm/i915: Read sink_count dpcd always"), the status of a DP connector depends on its sink count value. However, some eDP panels don't set that value appropriately, causing them to be reported as disconnected. Fix this by ignoring sink count for eDP. v2: Rephrased commit message. (Ander) In case of eDP, returning status as connected if DPCD read succeeds to avoid any further operations. Fixes: 30d9aa42 ("drm/i915: Read sink_count dpcd always") Cc: Ander Conselvan De Oliveira <conselvan2@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Tested-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460444034-22320-1-git-send-email-shubhangi.shrivastava@intel.com
-
jim.bride@linux.intel.com authored
In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some much needed clean-up was done, but unfortunately part of the change broke DP MST. The real issue was setting the connector state to disconnected in the MST case, which is good, but the code then (after a goto) checks if the connector state is not connected and shuts down MST if this is the case, which is bad. With this change both SST and MST seem to be happy. v2: Add removed check further up in the function to be sure that MST is shut down when we lose the link. (Ander) Fixes: commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> cc: Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by:
Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
Lyude <cpaul@redhat.com> Signed-off-by:
-
Joonas Lahtinen authored
Do not use magic numbers, do not prefix stuff with "PCI_", do not declare registers in implementation files. Also move the PCI registers under correct comment in i915_reg.h. v2: - Consistently use BSM (not BDSM or other variants from PRM) (Chris) - Also include register address to help identify the register (Chris) v3: - Refer to register value as *_val instead of *_reg (Chris) v4: - Make style checker happy Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Matthew Auld authored
We need to kunmap pt_vaddr and not pt itself, otherwise we end up mapping a bunch of pages without ever unmapping them. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: d1c54acd ("drm/i915/gtt: Introduce kmap|kunmap for dma page") Signed-off-by:
-
Ville Syrjälä authored
The power cycle delay starts _after_ turning off the panel power. Do the msleep after frobbing the pmic panel power gpio. Also toss in a FIXME about optimizing away needless waits. Cc: Shobhit Kumar <shobhit.kumar@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Fixes: fc45e821 ("drm/i915: Use the CRC gpio for panel enable/disable") Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Currently we're trying to define HSW/BDW power wells by what's not included. Let's do it the other way around, so that you can actually tell when the power well would get enabled. This will also allow us to add new power domains without accidentally adding it to the HSW/BDW display power domains. The current set of domains looks rather buggy even: - POWER_DOMAIN_MODESET is included in the display power well needlessly - DDI-B to DDI-E were not part of the display power well when they should be So let's fix that up while at it. Signed-off-by:
-
Ville Syrjälä authored
Currently we're using POWER_DOMAIN_MASK as the power domains for the display power well on VLV/CHV. That includes all power domains even though the disp2d/pipe-a power well is not needed for a lot of things. Let's reduce these to what we actually need. Signed-off-by:
-
Ville Syrjälä authored
The always-on well is the same as runtime PM, so we should just "enable" it for any power domain. Throw out the usless FOO_ALWAYS_ON_DOMAINS defines and just use POWER_DOMAIN_MASK. Signed-off-by:
-
Ville Syrjälä authored
intel_pipe_will_have_type() doesn't just look at the passied in pipe_config, instead it expects there to be a full atomic state behind it. Obviously that won't go so well when vlv_force_pll_on() just uses a temp pipe_config. Fix things by using pipe_config->has_dsi_encoder instead intel_pipe_will_have_type(INTEL_OUTPUT_DSI) to check if we need to actually enable the DPLL. Here's an example oops for reference: BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 IP: [<ffffffffa0389a5b>] intel_pipe_will_have_type+0x15/0x7b [i915] PGD 7acda067 PUD 72696067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole psmouse atkbd iTCO_wdt libps2 coretemp hwmon efi_pstore intel_rapl punit_atom_debug efivars pcspkr i2c_i801 r8169 lpc_ich mii processor_thermal_device snd_soc_rt5670 intel_soc_dts_iosf snd_soc_rl6231 i2c_hid hid snd_intel_sst_acpi snd_intel_sst_core snd_soc_sst_mfld_platform snd_soc_sst_match snd_soc_core i8042 serio snd_compress snd_pcm snd_timer snd i2c_designware_platform sdhci_acpi i2c_designware_core soundcore sdhci pwm_lpss_platform mmc_core pwm_lpss spi_pxa2xx_platform evdev int3403_thermal int3400_thermal int340x_thermal_zone acpi_thermal_rel sch_fq_codel ip_tables x_tables ipv6 autofs4 CPU: 3 PID: 290 Comm: Xorg Tainted: G U 4.6.0-rc4-bsw+ #2876 Hardware name: Intel Corporation CHERRYVIEW C0 PLATFORM/Braswell CRB, BIOS BRAS.X64.X088.R00.1510270350 10/27/2015 task: ffff88007a8dd200 ti: ffff880173ac4000 task.ti: ffff880173ac4000 RIP: 0010:[<ffffffffa0389a5b>] [<ffffffffa0389a5b>] intel_pipe_will_have_type+0x15/0x7b [i915] RSP: 0018:ffff880173ac7928 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880176594000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000009 RDI: ffff880176594000 RBP: ffff880173ac7930 R08: 0000000000019290 R09: 0000000000000000 R10: ffff880173ac7890 R11: 00000000000080cf R12: ffff88017fbd4000 R13: ffffffffa03e3c44 R14: ffff88007492c000 R15: ffff88007492c000 FS: 00007ff8936a6940(0000) GS:ffff88017ef80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 0000000177e08000 CR4: 00000000001006e0 Stack: ffff880176594000 ffff880173ac7948 ffffffffa0389b42 ffff880176594000 ffff880173ac7978 ffffffffa0396e02 ffff8801765b0000 ffff88007af660d8 0000000000000000 0000000000000004 ffff880173ac79c0 ffffffffa03b6b64 Call Trace: [<ffffffffa0389b42>] chv_compute_dpll.isra.39+0x33/0x55 [i915] [<ffffffffa0396e02>] vlv_force_pll_on+0x80/0xc6 [i915] [<ffffffffa03b6b64>] vlv_power_sequencer_pipe+0x29b/0x3dd [i915] [<ffffffffa03b6cd4>] _pp_stat_reg+0x2e/0x38 [i915] [<ffffffffa03b6dc1>] wait_panel_status+0x4c/0x1ec [i915] [<ffffffffa03b6fcb>] wait_panel_power_cycle+0x6a/0xb4 [i915] [<ffffffffa03b70da>] edp_panel_vdd_on+0xc5/0x1d1 [i915] [<ffffffffa03b861b>] intel_dp_aux_ch+0x55/0x572 [i915] [<ffffffff810af5c8>] ? mark_held_locks+0x5d/0x74 [<ffffffff81518e61>] ? mutex_lock_nested+0x321/0x346 [<ffffffff81094007>] ? preempt_count_sub+0xf2/0x102 [<ffffffffa03b8cb4>] intel_dp_aux_transfer+0x17c/0x1b5 [i915] [<ffffffffa03028ef>] drm_dp_dpcd_access+0x62/0xed [drm_kms_helper] [<ffffffffa0302995>] drm_dp_dpcd_read+0x1b/0x1f [drm_kms_helper] [<ffffffffa03b5147>] intel_dp_dpcd_read_wake+0x31/0x69 [i915] [<ffffffffa03bb36a>] intel_dp_long_pulse+0x15f/0x5ed [i915] [<ffffffffa03bbb09>] intel_dp_detect+0x79/0x95 [i915] [<ffffffffa030340e>] drm_helper_probe_single_connector_modes+0xc7/0x3db [drm_kms_helper] [<ffffffffa029de23>] drm_mode_getconnector+0xe9/0x333 [drm] [<ffffffff810b1cfb>] ? lock_acquire+0x137/0x1df [<ffffffffa0292364>] drm_ioctl+0x266/0x3ae [drm] [<ffffffffa029dd3a>] ? drm_mode_getcrtc+0x126/0x126 [drm] [<ffffffff811af082>] vfs_ioctl+0x18/0x34 [<ffffffff811af682>] do_vfs_ioctl+0x547/0x5fe [<ffffffff811b9acb>] ? __fget_light+0x62/0x71 [<ffffffff811af77c>] SyS_ioctl+0x43/0x61 [<ffffffff81001a82>] do_syscall_64+0x63/0xf8 [<ffffffff8151bc9a>] entry_SYSCALL64_slow_path+0x25/0x25 Code: 35 00 40 a0 e8 97 4b ce e0 b8 17 00 00 00 5d c3 b8 17 00 00 00 c3 0f 1f 44 00 00 55 31 c0 31 d2 48 89 e5 53 48 8b 8f e8 01 00 00 <44> 8b 49 30 41 39 c1 7e 2d 4c 8b 51 38 4c 8b 41 40 49 83 3c c2 RIP [<ffffffffa0389a5b>] intel_pipe_will_have_type+0x15/0x7b [i915] RSP <ffff880173ac7928> CR2: 0000000000000030 The regressing patch wasn't exactly new (as in first posted more than six months ago), so I'm a bit baffled how I didn't manage to hit this myself so far. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Marius Vlad <marius.c.vlad@intel.com> Reported-by:
Marius Vlad <marius.c.vlad@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94995 Fixes: cd2d34d9 ("drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV") Signed-off-by:
-
Imre Deak authored
While we disable runtime PM and with that display power well support if the DMC firmware isn't loaded, we still want to disable power wells during system suspend and driver unload. So drop/reacquire the corresponding power refcount during suspend/resume and driver unloading. This also means we have to check if DMC is not loaded and skip enabling DC states in the power well code. v2: - Reuse intel_csr_ucode_suspend() in intel_csr_ucode_fini() instead of opencoding the former. (Chris) - Add docbook comment to the public resume and suspend functions. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
The driver's VDD on/off logic assumes that whenever the VDD is on we also hold an AUX power domain reference. Since BIOS can leave the VDD on during booting and resuming and on DDI platforms we won't take a corresponding power reference, the above assumption won't hold on those platforms and an eventual delayed VDD off work will do an extraneous AUX power domain put resulting in a refcount underflow. Fix this the same way we did this for non-DDI DP encoders: commit 6d93c0c4 ("drm/i915: fix VDD state tracking after system resume") At the same time call the DP encoder suspend handler the same way as the non-DDI DP encoders do to flush any pending VDD off work. Leaving the work running may cause a HW access where we don't expect this (at a point where power domains are suspended already). While at it remove an unnecessary function call indirection. This fixed for me AUX refcount underflow problems on BXT during suspend/resume. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: stable@vger.kernel.org Signed-off-by:
-
Imre Deak authored
During system resume we depended on pci_enable_device() also putting the device into PCI D0 state. This won't work if the PCI device was already enabled but still in D3 state. This is because pci_enable_device() is refcounted and will not change the HW state if called with a non-zero refcount. Leaving the device in D3 will make all subsequent device accesses fail. This didn't cause a problem most of the time, since we resumed with an enable refcount of 0. But it fails at least after module reload because after that we also happen to leak a PCI device enable reference: During probing we call drm_get_pci_dev() which will enable the PCI device, but during device removal drm_put_dev() won't disable it. This is a bug of its own in DRM core, but without much harm as it only leaves the PCI device enabled. Fixing it is also a bit more involved, due to DRM mid-layering and because it affects non-i915 drivers too. The fix in this patch is valid regardless of the problem in DRM core. v2: - Add a code comment about the relation of this fix to the freeze/thaw vs. the suspend/resume phases. (Ville) - Add a code comment about the inconsistent ordering of set power state and device enable calls. (Chris) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: stable@vger.kernel.org Signed-off-by:
-
