A few bits have changed in MI_DISPLAY_FLIP to accomodate the new planes.
DE_RRMR seems to have kept its plane flip bits backward compatible.
v2: Rebase on top of nightly
v3: Rebase on top of nightly (minor conflict in i915_reg.h)
v4: Remove code that is now part of intel_crtc_page_flip()
Don't use BUG() in default:
Use intel_crtc->unpin_work->gtt_offset
(Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: rebase on top of the hw state flattening.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Modify the implementation to query DPLL attached to a SKL port.
v2: Rebase on top of the run-time PM on DPMS series (Damien)
v3: Modified as per review comments from Paulo
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some machines may have a broken VBT or no VBT at all, but we still want
to use SSC there. So check for it and keep it enabled if we see it
already on. Based on an earlier fix from Kristian.
v2: honor modparam if set too (Daniel)
read out at init time and store for panel_use_ssc() use (Jesse)
v3: trust BIOS configuration over VBT like we do for DP (Jani)
Reported-by: Kristian Høgsberg <hoegsberg@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This only affects the fastboot path as-is. In that case, we simply need
to make sure that we update the pipe size at the first mode set. Rather
than putting it off until we decide to flip (if indeed we do end up
flipping), update the pipe size as appropriate a bit earlier in the
set_config call.
This sets us up for better pipe tracking in later patches.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If these change (e.g. after a modeset following a fastboot), we need to
do a full mode set.
v2:
- put under pipe_config check so we don't deref a null state (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is useful for checking things later.
v2:
- fix hsw infoframe enabled check (Ander)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Add the missing PIPE_CONF_CHECK_I(has_infoframe); line to the
hw state cross-checker.]
[danet: Squash in fixup from Jesse to correctly compute has_infoframe
in the hdmi compute_config function.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will allow us to consult more info before deciding whether to flip
or do a full mode set.
v2:
- don't use uninitialized or incorrect pipe masks in set_config
failure path (Ander)
v3:
- fixup for pipe_config changes in compute_config (Jesse)
v4:
- drop spurious hunk in force restore path (Ander)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows us to calculate the full pipe config before we do any mode
setting work.
v2:
- clarify comments about global vs. per-crtc mode set (Ander)
- clean up unnecessary pipe_config = NULL setting (Ander)
v3:
- fix pipe_config handling (alloc in compute_config, free in set_mode) (Jesse)
- fix arg order in set_mode (Jesse)
- fix failure path of set_config (Ander)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we register the backlight device as soon as we register the
connector. That means we can get backlight requests from userspace
already before reading out the current modeset hardware state.
That means we don't yet know the current crtc->encoder->connector mapping,
which causes problems for VLV/CHV which need to know the current pipe in
order to figure out which BLC registers to poke. Currently we just
ignore such requests fairly deep in the backlight code which means the
backlight device brightness property will get out of sync with our
backlight.level and the actual hardware state.
Fix the problem by delaying the backlight device registration until the
entire modeset init has been performed. And we also move the
backlight unregisteration to happen as the first thing during the
modeset cleanup so that we also won't be bothered with userspace
backlight requested during teardown.
This is a real world problem on machines using systemd, because systemd,
for some reason, wants to restore the backlight to the level it used last
time. And that happens as soon as it sees the backlight device appearing
in the system. Sometimes the userspace access makes it through before
the modeset init, sometimes not.
v2: Do not lie to the user in the debug prints (Jani)
Include connector name in the prints (Jani)
Fix a typo in the commit message (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the connector would have an encoder but the encoder didn't have a
crtc we might dereference a NULL crtc here. I suppose that should never
happen due to intel_sanitize_encoder(), but let's be a bit paranoid
print a warning if we ever hit this and return INVALID_PIPE to the
caller.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since a8bb681827 __intel_framebuffer_create() is called
with struct_mutex held, so it should use drm_gem_object_unreference()
instead of drm_gem_object_unreference_unlocked().
Found by Linux Driver Verification project (linuxtesting.org).
This regression has been introduced in
commit a8bb681827
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Feb 10 18:00:39 2014 +0100
drm/i915: Fix error path leak in fbdev fb allocation
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the new pipe config values to calculate the updated pll dividers.
This regression was introduced in
commit 0dbdf89f27b17ae1eceed6782c2917f74cbb5d59
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Wed Oct 29 11:32:33 2014 +0200
drm/i915: Add infrastructure for choosing DPLLs before disabling crtcs
and
commit 00d958817dd3daaa452c221387ddaf23d1e4c06f
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Wed Oct 29 11:32:36 2014 +0200
drm/i915: Covert remaining platforms to choose DPLLS before disabling CRTCs
v2: Use intel_pipe_will_have_type() to look at new configuration - Ander
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
CC: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The cleanup path would reset pll->new_config to NULL but wouldn't free
the allocated memory.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Turned out to be much simpler on top of my latest atomic stuff than
what I've feared. Some details:
- Drop the modeset_lock_all snakeoil in drm_plane_init. Same
justification as for the equivalent change in drm_crtc_init done in
commit d0fa1af40e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Sep 8 09:02:49 2014 +0200
drm: Drop modeset locking from crtc init function
Without these the drm_modeset_lock_init would fall over the exact
same way.
- Since the atomic core code wraps the locking switching it to
per-plane locks was a one-line change.
- For the legacy ioctls add a plane argument to the locking helper so
that we can grab the right plane lock (cursor or primary). Since the
universal cursor plane might not be there, or someone really crazy
might forgoe the primary plane even accept NULL.
- Add some locking WARN_ON to the atomic helpers for good paranoid
measure and to check that it all works out.
Tested on my exynos atomic hackfest with full lockdep checks and ww
backoff injection.
v2: I've forgotten about the load-detect code in i915.
v3: Thierry reported that in latest 3.18-rc vmwgfx doesn't compile any
more due to
commit 21e88620aa
Author: Rob Clark <robdclark@gmail.com>
Date: Thu Oct 30 13:39:04 2014 -0400
drm/vmwgfx: fix lock breakage
Rebased and fix this up.
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUX/DqAAoJEHm+PkMAQRiGLtQH/iAt3fRHlYDXjaJian/KG1Cb
wVP0I+HWZmvVmmd0PzyaxCZLgRNwdmmYHEH4QLy2JwZ3jZfFHlxhy+hDWCgz+67t
bIzkLs0Pf1T4kJ2+r8qW2kBEz9PWJHGTQw7NTqZ++Ts3rPptBA6Fg4mEJ6fQigXy
qRIY68DpipUkXV9BWBWijnTmrvP5tt7JtPzBr4DC8frMjvWct8+XwYhc2k2tEv2j
LwLYb1OW6PUpPv2BQBfWjqqH77vYNQVhJwuwGcDe2YZdI0UFkDheL24+RbbPcZ4f
OnrLjJSSgzv6lBWkAaXZK7/WJ/JZbXxEqHzWZQ3xXoQov97bm7lEYJqqi5gDasQ=
=6Qpa
-----END PGP SIGNATURE-----
Merge tag 'v3.18-rc4' into drm-next
backmerge to get vmwgfx locking changes into next as the
conflict with per-plane locking.
We need the HPLL frequency when calculating cdclk. Currently we read
that out from the hardware every single time, which isn't going to fly
very well if the device is runtime suspended. So cache the HPLL
frequency in dev_priv and use the cached value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This simplifies the code quite a bit compared to iterating over all
rings during the ring interrupt.
Also, it allows us to drop the mmio_flip spinlock, since the mmio_flip
struct is only accessed in two places. The first is when the flip is
queued and the other when the mmio writes are done. Since a flip cannot
be queued while there is a pending flip, the two paths shouldn't ever
run in parallel. We might need to revisit that if support for replacing
flips is implemented though.
v2: Don't hold dev->struct_mutext while waiting (Chris)
v3: Make the wait uninterruptable (Chris)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We may need to access various hardware bits in the .global_resources()
hook, so move the call to occur after enabling all the newly required
power wells, but before disabling all the now unneeded wells. This
should guarantee that we have all the sufficient hardware resources
available during the .global_resources() call. And if not, any additional
resources must be explicitly acquired by the .global_resorces() hook.
For instance on VLV/CHV we need to access the gunit mailbox so that we
can talk to punit/cck over sideband. In addition some PFI credit
reprogramming may need to be addes as well, which may require the disp2d
well.
This should also make the power domain refcounts consistent on platforms
which don't have a .global_resource() hook since now they too will
call modeset_update_crtc_power_domains() which will drop the init power.
Previously init power was just left enabled for such platforms.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch provides the implementation for reading the pipe wm HW
state.
v2: Incorporated Damien's review comments and also made modifications
to incorporate the plane/cursor split.
v3: No need to ident a line that was fitting 80 chars
Return early instead of indenting the remaining of a function
(Damien)
v4: Rebase on top of nightly (minor conflict in intel_drv.h)
v5: Rebase on top of nightly (minor conflict in intel_drv.h)
v6: Rebase on top of nightly (minor conflict in intel_drv.h)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we program just DPSCNTR and DSPSTRIDE directly from the ring
interrupt handler, which is fine since the hardware guarantees that
those are update atomically. When we have atomic page flips we'll want
to be able to update also the offset registers, and then we need to use
the vblank evade mechanism to guarantee atomicity. Since that mechanism
introduces a wait, we need to do the actual register write from a work
when it is triggered by the ring interrupt.
v2: Explain the need for mmio_flip.work in the commit message (Paulo)
Initialize the mmio_flip work in intel_crtc_init() (Paulo)
Prevent new flips the previous flip work finishes (Paulo)
Don't acquire modeset locks for mmio flip work
Note: Paulo had reservations about the work item leaking over a plane
disable. But insofar as we do lack these checks that issue is already
present with the existing code.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It will help future code if this function knows something about of the context
of the display setup object is being pinned for.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As Paulo said when introducing the enum, having more types is really
good to document what should go where (int foo(int, int, bool, bool).
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's really part of the "push all new_* state into current state
pointers" done in that function. So let's move it there to make this
clear.
Also, with the conversion done the num_shared_dpll check the function
does in it's loop is enough, so we can drop the check for the dpll
compute callback, too.
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Now that shared DPLLs configuration is staged, there's no need to track
the current ones in the new pipe_config since those are released before
making the new pipe_config effective.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no users left after the conversion to calculate clocks before
disabling crtcs during mode set.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the infrastructure added in a previous patch to choose shared DPLLs
and calculate clocks before touching the hardware.
v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the infrastructure added in a previous patch to choose shared DPLLs
and calculate clocks before touching the hardware.
v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the infrastructure added in a previous patch to choose shared DPLLs
and calculate clocks before touching the hardware.
v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is possible for a mode set to fail if there aren't shared DPLLS that
match the new configuration requirement or other errors in clock
computation. If that step is executed after disabling crtcs, in the
failure case the hardware configuration is changed and needs to be
restored. Doing those things early will allow the mode set to fail
before actually touching the hardware.
Follow up patches will convert different platforms to use the new
infrastructure.
v2: Keep pll->new_config valid only during mode set (Ville)
Use kmemdup() in i915_shared_dpll_start_config() (Ville)
Restore old pll config if something fails before commit (Ville)
Don't set compute_clock hooks since dev_priv is kzalloc()'d (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The new struct will be used in a follow up patch to allow a current and
a staged config to exist for the same shared DPLL.
v2: Rebase on by mask_to_refcount()->hweight32() change. (Damien)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will be used in a follow up patch to properly release shared DPLLs
without relying on the shared_dpll field in pipe_config.
v2: Fix white space error (Ville)
Use hweight32() (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
More concise. Noticed while reviewing Ander's patch which touched a
lot of the pipe_has_type checks.
v2: Use new_config in one place Ander spotted.
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This shouldn't change the behavior of those functions, since they are
called after the new_config is made effective and that points to the
current config. In a follow up patch, the mode set sequence will be
changed so this is called before disabling crtcs, and in that case
those functions should work on the staged config.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Flatten if by moving the check into the WARN.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV adds a bunch of new registers for primary plane size/position and
pipe blender setup. Initialize all those registers to avoid nasty
surprises. PRIMSIZE is especially important as without programming it
the outout will be garbled whenever the primary plane size would not
match what the BIOS set up.
Also program the sprite constant alpha register to disable the constant
alpha blending factor. This applies to vlv as well as chv.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Take out the pin_fb code so commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The power seqeuencer kick procedure requires the DPLL to be running
in order to complete successfully. In case the DPLL isn't currently
running when we need to kick the power seqeuncer enable it
temporarily. This can happen eg. during ->detect() when the pipe is
not already active.
To avoid needlessly duplicating the DPLL programming re-use the already
existing functions by passing a temporary pipe config to them instead
of having them consult the current pipe config at crtc->config.
v2: Introduce vlv_force_pll_{on,off}() (Daniel)
v3: Rebase due to drm_crtc vs. intel_crtc changes
Fix a typo in commit msg (checkpatch)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v1)
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because I got annoyed that I had to document what values "int
ddi_personality" is supposed to hold.
A good side-effect of this change is that now the compilers can do
some additional checks on our code, which may prevent some bugs in the
future. A bad side-effect of this change is that now the compilers do
some additional checks on our code and complain when a switch
statement doesn't check for all possible values, so we need to add
"default" cases to all those switches. Hopefully, this may help
preventing confusions against DRM_MODE_CONNECTOR_* and
DRM_MODE_ENCODER_*.
I guess that just by looking at the patch, some people will think this
change is not worth its benefits. In this case, I don't really mind
dropping the patch.
Also, there's probably still a few more places where we can
s/int/enum intel_output_type/, but we can change that later, when we
spot the places.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Resolve conflict due to reordered patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for some additional cleanup. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The fb check introduced to drm_plane_helper_check_update() just make this
check impossible to branch in.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
use_mmio_flip() makes sure we only enable MMIO flips on gen5+. So we
don't need to take into account older devices.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no point in flipping a buffer for a disabled crtc.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows the cursor plane to be updated the same way as primary and sprites,
and same set_property handler is used for all of these planes.
v2 (by Matt Roper): Rework to apply to latest di-nightly codebase. The
switch to split check/commit plane programming changed the code
flow enough that the original patch could no longer be applied.
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by (IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit c675949ec5
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Apr 9 11:31:37 2014 +0300
drm/i915: do not setup backlight if not available according to VBT
prevents backlight setup on Macbook 2,1. Apply quirk to ignore the VBT
check so backlight is set up properly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81438
Signed-off-by: Jens Stein Jørgensen <jens.s.stein@gmail.com>
Cc: stable@vger.kernel.org (3.15+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider.
This is a regression from:
commit f8bf63fdcb
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Jun 13 13:37:54 2014 +0300
drm/i915: Kill duplicated cdclk readout code from i2c
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The cursor plane also supports 180 degree rotation. Add a new
"cursor-rotation" property on the crtc which controls this.
Unlike sprites, the cursor has a fixed size, so if you have a small
cursor image with the rest of the bo filled by transparent pixels,
simply flipping the rotation property will cause the visible part
of the cursor to shift. This is something to keep in mind when
using cursor rotation.
v2: Fix gen4/vlv by offsetting the base address appropriately
v3: Removing cursor-rotation property and using rotation property on cursor
plane.
v4: Changing the author name back to Ville.
v5 (by Matt Roper): Slight tweaking to apply against latest di-nightly
codebase.
Cc: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by (IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some machines (like MBAs) might use a tiled framebuffer but not enable
display swizzling at boot time. We want to preserve that configuration
if possible to prevent a boot time mode set. On IVB+ it shouldn't
affect performance anyway since the memory controller does internal
swizzling anyway.
For most other configs we'll be able to enable swizzling at boot time,
since the initial framebuffer won't be tiled, thus we won't see any
corruption when we enable it.
v2: preserve swizzling if BIOS had it set (Daniel)
v3: preserve swizzling only if we inherited a tiled framebuffer (Daniel)
check display swizzle setting in detect_bit_6_swizzle (Daniel)
use gen6 as cutoff point (Daniel)
v4: fixup swizzle preserve again, had wrong init order (Daniel)
Reported-by: Kristian Høgsberg <hoegsberg@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For consistency, since that's the rule followed for internal functions.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For consistency, since that's the rule followed for internal functions.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For consistency, since that's the rule followed for internal functions.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the ironlake mode set code, there was two instances of a loop through
encoders to find out if one of them has INTEL_OUTPUT_LVDS type. Simplify
the code by deleting some lines and use intel_pipe_has_type() instead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add support for 180 degree rotation for primary and sprite planes
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even if the fb is the same we should still check if the sizes are
valid to be set.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move check inside intel_crtc_cursor_set_obj() to
intel_check_cursor_plane(), we only use it there so move them out to
make the merge of intel_crtc_cursor_set_obj() into
intel_check_cursor_plane() easier.
This is another step toward the atomic modesetting support and unification
of plane operations such pin/unpin of fb objects on i915.
v2: take Ville's comment: move crtc_{w,h} assignment a bit down in the
code
v3: take Ville's comment: kept only the restructuring changes, the rest of
the code was moved to a separated patch since it is a bug fix (we weren't
checking sizes when the fb was the same)
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
[danvet: Fixup commit message mixup.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that universal planes are in place we don't need this plane unref on
failures.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Ville's comments:
- remove unnecessary plane check
- move mutex lock to inside the conditional
- make the pin fail message a debug one
- add a fixme for the fastboot hack
- call intel_frontbuffer_flip() after FBC update
v3: take more Ville's comments:
- fold update code under if (intel_crtc->active), and do the
visible/!visible split inside.
- check ret inside the same conditional we assign it
v4: don't use intel_enable_primary_hw_plane(), the primary_enabled
check inside will break page flips
v5: take more Ville's comments:
- set primary_enabled to true and add BDW hack
- unify if (old_fb) and if (old_fb != fb)
v6: take more Ville's comments:
- make was_primary bool and fix its check
- add the BDW vblank wait comment
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The quality of being a ULT or ULX package doesn't tell anything across
generations and so a global IS_ULT() macro doesn't make much sense, esp.
as we're adding new products.
So, spell out which ULT/ULX SKUs we are talking about here, namely HSW
and BDW.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So I've sent the first pull request to Dave and I expect his request
for a merge tree any second now ;-)
More seriously I have some pending patches for 3.19 that depend upon
both trees, hence backmerge. Conflicts are all trivial.
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/intel_display.c
v2: Of course I've forgotten the fixup script for the silent conflict.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
On CHV the display DDC pins may be muxed to an alternate function if
there's no need for DDC on a specific port, which is the case for eDP
ports since there's no way to plug in a DP++ HDMI dongle.
This causes problems when trying to determine if the port is present
since the the DP_DETECTED bit is the latched state of the DDC SDA pin
at boot. If the DDC pins are muxed to an alternate function the bit
may indicate that the port isn't present.
To work around this look at the VBT as well as the DP_DETECTED bit
to determine if we should attempt registering an eDP port. Do this
only for ports B and C since port D doesn't support eDP (no PPS/BLC).
In theory someone could also wire up a normal DP port w/o DDC lines.
That would just mean that simple DP++ HDMI dongles wouldn't work
on such a port. With this change we would still fail to register
such DP ports. But let's hope no one wires their board in such a way,
and if they do we can extend the VBT checks to cover normal DP ports
as well.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84265
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move the duplicated DIV_ROUND_CLOSEST_ULL macro into the intel_drv.h
header file so that it can be shared between intel_display.c
and intel_panel.c.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-By: Joe Konno <joe.konno@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Double negations just parse harder. Also this allows us to ditch some
init code since clearing to 0 dtrt. Also ditch the assignment in
intel_pm_setup, that's not redundant since we do the assignement now
while setting up interrupts.
While at it do engage in a bit of OCD and wrap up the few lines of
setup/teardown code into little helper functions: intel_irq_fini for
cleanup and intel_irq_init_hw for hw setup.
v2: Use _install/_uninstall for the new wrapper function names as
Paulo suggested.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've decided to not move intel_display_port_power_domain because
that's just a hack in our design ...
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- fini goes with init, so call it intel_power_domains_fini. While
at it shovel some of the fini code that leaked out of it back in.
- give power_enabled functions the verb _is_ to make the meaning clearer.
Also use a __ prefix instead of _unlocked to really discourage users.
- rename runtime_pm_init/fini to enable/disable since that's what they do.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Another layer of indirection for just an lpt-only w/a is a bit
excessive. Reduce it.
This was added in
commit 7d708ee40a
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Apr 17 14:04:50 2013 +0300
drm/i915: HSW: allow PCH clock gating for suspend
Cc: Imre Deak <imre.deak@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Haswell and later silicon has added a new pixel replication register
to the pipe timings for each transcoder. Now in addition to the
DPLL_A_MD register for the pixel clock double, we also need to write
to the TRANS_MULT_n (0x6002c) register to double the pixel data. Writing
to the DPLL only double the pixel clock.
ver2: Macro name change from MULTIPLY to PIPE_MULTI. (Daniel)
ver3: Do not set pixel multiplier if transcoder is eDP (Ville)
ver4: Macro name change to PIPE_MULT and default else pixel_multiplier
Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Appease checkpatch and move one hunk back into the right
place that git am misplace!?]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SKL stage 1 patches still need polish so will likely miss the 3.18
merge window. We've decided to postpone to 3.19 so let's pull this in
to make patch merging and conflict handling easier.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This reverts commit c76bb61a71.
It's apparently too broken so that Rodrigo submitted a patch to add a
config option for it. Given that the design is also ... suboptimal and
that I've only merged this to get lead engineers and managers off my
back for one second let's just revert this.
/me puts on combat gear again
It was worth a shot ...
References: http://mid.mail-archive.com/1411686380-1953-1-git-send-email-rodrigo.vivi@intel.com
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daisy Sun <daisy.sun@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Let's put to good use the new PLANE_CTL macros.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Set gen 9 function pointers for eld write and global resource.
Implementation remains same as HSW.
v2: Rebase on top of Sonika's untangling of the if/else ladder (Damien)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pipe misc programming in gen9 is similar to BDW. Extending the BDW
implementation to gen 9.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the platform doesn't have a FDI link, don't try to read out the
state of a potential PCH transcoder.
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Don't open-code HAS_FDI if there's only one place that needs
it. Acked by Damien on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Rebase on top of the intel_crt_present() addition
v3: Fix rebase error (we were patching the wrong function)
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Skylake makes primary planes the same as sprite planes and call the
result "universal planes".
This commit emulates a primary plane with plane 0, taking the
opportunity to redefine primary and sprite registers to be identical now
that the underlying hardware is. It also makes sense as plenty of fields
have changed.
v2: Rebase on top of the vma code.
v3: Follow upstream evolution:
- Drop return values.
- Remove pipe checks since redudant and BUG instead.
- Remove tiling checks and BUG instead.
- Drop commented out DISP_MODIFY usage.
v4: s/plane/primary_plane/
v5: Misc fixes:
- Fix the fields we need to clear up
- Disable trickle feed
- Correctly use PLANE_OFFSET for the panning
v6: (Jesse)
Use pipe src size when programming plane size. This makes cloned configs
work correctly w/o the use of a panel fitter.
v7: Rebase on top of Ville's rmw elimination series
v8: Remove clearing the trickle feed bit now that we don't do a RMW (Rodrigo,
Damien)
Add a comment about the stride unit (Rodrigo)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1,5,6,7)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2,3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Also align X tiled fbs to 256KB (Thomas)
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I shouldn't ask everyone to do this and fail myself ...
This extracts all the frontbuffer tracking functions into
intel_frontbuffer.c, adds a DOC overview section and also adds the
missing kerneldoc for i915_gem_track_fb and also pulls it into the
same section for convenience.
v2: Don't forget about the header files.
v3: Oops, might check compilation next time around. To make my life
easier drop the increase_pllclock from set_base_atomic since really,
it doesn't matter if you see your Oops or kgdb with a tiny bit of lag.
v4: Try to better explain how to actually use this, requested by Paulo
on irc.
v5: Explain invalidate/flush a bit clearer.
v6: s/business/busyness/
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The ->queue_flip callback is always called from process context, so
plain _irq spinlock variants are enough.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only one place looked in need of a bit of polish: hsw_restore_lcpll.
It's used by the runtime pm code and hence is always called from
process context. No irq flag saving required.
Another thing I've stumbled over is that we might need to add a
raw forcewake_get/put helpers which don't grab a runtime pm reference
but just check that the device isn't suspended - we have this duplicated
in the execlist code, too.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now we tackle the functions also called from interrupt handlers.
- intel_check_page_flip is exclusively called from irq handlers, so a
plain spin_lock is all we need. In i915_irq.c we have the convention
to give all such functions an _irq_handler postfix, but that would
look strange and als be a bit a misleading name. I've opted for a
WARN_ON(!in_irq()) instead.
- The other two places left are called both from interrupt handlers
and from our reset work, so need the full irqsave dance. Annotate
them with a short comment.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's good practice to use the more specific versions for irq save
spinlocks both as executable documentation and to enforce saner
design. The _irqsave version really should only be used if the calling
context is unknown and there's a good reason to call a function from
all kinds of places.
This is the first step whice replaces all occurances of _irqsave in
process context with the simpler irq disable/enable variants. We don't
have any funky spinlock nesting going on, especially since the
event_lock is the outermost of the irq/vblank related spinlocks.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We changed to an interrupt based vblank wait (as opposed to polling)
in:
commit 44bd93a3d367913d883be6abba9a6e51a53c4e90
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 25 23:36:44 2014 +0200
drm/i915: Use generic vblank wait
However we already had vblank waits on the wrong side of
drm_vblank_{on,off}() calls due to various workarounds, so now we get
a warning more or less every time we do a modeset, and we fail to
wait for the vblank like we should.
Move the drm_vblank_{on,off}() calls back out from
intel_crtc_{enable,disable}_planes() so that all of these vblank waits
return to proper operation. Also move the cxsr wait a bit earlier so
that we can keep the encoder disable after we've turned off vblanks.
Moving stuff out from the plane enable/disable functions seems
preferrable to moving the workaround stuff in since the workarounds are
required only on specific platforms.
While at it switch over to the drm_crtc_ variants of the vblank on/off
functions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82525
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82490
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Requested by Chris, and also requested to keep it since it's a
more accurate name in his opinion.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has the upside that it will no longer steal interrupts from the
interrupt handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.
v2: Adjust to the new names.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems cleaner if we keep CURCNTR at 0 when the cursor is disabled,
so don't set the CURSOR_PIPE_CSC_ENABLE bit unless the cursor is
enabled.
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>
To make the code a bit more undestandable move the
intel_crtc->cursor_base assignment into the low level update cursor
routines. That's were we compare the current value with the new one
so immediately seeing that it gets assigned only afterwards helps
one to understand that it gets assigned only after the comparison.
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>
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.
This will help refactor the update primary plane path.
v2: use struct intel_crtc as argument to intel_update_pipe_size()
v3: use 'crtc' as argument name
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The !crtc->enabled case will now be handled by the !visible code,
since the handling is basically the same.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As a preparation for atomic updates we need to split the code to check
everything we are going to commit first. This patch starts the work to
split intel_primary_plane_setplane() into check() and commit() parts.
More work is expected on this to get a better split of the two steps.
Ideally the commit() step should never fail.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
The commit part can still fail, but that should be solved in another
upcoming patch.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_send_vblank_event() demands that we hold the event spinlock whilst
calling it, so do so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fix the double lock as requested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The spec says:
"For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata,
GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31
(DPLL VCO Enable) and Bit 30 (2X Clock Enable) must be set to “1” in
both the DPLL A Control Register (06014h-06017h) and DPLL B Control
Register (06018h-0601Bh)."
The pipe A and B force quirks take care of DPLL_VCO_ENABLE, so we
just need a bit of special care to handle DPLL_DVO_2X_MODE.
v2: Recompute num_dvo_pipes on the spot, use PIPE_A/PIPE_B instead
of pipe/!pipe for the register offsets in disable (Daniel)
Add a comment about the ordering in enable and another one
about filtering out the DVO 2x bit in state readout
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- final bits (again) for the rotation support (Sonika Jindal)
- support bl_power in the intel backlight (Jani)
- vdd handling improvements from Ville
- i830M fixes from Ville
- piles of prep work all over to make skl enabling just plug in (Damien, Sonika)
- rename DP training defines to reflect latest edp standards, this touches all
drm drivers supporting DP (Sonika Jindal)
- cache edids during single detect cycle to avoid re-reading it for e.g. audio,
from Chris
- move w/a for registers which are stored in the hw context to the context init
code (Arun&Damien)
- edp panel power sequencer fixes, helps chv a lot (Ville)
- piles of other chv fixes all over
- much more paranoid pageflip handling with stall detection and better recovery
from Chris
- small things all over, as usual
* tag 'drm-intel-next-2014-09-05' of git://anongit.freedesktop.org/drm-intel: (114 commits)
drm/i915: Update DRIVER_DATE to 20140905
drm/i915: Decouple the stuck pageflip on modeset
drm/i915: Check for a stalled page flip after each vblank
drm/i915: Introduce a for_each_plane() macro
drm/i915: Rewrite ABS_DIFF() in a safer manner
drm/i915: Add comments explaining the vdd on/off functions
drm/i915: Move DP port disable to post_disable for pch platforms
drm/i915: Enable DP port earlier
drm/i915: Turn on panel power before doing aux transfers
drm/i915: Be more careful when picking the initial power sequencer pipe
drm/i915: Reset power sequencer pipe tracking when disp2d is off
drm/i915: Track which port is using which pipe's power sequencer
drm/i915: Fix edp vdd locking
drm/i915: Reset the HEAD pointer for the ring after writing START
drm/i915: Fix unsafe vma iteration in i915_drop_caches
drm/i915: init sprites with univeral plane init function
drm/i915: Check of !HAS_PCH_SPLIT() in PCH transcoder funcs
drm/i915: Use HAS_GMCH_DISPLAY un underrun reporting code
drm/i915: Use IS_BROADWELL() instead of IS_GEN8() in forcewake code
drm/i915: Don't call gen8_fbc_sw_flush() on chv
...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUFjfVAAoJEHm+PkMAQRiGANkIAIU3PNrAz9dIItq8a/rEAhnx
l2shHoOyEmyNR2apholM3BPUNX50cbsc/HGdi7lZKLkA/ifAj6B9nFD2NzVsIChD
1QWVcvdkKlVuxXCDd26qbijlfmbTOAWrLw9ntvM+J6ZtECM6zCAZF4MAV/FwogPq
ETGKD76AxJtVIhBMS99troAiC1YxmQ7DKgEr8CraTOR1qwXEonnPCmN/IZA6x2/G
EXiihOuQB5me1X7k4PI0V8CDscQOn+3B2CQHIrjRB+KiTF+iKIuI8n6ORC6bpFh+
U8UZP9wLlIG1BrUHG83pIndglIHotqPcjmtfl1WGrRr2hn7abzVSfV+g5Syo3Vg=
=Ep+s
-----END PGP SIGNATURE-----
drm: backmerge tag 'v3.17-rc5' into drm-next
This is requested to get the fixes for intel and radeon into the
same tree for future development work.
i915_display.c: fix missing dev_priv conflict.
Dave asked me to do the backmerge before sending him the revised pull
request, so here we go. Nothing fancy in the conflicts, just a few
things changed right next to each another.
Conflicts:
drivers/gpu/drm/drm_irq.c
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
If we successfully confuse the hardware, and cause it to drop a queued
pageflip, we wait for 60s and issue a warning before continuing on with
the modeset. However, this leaves the pending pageflip still stuck
indefinitely. Pretend to userspace that it does complete, and let us
start afresh following the modeset.
v2: Rebase after refactor
v3: Rebase, rebase.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=82612
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to display continuously updating information 24/7, and so
some code to detect when the driver missed the page flip completion
signal was added. Until recently, it was presumed that the interrupt
handling was now flawless, but once again Simon Farnsworth has found a
system whose display will stall. Reinstate the pageflip stall detection,
which works by checking to see if the hardware has been updated to the
new framebuffer address following each vblank. If the hardware is
scanning out from the new framebuffer, but we still think the flip is
pending, then we kick our driver into submision.
This is a continuation of the effort started with
commit 4e5359cd05
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date: Wed Sep 1 17:47:52 2010 +0100
drm/i915: Avoid pageflipping freeze when we miss the flip prepare interrupt
This now includes a belt-and-braces approach to make sure the driver
(or the hardware) doesn't miss an interrupt and cause us to stop
updating the display should the unthinkable happen and the pageflip fail - i.e.
that the user is able to continue submitting flips.
v2: Cleanup, refactor, and rename
v3: Only start counting vblanks after the flip command has been seen by
the hardware.
v4: Record the seqno after we touch the ring, or else there may be no
seqno allocated yet.
v5: Rebase on mmio-flip.
v6: Rebase, rebase.
Reported-by: Simon Farnsworth <simon@farnz.org.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [v4]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduce a new mutex (pps_mutex) to protect the power sequencer
state. For now this state includes want_panel_vdd as well as the
power sequencer registers.
We need a single mutex (as opposed to per port) because later on we
will need to deal with VLV/CHV which have multiple power sequencer
which can be reassigned to different ports.
v2: Add the locking to intel_dp_encoder_suspend too (Imre)
v3: Take care intel_edp_backlight_power() and
_intel_edp_backlight_on/off(), deal with reboot notifier
vlv_power_sequencer_pipe() call (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Check for !HAS_PCH_SPLIT() instead of 'gen < 5' in the PCH transcoder
enable functions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few open coded HAS_GMCH_DISPLAY() remain in the underrun reporting
code. Convert them over.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV doesn't have FBC, so don't go calling gen8_fbc_sw_flush() on it.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a FIXME comment while at it that we should rework this a
lot more.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, CHV is using the same functions as HSW/BDW instead of the
same functions as VLV. This looks wrong, especially since, for
example, valleyview_modeset_global_resouces even has an IS_CHERRYVIEW
check.
This patch has the potential to fix display audio and the CHV CDCLK.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My Fujistsu-Siemens Lifebook S6010 doesn't like to resume from
S3 unless VGACNTR has been restore to the original value. The BIOS
value in this case was 0x0124008E. Setting the "VGA disable" bit
doesn't interfere with the S3 resume fortunately.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
830M has problems when some of the pipes are disabled. Namely if a
plane, DVO port etc. is currently assigned to a disabled pipe, it
can't moved to the other pipe until the current pipe is also enabled.
To keep things simple just leave both pipes running all the time.
Ideally I think should turn the pipes off if neither is active, and
when either becomes active we enable both. But that would reuquire
proper atomic modeset support, and probably a bit of extra care in
the order things get enabled.
v2: Reorder wrt. double wide handling changes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
830 really does want the pipe A quirk. The planes and ports don't
react to any register writes unless the pipe currently attached
to them is running, so it's impossible to move them to the other
pipe unless both pipes are running.
Also it's documented that the DPLL must be enabled on both pipes
whenever it's needed.
This reverts commit ac6696d3236bd61503f89a1a99680fd7894d5d53.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Disable double wide even if the pipe quirk compels us to leave the
pipe running. Double wide has certain implications for the plane
assignments so best keep it off.
Also helps resuming from S3 on the Fujitsu-Siemens Lifebook S6010
when double wide was enabled prior to suspend.
We do leave the pixel clock ticking at the original rate which would
require double wide to be enabled. But since the planes are all disabled
I'm hoping that the overly fast clock won't cause any problems. Seems
to be fine so far.
v2: Disable double wide also when turning the pipe off
v3: Reorder wrt. force pipe B quirk
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just pass the intel_crtc around instead of dev_priv+pipe.
Also make intel_wait_for_pipe_off() static since it's only used in
intel_display.c.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At this point of the code the obj var is already NULL, so we don't
need to set it again to NULL.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BDW supports GT C0 residency reporting in constant time unit. Driver
calculates GT utilization based on C0 residency and adjusts RP
frequency up/down accordingly. For offscreen workload specificly,
set frequency to RP0.
Offscreen task is not restricted by frame rate, it can be
executed as soon as possible. Transcoding and serilized workload
between CPU and GPU both need high GT performance, RP0 is a good
option in this case. RC6 will kick in to compensate power
consumption when GT is not active.
v2: Rebase on recent drm-intel-nightly
v3: Add flip timerout monitor, when no flip is deteced within
100ms, set frequency to RP0.
Signed-off-by: Daisy Sun <daisy.sun@intel.com>
[torourke: rebased on latest and resolved conflict]
Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the pixel_size we got from drm_format_plane_cpp() instead of
fb->bits_per_pixel/8 when computing the primary plane page/linear
offsets. Avoids a few divs and makes the code more future proof
against funky pixel formats where bits_per_pixel isn't well defined.
This is what we already did in the sprite code.
Note that the relevant sprite patch was
commit ca320ac456
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Dec 19 12:14:22 2012 +0000
drm/i915: Use pixel size for computing linear offsets into a sprite
This change was required on sprites because they support yuv formats
which have fb->bits_per_pixel undefined.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add Chris' software archeology as a note to the commit
message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During driver init we may not have a valid framebuffer for the primary
plane even though the plane is enabled due to failed BIOS fb takeover.
This means we have to avoid dereferencing the fb in
.update_primary_plane() when disabling the plane.
The introduction of the primary plane rotation in
commit d91a2cb8e5104233c02bbde539bd4ee455ec12ac
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Fri Aug 22 14:06:04 2014 +0530
drm/i915: Add 180 degree primary plane rotation support
caused a regression by trying to look up the pixel format before we can
be sure there's a valid fb available. This isn't entirely unsurprising
since the rotation patches originally predate the change to the primary
plane code that calls .update_primary_plane() also when disabling the
plane:
commit fdd508a641
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Aug 8 21:51:11 2014 +0300
drm/i915: Call .update_primary_plane in intel_{enable,
disable}_primary_hw_plane()
v2: Warn but don't blow up when trying to enable a plane w/o an fb (Chris)
Cc: Sonika Jindal <sonika.jindal@intel.com>
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>
According to spec FBC on BDW and HSW are identical without any gaps.
So let's copy the nuke and let FBC really start compressing stuff.
Without this patch we can verify with false color that nothing is being
compressed. With the nuke in place and false color it is possible
to see false color debugs.
Unfortunatelly on some rings like BCS on BDW we have to avoid Bits 22:18 on
LRIs due to a high risk of hung. So, when using Blt ring for frontbuffer rend
cache would never been cleaned and FBC would stop compressing buffer.
One alternative is to cache clean on software frontbuffer tracking.
v2: Fix rebase conflict.
v3: Do not clean cache on BCS ring. Instead use sw frontbuffer tracking.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix assert_panel_unlocked for vlv/chv, and improve it a bit for
non-LVDS. Also don't pretend it works for DDI. There's still work to do
to get this right for eDP on PCH platforms, but this is a start.
v2: WARN_ON(HAS_DDI)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the correct mask for the unlock bits. In theory this could have lead
to incorrect asserts but this is unlikely in practise.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Be sure to always flush a stuck pageflip even if we couldn't possibly
expect one to be there.
References: https://bugs.freedesktop.org/show_bug.cgi?id=82612
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>
Improve the debug message that tells us we've been waiting for a vblank
that never arrived. Printing the pipe could lead a "doh!" moment where
we've been waiting for a vblank on a pipe that was off for instance.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
[danvet: Polish commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris has decided that enough is enough. It's time to fixup dev Vs
dev_priv. This is a modest contribution to the crusade.
v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
the info struct with defines (Chris)
Rename the macro argument from 'dev' to 'dev_priv' (Jani)
v3: Use names unlikely to be used as macro arguments (Chris)
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.
v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
crtc->primary->fb and return value of update_primary_plane is ignored.
v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to
drm_mode_config, so drm layer will take care of resetting. Adding updation of
fbc when rotation is set to 0. Allowing rotation only if value is
different than old one.
v10: Calling intel_primary_plane_setplane instead of update_primary_plane in
set_property(Daniel).
v11: Using same set_property function for both primary and sprite, Adding
primary plane specific code in the same function (Matt).
v12: Removing disabling/ enabling of fbc from set_property because it is done
from intel_pipe_set_base. Other formatting
v13: we need to call disable_fbc before changing the rotation to 180,
disable_fbc from intel_pipe_set_base gets called very late, that will
be used to re-enable fbc if rotation is set to 0 (Ville).
Testcase: igt/kms_rotation_crc
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
[danvet: Add FIXME to explain why we need the open-coded update_fbc
hunk to disable fbc when rotated 180 degree. And make checkpatch
happier.]
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This unifies how the primary plane functions work with how the sprite
functions works, which allows us to reuse them to update primary plane
properties.
v2: Moving setting of plane members in the end to take care of failure cases and
not-visible cases (Matt).
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
[danvet: Add a real commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm-intel-next-2014-08-22:
- basic code for execlist, which is the fancy new cmd submission on gen8. Still
disabled by default (Ben, Oscar Mateo, Thomas Daniel et al)
- remove the useless usage of console_lock for I915_FBDEV=n (Chris)
- clean up relations between ctx and ppgtt
- clean up ppgtt lifetime handling (Michel Thierry)
- various cursor code improvements from Ville
- execbuffer code cleanups and secure batch fixes (Chris)
- prep work for dev -> dev_priv transition (Chris)
- some of the prep patches for the seqno -> request object transition (Chris)
- various small improvements all over
* tag 'drm-intel-next-2014-09-01' of git://anongit.freedesktop.org/drm-intel: (86 commits)
drm/i915: fix suspend/resume for GENs w/o runtime PM support
drm/i915: Update DRIVER_DATE to 20140822
drm: fix plane rotation when restoring fbdev configuration
drm/i915/bdw: Disable execlists by default
drm/i915/bdw: Enable Logical Ring Contexts (hence, Execlists)
drm/i915/bdw: Document Logical Rings, LR contexts and Execlists
drm/i915/bdw: Print context state in debugfs
drm/i915/bdw: Display context backing obj & ringbuffer info in debugfs
drm/i915/bdw: Display execlists info in debugfs
drm/i915/bdw: Disable semaphores for Execlists
drm/i915/bdw: Make sure gpu reset still works with Execlists
drm/i915/bdw: Don't write PDP in the legacy way when using LRCs
drm/i915: Track cursor changes as frontbuffer tracking flushes
drm/i915/bdw: Help out the ctx switch interrupt handler
drm/i915/bdw: Avoid non-lite-restore preemptions
drm/i915/bdw: Handle context switch events
drm/i915/bdw: Two-stage execlist submit process
drm/i915/bdw: Write the tail pointer, LRC style
drm/i915/bdw: Implement context switching (somewhat)
drm/i915/bdw: Emission of requests with logical rings
...
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
Somehow the intel_ddi_set_vc_payload_alloc(false) call has ended up
in ironlake_crtc_disable() rather than haswell_crtc_disable(). Move it
to the correct place.
intel_ddi_disable_transcoder_func() already disables the vc payload
allocation so this doesn't actually do anything more. The spec
says we should wait for some kind of ack after frobbing the bit. We
don't appear to do that currently, but if and when someone decides
that we should do it, intel_ddi_set_vc_payload_alloc() would appear
to be be the right place for it. So having the function call in
haswell_crtc_disable() seems like the right thing for the future
even if it does nothing currently.
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If we're runtime suspended and try to use the plane interfaces, we
will get a lot of WARNs saying we did the wrong thing.
We need to get runtime PM references to pin the objects, and to
change the fences. The pin functions are the ideal places for
this, but intel_crtc_cursor_set_obj() doesn't call them, so we also
have to add get/put calls inside it. There is no problem if we runtime
suspend right after these functions are finished, because the
registers written are forwarded to system memory.
Note: for a complete fix of the cursor-dpms test case, we also need
the patch named "drm/i915: Don't try to enable cursor from setplane
when crtc is disabled".
v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
v3: - Make get/put also surround the fence and unpin calls (Daniel and
Ville).
- Merge all the plane changes into a single patch since they're
the same fix.
- Add the comment requested by Daniel.
v4: - Remove spurious whitespace (Ville).
v5: - Remove intel_crtc_update_cursor() chunk since Ville did an
equivalent fix in another patch (Ville).
v6: - Remove unpin chunk: it will be on a separate patch (Ville,
Chris, Daniel).
v7: - Same thing, new color.
Testcase: igt/pm_rpm/cursor
Testcase: igt/pm_rpm/cursor-dpms
Testcase: igt/pm_rpm/legacy-planes
Testcase: igt/pm_rpm/legacy-planes-dpms
Testcase: igt/pm_rpm/universal-planes
Testcase: igt/pm_rpm/universal-planes-dpms
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82603
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
commit c675949ec5
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Apr 9 11:31:37 2014 +0300
drm/i915: do not setup backlight if not available according to VBT
prevents backlight setup on the Acer C720 (Core i3 4005U CPU), which has a
misconfigured VBT. Apply quirk to ignore the VBT backlight presence check
during backlight setup.
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Tested-by: Tyler Cleveland <siralucardt@openmailbox.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (3.15+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
- Setting dp M2/N2 values plus state checker support (Vandana Kannan)
- chv power well support (Ville)
- DP training pattern 3 support for chv (Ville)
- cleanup of the hsw/bdw ddi pll code, prep work for skl (Damien)
- dsi video burst mode support (Shobhit)
- piles of other chv fixes all over (Ville et. al.)
- cleanup of the ddi translation tables setup code (Damien)
- 180 deg rotation support (Ville & Sonika Jindal)
* tag 'drm-intel-next-2014-08-08' of git://anongit.freedesktop.org/drm-intel: (59 commits)
drm/i915: Update DRIVER_DATE to 20140808
drm/i915: No busy-loop wait_for in the ring init code
drm/i915: Add sprite watermark programming for VLV and CHV
drm/i915: Round-up clock and limit drain latency
drm/i915: Generalize drain latency computation
drm/i915: Free pending page flip events at .preclose()
drm/i915: clean up PPGTT checking logic
drm/i915: Polish the chv cmnlane resrt macros
drm/i915: Hack to tie both common lanes together on chv
drm/i915: Add cherryview_update_wm()
drm/i915: Update DDL only for current CRTC
drm/i915: Parametrize VLV_DDL registers
drm/i915: Fill out the FWx watermark register defines
drm: Resetting rotation property
drm/i915: Add rotation property for sprites
drm: Add rotation_property to mode_config
drm/i915: Make intel_plane_restore() return an error
drm/i915: Add 180 degree sprite rotation support
drm/i915: Introduce a for_each_intel_encoder() macro
drm/i915: Demote the DRRS messages to debug messages
...
Make sure these work handlers don't run after we system suspend or
unload the driver. Note that we don't cancel the handlers during runtime
suspend. That could lead to a lockup, since we take a runtime PM ref
from the handlers themselves. Fortunaltely canceling there is not needed
since the RPM ref itself provides for the needed serialization.
v2:
- fix the order of canceling dig_port_work wrt. hotplug_work (Ville)
- zero out {long,short}_hpd_port_mask and hpd_event_bits for speed
(Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org (3.16+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.
Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling the timer during runtime suspend, since the only important
thing there is that the HW is awake when we write the registers and
that's ensured by the RPM ref. So do the cancelation only during driver
unload time; this is also a requirement for an upcoming patch where we
want to cancel all HPD related works only during system suspend and
driver unload time, but not during runtime suspend.
Note that there is still a race between the HPD IRQ reenable work and
drm_irq_uninstall() during driver unload, where the work can reenable
the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since
the HPD IRQs will still be effectively masked by the first level
interrupt mask.
v2-3:
- unchanged
v4:
- use proper API for changing the expiration time for an already pending
delayed work (Jani)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
Cc: stable@vger.kernel.org (3.16+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Make sure the cursor gets fully clipped when enabling it on a disabled
crtc via setplane. This will prevent the lower level code from
attempting to enable the cursor in hardware.
Cc: Paulo Zanoni <przanoni@gmail.com>
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>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During suspend we turn off the crtcs, but leave the staged config in
place so that we can restore the display(s) to their previous state on
resume.
During resume when we attempt to apply the force pipe A quirk we use the
load detect mechanism. That doesn't check whether there was an already
staged configuration for the crtc since that's not even possible during
normal runtime load detection. But during resume it is possible, and if
we just blindly go and overwrite the staged crtc configuration for the
load detection we can no longer restore the display to the correct
state.
Even worse, we don't even clear all the staged connector->encoder->crtc
links so we may end up using a cloned setup for the load detection, and
after we're done we just clear the links related to the VGA output
leaving the links for the other outputs in place. This will eventually
result in calling intel_set_mode() with mode==NULL but with valid
connector->encoder->crtc links which will result in dereferencing the
NULL mode since the code thinks it will have to a modeset.
To avoid these problems don't use any crtc with new_enabled==true for
load detection.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (for 3.16)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
intel_enable_pipe_a() gets called with all the modeset locks already
held (by drm_modeset_lock_all()), so trying to grab the same
locks using another drm_modeset_acquire_ctx is going to fail miserably.
Move most of the drm_modeset_acquire_ctx handling (init/drop/fini)
out from intel_{get,release}_load_detect_pipe() into the callers
(intel_{crt,tv}_detect()). Only the actual locking and backoff
handling is left in intel_get_load_detect_pipe(). And in
intel_enable_pipe_a() we just share the mode_config.acquire_ctx from
drm_modeset_lock_all() which is already holding all the relevant locks.
It's perfectly legal to lock the same ww_mutex multiple times using the
same ww_acquire_ctx. drm_modeset_lock() will convert the returned
-EALREADY into 0, so the caller doesn't need to do antyhing special.
Fixes a hang on resume on my 830.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We treat other plane updates in the same fashion. Spotted because
Rodrigo kept reporting a bug in the PSR code where the frontbuffer was
eternally stuck with a dirty cursor bit set.
The psr testcase should have caught this, but that i-g-t is kaputt.
Rodrigo is signed up to fix that.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by-and-Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
845/865 support different cursor sizes as well, albeit a bit differently
than later platforms. Add the necessary code to make them work.
Untested due to lack of hardware.
v2: Warn but accept invalid stride (Chris)
Rewrite the cursor size checks for other platforms (Chris)
v3: More polish and magic to the cursor size checks (Chris)
v4: Moar polish and a comment (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ever since
commit 5efb3e2838
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Apr 9 13:28:53 2014 +0300
drm/i915/chv: Add cursor pipe offsets
the only difference between i9xx_update_cursor() and ivb_update_cursor()
was the hsw+ pipe csc handling. Let's unify them and we can rid
outselves of some duplicated code.
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>
CURSIZE register exists on 845/865 only, so move it to
i845_update_cursor(). Changes to cursor size must be done only when the
cursor is disabled, so do the write just before enabling the cursor.
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>
Make sure the cursor gets fully clipped when enabling it on a disabled
crtc via setplane. This will prevent the lower level code from
attempting to enable the cursor in hardware.
Cc: Paulo Zanoni <przanoni@gmail.com>
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>
The normal flip function places things in the ring in the legacy
way, so we either fix that or force MMIO flips always as we do in
this patch.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Checkpatch. Fucking again.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Removing the check for HAS_PCH_SPLIT, it looks redundant here. Anyways all the
platforms are checked separately.
v2: Reordering as per the gen (Ville)
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make the intel_{enable,disable}_primary_hw_plane() simply call
.update_primary_plane(), thus eliminating the rmw from these functions
which should help the poor old 830M.
Now we can also remove the .update_primary_plane() from the
.crtc_enable() hooks because we end up calling it via
intel_crtc_enable_planes()->intel_enable_primary_hw_plane().
This also has the nice benefit of making primary planes a bit closer to
the way we handle sprite planes during modesets.
v2: Just write 0 to DSPCNTR and DSPSURF/DSPADDR if the plane is (to be)
disabled. Quicker, and more importantly avoids an oops when fb==NULL
due to BIOS fb takeover failure.
Pimp the commit message a bit (Matt)
v3: Drop useless primary_enabled checks when setting DISPLAY_PLANE_ENABLE
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the entire DSPCNTR register setup into the .update_primary_plane()
functions. That's where it belongs anyway and it'll also help 830M which
has the extra problem that plane registers reads will return the value
latched at the last vblank, not the value that was last written.
Also move DSPPOS and DSPSIZE setup there.
v2: Don't move variable initialization to avoid churn later
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If there are pending page flips when the fd gets closed those page
flips may have events associated to them. When the page flip eventually
completes it will queue the event to file_priv->event_list, but that
may be too late and file_priv->event_list has already been cleaned up.
Thus we leak a bit of kernel memory in the form of the event structure.
To avoid such problems clear out such pending events from
intel_crtc->unpin_work at ->preclose(). Any event that already made it
to file_priv->event_list will get cleaned up by the drm_release_events()
a bit later.
We can ignore the file_priv->event_space accounting since file_priv is
going away. This is already how drm core deals with pending vblank
events, which are maintained by the drm core.
What saves us from a total disaster (ie. dereferencing and alrady
freed file_priv) is the fact that the fb descruction triggers a modeset
and there we wait for pending flips.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Following the established idom, let's provide a macro to iterate through
the encoders.
spatch helps, once more, for the substitution:
@@
iterator name list_for_each_entry;
iterator name for_each_intel_encoder;
struct intel_encoder * encoder;
struct drm_device * dev;
@@
-list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head) {
+for_each_intel_encoder(dev, encoder) {
...
}
I also modified a few call sites by hand where a pointer to mode_config
was directly used (to avoid overflowing 80 chars).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Wrap paramters correctly in the macro and remove spurious
space checkpatch noticed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We enable the DPLL refclock already when bringing up the cmnlane power
well, so also leave it on when otherwise disabling the DPLL.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Punit seems a bit WIP still. Disable cdclk changes until we have
hardware where it works.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks like the Punit is supposed to support the 400MHz cdclk directly on
chv, so we don't need the vlv tricks.
FIXME: Punit doesn't seem ready for this yet on current hw
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to the specifications bit 6 is actually valid in the stride register.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both VLV and CHV handle the cmnreset stuff in the power well code now,
so intel_reset_dpio() is no longer needed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Share the waitqueue that drm_irq uses when performing the vblank evade
trick for atomic pipe updates.
v2: Keep intel_pipe_handle_vblank() (Chris)
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adding relevant read out comparison code, in check_crtc_state, for the new
member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
values for a DP downclock mode (if available). Suggested by Daniel.
v2: Changed patch title.
Daniel's review comments incorporated.
Added relevant state readout code for M2_N2. dp_m2_n2 comparison to be done
only when high RR is not in use (This is because alternate m_n register
programming will be done only when low RR is being used).
v3: Modified call to get_m2_n2 which had dp_m_n as param by mistake.
Compare dp_m_n and dp_m2_n2 for gen 7 and below. compare the structures
based on DRRS state for gen 8 and above.
Save and restore M2 N2 registers for gen 7 and below
v4: For Gen>=8, check M_N registers against dp_m_n and dp_m2_n2 as there is
only one set of M_N registers
v5: Removed the chunk which saves and restores M2_N2 registers. Modified
get_m_n() to get M2_N2 registers as well. Modified the macro which compares
hw.dp_m_n against sw.dp_m2_n2/sw.dp_m_n for gen > 8.
v6: Added check to compare dp_m2_n2 only when DRRS is enabled
v7: Modified drrs check to use has_drrs
v8: Add has_drrs check before reading M2_N2 registers
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For Gen < 8, set M2_N2 registers on every mode set. This is required to make
sure M2_N2 registers are set during boot, resume from sleep for cross-
checking the state. The register is set only if DRRS is supported.
v2: Patch rebased
v3: Daniel's review comments
- Removed HAS_DRRS(dev) and added bool has_drrs to pipe_config to
track drrs support
v4: Jesse's review comments
- Made changes to set m2_n2 in intel_dp_set_m_n()
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
It will not be enabled for DSI and avoid dpio read WARN dumps.
Absence of ->get_config was causing other WARN dumps as well. Update
dpll_hw_state as well correctly
v2: Address review comments by Daniel
- Check if DPLL is enabled rather than checking pipe output type
- set adjusted_mode->flags to 0 in compute_config rather than using
pipe_config->quirks
- Add helper function in intel_dsi_pll.c and use that in intel_dsi.c
- updated dpll_hw_state correctly
- Updated commit message and title
v3: Address review comments by Imre
- Proper masking of P1, M1 fields while computing divisors
- assert in case of bpp mismatch
- guard for divide by 0 while computing pclk
- Use ARRAY_SIZE instead of direct calculation
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
update_scanline_offset() in intel_sanitize_crtc() was supposed to
be called only for active crtcs. But due to some underrun patches it
now gets updated for all crtcs on gmch platforms.
Move the update_scanline_offset() to the very beginning of
intel_sanitize_crtc() where we update the vblank state. This seems like
a better place anyway since the scanline offset ought to be up to date
before we might need to consult it. So before any vblanky stuff happens.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Drop the drm_vblank_off() (Daniel)
Use drm_crtc_vblank_{get,put}()
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull in drm-next with Dave's DP MST support so that I can merge some
conflicting patches which also touch the driver load sequencing around
interrupt handling.
Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we merged runtime PM support for DPMS, it is possible that these
assertions will be called when the power wells are disabled but a mode
is "set", resulting in "failed assertion" and "device suspended while
reading register" WARNs.
To reproduce the bug: disable all screens using mode unset, do a
modeset on one screen, disable it using DPMS, then try to do a mode
unset on it again to see the WARNs.
v2: The first version of this patch changed the assertions to also
check the power domains. Daniel suggested that it would be better to
just remove the assertions: "The modeset state checker
will already notice when we've failed to turn off the pipe. And we
check cursors and plane state in the enable sequence, too. Since we
use these asserts a lot to lock down the precise modeset sequence I
actually prefer if they're a bit dumb and don't check the power
wells."
Testcase: igt/rpm_rpm/dpms-mode-unset-lpsp
Testcase: igt/rpm_rpm/dpms-mode-unset-non-lpsp
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we use the runtime IRQ enable/disable functions in our suspend
path, we can simply check the pm._irqs_disabled flag everywhere. So
rename it to catch the users, and add an inline for it to make the
checks clear everywhere.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't write it, otherwise we will trigger unclaimed register
errors.
Testcase: igt/pm_rpm/rte
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>
I've tried to split this up, but all the changes are so tightly
related that I didn't find a good way to do this without breaking
bisecting. Essentially this completely changes how psr is glued into
the overall driver, and there's not much you can do to soften such a
paradigm change.
- Use frontbuffer tracking bits stuff to separate disable and
re-enable.
- Don't re-check everything in the psr work. We have now accurate
tracking for everything, so no need to check for sprites or tiling
really. Allows us to ditch tons of locks.
- That in turn allows us to properly cancel the work in the disable
function - no more deadlocks.
- Add a check for HSW sprites and force a flush. Apparently the
hardware doesn't forward the flushing when updating the sprite base
address. We can do the same trick everywhere else we have such
issues, e.g. on baytrail with ... everything.
- Don't re-enable psr with a delay in psr_exit. It really must be
turned off forever if we detect a gtt write. At least with the
current frontbuffer render tracking. Userspace can do a busy ioctl
call or no-op pageflip to re-enable psr.
- Drop redundant checks for crtc and crtc->active - now that they're
only called from enable this is guaranteed.
- Fix up the hsw port check. eDP can also happen on port D, but the
issue is exactly that it doesn't work there. So an || check is
wrong.
- We still schedule the psr work with a delay. The frontbuffer
flushing interface mandates that we upload the next full frame, so
need to wait a bit. Once we have single-shot frame uploads we can do
better here.
v2: Don't enable psr initially, rely upon the fb flush of the initial
plane setup for that. Gives us more unified code flow and makes the
crtc enable sequence less a special case.
v3: s/psr_exit/psr_invalidate/ for consistency
v4: Fixup whitespace.
v5: Correctly bail out of psr_invalidate/flush when
dev_priv->psr.enabled is NULL. Spotted by Rodrigo.
v6:
- Only schedule work when there's work to do. Fixes WARNINGs reported
by Rodrigo.
- Comments Chris requested to clarify the code.
v7: Fix conflict on rebase (Rodrigo)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v6)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV, after i915_pm_suspend display power wells are staying
power ungated. So, after initiating mem sleep "echo mem > /sys/power/state"
Display is staing D0 State. There might be better way/place to power gate
these wells. Also, we need to make sure that if wells are power gated due to
DPMS OFF sequence, they need not be turned off by i915_pm_suspend again.
v2: Extracted helper for intel_crtc_disable and power gating CRTC power wells.
[Daniel]
Cc: Imre Deak <imre.deak@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Change-Id: I34c80da66aa24c423a5576c68aa1f3a8d0f43848
Signed-off-by: Borun Fu <borun.fu@intel.com>
Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This adds DP 1.2 MST support on Haswell systems.
Notes:
a) this reworks irq handling for DP MST ports, so that we can
avoid the mode config locking in the current hpd handlers, as
we need to process up/down msgs at a better time.
Changes since v0.1:
use PORT_PCH_HOTPLUG to detect short vs long pulses
add a workqueue to deal with digital events as they can get blocked on the
main workqueue beyong mode_config mutex
fix a bunch of modeset checker warnings
acks irqs in the driver
cleanup the MST encoders
Changes since v0.2:
check irq status again in work handler
move around bring up and tear down to fix DPMS on/off
use path properties.
Changes since v0.3:
updates for mst apis
more state checker fixes
irq handling improvements
fbcon handling support
improved reference counting of link - fixes redocking.
Changes since v0.4:
handle gpu reset hpd reinit without oopsing
check link status on HPD irqs
fix suspend/resume
Changes since v0.5:
use proper functions to get max link/lane counts
fix another checker backtrace - due to connectors disappearing.
set output type in more places fro, unknown->displayport
don't talk to devices if no HPD asserted
check mst on short irqs only
check link status properly
rebase onto prepping irq changes.
drop unsued force_act
Changes since v0.6:
cleanup unused struct entry.
[airlied: fix some sparse warnings].
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- fbc improvements when stolen memory is tight (Ben)
- cdclk handling improvements for vlv/chv (Ville)
- proper fix for stuck primary planes on gmch platforms with cxsr (Imre&Ebgert
Eich)
- gen8 hw semaphore support (Ben)
- more execlist prep work from Oscar Mateo
- locking fixes for primary planes (Matt Roper)
- code rework to support runtime pm for dpms on hsw/bdw (Paulo, Imre & me), but
not yet enabled because some fixes from Paulo haven't made the cut
- more gpu boost tuning from Chris
- as usual piles of little things all over
* tag 'drm-intel-next-2014-07-11' of git://anongit.freedesktop.org/drm-intel: (93 commits)
drm/i915: Make the RPS interrupt generation mask handle the vlv wa
drm/i915: Move RPS evaluation interval counters to i915->rps
drm/i915: Don't cast a pointer to void* unnecessarily
drm/i915: don't read LVDS regs at compute_config time
drm/i915: check the power domains in intel_lvds_get_hw_state()
drm/i915: check the power domains in ironlake_get_pipe_config()
drm/i915: don't skip shared DPLL assertion on LPT
drm/i915: Only touch WRPLL hw state in enable/disable hooks
drm/i915: Switch to common shared dpll framework for WRPLLs
drm/i915: ->enable hook for WRPLLs
drm/i915: ->disable hook for WRPLLs
drm/i915: State readout support for WRPLLs
drm/i915: add POWER_DOMAIN_PLLS
drm/i915: Document that the pll->mode_set hook is optional
drm/i915: Basic shared dpll support for WRPLLs
drm/i915: Precompute static ddi_pll_sel values in encoders
drm/i915: BDW also has special-purpose DP DDI clocks
drm/i915: State readout and cross-checking for ddi_pll_sel
drm/i915: Move ddi_pll_sel into the pipe config
drm/i915: Add a debugfs file for the shared dpll state
...
commit 98ec77397a
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Apr 30 17:43:01 2014 +0300
drm/i915: Make primary_enabled match the actual hardware state
introduced more accurate tracking of the primary plane and some
checks. It missed the plane->pipe reassignement code for gen2/3
though, which the checks caught and resulted in WARNING backtraces.
Since we only use this path if the plane is on and on the wrong pipe
we can just always set the tracking bit to "enabled".
Reported-and-tested-by: Paul Bolle <pebolle@tiscali.nl>
Cc: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit c675949ec5
drm/i915: do not setup backlight if not available according to VBT
caused a regression on the HP Chromebook 14 (with Celeron 2955U CPU),
which has a misconfigured VBT. Apply quirk to ignore the VBT backlight
presence check during backlight setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Tested-by: Stefan Nagy <public@stefan-nagy.at>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV and CHV disable the DP port only in the .post_disable() hook, so we
need to make intel_sanitize_encoder() call that when it's trying to
disable encoders without an active pipes.
My bsw actaully hits this when an external display is connected. The
BIOS still likes to turn on the eDP port, but leaves the pipe disabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Remove now bogus comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like we already do in haswell_get_pipe_config(). This should
prevent some WARNs when we run pm_rpm on SNB.
Testcase: igt/pm_rpm
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80463
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we now have support for shared DPLLS.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To be able to do this we need to separately keep track of how many
crtcs need a given WRPLL and how many actually actively use it. The
common shared dpll framework already has all this, including massive
state readout and cross checking. Which allows us to do this switch in
a fairly small patch.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mostly this patch is one big excersize in deleting code and asserts
which are no longer needed. Note that we still abuse the shared dpll
framework a bit since we call the enable/disable functions from the
crtc mode_set and off hooks. But changing the actual hardware sequence
will be done in the next step.
Note that besides the massive amount of changes in this patch the
places and order in which the low-level WRPLL code is called is
absolutely unchanged.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently still with a redudant WARN_ON in there, the common shared
dpll code will take care of this in the future.
Also we need to flip the switch for the transitional hack now to make
sure that we disable the right pll.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Still tacked onto the side, but slowly getting there.
v2: Don't forget the debugfs file.
v3 (from Paulo): Don't forget to check the power domains.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And get/put it when needed. The special thing about this commit is
that it will now return false in ibx_pch_dpll_get_hw_state() in case
the power domain is not enabled. This will fix some WARNs we have when
we run pm_rpm on SNB.
Testcase: igt/pm_rpm
Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=80463
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just filing in names and ids, but not yet officially registering them
so that the hw state cross checker doesn't completely freak out about
them. Still since we do already read out and cross check
config->shared_dpll the basics are now there to flesh out the wrpll
shared dpll implementation.
The idea is now to roll out all the callbacks step-by-step and then at
the end switch to the shared dpll framework. This way hw and sw
changes are clearly separated.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[imre: added const to hsw_ddi_pll_names (Damien)]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To make things a bit more manageable extract a new function for
reading out common ddi port state. This means a bit of duplication
between encoders and the core since both look at the same registers,
but doesn't seem worth to make a fuzz about.
We can also remove the state readout code in intel_ddi_setup_hw_pll_state.
That code is only called from the hardware take over and not the cross
check code, and only after the crtc state is reconstructed. So we can
rely on an accurate value of crtc->config.ddi_pll_sel already.
Compared to the old code also trust the hw state more and don't
special-case port A - we want to cross-check the actual-state, not
bake in our own assumptions about how this is supposed to all be
linked up.
v2: Make use of the read-out ddi_pll_sel in intel_ddi_clock_get.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is needed by an upcoming patch that moves the PCH/CRT PLL disabling
into the post_disable hook, after which we want to keep the modeset
sequence at its current state. At this point this won't have an effect
since the PCH/CRT post_disable hook is atm a NOP.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is needed by an upcoming patch that moves the PCH/CRT PLL enabling
into the pre_enable hook, after which we want to keep the modeset
sequence at its current state. At this point this won't have an effect
since the PCH/CRT pre_enable hook is atm a NOP.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All the other checks also check hw state, so checking our software
refcounts for the plls looks a bit odd. Also this will simplify the
conversion over to the shared dpll framework, which itself has massive
amounts of checks to make sure that we never leave a display pll
enabled when we shouldn't.
So after that conversion we should stil have a good enough coverage of
asserts for entering pc8/runtime pm on hsw/bdw.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add !mutex_is_locked() checks to intel_pin_and_fence_fb_obj() and
intel_unpin_fb_obj() to help catch failures to grab struct_mutex when
operating on fb objects.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_primary_plane_{setplane,disable} were lacking struct_mutex locking
around their GEM operations.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reported-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On HSW, the D_COMP register can be accessed through the mailbox (read
and write) or through MMIO on a MCHBAR offset (read only). On BDW, the
access should be done through MMIO on another address. So to account
for all these cases, create hsw_read_dcomp() with the correct
implementation for reading, and also fix hsw_write_dcomp() to do the
correct thing on BDW.
With this patch, we can now get back from the PC8+ state on BDW. We
were previously getting a black screen and lots of dmesg errors.
Please notice that the bug only happens when you actually reach the
PC8+ states, not when you only allow it.
Testcase: igt/pm_rpm/rte
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That function can be used to write anything on D_COMP, not just
disable it, so print a more appropriate message.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should hopefully simplify the display code slightly and also
solves at least one mistake in intel_pipe_set_base() where
to_intel_framebuffer(fb)->obj is referenced during local variable
initialization, before 'if (!fb)' gets checked.
Potential uses of this macro were identified via the following
Coccinelle patch:
@@
expression E;
@@
* to_intel_framebuffer(E)->obj
@@
expression E;
identifier I;
@@
I = to_intel_framebuffer(E);
...
* I->obj
v2: Rewrite some NULL tests in terms of the obj rather than the fb.
Also add a WARN() if trying to pageflip with a disabled primary
plane. [Suggested by Chris Wilson]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Toshiba CB35 Chromebook (with Celeron 2955U CPU) has a controllable
backlight although its VBT reports otherwise. Apply quirk to ignore the
backlight presence check during backlight setup.
Patch tested by author on Toshiba CB35.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
CC: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org # 3.15 only
[danvet: Add cc: stable because the regressing commit is in 3.15.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Acer C720 and C720P Chromebooks (with Celeron 2955U CPU) have a
controllable backlight although their VBT reports otherwise. Apply quirk
to ignore the backlight presence check during backlight setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
Tested-by: James Duley <jagduley@gmail.com>
Tested-by: Michael Mullin <masmullin@gmail.com>
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
CC: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org # 3.15 only
[danvet: Add cc: stable because the regressing commit is in 3.15.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit c675949ec5
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Apr 9 11:31:37 2014 +0300
drm/i915: do not setup backlight if not available according to VBT
caused a regression on machines with a misconfigured VBT. Add a quirk to
assert the presence of a controllable backlight. Use it to ignore the VBT
backlight presence check during backlight setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
Tested-by: James Duley <jagduley@gmail.com>
Tested-by: Michael Mullin <masmullin@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org # 3.15 only
[danvet: Add cc: stable because the regressing commit is in 3.15.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and
flip events. This is prep work for proper PSR support and should also be
useful for DRRS&fbc.
- Runtime suspend hardware on system suspend to support the new SOix sleep
states, from Jesse.
- PSR updates for broadwell (Rodrigo)
- Universal plane support for cursors (Matt Roper), including core drm patches.
- Prefault gtt mappings (Chris)
- baytrail write-enable pte bit support (Akash Goel)
- mmio based flips (Sourab Gupta) instead of blitter ring flips
- interrupt handling race fixes (Oscar Mateo)
And old, not yet merged features from the previous round:
- rps/turbo support for chv (Deepak)
- some other straggling chv patches (Ville)
- proper universal plane conversion for the primary plane (Matt Roper)
- ppgtt on vlv from Jesse
- pile of cleanups, little fixes for insane corner cases and improved debug
support all over
* tag 'drm-intel-next-2014-06-20' of git://anongit.freedesktop.org/drm-intel: (99 commits)
drm/i915: Update DRIVER_DATE to 20140620
drivers/i915: Fix unnoticed failure of init_ring_common()
drm/i915: Track frontbuffer invalidation/flushing
drm/i915: Use new frontbuffer bits to increase pll clock
drm/i915: don't take runtime PM reference around freeze/thaw
drm/i915: use runtime irq suspend/resume in freeze/thaw
drm/i915: Properly track domain of the fbcon fb
drm/i915: Print obj->frontbuffer_bits in debugfs output
drm/i915: Introduce accurate frontbuffer tracking
drm/i915: Drop schedule_back from psr_exit
drm/i915: Ditch intel_edp_psr_update
drm/i915: Drop unecessary complexity from psr_inactivate
drm/i915: Remove ctx->last_ring
drm/i915/chv: Ack interrupts before handling them (CHV)
drm/i915/bdw: Ack interrupts before handling them (GEN8)
drm/i915/vlv: Ack interrupts before handling them (VLV)
drm/i915: Ack interrupts before handling them (GEN5 - GEN7)
drm/i915: Don't BUG_ON in i915_gem_obj_offset
drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info
drm/i915: Add some L3 registers to the parser whitelist
...
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
For whatever reason, MI_DISPLAY_FLIP fails to change tiling mode on
Baytrail, so just use CPU driven mmio flips instead.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76176
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently see random GPU hangs when using RCS flips with multiple
pipes on Ivybridge. Now that we have mmio flips, we can fairly cheaply
fallback to using CPU driven flips instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77104
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
misc core patches picked up by Daniel and Jani.
* tag 'topic/core-stuff-2014-06-30' of git://anongit.freedesktop.org/drm-intel:
drm/fb-helper: Remove unnecessary list empty check in drm_fb_helper_debug_enter()
drm/fb-helper: Redundant info->fix.type_aux setting in drm_fb_helper_fill_fix()
drm/debugfs: add an "edid_override" file per connector
drm/debugfs: add a "force" file per connector
drm: add register and unregister functions for connectors
drm: fix uninitialized acquire_ctx fields (v2)
drm: Driver-specific ioctls range from 0x40 to 0x9f
drm: Don't export internal module variables
The always-on power well pixel path on haswell is routed such that it
bypasses the panel fitter when we use is. Which means the pfit CRC
source won't work in that configuration.
Add a new disallow-bypass flags to the pfit pipe config state and set
it when we want to use the pf CRC. Results in a bit of flicker, but
should get the job done. We'll also undo do it afterwards to make sure
other tests arent' negatively affected.
Totally untested due to lack of hsw laptops around here.
v2: s/disallow_bypass/force_power_well_on/ to avoid a double negative
(Damien).
v3: force_thru because roadsigns.
v4: Don't forget the power wells! Also note that until the runtime pm
for DPMS series is fully merged the simple disable/enable trick won't
work since the ->crtc_mode_set callback is still required to do nasty
things. This stuff is tricky, but I think by both fixing up
get_crtc_power_domains and the debugfs wa code we should always
grab/drop the additional power well correctly.
v5: Wrap in () as suggested by Damien to avoid setting reserved values
for the edp transcoder path on bdw+
References: https://bugs.freedesktop.org/show_bug.cgi?id=72864
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Tested-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the root cause is understood now and with the fix
commit 564ed191f5
Author: Imre Deak <imre.deak@intel.com>
Date: Fri Jun 13 14:54:21 2014 +0300
drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode
in place the magic for G4x chipsets introduced with commit
commit 61bc95c1fb
Author: Egbert Eich <eich@suse.com>
Date: Mon Mar 4 09:24:38 2013 -0500
DRM/i915: On G45 enable cursor plane briefly after enabling the display plane.
to avoided occasional screen blanking on mode changes can finally
be removed.
It's been verified that Imre's fix also resolves the said issue.
Signed-off-by: Egbert Eich <eich@suse.de>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Blanking/unblanking the console in a loop on an Asus T100 sometimes
leaves the console blank. After some digging I found that applying
commit 61bc95c1fb
Author: Egbert Eich <eich@suse.com>
Date: Mon Mar 4 09:24:38 2013 -0500
DRM/i915: On G45 enable cursor plane briefly after enabling the display plane.
fixed VLV too.
In my case the problem seemed to happen already during the previous crtc
disabling and went away if I disabled self-refresh mode before disabling
the primary plane.
The root cause for this is that updates from the shadow to live plane
control register are blocked at vblank time if the memory self-refresh
mode (aka max-fifo mode on VLV) is active at that moment. The controller
checks at frame start time if the CPU is in C0 and the self-refresh mode
enable bit is set and if so activates self-reresh mode, otherwise
deactivates it. So to make sure that the plane truly gets disabled before
pipe-off we have to:
1. disable memory self-refresh mode
2. disable plane
3. wait for vblank
4. disable pipe
5. wait for pipe-off
v2:
- add explanation for the root cause from HW team (Cesar Mancini et al)
- remove note about the CPU C7S state, in my latest tests disabling it
alone didn't make a difference
- add vblank between disabling plane and pipe (Ville)
- apply the same workaround for all gmch platforms (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the CMNRESET deassert is part of the cmnlane power well,
intel_reset_dpio() is called too late to make any difference. We've
deasserted CMNRESET by that time, and so the off+on toggle w/a will
never kick in.
Move the workaround to intel_power_domains_init_hw() where it gets
called before we enable the init power domain.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have a slightly different way of readoing out the cdclk in
gmbus_set_freq(). Kill that and just call .get_display_clock_speed().
Also need to remove the GMBUSFREQ update from intel_i2c_reset() since
that gets called way too early. Let's do it in intel_modeset_init_hw()
instead, and also pull the initial vlv_cdclk_freq update there from
init_clock gating.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If someone is interested in the current cdclk frquency it should
be stable and not in process of changing frquency. Warn if the current
and requested cdclk don't match in .get_display_clock_spee() on vlv.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV Punit doesn't support the 400MHz cdclk option, so we bypass the
Punit and poke at CCK directly. However we forgot to wait for the
frequeency change to complete. Poll the CCK clock status to make sure
the clock has changed before we fire up any pipes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Drop the cdclk frequency to 200MHz on vlv when all pipes are off. In
theory we should be able to use 200MHz also when the pixel clock is at
most 90% of 200MHz. However in practice all we seem to get is a solid
color picture or an otherwise corrupted display.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Depending on the HPLL frequency one of the supported cdclk frquencies is
either 320MHz or 333MHz. Figure out which one it is to accurately pick
the minimal required cdclk. This would also avoid a warning from the
cdclk code where it compares the actual cdclk read out from the hardware
with a value that was calculated using valleyview_calc_cdclk().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have a standard hook for reading out the current cdclk. Move the VLV
code from valleyview_cur_cdclk() to .get_display_clock_speed().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Avoid using magic values for CCK frequency bits. Also the mask we were
using for the requested frequency was one bit too short. Fix it up.
Note: This also fixes the #define for a mask (spotted by Jesse in his
review).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add note about mask change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use kHz units in vlv cdclk code since that's more customary.
Also replace the precomputed 90% values with *9/10 computation
for extra clarity.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTuaWZAAoJEHm+PkMAQRiGfkIH/2Hhwrg51GWazUYIXVxz5zLU
kPMlaws3vankbhka9HCg02eS3tkzr6shO3F/qlBba+5GUkUDKCcCisIsvk4hgZZg
7YqepTvcaupNxIp4TmTGm1FYVK1GpaWFdJVgg2PDdGFahw3HSlfZoTkBzirNCwga
p/jfeRzathbUixpz9OAC1AEn2gP1AxNRpSt1wShL5rexBb1YRXCPuCEt9B0UsVoR
mzKf5xEsuaZnpCuvWK4S60fjfVhTe8UJ/xGPPfdLyIXU0rvhaKzfeVQO6F5nIQBy
Xvrar1f7oOPZaJRdlmPvAimS7iS8lq/YctuHu7ia1NdJSihtA5sRPf7cWAw2d7s=
=4PrL
-----END PGP SIGNATURE-----
Merge tag 'v3.16-rc4' into drm-intel-next-queued
Due to Dave's vacation drm-next hasn't opened yet for 3.17 so I
couldn't move my drm-intel-next queue forward yet like I usually do.
Just pull in the latest upstream -rc to unblock patch merging - I
don't want to needlessly rebase my current patch pile really and void
all the testing we've done already.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
use mm.h definition
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Apparently we can't trust this field on other platforms and need to find
some other way.
This fixes a regression introduced in
commit 27da3bdfcf
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Apr 4 16:12:07 2014 -0700
drm/i915: use VBT to determine whether to enumerate the VGA port
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
BDW signals the flip done interrupt immediately after the DSPSURF write
when the plane is disabled. This is true even if we've already armed
DSPCNTR to enable the plane at the next vblank. This causes major
problems for our page flip code which relies on the flip done interrupts
happening at vblank time.
So what happens is that we enable the plane, and immediately allow
userspace to submit a page flip. If the plane is still in the process
of being enabled when the page flip is issued, the flip done gets
signalled immediately. Our DSPSURFLIVE check catches this to prevent
premature flip completion, but it also means that we don't get a flip
done interrupt when the plane actually gets enabled, and so the page
flip is never completed.
Work around this by re-introducing blocking vblank waits on BDW
whenever we enable the primary plane.
I removed some of the vblank waits here:
commit 6304cd91e7
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Apr 25 13:30:12 2014 +0300
drm/i915: Drop the excessive vblank waits from modeset codepaths
To avoid these blocking vblank waits we should start using the vblank
interrupt instead of the flip done interrupt to complete page flips.
But that's material for another patch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79354
Tested-by: Guo Jinxian <jinxianx.guo@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
crtc->primary->fb may be NULL upon entry to intel_pipe_set_base() if the
primary plane has previously been disabled via the universal plane
interface. We need to check for NULL before trying to reference
old_fb's obj.
This fixes a regression introduced in
commit a071fa0064
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jun 18 23:28:09 2014 +0200
drm/i915: Introduce accurate frontbuffer tracking
Testcase: igt/kms_universal_plane
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
For MIPI, DSI PLL is configured separately in vlv_configure_dsi_pll
during the DSI enable sequence
Causing WARN dump otherwise in dpio_reads
v2: Add IS_CHERRYVIEW check as suggested by Ville
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jesse noticed that the punit communication needed to query the VLV power
well status can cause substantial delays. Since we can query the state
frequently, for example during I2C transfers, maintain a cached version
of the HW state to get rid of this delay.
This fixes at least one reported regression where boot time increased by
~4 seconds due to frequent power well state queries on VLV during eDP
EDID read.
This regression has been introduced in
commit bb4932c4f1
Author: Imre Deak <imre.deak@intel.com>
Date: Mon Apr 14 20:24:33 2014 +0300
drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on
Reported-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So these are the guts of the new beast. This tracks when a frontbuffer
gets invalidated (due to frontbuffer rendering) and hence should be
constantly scaned out, and when it's flushed again and can be
compressed/one-shot-upload.
Rules for flushing are simple: The frontbuffer needs one more full
upload starting from the next vblank. Which means that the flushing
can _only_ be called once the frontbuffer update has been latched.
But this poses a problem for pageflips: We can't just delay the
flushing until the pageflip is latched, since that would pose the risk
that we override frontbuffer rendering that has been scheduled
in-between the pageflip ioctl and the actual latching.
To handle this track asynchronous invalidations (and also pageflip)
state per-ring and delay any in-between flushing until the rendering
has completed. And also cancel any delayed flushing if we get a new
invalidation request (whether delayed or not).
Also call intel_mark_fb_busy in both cases in all cases to make sure
that we keep the screen at the highest refresh rate both on flips,
synchronous plane updates and for frontbuffer rendering.
v2: Lots of improvements
Suggestions from Chris:
- Move invalidate/flush in flush_*_domain and set_to_*_domain.
- Drop the flush in busy_ioctl since it's redundant. Was a leftover
from an earlier concept to track flips/delayed flushes.
- Don't forget about the initial modeset enable/final disable.
Suggested by Chris.
Track flips accurately, too. Since flips complete independently of
rendering we need to track pending flips in a separate mask. Again if
an invalidate happens we need to cancel the evenutal flush to avoid
races.
v3:
Provide correct header declarations for flip functions. Currently not
needed outside of intel_display.c, but part of the proper interface.
v4: Add proper domain management to fbcon so that the fbcon buffer is
also tracked correctly.
v5: Fixup locking around the fbcon set_to_gtt_domain call.
v6: More comments from Chris:
- Split out fbcon changes.
- Drop superflous checks for potential scanout before calling intel_fb
functions - we can micro-optimize this later.
- s/intel_fb_/intel_fb_obj_/ to make it clear that this deals in gem
object. We already have precedence for fb_obj in the pin_and_fence
functions.
v7: Clarify the semantics of the flip flush handling by renaming
things a bit:
- Don't go through a gem object but take the relevant frontbuffer bits
directly. These functions center on the plane, the actual object is
irrelevant - even a flip to the same object as already active should
cause a flush.
- Add a new intel_frontbuffer_flip for synchronous plane updates. It
currently just calls intel_frontbuffer_flush since the implemenation
differs.
This way we achieve a clear split between one-shot update events on
one side and frontbuffer rendering with potentially a very long delay
between the invalidate and flush.
Chris and I also had some discussions about mark_busy and whether it
is appropriate to call from flush. But mark busy is a state which
should be derived from the 3 events (invalidate, flush, flip) we now
have by the users, like psr does by tracking relevant information in
psr.busy_frontbuffer_bits. DRRS (the only real use of mark_busy for
frontbuffer) needs to have similar logic. With that the overall
mark_busy in the core could be removed.
v8: Only when retiring gpu buffers only flush frontbuffer bits we
actually invalidated in a batch. Just for safety since before any
additional usage/invalidate we should always retire current rendering.
Suggested by Chris Wilson.
v9: Actually use intel_frontbuffer_flip in all appropriate places.
Spotted by Chris.
v10: Address more comments from Chris:
- Don't call _flip in set_base when the crtc is inactive, avoids redunancy
in the modeset case with the initial enabling of all planes.
- Add comments explaining that the initial/final plane enable/disable
still has work left to do before it's fully generic.
v11: Only invalidate for gtt/cpu access when writing. Spotted by Chris.
v12: s/_flush/_flip/ in intel_overlay.c per Chris' comment.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The downclocking checks a few more things, so not that simple to
convert. Also, this should get unified with the drrs handling and also
use the locking of that. Otoh the drrs locking is about as hapzardous
as no locking, at least on first sight.
For easier conversion ditch the upclocking on unload - we'll turn off
everything anyway.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So from just a quick look we seem to have enough information to
accurately figure out whether a given gem bo is used as a frontbuffer
and where exactly: We have obj->pin_count as a first check with no
false negatives and only negligible false positives. And then we can
just walk the modeset objects and figure out where exactly a buffer is
used as scanout.
Except that we can't due to locking order: If we already hold
dev->struct_mutex we can't acquire any modeset locks, so could
potential chase freed pointers and other evil stuff.
So we need something else. For that introduce a new set of bits
obj->frontbuffer_bits to track where a buffer object is used. That we
can then chase without grabbing any modeset locks.
Of course the consumers of this (DRRS, PSR, FBC, ...) still need to be
able to do their magic both when called from modeset and from gem
code. But that can be easily achieved by adding locks for these
specific subsystems which always nest within either kms or gem
locking.
This patch just adds the relevant update code to all places.
Note that if we ever support multi-planar scanout targets then we need
one frontbuffer tracking bit per attachment point that we expose to
userspace.
v2:
- Fix more oopsen. Oops.
- WARN if we leak obj->frontbuffer_bits when freeing a gem buffer. Fix
the bugs this brought to light.
- s/update_frontbuffer_bits/update_fb_bits/. More consistent with the
fb tracking functions (fb for gem object, frontbuffer for raw bits).
And the function name was way too long.
v3: Size obj->frontbuffer_bits correctly so that all pipes fit in.
v4: Don't update fb bits in set_base on failure. Noticed by Chris.
v5: s/i915_gem_update_fb_bits/i915_gem_track_fb/ Also remove a few
local enum pipe variables which are now no longer needed to make the
function arguments no drop over the 80 char limit.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It doesn't make sense to never again schedule the work, since by the
time we might want to re-enable psr the world might have changed and
we can do it again.
The only exception is when we shut down the pipe, but that's an
entirely different thing and needs to be handled in psr_disable.
Note that later patch will again split psr_exit into psr_invalidate
and psr_flush. But the split is different and this simplification
helps with the transition.
v2: Improve the commit message a bit.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have _enable/_disable interfaces now for the modeset sequence and
intel_edp_psr_exit for workarounds.
The callsites in intel_display.c are all redundant with the modeset
sequence enable/disable calls in intel_ddi.c. The one in
intel_sprite.c is real and needs to be switched to psr_exit.
If this breaks anything then we need to augment the enable/disable
functions accordingly.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduce generic functions to register and unregister connectors. This
provides a common place to add and remove associated user space
interfaces.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch enables the framework for using MMIO based flip calls,
in contrast with the CS based flip calls which are being used currently.
MMIO based flip calls can be enabled on architectures where
Render and Blitter engines reside in different power wells. The
decision to use MMIO flips can be made based on workloads to give
100% residency for Media power well.
v2: The MMIO flips now use the interrupt driven mechanism for issuing the
flips when target seqno is reached. (Incorporating Ville's idea)
v3: Rebasing on latest code. Code restructuring after incorporating
Damien's comments
v4: Addressing Ville's review comments
-general cleanup
-updating only base addr instead of calling update_primary_plane
-extending patch for gen5+ platforms
v5: Addressed Ville's review comments
-Making mmio flip vs cs flip selection based on module parameter
-Adding check for DRIVER_MODESET feature in notify_ring before calling
notify mmio flip.
-Other changes mostly in function arguments
v6: -Having a seperate function to check condition for using mmio flips (Ville)
-propogating error code from i915_gem_check_olr (Ville)
v7: -Adding __must_check with i915_gem_check_olr (Chris)
-Renaming mmio_flip_data to mmio_flip (Chris)
-Rebasing on latest nightly
v8: -Rebasing on latest code
-squash 3rd patch in series(mmio setbase vs page flip race) with this patch
-Added new tiling mode update in intel_do_mmio_flip (Chris)
v9: -check for obj->last_write_seqno being 0 instead of obj->ring being NULL in
intel_postpone_flip, as this is a more restrictive condition (Chris)
v10: -Applied Chris's suggestions for squashing patches 2,3 into this patch.
These patches make the selection of CS vs MMIO flip at the page flip time, and
make the module parameter for using mmio flips as tristate, the states being
'force CS flips', 'force mmio flips', 'driver discretion'.
Changed the logic for driver discretion (Chris)
v11: Minor code cleanup(better readability, fixing whitespace errors, using
lockdep to check mutex locked status in postpone_flip, removal of __must_check
in function definition) (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # snb, ivb
[danvet: Fix up parameter alignement checkpatch spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Spotted while crawling around in the area.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The perfect solution for psr_exit is the hardware tracking the changes and
doing the psr exit by itself. This scenario works for HSW and BDW with some
environments like Gnome and Wayland.
However there are many other scenarios that this isn't true. Mainly one right
now is KDE users on HSW and BDW with PSR on. User would miss many screen
updates. For instances any key typed could be seen only when mouse cursor is
moved. So this patch introduces the ability of trigger PSR exit on kernel side
on some common cases that.
Most of the cases are coverred by psr_exit at set_domain. The remaining cases
are coverred by triggering it at set_domain, busy_ioctl, sw_finish and
mark_busy.
The downside here might be reducing the residency time on the cases this
already work very wall like Gnome environment. But so far let's get focused
on fixinge issues sio PSR couild be used for everybody and we could even
get it enabled by default. Later we can add some alternatives to choose the
level of PSR efficiency over boot flag of even over crtc property.
v2: remove exit from connector_dpms. Daniel pointed this is the wrong way and
also this isn't needed for BDW and HSW anyway.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
obj->framebuffer_references isn't an atomic_t so the decrement needs to
be protected by some lock. struct_mutex seems like the appropriate lock
here, and we may already take it for the obj unref anyway.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The DRM core will translate calls to legacy cursor ioctls into universal
cursor calls automatically, so there's no need to maintain the legacy
cursor support. This greatly simplifies the transition since we don't
have to handle reference counting differently depending on which cursor
interface was called.
The aim here is to transition to the universal plane interface with
minimal code change. There's a lot of cleanup that can be done (e.g.,
using state stored in crtc->cursor->fb rather than intel_crtc) that is
left to future patches.
v4:
- Drop drm_gem_object_unreference() that is no longer needed now that
we receive the GEM obj directly rather than looking up the ID.
v3:
- Pass cursor obj to intel_crtc_cursor_set_obj() if cursor fb changes,
even if 'visible' is false. intel_crtc_cursor_set_obj() will notice
that the cursor isn't visible and disable it properly, but we still
need to get intel_crtc->cursor_addr set properly so that we behave
properly if the cursor becomes visible again in the future without
changing the cursor buffer (noted by Chris Wilson and verified
via i-g-t kms_cursor_crc).
- s/drm_plane_init/drm_universal_plane_init/. Due to type
compatibility between enum and bool, everything actually works
correctly with the wrong init call, except for the type of plane that
gets exposed to userspace (it shows up as type 'primary' rather than
type 'cursor').
v2:
- Remove duplicate dimension checks on cursor
- Drop explicit cursor disable from crtc destroy (fb & plane
destruction will take care of that now)
- Use DRM plane helper to check update parameters
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter. The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call this new function.
This refactoring is in preparation for the universal plane cursor
support where we'll want to update the cursor with an actual GEM buffer
object (obtained via drm_framebuffer) rather than a userspace handle.
v2: Drop obvious kerneldoc and replace with note about function's
reference consumption
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Keeping track of the power domains is a bit messy since crtc->active
is currently updated by the platform hooks, but we need to be aware of
which state transition exactly is going on. Maybe we simply need to
shovel all the power domain handling down into platform code to
simplify this. But doing that requires some more auditing since
currently the ->mode_set callbacks still read some random registers
(to e.g. figure out the reference clocks).
Also note that intel_crtc_update_dpms is always call first/last even
for encoders which have their own dpms functions. Hence we really only
need to update this place here.
Being a quick "does it blow up?" run not really tested yet.
v2: Don't do runtime PM in the DPMS hooks for HAS_DDI platforms since
that is stalled. Also add a comment to explain what's going on.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
v8:
- Pin/unpin properly when clipping causes the primary plane to be
disabled when it has previously been enabled.
- s/drm_primary_helper_check_update/drm_plane_helper_check_update/
v7:
- Clip primary plane to invisible when crtc is disabled since
intel_crtc->config.pipe_src_{w,h} may be garbage otherwise.
- Unpin old fb before pinning new one in the "just pin and
return" case that is used when the crtc is disabled.
- Don't treat implicit disabling of the primary plane (caused by
clipping) the same way as explicit disabling (caused by fb=0).
For implicit disables, we should leave the fb set and pinned,
whereas for explicit disables we need to unpin the fb before
primary->fb is cleared.
v6:
- Pass rectangles to primary helper check function and get plane
visibility back.
- Wait for pending pageflips on primary plane update/disable.
- Allow primary plane to be updated while the crtc is disabled (changes
will take effect when the crtc is re-enabled if modeset passes -1
for the fb id).
- Drop WARN() if we try to disable the primary plane when it's
already been disabled. This will happen if the crtc gets disabled
after the primary plane has already been disabled independently.
v5:
- Use new drm_primary_helper_check_update() helper function to check
setplane parameter validity.
- Swap primary plane's pipe for pre-gen4 FBC (caught by Ville Syrjälä)
- Cleanup primary plane properly on crtc init failure
v4:
- Don't add a primary_plane field to intel_crtc; that was left over
from a much earlier iteration of this patch series, but is no longer
needed/used now that the DRM core primary plane support has been
merged.
v3:
- Provide gen-specific primary plane format lists (suggested by Daniel
Vetter).
- If the primary plane is already enabled, go ahead and just call the
primary plane helper to do the update (suggested by Daniel Vetter).
- Don't try to disable the primary plane on destruction; the DRM layer
should have already taken care of this for us.
v2:
- Unpin fb properly on primary plane disable
- Provide an Intel-specific set of primary plane formats
- Additional sanity checks on setplane (in line with the checks
currently being done by the DRM core primary plane helper)
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In a future patch, we'll allow the primary plane to be disabled by
userspace via the universal plane API. If a modeset is requested while
the primary plane is disabled, crtc->primary->fb will be NULL which
generally triggers a full modeset (except in fastboot situations). If
we detect that the crtc is active, but there's no primary plane fb,
we should still allow a simple plane update rather than a full modeset
if the mode isn't actually changing (after re-enabling the primary plane
of course).
v2:
- Enable plane after set_base to avoid enabling the plane if set_base
fails, and to make flip+enable atomic (suggested by Ville)
- Drop BUG to WARN if we somehow enter the 'fb_changed' modeset case
with the crtc disabled (suggested by Ville)
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This doesn't look possible but a little extra defense against the
improbable is worth it - an oops here could lockup the machine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we forced the clock buffers on in .pre_pll_enable() we
should probably undo the damage after we've turned the PLL off.
We do the clock buffer force enable in the .pre_pll_enable() hook
as we need to know which port is going to be used, but in the disable
case we don't need the port since we just disable the clock buffers
to both channels. So we can do this in chv_disable_pll() instead
of having to add any kind of .post_pll_disable() hook.
v2: Improve the commit message
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because of the upcoming vblank interrupt driven watermark update
mechanism we will have use for vblank interrupts during plane
enabling/disabling. So don't call drm_vblank_off() until planes
are off, and call drm_vblank_on() just before we start to enable
the planes.
v2: Pimp commit message (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>
> Bunch of stuff for 3.16 still:
> - Mipi dsi panel support for byt. Finally! From Shobhit&others. I've
> squeezed this in since it's a regression compared to vbios and we've
> been ridiculed about it a bit too often ...
> - connection_mutex deadlock fix in get_connector (only affects i915).
> - Core patches from Matt's primary plane from Matt Roper, I've pushed the
> i915 stuff to 3.17.
> - vlv power well sequencing fixes from Jesse.
> - Fix for cursor size changes from Chris.
> - agpbusy fixes from Ville.
> - A few smaller things.
>
* tag 'drm-intel-fixes-2014-06-06' of git://anongit.freedesktop.org/drm-intel: (32 commits)
drm/i915: BDW: Adding missing cursor offsets.
drm: Fix getconnector connection_mutex locking
drm/i915/bdw: Only use 2g GGTT for 32b platforms
drm/i915: Nuke pipe A quirk on i830M
drm/i915: fix display power sw state reporting
drm/i915: Always apply cursor width changes
drm/i915: tell the user if both KMS and UMS are disabled
drm/plane-helper: Add drm_plane_helper_check_update() (v3)
drm: Check CRTC compatibility in setplane
drm/i915: use VBT to determine whether to enumerate the VGA port
drm/i915: Don't WARN about ring idle bit on gen2
drm/i915: Silence the WARN if the user tries to GTT mmap an incoherent object
drm/i915: Move the C3 LP write bit setup to gen3_init_clock_gating() for KMS
drm/i915: Enable interrupt-based AGPBUSY# enable on 85x
drm/i915: Flip the sense of AGPBUSY_DIS bit
drm/i915: Set AGPBUSY# bit in init_clock_gating
drm/i915/vlv: add pll assertion when disabling DPIO common well
drm/i915/vlv: move DPIO common reset de-assert into __vlv_set_power_well
drm/i915/vlv: re-order power wells so DPIO common comes after TX
drm/i915/vlv: move CRI refclk enable into __vlv_set_power_well
...
Merge drm-fixes into drm-next.
Both i915 and radeon need this done for later patches.
Conflicts:
drivers/gpu/drm/drm_crtc_helper.c
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem_execbuffer.c
drivers/gpu/drm/i915/i915_gem_gtt.c
Apparently it does more harm than good. Thomas Richter reports that
it helps his machine (Thinkpad X31) and there's another report from a
Fujitsu S6010. Also, we've nuked it on i845G already to make Chris'
machine happy.
Cc: Thomas Richter <richter@rus.uni-stuttgart.de>
References: http://mid.mail-archive.com/538C54E0.8090507@rus.uni-stuttgart.de
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is possible for userspace to create a big object large enough for a
256x256, and then switch over to using it as a 64x64 cursor. This
requires the cursor update routines to check for a change in width on
every update, rather than just when the cursor is originally enabled.
This also fixes an issue with 845g/865g which cannot change the base
address of the cursor whilst it is active.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[Antti:rebased, adjusted macro names and moved some lines, no functional
changes]
Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Tested-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Cc: stable@vger.kernel.org
Testcase: igt/kms_cursor_crc/cursor-size-change
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some platforms may not have it, and enumerating it is both confusing and
time consuming due to the hotplug and DDC probing.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to do this anytime we power gate the DPIO common well.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This needs to be done before we power back on the CMN_BC well so the PHY
can calibrate properly.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
that it resets the whole common lane section of the PHY. This is
required on machines where the BIOS doesn't do this for us on boot or
resume to properly re-calibrate and get the PHY ready to transmit data.
Without this patch, such machines won't resume correctly much of the time,
with the symptom being a 'port ready' timeout and/or a link training
failure.
Note that simply asserting reset at suspend and de-asserting at resume
is not sufficient, nor is simply de-asserting at boot. Both of these
cases have been tested and have still been found to have failures on
some configurations.
v2: extract simpler set_power_well function for use in reset_dpio (Imre)
move to reset_dpio (Daniel & Ville)
v3: don't reset if DPIO reset is already de-asserted (Imre)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For atomic, it will be quite necessary to not need to care so much
about locking order. And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.
Because we will want to eventually make locking even more fine grained
(giving locks to planes, connectors, etc), split out drm_modeset_lock
and drm_modeset_acquire_ctx to track acquired locks.
Atomic will use this to keep track of which locks have been acquired
in a transaction.
v1: original
v2: remove a few things not needed until atomic, for now
v3: update for v3 of connection_mutex patch..
v4: squash in docbook
v5: doc tweaks/fixes
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
modeset-relevant connector state (e.g. properties which control the
panel fitter).
The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.
Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.
The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.
For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.
Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.
I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
sprinkle mode_config.connection_mutex over this file a bit, but
since it already lacks mode_config.mutex this patch wont make the
situation any worse. This is material for a follow-up patch.
- omap has a omap_framebuffer_flush function which walks the
connector->encoder->crtc links and is called from many contexts.
Some look like they don't acquire mode_config.mutex, so this is
already racy. Again fixing this is material for a separate patch.
- The radeon hot_plug function to retrain DP links looks at
connector->dpms. Currently this happens without any locking, so is
already racy. I think radeon_hotplug_work_func should gain
mutex_lock/unlock calls for the mode_config.connection_mutex.
- Same applies to i915's intel_dp_hot_plug. But again, this is already
racy.
- i915 load_detect code needs to acquire this lock. Which means the
w/w dance due to Rob's work will be nicely contained to _just_ this
function.
I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.
v1: original (only compile tested)
v2: missing mutex_init(), etc (from Rob Clark)
v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
A single object may be referenced by multiple registers fundamentally
breaking the static allotment of ids in the current design. When the
object is used the second time, the physical address of the first
assignment is relinquished and a second one granted. However, the
hardware is still reading (and possibly writing) to the old physical
address now returned to the system. Eventually hilarity will ensue, but
in the short term, it just means that cursors are broken when using more
than one pipe.
v2: Fix up leak of pci handle when handling an error during attachment,
and avoid a double kmap/kunmap. (Ville)
Rebase against -fixes.
v3: And fix the error handling added in v2 (Ville)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77351
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the upcoming patches we plan to break the correlation between
engine command streamers (a.k.a. rings) and ringbuffers, so it
makes sense to refactor the code and make the change obvious.
No functional changes.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On gen2 the scanline counter behaves a bit differently from the
later generations. Instead of adding one to the raw scanline
counter value, we must subtract one.
On HSW/BDW the scanline counter requires a +2 adjustment on HDMI
outputs. DP outputs on the on the other require the typical +1
adjustment.
As the fixup we must apply to the hardware scanline counter
depends on several factors, compute the desired offset at modeset
time and tuck it away for when it's needed.
v2: Clarify HSW+ situation
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: "Akash Goel <akash.goels@gmail.com>"
Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78997
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have to write to the primary plane base address registrer when we
enable/disable the primary plane in response to sprite coverage. Those
writes will cause the flip counter to increment which could interfere
with the detection of CS flip completion. We could end up completing
CS flips before the CS has even executed the commands from the ring.
To avoid such issues, wait for CS flips to finish before we toggle the
primary plane on/off.
v2: Rebased due to atomic sprite update changes
Testcase: igt/kms_mmio_vs_cs_flip/setplane_vs_cs_flip
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gen2 reports FIFO underruns whenever no planes are enabled on the pipe.
So in order to avoid false positives we must enable the FIFO underrun
reporting only when at least one plane is enabled on the pipe. For
now just move the underrun reporting enable/disable points to the
other side of the plane enable/disable point. That doesn't cover cases
when we turn off all the planes for the pipe but leave the pipe running
on purpose, but it's better than the current situation.
On gen4+ we can actually move the underrun reporting enable/disable to
the opposite ends of the crtc enable/disable hooks. I suppose in theory
we could leave the underrun reporting enabled all the time, except on
VLV where PIPESTAT stops working when the display power well is down.
If we ever get around to unifying the PIPESTAT irq handling for all
gmch platforms, we should still follow the VLV route for other platforms.
It would also micro-optimize the irq handler a bit since we could then
skip the PIPESTAT reads for all disabled pipes.
Gen3 is still a mystery, but for now I'm going to assume it behaves
like gen4+.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
FIFO underruns don't generate interrupts on gmch platforms, so
if we want to know whether a modeset triggered FIFO underruns we
need to explicitly check for them.
As a modeset on one pipe could cause underruns on other pipes,
check for underruns on all pipes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thomas Wood <thomas.wood@intel.com>
[danvet: Fix up merge error, kudos to Ville for noticing it.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If a pipe is already active when we init/resume there might not be a
full modeset afterwards so drm_vblank_on() may not get called. In such
a case if someone is holding a vblank reference across a suspend/resume
cycle drm_vblank_get() called after resuming won't re-enable the vblank
interrupts.
So in order to make sure vblank interrupts get re-enabled post-resume,
call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already
active.
v2: Also drm_vblank_off() if the pipe got disabled magically
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Testecase: igt/kms_flip/vblank-vs-suspend
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull in the drm vblank rework from Ville and me. drm core parts acked
by Dave Airlie
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Just a bit of fun around the placement of drm_vblank_on. This merge
resolution has been tested in drm-intel-nightly for a while already.
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms and hence we must allow underrun
reporting on disabled pipes. Otherwise nothing really works,
especially the CRC support since that's key'ed off the same irq
disable bit.
This allows us to ditch the fifo underrun reporting hack from the vlv
runtime pm code and unexport the internal function from i915_irq.c
again. Yay!
v2: Keep the display irq disabling, spotted by Imre.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only the low-level irq handling functions still use integer crtc
indices with this. But fixing that will require a lot more sugery
and some good ideas for backwards compat with old ums userspace.
Both in drivers and in the drm core.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Originally these functions have been for user modesetting drivers to
ensure vblank processing doesn't fall over completely around modeset
changes. This has been carried over ever since then.
Now that Ville cleaned our vblank handling with an explicit
drm_vblank_off/on braket when disabling/enabling crtcs. So this seems
to be unnecessary now. The most important side effect was that due to
the delayed vblank disabling we have been pretty much guaranteed to
receive a vblank interrupt soonish after a crtc was enabled.
Note that our vblank handling across modeset is still fairly decent
fubar - we don't actually handle vblank counter all to well.
drm_update_vblank_count will make sure that the frame counter always
rolls forward, but userspace isn't really all to ready to cope with
the big jumps this causes.
This isn't a big mostly because the hardware retains the frame
counter. But with runtime pm and also across suspend/resume we fall
over.
Fixing this is a lot more involved and also needs som i-g-ts. So
material for another patch series.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All of the .queue_flip() callbacks duplicate the same code to pin the
buffers and calculate the gtt_offset. Move that code to
intel_crtc_page_flip(). In order to do that we must also move the ring
selection logic there.
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>
Now that we've plugged the mmio vs. ring flip race, we shouldn't need
these vblank waits in the modeset codepaths anymore. So get rid of
them.
v2: gen2 needs to wait for planes to turn off before disabling pipe
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the vblank wait is gone from intel_enable_primary_plane(),
hsw_enable_ips() needs to do the vblank wait itself.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Starting from ILK, mmio flips also cause a flip done interrupt to be
signalled. This means if we first do a set_base and follow it
immediately with the CS flip, we might mistake the flip done interrupt
caused by the set_base as the flip done interrupt caused by the CS
flip.
The hardware has a flip counter which increments every time a mmio or
CS flip is issued. It basically counts the number of DSPSURF register
writes. This means we can sample the counter before we put the CS
flip into the ring, and then when we get a flip done interrupt we can
check whether the CS flip has actually performed the surface address
update, or if the interrupt was caused by a previous but yet
unfinished mmio flip.
Even with the flip counter we still have a race condition of the CS flip
base address update happens after the mmio flip done interrupt was
raised but not yet processed by the driver. When the interrupt is
eventually processed, the flip counter will already indicate that the
CS flip has been executed, but it would not actually complete until the
next start of vblank. We can use the DSPSURFLIVE register to check
whether the hardware is actually scanning out of the buffer we expect,
or if we managed hit this race window.
This covers all the cases where the CS flip actually changes the base
address. If the base address remains unchanged, we might still complete
the CS flip before it has actually completed. But since the address
didn't change anyway, the premature flip completion can't result in
userspace overwriting data that's still being scanned out.
CTG already has the flip counter and DSPSURFLIVE registers, and
although the flip done interrupt is still limited to CS flips alone,
the code now also checks the flip counter on CTG as well.
v2: s/dspsurf/gtt_offset/ (Chris)
Testcase: igt/kms_mmio_vs_cs_flip/setcrtc_vs_cs_flip
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73027
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add g4x_ prefix to flip_count_after_eq.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a vblank reference while a modeset is
happening, and the driver requires vblank interrupt to work during that
time.
Add drm_vblank_on() as a counterpart to drm_vblank_off() which will
re-enabled vblank interrupts if the refcount is already elevated. This
will allow drivers to choose the specific places in the modeset sequence
at which vblank interrupts get disabled and enabled.
Testcase: igt/kms_flip/*-vs-suspend
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add Testcase tag for the igt I've written.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Seems like we shouldn't leave the data lane resert deasserted when
the port if disabled. So propagate the reset the data lanes in
the encoder .post_disable() hook.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During the enable sequence we first enable the dclkp output to the
display controller, and then enable the PLL. Do the opposite during
the disable sequence.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to pick the correct data lanes based on the port not the
pipe, so move the data lane deassert into the encoder .pre_enable()
hook from the chv_enable_pll().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Setup the pipe config dpll state correctly for CHV. Also add
a assert_pipe_disabled() to chv_disable_pll(), and program the
DPLL_MD registers in chv_enable_pll().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unsurprisingly the cursor C regiters are also at a weird offset on CHV.
Add more pipe offsets to handle them.
This also gets rid of most of the differences between the i9xx vs. ivb
cursor code. We can unify the remaining code as well, but I'll leave
that for another patch.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Besides the fairly useless BUG_ON the logic is completely generic
and cane be used on any platform what wants to reuse the shared
dpll support code.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the last piece of code which write state to the hardware in
the ironalake ->crtc_mode_set callback.
I think we could merge this with the pll->enable hook, but otoh the
ordering requirements with the ldvs port are really tricky. Doing the
FP0/1 writes up-front before we even prepare the lvds port (in the
pre_pll_enable hook) like on i9xx seems safest.
With this ilk+ platforms are now ready for runtime PM with DPMS. Since
hsw/bdw also support runtime pm besides snb we need to first make the
haswell code save before we can touch the core code.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of every time it isn't active: We only need to do that when
the pll is currently unused, i.e. when pll->refcount == 0. For
paranoia add a warning for the ibx case where plls have a fixed
mapping and hence should always be unused after the call to
intel_put_shared_dpll.
v2: Simplify control flow and use struct assignment instead of memcpy
as suggested by Damien.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With this all hw writes are also gone from the ->crtc_mode_set hook on
vlv. I wondered whether we should track more of the pll state in the
pipe config, but otoh as long as we don't have shared plls that's not
really useful - the cross-checking of the port clock should be
sufficient.
While at it also de-magic some of the pipe checks, this has been
irking me since a long time.
Whit this vlv is now ready for runtime PM on dpms. If we'd have
runtime PM support in general ...
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These two writes are the very last hw writes from the
->crtc_modeset_callback on pre-gen5 hardware. As usual vlv is a bit
different, so this here is just warm-up.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again the same story: This code just transform sw state from the pipe
config into hardware state. And again we can't move the pll code, but
this time around because the state isn't properly tracked in the pipe
config.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again this code just transforms sw state from the pipe config into
hardware state, so we can just move it around. Unfortunately again a
few forward declarations since intel_display.c is becoming a bit of a
mess.
Note that both for i9xx and ironlake code the only things remaining in
the ->crtc_mode_set hook is now the clock state computation and
sharing code. That needs to be moved into the compute config stage so
that we can catch impossible configurations earlier.
Also note that some of the DPLL hw setup code is still run from within
->crtc_mode_set, namele the pll->mode_set callback. We need to move
that first before we can do fancy things like enable runtime PM for
dpms off.
v2: Make it compile again after the rebase, bisectability issue
reported by Wu Fengguang.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now this really should be in the pipe config somewhere, but till now
it isn't. We can at least move it up a bit next to all the other pll
code since intel_dp_set_m_n really doesn't depend upon this.
This is just prep work so that moving all the hw frobbing code from
->crtc_mode_set to ->crtc_enable is clean.
v2: Do the same for haswell while at it, not just for ivb.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All these functions simply convert sw state as encoded in the pipe
config or primary framebuffer into hardware state. So we can move them
all into the crtc enable hook. Unfortunately this means a little bit
of duplication between the i9xx and vlv functions, but since we
already have highly refactored code I think this is acceptable.
Also a pile of forward declarations unfortunately.
Note also that the various <platform>_update_pll functions are still
called from within the ->crtc_mode_set hook. Mostly they compute the
clock state for the pipe config, but unfortunately there are some
random register writes interspersed. Those need to be moved out first
before we can enable runtime PM for DPMS.
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can apperently miss them, but breaking the entire driver hampers
testing. So bail out after one minute, our customerary "this is a lost
cause" timeout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=78383
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: Robin Schroer <sulamiification@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our two ->crtc_mode_set callbacks really don't care whether the fb is
pinned and set up already or not - all the state computation and
handling which originally looked at the framebuffer is already using
the indirection through the pipe configuration.
Eventually we want to move this up a bit more, but as long as the crtc
mode_set callback still exists (and as long as we don't need to pin an
entire pile of planes due to atomic modesets) there's not much point
in it. So I'll let this be for now.
v2: Don't forget about haswell ...
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A lot of the code in set_base is uncessary when the crtc is off, so we
can get rid of it all. Also, we don't need to call the fbc/psr update
functions since the crtc enable/disable hooks do that already.
The only things we really need are:
- Pin the new framebuffer and potentially unpin the old framebuffer
(if the crtc has been on and we only change the configuration).
- Update the plane registers.
The first step will move out of platform code with the very next
patch.
v2: Don't forget about haswell ...
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My plan here is to split up set_base into a prepare step, which does
the pinning, and a commit stage, which updates the hw state. Eventually
we should be able to move the prepare step at the beginning of any
atomic update. For now I only want to move the commit step into the
crtc_enable callbacks.
As a prep step sprinkle intel_edp_psr_update all over the place so
that we don't have to concern ourselves with that in the commit step.
v2: Rebase on top of Ville's enable/disable functions for all planes.
v3: Rebase more.
Reviewed-by: Akash Goel <akash.goel@intel.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just for consistency, this patch won't fix anything really.
v2: Rebase over all the recent plane enabling shuffling.
Reviewed-by: Akash Goel <akash.goel@intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Way back we've used this to reject framebuffers with unsupported
pixel formats. But since the modesetting reorg with the compute
config stage we reject those much earlier and just BUG() in this
callback. So switch to a void return type.
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Including state readout and cross-checking. This allows us to get rid
of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy
if the BIOS hasn't set up the audio routing like we want it too.
Wrt fastboot and external screens I see a few options:
- Don't.
- Try to fix up eld, infoframes and audio settings after the fact. But
that means some pretty extensive reworking of our code which
currently does all this while the pipe/port is still off.
I won't bother with converting SDVO over to this because the audio
support for SDVO is very lacking:
- We don't update the eld.
- We don't update the audio state on the sdvo encoder.
- We don't check whether the platform can even feed audio to the sdvo
encoder.
I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi
and dp converted and so doing it step-by-step would have required a
few intermediate hacks.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least on those platforms which have a simple bit and don't rely
on the fully programmable CSC unit to do this.
Note that with the current code this includes CHV, but I guess that
platform will match BYT.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also add state readout and cross-check support. The only invasive change
is wiring up the new flag to the ->set_infoframes callbacks.
Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Patch done using the following semantic patch (thanks Daniel for the
help!)
@@
iterator name list_for_each_entry;
iterator name for_each_crtc;
struct drm_crtc * crtc;
struct drm_device * dev;
@@
-list_for_each_entry(crtc,&dev->mode_config.crtc_list, head) {
+for_each_crtc(dev,crtc) {
...
}
Followed by a couple of fixups by hand (that spatch doesn't match the
cases where list_for_each_entry() is not followed by a set of '{', '}',
but I couldn't figure out a way to leave the '{' out of the iterator
match).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Generated using the semantic patch:
@@
iterator name list_for_each_entry;
iterator name for_each_intel_crtc;
struct intel_crtc * crtc;
struct drm_device * dev;
@@
-list_for_each_entry(crtc,&dev->mode_config.crtc_list,...) {
+for_each_intel_crtc(dev,crtc) {
...
}
Followed by a couple of fixups by hand (that spatch doesn't match the
cases where list_for_each_entry() is not followed by a set of '{', '}',
but I couldn't figure out a way to leave the '{' out of the iterator
match).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The pipe might not start to actually run until the port has been enabled
(depends on the platform and port type). So don't try to wait for vblank
after we enabled the pipe but haven't yet enabled the port.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=77297
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already moved the plane disable/enable to happen as the first/last
thing on every other platforms. Follow suit with gmch platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Frob drm_vblank_on conflict, as usual.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No CRT output on CHV, so don't call intel_crt_init().
v2: Don't disable CRT on HAS.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add chv_crtc_clock_get() to read out the DPLL settings.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Fix compile due to bikeshedded headers in an earlier patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With additional of pipe C, current 1 bit registers for pipe select
for HDMI and DP are no longer able to gather for 3 pipes. As a result,
new bits location in the same registers are added.
For HDMI, VLV uses bit 30, CHV uses bit 24-25.
For DP, VLV uses bit 30, CHV uses bit 16-17.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added programming PLL for CHV based on "Application note for 1273 CHV
Display phy".
v2: -Break the common lane reset into another patch.
-Break the clock calculation into another patch.
-The changes are based on Ville review.
-Rework based on DPIO register define naming convention change.
-Break the dpio write into few lines to improve readability.
-Correct the udelay during chv_enable_pll.
-clean up some magic numbers with some new define.
-program the afc recal bit which was missed.
v3: Based on Ville review
- minor correction of the bit defination
- add deassert/propagate data lane reset
v4: Corrected the udelay between dclkp enable and pll enable.
Minor comment and better way to clear the TX lane reset.
v5: Squash in fixup from Rafael Barbalho.
[vsyrjala: v6: Polish the defines (Imre)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on the chv clock limit, find the best divisor.
The divisor data has been verified with this spreadsheet.
P1273_DPLL_Programming Spreadsheet.
v2: Rebase the code and change the chv_find_best_dpll based on new
standard way to use intel_PLL_is_valid. Besides, clean up some extra
variables.
v3: Ville suggest better fixed point for m2 calculation.
v4: -Add comment for the limit is compute using fast clock. (Ville)
-Don't pass the request clock to chv_clock, as the same function will
be use clock readout, which doens't have request clock. (Ville)
-Add and use DIV_ROUND_CLOSEST_ULL to consistent with other clock
calculation. (Ville)
-Fix the dp m2 after m2 has stored fixed point. (Ville)
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
[vsyrjala: Avoid div-by-zero in chv_clock()]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During cold boot, the display controller needs to deassert the common
lane reset. Only do it once during intel_init_dpio for both PHYx2 and
PHYx1.
Besides, assert the common lane reset when disable pll. This still
to be determined whether need to do it by driver.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
[vsyrjala: Don't disable DPIO PLL when using DSI]
[vsyrjala: Don't call vlv_disable_pll() by accident on CHV]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Move part of a moved comment back as suggested by Imre since
it's valid for both byt and chv.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The additional DPLL registers added to support Port D. Besides, add
some new PHY control and status registers based on B-spec.
v2: Based on Ville review
- Corrected DPIO_PHY_STATUS offset and name.
- Rebase based on upstream change after introduce enum dpio_phy and
enum dpio_channel.
v3: Rebased on top of Antti's 3-pipe prep patch. Note that the new offsets for
the DPLL registers aren't in place yet, so this introduces a slight regression.
But since 3 pipe support isn't fully enabled yet anyaway in -internal this
shouldn't matter too much.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CHV has 2 display phys. First phy (IOSF offset 0x1A) has two channels,
and second phy (IOSF offset 0x12) has single channel. The first phy is
used for port B and port C, while second phy is only for port D.
v2: Move the pipe to determine which phy to select for
vlv_dpio_read/vlv_dpio_write to another patch. (Daniel)
v3: Rebase the code based on rework on how to calculate DPIO offset.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the same code for enabling/disabling planes on all platforms. Rename
the functions to reflect that they're no longer specific to any
platform.
For now we leave the plane enable/disable to ccur at the same old
position in the modeset sequence.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Frob drm_vblank_on conflict.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We won't be calling intel_enable_primary_plane() or
intel_disable_primary_plane() with the primary plane in the
wrong state. So remove the useless DISPLAY_PLANE_ENABLE checks.
v2: Convert the checks to WARNs instead (Daniel,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>
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
We do the vblank evade by checking the scanline counter, and if it's too
close to the start of vblank (too close has been hardcoded to 100usec
for now), we will wait for the vblank start to pass. In order to
eliminate random delayes from the rest of the system, we operate with
interrupts disabled, except when waiting for the vblank obviously.
Note that we now go digging through pipe_to_crtc_mapping[] in the
vblank interrupt handler, which is a bit dangerous since we set up
interrupts before the crtcs. However in this case since it's the vblank
interrupt, we don't actually unmask it until some piece of code
requests it.
v2: preempt_check_resched() calls after local_irq_enable() (Jesse)
Hook up the vblank irq stuff on BDW as well
v3: Pass intel_crtc instead of drm_crtc (Daniel)
Warn if crtc.mutex isn't locked (Daniel)
Add an explicit compiler barrier and document the barriers (Daniel)
Note the irq vs. modeset setup madness in the commit message (Daniel)
v4: Use prepare_to_wait() & co. directly and eliminate vbl_received
v5: Refactor intel_pipe_handle_vblank() vs. drm_handle_vblank() (Chris)
Check for min/max scanline <= 0 (Chris)
Don't call intel_pipe_update_end() if start failed totally (Chris)
Check that the vblank counters match on both sides of the critical
section (Chris)
v6: Fix atomic update for interlaced modes
v7: Reorder code for better readability (Chris)
v8: Drop preempt_check_resched(). It's not available to modules
anymore and isn't even needed unless we ourselves cause
a wakeup needing reschedule while interrupts are off
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Sourab Gupta <sourabgupta@gmail.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For a bunch of reasons we want to move away from the ->mode_set
callbacks: All hw state setup needs to move into ->enable hooks (so
that DOMS can do runtime pm) and all the configuration setup needs to
move into the compute_config functions.
To start with this make the enocer->mode_set callback optional.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BIOS can enable a pipe but leave the primary plane disabled. This
coflicts with out current idea of primary_enabled. Read the actual
hardware plane state and set primary_enabled appropriately.
We currently assume that primary_enabled is always true when we're about
to disable a crtc. That needs to change now as the plane may not be
enabled. So replace the relevant WARNs with early returns in
intel_{enable,disable}_primary_hw_plane().
Fixes the following warning
[ 3.831602] WARNING: CPU: 0 PID: 1112 at linux/drivers/gpu/drm/i915/intel_display.c:1918 intel_disable_primary_hw_plane+0xe4/0xf0 [i915]()
which got introduced here by me:
commit e9e39655c0c30cddc3f8c09a757678a24dd36737
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Apr 28 15:53:25 2014 +0300
drm/i915: Remove useless checks from primary enable/disable
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
assert_plane_enabled() is now triggering during FDI link train because
we no longer enable planes that early.
This problem got introduced in:
commit a5c4d7bc18
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Mar 7 18:32:13 2014 +0200
drm/i915: Disable/enable planes as the first/last thing during modeset on ILK+
Just drop the assert since we shouldn't need planes for link training.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Squash in fixup for now unused plane local variable, reported
by 0-day tester.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to re-init sizzling on all platforms so move it to the
platform independent runtime resume callback. The ring frequency reinit
is also needed everywhere except on VLV, but gen6_update_ring_freq()
will be a noop on VLV, so we can move this function too to platform
independent code.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is needed by the next patch moving the call out from platform
specific RPM callbacks to platform independent code.
No functional change.
v2:
- patch introduce in v2 of the patchset
v3:
- simplify platform check condition (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to disable the interrupts for all platforms, so make the helpers
for this platform independent and call them from them platform
independent runtime suspend/resume callbacks.
On HSW/BDW this will move interrupt disabling/re-enabling at the
beginning/end of runtime suspend/resume respectively, but I don't see
any reason why this would cause a problem there. In any case this seems
to be the correct thing to do even on those platforms.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.
The move also revealed that we actually don't include this register in
the error report, so fix that too.
v2:
- patch introduced in v2 of the patchset
v3:
- add back !HAS_PCH_SPLIT check (Ville)
[ Ignore my previous comment about the gen<=5 || vlv check, I realized
that it's the same as !HAS_PCH_SPLIT. ]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm-intel-next-2014-04-16:
- vlv infoframe fixes from Jesse
- dsi/mipi fixes from Shobhit
- gen8 pageflip fixes for LRI/SRM from Damien
- cmd parser fixes from Brad Volkin
- some prep patches for CHV, DRRS, ...
- and tons of little things all over
drm-intel-next-2014-04-04:
- cmd parser for gen7 but only in enforcing and not yet granting mode - the
batch copying stuff is still missing. Also performance is a bit ... rough
(Brad Volkin + OACONTROL fix from Ken).
- deprecate UMS harder (i.e. CONFIG_BROKEN)
- interrupt rework from Paulo Zanoni
- runtime PM support for bdw and snb, again from Paulo
- a pile of refactorings from various people all over the place to prep for new
stuff (irq reworks, power domain polish, ...)
drm-intel-next-2014-04-04:
- cmd parser for gen7 but only in enforcing and not yet granting mode - the
batch copying stuff is still missing. Also performance is a bit ... rough
(Brad Volkin + OACONTROL fix from Ken).
- deprecate UMS harder (i.e. CONFIG_BROKEN)
- interrupt rework from Paulo Zanoni
- runtime PM support for bdw and snb, again from Paulo
- a pile of refactorings from various people all over the place to prep for new
stuff (irq reworks, power domain polish, ...)
Conflicts:
drivers/gpu/drm/i915/i915_gem_context.c
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector->encoder->base).
Only one of those connectors should be active (ie link to the encoder
thru drm_connector->encoder).
If intel_connector_break_all_links() is called from intel_sanitize_crtc()
we may break the crtc connection of an encoder thru an inactive connector
in which case intel_connector_break_all_links() will not be called again
for the active connector if this happens to come later in the list due to:
if (connector->encoder->base.crtc != &crtc->base)
continue;
in intel_sanitize_crtc().
This will however leave the drm_connector->encoder linkage for this
active connector in place. Subsequently this will cause multiple
warnings in intel_connector_check_state() to trigger and the driver
will eventually die in drm_encoder_crtc_ok() (because of crtc == NULL).
To avoid this remove intel_connector_break_all_links() and move its
code to its two calling functions: intel_sanitize_crtc() and
intel_sanitize_encoder().
This allows to implement the link breaking more flexibly matching
the surrounding code: ie. in intel_sanitize_crtc() we can break the
crtc link separatly after the links to the encoders have been
broken which avoids above problem.
This regression has been introduced in:
commit 2492935248
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jul 2 20:28:59 2012 +0200
drm/i915: read out the modeset hw state at load and resume time
so goes back to the very beginning of the modeset rework.
v2: This patch takes care of the concernes voiced by Chris Wilson
and Daniel Vetter that only breaking links if the drm_connector
is linked to an encoder may miss some links.
v3: move all encoder handling to encoder loop as suggested by
Daniel Vetter.
Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the gmch_pfit state to
it.
3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.
-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The pipe is off at that point in time, so a vblank wait is simply a
50ms wait. Caught by Jesse's verbose "make vblank wait timeouts WARN"
patch. We've probably had a few versions of this float around already.
To document assumptions put a pipe assert into the same place. And
also add a posting read.
If we ever decide to update the eld and infoframes while the pipe is
already on (e.g. for fastboot) then there's lots of work to do. So
better properly document all the hidden assumptions.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already do this for HSW, but doing it makes sense for everything else
as well. Extend it for ILK/SNB/IVB since that's where the new watermark
code is used.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77297
[danvet: Resolve conflict since I've plucked this out of the middle of
Ville's series.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like on hsw/bdw the pipe isn't actually running yet at this point.
This holds for both pch ports and the cpu edp port according to my
testing on ilk, snb and ivb.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77297
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a requirement added to the spec. This patch will prevent
persistent corruption on the display.
v2: Make the wait before the vblank wait. (Art)
Try to finish early by polling the register
s/present/prevent (Chris)
Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Upgrade debug output to ERROR.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
haswell_write_eld() is also used on broadwell, so let's not explicitely
mention Haswell. The rest of the function has plenty of debug output
which will print the function name, so we know where we are anyway.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment from Ben: It's a bit unclear whether we need this dance still
on bdw.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge drm-next after the big s/crtc->fb/crtc->primary->fb/
cocinelle patch to avoid endless amounts of conflict hilarity in my
-next queue for 3.16.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Merge window -fixes pull request as usual. Well, I did sneak in Jani's
drm_i915_private_t typedef removal, need to have fun with a big sed job
too ;-)
Otherwise:
- hdmi interlaced fixes (Jesse&Ville)
- pipe error/underrun/crc tracking fixes, regression in late 3.14-rc (but
not cc: stable since only really relevant for igt runs)
- large cursor wm fixes (Chris)
- fix gpu turbo boost/throttle again, was getting stuck due to vlv rps
patches (Chris+Imre)
- fix runtime pm fallout (Paulo)
- bios framebuffer inherit fix (Chris)
- a few smaller things
* tag 'drm-intel-fixes-2014-04-04' of git://anongit.freedesktop.org/drm-intel: (196 commits)
Skip intel_crt_init for Dell XPS 8700
drm/i915: vlv: fix RPS interrupt mask setting
Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec"
drm/i915: move power domain init earlier during system resume
drm/i915: Fix the computation of required fb size for pipe
drm/i915: don't get/put runtime PM at the debugfs forcewake file
drm/i915: fix WARNs when reading DDI state while suspended
drm/i915: don't read cursor registers on powered down pipes
drm/i915: get runtime PM at i915_display_info
drm/i915: don't read pp_ctrl_reg if we're suspended
drm/i915: get runtime PM at i915_reg_read_ioctl
drm/i915: don't schedule force_wake_timer at gen6_read
drm/i915: vlv: reserve the GT power context only once during driver init
drm/i915: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/overlay: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/ringbuffer: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/display: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/gem: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/dma: prefer struct drm_i915_private to drm_i915_private_t
...
There's no point in hiding the DP M/N setup in the update_pll functions.
Just move it to the mode_set function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less
flicker for fastbooting.
- More flexible cloning for hdmi (Ville).
- Some PPGTT fixes from Ben.
- Ring init fixes from Naresh Kumar.
- set_cache_level regression fixes for the vma conversion from Ville&Chris.
- Conversion to the new dp aux helpers (Jani).
- Unification of runtime pm with pc8 support from Paulo, prep work for runtime
pm on other platforms than HSW.
- Larger cursor sizes (Sagar Kamble).
- Piles of improvements and fixes all over, as usual.
* tag 'drm-intel-next-2014-03-21' of git://anongit.freedesktop.org/drm-intel: (75 commits)
drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64
drm/i915/sdvo: fix questionable return value check
drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
drm/i915: Print how many objects are shared in per-process stats
drm/i915: Per-process stats work better when evaluated per-process
drm/i915: remove rps local variables
drm/i915: Remove extraneous MMIO for RPS
drm/i915: Rename and comment all the RPS *stuff*
drm/i915: Store the HW min frequency as min_freq
drm/i915: Fix coding style for RPS
drm/i915: Reorganize the overclock code
drm/i915: init pm.suspended earlier
drm/i915: update the PC8 and runtime PM documentation
drm/i915: rename __hsw_do_{en, dis}able_pc8
drm/i915: kill struct i915_package_c8
drm/i915: move pc8.irqs_disabled to pm.irqs_disabled
drm/i915: remove dev_priv->pc8.enabled
drm/i915: don't get/put PC8 when getting/putting power wells
drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
Because if we keep the current code, we'll get tons of WARNs on
Broadwell, since the code is Haswell-specific.
We could have also added a Broadwell-specific code there, but it's not
really needed since we never disable LCPLL with the hotplug interrupts
still enabled. So keep the easy-and-simple-to-maintain solution until
we actually need something else.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC. Replace all references to the CRTC fb with the
primary plane's fb.
This patch was generated by the Coccinelle semantic patching tool using
the following rules:
@@ struct drm_crtc C; @@
- (C).fb
+ C.primary->fb
@@ struct drm_crtc *C; @@
- (C)->fb
+ C->primary->fb
v3: Generate patch via coccinelle. Actual removal of crtc->fb has been
moved to a subsequent patch.
v2: Fixup several lingering crtc->fb instances that were missed in the
first patch iteration. [Rob Clark]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Ensure that existing driver loops over all planes do not change behavior
when we begin adding new types of planes (primary and cursor) to the DRM
plane list in future patches.
v2: Switch to using drm_for_each_legacy_plane()
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
That's what the spec said! And HSW needs it through pcode (you can
only read it through MCHBAR), so create hsw_write_dcomp to abstract
the weirdness.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that PC8 is part of runtime PM, the check is useless.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just because I have a SNB machine and I can easily test it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we don't keep the hotplug interrupts enabled anymore, we can
kill the regsave struct and just cal the normal IRQ preinstall,
postinstall and uninstall functions. This makes it easier to add
runtime PM support to non-HSW platforms.
The only downside is in case we get a request to update interrupts
while they are disabled, won't be able to update the regsave struct.
But this should never happen anyway, so we're not losing too much.
v2: - Rebase.
v3: - Rebase.
v4: - Rebase.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These were apparently meant to protect the SAREA which only has
room for two pipes, but things clearly went a bit wonky when
first the .update_plane() hooks were split up and then pipe C
got introduced.
The checks actually protecting the SAREA live in
intel_crtc_update_sarea() these days, so the checks in the primary
plane update hooks are just historical leftovers which are to be
eliminated.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those values are, global, only used in one function and already stored
in mode_config.cursor_{width,height}.
As a result, this initialization code has been moved from the
crtc_init() function to the global modeset_init() one.
I also renamed CURSOR_{WIDTH,HEIGHT} to MAX_CURSOR_{WIDTH,HEIGHT} to be
more accurate about what these value really are.
Cc: Sagar Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of reading out the CD clock rate from the HW at each modeset, do
this only during driver init and resume and use the cached value during
modeset. This moves things towards a state where the sw and hw side
setup is separated. It's also needed for VLV RPM, where we don't put
device into D0 state until modeset_global_resources is called and thus
can't access any display/gfx registers.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we reserve/allocate and free the power context during GT power
enable/disable time. There is no need to do this, we can reserve/allocate
the buffer once during driver loading and free it during driver cleanup.
The re-reservation can also fail in case the driver previously manages to
allocate something on the given fixed address.
The buffer isn't exepected to move even if allocated by the BIOS, for
safety add an assert to check this assumption.
This also fixed a bug for Ville, where re-reserving the context failed
during a GPU reset (I assume because something else got allocated on its
fixed address).
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If vsyncshift comes out as negative, add one htotal to it to get the
corresponding positive value.
This is rather theoretical as it would require a mode where the
hsync+back porch is very long and the active+front porch very short.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PIPECONF_INTERLACE_W_FIELD_INDICATION is only meant to be used for sdvo
since it implies a slightly weird vsync shift of htotal/2. For everything
else we should use PIPECONF_INTERLACE_W_SYNC_SHIFT and let the value in
the VSYNCSHIFT register take effect.
The only exception is gen3 simply because VSYNCSHIFT didn't exist yet.
Gen2 doesn't support interlaced modes at all, so we can drop the
explicit gen2 checks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When interlaced sdvo output is used, vsyncshift should supposedly
be (htotal-1)/2. In reality PIPECONF/TRANSCONF will override it by
using the legacy vsyncshift interlace mode which causes the hardware
to ignore the VSYNCSHIFT register.
The only odd thing here is that on PCH platforms we program the
VSYNCSHIFT on both CPU and PCH, and it's not entirely clear if both
sides have to agree on the value or not. On the CPU side there's no
way to override the value via PIPECONF anymore, so if we want to make
the CPU side agree with the PCH side, we should probably program the
approriate value into VSYNCSHIFT manually. So let's do that, but for
now leave the PCH side to still use the legacy interlace mode in
TRANSCONF.
We can also drop the gen2 check since gen2 doesn't support interlaced
modes at all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This makes HDMI testers happier on VLV platforms. It may be that we
need it for any non-SVO platform, but I don't have any tests to back
that up, so I'm leaving other pre-ILK platforms alone for now.
Tested-by: "Clint Taylor <clinton.a.taylor@intel.com>"
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74964
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the cursor width is changed, we may need to recompute our WM to
prevent untold flickering. We hope that the registers are flushed on the
same vblank to prevent underruns...
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since
commit 5c673b60a9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Mar 7 20:34:46 2014 +0100
drm/i915: Don't enable display error interrupts from the start
we don't enable underrun interrupts any more at takeover time.
Unfortunately I've forgotten to also adjust the sw-side tracking.
Since the code assumes that disabled pipes have underrun reporting
enabled set the disable flag only on all pipes which are active at
takeover time. Without this underrun reporting wasn't enabled
correctly on the first modeset. Note that for fastboot this is another
piece of state that needs to be fixed up by enabling the underrung
reporting after watermarks have beend fixed up.
On ivb/hsw an additional effect of this regression was that also all
cpu crc reporting stopped working since the master error interrupt it
shared across all pipes and sources.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76150
[danvet: Augment the code comment and polish the commit message a bit,
as discussed with Jani.]
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: lu hua <huax.lu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With this patch we allow larger cursor planes of sizes 128x128
and 256x256.
v2: Added more precise check on size while setting cursor plane.
v3: Changes related to restructuring cursor size restrictions
and DRM_DEBUG usage.
v4: Indentation related changes for setting cursor control and
implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT
Testcase: igt/kms_cursor_crc
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: G, Pallavi <pallavi.g@intel.com>
Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that PC8 got much simpler, there are less things to document.
Also, runtime PM already has a nice documentation, so we don't need to
re-explain it on our driver.
v2: - Rebase.
- Fix typo (Jesse).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After we removed all the intermediate abstractions, we can rename
these functions to just hsw_{en,dis}able_pc8.
v2: - Rebase.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When other platforms add runtime PM support they will also need to
disable interrupts, so move the variable to the runtime PM struct.
Also notice that the longer-term goal is to completely kill the
regsave struct, and I even have patches for that.
v2: - Rebase.
v3: - Rebase.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It was just being used on debugfs and on a WARN inside
hsw_set_power_well. But now that we PC8 is part of runtime PM and we
get/put runtime PM when we get/put any power domain, we shouldn't need
the WARN anymore.
v2: - Rebase.
v3: - Rebase.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because we already get/put runtime PM every time we get/put any power
domain, and now PC8 and runtime PM are the same thing.
With this, we can also now kill the hsw_{en,dis}able_package_c8
functions.
v2: - Rebase.
v3: - Rebase.
v4: - Rebase.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After the latest changes, the indirection is useless.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since after the latest patches it's only being used to prevent
getting/putting the runtime PM refcount.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of PC8 references. Now that both are the same thing and we
are killing PC8, just get the runtime PM reference.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The requirements_met variable was used to track two things: enabled
CRTCs and the power well. After the latest chagnes, we get a runtime
PM reference whenever we get any of the power domains, and we get
power domains when we enable CRTCs or the power well, so we should
already be covered, not needing this specific tracking.
v2: - Rebase.
v3: - Rebase.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, when our driver becomes idle for i915.pc8_timeout (default:
5s) we enable PC8, so we save some power, but not everything we can.
Then, while PC8 is enabled, if we stay idle for more
autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the
graphics device in D3 state, saving even more power. The two features
are separate things with increasing levels of power savings, but if we
disable PC8 we'll never get into D3.
While from the modularity point of view it would be nice to keep these
features as separate, we have reasons to merge them:
- We are not aware of anybody wanting a "PC8 without D3" environment.
- If we keep both features as separate, we'll have to to test both
PC8 and PC8+D3 code paths. We're already having a major pain to
make QA do automated testing of just one thing, testing both paths
will cost even more.
- Only Haswell+ supports PC8, so if we want to add runtime PM support
to, for example, IVB, we'll have to copy some code from the PC8
feature to runtime PM, so merging both features as a single thing
will make it easier for enabling runtime PM on other platforms.
This patch only does the very basic steps required to have PC8 and
runtime PM merged on a single feature: the next patches will take care
of cleaning up everything.
v2: - Rebase.
v3: - Rebase.
- Fully remove the deprecated i915 params since Daniel doesn't
consider them as part of the ABI.
v4: - Rebase.
- Fix typo in the commit message.
v5: - Rebase, again.
- Add a huge comment explaining the different forcewake usage
(Chris, Daniel).
- Use open-coded forcewake functions (Daniel).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we merge PC8 and runtime PM, these new functions are going to be
called by the runtime suspend/resume functions, and their callers are
going to be removed.
v2: - Rebase
Reviewed-by: Imre Deak <imre.deak@intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.
On a similar note, intel_display.c already had a function called
intel_disable_primary_plane() that programs the hardware to disable a
pipe's primary plane. When we hook up primary planes through the DRM
plane interface, one of the natural handler names will be
intel_primary_plane_disable(), which is very similar. To avoid
confusion, rename the existing intel_disable_primary_plane() to
intel_disable_primary_hw_plane() to make the two names a little more
distinct.
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
[danvet: Fix up conflicts.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTJlUvAAoJEHm+PkMAQRiGOhYH/1I+Bc7N7Rjr6QQAtBIy0GPC
XMqSE/gpgxlvRneQbQsvTUlPnWRhgzLGendT9HFKawkaQ0UNuZdRVyBHGFmpuED8
RlbicVVuuEZabrxEnCd7UPvYvEyK5pLIFpCRs5B+ManB1qLki2Ar03ymH1NRxOde
edmPbSUFo2aONITrEBm7tqT3cShTmBaDGP/zU0TNDMNrpVVDbHZolSNu2z4xOTa5
GqAOEbluLQ6jP3yxWur/V3Lk3W7pB6TabfX4o6UZu0F3iFnJxRMIzHXrI3o4yLTj
HEwmB3npfc8DIUk4oik7RkN+aqxDcdg/rBLQD63+xxt6zCkP+0q16brC0R67qWE=
=n9Ml
-----END PGP SIGNATURE-----
Merge tag 'v3.14-rc7' into drm-next
Linux 3.14-rc7
Backmerge to help out Intel guys.
Conflicts:
drivers/gpu/drm/i915/Makefile
Makefile cleanup in drm-intel-next conflicts with a build-fix to move
intel_opregion under CONFIG_ACPI.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't need to hold struct_mutex all through intel_pipe_set_base(),
just need to hold it while pinning/unpinning the buffers.
So reduce the struct_mutext usage in intel_pipe_set_base() just like we
did for the sprite code in:
commit 82284b6bec
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Tue Oct 1 18:02:12 2013 +0300
drm/i915: Reduce the time we hold struct mutex in sprite update_plane code
The FBC and PSR locking is still entirely fubar. That stuff was
previouly done while holding struct_mutex, so leave it there for now.
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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTHSaRAAoJEHm+PkMAQRiG7G8IAJHElwFDNSQE7Y9MmbicrAMG
kfjhBtBpTaVrJKQXegCNUwDaLLyC4oLIxDheW84oPXbrEGDLqPtBov/hrcFkHVr4
lh/ZYk02nYtcfpN0JnL/Yj2oKHVmBWs0vFlM7StSFsJCj10DoCVQQdmAJ8XODTPo
CXMapk+UikTX1TlIO8+B5toyl3R1OqPmW211UV1vQVLKy66hu+MKVN/V+/EyopL0
1jO81EDpaRaeIJh1/okcyUoIq9pqLkAWNpeQ7uyXZ+Sfivt9RXwLYKmAB3lP20Hc
ZMIIoHSCyYRFjxLlQvt02bA9nY4wTY7YN5kZ2kk65y7TFfhcGsCw1Sc69iyCoKs=
=CJcA
-----END PGP SIGNATURE-----
Merge tag 'v3.14-rc6' into drm-intel-next-queued
Linux 3.14-rc6
I need the hdmi/dvi-dual link fixes in 3.14 to avoid ugly conflicts
when merging Ville's new hdmi cloning support into my -next tree
Conflicts:
drivers/gpu/drm/i915/Makefile
drivers/gpu/drm/i915/intel_dp.c
Makefile cleanup conflicts with an acpi build fix, intel_dp.c is
trivial.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we allow encoders to indicate whether they can be part of a
cloned set with just one flag. That's not flexible enough to describe
the actual hardware capabilities. Instead make it a bitmask of encoder
types with which the current encoder can be cloned.
For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should
match what the old boolean flag allowed. We will add some more cloning
options in the future.
Note that this patch also removes the encoder.possible_clones setting
from encoder setup code - we compute this dynamically.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add Ville's explanation why removing the encoder
possible_clones is save.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The stolen allocator objects loudly if the caller requests a zero-sized
object. This is a useful verbose check as in most cases the request
should have been pruned much early. Here we just want to silently return
before attempting the allocation.
Regression from
commit 484b41dd70
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:55 2014 -0800
drm/i915: remove early fb allocation dependency on CONFIG_FB v2
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75963
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During KMS takeover, we try to capture the current configuration and
preserve it across our initialisation. For a variety of reasons, we may
fail this, for example if the current mode was using the legacy VGA
plane. Under such circumstances, we discard the fb in the plane config
and tried to find a matching fb on another CRTC. This obviously also
failed, leaving the plane config fb dangling, pointing to the freed block.
Regression from
commit 484b41dd70
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:55 2014 -0800
drm/i915: remove early fb allocation dependency on CONFIG_FB v2
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75963
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By stuffing the fb allocation into the crtc, we get mode set lifetime
refcounting for free, but have to handle the initial pin & fence
slightly differently. It also means we can move the shared fb handling
into the core rather than leaving it out in the fbdev code.
v2: null out crtc->fb on error (Daniel)
take fbdev fb ref and remove unused error path (Daniel)
Requested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fixup aperture and cmap frees (Imre)
use unlocked unref if init_bios fails (Jesse)
fix curly brace around DSPADDR check (Imre)
comment failure path for pin_and_fence (Imre)
v3: fixup fixup of aperture frees (Chris)
v4: update to current bits (locking & pin_and_fence hack) (Jesse)
v5: move fb config fetch to display code (Jesse)
re-order hw state readout on initial load to suit fb inherit (Jesse)
re-add pin_and_fence in fbdev code to make sure we refcount properly (Je
v6: rename to plane_config (Daniel)
check for valid object when initializing BIOS fb (Jesse)
split from plane_config readout and other display changes (Jesse)
drop use_bios_fb option (Chris)
update comments (Jesse)
rework fbdev_init_bios for clarity (Jesse)
drop fb obj ref under lock (Chris)
v7: use fb object from plane_config instead (Ville)
take ref on fb object (Jesse)
v8: put under i915_fastboot option (Jesse)
fix fb ptr checking (Jesse)
inform drm_fb_helper if we fail to enable a connector (Jesse)
drop unnecessary enabled[] modifications in failure cases (Chris)
split from BIOS connector config readout (Daniel)
don't memset the fb buffer if preallocated (Chris)
alloc ifbdev up front and pass to init_bios (Chris)
check for bad ifbdev in restore_mode too (Chris)
v9: fix up !fastboot bpp setting (Jesse)
fix up !fastboot helper alloc (Jesse)
make sure BIOS fb is sufficient for biggest active pipe (Jesse)
v10:fix up size calculation for proposed fbs (Chris)
go back to two pass pipe fb assignment (Chris)
add warning for active pipes w/o fbs (Chris)
clean up num_pipes checks in fbdev_init and fbdev_restore_mode (Chris)
move i915.fastboot into fbdev_init (Chris)
v11:make BIOS connector config usage unconditional (Daniel)
v12:fix up fb vs pipe size checking (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should allow BIOS fb inheritance to work on ILK+ machines too.
v2: handle tiled BIOS fbs (Kristian)
split out common bits (Jesse)
v3: alloc fb obj out in _init
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
v2: update for new pitch_for_width function (Jesse)
comment how get_plane_config works with shared fbs (Jesse)
v3: s/ARGB/XRGB (Ville)
use pipesrc width/height (Ville)
fix fourcc comment (Bob)
use drm_format_plane_cpp (Ville)
v4: use fb for tracking fb data object (Ville)
v5: fix up gen2 pitch limits (Ville)
v6: read out stride as well (Daniel)
v7: split out init ordering changes (Daniel)
don't fetch config if !CONFIG_FB
v8: use proper height in get_plane_config (Chris)
v9: fix CONFIG_FB check for modular configs (Jani)
v10: add comment about stolen allocation stomping
v11: drop hw state readout hunk (Daniel)
v12: handle tiled BIOS fbs (Kristian)
pull out common bits (Jesse)
v13: move fb obj alloc out to _init
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Early at init time, we can try to read out the plane config structure
and try to preserve it if possible.
v2: alloc fb obj at init time after fetching plane config
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on an early draft from Jesse.
Add support for powering on/off the dynamic power wells on VLV by
registering its display and dpio dynamic power wells with the power
domain framework.
For now power on all PHY TX lanes regardless of the actual lane
configuration. Later this can be optimized when the PHY side setup
enables only the required lanes. Atm, it enables all lanes in all
cases.
v2:
- undef function local COND macro after its last use (Ville)
- Take dev_priv->irq_lock around the whole sequence of
intel_set_cpu_fifo_underrun_reporting_nolock() and
valleyview_disable_display_irqs(). They are short and releasing
the lock in between only makes proving correctness more difficult.
- sanitize local var names in vlv_power_well_enabled()
v3:
- rebase on latest -nightly
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict due to my changes in the previous patch.
Also throw in an assert_spin_locked for safety. And finally appease
checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can read out the pipe HW state only if the required power domain is
on. If not we consider the pipe to be off.
v2:
- no change
v3:
- push down the power domain checks into the specific crtc
get_pipe_config handlers (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Parts that poke port specific HW blocks like the encoder HW state
readout or connector hotplug detect code need a way to check whether
required power domains are on or enable/disable these. For this purpose
add a set of power domains that refer to the port HW blocks. Get the
proper port power domains during modeset.
For now when requesting the power domain for a DDI port get it for a 4
lane configuration. This can be optimized later to request only the 2
lane power domain, when proper support is added on the VLV PHY side for
this. Atm, the PHY setup code assumes a 4 lane config in all cases.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions will be needed by the valleyview specific power well
update functionality added in an upcoming patch, so move them earlier.
No functional change.
v2:
- no change
v3:
- rebase on latest -nightly
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This macro is similar to for_each_pipe() we already have. Convert the
two call sites we have at the same time.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I recently fumbled a patch because I wrote twice num_sprites[i], and it
was the right thing to do in only 50% of the cases.
This patch ensures I need to write num_sprites[pipe], ie it should be
self-documented that it's per-pipe number of sprites without having to
look at what is 'i' this time around.
It's all a lame excuse, but it does make it harder to redo the same
mistake.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we need precisely N lanes to satisfy the FDI bandwidth requirement,
the code would still claim that we need N+1 lanes. Use DIV_ROUND_UP()
to get a more accurate answer.
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>
After a hang and failed reset, we cannot use the GPU to execute the page
flip instructions. Instead we can force a synchronous mmio flip. (Later,
we can reduce the synchronicity of the mmio flip by moving some of the
delays off to a worker, like the current page flip code; see vblank
tasks.)
References: https://bugs.freedesktop.org/show_bug.cgi?id=72631
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>
Since the addition of dev_priv->mm.busy, there's no more need for
dev_priv->pc8.gpu_idle, so kill it.
Notice that when you remove gpu_idle, hsw_package_c8_gpu_idle and
hsw_package_c8_gpu_busy become identical to hsw_enable_package_c8 and
hsw_disable_package_c8, so just use them.
Also, when we boot the machine, dev_priv->mm.busy initially considers
the machine as idle. This is opposed to dev_priv->pc8.gpu_idle, which
considered it busy. So dev_priv->pc8.disable_count has to be
initalized to 1 now.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because intel_mark_idle still touches some registers: it needs the
machine to be awake. If you set both the autosuspend and PC8 delays to
zero, you can get a "Device suspended" WARN when gen6_rps_idle touches
registers.
This is not easy to reproduce, but happens once in a while when
running pm_pc8.
Testcase: igt/pm_pc8
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently call intel_mark_idle() too often, as we do so as a
side-effect of processing the request queue. However, we the calls to
intel_mark_idle() are expected to be paired with a call to
intel_mark_busy() (or else we try to idle the hardware by accessing
registers that are already disabled). Make the idle/busy tracking
explicit to prevent the multiple calls.
v2: We can drop some of the complexity in __i915_add_request() as
queue_delayed_work() already behaves as we want (not requeuing the item
if it is already in the queue) and mark_busy/mark_idle imply that the
idle task is inactive.
v3: We do still need to cancel the pending idle task so that it is sent
again after the current busy load completes (not in the middle of it).
Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This way we can reuse the check on other platforms too. Also factor out
a version of the function that doesn't check if the power is on, we'll
need to call this from within the power domain framework.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The power domains framework is internal to the i915 driver, so pass
drm_i915_private instead of drm_device to its functions.
Also remove a dangling intel_set_power_well() declaration.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should be impossible due to the wait for outstanding flips that the
caller is meant to perform prior to updating the scanout base. Paranoia
tells me to check anyway.
References: https://bugs.freedesktop.org/show_bug.cgi?id=75502
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To silence locking complaints. This was a rebase failure on my part in
commit fa9fa083d0
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Feb 11 15:28:56 2014 -0800
drm/i915: read out hw state earlier v2
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To modeset_update_crtc_power_domains, since this function is
responsible for updating all the power domains of all CRTCs after a
modeset. In the future we should also run this function on all
platforms, not just Haswell.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Fix the execbuf rebind performance regression due to topic/ppgtt (Chris).
- Fix up the connector cleanup ordering for sdvod i2c and dp aux devices (Imre).
- Try to preserve the firmware modeset config on driver load. And a bit of prep
work for smooth takeover of the fb contents (Jesse).
- Prep cleanup for larger gtt address spaces on bdw (Ben).
- Improve our vblank_wait code to make hsw modesets faster (Paulo).
- Display debugfs file (Jesse).
- DRRS prep work from Vandana Kannan.
- pipestat interrupt handler to fix a few races around vblank/pageflip handling
on byt (Imre).
- Improve display fuse handling for display-less SKUs (Damien).
- Drop locks while stalling for the gpu when serving pagefaults to improve
interactivity (Chris).
- And as usual piles of other improvements and small fixes all over.
* tag 'drm-intel-next-2014-02-14' of ssh://git.freedesktop.org/git/drm-intel: (65 commits)
drm/i915: fix NULL deref in the load detect code
drm/i915: Only bind each object rather than for every execbuffer
drm/i915: Directly return the vma from bind_to_vm
drm/i915: Simplify i915_gem_object_ggtt_unpin
drm/i915: Allow blocking in the PDE alloc when running low on gtt space
drm/i915: Don't allocate context pages as mappable
drm/i915: Handle set_cache_level errors in the status page setup
drm/i915: Don't pin the status page as mappable
drm/i915: Don't set PIN_MAPPABLE for legacy ringbuffers
drm/i915: Handle set_cache_level errors in the pipe control scratch setup
drm/i915: split PIN_GLOBAL out from PIN_MAPPABLE
drm/i915: Consolidate binding parameters into flags
drm/i915: sdvo: add i2c sysfs symlink to the connector's directory
drm/i915: sdvo: fix error path in sdvo_connector_init
drm/i915: dp: fix order of dp aux i2c device cleanup
drm/i915: add unregister callback to connector
drm/i915: don't reference null pointer at i915_sink_crc
drm/i915/lvds: Remove dead code from failing case
drm/i915: don't preserve inherited configs with nothing on v2
drm/i915/bdw: Split up PPGTT cleanup
...
We need to read the correct register, not a register that doesn't exist
and will trigger "Unclaimed register" messages when we touch it.
Also rearrange the checks in an attempt to prevent this error from
happening again.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[Jani: dropped an extra empty line introduced.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Apparently we've missed a few more than what Fengguang's 0-day tester
recently reported in i915_irq.c ... Makes sparse happy again (ignore
some spurious stuff about ksyms of exported functions).
Cc: kbuild test robot <fengguang.wu@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Yet more steps towards atomic modeset from Ville.
- DP panel power sequencing improvements from Paulo.
- irq code cleanups from Ville.
- 5.4 GHz dp lane clock support for bdw/hsw from Todd.
- Clock readout support for hsw/bdw (aka fastboot) from Jesse.
- Make pipe underruns report at ERROR level (Ville). This is to check our
improved watermarks code.
- Full ppgtt support from Ben for gen7.
- More fbc fixes and improvements from Ville all over the place, unfortunately
not yet enabled by default on more platforms.
- w/a cleanups from Ville.
- HiZ stall optimization settings (Chia-I Wu).
- Display register mmio offset refactor patch from Antti.
- RPS improvements for corner-cases from Jeff McGee.
* tag 'drm-intel-next-2014-02-07' of ssh://git.freedesktop.org/git/drm-intel: (166 commits)
drm/i915: Update rps interrupt limits
drm/i915: Restore rps/rc6 on reset
drm/i915: Prevent recursion by retiring requests when the ring is full
drm/i915: Generate a hang error code
drm/i915: unify FLIP_DONE macro names
drm/i915: vlv: s/spin_lock_irqsave/spin_lock/ in irq handler
drm/i915: factor out valleyview_pipestat_irq_handler
drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt
drm/i915: Reorganize display pipe register accesses
drm/i915: Treat using a purged buffer as a source of EFAULT
drm/i915: Convert EFAULT into a silent SIGBUS
drm/i915: release mutex in i915_gem_init()'s error path
drm/i915: check for oom when allocating private_default_ctx
drm/i915/vlv: WA to fix Voltage not getting dropped to Vmin when Gfx is power gated.
drm/i915: Get rid of acthd based guilty batch search
drm/i915: Use hangcheck score to find guilty context
drm/i915: Drop WaDisablePSDDualDispatchEnable:ivb for IVB GT2
drm/i915: Fix IVB GT2 WaDisableDopClockGating and WaDisablePSDDualDispatchEnable
drm/i915: Don't access snooped pages through the GTT (even for error capture)
drm/i915: Only print information for filing bug reports once
...
Conflicts:
drivers/gpu/drm/i915/intel_dp.c
3 fixes plus 1 prep patch, all four cc: stable. Jani will take over from
here and the plan is that he'll do 3.14-fixes for the entire release just
to work things out a bit.
* tag 'drm-intel-fixes-2014-02-14' of ssh://git.freedesktop.org/git/drm-intel:
drm/i915/dp: add native aux defer retry limit
drm/i915/dp: increase native aux defer retry timeout
drm/i915: Prevent MI_DISPLAY_FLIP straddling two cachelines on IVB
drm/i915: Add intel_ring_cachline_align()
Spotted while auditing the code for fencing issues.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks like I've missed one of the potential NULL deref bugs in Jesse's
fbdev->fb embedded struct to pointer conversions. Fix it up.
This regression has been introduced in
commit 8bcd45534d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Feb 7 12:10:38 2014 -0800
drm/i915: alloc intel_fb in the intel_fbdev struct
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since
commit d9255d5714
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Sep 26 20:05:59 2013 -0300
it became clear that we need to separate the unload sequence into two
parts:
1. remove all interfaces through which new operations on some object
(crtc, encoder, connector) can be started and make sure all pending
operations are completed
2. do the actual tear down of the internal representation of the above
objects
The above commit achieved this separation for connectors by splitting
out the sysfs removal part from the connector's destroy callback and
doing this removal before calling drm_mode_config_cleanup() which does
the actual tear-down of all the drm objects.
Since we'll have to customize the interface removal part for different
types of connectors in the upcoming patches, add a new unregister
callback and move the interface removal part to it.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We assign the sarea_priv pointer only in the dma ioctl, which is
disallowed when kernel modesetting is enabled. So this is dead code.
Cc: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BIOS or boot loader will generally create an initial display
configuration for us that includes some set of active pipes and
displays. This routine tries to figure out which pipes and connectors
are active and stuffs them into the crtcs and modes array given to us by
the drm_fb_helper code.
The overall sequence is:
intel_fbdev_init - from driver load
intel_fbdev_init_bios - initialize the intel_fbdev using BIOS data
drm_fb_helper_init - build fb helper structs
drm_fb_helper_single_add_all_connectors - more fb helper structs
intel_fbdev_initial_config - apply the config
drm_fb_helper_initial_config - call ->probe then register_framebuffer()
drm_setup_crtcs - build crtc config for fbdev
intel_fb_initial_config - find active connectors etc
drm_fb_helper_single_fb_probe - set up fbdev
intelfb_create - re-use or alloc fb, build out fbdev structs
v2: use BIOS connector config unconditionally if possible (Daniel)
check for crtc cloning and reject (Daniel)
fix up comments (Daniel)
v3: use command line args and preferred modes first (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Re-add the WARN_ON for a missing encoder crtc - the state
sanitizer should take care of this. And spell-ocd the comments.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to reuse this in the fbdev initial config code independently
from any fastboot hacks. So allow a bit more flexibility.
v2: Forgot to git add ...
v3: make non-static (Jesse)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to do this early on before we try to fetch the plane config,
which depends on some of the pipe config state.
Note that the important part is that we do this before we initialize
gem, since otherwise we can't properly pre-reserve the stolen memory
for framebuffers inherited from the bios.
v2: split back out from get_plane_config change (Daniel)
update for recent locking & reset changes (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Explain a bit more why we need to move this.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and QUIRK_PIPEA_FORCE is not present.
I initially thought that case was impossible and just added a WARN on
it, but then I was told this case is possible due to
QUIRK_PIPEA_FORCE. So let's add a WARN that serves two purposes:
- tell us in case we have done something wrong;
- document the only case where we expect this.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a nice comment explaining why we shouldn't wait for a vblank on
all cases, wait based on the HW gen, and add a comment saying we
should probably skip that wait on some of the previous HW gens.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we pass struct intel_crtc as an argument, we can check for
DSI inside the function, removing one more of those confusing boolean
arguments.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we pass struct intel_crtc as an argument, there's no need for
it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to remove those 3 boolean arguments. This is the first step.
The "pipe" passed as the argument is always intel_crtc->pipe.
Also adjust the function documentation.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When I forked haswell_crtc_enable I copied all the code from
ironlake_crtc_enable. The last piece of the function contains a big
comment with a call to intel_wait_for_vblank. After this fork, we
rearranged the Haswell code so that it enables the planes as the very
last step of the modeset sequence, so we're sure that we call
intel_enable_primary_plane after the pipe is really running, so the
vblank waiting functions work as expected. I really believe this is
what fixes the problem described by the big comment, so let's give it
a try and get rid of that intel_wait_for_vblank, saving around 16ms
per modeset (and init/resume). We can always revert if needed :)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because on Haswell, the pipe is never running at this point, so we hit
the 50ms timeout waiting for nothing. We already have two other places
where we wait for vblanks on haswell_crtc_enable, so we're safe.
This gets us rid of one instance of "vblank wait timed out" for each
mode set, which means driver init and resume are also 50ms faster.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Depending on the HW gen and the connector type, the pipe won't start
running right after we call intel_enable_pipe, so that
intel_wait_for_vblank call we currently have will just sit there for
the full 50ms timeout. So this patch adds an argument that will allow
us to avoid the vblank wait in case we want. Currently all the callers
still request for the vblank wait, so the behavior should still be the
same.
We also added a POSTING_READ on the register: previously
intel_wait_for_vblank was acting as a POSTING_READ, but now if
wait_for_vblank is false we'll stkip it, so we need an explicit
POSTING_READ.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For use by get_plane_config.
v2: cleanup tile_height bits (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Jesse's patch to switch the fbdev framebuffer from an embedded
struct to a pointer the kfree in case of an error was missed. Fix this
up by using our own internal fb allocation helper directly instead of
reinventing that wheel.
We need a to_intel_framebuffer cast unfortunately since all the other
callers of _create still look better whith using a drm_framebuffer as
return pointer.
v2: Add an unlocked __intel_framebuffer_create function since our
dev->struct_mutex locking is too much a mess. With ppgtt we even need
it to take a look at the global gtt offset of pinned objects, since
the vma list might chance from underneath us. At least with the
current global gtt lookup functions. Reported by Mika.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that it's a normally kmalloce buffer we can use the usual cleanup
paths. The upside here is that if we get the refcounting wrong will be
able to catch it, since the drm core will complain about leftover
framebuffers and kref about underflows.
v2: Kill intel_framebuffer_fini - no longer needed now that we
refcount all fbs properly and only confusing.
v3: We actually still need to call unregister_private to remove the fb
from the idr and drop the idr reference - the final unref doesn't do
that. So much for remembering my own fb liftime rules. Reported by
Imre Deak.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Touching the VGA registers risks a hard machine hang, at least on this
ivb machine after removing a conflicting efifb. This is more than likely
related to the discovery that VGA IO decode on the more recent PCH
platforms is terminally broken.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has very little effect other than log the errors in case of failure,
and we then hope for the best.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allocate this struct instead, so we can re-use another allocated
elsewhere if needed.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: WARN_ON if there's no backing storage attached to an fb,
that's a bug.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We had 2 set of defines for the same register, so make it one.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And rename it to num_sprites as this value doesn't count the primary
plane.
This limit lives with num_pipes really, and now that dev_priv->info is
writable we can put it there instead.
While at it, introduce a intel_device_info_runtime_init() where we'll be
able to gather the device info fields at run-time.
v2: rename num_plane to num_sprites (Ville Syrjälä)
v3: rebase on top of latest drm-nightly
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v2)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v2)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we make sure that all the dev_priv->info usages are wrapped by
INTEL_INFO(), we can easily modify the ->info field to be structure and
not a pointer while keeping the const protection in the INTEL_INFO()
macro.
v2: Rebased onto latest drm-nightly
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to BSpec the entire MI_DISPLAY_FLIP packet must be contained
in a single cacheline. Make sure that happens.
v2: Use intel_ring_begin_cacheline_safe()
v3: Use intel_ring_cacheline_align() (Chris)
Cc: Bjoern C <lkml@call-home.ch>
Cc: Alexandru DAMIAN <alexandru.damian@intel.com>
Cc: Enrico Tagliavini <enrico.tagliavini@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74053
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge drm-next - I need to backmerge drm-intel-fixes patches
touching the error capture code to be able to merge Ben's cleanup
patches.
Conflicts:
drivers/gpu/drm/i915/i915_gpu_error.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJS4TK6AAoJEN0jrNd/PrOhwXoP/i09xa9CKOnpy8Ewdmgi5gBt
vnjzqjwmHzZRpNeWw2xvcqzv5kKgXkpPdMhNUjErlJTUC1S6uCf/Uj+ExppYYysW
7uxNjPQQc6jgX+0342MabKITeZyTk9iEWPqTDtHDP5O2vXi4XSaQTMm9HpWGe1qZ
1CTb0yJc1epXGJPutlqhJSZgKwzrs6Pm2Q/nsTdxpGPAoTQj9J0NebDaZwJmmFGi
qNyfI4DVBp1sj8AgtUkQQn9x5oLDpdvHKLPHsAWgHnNTKqRxY8C0EL+S2TYGa812
sx8jvZgjvBoPuwaOr4hcOx91OFdfOoKVap9D/corU+UjstF9lTd+PvAHzZMO5qte
yQhWmYFn1gGr/I9b9K/mAB98s83W7lMmSs/7HtiawvLtogZ/t8xvSp94R7X8SGd1
wYcw3NqzgDxrcpJjDOsLIw1Pa4PxXoChtV0SfiaEoVlGn5WSONS/8cKeNwbO6e9D
gKkd/zvCMsYqHt7p8zDizcQKi4W+8zYiZySOfLohZzhf0qaoQnnD5yirfiIpljqA
Ql40F4XP3OF3CliikcSwFhvrTUCLb08Ol0MV6FX1H1iMae0dgiFqtz7AihFTbKHZ
PQeskMgEemxhIqKEsH0JcpV3+YxLRlWy/3I+OO7QczsL0xKD30FQ9Xhsu9EFx8gu
jXVvMDldeefaVBuTdqCb
=NfNj
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.14-rc1 (update)
These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).
* tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Obtain head number from DT
drm/panel: update EDID BLOB in panel_simple_get_modes()
gpu: host1x: Remove unnecessary include
drm/tegra: Use proper data type
drm/tegra: Clarify how panel modes override others
drm/tegra: Fix possible CRTC mask for RGB outputs
drm/i915: Use drm_encoder_crtc_ok()
drm: Move drm_encoder_crtc_ok() to core
drm: provide a helper for the encoder possible_crtcs mask
drm/tegra: Don't check resource with devm_ioremap_resource()
drm/panel: Add support for Chunghwa CLAA101WA01A panel
drm/panel: Add support for Samsung LTN101NT05 panel
With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.
Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".
The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:
$ git grep "i915\." -- drivers/gpu/drm/i915
v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we print all pipe underruns on GMCH platforms. Hook up the
same logic we use on PCH platforms where we disable the underrun
reporting after the first underrun.
Underruns don't actually generate interrupts themselves on GMCH
platforms, we just can detect them whenever we service other
interrupts. So we don't have any enable bits to worry about. We just
need to remember to clear the underrun status when enabling underrun
reporting.
Note that the underrun handling needs to be moved to the non-locked
pipe_stats[] loop in the interrupt handlers to avoid having to rework
the locking in intel_set_cpu_fifo_underrun_reporting().
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>
Now that we have DDI support, we can check these all the time.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since
commit ee1452d745
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Sep 20 15:05:30 2013 +0300
drm/i915: assume all GM45 Acer laptops use inverted backlight PWM
failed and was later reverted in
commit be505f6439
Author: Alexander van Heukelum <heukelum@fastmail.fm>
Date: Sat Dec 28 21:00:39 2013 +0100
Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"
fix the individual broken machine instead.
Note to backporters:
http://patchwork.freedesktop.org/patch/17837/
is the patch you want for 3.13 and older.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171
Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl
CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Patch mangling for 3.14 plus adding the link to the original
for 3.13.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we're doing the reset handling a bit late, and we're doing
it both in the driver load code and on resume. This makes it unusable
for e.g. resetting the panel power sequence state like Paulo wants to.
Instead of adding yet another single-use callback shuffle things
around:
- Output handling code is responsible to reset/init all state on its
own at driver load time.
- We call the reset functions much earlier, before we start using any
of the modeset code.
Compared to Paulo's new ->resume callback the only difference in
placement is that ->reset is still called without dev->struct_mutex
held. Which is imo a feature.
v2: Rebase on top of the now merge dinq.
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I forgot to set new_config and new_enabled appropriately in the load
detect code. Fix it up.
v2: Handle the other error path in intel_get_load_detect_pipe() too (Imre)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
crtc->new_config is only relevant for pipes that are going to be active
post-modeset. Set the pointer to NULL for all pipes that are going to
be disabled. This is done to help catch bugs where some piece of code
would go looking at crtc->new_config even if the data there is stale.
v2: Clear new_config in disable_crtc_nofb() too (Imre)
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the first modeset operation fails, we will attempt to restore the
previous configuration that we read out from the hardware. But as we
don't yet reconstruct the framebuffer information, we end up calling
the modeset code with an enabled crtc but with fb==NULL. This will
lead to an oops within the modeset code.
Check for NULL fb when restoring the configuration, and instead of
oopsing simply disable the pipe.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV we need to compute the new cdclk before we've updated the current
state. The code achieved that in a somewhat complex way. Now that we
have new_enabled and new_config, we can simplify the code quite a bit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a new_config pointer to intel_crtc which will point to the new pipe
config for said crtc while intel_crtc.config will still contain the old
config during first parts of the modeset operation. This is a step
towards having the entire new state available during the compute phase,
so that we can make accurate decisions about global resource usage.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add 'new_enabled' to intel_crtc and precompute it alongside new_encoder
and new_crtc. This will allow making decisions about shared resources
that are affected by the set of active pipes, before we've clobbered
anything for real.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 446f254566.
I've left the masking in the pageflip code since that seems to be some
useful piece of preemptive robustness.
Iirc I've merged this patch under the assumption that the BIOS leaves
some random gunk in the lower bits and gets unhappy if we trample on
them. We have quite a few case like this, so this made sense.
Now I've just learned that there's actual hardware features bits in
the low 12 bits, and the kernel needs to preserve them to allow a
userspace blob to do its job. Given Dave Airlie's clear stance on
userspace blob drivers I've quickly chatted with him and he doesn't
seem too happy. So let's revert this.
If there are indeed bits that we must preserve in this range then we
can ressurrect this patch, but with proper documentation for those
bits supplied. And we probably also need to think a bit about
interactions with our driver.
Cc: Armin Reese <armin.c.reese@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@linux.ie>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On older generations (gen2, gen3) the GPU requires fences for many
operations, such as blits. The display hardware also requires fences for
scanouts and this leads to a situation where an arbitrary number of
fences may be pinned by old scanouts following a pageflip but before we
have executed the unpin workqueue. This is unpredictable by userspace
and leads to random EDEADLK when submitting an otherwise benign
execbuffer. However, we can detect when we have an outstanding flip and
so cause userspace to wait upon their completion before finally
declaring that the system is starved of fences. This is really no worse
than forcing the GPU to stall waiting for older execbuffer to retire and
release their fences before we can reallocate them for the next
execbuffer.
v2: move the test for a pending fb unpin to a common routine for
later reuse during eviction
Reported-and-tested-by: dimon@gmx.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Update the pixel/line/frame duration information when we switch to the
new pipe config. This will keep the timestamping constants in better
sync with the real hardware state.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm core no longer uses crtc->hwmode, and neither does i915, so we can totally ignore it
in i915.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We don't really use hwmode anymore in i915, so eliminating its use
from the core code seems prudent. Just pass the appropriate mode
to drm_calc_timestamping_constants().
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Conflicts are getting out of hand, and now we have to shuffle even
more in -next which was also shuffled in -fixes (the call for
drm_mode_config_reset needs to move yet again).
So do a proper backmerge. I wanted to wait with this for the 3.13
relaese, but alas let's just do this now.
Conflicts:
drivers/gpu/drm/i915/i915_reg.h
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_pm.c
Besides the conflict around the forcewake get/put (where we chaged the
called function in -fixes and added a new parameter in -next) code all
the current conflicts are of the adjacent lines changed type.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The intel_encoder_crtc_ok() is a duplicate of the drm_encoder_crtc_ok()
function that used to be only available in the DRM CRTC helpers. It has
recently been moved to the core, so the duplicate can now be dropped.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
There's no LVDS port on 830M so don't go reading the LVDS control
register.
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>
PFIT_CONTROL doesn't exist on 830M, so avoid reading it in
i9xx_get_pfit_config().
Also assume that only mobile gen2/3 chipsets have a panel fitter. This
matches the documentation, but I didn't have real hardware to verify.
Gen4 docmentation is a bit inconsistent, but experimenetation on my
LPT machine suggests that the panel fitter is available on non-mobile
gen4 platforms. At least on this machine panel fitter appears works
just fine even on VGA output.
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>
VGA detection requires the reference clock to be on, so make sure this
is the case.
This fixes VGA hotplug/manual detection where all pipes are off and so
we would normally disable all clocks.
v2:
- Instead of disabling PSR clock gating, force the reference clock on
through the DPLL_A register. (Kin Chan S <kin.s.chan@intel.com>)
v3:
- Move enabling of the clock to intel_reset_dpio() and use the DPLL_B
register instead, where we already have a similar tweak for the CRI
clock. (Ville)
Reported-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_init_dpio() isn't called during resume, so we won't set the CRI
clock enable bit during that time. Move the enabling to
intel_reset_dpio() instead.
Note that the HW reset value for this bit is 1, so probably this patch
won't make any difference. We should still make the setting explicit,
since BIOS could change things under us.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The WA is mentioned in HSW's GAMMA_MODE register documentation, but
not on on BDW's documentation, so let's assume it is not needed there.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That we can use for debugging purposes.
v2: Use designated initializers for the 'names' array (Paulo Zanoni,
Jani Nikula).
Add a check in case the array has a hole (which can now remain
unnoticed with designated initializers) (Jani Nikula)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (for v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In some cases we have more than 1 connector associated to an encoder
(e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of
these connectors. If we only allowed modesets for connected connectors
we would never need this patch, but since we do allow modeset for
disconnected connectors we may see user space trying to set modes on
the two connectors attached to the same encoder, so we need to forbid
that.
This problem can be reproduced by running the following
intel-gpu-tools test case:
./kms_setmode --run-subtest clone-exclusive-crtc
Thanks to Daniel Vetter for providing a version of this patch on
pastebin.
Credits-to: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My OCD just couldn't let this slide. Spotted while reviewing Ville's
patch to only flip planes when we have FBC.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks like 830M doesn't quite like it when you try to move a plane from
one pipe to another. It seems that the plane's old pipe has to be active
even if the plane is already disabled, otherwise the relevant register
just won't accept new values.
The following commit:
commit 1f1c2e2468
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Nov 28 17:30:01 2013 +0200
drm/i915: Swap primary planes on gen2 for FBC
caused a regression on 830M. It will attempt to swap the planes when the
driver is loaded, but at that time only pipe A might be active, so plane
A gets disabled, but plane B won't get enabled since pipe B is not
active when we try to move the plane over to pipe A.
There's no reason to swap planes on 830M since it doesn't support
FBC. Change the logic a bit to limit the plane swapping to platforms
which actually support FBC. This should avoid getting a black screen on
830M.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the pipe A force quirk is applied the code will attempt to grab
a crtc mutex during intel_modeset_setup_hw_state(). If we're already
holding all crtc mutexes this will obviously deadlock every time.
So instead of using drm_modeset_lock_all() just grab the
mode_config.mutex. This is enough to avoid the unlocked mutex warnings
from certain lower level functions.
The regression was introduced in:
commit 0274766428
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Dec 2 11:08:06 2013 +0200
drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
[danvet: Add cc: stable since the offending commit has that, too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
LPT does have PCH refclk, but it's different form the IBX/CPT/PPT one
and doesn't use the same structs. It is wrong to have a message saying
that "LPT does not has PCH refclk" (sic). While at it, signal that we
only want this function on IBX/CPT/PPT by renaming it and adding a
WARN.
On HSW we also print "0 shared PLLs initialized", but we *do* have
shared PLLs on HSW (LCPLL, WRPLL, SPLL) and we *do* initialize them.
We just don't use "struct intel_shared_dpll". So remove the debug
message.
In the future we may want to rename all that "intel shared pll" code
to "ibx shared pll", but I'll leave this to another patch.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to Art, we don't have a way to read back the state reliably at
runtime, through the control reg or the mailbox, at least not without risking
disabling it again. So drop the readout and checking on BDW.
v2: drop TODO comment (Paulo)
move POSTING_READ of control reg under HSW branch in disable (Paulo)
always report IPS as enabled on BDW (Paulo)
References: https://bugs.freedesktop.org/show_bug.cgi?id=71906
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When fastbooting, we read out the pipe timings early on, and then in a
panel fitted config, disable the fitter later. But we weren't updating
the pipe src h/w, which meant the mouse cursor was clipped to the
pfitted size rather than the native size set later. Fix that up so the
cursor is visible in the new mode.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise we won't check the state until the next DPMS transition, which
may never happen.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're iterating over the CPU transcoders, so check for the correct
power domain.
This fixes many "unclaimed register" error messages.
This can be reproduced by the IGT test mentioned below, but we still
get a FAIL when we run it.
Testcase: igt/kms_lip/flip-vs-panning-vs-hang
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My Acer 8510TZ stops displaying anything when X starts with Linus' current
tree. I bisected it down to commit ee1452d745.
This patch reverts commit ee1452d745.
After the revert, everything works as before.
Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>
Reported-by: Dylan Borg <borgdylan@hotmail.com> (for a Acer Extensa 5635Z)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.
Note that the register is still marked as locked RO on Sandybridge, so
vgaarb is still dysfunctional.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The new HSW watermark code can now handle ILK/SNB/IVB as well, so
switch them over. Kill the old code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only need to init the reg offset for DPIO once, but we need to reset
DPIO at resume time and at init time.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just add an early init since we may need to access DPIO regs early on.
The init call in modeset_init_hw is also needed for the resume case,
when we need to reset DPIO to keep things happy.
v2: split reset and reg init
v3: split patches (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, PC8 is enabled at modeset_global_resources, which is called
after intel_modeset_update_state. Due to this, there's a small race
condition on the case where we start enabling PC8, then do a modeset
while PC8 is still being enabled. The racing condition triggers a WARN
because intel_modeset_update_state will mark the CRTC as enabled, then
the thread that's still enabling PC8 might look at the data structure
and think that PC8 is being enabled while a pipe is enabled. Despite
the WARN, this is not really a bug since we'll wait for the
PC8-enabling thread to finish when we call modeset_global_resources.
The spec says the CRTC cannot be enabled when we disable LCPLL, so we
had a check for crtc->base.enabled. If we change to crtc->active we
will still prevent disabling LCPLL while the CRTC is enabled, and we
will also prevent the WARN above.
This is a replacement for the previous patch named
"drm/i915: get/put PC8 when we get/put a CRTC"
Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
(cherry picked from commit 798183c547
from -next due to Dave's report.)
Reported-by: Dave Jones <davej@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The first piece, intel_ddi_pll_select, finds a PLL and assigns it to
the CRTC, but doesn't write any register. It can also fail in case it
doesn't find a PLL.
The second piece, intel_ddi_pll_enable, uses the information stored by
intel_ddi_pll_select to actually enable the PLL by writing to its
register. This function can't fail. We also have some refcount sanity
checks here.
The idea is that one day we'll remove all the functions that touch
registers from haswell_crtc_mode_set to haswell_crtc_enable, so we'll
call intel_ddi_pll_select at haswell_crtc_mode_set and then call
intel_ddi_pll_enable at haswell_crtc_enable. Since I'm already
touching this code, let's take care of this particular split today.
v2: - Clock on the debug message is in KHz
- Add missing POSTING_READ
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Bikeshed comments.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On my 855 machine the BIOS uses the following DPLL settings:
DPLL 0x90016000
FP0 = 0x61207
FP1 = 0x21207
With the 66MHz SSC refclock, that puts the BIOS generated VCO
frequency at ~908 MHz, which is lower than the 930 MHz limit
we have currently. This also results in the pixel clock coming
out significantly higher than the requested 65 MHz when we try
to recompute it.
Reduce the the VCO limit to 908 MHz. Combined with the earlier
SSC reference clock accuracy fix, this results in the pixel clock
coming out as 65.08 MHz which is quite close to the target. For
some reason the BIOS uses 64.881 MHz, which isn't quite as close.
This makes kms_flip wf_vblank-ts-check pass for the first time
on this machine \o/
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Store the SSC refclock frequency in kHz to get more accuracy. Currently
we're pretending that 66 MHz is ~66000 kHz, when in fact it is actually
~66667 kHz. By storing the less rounded kHz value we get a much better
accuracy for out pixel clock calculations.
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bruno Prémont has a 855 machine with a 1400x1050 LVDS screen.
The VBT mode is as follows:
0:"1400x1050" 0 108000 1400 1416 1528 1688 1050 1051 1054 1066 0x8 0xa
The BIOS uses the following DPLL settings:
DPLL = 0x90020000
FP0 = 0x2140e
FP1 = 0x21207
That puts the BIOS generated VCO frequency at 1512 MHz, which is
higher than the 1400 MHz limit we have currently.
Let's bump the VCO limit to 1512 MHz and see what happens.
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bruno Prémont has a 855 machine with a 1400x1050 LVDS screen.
The VBT mode is as follows:
0:"1400x1050" 0 108000 1400 1416 1528 1688 1050 1051 1054 1066 0x8 0xa
The BIOS uses the following DPLL settings:
DPLL = 0x90020000
FP0 = 0x2140e
FP1 = 0x21207
We can't generate that pixel clock currently as we're limiting the N
divider to at least 3, whereas the BIOS uses a value of 2.
Let's reduce the N minimum to 2 and see what happens.
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to determine the correct p2 divider for LVDS on gen2,
we need to check the CLKB mode from the LVDS port register to
determine if we're dealing with single or dual channel LVDS.
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The code to enable/disable PC8 already takes care of saving and
restoring all the registers we need to save/restore, so do a put()
call when we enable PC8 and a get() call when we disable it.
Ideally, in order to make it easier to add runtime PM support to other
platforms, we should move some things from the PC8 code to the runtime
PM code, but let's do this later, since we can make Haswell work right
now.
V2: - Rebase
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Don't actually enable runtime pm since I didn't merge all
patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current code was checking if all bits of "val" were enabled and
DE_PCH_EVENT_IVB was disabled. The new code doesn't care about the
state of DE_PCH_EVENT_IVB: it just checks if everything else is 1.
The goal is that future patches may completely disable interrupts, and
the LCPLL-disabling code shouldn't care about the state of
DE_PCH_EVENT_IVB.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: I think the commit message is actually wrong in it's
description of what the old test checked, but the new one seems sane.
So meh.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already have some checks and shouldn't be reaching these places on
!HAS_PC8 platforms, but add a WARN, just in case.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The CRI clock is related to the display PHY, so the setup belongs
in intel_init_dpio().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQEcBAABAgAGBQJSogqUAAoJEHm+PkMAQRiGM2MIAJrr5KEXEWuuAR4+JkkWBK7A
+dVT4n1MM4wP/aCIyriSlq7kgT03Wxk4Q4wKsj2wZvDQkNgEQjrctgIihc75jqi5
126nmT3YXJLwgDpFA3RHZUWve3j3vfUG53rRuk7K9Xx1sGWU3Ls7BuInvQZ//+QS
6UB4UuEAalmose5U8ToXQfMqZhjwreZKeb64TEZwFvu2klv4cnka1L/zHbmQGgRg
2Pfv+aUrjsYE8s9lkEKX8MIQsDn28Q5Lsv7XIEQwo2at4rYbJaxX6usuC1OI0MQ5
BLUn1GgtvOidq6FzSg6kXiA/MJYH3J0S+p4uULWAprxA+KeJRbWNRroM94W1qAk=
=1Wcq
-----END PGP SIGNATURE-----
Merge tag 'v3.13-rc3' into drm-intel-next-queued
Linux 3.13-rc3
I need a backmerge for two reasons:
- For merging the ppgtt patches from Ben I need to pull in the bdw
support.
- We now have duplicated calls to intel_uncore_forcewake_reset in the
setup code to due 2 different patches merged into -next and 3.13.
The conflict is silen so I need the merge to be able to apply
Deepak's fixup patch.
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Trivial conflict, it doesn't even show up in the merge diff.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, PC8 is enabled at modeset_global_resources, which is called
after intel_modeset_update_state. Due to this, there's a small race
condition on the case where we start enabling PC8, then do a modeset
while PC8 is still being enabled. The racing condition triggers a WARN
because intel_modeset_update_state will mark the CRTC as enabled, then
the thread that's still enabling PC8 might look at the data structure
and think that PC8 is being enabled while a pipe is enabled. Despite
the WARN, this is not really a bug since we'll wait for the
PC8-enabling thread to finish when we call modeset_global_resources.
The spec says the CRTC cannot be enabled when we disable LCPLL, so we
had a check for crtc->base.enabled. If we change to crtc->active we
will still prevent disabling LCPLL while the CRTC is enabled, and we
will also prevent the WARN above.
This is a replacement for the previous patch named
"drm/i915: get/put PC8 when we get/put a CRTC"
Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only plane A is FBC capable on gen2 (like gen3), but the panel fitter
is hooked up to pipe B, so we want to prefer pipe B + plane A.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add the code comment Chris requested in his review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't have clock state readout support for DDI, so skip the pipe
config clock checks on all DDI platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We call intel_modeset_setup_hw_state() along two paths, driver
load/resume and after a lid event notification. During initialisation of
the driver, it is imperative that we reset the config state. This
correctly sets up the initial connector statuses and prepares the
hardware for a thorough probing. However, during a lid event, we only
want to undo the damage caused by the bios by resetting our last known
mode. In this cirumstance, we do not want to clobber our desired state.
In order to try and keep sanity between the config state and our own
tracking, do the drm_mode_config_reset() first along the load/resume
paths before reading out the hw state and apply any definite known
corrections.
v2: "As discussed on irc I don't think we should force the connector
state to anything here: Imo connector->status should reflect what we
believe to be the true output connection state, whereas connector->encoder
reflects whether this connector is wired up to a pipe. And since we no
longer reject modeset on disconnected connectors and never nuked the pipe
if the connector gets disconnected there's no reason for that - such policy
is userspace's job.
This regression has been introduced in
commit 2e9388923e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Oct 11 20:08:24 2012 +0200
drm/i915/crt: explicitly set up HOTPLUG_BITS on resume"
so sayeth Daniel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org (v3.8 and later)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.
Note: This slipped through since we only disable pipes if the
plane/pipe linking doesn't match. Which is only relevant on older
gen3 mobile machines, if the BIOS fails to set up our preferred
linking.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Tested-and-reported-by: Paul Bolle <pebolle@tiscali.nl>
[danvet: Add note now that I could confirm my theory with the log
files Paul Bolle provided.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Check that the N and P dividers don't cause a divide by zero.
This shouldn't happen under normal circumstances, but can
happen eg. under simulation.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're currently misprinting the port name when vlv_wait_port_ready()
times out. Fix it by using port_name().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ring scratch pages don't have a PPGTT mapping, so the DERRM SRM
should target the global GTT instead.
v2: Add MI_SRM_LRM_GLOBAL_GTT define for -fixes
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When I submitted the first patch adding these force wake functions,
Chris Wilson observed that I was using the wrong functions, so I sent
a second version of the patch to correct this problem. The problem is
that v1 was merged instead of v2.
I was able to notice the problem when running the
debugfs-forcewake-user subtest of pm_pc8 from intel-gpu-tools.
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We were miscalculating the pipe CSC post offset for the full->limited
range conversion. The resulting post offset was double what it was
supposed to be, which caused blacks to come out grey when using
limited range output on HSW+.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71769
Cc: stable@vger.kernel.org
Tested-by: Lauri Mylläri <lauri.myllari@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we call intel_display_power_enabled() from
i915_capture_error_state() in IRQ context and then take a mutex. To fix
this add a new intel_display_power_enabled_sw() which returns the domain
state based on software tracking as opposed to reading the actual HW
state.
Since we use domain_use_count for this without locking on the reader
side make sure we increase the counter only after enabling all required
power wells and decrease it before disabling any of these power wells.
Regression introduced in
commit 1b02383464b4a915627ef3b8fd0ad7f07168c54c
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Sep 24 16:17:09 2013 +0300
drm/i915: support for multiple power wells
Note that atm we depend on the value returned by
intel_display_power_enabled_sw() in i915_capture_error_state() to avoid
unclaimed register access reports. This was never guaranteed though,
since another thread can disable the power concurrently. If this is a
problem we need another explicit way to disable the reporting during
error captures.
v2:
- remove barriers as the caller can't depend on the value
returned from i915_capture_error_state_sw() anyway (Ville)
- dump the state of pipe/transcoder power domain state (Daniel)
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV can have eDP on either port B or C, or even both. Based on the
VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we
check the correct ports.
So instead of hardcoding port D, rename the function to
intel_dp_is_edp() and pass the port as a parameter, and use it
on VLV ports B and C.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051
Tested-by: Robert Hooker <robert.hooker@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Wrestle the patch to apply and compile properly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added power well arguments to all the force wake routines
to help us individually control power well based on the
scenario.
Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict with the removed forcewake hack and drop one
spurious hunk Jesse noticed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Due to user fudging (for instance using video=VGA-1:e with FBDEV=n) we can
attempt to reset an inconsistent CRTC that is marked as active but has
no assigned fb. It would be wise to fix this earlier, but the long
term plan is to have primary and secondary planes associated with a
CRTC, in which crtc->fb being NULL will be expected. So for a quick
short term fix with pretensions of grandeur, just check for a NULL fb
during GPU reset and ignore the plane restoration.
This fixes a potential hard hang (a panic in the panic handler)
following a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Add a corresponding fixme comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This may need work if other platforms do the same thing, but in the
meantime we should avoid looking at HSW specific bits in this generic
function.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[added IS_BROADWELL too as that needs the same handling (Imre)]
Signed-off-by: Imre Deak <imre.deak@intel.com>
[danvet: Add Imre's missing sob.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In intel_display_capture_error_state we use HAS_POWER_WELL to check if
we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER
which is specific to these platforms. Future platforms with power wells
don't have this register, so HAS_POWER_WELL won't work there any more.
Use IS_HASWELL/IS_BROADWELL instead.
v3: fix using logical || instead of bitwise | (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to hold the pc8 lock around toggling the value of gpu_idle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the hardware does not support package C8, then do not even schedule
work to enable it. Thereby we can eliminate a bunch of dangerous work.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to hold the pc8 lock around toggling the value of gpu_idle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We must have one to fill out the adjusted_mode.crtc_clock. And with
the tv encoder fixed up every encoder we have has a ->get_config
callback. So we can drop the checks.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Apparently they need the same treatment as primary planes. This fixes
modesetting failures because of stuck cursors (!) on Thomas' i830M
machine.
I've figured while at it I'll also roll it out for the ivb 3 pipe
version of this function. I didn't do this for i845/i865 since Bspec
says the update mechanism works differently, and there's some
additional rules about what can be updated in which order.
Tested-by: Thomas Richter <thor@math.tu-berlin.de>
Cc: stable@vger.kernel.org
Cc: Thomas Richter <thor@math.tu-berlin.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull in Jani's backlight rework branch. This was merged through a
separate branch to be able to sort out the Broadwell conflicts
properly before pulling it into the main development branch.
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The quirk was added as what I'd say was a stopgap measure in
commit e85843bec6
Author: Kamal Mostafa <kamal@canonical.com>
Date: Fri Jul 19 15:02:01 2013 -0700
drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight
without really digging into what was going on.
Also, as mentioned in the related bug [1], having the quirk regressed
some of the machines it was supposed to fix to begin with, and there
were patches posted to disable the quirk on such machines [2]!
The fact is, we do need the BLM_PCH_PWM_ENABLE bit set to have
backlight. With the quirk, we've relied on BIOS to have set it, and our
save/restore code to retain it. With the full backlight setup at enable,
we have no place for things that rely on previous state.
With the per platform hooks, we've also made a change in the PCH
platform enable order: setting the backlight duty cycle between CPU and
PCH PWM enable. Some experimenting and
commit 770c12312a
Author: Takashi Iwai <tiwai@suse.de>
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening lid
indicate that we can't set the backlight before enabling CPU PWM; the
value just won't stick. But AFAICT we should do it before enabling the
PCH PWM.
Finally, any fallout we should fix properly, preferrably without quirks,
and absolutely without quirks that rely on existing state. With the per
platform hooks have much more flexibility to adjust the sequence as
required by platforms.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=47941
[2] http://lkml.kernel.org/r/1378229848-29113-1-git-send-email-kamal@canonical.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The backlight code has grown rather hairy, not least because the
hardware registers and bits have repeatedly been shuffled around. And
this isn't expected to get any easier with new hardware. Make things
easier for our (read: my) poor brains, and split the code up into chip
specific functions.
There should be no functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've always felt the backlight device conditional build has been all
backwards. Make it feel right.
Gently move things towards connector based stuff while at it.
There should be no functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
vlv_dpio_read/write should be describe more in PHY centric instead of
display controller centric.
Create a enum dpio_channel for channel index and enum dpio_phy for PHY
index. This should better to gather for upcoming platform.
v2: Rebase the code based on
drm/i915/vlv: Fix typo in the DPIO register define.
v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro
DPIO_PHY, and remove unrelated change. (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So here's the Broadwell pull request. From a kernel driver pov there's
two areas with big changes in Broadwell:
- Completely new enumerated interrupt bits. On the plus side it now looks
fairly unform and sane.
- Completely new pagetable layout.
To ensure minimal impact on existing platforms we've refactored both the
irq and low-level gtt handling code a lot in anticipation of the bdw push.
So now bdw enabling in these areas just plugs in a bunch of vfuncs.
Otherwise it's all fairly harmless adjusting of switch cases and
if-ladders to shovel bdw into the right blocks. So minimized impact on
existing platforms. I've also merged the bdw-stage1 branch into our
-nightly integration branch for the past week to make sure we don't break
anything.
Note that there's still quite a flurry or patches floating around, but
I've figured I'll push this out. I plan to keep the bdw fixes separate
from my usual -fixes stream so that you can reject them easily in case it
still looks like too much churn. Also, bdw is for now hidden behind the
preliminary hw enabling module option. So there's no real pressure to get
follow-up patches all into 3.13.
* tag 'bdw-stage1-2013-11-08-v2' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits)
drm/i915: Mask the vblank interrupt on bdw by default
drm/i915: Wire up cpu fifo underrun reporting support for bdw
drm/i915: Optimize gen8_enable|disable_vblank functions
drm/i915: Wire up pipe CRC support for bdw
drm/i915: Wire up PCH interrupts for bdw
drm/i915: Wire up port A aux channel
drm/i915: Fix up the bdw pipe interrupt enable lists
drm/i915: Optimize pipe irq handling on bdw
drm/i915/bdw: Take render error interrupt out of the mask
drm/i915/bdw: Add BDW PCH check first
drm/i915: Use hsw_crt_get_config on BDW
drm/i915/bdw: Change dp aux timeout to 600us on DDIA
drm/i915/bdw: Enable trickle feed on Broadwell
drm/i915/bdw: WaSingleSubspanDispatchOnAALinesAndPoints
drm/i915/bdw: conservative SBE VUE cache mode
drm/i915/bdw: Limit SDE poly depth FIFO to 2
drm/i915/bdw: Sampler power bypass disable
ddrm/i915/bdw: Disable centroid pixel perf optimization
drm/i915/bdw: BWGTLB clock gate disable
drm/i915/bdw: Implement edp PSR workarounds
...
Like on HSW, trickle feed should always be enabled on BDW.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Squash in fixup from Ben to synchronize the GT mailbox commands.
CC: Art Runyan <arthur.j.runyan@intel.com>
Reviewed-by: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So treat it like Haswell.
Reviewed-by: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Route cursor and sprite data through the pipe CSC unit on BDW.
Primary plane data is already sent through the pipe CSC.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And it inherits some bits from the previous TRANS_CONF (aka PIPE_CONF
on previous gens).
v2: Rebase on to of the pipe config bpp handling rework.
v3: Rebased on top of the pipe_config->dither refactoring.
v4: Drop the read-modify-write cycle for PIPEMISC, similarly to how we
now also build up PIPECONF completely ourselves - keeping around
random stuff set by the BIOS just isn't a good idea. I've checked BDW
BSpec and we already set all relevant bits.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just make Broadwell follow the same code paths as Haswell here,
instead of running code for the even-older platforms.
v2: Shuffle around Ben's vma prep work.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just enough to make the code not barf...
Init BDW display to look like HSW. For the simulator this should be
fine, but this will probably require more work.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add a FIXME comment about RCS flips being untested on bdw.
Also add a note that hblank events are reserved on bdw+ in DERRMR.]
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current
DPIO register definition doesn't have a structure way to break them
down. As a result it is not easy to match the PHY/PLL registers with the
configdb document. Rename those registers based on the configdb for easy
cross references, and without the need to check the offset in the header
file.
New format is as following.
<platform name>_<DPIO component><optional lane #>_DW<dword # in the
doc>_<optional channel #>
For example,
VLV_PCS_DW0 - Group access to PCS for lane 0 to 3 for PCS DWORD 0.
VLV_PCS01_DW0_CH0 - PCS access to lane 0/1, channel 0 for PCS DWORD 0.
Another example is
VLV_TX_DW0 - Group access to TX lane 0 to 3 for TX DWORD 0
VLV_TX0_DW0 - Refer to TX Lane 0 access only for TX DWORD 0.
There is no functional change on this patch.
v2: Rebase based on previous patch change.
v3: There may be configdb different version that document the start DW
differently. Add a comment to clarify. Fix up some mismatch start DW
for second PLL block. (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bit a bit -fixes pull request in the merge window than usual dua to two
feauture-y things:
- Display CRCs are now enabled on all platforms, including the odd DP case
on gm45/vlv. Since this is a testing-only feature it should ever hurt,
but I figured it'll help with regression-testing -fixes. So I left it
in and didn't postpone it to 3.14.
- Display power well refactoring from Imre. Would have caused major pain
conflict with the bdw stage 1 patches if I'd postpone this to -next.
It's only an relatively small interface rework, so shouldn't cause pain.
It's also been in my tree since almost 3 weeks already.
That accounts for about two thirds of the pull, otherwise just bugfixes:
- vlv backlight fix from Jesse/Jani
- vlv vblank timestamp fix from Jesse
- improved edp detection through vbt from Ville (fixes a vlv issue)
- eDP vdd fix from Paulo
- fixes for dvo lvds on i830M
- a few smaller things all over
Note: This contains a backmerge of v3.12. Since the -internal branch
always applied on top of -nightly I need that unified base to merge bdw
patches. So you'll get a conflict with radeon connector props when pulling
this (and nouveau/master will also conflict a bit when Ben doesn't
rebase). The backmerge itself only had conflicts in drm/i915.
There's also a tiny conflict between Jani's backlight fix and your sysfs
lifetime fix in drm-next.
* tag 'drm-intel-fixes-2013-11-07' of git://people.freedesktop.org/~danvet/drm-intel: (940 commits)
drm/i915/vlv: use per-pipe backlight controls v2
drm/i915: make backlight functions take a connector
drm/i915: move opregion asle request handling to a work queue
drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV
drm/i915: Make intel_dp_is_edp() less specific
drm/i915: Give names to the VBT child device type bits
drm/i915/vlv: enable HDA display audio for Valleyview2
drm/i915/dvo: call ->mode_set callback only when the port is running
drm/i915: avoid unclaimed registers when capturing the error state
drm/i915: Enable DP port CRC for the "auto" source on g4x/vlv
drm/i915: scramble reset support for DP port CRC on vlv
drm/i915: scramble reset support for DP port CRC on g4x
drm/i916: add "auto" pipe CRC source
...
Conflicts:
MAINTAINERS
drivers/gpu/drm/i915/intel_panel.c
drivers/gpu/drm/nouveau/core/subdev/mc/base.c
drivers/gpu/drm/radeon/atombios_encoders.c
drivers/gpu/drm/radeon/radeon_connectors.c
Use the same wait_for_vblank code for CTG that we use for ILK+.
Also fix the name of the frame counter register while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV/BYT, backlight controls a per-pipe, so when adjusting the
backlight we need to pass the correct info. So make the externally
visible backlight functions take a connector argument, which can be used
internally to figure out the pipe backlight to adjust.
v2: make connector pipe lookup check for NULL crtc (Jani)
fixup connector check in ASLE code (Jani)
v3: make sure we take the mode config lock around lookups (Daniel)
v4: fix double unlock in panel_get_brightness (Daniel)
v5: push ASLE work into a work queue (Daniel)
v6: separate ASLE work to a prep patch, rebase (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
valleyview_modeset_global_pipes() may add pipes that are getting fully
disabled to prepare_pipes bitmask. The rest of the code doesn't expect
this, so clear out any such pipes from the prepare_pipes bitmask.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's possible that the CCK clock could run at a different rate than the
DDR clock, so use the same method to get CCK as the GMBUS code does when
calculating the new CDclk divider in the VLV display code.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV/BYT, we can adjust the CDclk frequency up or down based on the
max pixel clock we need to drive. Lowering it can save power, while
raising it is necessary to support high resolution.
Add a new callback in modeset_affected_pipes and a
modeset_global_resources function to perform this adjustment as
necessary.
v2: use punit interface for 320 and 266 MHz CDclk adjustments (Ville)
v3: reset GMBUS dividers too, since we changed CDclk (Ville)
v4: jump to highest voltage when going to 400MHz CDclk (Jesse)
v5: drop duplicate define (Ville)
use shifts by 1 for fixed point (Ville)
drop new callback (Daniel)
v6: fixup adjusted_mode.clock -> adjusted_mode.crtc_clock again (Ville)
document Bunit reg access better (Ville)
v7: pass modeset_pipes and pipe_config to global_pipes so we get the right
clock data (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch defines HD-Audio configuration registers and enables display audio
from HDA controller for Valleyview2.
v2: fix missing offset VLV_DISPLAY_BASE
v3: rename patch from 'enable HDMI audio' to 'enable HDA display audio', since
it's for both HDMI and DP audio
v4: use enc_to_dig_port() to get port number, instead of using Haswell specific
function intel_ddi_get_encoder_port()
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I want to merge in the new Broadwell support as a late hw enabling
pull request. But since the internal branch was based upon our
drm-intel-nightly integration branch I need to resolve all the
oustanding conflicts in drm/i915 with a backmerge to make the 60+
patches apply properly.
We'll propably have some fun because Linus will come up with a
slightly different merge solution.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/intel_crt.c
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
All rather simple adjacent lines changed or partial backports from
-next to -fixes, with the exception of the thaw code in i915_dma.c.
That one needed a bit of shuffling to restore the intent.
Oh and the massive header file reordering in intel_drv.h is a bit
trouble. But not much.
v2: Also don't forget the fixup for the silent conflict that results
in compile fail ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even though we only check for unclaimed registers while we're writing
registers, if we read a bad register we'll still trigger a CPU error
interrupt, and we'll print an "Unclaimed register" DRM_ERROR due to
that. To avoid this error, just avoid touching power domains that are
not enabled.
Use kzalloc so we're sure all the disabled domains will be zeroed on
the error state file. We already print the information that is enough
to discover if the power well is enabled on the error state file, so
this should not be a problem.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69747
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.
For example when we change the fdi lines from 2 to 3 without switching
off outputs in-between we'll never see the crucial on->off transition
in the ->modeset_global_resources hook the current logic relies on.
Patch version 2 got this right by instead also checking whether the
pipe is indeed active. But that in turn broke things when pipes have
been turned off through dpms since the bifurcate enabling is done in
the ->crtc_mode_set callback.
To address this issues discussed with Ville in the patch review move
the setting of the bifurcate bit into the ->crtc_enable hook. That way
we won't wreak havoc with this state when userspace puts all other
outputs into dpms off state. This also moves us forward with our
overall goal to unify the modeset and dpms on paths (which we need to
have to allow runtime pm in the dpms off state).
Unfortunately this requires us to move the bifurcate helpers around a
bit.
Also update the commit message, I've misanalyzed the bug rather badly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507
Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We store cursor_x/y as int16_t internally, but the user provided
coordinates are int32_t. Clamp the coordinates so that they don't
overflow the int16_t. Since the cursor is only 64x64 in size, the
clamping can't cause any visual changes.
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>
On CTG+ read out the pipe bpp setting from hardware and fill it into
pipe config. Also check it appropriately.
v2: Don't do the pipe_bpp extraction inside the PCH only code block on
ILK+.
Avoid the PIPECONF read as we already have read it for the
PIPECONF_EANBLE check.
Note: This is already in drm-intel-next-queued as
commit 42571aefaf
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Sep 6 23:29:00 2013 +0300
drm/i915: Add support for pipe_bpp readout
but is needed for the following bugfix.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.
This logic is supported by intel_set_power_well() in the power domain
framework. It would be nice to simplify the API, so that we only have
get/put functions and make it more explicit on the higher level how this
"power well on during init" logic works. This will make it also easier
if in the future we want to shorten the time the power wells are on.
For this add a new device private flag tracking whether we have the
power wells on because of init/suspend and use only
intel_display_power_get()/put(). As nothing else uses
intel_set_power_well() we can remove it.
This also fixes
commit 6efdf354dd
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Oct 16 17:25:52 2013 +0300
drm/i915: enable only the needed power domains during modeset
where removing intel_set_power_well() resulted in not releasing the
reference on the power well that was taken during init and thus leaving
the power well on all the time. Regression reported by Paulo.
v2:
- move the init_power_on flag to the power_domains struct (Daniel)
v3:
- add note about this being a regression fix too (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far the modeset code enabled all power domains if it needed any. It
wasn't a problem since HW generations so far only had one always-on
power well and one dynamic power well that can be enabled/disabled. For
domains powered by always-on power wells (panel fitter on pipe A and the
eDP transcoder) we didn't do anything, for all other domains we just
enabled the single dynamic power well.
Future HW generations will change this, as they add multiple dynamic
power wells. Support for these will be added later, this patch prepares
for those by making sure we only enable the required domains.
Note that after this change on HSW we'll enable all power domains even
if it was the domain for the panel fitter on pipe A or the eDP
transcoder. This isn't a problem since the power domain framework
already checks if the domain is on an always-on power well and doesn't
do anything in this case.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We'll need the same functionality for other HW generations. The support
for these will be added by upcoming patches.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jun 5 13:34:23 2013 +0200
drm/i915: consolidate pch pll enable sequence
I've removed all the code from this if block, but somehow forgotten to
kill the block itself.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The HDMI audio expects HDMI pixel clock to be set in the audio
configuration. We've currently just set 0, using 25.2 / 1.001 kHz
frequency, which fails with some modes.
v2: Now with a commit message.
Reference: http://mid.gmane.org/CAGpEb3Ep1LRZETPxHGRfBDqr5Ts2tAc8gCukWwugUf1U5NYv1g@mail.gmail.com
Reference: http://mid.gmane.org/20130206213533.GA16367@hardeman.nu
Reported-by: David Härdeman <david@hardeman.nu>
Reported-by: Jasper Smet <josbeir@gmail.com>
Tested-by: Jasper Smet <josbeir@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will be needed for setting the HDMI pixel clock for audio
config. No functional changes.
v2: Now with a commit message.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's better to catch such fallout early, and this way we can rely on
the checking done by the drm core on fb->heigh/width at modeset time.
If we ever support planar formats on intel we might want to look into
a common helper to do all this, but for now this is good enough.
v2: Take tiling into account, requested by Ville.
v3: Fix tile height on gen2, spotted by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: 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>
Assuming that all framebuffer related metadata is invariant simplifies
our userspace input data checking. And current userspace always first
updates the tiling of an object before creating a framebuffer with it.
This allows us to upconvert a check in pin_and_fence to a WARN.
In the future it should also be helpful to know which buffer objects
are potential scanout targets for e.g. frontbuffer rendering tracking
and similar things.
Note that SNA shipped for one prerelease with code which will be
broken through this patch. But users shouldn't notice since it's
purely an optimization and will transparently fall back to allocating
a new fb. i-g-t also had offending code (now fixed), but we don't
really care about breaking the test-suite.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Grumpily-reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We look at gem state (like obj->tiling/obj->stride), we better have
the relevant locks.
Right now this doesn't matter much since most of these checks are
a curtesy to safe buggy userspace, but I'd like to freeze the tiling
once we have framebuffer objects attached. And then locking matters.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch changes HDMI port registration order for the BayTrail platform.
The story is that in kernel version 3.11 i915 supported only one HDMI port -
the HDMIB port. So this port ended up being HDMI-1 in user-space.
But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT'
introduced HDMIC port support. And added HDMIC registration prior to HDMIB,
so HDMIB became HDMI-2 and HDMIC became HDMI-1.
Well, this is fine as far as the kernel is concerned. i915 does not give any
guarantees to the numbering, and has never given them.
However, this breaks wayland setup in Tizen IVI. We have only one single HDMI
port on our hardware, and it is connected to HDMIB. Our configuration relies on
the fact that it is HDMI-1.
Well, certainly this is user-space problem which was exposed with Jesse's
patch. However, there is a reason why we have to do this assumption - we use
touchscreen monitors and we have to associate event devices with the monitors,
and this is not easy to do dynamically, so we just have a static setup.
Anyway, while the user-space setup will have to be fixed regardless, let's
chane the HDMI port registration order so that HDMIB stays HDMI-1, just like it
was in 3.11. Simply because there is no strong reason for changing the order in
the kernel, and it'll help setups like ours in sense that we'll have more time
for fixing the issue properly.
Also amend the commentary which looks a bit out-of-date.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
[danvet: Drop the commment, SDVOC is gone and we have a proper HDMIC
define now.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yet other direct usages of the pipe number instead of pipe_name().
We've been tracking them lately but managed to miss these last ones.
v2: Catch them all! (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fill out the HSW watermark s/w tracking structures with the current
hardware state in intel_modeset_setup_hw_state(). This allows us to skip
the HW state readback during watermark programming and just use the values
we keep around in dev_priv->wm. Reduces the overhead of the watermark
programming quite a bit.
v2: s/init_wm/wm_get_hw_state
Remove stale comment about sprites
Make DDB partitioning readout safer
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix whitespace fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rounding down when calculating the dot/vco frequencies doesn't make much
sense. Round to closest should give slightly nicer answers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This file is all about the legacy fbdev support. If we want to extract
framebuffer functions, we better put those into a separate file.
Also rename functions accordingly, only two have used the intel_fb_
prefix anyway.
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Boots Just Fine (tm)!
The only glitch seems to be that at least on Fedora the boot splash
gets confused and doesn't display much at all.
And since there's no ugly console flickering anymore in between, the
flicker while switching between X servers (VT support is still enabled)
is even more jarring.
Also, I'm unsure whether we don't need to somehow kick out vgacon, now
that nothing else gets in the way. But stuff seems to work, so I
don't care. Also everything still works as well with VGA_CONSOLE=n
Also the #ifdef mess needs a bit of a cleanup, follow-up patches will
do just that.
To keep the Kconfig tidy, extract all the i915 options into its own
file.
v2:
- Rebase on top of the preliminary hw support option and the
intel_drv.h cleanup.
- Shut up warnings in i915_debugfs.c
v3: Use the right CONFIG variable, spotted by Chon Ming.
Cc: Lee, Chon Ming <chon.ming.lee@intel.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current pre-gen4 pipe off code might break out of the loop
due to the timeout, but then the fail to print the warning.
Refactor the code a bit to use wait_for() to avoid the problem,
and that we also re-check the condition after the timeout has
expired.
v2: Use wait_for()
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>
This reverts commit 81b5c7bc8d.
Adding drm/i915 into the vga arbiter chain means that X (in a piece of
well-meant paranoia) will do a get/put on the vga decoding around
_every_ accel call down into the ddx. Which results in some nice
performance disasters [1]. This really breaks userspace, by disabling
DRI for everyone, and stops OpenGL from working, this isn't limited
to just the i915 but both the integrated and discrete GPUs on
multi-gpu systems, in other words this causes untold worlds of pain,
Ville tried to come up with a Great Hack to fiddle the required VGA
I/O ops behind everyone's back using stop_machine, but that didn't
really work out [2]. Given that we're fairly late in the -rc stage for
such games let's just revert this all.
One thing we might want to keep is to delay the disabling of the vga
decoding until the fbdev emulation and the fbcon screen is set up. If
we kill vga mem decoding beforehand fbcon can end up with a white
square in the top-left corner it tried to save from the vga memory for
a seamless transition. And we have bug reports on older platforms
which seem to match these symptoms.
But again that's something to play around with in -next.
References: [1] http://lists.x.org/archives/xorg-devel/2013-September/037763.html
References: [2] http://www.spinics.net/lists/intel-gfx/msg34062.html
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 6e1b4fdad5.
This is part of a revert due to a userspace breakage, better explained in the revert of 1a1a4cbf4906a13c0c377f708df5d94168e7b582.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Let's try to avoid these confusing negated booleans.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At the end of haswell_crtc_enable we have an intel_wait_for_vblank
with a big comment, and the message suggests it's a workaround for
something we don't really understand. So I removed that wait and
started getting HW state readout error messages saying that the IPS
state is not what we expected.
I investigated and concluded that after you write IPS_ENABLE to
IPS_CTL, the bit will only actually become 1 on the next vblank. So
add code to wait for the IPS_ENABLE bit. We don't really need this
wait right now due to the wait I already mentioned, but at least this
one has a reason to be there, while the other one is just to
workaround some problem: we may remove it in the future.
The wait also acts as a POSTING_READ which we missed.
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>
The PIPEA quirk is specifically for the issue with the PIPEB PLL on
830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA
running. i845 doesn't even have the second PLL or pipe, and enabling
the quirk results in a blank DVO LVDS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
The new names make it clearer which plane we're talking about.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Resolve small conflict with the haswell_crtc_disable_planes
extraction.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The intel_flush_primary_plane name actually tells us which plane
we're talking about.
Also reorganize the internals a bit and add a missing POSTING_READ()
to make sure the hardware has seen the changes by the time we
return from the function.
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>
IPS should be OK as long as one plane is enabled on the pipe, but
it does seem to cause problems when going between primary only and
sprite only.
This needs more investigations, but for now just disable IPS whenever
the primary plane is disabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the primary gets marked as disabled while the pipe is off for
instance, we should still re-enable it when the pipe is turned on,
unless the sprite covers it fully also in that configuration.
Unfortunately we do the plane visibility checks only in the sprite code,
which is executed after the primary enabling when turning the pipe off.
Ideally we should compute the plane visibility before touching the
hardware at all, but for now just set the primary_disabld flag
in intel_{enable,disable}_plane.
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>
The VGACNTRL register contains a bunch of other stuff besides
the VGA_DISP_DISABLE bit. When we write the register we always set those
other bits to zero, so normally the current check would work.
However on HSW disabling and re-enabling the power well will reset the
VGACNTRL register to its default value, which has several of the other
bits set as well.
So only look at the VGA_DISP_DISABLE bit when checking whether the VGA
plane needs re-disabling.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
