- 19 Apr, 2016 5 commits
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461000844-20543-1-git-send-email-ville.syrjala@linux.intel.comTested-by:
Jani Nikula <jani.nikula@intel.com>
-
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 <imre.deak@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460980101-14713-1-git-send-email-imre.deak@intel.com
-
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:
-
Imre Deak authored
If system resume fails, this may lead to a runtime PM wake reference underflow used for runtime PM state checking. Fixes: 1f814dac ("drm/i915: add support for checking if we hold an RPM reference") Signed-off-by:
-
- 18 Apr, 2016 4 commits
-
-
Imre Deak authored
The workaround added in commit c6782b76 ("drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR") needs to be applied on Kabylake too as shown by the corresponding timeout errors about power well 1 and MISC IO power well disabling in the latest CI run. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460748778-4484-1-git-send-email-imre.deak@intel.com
-
Ville Syrjälä authored
When a vblank wait times out in intel_atomic_wait_for_vblanks() we just get a cryptic 'WARN_ON(!ret)' backtrace in dmesg. Repace it with something that tells you what actually happened. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Chris Wilson authored
The legacy cursor ioctl expects to be asynchronous with respect to other screen updates, in particular page flips. As X updates the cursor from a signal context, if the cursor blocks then it will stall both the input and output chains causing bad stuttering and horrible UX. Reported-and-tested-by:
Rafael Ristovski <rafael.ristovski@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94980 Fixes: 5008e874 ("drm/i915: Make wait_for_flips interruptible.") Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Jani Nikula authored
Due to "some hardware limitation" the DPI enable bit in port C control register does not get set on VLV. As a workaround we check the status in pipe B conf register instead. The workaround was added in commit c0beefd2 Author: Gaurav K Singh <gaurav.k.singh@intel.com> Date: Tue Dec 9 10:59:20 2014 +0530 drm/i915: Software workaround for getting the HW status of DSI Port C on BYT Empirical evidence (on Surface 3 with DSI on port C per VBT) shows that this is the case also on CHV, so extend the workaround to CHV. We still have the device ready register check in place, so this should not get confused with e.g. HDMI on pipe B. This fixes a number of state checker warnings on CHV DSI port C. Cc: stable@vger.kernel.org Reviewed-by:
-
- 15 Apr, 2016 25 commits
-
-
Tvrtko Ursulin authored
Show a total and purgeable number of pin mapped objects and their total and purgeable size. Example output (new stat prefixed with a star): # cat i915_gem_objects 19920 objects, 289243136 bytes 19920 [18466] objects, 288714752 [267911168] bytes in gtt 0 [0] active objects, 0 [0] bytes 19917 [18466] inactive objects, 288714752 [267911168] bytes 0 unbound objects, 0 bytes 0 purgeable objects, 0 bytes 1 pinned mappable objects, 3145728 bytes 0 fault mappable objects, 0 bytes * 19914 [0] pin mapped objects, 285560832 [0] bytes [purgeable] 4294967296 [268435456] gtt total Signed-off-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Tvrtko Ursulin authored
Reflect the status of obj->mapping as added with the i915_gem_object_pin_map API. 'M' was chosen to designate the pin mapped status. Signed-off-by:
-
Ville Syrjälä authored
We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI, and just trying to frob the display timings to include borders results in a corrupted picture. So reject the 'Center' scaling mode on GMCH platforms for eDP and DSI. TODO: Should really filter out the unsupported modes from the prop, but that would be fairly invasive since the prop is now created and stored by drm core. So leave it for a rainy day. Signed-off-by:
-
Ville Syrjälä authored
Add the scaling mode property to DSI connectors, handle changes in the property value, and compute the panel fitter state during .compute_config(). v2: Handle BXT as well Signed-off-by:
-
Ville Syrjälä authored
Fold the DSI PLL configuration functions into the DSI PLL enable functions since they are small and not called from anywhere else. Signed-off-by:
-
Ville Syrjälä authored
Compute the DSI PLL parameters during .compute_config() rather than .pre_pll_enable() so that we can fail gracefully if we can't find suitable parameters. In order to do that we need to store the DSI PLL parameters in pipe_config. v2: Handle BXT too Signed-off-by:
-
Ville Syrjälä authored
Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While the DPLL isn't used to provide the clock we still need the refclock, and it appears that the pixel repeat factor also has an effect on DSI output. So set up eveyrhing in DPLL and DPLL_MD as we would do for DP/HDMI/VGA, but don't actually enable the DPLL or configure the dividers via DPIO. Signed-off-by:
-
Dongwon Kim authored
This patch is to correct one thing in this commit: commit 25a56705 Author: Dongwon Kim <dongwon.kim@intel.com> Date: Wed Mar 16 18:06:13 2016 -0700 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit This reversed bit polarity is actually common for all BXT and APL SoCs. Therefore, revision checking in the original commit should be removed to make the bit set regardless of revision ID of GFX block. Signed-off-by:
Dongwon Kim <dongwon.kim@intel.com> Reviewed-by:
-
Imre Deak authored
With the preceding fixes runtime PM should be functional, I could runtime suspend/resume the device without problems. Signed-off-by:
David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-17-git-send-email-imre.deak@intel.com
-
Imre Deak authored
With the preceding fixes power well support should be functional on Broxton, I could enter/exit DC5 without problems. This reverts commit 18024199. CC: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Imre Deak authored
I caught a few errors in our current PHY/CDCLK programming by sanity checking the actual programmed state, so I thought it would be also useful for the future. In addition to verifying the state after programming it also verify it after exiting DC5, to make sure DMC restored/kept intact everything related. v2: - Inlining __phy_reg_verify_state() doesn't make sense and also incorrect, so don't do it (PW/CI gcc) v3: - Rebase on latest -nightly Signed-off-by:
-
Imre Deak authored
If BIOS has already programmed and enabled a PHY, don't reprogram it as that may interfere with the currently active outputs. A follow-up patch will add state verification, so we can catch any misconfiguration on BIOS's behalf. Signed-off-by:
-
Imre Deak authored
When determining whether CDCLK is enabled by BIOS and so we should skip reprogramming it, we didn't check the related DBUF power request and state. In theory BIOS could enable one without the other so check for this case and reprogram things if something is amiss. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-13-git-send-email-imre.deak@intel.com
-
Imre Deak authored
Power well 1 is managed by the DMC firmware so don't toggle it on-demand from the driver. This means we need to follow the BSpec display initialization sequence during driver loading and resuming (both system and runtime) and enable power well 1 only once there. Afterwards DMC will toggle power well 1 whenever entering/exiting DC5. For this to work we also need to do away getting the PLL power domain, since that just kept runtime PM disabled for good. Signed-off-by:
-
Imre Deak authored
The power-down step logically belongs to the individual PHY uninit sequence so move it there. The only functional change is that we will power down now PHY 1 separately before PHY 0 and preserve the other bits in the register which are defined as reserved. Signed-off-by:
-
Imre Deak authored
For internal APIs passing dev_priv is preferred to reduce indirections, so convert over a few DDI PHY, CDCLK helpers. No functional change. Signed-off-by:
-
Imre Deak authored
On Broxton we need to enable/disable power well 1 during the init/unit display sequence similarly to Skylake/Kabylake. The code for this will be added in a follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's a simple function called only from a single place and having it inlined in the Skylake display core init/unit functions will make it easier to compare it with its Broxton counterpart. This also flips the order of Misc IO and power well 1 disabling which matches the enabling order. The specification doesn't prescribe the disabling order, so this should be fine. v2: - Fix incorrect enable vs. disable power well call in skl_display_core_uninit() (Patrik) - Add commit comment about chaning the order of PW1 and Misc IO power well disabling (Patrik) CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
Imre Deak authored
On SKL/KBL suspend-to-idle (aka freeze/s0ix) is performed with DMC firmware assistance where the target display power state is DC6. On Broxton on the other hand we don't use the firmware for this, but rely instead on a manual DC9 flow. For this we have to uninitialize the display following the BSpec display uninit sequence, just as during S3/S4, so make sure we follow this sequence. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
Imre Deak authored
The display power well support and DC state management doesn't depend on runtime PM support, so remove the incorrect asserts about this. Also Broxton does support DC5, so the related assert in assert_can_enable_dc5() is incorrect. There is a more generic and correct assert for this already in gen9_set_dc_state(), so we can remove all the other ones. At the same time convert WARNs to WARN_ONCE for consistency with the other DC state asserts. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
Imre Deak authored
So far we only power well enabling was synchronous not disabling. Since we don't exactly know how the firmware (both DMC and PCU) synchronizes against the actual power well state during DC transitions, make the disabling also synchronous. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
Imre Deak authored
DMC forces on power well 1 and the misc IO power well by setting the corresponding request bits both in the BIOS and the DEBUG power well request registers. This is somewhat unexpected since the firmware should really just save and restore state but not alter it. We also depend on being able to disable power well 1, and the misc IO power well before entering S3/S4 on BXT and SKL or entering DC9 on BXT. To fix this make sure these request bits are cleared whenever we want to disable the given power wells. On SKL there is another twist where the firmware also clears the power well 1 request bit in HSW_POWER_WELL_DRIVER (but not that of the misc IO power well). This happens to not cause a problem due to the forced-on request bits in the other request registers. I've filed a bug about all this, but fixing that may take a while and having this sanity check in place makes sense even for future firmware versions. At the same time also check the KVMR request bits. I haven't seen this being altered, but we don't expect any request bits in here either, so sanitize this register as well. v2: - Apply the workaround on SKL as well. I noticed the related failure from the CI report, later Patrik also reported seeing it on his machine. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
Imre Deak authored
This register is read-only, so we have never actually set OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code comment about this. I filed a specification update request to clarify this there. CC: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by:
-
Imre Deak authored
This has been corrected in BSpec quite some time ago, but we missed it somehow. The wrong field definitions resulted in configuring PHY0 with an incorrect GRC value. v2: - Remove the FIXME comment, we left in the code exactly about this issue. (Ville) CC: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by:
-
Imre Deak authored
DMC version 1.06 has a known bug, where the firmware polls forever for a port PLL to lock, if the PLL was disabled when entering DC5, which locks up the machine. Version 1.07 fixes this, so make that the minimum required version on BXT. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Gustavo Padovan authored
Replace the legacy drm_send_vblank_event() with the new helper function. Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
- 14 Apr, 2016 6 commits
-
-
Ville Syrjälä authored
HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Deepak S <deepak.s@linux.intel.com> Fixes: 05a2fb15 ("drm/i915: Consolidate forcewake code") Signed-off-by:
-
Ville Syrjälä authored
As we did on VLV, split the gt irq handling to ack and handler phases on CHV. Leave the BDW+ codepath mostly intact for now. Signed-off-by:
-
Ville Syrjälä authored
It looks silly to pass both dev and dev_priv to the snb/ilk gt irq handlers. Just pass dev_priv. Signed-off-by:
-
Ville Syrjälä authored
No need to actually handle the GT/PM interrupt while we have interrupt sources disabled. Move the actual processing to happen after we've restored VLV_IER and master interrupt enable. Signed-off-by:
-
Ville Syrjälä authored
Minimize the amount of stuff we do with interrupt sources disabled by splitting the PIPESTAT irq handling into ack+handler phases. Signed-off-by:
-
Ville Syrjälä authored
Split the VLV/CHV hoplug irq handling to ack and handler phases. This way we can move the actual irq handling outside the section where we have disabled the interrupt sources. For now, we leave things as is for pre-VLV GMCH platforms, but eventually they could get the same treatment. Signed-off-by:
-
