- 12 Jan, 2016 12 commits
-
-
Ville Syrjälä authored
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.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
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:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
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: 5c6c6003 ("drm/i915: Remove DRI1 ring accessors and API") Signed-off-by: -
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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: -
Tvrtko Ursulin authored
Same effect for slightly less source code and resulting binary. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
- 11 Jan, 2016 11 commits
-
-
Jani Nikula authored
Reviewed-by:
-
Jani Nikula authored
Make it a bit tidier and safer. Reviewed-by:
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
Jani Nikula authored
New sequences, new operations within sequences. Reviewed-by:
-
Jani Nikula authored
Don't choke on unknown elements when we do know how to skip them. Reviewed-by:
-
Jani Nikula authored
Properly parse the new sequences added in MIPI sequence block v2. Reviewed-by:
-
Jani Nikula authored
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:
-
Mika Kuoppala authored
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
-
Mika Kuoppala authored
With commit 8ac3e1bb ("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:
-
Maarten Lankhorst authored
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:
-
- 10 Jan, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 08 Jan, 2016 11 commits
-
-
Boyer, Wayne authored
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 02235808 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
-
Rodrigo Vivi authored
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 16fbc291 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:
Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452214179-22361-1-git-send-email-rodrigo.vivi@intel.com
-
Jani Nikula authored
The dsi_rr_formula() function has been unused for almost two years, since commit 44d4c6ee 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:
-
Jani Nikula authored
Hide away the platform differences in intel_dsi_get_pckl() within intel_dsi_pll.c. No functional changes. Reviewed-by:
-
Mika Kuoppala authored
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:
-
Mika Kuoppala authored
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:
-
Mika Kuoppala authored
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:
-
Mika Kuoppala authored
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:
-
Mika Kuoppala authored
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:
-
Mika Kuoppala authored
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: -
Mika Kuoppala authored
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:
-
- 07 Jan, 2016 5 commits
-
-
Rodrigo Vivi authored
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 authored
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 authored
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:
-
Lyude authored
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: 0e32b39c ("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.comSigned-off-by:
-
Ben Widawsky authored
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:
-
