The vma may have been rebound between the last time the cursor was
enabled and now, so skipping the cursor gtt offset deduction is not
safe unless we would also reset cursor_bo to NULL when disabling the
cursor. Just thow cursor_bo to the bin instead since it's lost all
other uses thanks to universal plane support.
Chris pointed out that cursor updates are currently too slow
via universal planes that micro optimizations like these wouldn't
even help.
v2: Add a note about futility of micro optimizations (Chris)
Cc: drm-intel-fixes@lists.freedesktop.org
References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Here are the patchset to add get_eld op to audio component for
communicating more directly between i915 and HD-audio.
Currently, the HDMI/DP audio status and ELD are notified and obtained
via the hardware-level communication over HD-audio unsolicited event
and verbs although the graphics driver holds the exactly same
information. As we already have a notification via audio component,
this is another step forward; namely, the audio driver may fetch
directly the audio status and ELD via the new component op.
The commits are based on Dave's latest drm-next branch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWaXTVAAoJEGwxgFQ9KSmkdZIQAKg2NQN1CGOIb+ce80UmJ9ap
myZH42aZXytPrMAhHQCw2mvf8aL18EKyQcGv+anLdFM+AqlzZvH/exfOblkr88lg
ZMGr0bXVNa2Lfyrgt9blUwH58uETQZC4P3BrI0cPqIJBdPagDxnxoaV1e/21g/9p
0a2bhiz0gn4OFb83vpi5pL4hGv+BQwwlmkOujcVg7yxR7ylnYI419NM9Z+Lbmfq7
p5jId6Q3EwBw6vpWryOI2TElM3VDThoOGCOtkfmZx6o4fDZ0bdl8CYVCgRFwZZCe
kk01Caa+5+CW88MlJ1VX6gLy0WRlPY0AFreCWKgy5HCUNqew9ruhUeMj4+C1oHpj
ui/79ULLRN2hmu2rvU8lZb0ClihXkDCBN8p89j6o2I+y1aIcUtxvY9Srg5w2tVBe
Ue+OSB3lA4rdnuSjxZiaPf+V4rozIyNJHRjo6xNdY0zuScB4lw9Bh7IYXmj8B8OW
k3LklToj4ZGeyCgfcTQwztAh7fFEXUb1wN+lLqCt3b9688zvMYTQlJ8ZdtK+t188
3DNz9QjjPd4DcxLypl1VpM2Xv3AhuFfugq0oEuQq9bXs7qtj+iLmSWWdmhUNaVWb
Qot21vJEHDii6jtoLdbVMTEZTWyr2nXUfUNFJpUgitif2UhqqgecnR16Fi05pjTv
+Th/GvjddrQ0oe9DwVGY
=NShN
-----END PGP SIGNATURE-----
Merge tag 'drm-i915-get-eld' of tiwai/sound into drm-intel-next-queued
Add get_eld audio component for i915/HD-audio
Currently, the HDMI/DP audio status and ELD are notified and obtained
via the hardware-level communication over HD-audio unsolicited event
and verbs although the graphics driver holds the exactly same
information. As we already have a notification via audio component,
this is another step forward; namely, the audio driver may fetch
directly the audio status and ELD via the new component op.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Implement a new i915_audio_component_ops, get_eld(). It's called by
the audio driver to fetch the current audio status and ELD of the
given HDMI/DP port. It returns the size of expected ELD bytes if it's
valid, zero if no valid ELD is found, or a negative error code. The
current state of audio on/off is stored in the given pointer, too.
Note that the returned size isn't limited to the given max bytes. If
the size is greater than the max bytes, it means that only a part of
ELD has been copied back.
For achieving this implementation, a new field audio_connector is
added to struct intel_digital_port. It points to the connector
assigned to the given digital port. It's set/reset at each audio
enable/disable call in intel_audio.c, and protected with av_mutex.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Another separated patches to support DP MST audio will be implemented
in audio driver.
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Libin Yang <libin.yang@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449036584-105393-2-git-send-email-libin.yang@linux.intel.com
This removes pre/post_wm_update from intel_crtc->atomic, and
creates atomic state for it in intel_crtc.
Changes since v1:
- Rebase on top of wm changes.
Changes since v2:
- Split disable_cxsr into a separate patch.
Changes since v3:
- Move some of the changes to intel_wm_need_update.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56603A49.5000507@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The goal is to call FBC enable/disable only once per modeset, while
activate/deactivate/update will be called multiple times.
The enable() function will be responsible for deciding if a CRTC will
have FBC on it and then it will "lock" FBC on this CRTC: it won't be
possible to change FBC's CRTC until disable(). With this, all checks
and resource acquisition that only need to be done once per modeset
can be moved from update() to enable(). And then the update(),
activate() and deactivate() code will also get simpler since they
won't need to worry about the CRTC being changed.
The disable() function will do the reverse operation of enable(). One
of its features is that it should only be called while the pipe is
already off. This guarantees that FBC is stopped and nothing is
using the CFB.
With this, the activate() and deactivate() functions just start and
temporarily stop FBC. They are the ones touching the hardware enable
bit, so HW state reflects dev_priv->crtc.active.
The last function remaining is update(). A lot of times I thought
about renaming update() to activate() or try_to_activate() since it's
called when we want to activate FBC. The thing is that update() may
not only decide to activate FBC, but also deactivate or keep it on the
same state, so I'll leave this name for now.
Moving code to enable() and disable() will also help in case we decide
to move FBC to pipe_config or something else later.
The current patch only puts the very basic code on enable() and
disable(). The next commits will take care of moving more stuff from
update() to the new functions.
v2:
- Rebase.
- Improve commit message (Chris).
v3: Rebase after changing the patch order.
v4: Rebase again after upstream changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
The long term goal is to have enable/disable as the higher level
functions and activate/deactivate as the lower level functions, just
like we do for PSR and for the CRTC. This way, we'll run enable and
disable once per modeset, while update, activate and deactivate will
be run many times. With this, we can move the checks and code that
need to run only once per modeset to enable(), making the code simpler
and possibly a little faster.
This patch is just the first step on the conversion: it starts by
converting the current low level functions from enable/disable to
activate/deactivate. This patch by itself has no benefits other than
making review and rebase easier. Please see the next patches for more
details on the conversion.
v2:
- Rebase.
- Improve commit message (Chris).
v3: Rebase after changing the patch order.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
There's no need to reevaluate the status of every single crtc when a
single crtc changes its state.
With this, we're cutting the case where due to a change in pipe B,
intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC
should be enabled on pipe A, then it completely rechecks the state of
pipe A only to conclude FBC should remain enabled on pipe A. If any
change on pipe A triggers a need to recompute whether FBC is valid on
pipe A, then at some point someone is going to call
intel_fbc_update(PIPE_A).
The addition of intel_fbc_deactivate() is necessary so we keep track
of the previously selected CRTC when we do invalidate/flush. We're
also going to continue the enable/disable/activate/deactivate concept
in the next patches.
v2: Rebase.
v3: Rebase after changing the patch order.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
The .get_config() hooks should not reference anything in crtc->config,
everything should be based on the passed in pipe_config instead. So
don't dig out the cpu_transcoder from crtc->config on ddi platfforms,
and also avoid using the encoder->crtc link and instead look up the
pipe via pipe_config->base.crtc.
I don't think this will actually fix anything since during the initial
state readout we set up the encoder->crtc link prior to calling
.get_config(), and during the modeset state check the encoder->crtc
ought to be correct anyway since it's that state we just programmed.
But this seems the right thing to do anyway.
While at it, do some house cleaning on the local variables in the
.infoframe_enabled() hooks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448555227-31403-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm-intel-next-2015-11-20-rebased:
4 weeks because of my vacation, so a bit more:
- final bits of the typesafe register mmio functions (Ville)
- power domain fix for hdmi detection (Imre)
- tons of fixes and improvements to the psr code (Rodrigo)
- refactoring of the dp detection code (Ander)
- complete rework of the dmc loader and dc5/dc6 handling (Imre, Patrik and
others)
- dp compliance improvements from Shubhangi Shrivastava
- stop_machine hack from Chris to fix corruptions when updating GTT ptes on bsw
- lots of fifo underrun fixes from Ville
- big pile of fbc fixes and improvements from Paulo
- fix fbdev failures paths (Tvrtko and Lukas Wunner)
- dp link training refactoring (Ander)
- interruptible prepare_plane for atomic (Maarten)
- basic kabylake support (Deepak&Rodrigo)
- don't leak ringspace on resets (Chris)
drm-intel-next-2015-10-23:
- 2nd attempt at atomic watermarks from Matt, but just prep for now
- fixes all over
* tag 'drm-intel-next-2015-11-20-merged' of git://anongit.freedesktop.org/drm-intel: (209 commits)
drm/i915: Update DRIVER_DATE to 20151120
drm/i915: take a power domain reference while checking the HDMI live status
drm/i915: take a power domain ref only when needed during HDMI detect
drm/i915: Tear down fbdev if initialization fails
async: export current_is_async()
Revert "drm/i915: Initialize HWS page address after GPU reset"
drm/i915: Fix oops caused by fbdev initialization failure
drm/i915: Fix i915_ggtt_view_equal to handle rotation correctly
drm/i915: Stuff rotation params into view union
drm/i915: Drop return value from intel_fill_fb_ggtt_view
drm/i915 : Fix to remove unnecsessary checks in postclose function.
drm/i915: add MISSING_CASE to a few port/aux power domain helpers
drm/i915/ddi: fix intel_display_port_aux_power_domain() after HDMI detect
drm/i915: Remove platform specific *_dp_detect() functions
drm/i915: Don't do edp panel detection in g4x_dp_detect()
drm/i915: Send TP1 TP2/3 even when panel claims no NO_TRAIN_ON_EXIT.
drm/i915: PSR: Don't Skip aux handshake on DP_PSR_NO_TRAIN_ON_EXIT.
drm/i915: Reduce PSR re-activation time for VLV/CHV.
drm/i915: Delay first PSR activation.
drm/i915: Type safe register read/write
...
DSI has quite a few special cases, like DP, so add it to crtc
state. This way we can get rid of a number of intel_pipe_has_type()
checks for DSI. This isn't necessarily the prettiest way, but it's a
step towards being aligned with what's being done with other encoders.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448619706-21293-3-git-send-email-jani.nikula@intel.com
I noticed that intel_fbdev->our_mode is unused. Introduced by
79e539453b ("DRM: i915: add mode setting support").
Then I noticed that intel_fbdev->fbdev_list is unused as well.
Introduced by 386516744b ("drm/fb: fix fbdev object model +
cleanup properly.") in i915, nouveau and radeon.
Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl,
virtio and mgag200.
Already removed from the latter with cc59487a05 ("drm/mgag200:
'fbdev_list' in 'struct mga_fbdev' is not used").
Remove it from the others.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let us print human-parseable values from the power domain code; upcoming
display code also wants to use it.
This requires moving it out of i915_debugfs.c, as that is only conditionally
compiled.
v2: Move it out of the header.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448034934-11926-1-git-send-email-daniels@collabora.com
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
Replace the is_sdvob bool and some sdvo_reg checks with enum port. This
makes the SDVO code look more modern, and gets rid of explicit register
offset checks in the code which will hamper register type checking.
v2: Add assert_sdvo_port_valid() (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1446838199-3666-1-git-send-email-ville.syrjala@linux.intel.com
It was created at 'commit aabc95dcf2 (drm/i915: Dont -ETIMEDOUT
on identical new and previous (count, crc).")' becase the counter
wasn't reliable.
Now that we properly wait for the counter to be reset we can rely
a bit more in the counter.
Also that patch stopped to return -ETIMEDOUT so the test case is
unable to skip when it is unreliable and end up in many fails
that should be skip instead.
So, with the counter more reliable we can remove
this hack that just makes things more confusing when test cases
are really expecting the same CRC and let test case skip if that's
not the case.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently the gmbus code uses intel_aux_display_runtime_get/put in an
effort to make sure the hardware is powered up sufficiently for gmbus.
That function only takes the runtime PM reference which on VLV/CHV/BXT
is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well
2 on BXT. So add a new power domnain for gmbus and kill off the now
unused intel_aux_display_runtime_get/put. And change
intel_hdmi_set_edid() to use the gmbus power domain too since that's all
we need there.
Also toss in a BUILD_BUG_ON() to catch problems if we run out of
bits for power domains. We're already really close to the limit...
[Patrik: Add gmbus string to debugfs output]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-5-git-send-email-patrik.jakobsson@linux.intel.com
Introduce intel_display_port_aux_power_domain() which simply returns
the appropriate AUX power domain for a specific port, and then replace
the intel_display_port_power_domain() with calls to the new function
in the DP code. As long as we're not actually enabling the port we don't
need the lane power domains, and those are handled now purely from
modeset_update_crtc_power_domains().
My initial motivation for this was to see if I could keep the DPIO power
wells powered down while doing AUX on CHV, but turns out I can't so this
doesn't change anything for CHV at least. But I think it's still a
worthwile change.
v2: Add case for PORT E. Default to POWER_DOMAIN_AUX_D for now. (Ville)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447682467-6237-1-git-send-email-patrik.jakobsson@linux.intel.com
We need to initialize the display core part early, before initializing
the rest of the display power state. This is also described in the bspec
termed "Display initialization sequence". Atm we run this sequence
during driver loading after power domain HW state initialization which
is too late and during runtime suspend/resume which is unneeded and can
interere with DMC functionality which handles HW resources toggled
by this init/uninit sequence automatically. The init sequence must be
run as the first step of HW power state initialization and during
system resume. The uninit sequence must be run during system suspend.
To address the above move the init sequence to the initial HW power
state setup and the uninit sequence to a new power domains suspend
function called during system suspend.
As part of the init sequence we also have to reprogram the DMC firmware
as it's lost across a system suspend/resume cycle.
After this change CD clock initialization during driver loading will
happen only later after other dependent HW/SW parts are initialized,
while during system resume it will get initialized as the last step of
the init sequence. This distinction can be removed by some refactoring
of platform independent parts. I left this refactoring out from this
series since I didn't want to change non-SKL parts. This is a TODO for
later.
v2:
- fix error path in i915_drm_suspend_late()
- don't try to re-program the DMC firmware if it failed to load
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447774433-20834-1-git-send-email-imre.deak@intel.com
Before this patch, we used the intel_display_power_{get,put} functions
to make sure the PW1 and Misc I/O power wells were enabled all the
time while LCPLL was enabled. We called a get() at
intel_ddi_pll_init() when we discovered that LCPLL was enabled, then
we would call put/get at skl_{un,}init_cdclk().
The problem is that skl_uninit_cdclk() is indirectly called by
intel_runtime_suspend(). So it will only release its power well
_after_ we already decided to runtime suspend. But since we only
decide to runtime suspend after all power wells and refcounts are
released, that basically means we will never decide to runtime
suspend.
So what this patch does to fix that problem is move the PW1 + Misc I/O
power well handling out of the runtime PM mechanism: instead of
calling intel_display_power_{get_put} - functions that touch the
refcount -, we'll call the low level intel_power_well_{en,dis}able,
which don't change the refcount. This way, it is now possible for the
refcount to actually reach zero, and we'll now start runtime
suspending/resuming.
v2 (from Paulo):
- Write a commit message since the original patch left it empty.
- Rebase after the intel_power_well_{en,dis}able rename.
- Use lookup_power_well() instead of hardcoded indexes.
Testcase: igt/pm_rpm/rte (and every other rpm test)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92211
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92605
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-4-git-send-email-imre.deak@intel.com
Rather than computing on demand, store also the aux data reg
offsets under intel_dp.
v2: Duplicate some code to make things less magic (Jani)
v3: Use PORT_B registers for invalid ports in g4x_aux_data_reg()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-6-git-send-email-ville.syrjala@linux.intel.com
As all csr firmware related opertion are not using any
any data structures of drm framework level, so better to
use dev_priv instead of dev. it's a new style! :)
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-9-git-send-email-imre.deak@intel.com
This removes two anti-patterns:
- Locking shouldn't be used to synchronize with async work (of any
form, whether callbacks, workers or other threads). This is what the
mutex_lock/unlock seems to have been for in intel_csr_load_program.
Instead ordering should be ensured with the generic
wait_for_completion()/complete(). Or more specific functions
provided by the core kernel like e.g.
flush_work()/cancel_work_sync() in the case of synchronizing with a
work item.
- Don't invent own completion like the following code did with the
(already removed) wait_for(csr_load_status_get()) pattern - it's
really hard to get these right when you want them to be _really_
correct (and be fast) in all cases. Furthermore it's easier to read
code using the well-known primitives than new ones using
non-standard names.
Before enabling/disabling DC6 check if the firmware is loaded
successfully. This is guaranteed during runtime s/r, since otherwise we
don't enable RPM, but not during system s/r.
Note that it's still unclear whether we need to enable/disable DC6
during system s/r, until that's clarified, keep the current behavior and
enable/disable DC6.
Also after this patch there is a race during system s/r where the
firmware may not be loaded yet, that's addressed in an upcoming patch.
v2-v3:
- unchanged
v4:
- rebased on latest drm-intel-nightly
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: added code and note about checking if the firmware loaded ok,
before enabling/disabling it]
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447341037-2623-1-git-send-email-imre.deak@intel.com
Avoids non-static functions since all the callers are in intel_rpm.c.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: removed note about reg definitions from commit message, since
it's not relevant any more]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
[Jani: make assert_csr_loaded static]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-4-git-send-email-imre.deak@intel.com
Reading the driver load/unload code leaves one confused as there's
an async_schedule() in the load, but not async_synchronize_full()
in sight. In fact it's hidden inside intel_fbdev.c. So let's move the
async_schedule() into intel_fbdev.c as well so that it's next to the
async_synchronize_full(), which should make the relationship easier
to see.
Plus this way we won't schedule a nop function call when fbdev is
disabled. And we were passing a pointer to a static inline
function to async_schedule(), which seems rather dubious to me.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Doing the IBX transcoder B workaround causes underruns on
pipe/transcoder A. Just hide them by disabling underrun reporting for
pipe A around the workaround.
It might be possible to avoid the underruns by moving the workaround
to be applied only when enabling pipe A. But I was too lazy to try it
right now, and the current method has been proven to work, so didn't
want to change it too hastily.
Note that this can re-enable underrun reporting on pipe A if was
already disabled due to a previous actual underrun. But that's OK, we
may just get a second underrun report if another real underron occurrs
on pipe A.
v2: Note that pipe A underruns can get re-enabled due to this (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1446225802-11180-1-git-send-email-ville.syrjala@linux.intel.com
Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not
always get an interrupt on a FIFO underrun. But we can always do an
explicit check (like we do on GMCH platforms that have no underrun
interrupt).
v2: Drop stale kerneldoc for i9xx_check_fifo_underruns() (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1446225741-11070-1-git-send-email-ville.syrjala@linux.intel.com
VMA offsets are 64 bits. Plane surface offsets are in ggtt and
the hardware register to set this is thus 32 bits. Be explicit
about these and convert carefully to from vma to final size.
This will make sparse happy by not creating 32bit pointers out
of 64bit vma offsets.
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446204375-29831-1-git-send-email-mika.kuoppala@intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
In order to prepare for a link training with DDI, the state machine
would call intel_ddi_prepare_link_retrain(). To remove the dependency to
the hardware information, replace that direct call with a callback.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-7-git-send-email-ander.conselvan.de.oliveira@intel.com
I wanted to add yet another check to intel_fbc_update() and realized
I would need to create yet another enum no_fbc_reason case. So I
remembered this patch series that Damien wrote a long time ago and
nobody ever reviewed, so I decided to reimplement it since the code
changed a lot since then.
Credits-to: Damien Lespiau <damien.lespiau@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445964628-30226-2-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Make pinning and waiting a separate step, and wait for object idle
without struct_mutex held.
Changes since v1:
- Do not wait when a reset is in progress.
- Remove call to i915_gem_object_wait_rendering for
intel_overlay_do_put_image (Chris Wilson)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Move it from intel_crtc_atomic_commit to prepare_plane_fb.
Waiting is done before committing, otherwise it's too late
to undo the changes.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
v2: Don't forget to actually check the cstate->active value when
tallying up the number of active CRTC's. (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/59561/
A future patch will calculate these during the atomic 'check' phase
rather than at WM programming time, so let's store the watermark
values we're planning to use in the CRTC state; the values actually
active on the hardware remains in intel_crtc.
While we're at it, do some minor restructuring to keep ILK and SKL
values in a union.
v2: Don't move cxsr_allowed to state (Maarten)
v3: Only calculate watermarks in state. Still keep active watermarks in
intel_crtc itself. (Ville)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/59556/
The only platform that still has an update_sprite_wm entrypoint is SKL;
on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
then performs a regular watermark update. However intel_plane->wm is
only used to update a couple fields in intel_wm_config, and those fields
are never used by the SKL code, so on SKL an update_sprite_wm is
effectively identical to an update_wm call. Since we're already
ensuring that the regular intel_update_wm is called any time we'd try to
call intel_update_sprite_watermarks, the whole call is redundant and can
be dropped.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60372/
Determine whether we need to apply this workaround at atomic check time
and just set a flag that will be used by the main watermark update
routine.
Moving this workaround into the atomic framework reduces
ilk_update_sprite_wm() to just a standard watermark update, so drop it
completely and just ensure that ilk_update_wm() is called whenever a
sprite plane is updated in a way that would affect watermarks.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60367/
Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.
v2: Do not access potentialy old plane state at flip time,
but store the rotation value at the time of queing the flip.
(Ville)
v3: No need to pass rotation to intel_queue_mmio_flip since it
is available in the crtc. (Ville)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Testcase: igt/kms_rotation_crc/primary-rotation-90-flip-stress (SKL)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Especially in cases where pre-os does not enable display, cdclk might
not be in sane state. During sanitization initialize cdclk with maximum
value till we get dynamic cdclk support.
v2: Check if BIOS programmed correctly rather than always calling init
- Do validation of programmed cdctl and what it is expected
- Only do slk_init_cdclk if validation failed else reuse BIOS
programmed value
v3: Move the validation logic in a separate sanitize function (Ville)
v4: No need to check LCPLL after sanitize and use max_cdclk_freq instead
of hardcoded value (Ville)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445344992-14658-1-git-send-email-shobhit.kumar@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
atomic->disabled_planes is a hack that had to exist because
prepare_fb was only called when a new fb was set. This messed
up fb tracking in some circumstances like aborts from
interruptible waits. As a result interruptible waiting in
prepare_plane_fb was forbidden, but other errors could still
cause frontbuffer tracking to be messed up.
Now that prepare_fb is always called, this hack is no longer
required and prepare_fb may fail without consequences.
Changes since v1:
- Clean up a few fb tracking warnings by changing plane->fb to
plane->state->fb.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.
Addtional note from Imre:
Currently we keep DC6 enabled during modesets and DPAUX transfers, which
is not allowed according to the specification. This can lead at least to
PLL locking failures, DPAUX timeouts and prevent deeper package power
states (PC9/10). Fix this for now by enabling DC6 only when we know the
above events (modeset, DPAUX) can't happen.
This a temporary solution as some issues are still unsolved as described
in [1] and [2], we'll address those as a follow-up.
[1]
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077669.html
[2]
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077787.html
v1: Initial version.
v2: Based on review comment from Daniel,
- created a seperate patch for csr uninitialization set call.
v3: Rebased on top of latest code.
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a squash of the following commits:
Revert "drm/i915: Drop intel_update_sprite_watermarks"
This reverts commit 47c99438b5.
Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check"
This reverts commit 7809e5ae35.
Revert "drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)"
This reverts commit 3a05f5e2e7.
With these reverts, SKL finally stops failing every single FBC test
with FIFO underrun error messages. After some brief testing, it also
seems that this commit prevents the machine from completely freezing
when we run igt/kms_fbc_crc (see fd.o #92355).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92355
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's been reported that the atomic watermark series triggers some
regressions on SKL, which we haven't been able to track down yet. Let's
temporarily revert these patches while we track down the root cause.
This commit squashes the reverts of:
76305b1 drm/i915: Calculate watermark configuration during atomic check (v2)
a4611e4 drm/i915: Don't set plane visible during HW readout if CRTC is off
a28170f drm/i915: Calculate ILK-style watermarks during atomic check (v3)
de4a9f8 drm/i915: Calculate pipe watermarks into CRTC state (v3)
de165e0 drm/i915: Refactor ilk_update_wm (v3)
Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-October/077190.html
Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: "Vetter, Daniel" <daniel.vetter@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The link training functions had confusing names. The start function
actually does the clock recovery phase of the link training, and the
complete function does the channel equalization. So call them that
instead. Also, every call to intel_dp_start_link_train() was followed
by a call to intel_dp_complete_link_train(), so add a new start
function that calls clock_recory and channel_equalization.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Latest VBT mentions which set of registers will be used for BLC,
as controller number field. Making use of this field in BXT
BLC implementation. Also, the registers are used in case control
pin indicates display DDI. Adding a check for this.
According to Bspec, BLC_PWM_*_2 uses the display utility pin for output.
To use backlight 2, enable the utility pin with mode = PWM
v2: Jani's review comments
addressed
- Add a prefix _ to BXT BLC registers definitions.
- Add "bxt only" comment for u8 controller
- Remove control_pin check for DDI controller
- Check for valid controller values
- Set pipe bits in UTIL_PIN_CTL
- Enable/Disable UTIL_PIN_CTL in enable/disable_backlight()
- If BLC 2 is used, read active_low_pwm from UTIL_PIN polarity
Satheesh's review comment addressed
- If UTIL PIN is already enabled, BIOS would have programmed it. No
need to disable and enable again.
v3: Jani's review comments
- add UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK
- Disable UTIL_PIN if controller 1 is used
- Mask out UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK before enabling
UTIL_PIN
- check valid controller value in intel_bios.c
- add backlight.util_pin_active_low
- disable util pin before enabling
v4: Change for BXT-PO branch:
Stubbed unwanted definition which was existing before
because of DC6 patch.
UTIL_PIN_MODE_PWM (0x1b << 24)
v2: Fixed Jani's review comment.
v3: Split the backight PWM frequency programming into separate patch,
in cases BIOS doesn't initializes it.
v4: Starting afresh and not modifying existing state for backlight, as
per Jani's recommendation.
v5: Fixed Jani's review comment wrt util pin enable
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Don't forget to actually check the cstate->active value when
tallying up the number of active CRTC's. (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
