- 02 Sep, 2015 30 commits
-
-
Ville Syrjälä authored
On GMCH plaforms we are now getting the following spew on aux interrupts: [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 Prevent it by not calling intel_get_hpd_pins() unless one of the HPD interrupt bits are actually set. I already fixed similar annoyance once with 4bca26d0 drm/i915: Use HOTPLUG_INT_STATUS_G4X on VLV/CHV but another source for it got added in fd63e2a9 drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins due to pch_get_hpd_pins() being chosen over i9xx_get_hpd_pins() to serve as the new unified piece of code. pch_get_hpd_pins() had the debug print, and i9xx_get_hpd_pins() didn't. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Rewrite the BXT hpd setup to match the way we do it on other platforms: - Throw out BXT_HOTPLUG_CTL since it's the same as PCH_PORT_HOTPLUG - Enable the HPD bits in the DE port IER in gen8_de_irq_postinstall() - Update DE port IMR using bdw_update_port_irq() Also throw out port D from bxt_port_hotplug_long_detect() since BXT only goes up to C. Signed-off-by:
-
Ville Syrjälä authored
A lot of the hpd irq handling is duplicated code, so refactor it a bit by observing that in several places the only difference is the hpd[] array. So pull the code to a few functions and pass in the hpd[] array from the caller. Another option would be to determine the correct array to use within the functions themselves, but somehow passing it in felt nicer. Further code reduction could be achieved by passing in the hotplug register offset, and the long pulse detection function pointer. But that didn't feel as good for some reason, so I left it at the middle ground. Signed-off-by:
-
Ville Syrjälä authored
bxt_hpd_handler() looks different to everyone else for no good reason. Rewrite it to use the standard variable namees etc. Signed-off-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
On SKL the port A HPD has moved to the PCH. Hook it up. Reviewed-by:
-
Ville Syrjälä authored
Wire up the port A HPD for BDW. Compared to earlier platforms the interrupt setup is a bit different, but basically everything else looks the same. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Check for BDW before processing the HPD to not break BXT Set found=true when processing port A HPD Sort out the mess I made of the irq setup in v1 Warn about bad irq mask vs. enable bits in bdw_update_port_irq() (Paulo) Signed-off-by: -
Ville Syrjälä authored
If the CPU and PCH are on the same package we must enabled the port A HPD also in the south hotplug register. To identify the package type we simply look at the PCH type: LPT-H means separate package, and LPT-LP means multi chip package (MCP). v2: Add comment and pimp commit message Reviewed-by:
-
Ville Syrjälä authored
As with ILK/SNB wire up the port A HPD on IVB/HSW. This might be more important on HSW with PSR. BSpec tells us that if the automagic link training performed by the hardware fails for some reason, we're going to get a short HPD and are supposed to re-train the link manyally. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Add a comment about the pulse duration bits being reserved on HSW+ like we have for LPT+ in ibx_hpd_irq_setup() Reviewed-by: -
Ville Syrjälä authored
ILK/SNB support port A HPD. While HPD is optional on eDP let's at least try to wite it up so that we might notice if the link has issues. The eDP spec suggests that if HPD is not wired up, one should poll the link status instead. We don't even do that currently. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Reviewed-by:
-
Ville Syrjälä authored
Starting from SPT the only interrupts living in the south are GMBUS and HPD. What's worse some of the SPT specific new bits conflict with some other bits on earlier PCH generations. So better not use the cpt_irq_handler() for SPT+ anymore. Also kill the hand rolled port E handling with something more standardish. This also avoids accidentally confusing port B and port E long pulses since the bits occupy the same positions, just in different registers. Also add a comment noting that the short pulse duration bits are reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the MBZ in the spec. v2: Call intel_hpd_irq_handler() only once (Paulo) Signed-off-by:
-
Ville Syrjälä authored
Move the 0 initialization of pin_mask and long_mask from intel_get_hpd_pins() into each caller. This we we can call intel_get_hpd_pins() multiple times to accumulate more pins from several sources. v2: Add a comment explaining the dangers of intel_get_hpd_pins() (Paulo) Reviewed-by:
-
Ville Syrjälä authored
The PORTA HPD defines are not BXT specific. They also exist on SPT, and partially already on LPT:LP. Reviewed-by:
-
Ville Syrjälä authored
Make LPT:LP checks look neater by wrapping the details in a new HAS_PCH_LPT_LP() macro. Reviewed-by:
-
Ville Syrjälä authored
Extract the core of ironlake_{enable,disable}_display_irq() into a new function. We'll have further use for it later. v2: Warn about invalid mask vs. enable bits (Paulo) Reviewed-by: -
Ville Syrjälä authored
Eliminate a bunch of duplicated code that calculates the currently enabled HPD interrupt bits. v2: s/;/:/ in patch subject (Paulo) Reviewed-by:
-
Ville Syrjälä authored
Indent the PORTx_HOTPLUG_... defines appropriately, and fix some space vs. tab issues. v2: Document pre-HSW/LPT bits, and order another tab (Paulo) Reviewed-by:
-
Daniel Vetter authored
Forgot to do that in commit d328c9d7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 10 16:22:37 2015 +0200 drm/i915: Select starting pipe bpp irrespective or the primary plane and it's confusing. Fix it. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Backmerge -fixes since there's more DDI-E related cleanups on top of the pile of -fixes for skl that just landed for 4.3. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i914/intel_dp.c drivers/gpu/drm/i915/intel_lrc.c Conflicts are all fairly harmless adjacent line stuff. Signed-off-by: -
Maarten Lankhorst authored
This makes the error message slightly more useful. Changes since v1: - Use ktime_get() while irqs are still disabled. (vsyrjala) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
There's already a per crtc member that can be used for it. Signed-off-by:
-
Zhiyuan Lv authored
When i915 drivers run inside a VM with Intel GVT-g, some explicit notifications are needed from guest to host device model through PV INFO page write. The notifications include: PPGTT create PPGTT destroy They are used for the shadow implementation of PPGTT. Intel GVT-g needs to write-protect the guest pages of PPGTT, and clear the write protection when they end their life cycle. v2: - Use lower_32_bits()/upper_32_bits() for qword operations; - Remove the notification of guest context creation/destroy; Signed-off-by:
Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Zhiyuan Lv authored
Some more definitions in the PV info page are added. They are mainly for the guest notification to Intel GVT-g device model. They are used for Broadwell enabling. The notification of PPGTT page table creation/destroy is to notify GVT-g device model the life cycle of guest page tables. Then device model will implement shadow page table for guests. The notification of context create/destroy is optional. If it is used, the device model will create/destroy shadow context corresponding to the context's life cycle. Guest driver needs to make sure that the context's LRCA and backing storage address unchanged. If it is not used, the device model will perform the context shadow work in the context scheduling time. Signed-off-by:
-
Zhiyuan Lv authored
Broadwell hardware supports both ring buffer mode and execlist mode. When i915 runs inside a VM with Intel GVT-g, we allow execlist mode only. The main reason of EXECLIST only is that GVT-g does not support the dynamic mode switch between ring buffer mode and execlist mode when running multiple virtual machines. v2: - Adjust the position of vgpu check in sanitize function (Joonas) - Add vgpu error check in context initialization. (Joonas, Daniel) Signed-off-by:
-
Zhiyuan Lv authored
This is based on Mika Kuoppala's patch below: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/61104/match=workaround+hw+preload The patch will preallocate the page directories for 32-bit PPGTT when i915 runs inside a virtual machine with Intel GVT-g. With this change, the root pointers in EXECLIST context will always keep the same. The change is needed for vGPU because Intel GVT-g will do page table shadowing, and needs to track all the page table changes from guest i915 driver. However, if guest PPGTT is modified through GPU commands like LRI, it is not possible to trap the operations in the right time, so it will be hard to make shadow PPGTT to work correctly. Shadow PPGTT could be much simpler with this change. Meanwhile hypervisor could simply prohibit any attempt of PPGTT modification through GPU command for security. The function gen8_preallocate_top_level_pdps() in the patch is from Mika, with only one change to set "used_pdpes" to avoid duplicated allocation later. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by:
-
Jani Nikula authored
Add a common function to return "yes" or "no" string based on the argument, and drop the local versions of it. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
Make it available outside of intel_dp.c. Signed-off-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
-
Alex Dai authored
If rc6 is enabled, notify GuC so it can do proper forcewake before command submission. Signed-off-by:
Alex Dai <yu.dai@intel.com> Reviewed-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by:
-
Alex Dai authored
The firmware layout changes that now it only has css header + uCode + RSA signature. Plus, other trivial changes to support GuC V4.3. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
-
Maarten Lankhorst authored
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:
-
- 01 Sep, 2015 10 commits
-
-
Ville Syrjälä authored
Make the code mode readable by pulling the "does this crtc have any encoders?" deduction into a separate function. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
The BIOS sometimes likes to enable pipes w/o any ports, at least on older machines. Currently we fail to assign anything sensible to crtc->hwmode.crtc_clock which leads to complaints from the vblank code. Deal with active pipes w/o ports and assign something sensible to crtc_clock in i9xx_get_pipe_config(). The encoder .get_config() will override this if the port is enabled. Gets rid of rest of these on my gen4: [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 24: Can't calculate constants, dotclock = 0! [drm:i915_get_vblank_timestamp] crtc 1 is disabled v2: Fill out crtc_clock already in i9xx_get_pipe_config() (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
At various points when changing the DPIO lane/phy power states, construct an expected value of the DISPLAY_PHY_STATUS register and compare it with the real thing. To construct the expected value we look at our shadow PHY_CONTROL register value (which should match what we've just written to the hardware), and we also need to look at the actual state of the cmn power wells as a disabled power well causes the relevant LDO status to be reported as 'on' in DISPLAY_PHY_STATUS. When initially powering up the PHY it performs various internal calibrations for which it fully powers up. That means that if we check for the expetected power state immediately upon releasing cmnreset we would get the occasional false positive. But we can of course poll until the expected value appears. It shouldn't be too long so this shouldn't make modesets substantially longer. One extra complication is introduced when we cross the streams, ie. drive port B with pipe B. In this case we trick CL2 (where the DPLL lives) into life by temporaily powering up the lanes in the second channel, and once the pipe is up and runnign we release the lane power override. At that point the power state of CL2 has somehow gotten entangled with the power state of the first channel. That means that constructing the expected DISPLAY_PHY_STATUS value is a bit tricky since based on the lane power states in the second channel, CL2 should also be powered down. But we can use the DPLL enable bit to determine when CL2 should be alive even if the lanes are powered down. However the power state of CL2 isn't actually tied in with the DPLL state, but to the state of the lanes in first channel, so we have to avoid checking the expected state between shutting down the DPLL and powering down the lanes in the first channel. So no calling assert_chv_phy_status() before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(), but after the write is a safe time to check. Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add some checks that the state of the DPIO lanes is more or less what we expect based on the overrides. The hardware only provides two bits per channel indicating whether all or some of the lanes are powered down, so we can't do an exact check. Additionally, CL2 powering down before we can check it adds another twist. To work around this we simply check for the 0 value of the CL2 register (which is what we get when it's powered down) and adjust our expectations. Signed-off-by:
-
Ville Syrjälä authored
Currently we release the lane soft reset before lane stagger settings have been programmed. I believe that means we don't actually do lane staggering. So move the soft reset deassert to happen after lane staggering has been programmed. The one confusing thing in this is that when we remove the power down override from the lanes, they power up with defaul register values, which do not have the soft reset overrides enabled. And according to some docs by default the data lane resets are tied to cmnreset. So that would mean that lanes would come out of reset without staggering as soon as the power down overrides are removed. But since we can't access either the lane stagger register nor the soft reset override registers until the lanes are powered on, we can't really do anything about it. So let's just set the soft reset overrides as soon as the lane is powered on and hope for the best. v2: Fix typos in commit message (Daniel) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The DP MST encoder config function never sets ddi_pll_sel, even though its value is programmed in its ->pre_enable() hook. That used to work because a new pipe_config was kzalloc'ed at every modeset, and the value of zero selects the highest clock for the PLL. Starting with the commit below, the value of ddi_pll_sel is preserved through modesets, and since the correct value wasn't properly setup by the MST code, it could lead to warnings and blank screens. commit 8504c74c Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Fri May 15 11:51:50 2015 +0300 drm/i915: Preserve ddi_pll_sel when allocating new pipe_config Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628 Cc: stable@vger.kernel.org # 7e6313a2 drm/i915: Don't use link_bw for PLL setup Cc: stable@vger.kernel.org Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
-
Francisco Jerez authored
This was forgotten in commit d351f6d9 Author: Francisco Jerez <currojerez@riseup.net> Date: Fri May 29 16:44:15 2015 +0300 drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist. Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Ville Syrjälä authored
Use port_clock instead of link_bw when picking the PLL parameters for DP. link_bw may be zero with an eDP 1.4 sink that supports DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it to the sink appropriately. v2: Fix typo in commit message (Sivakumar) Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Jani Nikula authored
Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
