MI_BATCH_BUFFER is nasty since it requires that userspace pass in the
correct batch length.
Let's switch to using MI_BATCH_BUFFER_START instead (like we do on
other platforms). Then we don't have to specify the batch length
at all, and the CS will instead execute until it sees the
MI_BATCH_BUFFER_END.
We still need the batch length since we do the CS TLB workaround
and copy the batch into the permanently pinned scratch object
and execute it from there. But for this we can simply use the
batch object length when the user hasn't specified the actual
batch length. So specifying the batch length becomes just a
way to optimize the batch copy a little bit.
We lost batch_len from a bunch of igts (including the quiesce batch)
so without this igt is utterly broken on 830/845. Also some igts such
as gem_cpu_reloc never specified the batch_len and so didn't work.
With MI_BATCH_BUFFER_START we don't have to fix up igt every time
someone forgets that 830/845 exist.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450110229-30450-11-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
My 85x has VBT version 108 which has a child dev size of 27 bytes.
Let's allow that without printing an error.
We still want to reject the actual parsin since for that we need
the child device size to be at least 33 bytes. So we should still
check for that, but let's make it print a debug message only instead
of an error.
While at it, toss in a BUILD_BUG_ON() to verify our struct
old_child_dev_config is in fact 33 bytes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450110229-30450-8-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We use the vblank timestamps to generate the vblank frame counter value
on gen2. That means we need the pipe scanout position to be accurate
when we call drm_crtc_vblank_on(), otherwise the frame counter
guesstimate may jump when the pipe actually start.
What I observed on my 85x is that the DSL initially reads 0, and when
the pipe actually starts DSL jumps to vblank_start. On gen2 DSL==0 means
actually vtotal-1 (see update_scanline_offset()), so if we initially
get vtotal-1, and then very quickly vblank_start (or thereabouts), the
scanout position will appear to jump backwards by approximately one
vblank length. Which means the frame counter guesstimate will also
jump backwards. That's no good, so let's make sure the pipe has
started before we call drm_crtc_vblank_on().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450110229-30450-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the ddi buffer translation programming to occur from the encoder
.pre_enable() hook, for just the ddi port we are enabling. Previously
we used to reprogram the translations for all ddi ports during
init and during power well enabling.
v2: s/intel_prepare_ddi_buffers/intel_prepare_ddi_buffer/ (Daniel)
Resolve conflicts due to dev_priv->atomic_cdclk_freq
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make the ddi buffer programming code a bit more neat by passing
around dev_priv instead of dev.
v2: Resolve conflicts due to KBL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
skl_get_buf_trans_edp() effectively contains another copy of
skl_get_buf_trans_dp(). Remove the duplication and just call
skl_get_buf_trans_dp() from skl_get_buf_trans_edp().
v2: Resolve conflicts due to KBL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
skl_get_buf_trans_*() don't need the 'ddi_translations' local variable
since all they with is assign and return. Just return the right thing
directly and get rid of the local variable.
v2: Resolve conflicts due to KBL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
Rather than having open coded checks for the DDI A/E configuration,
just store the max supported lane count in intel_digital_port.
We had an open coded check for DDI A, but not for DDI E. So we may
have been vilating the DDI E max lane count.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're supposed to pass the primary DP encoder to intel_ddi_clk_select(),
not the fake MST encoder. Do so.
There's no real bug here though, since intel_ddi_clk_select() only
checks if the encoder type is EDP (which it isn't for either the
primary DP encoder or the fake MST encoder), and it gets the DDI port
via intel_ddi_get_encoder_port() (which knows how to do the
fake->primary->port dance itself).
Fixes: e404ba8 ("drm/i915: Setup DDI clk for MST on SKL")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449597590-6971-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The sequence block has sizes of elements after the operation byte since
sequence block v3. Use it to skip elements we don't support yet.
v2: remove redundant exec_elem[operation_byte] check (Daniel)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452006408-27688-1-git-send-email-jani.nikula@intel.com
The changes since the sequence block v2 are:
* The whole MIPI bios data block has a separate 32-bit size field since
v3, stored after the version. This facilitates big sequences.
* The size of the panel specific sequence blocks has grown to 32
bits. This facilitates big sequences.
* The elements within sequences now have an 8-bit size field following
the operation byte. This facilitates skipping unknown new operation
bytes, i.e. forward compatibility.
v2 (of the patch): use DRM_ERROR for unknown operation byte
v3 (of the patch): even more bounds checking (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/1452518102-3154-1-git-send-email-jani.nikula@intel.com
If we go into suspend with unclaimed access detected,
it would be nice to catch that access on a next suspend path.
So instead of just notifying about it, arm the unclaimed
mmio checks on suspend side.
We want to keep the asymmetry on resume, as if it was
on resume path, it was not driver that is responsible so
no point in arming mmio debugs.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1452261080-6979-2-git-send-email-mika.kuoppala@intel.com
With commit 8ac3e1bb76 ("drm/i915: Add non claimed mmio checking
for vlv/chv") we now have chv/vlv support in place for detecting
unclaimed access. Also the perf hit of extra mmio read
is now only suffered if mmio_debug is set.
This allows us to stuff the macro for unclaimed reg
detection inside a generic gen6 register access, as now all
gens using these macros uses also unclaimed debugs, the one
exception being snb. We gain more clean and generic macros
and only downside is that snb will suffer one branch perf hit
without upside.
Note that the hsw write path debug register check now
happens before fifo check, but this should not make
any real difference.
As vlv/chv use the generic gen6 access macros, the consequence
is that they gain the mmio_debug feature.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1452261080-6979-1-git-send-email-mika.kuoppala@intel.com
This fixes a spurious warning from an integer overflow on 64-bits systems.
The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1.
Explicitly handling this by casting to lret fixes it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-and-tested-by: Joseph Yasi <joe.yasi@gmail.com>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 3c28ff22f6 ("i915: wait for fence in prepare_plane_fb")
Link: http://patchwork.freedesktop.org/patch/msgid/5666EEC8.2000403@linux.intel.com
Extend the same reasoning as in the patch listed below. It's not an
error for the workaround list to be empty if no workarounds are needed.
commit 02235808b6
Author: Francisco Jerez <currojerez@riseup.net>
Date: Wed Oct 7 14:44:01 2015 +0300
drm/i915: Don't warn if the workaround list is empty.
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452129330-3484-2-git-send-email-rodrigo.vivi@intel.com
When adding IS_KABYLAKE definition I didn't included the
DC states related because I was planing to include them
with the patch that fixes DMC firmware loading, but I
forgot them.
Meanwhile this runtime pm code changed a lot for
Skylake.
Well, I didn't expect that this would crash the machine
and I just noticed now that Sarah warned me our driver
wasn't working. Thanks Sarah.
Michel had found the main error first and his
fix had better details on the history and got
merged already:
commit 16fbc291cb
Author: Michel Thierry <michel.thierry@intel.com>
Date: Wed Jan 6 12:08:36 2016 +0000
drm/i915/kbl: Enable PW1 and Misc I/O power wells
This one is a follow-up adding the other remaining
missing pieces.
v2: Rebased on top of Michel's patch as explained above.
Cc: Sarah Sharp <sarah.a.sharp@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452214179-22361-1-git-send-email-rodrigo.vivi@intel.com
The dsi_rr_formula() function has been unused for almost two years,
since
commit 44d4c6eebb
Author: Shobhit Kumar <shobhit.kumar@intel.com>
Date: Tue Dec 10 12:14:56 2013 +0530
drm/i915: Compute dsi_clk from pixel clock
citing the reason as pixel clock based calculation being recommended in
the MIPI host controller documentation. Remove the dead code, we can
always bring it back if it's needed.
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/1452249940-2605-2-git-send-email-jani.nikula@intel.com
Imre mentioned that chv might also have capability to
track unclaimed mmio accesses. Ville added that
both chv and vlv has this capability and he had already
made this way back [1]. Mimic what Ville's patch does
but adapt on top of less frequent mmio accesses by
omitting checking always on reg writes.
This patch is untested as of now.
v2: overflow handling and posting omitted (Ville)
References: [1] http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450201542-22918-1-git-send-email-mika.kuoppala@intel.com
Remove char* assignments and add branching hint and
also constify the parameters.
This results in a 35 bytes shorter fast path, so author
boldly assumes it helps without doing in-depth assembly
analysis.
v2: use WARN's branching (Chris), commit name (Joonas)
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450189512-30360-5-git-send-email-mika.kuoppala@intel.com
We have done unclaimed register access check in normal
(mmio_debug=0) mode once per write. This adds probability
of finding the exact sequence where we did the bad access, but
also adds burden to each write.
As we have mmio_debug available for more fine grained analysis,
give up accuracy of detecting correct spot at the first occurrence
by doing the one shot detection and arming of mmio_debug in hangcheck
and in modeset. This removes the write path performance burden.
v2: Remove gratuitous DRM_DEBUG and return value, comments (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450250808-14864-1-git-send-email-mika.kuoppala@intel.com
If something, the usual suspect being bios, access hw
behind our back, don't let it slide into situation where
normal register access will detect this and spit out
a warn on into dmesg. On some bdw bioses this happens
during igt/bat run always and as there is not much we can
do about it, its better just to detect and flush this
explicitly on resume and only print a debug message.
v2: use DRM_DEBUG_DRIVER (Chris)
v3: s/access/mmio, s/prior/prior to, s/dev/dev_priv
Testcase: igt/pm_rpm/basic-rte
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[Mika: fixed merge conflict]
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450189512-30360-3-git-send-email-mika.kuoppala@intel.com
Currently interrupt code is the only place checking
for the unclaimed register access prior to actual register
macros using the same functionality. Rename the function
and make it return bool so that the possible error message
context is clear in the caller side. The motivation is to allow
usage of unclaimed detection on arbitrary places.
v2: rebase, s/access/mmio, s/dev/dev_priv
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450189512-30360-2-git-send-email-mika.kuoppala@intel.com
Access the unclaimed reg detection register through
one helper which also does cleanup. Note that we now access
the register only if the platform has the actual non claimed
access bit. This prevents reading the register with gens that
doesn't have the register or the unclaimed bit,
when debug_mmio > 0.
Note that we post after clearing the bit. This makes sure
that the next unclaimed write access would get detected
also if it happened right after clearing, and not fold
into the previous detection.
v2: s/unclaimed_reg_access/check_for_unclaimed_mmio (Chris)
debug log on unclaimed detection on uncore init (Joonas)
v3: remove posting read (Ville)
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450200287-24080-1-git-send-email-mika.kuoppala@intel.com
If head seems stuck and engine in question is rcs,
inspect subunit state transitions from undone to done,
before deciding that this really is a hang instead of limited
progress. Only account the transitions of subunits from
undone to done once, to prevent unstable subunit states
to keep us falsely active.
As this adds one extra steps to hangcheck heuristics,
before hang is declared, it adds 1500ms to to detect hang
for render ring to a total of 7500ms. We could sample
the subunit states on first head stuck condition but
decide not to do so only in order to mimic old behaviour. This
way the check order of promotion from seqno > atchd > instdone
is consistently done.
v2: Deal with unstable done states (Arun)
Clear instdone progress on head and seqno movement (Chris)
Report raw and accumulated instdone's in in debugfs (Chris)
Return HANGCHECK_ACTIVE on undone->done
References: https://bugs.freedesktop.org/show_bug.cgi?id=93029
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448985372-19535-1-git-send-email-mika.kuoppala@intel.com
No functional changes.
That state the obvious and just duplicate the place we
need to change whenever the table is updated. So let's clean it.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452021535-22641-1-git-send-email-rodrigo.vivi@intel.com
When debuging an intermittent corrupted screen I suspected on DDI
translation table and checked we are out of date with the spec.
I'm not sure this will fix my bug yet, but it is always good to follow
the spec.
v2: Ville caught a switched i-boost value. Thanks!
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452021087-21673-1-git-send-email-rodrigo.vivi@intel.com
This fixes reprobing of display connectors on resume. After some
talking with danvet on IRC, I learned that calling
drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
connector's status. It turns out this is the actual reason reprobing on
resume hasn't been working (this was observed on a T440s):
- We call hpd_init()
- We check each connector for a couple of things before marking
connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
active encoder. Of course, a disconnected port won't have an
active encoder, so we don't add the flag to any of the
connectors.
- We call drm_helper_hpd_irq_event()
- drm_helper_irq_event() checks each connector for the
DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1,
so we skip reprobing each connector except that one.
In addition, we also now avoid setting connector->polled to
DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is
handled by the mst helpers. This is probably what was originally
intended to happen here.
Changes since V1:
* Use the explanation of the issue as the commit message instead
* Change the title of the commit, since this does more then just stop a
check for an encoder now
* Add "Fixes" line for the patch that introduced this regression
* Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors
Changes since V2:
* Put patch changelog above Signed-off-by
* Follow Daniel Vetter's suggestion for making the code here a bit more
legible
Fixes: 0e32b39cee ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: stable@vger.kernel.org
Signed-off-by: Lyude <cpaul@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452181408-14777-1-git-send-email-cpaul@redhat.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a useful thing to have around as a function because the mechanism may
change in the future.
There is a net increase in LOC here, and it will continue to be the case on GEN8
and GEN9 - but future GENs may have an alternate mechanism for doing this.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452018609-10142-4-git-send-email-benjamin.widawsky@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no point in emitting a WARN since the backtrace will always be the
same. Errors have actually become easier to spot given the large number of WARNs
which exist today in modesetting paths.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452018609-10142-3-git-send-email-benjamin.widawsky@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I think this patch is a worthwhile cleanup even if it might look only marginally
useful. It gets more useful in upcoming patches and for handling of future GEN
platforms.
The only non-mechanical part of this is the removal of the extra & operation on
the ring->next_context_status_buffer. This is safe because right above this, we
already did a modulus operation.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452018609-10142-2-git-send-email-benjamin.widawsky@intel.com
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My kbl stopped working because of this.
Fixes regression from
commit 2f693e28b8
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Wed Nov 4 19:24:12 2015 +0200
drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini
sequences
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452082116-16770-1-git-send-email-michel.thierry@intel.com
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
