Pull locking and atomic updates from Ingo Molnar:
"Main changes in this cycle are:
- Extend atomic primitives with coherent logic op primitives
(atomic_{or,and,xor}()) and deprecate the old partial APIs
(atomic_{set,clear}_mask())
The old ops were incoherent with incompatible signatures across
architectures and with incomplete support. Now every architecture
supports the primitives consistently (by Peter Zijlstra)
- Generic support for 'relaxed atomics':
- _acquire/release/relaxed() flavours of xchg(), cmpxchg() and {add,sub}_return()
- atomic_read_acquire()
- atomic_set_release()
This came out of porting qwrlock code to arm64 (by Will Deacon)
- Clean up the fragile static_key APIs that were causing repeat bugs,
by introducing a new one:
DEFINE_STATIC_KEY_TRUE(name);
DEFINE_STATIC_KEY_FALSE(name);
which define a key of different types with an initial true/false
value.
Then allow:
static_branch_likely()
static_branch_unlikely()
to take a key of either type and emit the right instruction for the
case. To be able to know the 'type' of the static key we encode it
in the jump entry (by Peter Zijlstra)
- Static key self-tests (by Jason Baron)
- qrwlock optimizations (by Waiman Long)
- small futex enhancements (by Davidlohr Bueso)
- ... and misc other changes"
* 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (63 commits)
jump_label/x86: Work around asm build bug on older/backported GCCs
locking, ARM, atomics: Define our SMP atomics in terms of _relaxed() operations
locking, include/llist: Use linux/atomic.h instead of asm/cmpxchg.h
locking/qrwlock: Make use of _{acquire|release|relaxed}() atomics
locking/qrwlock: Implement queue_write_unlock() using smp_store_release()
locking/lockref: Remove homebrew cmpxchg64_relaxed() macro definition
locking, asm-generic: Add _{relaxed|acquire|release}() variants for 'atomic_long_t'
locking, asm-generic: Rework atomic-long.h to avoid bulk code duplication
locking/atomics: Add _{acquire|release|relaxed}() variants of some atomic operations
locking, compiler.h: Cast away attributes in the WRITE_ONCE() magic
locking/static_keys: Make verify_keys() static
jump label, locking/static_keys: Update docs
locking/static_keys: Provide a selftest
jump_label: Provide a self-test
s390/uaccess, locking/static_keys: employ static_branch_likely()
x86, tsc, locking/static_keys: Employ static_branch_likely()
locking/static_keys: Add selftest
locking/static_keys: Add a new static_key interface
locking/static_keys: Rework update logic
locking/static_keys: Add static_key_{en,dis}able() helpers
...
This will make sure that audio callbacks do not race with
component bind/unbind.
[Note: this is an update patch to commit [51e1d83cab99: drm/i915: Call
audio pin/ELD notify function] where I mistakenly applied the older
version. Jani and Daniel's review tags were to the latest version,
so I add them below, too -- tiwai]
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The port_mst_index parameter was reserved for future use, but
maintainers prefer to add it later when it is actually used.
[Note: this is an update patch to commit [51e1d83cab99: drm/i915: Call
audio pin/ELD notify function] where I mistakenly applied the older
version. Jani and Daniel's review tags were to the latest version,
so I add them below, too -- tiwai]
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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
4bca26d0a6 drm/i915: Use HOTPLUG_INT_STATUS_G4X on VLV/CHV
but another source for it got added in
fd63e2a972 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>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On SKL the port A HPD has moved to the PCH. Hook it up.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The PORTA HPD defines are not BXT specific. They also exist on SPT,
and partially already on LPT:LP.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make LPT:LP checks look neater by wrapping the details in a
new HAS_PCH_LPT_LP() macro.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Eliminate a bunch of duplicated code that calculates the currently
enabled HPD interrupt bits.
v2: s/;/:/ in patch subject (Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Forgot to do that in
commit d328c9d78d
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>
Pass the correct hpd[] array to intel_get_hpd_pins() on pre-g4x
platforms.
This got broken in the following commit:
commit fd63e2a972
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Jul 21 15:32:44 2015 -0700
drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
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>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Egbert Eich <eich@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
There have been many hard to track down bugs whereby userspace forgot to
flag a write buffer and then cause graphics corruption or a hung GPU
when that buffer was later purged under memory pressure (as the buffer
appeared clean, its pages would have been evicted rather than preserved
and any changes more recent than in the backing storage would be lost).
In retrospect this is a rare optimisation against memory pressure,
already the slow path. If we always mark the buffer as dirty when
accessed by the GPU, anything not used can still be evicted cheaply
(ideal behaviour for mark-and-sweep eviction) but we do not run the risk
of corruption. For correct read serialisation, userspace still has to
notify when the GPU writes to an object. However, there are certain
situations under which userspace may wish to tell white lies to the
kernel...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "Goel, Akash" <akash.goel@intel.co>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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: Daniel Vetter <daniel.vetter@intel.com>
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's already a per crtc member that can be used for it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <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: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <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: Daniel Vetter <daniel.vetter@ffwll.ch>
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: 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: Daniel Vetter <daniel.vetter@ffwll.ch>
When the audio codec is enabled or disabled, notify the audio driver.
This will enable the audio driver to get the notification at all times
(even when audio is in different powersave states).
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Daniel Vetter <daniel.vetter@ffwll.ch>
Make it available outside of intel_dp.c.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 8504c74c7a
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 # 7e6313a251 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This was forgotten in
commit d351f6d948
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: Daniel Vetter <daniel.vetter@ffwll.ch>
No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/intel_dp_tps/drm_dp_tps/.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from future.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Commit 92122789b2 ("drm/i915: preserve SSC if previously set v3")
added code to intel_modeset_gem_init to override the SSC status read
from VBT with the SSC status set by BIOS.
However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
which calls intel_setup_outputs, which *modifies* SSC status by way of
intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
doesn't preserve the SSC status set by BIOS but whatever
intel_init_pch_refclk decided on.
This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, an LVDS
connector may initially seem disconnected and the SSC therefore
is disabled by intel_init_pch_refclk, but on reprobe the connector
may turn out to be connected and the SSC must then be enabled.
Due to 92122789b2 however, the SSC is not enabled on reprobe since
it is assumed BIOS disabled it while in fact it was disabled by
intel_init_pch_refclk.
Also, because the SSC status is preserved so late, the preserved value
only ever gets used on resume but not on panel initialization:
intel_modeset_init calls intel_init_display which indirectly calls
intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
is the sole user of dev_priv->vbt.lvds_use_ssc).
Fix this by moving the code introduced by 92122789b2 from
intel_modeset_gem_init to intel_modeset_init before the invocation
of intel_setup_outputs and intel_init_display.
Add a DRM_DEBUG_KMS as suggested way back by Jani:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko <pvt.gord@gmail.com>
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown <william@blackhats.net.au>
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner <lukas@wunner.de>
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net>
[MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress]
Fixes: 92122789b2 ("drm/i915: preserve SSC if previously set v3")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
From B spec, DDI_E port belong to PowerWell 2, but
DDI_E share the powerwell_req/staus register bit with
DDI_A which belong to DDI_A_E_POWER_WELL.
In order to communicate with the connector on DDI-E, both
DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.
Currently intel_dp_power_get(DDI_E) only enable
DDI_A_E_POWER_WELL, this patch will not only enable
DDI_a_E_POWER_WELL but also enable POWER_WELL_2.
This patch also fix the DDI-E hotplug function.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Enable eDP on DDI-E.
Also let's remove duplicated definitions to avoid later confusion.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
There are OEMs using DDI-E out there,
so let's enable it.
Unfortunately there is no detection bit for DDI-E
So we need to rely on VBT for that.
I also need to give credits to Xiong since before seing
his approach to check info->support_* I was creating an ugly
vbt->ddie_sfuse_strap in order to propagate the ddi presence info
v2: Rebased as last patch in the series. since all other patches
in this series are needed for anything working propperly on DDI-E.
Credits-to: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Cc: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
DDI-E doesn't have the correspondent GMBUS pin.
We rely on VBT to tell us which one it being used instead.
The DVI/HDMI on shared port couldn't exist.
This patch isn't tested without hardware wchich has HDMI
on DDI-E.
v2: fix trailing whitespace
v3: MISSING_CASE take place of BUG()
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
commit da2bc1b9db
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Oct 23 19:23:26 2014 +0300
drm/i915: add poweroff_late handler
introduced a regression on old platforms during hibernation. A workaround was
added in
commit ab3be73fa7
Author: Imre Deak <imre.deak@intel.com>
Date: Mon Mar 2 13:04:41 2015 +0200
drm/i915: gen4: work around hang during hibernation
using an explicit blacklist for the GENs/BIOS vendors where the issue was
reported. Later there we had reports of the same failure on platforms not on
this list.
To my best knowledge the correct thing to do is still to put the device to PCI
D3 state during hibernation, see [1] and [2] for the reasons. This also aligns
with our future plans to unify more the runtime and system suspend/resume
paths. Since an exact blacklist seems to be impractical (multiple GENs and
BIOS vendors are affected) apply the workaround on everything pre GEN6.
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html
[2] https://lkml.org/lkml/2015/6/22/274
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061
Reported-by: Ilya Tumaykin <itumaykin@gmail.com>
Reported-by: Dirk Griesbach <spamthis@freenet.de>
Reported-by: Pavel Machek <pavel@ucw.cz>
Reported-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Tested-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Reported-by: Paul Bolle <pebolle@tiscali.nl>
CC: stable@vger.kernel.org
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.
If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meaning the user is
left staring at a blank screen. With the retraining put back that should
be fixed.
Also remove the leftover comment that referred to the old retraining
from .hot_plug().
Fixes a regression introduced in:
commit 0e32b39cee
Author: Dave Airlie <airlied@redhat.com>
Date: Fri May 2 14:02:48 2014 +1000
drm/i915: add DP 1.2 MST support (v0.7)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453
Tested-by: Palmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
Cc: Dave Airlie <airlied@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91697
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Wei Shun Chang <wei.shun.chang@intel.com>
Tested-by: Gary Wang <gary.c.wang@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Xiong Y Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Gary Wang <gary.c.wang@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This partially reverts commit 74c090b1bd.
The DRIVER_ATOMIC cap cannot yet be exported because i915 lacks async
support.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dear git bisect user,
Even though this is the patch that introduced the WARN() you're
bisecting, please notice that it's very likely that the problem you're
facing was already present before this commit. In other words: this
commit adds code to detect errors and give WARN()s about them, but the
errors were already there.
In order to continue your debug, please use the i915.mmio_debug
option, check the backtraces and try to discover which read or write
operation is causing the error message. Then check if this is
happening because the register does not exist or because its power
well is down when the operation is being done.
On my SKL machine, if I use i915.mmio_debug=999, this patch triggers
42 WARNs just by booting. I didn't investigate them yet. Normal users
are only going to get a single WARN due to the default i915.mmio_debug
setting.
Thank you for your comprehension,
Paulo
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can choose to leave the display PHY CL2 powerdown up to some hardware
signals, or we can force it. The BXT code forces the nonexistent CL2 in
the x1 PHY to power down. Follow suit on CHV. Maybe it can still save
some extra power by disabling some extra logic in CL1, or something.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV has supports some form of automagic clock gating for the
DPIO SUS clock. We can simply enable the magic bits and the
hardware should take care of the rest.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With DPIO powergating active the DPLL can't be accessed unless
something else is keeping the common lane in the channel on.
That means the PPS kick procedure could fail to enable the PLL.
Power up some data lanes to force the common lane to power up
so that the PLL can be enabled temporarily.
v2: Avoid gcc uninitilized variable warning
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Normmally the common lane in a PHY channel gets powered up when some
of the data lanes get powered up. But when we're driving port B with
pipe B we don't want to enabled any of the data lanes, and just want
the DPLL in the common lane to be active.
To make that happens we have to temporarily enable some data lanes
after which we can access the DPLL registers in the common lane. Once
the pipe is up and running we can drop the power override on the data
lanes allowing them to shut down. From this point forward the common
lane will in fact stay powered on until the data lanes in the other
channel get powered down.
Ville's extended explanation from the review thread:
On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote:
> One Q, why only for port B? Port C is also in same common lane right?
Port B is in the first PHY channel which also houses CL1. CL1 always
powers up whenever any lanes in either PHY channel are powered up.
CL2 only powers up if lanes in the second channel (ie. the one with
port C) powers up.
So in this scenario (pipe B->port B) we want the DPLL from CL2, but
ideally we only want to power up the lanes for port B. Powering up
port B lanes will only power up CL1, but as we need CL2 instead we
need to, temporarily, power up some lanes in port C as well.
Crossing the streams the other way (pipe A->port C) is not a problem
since CL1 powers up whenever anything else powers up. So powering up
some port C lanes is enough on its own to make the CL1 DPLL
operational, even though CL1 and the lanes live in separate channels.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
[danvet: Amend commit message with extended explanation.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Powergate the PHY lanes when they're not needed. For HDMI all four lanes
are needed always, but for DP we can enable only the needed lanes. To
power down the unused lanes we use some power down override bits in the
DISPLAY_PHY_CONTROL register. Without the overrides it appears that the
hardware always powers on all the lanes. When the port is disabled the
power down override is not needed and the lanes will shut off on their
own. That also means the override is critical to actually be able to
access the DPIO registers before the port is actually enabled.
Additionally the common lanes will power down when not needed. CL1
remains on as long as anything else is on, CL2 will shut down when
all the lanes in the same channel will shut down. There is one exception
for CL2 that will be dealt in a separate patch for clarity.
With potentially some lanes powered down, the DP code now has to check
the number of active lanes before accessing PCS/TX registers. All
registers in powered down blocks will reads as 0xffffffff, and soe we
would drown in warnings from vlv_dpio_read() if we allowed the code
to access all those registers.
Another important detail in the DP code is the "TX latency optimal"
setting. Normally the second TX lane acts as some kind of reset master,
with the other lanes as slaves. But when only a single lane is enabled,
that single lane obviously has to be the master.
A bit of extra care is needed to reconstruct the initial state of the
DISPLAY_PHY_CONTROL register since it can't be read safely. So instead
read the actual lane status from the DPLL/PHY_STATUS registers and
use that to determine which lanes ought to be powergated initially.
We also need to switch the PHY power modes to "deep PSR" to avoid
a hard system hang when powering down the single channel PHY.
Also sprinkle a few debug prints around so that we can monitor the
DISPLAY_PHY_STATUS changes without having to read it and risk
corrupting it.
v2: Add locking to chv_powergate_phy_lanes()
v3: Actually enable dynamic powerdown in the PHY and deal with the
fallout
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bunch of stuff needs the DPLL ref/cri clocks on both VLV and CHV,
and having VGA mode enabled causes some problems for CHV. So let's just
pull the code to configure those bits into the disp2d well enable hook.
With the DPLL disable code also fixed to leave those bits alone we
should now have a consistent DPLL state all the time even if the DPLL
is disabled.
This also neatly removes some duplicated code between the VLV and
CHV codepaths.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Most of our char* arrays are markes as const already, but a few slipped
through the cracks. Fix it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A couple of hand rolled ARRAY_SIZE()s caught my eye. Get rid of them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simple one:
drivers/gpu/drm/i915/i915_debugfs.c:2449:57: warning: Using plain integer as NULL pointer
And something a bit more peculiar:
drivers/gpu/drm/i915/i915_debugfs.c:4953:18: warning: Variable length array is used.
drivers/gpu/drm/i915/i915_debugfs.c:4953:32: warning: Variable length array is used.
We pass a 'const int' as the array size which results in the warning,
dropping the const gets rid of the warning. Weird, but I think getting
rid of the warnings is better than holding on to the const.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BXT platform uses live status bits from 0x44440 register to obtain DP
status on hotplug. The existing g4x_digital_port_connected() uses a
different register and hence misses DP hotplug events on BXT
platform. This patch fixes it by using the appropriate register(0x44440)
and live status bits(3:5).
Based on a patch by Durgadoss R <durgadoss.r@intel.com>, from whom the
commit message is shamelessly copy pasted.
Reported-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Choose the right function at the intel_digital_port_connected level.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Choose the right function at the intel_digital_port_connected level.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.
v2: make the function return a boolean
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the case added for eDP on port A (always connected from this
function's point of view), we should not be hitting any of the default
cases in ibx_digital_port_connected, so add MISSING_CASE annotation.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We should not be hitting any of the default cases in
g4x_digital_port_connected, so add MISSING_CASE annotation and return
boolean status. The current behaviour is just cargo culting from the
days of yonder when the display port support was added to i915.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The function can be made static there. No functional changes.
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DVO.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- clock check against max dotclock moved inside 'if (fixed_mode)'
V5:
- dot clock check against fixed_mode clock when available
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DSI.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
- moved dot clock checking inside 'if (fixed_mode)'
V5:
- dot clock checked against fixed_mode clock
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to LVDS.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- moved supported dotclock check from mode_valid() to intel_lvds_init()
V5:
- dotclock check moved back to mode_valid() function
- dotclock check for fixed mode
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Store max dotclock into dev_priv structure so we are able
to filter out the modes that are not supported by our
platforms.
V2:
- limit the max dot clock frequency to max CD clock frequency
for the gen9 and above
- limit the max dot clock frequency to 90% of the max CD clock
frequency for the older gens
- for Cherryview the max dot clock frequency is limited to 95%
of the max CD clock frequency
- for gen2 and gen3 the max dot clock limit is set to 90% of the
2X max CD clock frequency
V3:
- max_dotclk variable renamed as max_dotclk_freq in i915_drv.h
- in intel_compute_max_dotclk() the rounding method changed from
round up to round down when computing max dotclock
V4:
- Haswell and Broadwell supports now dot clocks up to max CD clock
frequency
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add vlv_dport_to_phy() and fix up the return values of
vlv_dport_to_channel() and vlv_pipe_to_channel() to use
the appropriate enums.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With DPIO powergating active on CHV, we can't even access the DPIO PLL
registers until the lane power state overrides have been enabled. That
will happen from the encoder .pre_pll_enable() hook, so move
chv_prepare_pll() to happen after that point, which puts it just before
chv_enable_pll() actually.
Do the same for VLV to avoid accumulating weird differences between the
platforms. Both platforms seem happy with the new arrangement.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
dev_priv->chv_phy_control is protected by the power_domains->lock
elsewhere, so also grab it when initializing chv_phy_control.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To implement DPIO lane power gating on CHV we're going to need to access
DPIO registers from the cmn power well enable hook. That gets called
rather early, so we need to move the DPIO port IOSF sideband port
assignment earlier as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the CHV clock buffer disable from chv_disable_pll() to the new
encoder .post_pll_disable() hook. This is more symmetric since the
clock buffer enable happens from the .pre_pll_enable() hook.
We'll have more use for the new hook soon.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The docs give you the impression that the unique transition scale
value shouldn't matter when unique transition scale is enabled. But
as Imre found on BXT (and I verfied also on BSW) the value does
matter. So from now on just program the same value 0x9a always.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When fractional m2 divider isn't used on CHV the fractional part
is ignore by the hardware. Despite that, program the fractional
value (0 in this case) to the hardware register just to keep
things a bit more consistent. Might at least make register dumps
a bit less confusing when there isn't some stale fractional part
hanging around.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current versions of these two macros don't work correctly if the
argument expression happens to contain a modulo operator (%) -- when
stringified, it gets interpreted as a printf formatting character!
With a specifically crafted parameter, this could probably cause a
kernel OOPS; consider WARN_ON(p%s) or WARN_ON(f %*pEp).
Instead, we should use an explicit "%s" format, with the stringified
expression as the coresponding literal-string argument.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With MST there won't be a crtc assigned to the main link encoder, so
trying to dig up the pipe_config from there is a recipe for an oops.
Instead store the parameters (lane_count and link_rate) in the encoder,
and use those values during link training etc. Since those parameters
are now assigned only when the link is actually enabled,
.compute_config() won't clobber them as it did before.
Hardware state readout is still bonkers though as we don't transfer the
link parameters from pipe_config intel_dp. We should do that during
encoder sanitation. But since we don't even do a proper job of reading
out the main link encoder state for MST there's littel point in
worrying about this now.
Fixes a regression with MST caused by:
commit 90a6b7b052
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Jul 6 16:39:15 2015 +0300
drm/i915: Move intel_dp->lane_count into pipe_config
v2: Different apporoach that should keep intel_dp_check_mst_status()
somewhat less oopsy
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Due to a coherency issue on BXT A steppings we can't guarantee a
coherent view of cached (CPU snooped) GPU mappings, so fail such
requests. User space is supposed to fall back to uncached mappings in
this case.
v2:
- limit the WA to A steppings, on later stepping this HW issue is fixed
v3:
- return error instead of trying to work around the issue in kernel,
since that could confuse user space (Chris)
Testcast: igt/gem_store_dword_batches_loop/cached-mapping
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By running igt/store_dword_loop_render on BXT we can hit a coherency
problem where the seqno written at GPU command completion time is not
seen by the CPU. This results in __i915_wait_request seeing the stale
seqno and not completing the request (not considering the lost
interrupt/GPU reset mechanism). I also verified that this isn't a case
of a lost interrupt, or that the command didn't complete somehow: when
the coherency issue occured I read the seqno via an uncached GTT mapping
too. While the cached version of the seqno still showed the stale value
the one read via the uncached mapping was the correct one.
Work around this issue by clflushing the corresponding CPU cacheline
following any store of the seqno and preceding any reading of it. When
reading it do this only when the caller expects a coherent view.
v2:
- fix using the proper logical && instead of a bitwise & (Jani, Mika)
- limit the workaround to A stepping, on later steppings this HW issue
is fixed
v3:
- use a separate get_seqno/set_seqno vfunc (Chris)
Testcase: igt/store_dword_loop_render
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: fix one error found by checkpath.pl
v3: Add one ignored break for switch-case. DDI-E hotplug
function doesn't work after updating drm-intel tree,
I checked the code and found this missing which isn't
the root cause for broke DDI-E hp. The broken
DDI-E hp function is fixed by "Adding DDI_E power
well domain".
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The gtt.stolen_size field is of type size_t, and so should be printed
using %zu to avoid build warnings on either 32-bit and 64-bit builds.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
SKL-Y can now use the same programming for all VccIO values after an
adjustment to I_boost. SKL-U DP table adjustments.
1. Remove SKL Y 0.95V from "SKL H and S" columns in all tables. The
other SKL Y column removes the "0.85V VccIO" so it now applies to all
voltages.
2. DP table changes SKL U 400mV+0db dword 0 value from 2016h to 201Bh.
3. DP table changes SKL U 600mv+0db dword 0 value from 2016h to 201Bh.
4. DP table increases I_boost to level 3 for SKL Y 400mv+9.5db.
v2: Fix compilation warnings as pointed by Paulo.
Reference: Graphics Spec Change r97962
Cc: Arthur Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[Jani: reformatted commit message for shorter lines.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We also need to call the frontbuffer flip to trigger proper
invalidations when disabling planes. Otherwise we will miss
screen updates when disabling sprites or cursor.
On core platforms where HW tracking also works, this issue
is totally masked because HW tracking triggers PSR exit
however on VLV/CHV that has only SW tracking we miss screen
updates when disabling planes.
It was caught with kms_psr_sink_crc sprite_plane_onoff
and cursor_plane_onoff subtests running on VLV/CHV.
This is probably a regression since I can also get this
with the manual test case, but with so many changes on atomic
modeset I couldn't track exactly when this was introduced.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM instructions are not really
variable length instructions unlike MI_LOAD_REGISTER_IMM where it expects
(reg, addr) pairs so use fixed length for these instructions.
v2: rebase
Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Appease checkpatch as Mika spotted in i915_reg.h - it seems
terminally unhappy about i915_cmd_parser.c so that would be a separate
patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VBT version 196 increased the size of common_child_dev_config. The
parser code assumed that the size of this structure would not change.
The modified code now copies the amount needed based on the VBT version,
and emits a debug message if the VBT version is unknown (too new); since
the struct config block won't shrink in newer versions it should be
harmless to copy the maximum known size in such cases, so that's what we
do, but emitting the warning is probably sensible anyway.
In the longer run it might make sense to modify the parser code to use a
version/feature mapping, rather than hardcoding things like this, but
for now the variants are fairly manageable.
This fixes a regression introduced in
commit 75067ddecf
Author: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Date: Fri Jul 10 14:10:55 2015 +0300
drm/i915: Per-DDI I_boost override
since that commit changed the child device config size without updating
the checks and memcpy.
v2: Stricter size checks
v3 by Jani:
- Keep the checks strict, and warnigns verbose, but keep going anyway.
- Take care to copy the max amount of child device config we can.
- Fix the messages.
Signed-off-by: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This patch fixes the bug that SKL SKUs before B0 might return
HBR2 as supported even though it is not supposed to be enabled
on such platforms.
v2: optimize if else condition (Jani)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
[Jani: minor whitespace fix.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
commit 75067ddecf
Author: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Date: Fri Jul 10 14:10:55 2015 +0300
drm/i915: Per-DDI I_boost override
increased size of union child_device_config without taking into account
the size check in parse_sdvo_device_mapping(). Switch the function over
to using the legacy struct only.
Fixes: 75067ddecf ("drm/i915: Per-DDI I_boost override")
Cc: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJV2pUkAAoJEHm+PkMAQRiGCIoH/Rb29ZjdCoZJp9OtnjAG+qRc
bG3YuomIdib86x7xHRKKaLWBa7din7IYjuwT/X4S4duO5a1R5Lp1sRG3IlGfhT0W
nBNbjFl4q4bOyiTPtTRTYyh4g5UQv4IuyCnCmZyCTJyVi/O6HVM9TWKUzm68P2dJ
30LwLUcQJ+mHueGJwFBAXe2BaojEpvYCdSX6tvbrQ/8X3FrVExZXuJl4uMYNFYNK
ZwG/v5t7tYOiAe76JGbrEuVFPZWLPEW7amHOWR0T4Ye4nWTlBgx7fENiNRlfgcvI
CM16l/xkyrZQ3Q5jZy1qYDfdHYF++dyEDysX4w1ae/X0aaLZn7l+u5VQD6WpkQQ=
=IF6I
-----END PGP SIGNATURE-----
Merge tag 'v4.2-rc8' into drm-next
Linux 4.2-rc8
Backmerge required for Intel so they can fix their -next tree up properly.
This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.
v2: rename the function to indicate it checks source rates (Jani)
v3: update comment to indicate TP3 dependency on HBR2 supported
hardware (Jani)
Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
[Jani: fixed a couple of checkpatch warnings.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This patch removes 5.4Gbps from supported link rate for CHV since
it is not supported in it.
v2: change the ordering for better readability (Ville)
Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts
commit fe51bfb95c.
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Mar 12 17:10:38 2015 +0200
CHV does not support intermediate frequencies so reverting the
patch that added it in the first place
Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts
commit 047fe6e6db
Author: David Weinehall <david.weinehall@linux.intel.com>
Date: Tue Aug 4 16:55:52 2015 +0300
drm/i915: Allow parsing of variable size child device entries from VBT
That commit is not valid for v4.2, however it will be valid for v4.3. It
was simply queued too early.
The referenced regressing commit is just fine until the size of struct
common_child_dev_config changes, and that won't happen until
v4.3. Indeed, the expected size checks here rely on the increased size
of the struct, breaking new platforms.
Fixes: 047fe6e6db ("drm/i915: Allow parsing of variable size child device entries from VBT")
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Everytime we use the logical context with execlists it becomes dirty (as
the hardware will write the new register values afterwards, as well as
the GPU state that will be used). We need to then flag the context as
dirty everytime since after a swap-out/swap-in cycle the dirty flag will
be cleared, and a further swap-out cycle will then loose the most recent
GPU state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Bunch more fixes for 4.3, most of it skl fallout. It's not quite all yet,
there's still a few more patches pending to enable DDI-E correctly on skl.
Also included the dpms atomic work from Maarten since atomic is just a
pain and not including would cause piles of conflicts right from the
start.
* tag 'drm-intel-next-fixes-2015-08-16' of git://anongit.freedesktop.org/drm-intel: (67 commits)
drm/i915: Per-DDI I_boost override
drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A
drm/i915: fix checksum write for automated test reply
drm/i915: Contain the WA_REG macro
drm/i915: Remove the failed context from the fpriv->context_idr
drm/i915: Report IOMMU enabled status for GPU hangs
drm/i915: Check idle to active before processing CSQ
drm/i915: Set alternate aux for DDI-E
drm/i915: Set power domain for DDI-E
drm/i915: fix stolen bios_reserved checks
drm/i915: Use masked write for Context Status Buffer Pointer
drm/i915/skl WaDisableSbeCacheDispatchPortSharing
drm/i915: Spam less on dp aux send/receive problems
drm/i915: Handle return value in intel_pin_and_fence_fb_obj, v2.
drm/i915: Only update mode related state if a modeset happened.
drm/i915: Remove connectors_active.
drm/i915: Remove connectors_active from intel_dp.c, v2.
drm/i915: Remove connectors_active from sanitization, v2.
drm/i915: Get rid of dpms handling.
drm/i915: Make crtc checking use the atomic state, v2.
...
There's so much scaler debugging messages that it makes other debugging
hard. Remove them.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
v5:
Added GuC per-engine submission & seqno statistics
v6:
Add per-ring statistics to client, refactor client-dumper.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a few other changes also required, notably:
1. Contexts must be pinned at GGTT addresses accessible by the GuC
i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
2. The GuC's TLB must be invalidated after a context is pinned at
a new GGTT address.
3. GuC firmware uses the one page before Ring Context as shared data.
Therefore, whenever driver wants to get base address of LRC, we
will offset one page for it. LRC_PPHWSP_PN is defined as the page
number of LRCA.
4. In the work queue used to pass requests to the GuC, the GuC
firmware requires the ring-tail-offset to be represented as an
11-bit value, expressed in QWords. Therefore, the ringbuffer
size must be reduced to the representable range (4 pages).
v2:
Defer adding #defines until needed [Chris Wilson]
Rationalise type declarations [Chris Wilson]
v4:
Squashed kerneldoc patch into here [Daniel Vetter]
v5:
Update request->tail in code common to both GuC and execlist modes.
Add a private version of lr_context_update(), as sharing the
execlist version leads to race conditions when the CPU and
the GuC both update TAIL in the context image.
Conversion of error-captured HWS page to string must account
for offset from start of object to actual HWS (LRC_PPHWSP_PN).
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Turn on interrupt steering to route necessary interrupts to GuC.
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A GuC client has its own doorbell and workqueue. It maintains the
doorbell cache line, process description object and work queue item.
A default guc_client is created for the i915 driver to use for
normal-priority in-order submission.
Note that the created client is not yet ready for use; doorbell
allocation will fail as we haven't yet linked the GuC's context
descriptor to the default contexts for each ring (see later patch).
v2:
Defer adding structure members until needed [Chris Wilson]
Rationalise type declarations [Chris Wilson]
v5:
Add GuC per-engine submission & seqno statistics.
Move wq locking to encompass both get_space() and add_item().
Take forcewake lock in host2guc_action() [Tom O'Rourke]
v6:
Fix GuC doorbell cacheline selection code (the
cacheline-within-page calculation was wrong).
Rename GuC priorities to make them closer to the names used in
the GuC firmware source, matching what the autogenerated
versions will (probably) be.
Add per-ring statistics to client.
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allocate a GEM object to hold GuC log data. A debugfs interface
(i915_guc_log_dump) is provided to print out the log content.
v2:
Add struct members at point of use [Chris Wilson]
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This adds the first of the data structures used to communicate with the
GuC (the pool of guc_context structures).
We create a GuC-specific wrapper round the GEM object allocator as all
GEM objects shared with the GuC must be pinned into GGTT space at an
address that is NOT in the range [0..WOPCM_TOP), as that range of GGTT
addresses is not accessible to the GuC (from the GuC's point of view,
it's permanently reserved for other objects such as the BootROM & SRAM).
Later, we will need to allocate additional GuC-sharable objects for the
submission client(s) and the GuC's debug log.
v2:
Remove redundant initialisation [Chris Wilson]
Defer adding struct members until needed [Chris Wilson]
Local functions should pass dev_priv rather than dev [Chris Wilson]
v5:
Invalidate GuC TLB after allocating and pinning a new object
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to describe a context for submission via
the GuC, we need one of the same functions used in execlist mode.
This commit exposes one such function, changing its name to better
describe what it does (it's related to logical ring contexts rather
than to execlists per se).
v2:
Replaces previous "drm/i915: Move execlists defines from .c to .h"
v3:
Incorporates a change to one of the functions exposed here that was
previously part of an internal patch, but which was omitted from
the version recently committed to drm-intel-nightly:
7a01a0a drm/i915/lrc: Update PDPx registers with lri commands
So we reinstate this change here.
v4:
Drop v3 change, update function parameters due to collision with
8ee3615 drm/i915: Convert execlists_ctx_descriptor() for requests
v5:
Don't expose execlists_update_context() after all. The current
version is no longer compatible with GuC submission; trying to
share the execlist version of this function results in both GuC
and CPU updating TAIL in the context image, with bad results when
they get out of step. The GuC submission path now has its own
private version that just updates the ringbuffer start address,
and not TAIL or PDPx.
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The new node provides access to the status of the GuC-specific loader;
also the scratch registers used for communication between the i915
driver and the GuC firmware.
v2:
Changes to output formats per Chris Wilson's suggestions
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fetches the required firmware image from the filesystem,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky.
v2:
Various improvements per review comments by Chris Wilson
v3:
Removed 'wait' parameter to intel_guc_ucode_load() as firmware
prefetch is no longer supported in the common firmware loader,
per Daniel Vetter's request.
Firmware checker callback fn now returns errno rather than bool.
v4:
Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
Don't keep the driver working (by falling back to execlist mode)
if GuC firmware loading fails [Daniel Vetter]
v5:
Clarify WOPCM-related #defines [Tom O'Rourke]
Delete obsolete code no longer required with current h/w & f/w
[Tom O'Rourke]
Move the call to intel_guc_ucode_init() later, so that it can
allocate GEM objects, and have it fetch the firmware; then
intel_guc_ucode_load() doesn't need to fetch it later.
[Daniel Vetter].
v6:
Update comment describing intel_guc_ucode_load() [Tom O'Rourke]
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only need the link_bw/rate_select parameters when starting link
training, and they should be computed based on the currently active
config, so throw them out from intel_dp and just compute on demand.
Toss in an extra debug print to see rate_select in addition to link_bw,
as the latter may be 0 for eDP 1.4.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_dp->link_bw is going away, so consul the port_clock instead when
choosing between TP1 and TP3.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we clobber intel_dp->lane_count in compute config, which means
after a rejected modeset we may no longer be able to retrain the current
link. Move lane_count into pipe_config to avoid that.
v2: Add missing ':' to the pipe config debug dump
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use a separate variable for the TRANS_DP_CTL value instead of reusing
'tmp' that otherwise contains the DP port register value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All the *_ddi_pll_select() functions get passed the port_clock and pipe
config as parameters. We only need to pass the pipe config, and the
functions can dig up the port_clock themselves.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we treat intel_{dp,hdmi}->color_range as partly user
controller value (via the property) but we also change it during
.compute_config() when using the "Automatic" mode. That is a bit
confusing, so let's just change things so that we store the user
property values in intel_dp, and only change what's stored in
pipe_config during .compute_config().
There should be no functional change.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we queue the command or operation to change the scanout address, we
mark the flip as in progress. We can use this flag to prevent us from
checking for a stalled flip prior to its existence!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we don't clflush on pin_to_display if the bo is already
UC/WT and is not in the CPU write domain. This causes problems with
pwrite since pwrite doesn't change the write domain, and it avoids
clflushing on UC/WT buffers on LLC platforms unless the buffer is
currently being scanned out.
Fix the problem by marking the cache dirty and adjusting
i915_gem_object_set_cache_level() to clflush when the cache is dirty
even if the cache_level doesn't change.
My last attempt [1] at fixing this via write domain frobbing was shot
down, but now with the cache_dirty flag we can do things in a nicer way.
[1] http://lists.freedesktop.org/archives/intel-gfx/2014-November/055390.html
v2: Drop the I915_CACHE_NONE/WT checks from pwrite
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86422
Testcase: igt/kms_pwrite_crc
Testcase: igt/gem_pwrite_snooped
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling
DDIA HPD pin in place of DDIB.
v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)
v4: Dont enable interrupt for edp, also reframe the description (Siva)
v5: Don’t check for PORT_A in intel_ddi_init to update dig_port,
instead avoid setting hpd_pin itself (Imre)
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And fix 0-DAY kernel test infrastructure warning.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the offset length being taken care of in ("drm/i915/gtt: Allow >=
4GB offsets in X86_32"), the code should be finally safe in 32-bit
kernels.
This reverts commit 501fd70fca
Author: Michel Thierry <michel.thierry@intel.com>
Date: Fri May 29 14:15:05 2015 +0100
drm/i915: limit PPGTT size to 2GB in 32-bit platforms
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to commit c44ef60e43 ("drm/i915/gtt:
Allow >= 4GB sizes for vm"), i915_gem_obj_offset and i915_gem_obj_ggtt_offset
return an unsigned long, which in only 4-bytes long in 32-bit kernels.
Change return type (and other related offset variables) to u64.
Since Global GTT is always limited to 4GB, this change would not be required
in i915_gem_obj_ggtt_offset, but this is done for consistency.
v2: Remove unnecessary offset variable in do_pin, as we already have
vma->node.start (Chris).
Update GGTT offset too (Tvrtko).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By Vesa DP 1.2 spec TEST_CRC_COUNT is a "4 bit wrap counter which
increments each time the TEST_CRC_x_x are updated."
However if we are trying to verify the screen hasn't changed we get
same (count, crc) pair twice. Without this patch we would return
-ETIMEOUT in this case.
So, if in 6 vblanks the pair (count, crc) hasn't changed we
return it anyway instead of returning error and let test case decide
if it was right or not.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By Vesa DP 1.2 Spec TEST_CRC_COUNT should be
"reset to 0 when TEST_SINK bit 0 = 0."
However for some strange reason when PSR is enabled in
certain platforms this is not true. At least not immediatelly.
So we face cases like this:
first get_sink_crc operation:
count: 0, crc: 000000000000
count: 1, crc: c101c101c101
returned expected crc: c101c101c101
secont get_sink_crc operation:
count: 1, crc: c101c101c101
count: 0, crc: 000000000000
count: 1, crc: 0000c1010000
should return expected crc: 0000c1010000
But also the reset to 0 should be faster resulting into:
get_sink_crc operation:
count: 1, crc: c101c101c101
count: 1, crc: 0000c1010000
should return expected crc: 0000c1010000
So in order to know that the second one is valid one
we need to compare the pair (count, crc) with latest (count, crc).
If the pair changed you have your valid CRC.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By Vesa DP spec, test counter at DP_TEST_SINK_MISC just reset to 0
when unsetting DP_TEST_SINK_START, so let's force this stop here.
But let's minimize the aux transactions and just do it when we know
it hasn't been properly stoped.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GTT was only 32b and its max value is 4GB. In order to allow objects
bigger than 4GB in 48b PPGTT, i915_gem_userptr_ioctl we could check
against max 48b range (1ULL << 48).
But since the check no longer applies, just kill the limit.
v2: Use the default ctx to infer the ppgtt max size (Akash).
v3: Just kill the limit, it was only there for early detection of an
error when used for execbuffer (Chris).
Cc: Akash Goel <akash.goel@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bffa ("drm/i915: Merged
the many do_execbuf() parameters into a structure"), it was already an u64.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it is important that size is a 64b variable.
v2: Drop the warning about bind with size 0, it shouldn't happen anyway.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Clean up patch after rebases.
v3: gen8_dump_ppgtt for 32b and 48b PPGTT.
v4: Use used_pml4es/pdpes (Akash).
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rely on used_px bits instead of null checking (Akash)
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: For semaphore errors, object is mapped to GGTT and offset will not
be > 4GB, print only lower 32-bits (Akash)
v3: Print gtt_offset in groups of 32-bit (Chris)
Cc: Akash Goel <akash.goel@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to PDs, while setting up a page directory pointer, make all entries
of the pdp point to the scratch pd before mapping (and make all its entries
point to the scratch page); this is to be safe in case of out of bound
access or proactive prefetch.
Also add a scratch pdp, which the PML4 entries point to.
v2: Handle scratch_pdp allocation failure correctly, and keep
initialize_px functions together (Akash)
v3: Rebase after Mika's ppgtt cleanup / scratch merge patch series. Rely on
the added macros to initialize the pdps.
v4: Rebase after final merged version of Mika's ppgtt/scratch patches
(and removed commit message part related to v3).
v5: Update commit message to also mention PML4 table initialization and
the new scratch pdp (Akash).
Suggested-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map
Level 4 (PML4), before it selects which Page Directory Pointer (PDP)
it will write to.
Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range.
This patch was inspired by Ben's "Depend exclusively on map and
unmap_vma".
v2: Rebase after s/page_tables/page_table/.
v3: Remove unnecessary pdpe loop in gen8_ppgtt_clear_range_4lvl and use
clamp_pdp in gen8_ppgtt_insert_entries (Akash).
v4: Merge gen8_ppgtt_clear_range_4lvl into gen8_ppgtt_clear_range to
maintain symmetry with gen8_ppgtt_insert_entries (Akash).
v5: Do not mix pages and bytes in insert_entries (Akash).
v6: Prevent overflow in sg_nents << PAGE_SHIFT, when inserting 4GB at
once.
v7: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Use gen8_px_index functions, and remove unnecessary number of pages
parameter in insert_pte_entries.
v8: Change gen8_ppgtt_clear_pte_range to stop at PDP boundary, instead of
adding and extra clamp function; remove unnecessary pdp_start/pdp_len
variables (Akash).
v9: pages->orig_nents instead of sg_nents(pages->sgl) to get the
length (Akash).
v10: Remove pdp warning check ingen8_ppgtt_insert_pte_entries until this
commit (Akash).
Reviewed-by: Akash Goel <akash.goel@intel.com> (v9)
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As a step towards implementing 4 levels, while not discarding the
existing pte insert functions, we need to pass the sg_iter through.
The current function understands to the page directory granularity.
An object's pages may span the page directory, and so using the iter
directly as we write the PTEs allows the iterator to stay coherent
through a VMA insert operation spanning multiple page table levels.
v2: Rebase after s/page_tables/page_table/.
v3: Rebase after Mika's ppgtt cleanup / scratch merge patch series;
updated commit message (s/map/insert).
v4: Rebase.
Reviewed-by: Akash Goel <akash.goel@intel.com> (v3)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains
the base address to PML4, while the other PDP registers are ignored.
In LRC, the addressing mode must be specified in every context
descriptor, and the base address to PML4 is stored in the reg state.
v2: PML4 update in legacy context switch is left for historic reasons,
the preferred mode of operation is with lrc context based submission.
v3: s/gen8_map_page_directory/gen8_setup_page_directory and
s/gen8_map_page_directory_pointer/gen8_setup_page_directory_pointer.
Also, clflush will be needed for bxt. (Akash)
v4: Squashed lrc-specific code and use a macro to set PML4 register.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
PDP update in bb_start is only for legacy 32b mode.
v6: Rebase after final merged version of Mika's ppgtt/scratch
patches.
v7: There is no need to update the pml4 register value in
execlists_update_context. (Akash)
v8: Move pd and pdp setup functions to a previous patch, they do not
belong here. (Akash)
v9: Check USES_FULL_48BIT_PPGTT instead of GEN8_CTX_ADDRESSING_MODE in
gen8_emit_bb_start to check if emit pdps is needed. (Akash)
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PML4 has no special attributes, and there will always be a PML4.
So simply initialize it at creation, and destroy it at the end.
The code for 4lvl is able to call into the existing 3lvl page table code
to handle all of the lower levels.
v2: Return something at the end of gen8_alloc_va_range_4lvl to keep the
compiler happy. And define ret only in one place.
Updated gen8_ppgtt_unmap_pages and gen8_ppgtt_free to handle 4lvl.
v3: Use i915_dma_unmap_single instead of pci API. Fix a
couple of incorrect checks when unmapping pdp and pd pages (Akash).
v4: Call __pdp_fini also for 32b PPGTT. Clean up alloc_pdp param list.
v5: Prevent (harmless) out of range access in gen8_for_each_pml4e.
v6: Simplify alloc_vma_range_4lvl and gen8_ppgtt_init_common error
paths. (Akash)
v7: Rebase, s/gen8_ppgtt_free_*/gen8_ppgtt_cleanup_*/.
v8: Change location of pml4_init/fini. It will make next patches
cleaner.
v9: Rebase after Mika's ppgtt cleanup / scratch merge patch series, while
trying to reuse as much as possible for pdp alloc. pml4_init/fini
replaced by setup/cleanup_px macros.
v10: Rebase after Mika's merged ppgtt cleanup patch series.
v11: Rebase after final merged version of Mika's ppgtt/scratch
patches.
v12: Fix pdpe start value in trace (Akash)
v13: Define all 4lvl functions in this patch directly, instead of
previous patches, add i915_page_directory_pointer_entry_alloc here,
use test_bit to detect when pdp is already allocated (Akash).
v14: Move pdp allocation into a new gen8_ppgtt_alloc_page_dirpointers
funtion, as we do for pds and pts; move pd and pdp setup functions to
this patch (Akash).
v15: Added kfree(pdp) from previous patch to this (Akash).
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
v4: kfree the pdp until the 4lvl alloc/free patch (Akash).
v5: Postpone 48-bit code in sanitize_enable_ppgtt (Akash).
v6: Keep _insert_pte_entries changes outside this patch (Akash).
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The dynamic page allocation patch series added it for GEN6, this patch
adds them for GEN8.
v2: Consolidate pagetable/page_directory events
v3: Multiple rebases.
v4: Rebase after s/page_tables/page_table/.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rebase after gen8_map_pagetable_range removal.
v7: Use generic page name (px) in DECLARE_EVENT_CLASS (Akash)
v8: Defer define of i915_page_directory_pointer_entry_alloc (Akash)
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v3+)
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The insert_entries function was the function used to write PTEs. For the
PPGTT it was "hardcoded" to only understand two level page tables, which
was the case for GEN7. We can reuse this for 4 level page tables, and
remove the concept of insert_entries, which was never viable past 2
level page tables anyway, but it requires a bit of rework to make the
function a bit more generic.
v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v3: Rebase after final merged version of Mika's ppgtt/scratch patches.
v4: Check and warn for NULL value of pdp pointer (Akash).
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2)
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Up until now, ppgtt->pdp has always been the root of our page tables.
Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
In preparation for 4 level page tables, we need to stop using ppgtt->pdp
directly unless we know it's what we want. The future structure will use
ppgtt->pml4 for the top level, and the pdp is just one of the entries
being pointed to by a pml4e. The temporal pdp local variable will be
removed once the rest of the 4-level code lands.
Also, start passing the vm pointer to the alloc functions, instead of
ppgtt.
v2: Updated after dynamic page allocation changes.
v3: Rebase after s/page_tables/page_table/.
v4: Rebase after changes in "Dynamic page table allocations" patch.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rebase after final merged version of Mika's ppgtt/scratch patches.
v7: Keep pagetable map in-line (and avoid unnecessary for_each_pde
loops), remove redundant ppgtt pointer in _alloc_pagetabs (Akash)
v8: Fix text indentation in _alloc_pagetabs/page_directories (Chris)
v9: Defer gen8_alloc_va_range_4lvl definition until 4lvl is implemented,
clean-up gen8_ppgtt_cleanup [pun intended] (Akash).
v10: Clean-up commit message (Akash).
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Reviewed-by: "Akash Goel" <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This transitional patch doesn't do much for the existing code. However,
it should make upcoming patches to use the full 48b address space a bit
easier.
32-bit ppgtt uses just 4 PDPs, while 48-bit ppgtt will have up-to 512;
this patch prepares the existing functions to query the right number of pdps
at run-time. This also means that used_pdpes should also be allocated during
ppgtt_init, as the bitmap size will depend on the ppgtt address range
selected.
v2: Renamed pdp_free to be similar to pd/pt (unmap_and_free_pdp).
v3: To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v4: Rebase after s/page_tables/page_table/, added extra information
about 4-level page table formats and use IS_ENABLED macro.
v5: Check CONFIG_X86_64 instead of CONFIG_64BIT.
v6: Rebase after Mika's ppgtt cleanup / scratch merge patch series, and
follow
his nomenclature in pdp functions (there is no alloc_pdp yet).
v7: Rebase after merged version of Mika's ppgtt cleanup patch series.
v8: Rebase after final merged version of Mika's ppgtt/scratch patches.
v9: Introduce PML4 (and 48-bit checks) until next patch (Akash).
v10: Also use test_bit to detect when pd/pt are already allocated (Akash)
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Reviewed-by: Akash Goel <akash.goel@intel.com>
[danvet: Amend commit message as suggested by Michel.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gen8_clamp_pd clamps to the next page directory boundary, but the macro
gen8_for_each_pde already has a check to stop at the page directory
boundary.
Furthermore, i915_pte_count also restricts to the next page table
boundary.
v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Suggested-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: "Akash Goel" <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
An OEM may request increased I_boost beyond the recommended values
by specifying an I_boost value to be applied to all swing entries for
a port. These override values are specified in VBT.
v2: rebase and remove unused iboost_bit variable
Issue: VIZ-5676
Signed-off-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge drm-intel-fixes because a bunch of atomic patch backporting
we had to do lead to horrible conflicts.
Conflicts:
drivers/gpu/drm/drm_crtc.c
Just a bit of context conflict between -next and -fixes.
drivers/gpu/drm/i915/intel_atomic.c
drivers/gpu/drm/i915/intel_display.c
Atomic conflicts, always pick the code from -next.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
There is currently conflicting documentation on which steppings the
workaround is needed, up to C vs. forever. However there is post-C
stepping hardware that doesn't report port presence on DDI A, leading to
black screen on eDP. Assume the strap isn't connected, and try to enable
DDI A on these machines. (We'll still check the VBT for the info in DDI
init.)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current code
to do the same.
v2: removed loop for jumping blocks and performed direct addition
as recommended by Daniel
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prevent leaking the if scoping by containing the WA_REG
macro inside its own scope.
Reported-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we encounter an allocation failure during ppggt creation (trivial
even with 16Gib+ RAM!), we need to remove the dead context from the
fpriv->context_idr along with the references.
gem_exec_ctx: page allocation failure: order:0, mode:0x8004
CPU: 3 PID: 27272 Comm: gem_exec_ctx Tainted: G W 4.2.0-rc5+ #37
0000000000000000 ffff880086ff7a78 ffffffff816b947a ffff88041ed90038
0000000000008004 ffff880086ff7b08 ffffffff8114b1a5 ffff880086ff7ac8
ffffffff8108d848 0000000000000000 ffffffff81ce84b8 0000000000000000
Call Trace:
[<ffffffff816b947a>] dump_stack+0x45/0x57
[<ffffffff8114b1a5>] warn_alloc_failed+0xd5/0x120
[<ffffffff8108d848>] ? __wake_up+0x48/0x60
[<ffffffff8114e0ed>] __alloc_pages_nodemask+0x73d/0x8e0
[<ffffffffc0472238>] ? i915_gem_execbuffer2+0x148/0x240 [i915]
[<ffffffffc0474240>] __setup_page_dma+0x30/0x110 [i915]
[<ffffffffc0477f61>] gen8_ppgtt_init+0x31/0x2f0 [i915]
[<ffffffffc04785e0>] i915_ppgtt_init+0x30/0x80 [i915]
[<ffffffffc0478928>] i915_ppgtt_create+0x48/0xc0 [i915]
[<ffffffffc046c9c2>] i915_gem_create_context+0x1c2/0x390 [i915]
[<ffffffffc046d9cb>] i915_gem_context_create_ioctl+0x5b/0xa0 [i915]
leading to an oops in i915_gem_context_close. Also note that this
benchmark should not be running out of memory in the first place...
Testcase: igt/benchmark/gem_exec_ctx -b create # ppgtt >= 2
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The IOMMU for Intel graphics has historically had many issues resulting
in random GPU hangs. Lets include its status when capturing the GPU hang
error state for post-mortem analysis.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If idle to active bit is set, the rest of the fields
in CSQ are not valid.
Bail out early if this is the case in order to prevent
rest of the loop inspecting stale values.
This was found by Bspec/code inspection. Doesn't seem to fix any of
the known issues.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
[danvet: Add note about how this was found.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no correspondent Aux channel for DDI-E.
So we need to rely on VBT to let us know witch one
is being used instead.
v2: Removing some trailing spaces and giving proper
credit to Xiong that added a nice way to avoid port
conflicts by setting supports_dp = 0 when using
equivalent aux for DDI-E.
Credits-to: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I started digging this when I noticed that the BDW code was just
reserving 1mb by coincidence since it was reading reserved fields.
Then I noticed we didn't have any values set for SNB and earlier, and
that the HSW sizes were wrong. After that, I noticed that the reserved
area has a specific start, and may not exactly end where the stolen
memory ends. I also noticed the base pointer can be zero. So I decided
to just write a single patch fixing everything instead of 20 patches
that would be much harder to review.
This patch may solve random stolen memory corruption/problems on
almost all platforms. Notice that since this is always dealing with
the top of the stolen memory, the problems are not so easy to
reproduce - especially since FBC is still disabled by default.
One of the major differences of this patch is that we now look at both
the size and base address. By only looking at the size we were
assuming that the reserved area was always at the very top of
stolen, which is not always true.
After we merge the patch series that allows user space to allocate
stolen memory we'll be able to write IGT tests that maybe catch the
bugs fixed by this patch.
v2:
- s/BIOS reserved/stolen reserved/g (Chris)
- Don't DRM_ERROR if we can't do anything about it (Chris)
- Improve debug messages (Chris).
- Use the gen7 version instead of gen6 on HSW. Tom found some
documentation problems, so I think with gen7 we're on the safer
side (Tom).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This register needs to be updated with masked writes.
This was found by code inspection and comparison with Bspec and
doesn't seem to fix any known issue.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
[danvet: Add note about impact.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we encounter frequent problems with dp aux channel
communications, we end up spamming the dmesg with the
exact similar trace and status.
Inject a new backtrace only if we have new information
to share as otherwise we flush out all other important
stuff.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-EDEADLK has special meaning in atomic, but get_fence may call
i915_find_fence_reg which can return -EDEADLK.
This has special meaning in the atomic world, so convert the error
to -EBUSY for this case.
Changes since v1:
- Add comment in the code.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The rest will be a noop anyway, since without modeset there will be
no updated dplls and no modeset state to update.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are no more users, byebye!
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that everything's atomic, checking encoder->base.crtc is enough.
This function doesn't have the locks to dereference crtc->state, but
stealing an encoder bound to any crtc is probably enough reason to warn.
Changes since v1:
- Commit message.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
connectors_active will be removed, so just calculate this instead.
Changes since v1:
- Look for the right pointer in intel_sanitize_encoder.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is now done completely atomically.
Keep connectors_active for now, but make it mirror crtc_state->active.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of allocating pipe_config on the stack use the old
crtc_state, it's only going to freed from this point on.
All crtc' are now only checked once during modeset,
because false positives can happen with encoders after
dpms changes and to limit the amount of errors for 1 failure.
Changes since v1:
- crtc_state -> old_crtc_state
- state -> old_state
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Connectors are updated atomically now, so the only interaction
with the encoder is through base.crtc.
If it's NULL the encoder's not part of any crtc, and if it's
not NULL then active should be equal to crtc_state->active.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is handled by the atomic core now, no need to check this for ourself.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Right now dpms callbacks can still fiddle with the connector state,
but it can only turn connectors off.
This is remediated by only checking crtc->state->active when the
connector is active, and ignore crtc->state->active when the
connector is off.
connectors_active is no longer checked, and will be removed later
in this series together with dpms.
Another check for !encoder->crtc is performed by check_encoder_state
too, so it can be removed.
Changes since v1:
- Add commit message.
- rename state to old_state.
- Move deletion of mst_port check to mst patch.
Changes since v2:
- Fix a null pointer dereference on MST now hw readout is fixed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.
With atomic the state can be made consistent all the time.
Thanks to Sivakumar Thulasimani for the idea of using
drm_atomic_helper_set_config.
Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Changes since v2:
- Use drm_atomic_helper_set_config.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
First step in removing dpms and validating atomic state.
There can still be a mismatch in the connector state because the dpms
callbacks are still used, but this can not happen immediately after a modeset.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Set connectors_changed to force a modeset if the panel fitter's force
enabled on eDP.
Changes since v1:
- Use connectors_changed instead of active_changed because it's a
routing update.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch is based on the upstream commit 5ac1c4bcf0 and amended
for v4.2 to make sure it works as intended.
Repeated calls to begin_crtc_commit can cause warnings like this:
[ 169.127746] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
[ 169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
[ 169.127840] 3 locks held by kms_flip/1947:
[ 169.127843] #0: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff814774bc>] __drm_modeset_lock_all+0x9c/0x130
[ 169.127860] #1: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffff814774cd>] __drm_modeset_lock_all+0xad/0x130
[ 169.127870] #2: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffff81477178>] drm_modeset_lock+0x38/0x110
[ 169.127879] irq event stamp: 665690
[ 169.127882] hardirqs last enabled at (665689): [<ffffffff817ffdb5>] _raw_spin_unlock_irqrestore+0x55/0x70
[ 169.127889] hardirqs last disabled at (665690): [<ffffffffc0197a23>] intel_pipe_update_start+0x113/0x5c0 [i915]
[ 169.127936] softirqs last enabled at (665470): [<ffffffff8108a766>] __do_softirq+0x236/0x650
[ 169.127942] softirqs last disabled at (665465): [<ffffffff8108ae75>] irq_exit+0xc5/0xd0
[ 169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+ #4039
[ 169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[ 169.127957] ffff8800c49036f0 ffff8800cde5fa28 ffffffff817f6907 0000000080000001
[ 169.127964] 0000000000000000 ffff8800cde5fa58 ffffffff810aebed 0000000000000046
[ 169.127970] ffffffff81c5d518 0000000000000268 0000000000000000 ffff8800cde5fa88
[ 169.127981] Call Trace:
[ 169.127992] [<ffffffff817f6907>] dump_stack+0x4f/0x7b
[ 169.128001] [<ffffffff810aebed>] ___might_sleep+0x16d/0x270
[ 169.128008] [<ffffffff810aed38>] __might_sleep+0x48/0x90
[ 169.128017] [<ffffffff817fc359>] mutex_lock_nested+0x29/0x410
[ 169.128073] [<ffffffffc01635f0>] ? vgpu_write64+0x220/0x220 [i915]
[ 169.128138] [<ffffffffc017fddf>] ? ironlake_update_primary_plane+0x2ff/0x410 [i915]
[ 169.128198] [<ffffffffc0190e75>] intel_frontbuffer_flush+0x25/0x70 [i915]
[ 169.128253] [<ffffffffc01831ac>] intel_finish_crtc_commit+0x4c/0x180 [i915]
[ 169.128279] [<ffffffffc00784ac>] drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper]
[ 169.128338] [<ffffffffc0184264>] __intel_set_mode+0x684/0x830 [i915]
[ 169.128378] [<ffffffffc018a84a>] intel_crtc_set_config+0x49a/0x620 [i915]
[ 169.128385] [<ffffffff817fdd39>] ? mutex_unlock+0x9/0x10
[ 169.128391] [<ffffffff81467b69>] drm_mode_set_config_internal+0x69/0x120
[ 169.128398] [<ffffffff8119b547>] ? might_fault+0x57/0xb0
[ 169.128403] [<ffffffff8146bf93>] drm_mode_setcrtc+0x253/0x620
[ 169.128409] [<ffffffff8145c600>] drm_ioctl+0x1a0/0x6a0
[ 169.128415] [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
[ 169.128424] [<ffffffff811e9ab8>] do_vfs_ioctl+0x2f8/0x530
[ 169.128429] [<ffffffff810d0fcd>] ? trace_hardirqs_on+0xd/0x10
[ 169.128435] [<ffffffff812e7676>] ? selinux_file_ioctl+0x56/0x100
[ 169.128439] [<ffffffff811e9d71>] SyS_ioctl+0x81/0xa0
[ 169.128445] [<ffffffff81800697>] system_call_fastpath+0x12/0x6f
Solve it by using the newly introduced drm_atomic_helper_commit_planes_on_crtc.
The problem here was that the drm_atomic_helper_commit_planes() helper
we were using was basically designed to do
begin_crtc_commit(crtc #1)
begin_crtc_commit(crtc #2)
...
commit all planes
finish_crtc_commit(crtc #1)
finish_crtc_commit(crtc #2)
The problem here is that since our hardware relies on vblank evasion,
our CRTC 'begin' function waits until we're out of the danger zone in
which register writes might wind up straddling the vblank, then disables
interrupts; our 'finish' function re-enables interrupts after the
registers have been written. The expectation is that the operations between
'begin' and 'end' must be performed without sleeping (since interrupts
are disabled) and should happen as quickly as possible. By clumping all
of the 'begin' calls together, we introducing a couple problems:
* Subsequent 'begin' invocations might sleep (which is illegal)
* The first 'begin' ensured that we were far enough from the vblank that
we could write our registers safely and ensure they all fell within
the same frame. Adding extra delay waiting for subsequent CRTC's
wasn't accounted for and could put us back into the 'danger zone' for
CRTC #1.
This commit solves the problem by using a new helper that allows an
order of operations like:
for each crtc {
begin_crtc_commit(crtc) // sleep (maybe), then disable interrupts
commit planes for this specific CRTC
end_crtc_commit(crtc) // reenable interrupts
}
so that sleeps will only be performed while interrupts are enabled and
we can be sure that registers for a CRTC will be written immediately
once we know we're in the safe zone.
The crtc->config->base.crtc update may seem unrelated, but the helper
will use it to obtain the crtc for the state. Without the update it
will dereference NULL and crash.
Changes since v1:
- Use Matt Roper's commit message.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90398
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This should be much cleaner, with the same effects.
(cherry picked for v4.2 from commit fb9d6cf8c2)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90398
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In
commit d328c9d78d
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
we started to select the pipe bpp from sink capabilities and not from
the primary framebuffer - that one might change (and we don't want to
incur a modeset) and sprites might contain higher bpp content too.
We also selected dithering on a 8 bpc screen displaying a 24bpp rgb
primary, because pipe_bpp is 24 for such a typical 8 bpc sink, but since
the commit mentioned above, base_bpp is always the absolute maximum
supported by the hardware, e.g., 36 bpp on my Ironlake chip. Iow. the
only way to not get dithering would have been to connect a deep color 12
bpc display, so pipe_bpp == 36 == base_bpp.
Hence only enable dithering on 6bpc screens where we difinitely and
always want it.
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Rather than a mix of the the sized uint32_t and signed integer, use an
unsized unsigned int to specify the format count.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of our own duplicated one. This fixes a bug in the driver
unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
try to unregister the nonexistent fbdev drm_framebuffer.
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull drm fixes from Daniel Vetter:
"One i915 regression fix and a drm core one since Dave's not around,
both introduced in 4.2 so not cc: stable.
The fix for the warning Ted reported isn't in here yet since he didn't
yet supply a tested-by and I can't repro this one myself (it's in
fixup code that needs firmware doing something i915 wouldn't do)"
* tag 'drm-intel-fixes-2015-08-07' of git://anongit.freedesktop.org/drm-intel:
drm/vblank: Use u32 consistently for vblank counters
drm/i915: Allow parsing of variable size child device entries from VBT
VBT version 196 increased the size of common_child_dev_config. The parser
code assumed that the size of this structure would not change.
The modified code now copies the amount needed based on the VBT version,
and emits a debug message if the VBT version is unknown (too new);
since the struct config block won't shrink in newer versions it should
be harmless to copy the maximum known size in such cases, so that's
what we do, but emitting the warning is probably sensible anyway.
In the longer run it might make sense to modify the parser code to
use a version/feature mapping, rather than hardcoding things like this,
but for now the variants are fairly managable.
This fixes a regression introduced in
commit 90e4f1592b
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Mar 25 18:45:58 2015 +0200
drm/i915: Fix the VBT child device parsing for BSW
since we're hitting a DRM_ERROR on older platforms with this.
v2: Stricter size checks
Signed-off-by: David Weinehall <david.weinehall@linux.intel.com>
[danvet: Fixup format string.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need a few core drm patches to be able to merge Maarten's series to
convert DPMS over to atomic.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
v3:
- Don't touch remove_conflicting_framebuffers
v2:
- No changes
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There was already one in the blank handler, but it failed silently.
That makes it impossible for drivers (like i915) who subclass these
functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we
really don't want to be bothered right now. This also allows us to
remove a pile of FIXMEs from the i915 fbdev code (since due to the
failure code they now won't attempt to grab dangerous locks any more).
Cc: Dave Airlie <airlied@gmail.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Looks like
commit eddfcbcdc2
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Mon Jun 15 12:33:53 2015 +0200
drm/i915: Update less state during modeset.
introduced the unconditional calling of disable_shared_dpll, but didn't
fix up pre-gen5 to avoid the BUG_ON at the top of the function.
So change the BUG_ON into a gen check (alternately we could move the
BUG_ON until later, since we shouldn't have a pll struct here either,
but this seems clearer to read).
This fixes a crash on load on my x200s platform.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch contains the changes to remove the byte
swapping logic introduced with old dmc firmware.
While debugging PC10 entry issue for skylake found
with latest dmc firmware version 1.18 without byte
swapping dmc is working fine and able to enter PC10.
Note that apparently this was changed with dmc version 1.0 and earlier
ones indeed are byteswapped like this ...
v1: Initial version.
v2: Corrected firmware size during memcpy(). (Suggested by Sunil)
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: A.Sunil Kamath <sunil.kamath@intel.com>
[danvet: Add note that this only holds for released dmc firmware.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and read into display_info, hence bpp from
VBT will be used only when bpc in display_info is zero.
v2: use display_info.bpc for deciding when to use vbt_bpp (Jani)
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I was told that the "repurposed D1 definition" is still valid for SKL.
It is BDW that is special due to its hotplug bug, so let's
special-case BDW instead of HSW.
Cc: Kristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to the ->enable vfunc in patch "drm/i915: Extract a
intel_power_well_enable() function".
v2 (from Paulo):
- Same s/i915_/intel_/ bikeshed as the previous patch.
- Update the commit hash.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need a bit book keeping around power wells' ops->enable(), namely a
nice debug message and updating hw_enabled. Let's introduce a
intel_power_well_enable() function to make sure all the callers do the
same things.
v2 (from Paulo):
- s/i915_power_well_enable/intel_power_well_enable/ since everything
else on this file uses intel_ instead of i915_.
- Fix typo in commit message.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With this simple git diff command one can see that skl_init_workarounds()
got two copies of WaBarrierPerformanceFixDisable:skl:
git diff -U21 ca6e4405779e^1 ca6e440577 drivers/gpu/drm/i915/intel_ringbuffer.c
This happened when the backmerge of drm-intel-fixes-2015-07-15
Merged the same fix on both sides. Same fix but not identical enough for
git: with a different surrounding context; hence the code duplication.
This commit merely reverts the output of the git command above
= the duplication introduced in the backmerge.
(This duplication was found while running git sanity checks on a
_linearized_ i915 forklift for ChromeOS.)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since active function on VLV immediately activate PSR let's give more
time for idleness. Different from core platforms where we have idle_frames
count.
Also kms_psr_sink_crc now is automated and always get this:
[drm:intel_enable_pipe] enabling pipe A
[drm:intel_edp_backlight_on]
[drm:intel_panel_enable_backlight] pipe
[drm:intel_panel_enable_backlight] pipe A
[drm:intel_panel_actually_set_backlight] set backlight PWM = 7812
PSR gets enabled somewhere here after backlight.
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x0
[drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
[drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
PSR gets flushed around here by intel_atomic_commit
[drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
[drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
[drm:intel_set_memory_cxsr] memory self-refresh is enabled
[drm:intel_connector_check_state] [CONNECTOR:39:eDP-1]
[drm:check_encoder_state] [ENCODER:30:DAC-30]
[drm:check_encoder_state] [ENCODER:31:TMDS-31]
[drm:check_encoder_state] [ENCODER:36:TMDS-36]
[drm:check_encoder_state] [ENCODER:38:TMDS-38]
[drm:check_crtc_state] [CRTC:21]
[drm:check_crtc_state] [CRTC:26]
[drm:intel_psr_activate [i915]] *ERROR* PSR Active
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO
Underrun.
It is true that in a product we won't keep disabling and enabling planes so
frequently, but for safeness let's stay conservative.
It is also true that 500ms is an etternity. But PSR is anyway a power saving
feature for idle scenario. So if it is idle feature stays on and 500ms to get
it reanabled is not that insane.
v2: Rebase over intel_psr.c and fix typo.
v3: Revival: Manual tests indicated that this is needed. With a short delay
there is a huge risk of getting blank screens when planes are being enabled.
v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but
actually time for link training what we aren't doing, but with only 100 sec
in some cases kms_psr_sink_crc manual was showing blank screen,
so let's use this for now. Also changed comment by a FIXME.
v5: Rebase after a long time, remove FIXME and update comment above.
v6: msecs_to_jiffies is already on delay. remove duplication.
v7: use msecs_to_jiffies on schedule_delayed_work call.
Reviewed-by: Durgadoss R <durgadoss.r@intel.com> (v4)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is just a preparation patch to make clear what operation we
are performing. There is no functional change on the sink crc
logic.
hsw_disable_ips has been moved a bit further in the start function
to avoid disabling ips when sink crc is not going to be started.
and to avoid goto on this function.
v2: explain why hsw_disable_ips() call place has changed.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
First, an introduction. We currently have two types of GTT mmaps: the
"normal" old mmap, and the WC mmap. For frontbuffer-related features
that have automatic hardware tracking, only the non-WC mmap writes are
detected by the hardware. Since inside the Kernel both are treated as
ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
tracking are destined to fail.
One of the special rules defined for the WC mmaps is that the user
should call the dirtyfb IOCTL after he is done using the pointers, so
that results in an intel_fb_obj_flush() call. The problem is that the
dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
though the hardware tracking is not detecing the WC mmap operations.
So in order to fix that without having to give up the automatic
hardware tracking for GTT mmaps we transform the flush operation from
dirtyfb into a special operation: ORIGIN_DIRTYFB.
This commit fixes all the kms_frontbuffer_tracking subtests that
contain "fbc" and "mmap-wc" in their names and are currently failing
(for a total of 16 subtests).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the appropriate call.
I know there's a discussion about whether we need this call here at
all, but removing the call means we'll only update FBC after we get
the page flip IRQ. So the user may only see the new frame a little
after it should. Let's wait just a little bit more before removing
this call since we can rely in the HW tracking for accurate flips.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because intel_unpin_work_fn() already calls
intel_frontbuffer_flip_complete() which will call intel_fbc_flush()
which will call intel_fbc_update() when needed.
We couldn't fix this previously due to the fact that FBC was not
properly behaving as intended on frontbuffer flushes, but now that
this is fixed, we can remove the additional call.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Due to the way busy_bits was handled, we were not doing any flushes if
we didn't previously get an invalidate. Since it's possible to get
flushes without an invalidate first, remove the busy_bits early
return.
So now that we don't have the busy_bits guard anymore we'll need the
origin check for the GTT tracking (we were not doing anything on GTT
flushes due to the GTT check at invalidate()).
As a last detail, since we can get multiple consecutive flushes,
disable FBC before updating it, otherwise intel_fbc_update() will just
keep FBC enabled instead of restarting it.
Notice that this does not fix any of the current IGT tests due to the
fact that we still have a few intel_fbc() calls at points where we
also have the frontbuffer tracking calls: we didn't fully convert to
frontbuffer tracking yet. Once we remove those calls and start relying
only on the frontbuffer tracking infrastructure we'll need this patch.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In
commit 8c7b5ccb72
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Tue Apr 21 17:13:19 2015 +0300
drm/i915: Use atomic helpers for computing changed flags
we've switched over to the atomic version to compute the
crtc->encoder->connector routing from the i915 variant. That one
relies upon the ->best_encoder callback, but the i915-private version
relied upon intel_find_encoder. Which didn't matter except for dp mst,
where the encoder depends upon the selected crtc.
Fix this functional bug by implemented a correct atomic-state based
encoder selector for dp mst.
Note that we can't get rid of the legacy best_encoder callback since
the fbdev emulation uses that still. That means it's incorrect there
still, but that's been the case ever since i915 dp mst support was
merged so not a regression. Best to fix that by converting fbdev over
to atomic too.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Linus Torvalds