Currently we disable RPM functionality on platforms that doesn't support
this by not putting/getting the RPM reference we receive from the RPM
core during driver loading/unloading respectively. This is somewhat
obscure, so make it more explicit by keeping a reference dedicated for
this particular purpose whenever the driver is loaded. This makes it
possible to remove the HAS_RUNTIME_PM() special casing from every other
places in the next patch.
v2:
- fix intel_runtime_pm_get vs. intel_runtime_pm_put in
intel_power_domains_fini()
v3:
- take only a low level RPM reference so the ref tracking asserts
continue to work (Ville)
- update the commit message
- move the patch earlier for bisectability
Suggested-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>
Link: http://patchwork.freedesktop.org/patch/msgid/1450352696-16135-1-git-send-email-imre.deak@intel.com
We can make the RPM dependency on RC6 explcit in the code by taking an
actual RPM reference, instead of avoiding to drop the initial one. This
will also enable us to remove the HAS_RUNTIME_PM special casing from
more places in the next patch.
v2:
- fixed typo in commit message (Joonas)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-4-git-send-email-imre.deak@intel.com
The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
mailbox may specify an alternate location for VBT instead of mailbox #4.
Use the alternate location if available and valid, falling back to
mailbox #4 otherwise.
v2: Update debug logging (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178280-28020-1-git-send-email-jani.nikula@intel.com
I broke AVI/HDMI/SPD infoframes on HSW+ with the register type
safety changes. We were supposed to check that the infoframe data
register is valid before writing the infoframe data, but the check
ended up inverted, and so in practice we never wrote or enabled
these infoframes.
We were still sending out the GCP infoframe when the sink was
deep-color capable. That and the fact that we use a single
bool to track our infoframe state meant that the state checker
only caught this when a HDMI sink that doesn't do deep-color was
used.
We really need to fix our infoframe state checking to be much
more anal. But in the meantime let's just fix the regression.
In fact let's just throw out the register validity check and
convert some of the "unknown info frame type" debug messages
into MISSING_CASE(). So far we support the same set of infoframe
types on all platforms, so the silent debug messages make no
sense.
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: f0f59a00a1 ("drm/i915: Type safe register read/write")
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc)
Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450282200-4203-1-git-send-email-ville.syrjala@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93119
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the future the VBT might not be in mailbox #4 of the ACPI OpRegion,
thus unavailable in i915_opregion, so add a separate file for the VBT.
v2: Drop the locking as unneeded (Chris)
v3: Rebase
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178232-27780-1-git-send-email-jani.nikula@intel.com
Make the validation function a boolean operating on a buffer of given
size, removing the extra pointer dances.
Move the OpRegion based VBT validation to intel_opregion_setup(), only
initializing opregion->vbt if it's valid.
v2: move logging about valid VBT to opregion setup too (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178175-27420-1-git-send-email-jani.nikula@intel.com
The decision about which source will be used for VBT is done in
intel_parse_bios(), not in the VBT validation function. Make the VBT
validation function strictly about validation, and move the debug
logging to where it logically belongs.
Also split the logging about where the valid VBT was found and what the
signature is. This will make even more sense in the future when the
validation for ACPI OpRegion based VBT takes place at OpRegion setup
time.
v2: Split logging about VBT signature and BDB version.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178092-27148-1-git-send-email-jani.nikula@intel.com
Mailbox 5 is BIOS to Driver Notification mailbox is intended
to support BIOS to Driver event notification or data storage
for BIOS to Driver data synchronization purpose. Mailbox 5 is
the extension of mailbox 3.
v4 by Jani:
- don't add asle_ext to dev_priv as it's unused
- use u8 for bddc and rsvd fields in asle ext struct
- add BUILD_BUG_ON the asle ext struct size
- debug logging for asle ext present
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Deepak M <m.deepak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/c2d4009659fca32280d9859ec34a62f45b86d895.1450089383.git.jani.nikula@intel.com
The cursor code tries to treat base==0 to mean disabled. That fails
when the cursor bo gets bound at ggtt offset 0, and the user is left
looking at an invisible cursor.
We lose the disabled->disabled optimization, but that seems like
something better handled at a slightly higher level.
Cc: drm-intel-fixes@lists.freedesktop.org
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/1450091808-32607-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
This bit is also reserved on Skylake. Actually the only
platform that supports this is Haswell, so let's fix
this logic and apply this link entry time only for the
platform that supports it, i.e. Haswell.
This also changes the style to let more clear platform
differences outside the reg write. We would probably catch
this case sooner if separated, or not...
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449880291-21388-1-git-send-email-rodrigo.vivi@intel.com
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>
When creating a new (pageable) GEM object and filling it with data, we
must mark it as 'dirty', i.e. backing store is out-of-date w.r.t. the
newly-written content. This ensures that if the object is evicted under
memory pressure, its pages in the pagecache will be written to backing
store rather than discarded.
Based on an original version by Alex Dai.
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1449773486-30822-3-git-send-email-david.s.gordon@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In various places, a single page of a (regular) GEM object is mapped into
CPU address space and updated. In each such case, either the page or the
the object should be marked dirty, to ensure that the modifications are
not discarded if the object is evicted under memory pressure.
The typical sequence is:
va = kmap_atomic(i915_gem_object_get_page(obj, pageno));
*(va+offset) = ...
kunmap_atomic(va);
Here we introduce i915_gem_object_get_dirty_page(), which performs the
same operation as i915_gem_object_get_page() but with the side-effect
of marking the returned page dirty in the pagecache. This will ensure
that if the object is subsequently evicted (due to memory pressure),
the changes are written to backing store rather than discarded.
Note that it works only for regular (shmfs-backed) GEM objects, but (at
least for now) those are the only ones that are updated in this way --
the objects in question are contexts and batchbuffers, which are always
shmfs-backed.
Separate patches deal with the cases where whole objects are (or may
be) dirtied.
v3: Mark two more pages dirty in the page-boundary-crossing
cases of the execbuffer relocation code [Chris Wilson]
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1449773486-30822-2-git-send-email-david.s.gordon@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When clearing an execlist queue, instead of traversing it and unreferencing all
requests while holding the spinlock (which might lead to thread sleeping with
IRQs are turned off - bad news!), just move all requests to the retire request
list while holding spinlock and then drop spinlock and invoke the execlists
request retirement path, which already deals with the intricacies of
purging/dereferencing execlist queue requests.
This patch can be considered v3 of:
commit b96db8b81c54ef30485ddb5992d63305d86ea8d3
Author: Tomas Elf <tomas.elf@intel.com>
drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues
This patch assumes v2 of the above patch is part of the baseline, reverts v2
and adds changes on top to turn it into v3.
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1445619757-19822-1-git-send-email-tomas.elf@intel.com
Reviewed-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Dave Gordon <dave.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pipe is assigned based on the port, but it should be
based on current crtc. Correcting the same in this patch.
v2: Use macro BXT_PIPE_SELECT(pipe) (Daniel)
Signed-off-by: Deepak M <m.deepak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mainly aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it was suggested to move retries to drm level.
Since drm level was already taking care of retries and didn't want
to through random retries on that level the second solution was to
put the retries at aux_transfer layer what was nacked.
So I realized we had so many retries in different places and
started to organize that a bit. During this organization I noticed
that we weren't handing at all the case were the message size was
zeroed. And this was exactly the case that was affecting sink_crc.
Also we weren't respect BSPec who says this size message = 0 or > 20
are forbidden.
It is a fact that we still have no clue why we are getting this
forbidden value there. But anyway we need to handle that for now
so we return -EBUSY and drm level takes care of the retries that
are already in place.
v2: Print debug messsage when this case is reached as suggested
by Jani.
v3: This patch is crucial to make PSR test cases reliably working
on SKL. So split this patch from the aux re-org series and add
a FIXME as a promisse to continue that effort besides reminding
to remove the sleep when that is merged.
v4: Use a bigger usleep range so kernel doesn't need to be interrupted
on a exact time, as suggested by Paulo.
But anyway we should discuss the better time
ranges on the EBUSY handle re-org at drm level since this one here
is temporary.
v5: s/1000,1500/1000, 1500/ (by Paulo).
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449774747-2772-1-git-send-email-rodrigo.vivi@intel.com
Based on Chris Wilson's patch from 6 months ago, rebased and adapted.
The current implementation of intel_ring_initialized() is too heavyweight;
it's a non-inlined function that chases several levels of pointers. This
wouldn't matter too much if it were rarely called, but it's used inside
the iterator test of for_each_ring() and is therefore called quite
frequently. So let's make it simple and inline ...
The idea here is to use ring->dev as an indicator showing which engines
have been initialised and are therefore to be included in iterations that
use for_each_ring(). This allows us to avoid multiple memory references
and a (non-inlined) function call on each iteration of each such loop.
Fixes regression from
commit 48d823878d
Author: Oscar Mateo <oscar.mateo@intel.com>
Date: Thu Jul 24 17:04:23 2014 +0100
drm/i915/bdw: Generic logical ring init and cleanup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449586956-32360-2-git-send-email-david.s.gordon@intel.com
This patch adds a reverse mapping from a digital port number to
intel_encoder object containing the corresponding intel_digital_port.
It simplifies the query of the encoder a lot.
Note that, even if it's a valid digital port, the dig_port_map[] might
point still to NULL -- usually it implies a DP MST port. Due to this
fact, the NULL check in each place has no WARN_ON() and just skips the
port. Once when the situation changes in future, we might introduce
WARN_ON() for a more strict check.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
When disable_noatomic is called plane_mask is not correct yet, and
plane_state->visible = true is left as true after disabling the primary
plane.
Other planes are already disabled as part of crtc sanitization, only the
primary is left active. But the plane_mask is not updated here. It gets
updated during fb takeover in modeset_gem_init, or set to the new value
on resume.
This means that to disable the primary plane 1 << drm_plane_index(primary)
needs to be used.
Afterwards because the crtc is no longer active it's forbidden to keep
plane_state->visible set, or a WARN_ON in
intel_plane_atomic_calc_changes triggers. There are other code points
that rely on accurate plane_state->visible too, so make sure the bool is
cleared.
The other planes are already disabled in intel_sanitize_crtc, so they
don't have to be handled here.
Cc: stable@vger.kernel.org #v4.3, v4.2?
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92655
Tested-by: Tomas Mezzadra <tmezzadra@gmail.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/5652DB88.9070208@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.
In this case remove the BUG_ON call in vlv_enable_pll().
v2: Also remove the BUG_ON call in chv_enable_pll(). (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449529362-18193-1-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.
In this case, in i915_gem_alloc_context_obj() only call
i915_gem_object_set_cache_level() for Ivy Bridge devices
since later platforms don't have L3 control bits in the PTE.
v2: Expand comment to mention snooping requirement. (Ville, Imre)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449596332-23470-1-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.
In this case remove a hack for VLV A0.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449514270-15171-4-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.
In this case check for '(GEN7 || GEN8) && HAS_PCH_SPLIT' since we're
reading FUSE_STRAP and SFUSE_STRAP which live in the PCH.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449514270-15171-3-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The cherryview device shares many characteristics with the valleyview
device. When support was added to the driver for cherryview, the
corresponding device info structure included .is_valleyview = 1.
This is not correct and leads to some confusion.
This patch changes .is_valleyview to .is_cherryview in the cherryview
device info structure and simplifies the IS_CHERRYVIEW macro.
Then where appropriate, instances of IS_VALLEYVIEW are replaced with
IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent.
v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro.
Also add followup patches to fix issues discovered during the first
review. (Ville)
v3: Fix some style issues and one gen check. Remove CRT related changes
as CRT is not supported on CHV. (Imre, Ville)
v4: Make a few more optimizations. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449692975-14803-1-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
In order to avoid accessing GPU registers while GPU is suspended cancel
the hangcheck work before calling intel_suspend_complete which actually
puts the GPU to suspend. Otherwise hangcheck might do MMIO reads to a
suspended GPU.
Placement before intel_guc_suspend is imitated from i915_drm_suspend
which cancels the work at i915_gem_suspend, to keep the functions
similar.
On VLV systems, namely BYT, this was causing an error during runtime
suspend cycle:
[drm:vlv_check_no_gt_access [i915]] *ERROR* GT register access while GT waking disabled
Testcase: igt/pm_rpm/basic-rte
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93121
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1449669373-8588-1-git-send-email-joonas.lahtinen@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
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
All of these iterator macros require a 'temp' argument, used merely to
hold internal partial results. We can instead declare the temporary
variable inside the macro, so the caller need not provide it.
Some of the old code contained nested iterators that actually reused the
same 'temp' variable for both inner and outer instances. It's quite
surprising that this didn't introduce bugs! But it does show that the
value of 'temp' isn't required to persist during the iterated body.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449581451-11848-2-git-send-email-david.s.gordon@intel.com
Kabylake A0 is based on Skylake H0.
v2: Don't assume revid+7 and only load the one we are sure about.
v3: Rebase on top of latest changes.
v4: Accept cleaner solution from Jani with kbl_stepping_info
starting on H0 instead of put a hack on revid.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449676319-6959-1-git-send-email-rodrigo.vivi@intel.com
We were not checking the return value of drm_encoder_init() which can
fail. And if it fails then we will be working with an uninitialized
encoder.
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1444312681-10149-2-git-send-email-sudipm.mukherjee@gmail.com
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris
Wilson. Fixed incorrect error paths causing crash found by Michal Winiarski.
(Not published externally)
v3: Rebased because of trivial conflict in object_bind_to_vm. Fixed eviction
to allow eviction of soft-pinned objects when another soft-pinned object used
by a subsequent execbuffer overlaps reported by Michal Winiarski.
(Not published externally)
v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
pinned first after an address conflict happens to avoid repeated conflicts in
rare cases (Suggested by Chris Wilson). Expanded comment on
drm_i915_gem_exec_object2.offset to cover this new API.
v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability
(Kristian). Added check for multiple pinnings on eviction (Akash). Made sure
buffers are not considered misplaced without the user specifying
EXEC_OBJECT_SUPPORTS_48B_ADDRESS. User must assume responsibility for any
addressing workarounds. Updated object2.offset field comment again to clarify
NO_RELOC case (Chris). checkpatch cleanup.
v6: Trivial rebase on latest drm-intel-nightly
v7: Catch attempts to pin above the max virtual address size and return
EINVAL (Tvrtko). Decouple EXEC_OBJECT_SUPPORTS_48B_ADDRESS and
EXEC_OBJECT_PINNED flags, user must pass both flags in any attempt to pin
something at an offset above 4GB (Chris, Daniel Vetter).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Zou Nanhai <nanhai.zou@intel.com>
Cc: Kristian Høgsberg <hoegsberg@gmail.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Acked-by: PDT
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449575707-20933-1-git-send-email-thomas.daniel@intel.com
Let's introduce ULT and ULX Kabylake definitions and start
using it for a propper DDI buffer translation.
v2: Remove extra white space. (Paulo)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
As described in the code comment, I couldn't set the minimum RPS
frequency on my BYT-M B0 to the minimum allowed as reported by Punit.
Fix this by clamping the minimum value to the first one that was
accepted on my machine.
Atm this issue doesn't cause any test failures, since in igt/pm_rps we
only check the cached version of the current frequency which is the same
what has been set. In the future we'll add checks for the actual
frequency too, and for that to pass this fix is necessary.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1417711175-13271-1-git-send-email-imre.deak@intel.com
Currently we disable some parts of FDI setup after a failed link
training. But despite that we continue with the modeset as if everything
is fine. This results in tons of noise from the state checker, and
it means we're not following the proper modeset sequence for the rest of
crtc enabling, nor for crtc disabling.
Ideally we should abort the modeset and follow the proper disable
sequence to shut off everything we enabled so far, but that would
require a big rework of the modeset code. So instead just leave FDI
up and running in its untrained state, and log an error. This is
what we do on older platforms too.
v2: Fix a typo in the commit message
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449260570-14670-1-git-send-email-ville.syrjala@linux.intel.com
Extract the LPT-H VGA dotclock disable to a separate function in
anticipation of further use.
While at it move the sb_lock locking inwards when enabling the VGA
dotclock, as it's only needed to protect the sideband accesses.
v2: Keep the PIXCLK_GATE_GATE name for 0 (Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449260494-14449-1-git-send-email-ville.syrjala@linux.intel.com
Bspec modeset sequence tells us to disable the PCH transcoder and
FDI after the CRT port on LPT-H, so let's do that. And the CRT port
should be disabled after the pipe, as we do on other PCH platforms
too since
commit 1ea56e269e ("drm/i915: Disable CRT port after pipe on PCH platforms")
commit 00490c22b1 ("drm/i915: Consider SPLL as another shared pll, v2.")
moved the SPLL disable from the .post_disable() hook to some upper
level code, so we can just move the CRT port disabling into the
.post_disable() hook. If we still had the non-shared SPLL, it would have
needed to be moved into the .post_pll_disable() hook.
v2: Actually move the CRT port disable to the .post_disable() hook,
and amend the commit message with more details (Paulo)
v3: Fix typos in commit message (Paulo)
Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449583548-11896-1-git-send-email-ville.syrjala@linux.intel.com
When we want to use SPLL for FDI we want SSC, which means we have to
disable clock bending for the PCH SSC reference (bend and spread are
mutually exclusive). So let's turn off bending when we want spread.
In case the BIOS enabled clock bending for some reason we'll just turn
it off and enable the spread mode instead.
Not sure what happens if the BIOS is actually using the bend source for
HDMI at this time, but I suppose it should be no worse than what already
happens when we simply turn on the spread.
We don't currently use the bend source for anything, and only use the
PCH SSC reference for the SPLL to drive FDI (always with spread).
v2: Fix the %5 vs %10 fumble for SSCDITHPHASE (Paulo)
Add 'WARN_ON(steps % 5 != 0)' sanity check (Paulo)
Fix typos in commit message (Paulo)
Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449260379-14093-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
There is conflicting info between E0 and F0 steppings
for this workarounds. Trust more authoritative source and
be conservative and extend also for F0.
This prevents numerous (>50) gpu hangs with SKL GT4e
during piglit run.
References: HSD: gen9lp/2134184
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449505785-20812-1-git-send-email-mika.kuoppala@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWZMgaAAoJEHm+PkMAQRiGGcIH+gNS/hbN2DKW7wphl1QuaV7C
1fror8AvpwbGa/o0yuxovaVuZzAR0TF31vn+gAemF4U/hnM25xqxEHXYZEVv8OWw
mbz4/z+jbVk3SiS5AiZPIZgL4W6RZnG5QYfiTVGPlBHuBznW2ITlNlClBOmBL45o
uhb3bjTzi70AZ7Gh6i9sHgJoHg6D9u/ZxLaLcWnM79BzyTMHTf2t0wnrQmh66lEE
hp7Rn9wXv9bk/e3iH7CVUb97P4IWhhkmfqcoturqAg9+C/M26b0VmvQp9Sy8S6Pd
FVQ+SUIZllj5ZDKe9mOcs37czlxTr0keEFqzWeMh/7y4iuI3RaRp/qb+7mX5sIE=
=WGZ1
-----END PGP SIGNATURE-----
Back merge tag 'v4.4-rc4' into drm-next
We've picked up a few conflicts and it would be nice
to resolve them before we move onwards.
'commit 97173eaf5 ("drm/i915: PSR: Increase idle_frames")' was a mistake.
The special case it tried to cover was already being covered by
the DP_PSR_NO_TRAIN_ON_EXIT. So this ended up duplicated.
So, instead of reverting that let's take this opportunity and unify
the idle_frame definition in a single place so we standardize the access
and avoid room for that same mistake again.
Few changes with this patch:
1. Instead of just respecting the VBT we set a
global minumum with max(). So we are sure that we will avoid corner cases
in case VBT is doing something we don't understand.
2. Instead of minimum 5 we use 6. When introducing the idle_frames += 4 case
we considered that minimum was 2. All because the off-by-one issue.
v2: Unified idle_frame definition.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449528320-27655-1-git-send-email-rodrigo.vivi@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>
This reverts commit 6d65ba943a.
Mika Kuoppala traced down a use-after-free crash in module unload to
this commit, because ring->last_context is leaked beyond when the
context gets destroyed. Mika submitted a quick fix to patch that up in
the context destruction code, but that's too much of a hack.
The right fix is instead for the ring to hold a full reference onto
it's last context, like we do for legacy contexts.
Since this is causing a regression in BAT it gets reverted before we
can close this.
Cc: Nick Hoath <nicholas.hoath@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Dai <yu.dai@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93248
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This was broken in
commit 6a8beeffed
Author: Wayne Boyer <wayne.boyer@intel.com>
Date: Wed Dec 2 13:28:14 2015 -0800
drm/i915: Clean up device info structure definitions
and I didn't spot this while reviewing. We really need that CI farm up
asap!
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
In commit 2e1b873072 [v4.2]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Apr 27 13:41:22 2015 +0100
drm/i915: Convert RPS tracking to a intel_rps_client struct
we converted the __i915_wait_request() to take a new intel_rps_client
struct (rather than having to pass fake drm_i915_file_private structs).
However, due to use of passing a void pointer, I didn't spot one
callsite in wait-ioctl was passing the wrong pointer.
Fwiw, the impact of this bug is zero. Along the rps path, we always
first call list_empty(rps) which when we pass in the wrong pointer
always evaluates to false and we return early and never chase the
invalid pointers.
The user visible impact is then wait-ioctl doesn't get the same
waitboosting as the other interfaces (set-domain, throttle), which is a
performance concern for the *very* few users of the wait interface.
There is also a libdrm_intel patch to use the wait-ioctl for
drm_intel_bo_wait_rendering() if anyone feels inclined to review
libdrm_intel patches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Add Chris' explanation for why the impact of this is pretty
close to 0.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Beginning with gen7, newer devices repetitively redefine values
for the device info structure members. This patch simplifies the
structure definitions by grouping member value definitions into the
existing GEN7_FEATURES #define and into the new GEN7_LP_FEATURES
and HSW_FEATURES #defines.
Specifically, GEN_DEFAULT_PIPEOFFSETS and IVB_CURSOR_OFFSETS are
added to GEN7_FEATURES and subsequent IVB definitions are simplified.
VLV_FEATURES is defined to differentiate and simplify the
gen7 low power (LP) devices.
HSW_FEATURES is defined and used to simplify all HSW+ devices
except for LP.
v2: Use VLV_FEATURES for the gen7 low power devices. (Jani)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449091694-7681-1-git-send-email-wayne.boyer@intel.com
In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for exclusive
fence
v2: First commit
v3: Remove object_name_lock acquire
Move wait from intel_atomic_commit() to intel_prepare_plane_fb()
v4: Wait only on exclusive fences, interruptible with no timeout
v5: Style tweaks to more closely match rest of file
v6: Properly handle interrupted waits
v7: No change
v8: No change
Link: https://patchwork.kernel.org/patch/7704181/
Signed-off-by: Alex Goins <agoins@nvidia.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
If a buffer is backed by dmabuf, wait on its reservation object's exclusive
fence before flipping.
v2: First commit
v3: Remove object_name_lock acquire
v4: Move wait ahead of mark_page_flip_active
Use crtc->primary->fb to get GEM object instead of pending_flip_obj
use_mmio_flip() return true when exclusive fence is attached
Wait only on exclusive fences, interruptible with no timeout
v5: Move wait from do_mmio_flip to mmio_flip_work_func
Style tweaks to more closely match rest of file
v6: Change back to unintteruptible wait to match __i915_wait_request due to
inability to properly handle interrupted wait.
Warn on error code from waiting.
v7: No change
v8: Test for !reservation_object_signaled_rcu(test_all=FALSE) instead of
obj->base.dma_buf->resv->fence_excl
Link: https://patchwork.kernel.org/patch/7704181/
Signed-off-by: Alex Goins <agoins@nvidia.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.
This fixes an issue with GuC submission where the GPU might not
have finished writing back the context before it is unpinned. This
results in a GPU hang.
v2: Moved the new pin to cover GuC submission (Alex Dai)
Moved the new unpin to request_retire to fix coverage leak
v3: Added switch to default context if freeing a still pinned
context just in case the hw was actually still using it
v4: Unwrapped context unpin to allow calling without a request
v5: Only create a switch to idle context if the ring doesn't
already have a request pending on it (Alex Dai)
Rename unsaved to dirty to avoid double negatives (Dave Gordon)
Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
Split out per engine cleanup from context_free as it
was getting unwieldy
Corrected locking (Dave Gordon)
v6: Removed some bikeshedding (Mika Kuoppala)
Added explanation of the GuC hang that this fixes (Daniel Vetter)
v7: Removed extra per request pinning from ring reset code (Alex Dai)
Added forced ring unpin/clean in error case in context free (Alex Dai)
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Issue: VIZ-4277
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Dai <yu.dai@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For now, remove the spinlocks that protected the GuC's
statistics block and work queue; they are only accessed
by code that already holds the global struct_mutex, and
so are redundant (until the big struct_mutex rewrite!).
The specific problem that the spinlocks caused was that
if the work queue was full, the driver would try to
spinwait for one jiffy, but with interrupts disabled the
jiffy count would not advance, leading to a system hang.
The issue was found using test case igt/gem_close_race.
The new version will usleep() instead, still holding
the struct_mutex but without any spinlocks.
v4: Reorganize commit message (Dave Gordon)
v3: Remove unnecessary whitespace churn
v2: Clean up wq_lock too
v1: Clean up host2guc lock as well
Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449104189-27591-1-git-send-email-yu.dai@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no need to stop and restart FBC, which is quite expensive as
we have to revalidate the CRTC state. After flushing a drawing
operation we know the CRTC state hasn't changed, so a nuke
(recompress) should be fine.
v2: Make it simpler (Chris).
v3: Rewrite the patch again due to patch order changes.
v4: Rewrite commit message (Chris).
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/
When running Cinnamon I see way too many pairs of these messages: many
per second. Get rid of them as they're just telling us FBC is working
as expected. We already have the messages for enable/disable, so we
don't really need messages for activation/deactivation.
v2: 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/
Directly call intel_fbc_calculate_cfb_size() in the only place that
actually needs it, and use the proper check before removing the stolen
node. IMHO, this change makes our code easier to understand.
v2: Use drm_mm_node_allocated() (Chris).
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/
This was already on my TODO list, and was requested both by Chris and
Ville, for different reasons. The advantages are avoiding a frequent
malloc/free pair, and the locality of having the work structure
embedded in dev_priv. The maximum used memory is also smaller since
previously we could have multiple allocated intel_fbc_work structs at
the same time, and now we'll always have a single one - the one
embedded on dev_priv. Of course, we're now using a little more memory
on the cases where there's nothing scheduled.
The biggest challenge here is to keep everything synchronized the way
it was before.
Currently, when we try to activate FBC, we allocate a new
intel_fbc_work structure. Then later when we conclude we must delay
the FBC activation a little more, we allocate a new intel_fbc_work
struct, and then adjust dev_priv->fbc.fbc_work to point to the new
struct. So when the old work runs - at intel_fbc_work_fn() - it will
check that dev_priv->fbc.fbc_work points to something else, so it does
nothing. Everything is also protected by fbc.lock.
Just cancelling the old delayed work doesn't work because we might
just cancel it after the work function already started to run, but
while it is still waiting to grab fbc.lock. That's why we use the
"dev_priv->fbc.fbc_work == work" check described in the paragraph
above.
So now that we have a single work struct we have to introduce a new
way to synchronize everything. So we're making the work function a
normal work instead of a delayed work, and it will be responsible for
sleeping the appropriate amount of time itself. This way, after it
wakes up it can grab the lock, ask "were we delayed or cancelled?" and
then go back to sleep, enable FBC or give up.
v2:
- Spelling fixes.
- Rebase after changing the patch order.
- Fix ms/jiffies confusion.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
This moves the pre-gen4 check from update() to enable(). The HAS_DDI
in the original code is not needed since only gen 2/3 have the plane
swapping code.
v2: Rebase.
v3: Extract fbc_on_plane_a_only() (Chris).
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/
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
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 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/
This thing where we need to get the crtc either from the work
structure or the fbc structure itself is confusing and unnecessary.
Set fbc.crtc right when scheduling the enable work so we can always
use it.
The problem is not what gets passed and how to retrieve it. The
problem is that when we're in the other parts of the code we always
have to keep in mind that if FBC is already enabled we have to get the
CRTC from place A, if FBC is scheduled we have to get the CRTC from
place B, and if it's disabled there's no CRTC. Having a single place
to retrieve the CRTC from allows us to treat the "is enabled" and "is
scheduled" cases as the same case, reducing the mistake surface. I
guess I should add this to the commit message.
Besides the immediate advantages, this is also going to make one of
the next commits much simpler. And even later, when we introduce
enable/disable + activate/deactivate, this will be even simpler as
we'll set the CRTC at enable time. So all the
activate/deactivate/update code can just look at the single CRTC
variable regardless of the current state.
v2: 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/
In function find_compression_threshold() we try to over-allocate CFB
space in order to reduce reallocations and fragmentation, and we're
not considering that at the CFB size check. Consider it.
There is also a longer-term plan to kill
dev_priv->fbc.uncompressed_size, but this will come later.
v2: Use drm_mm_node_allocated() (Chris).
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 are platforms that don't need the full GMBUS power domain (BXT)
while others do (PCH, VLV/CHV). For optimizing this we would need to add
a new power domain, but it's not clear how much we would benefit given
the short time we hold the reference. So for now let's keep things
simple.
This fixes a regression introduced in
commit 237ed86c69
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Tue Sep 15 09:44:20 2015 +0530
drm/i915: Check live status before reading edid
v2:
- fix commit message, PCH won't take any redundant power resource after
this change (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[fix commit message in v2 (Imre)]
[Cherry-picked from drm-intel-next-queued 29bb94bb (Imre)]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-6-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
MISSING_CASE() would have been useful to track down a recent problem in
intel_display_port_aux_power_domain(), so add it there and a few related
helpers. This was also suggested by Ville in his review of the latest
DMC/DC changes, we forgot to address that.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
[Cherry-picked from drm-intel-next-queued b9fec167 (Imre)]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-5-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Due to the current sharing of the DDI encoder between DP and HDMI
connectors we can run the DP detection after the HDMI detection has
already set the shared encoder's type. For now solve this keeping the
current behavior and running the detection in this case too. For a proper
solution Ville suggested to split the encoder into an HDMI and DP one, that
can be done as a follow-up.
This issue triggers the WARN in intel_display_port_aux_power_domain() and
was introduced in:
commit 25f78f58e5
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Nov 16 15:01:04 2015 +0100
drm/i915: Clean up AUX power domain handling
CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
[Cherry-picked from drm-intel-next-queued 651174a4 (Imre)]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-4-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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>
[Cherry-picked from drm-intel-next-queued f0ab43e6 (Imre)]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-3-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@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>
[Cherry-picked from drm-intel-next-queued 25f78f58 (Imre)]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-2-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Choose between i2c bit banging and gmbus in a new higher level function,
and let the i2c core retry the first time we fall back to bit banging.
The i2c core imposes a timeout on -EAGAIN, but it defaults to 1 second,
and shouldn't be a problem for us.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448980166-23055-2-git-send-email-jani.nikula@intel.com
Unfortunatey there appear to quite a few HSW/BDW machines (eg.
NUCs, Brix Pro) in the wild with LPT/WPT-H that have no physical
CRT connector and non-working FDI. FDI training fails every
single time on these machines. Dunno, maybe they just didn't
bother wiring it up or something?
Unfortunately all the fuse bits and whatnot are telling us that
the CRT connector is present. And so what we get from this is tons
of false positives from the CI systems due to VGA connector forcing.
I've not found any way to detect this purely from hardware, so we
have to resort to looking at the VBT int_crt_support bit. We used
to check this bit on all platforms, but that broke all the old
machines, so the check was then restricted to VLV only in
commit 84b4e042c4 ("drm/i915: only apply crt_present check on VLV")
Considering HSW and VLV VBT probably got defined around the same time,
it should be reasonably safe to assume that the bits is sane for
HSW/BDW as well. At least I have one copy of some VBT spec here that
says it's meant for both VLV and HSW, and it knows about the bit
(lists it being valid from version 155 onwards). Also I have two
desktop machines with actual CRT ports and both have
int_crt_support==1 in their VBTs.
Also we already trust VBT >= 155 to tell us various details about
the DDI ports, so trusting it a bit more seems reasonable.
As far as VLV goes, the added VBT version check should be fine. Even
if someone has some weird VLV machine with a very old VBT version,
it just means they'll end up with a shadow CRT connector. IIRC the
reason for eliminating the shadow CRT connector on VLV was to speed
up display probing rather than fixing something more serious.
v2: Move the platform checks into the VBT parsing code
Also check that the VBT version is at least 155
v3: Improve commit message (Paulo)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449005493-15487-1-git-send-email-ville.syrjala@linux.intel.com
On HSW/BDW DDI A and E share 2 lanes, so when DDI A requires the
shared lanes DDI E can't be used. The lanes are not supposed to
be dynamically switched between the two uses, so there's no point
in registering the CRT connector when DDI E has no lanes.
v2: Fix typos in the commit message (Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449005396-15319-1-git-send-email-ville.syrjala@linux.intel.com
LPT-H has a strap bit for fused off CRT block. Check it to see if
we should register the CRT connector or not. Supposedly this also
forces the ADAP enable bit to 0, so the detection we added in
commit 6c03a6bd0d ("drm/i915: Don't register CRT connector when it's fused off")
should already catch it, but checking the fuse bit should at least
do no harm.
v2: Use HAS_PCH_LPT_H() (Paulo)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449005335-15192-1-git-send-email-ville.syrjala@linux.intel.com
Imre Deak