Age | Commit message (Collapse) | Author |
|
commit 10afa0b65fe2 ("drm/i915: Reject >9 ddi translation entried if port != A/E on SKL")
added sanity checks to make sure we don't end up with too many ddi translation
values for eDP ports, but it actually failed to check if the port is eDP.
We still look up the edp translations for non-eDP ports, but don't use
them, so we shouldn't be complaining about them either.
Fixes: 10afa0b65fe2 ("drm/i915: Reject >9 ddi translation entried if port != A/E on SKL")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452612496-9201-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
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 830 has VBT version 105 with child device size of 22 bytes.
Let's assume that's correct and adjust our expectations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450110229-30450-9-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
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>
|
|
Restore the lost phys status page cleanup.
Fixes the following splat with DMA_API_DEBUG=y:
WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974 dma_debug_device_change+0x190/0x1f0()
pci 0000:00:02.0: DMA-API: device driver has pending DMA allocations while released from device [count=1]
One of leaked entries details: [device address=0x0000000023163000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
Modules linked in: i915(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sha256_generic hmac drbg ctr ccm sch_fq_codel binfmt_misc joydev mousedev arc4 ath5k iTCO_wdt mac80211 smsc_ircc2 ath snd_intel8x0m snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm input_leds i2c_i801 pcspkr snd_timer cfg80211 snd soundcore i2c_core ehci_pci firewire_ohci ehci_hcd firewire_core lpc_ich 8139too rfkill crc_itu_t mfd_core mii usbcore rng_core intel_agp intel_gtt usb_common agpgart irda crc_ccitt fujitsu_laptop led_class parport_pc video parport evdev backlight
CPU: 0 PID: 21615 Comm: rmmod Tainted: G U 4.4.0-rc4-mgm-ovl+ #4
Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26 05/10/2004
e31a3de0 e31a3de0 e31a3d9c c128d4bd e31a3dd0 c1045a0c c15e00c4 e31a3dfc
0000546f c15dfad2 000003ce c12b3740 000003ce c12b3740 00000000 00000001
f61fb8a0 e31a3de8 c1045a83 00000009 e31a3de0 c15e00c4 e31a3dfc e31a3e4c
Call Trace:
[<c128d4bd>] dump_stack+0x16/0x19
[<c1045a0c>] warn_slowpath_common+0x8c/0xd0
[<c12b3740>] ? dma_debug_device_change+0x190/0x1f0
[<c12b3740>] ? dma_debug_device_change+0x190/0x1f0
[<c1045a83>] warn_slowpath_fmt+0x33/0x40
[<c12b3740>] dma_debug_device_change+0x190/0x1f0
[<c1065499>] notifier_call_chain+0x59/0x70
[<c10655af>] __blocking_notifier_call_chain+0x3f/0x80
[<c106560f>] blocking_notifier_call_chain+0x1f/0x30
[<c134cfb3>] __device_release_driver+0xc3/0xf0
[<c134d0d7>] driver_detach+0x97/0xa0
[<c134c440>] bus_remove_driver+0x40/0x90
[<c134db18>] driver_unregister+0x28/0x60
[<c1079e8c>] ? trace_hardirqs_on_caller+0x12c/0x1d0
[<c12c0618>] pci_unregister_driver+0x18/0x80
[<f83e96e7>] drm_pci_exit+0x87/0xb0 [drm]
[<f8b3be2d>] i915_exit+0x1b/0x1ee [i915]
[<c10b999c>] SyS_delete_module+0x14c/0x210
[<c1079e8c>] ? trace_hardirqs_on_caller+0x12c/0x1d0
[<c115a9bd>] ? ____fput+0xd/0x10
[<c1002014>] do_fast_syscall_32+0xa4/0x450
[<c149f6fa>] sysenter_past_esp+0x3b/0x5d
---[ end trace c2ecbc77760f10a0 ]---
Mapped at:
[<c12b3183>] debug_dma_alloc_coherent+0x33/0x90
[<f83e989c>] drm_pci_alloc+0x18c/0x1e0 [drm]
[<f8acd59f>] intel_init_ring_buffer+0x2af/0x490 [i915]
[<f8acd8b0>] intel_init_render_ring_buffer+0x130/0x750 [i915]
[<f8aaea4e>] i915_gem_init_rings+0x1e/0x110 [i915]
v2: s/BUG_ON/WARN_ON/ since dim doens't like the former anymore
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 5c6c600 ("drm/i915: Remove DRI1 ring accessors and API")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1452538112-5331-1-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>
|
|
Only DDI A and E support 10 translation entries in DP mode. For the
other ports the tenth entry is reserved for HDMI.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449597590-6971-9-git-send-email-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>
|
|
DDI A and E share some of the lanes, so check that we have enough
lanes for the purpose we need before registering the encoders.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449597590-6971-3-git-send-email-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>
|
|
Same effect for slightly less source code and resulting binary.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452521321-4032-2-git-send-email-tvrtko.ursulin@linux.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/1452006497-28517-1-git-send-email-jani.nikula@intel.com
|
|
Make it a bit tidier and safer.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/cab24a84811ddbae72d8c3a5f59d29f57b1d3aad.1450702954.git.jani.nikula@intel.com
|
|
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
|
|
New sequences, new operations within sequences.
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/96335b9fb875f79882d694360bff060251bd2f17.1450702954.git.jani.nikula@intel.com
|
|
Don't choke on unknown elements when we do know how to skip them.
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/1452518948-16469-1-git-send-email-jani.nikula@intel.com
|
|
Properly parse the new sequences added in MIPI sequence block v2.
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/cc1551bdfc4392d02413b78179f3a65c786c75ab.1450702954.git.jani.nikula@intel.com
|
|
Add parsing of the i2c element, defined in MIPI sequence block v2. Drop
the status operation byte while at it, that does not exist.
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/d8a2998977feee2f5b5ad609aaca787adfb41479.1450702954.git.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 8ac3e1bb76cc ("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: 3c28ff22f6e20c ("i915: wait for fence in prepare_plane_fb")
Link: http://patchwork.freedesktop.org/patch/msgid/5666EEC8.2000403@linux.intel.com
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
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 02235808b61cd9382d224b0df263193006dd9913
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 16fbc291cb87c7defcd13ad715d3e4af0d523e43
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 44d4c6eebb2ef04f698c292bb6eda5f2e80c663b
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
|
|
Hide away the platform differences in intel_dsi_get_pckl() within
intel_dsi_pll.c. No functional changes.
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-1-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 reviewing DDI translation table I noticed few changes we
haven't incorporated yet and it is always good to follow latest
spec.
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/1452009511-15064-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: 0e32b39ceed6 ("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 2f693e28b8df69f67beced5e18bb2b91c2bfcec2
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>
|
|
With sprites, cursors and primary planes taking the atomic state
this is now unused. It's removed in a separate commit to allow
a revert.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452164052-21752-8-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Pass in the atomic states to allow for proper updates.
This removes uses of intel_crtc->config and direct access
to plane->state.
This breaks the last bit of kgdboc, but that appears to be dead code.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452164052-21752-7-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Cursor planes grab the state from plane->state instead of the state
that was passed. The only updates are atomic now, so use the plane_state
that's passed in.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452164052-21752-6-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Update cursor_addr when disable_plane is called.
This is required to make commit_cursor_plane take a
crtc_state and a plane_state.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452164052-21752-5-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|