- 24 Oct, 2014 39 commits
-
-
Ville Syrjälä authored
I managed to fumble the per spline PCS DW11 register defines in: commit 570e2a74 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Aug 18 14:42:46 2014 +0300 drm/i915: Clear TX FIFO reset master override bits on chv Fortunately the bit in DW0 that was cleared due to this didn't have any effect as long as the bit we meant to clear was already zero. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> [danvet: Fix commit ref as pointed out by Jani.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
intel_crt_reset() resets the ADPA register on all gen5+ platforms. However the debug message claims it's touching the PCH ADPA register which is clearly not what it does on VLV. Drop the PCH part from the debug message. Signed-off-by:
-
Paulo Zanoni authored
For some yet-undiscovered reason, when IPS gets enabled, the pipe CRC changes. Since hsw_enable_ips() doesn't really guarantees to enable IPS (it depends on package C-states), we can't really predict if IPS is enabled or disabled while running our CRC tests, so let's just completely disable IPS while pipe CRCs are being used. If we find a way to make IPS not change the pipe CRC result, we may want to fix IPS and then revert this patch. While this doesn't happen, let's merge this patch, so every IGT test relying on the CRCs can work on pipe A. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72864 Testcase: igt/kms_cursor_crc (and others) Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
In its current place, it just segfaults while trying to access the CRTC structures: [ 9132.421681] Call Trace: [ 9132.421707] [<ffffffffa01130d8>] i915_get_crtc_scanoutpos+0x1e8/0x220 [i915] [ 9132.421727] [<ffffffffa001da34>] drm_calc_vbltimestamp_from_scanoutpos+0x94/0x330 [drm] [ 9132.421744] [<ffffffffa001d240>] ?vblank_disable_and_save+0x40/0x1e0 [drm] [ 9132.421769] [<ffffffffa0114328>] i915_get_vblank_timestamp+0x68/0xb0 [i915] [ 9132.421786] [<ffffffffa001d094>] drm_get_last_vbltimestamp+0x44/0x80 [drm] [ 9132.421801] [<ffffffffa001d3a6>] vblank_disable_and_save+0x1a6/0x1e0 [drm] [ 9132.421817] [<ffffffffa001eac1>] drm_vblank_cleanup+0x61/0xa0 [drm] [ 9132.421849] [<ffffffffa0177a5e>] i915_driver_unload+0xde/0x290 [i915] [ 9132.421867] [<ffffffffa0020264>] drm_dev_unregister+0x24/0xb0 [drm] [ 9132.421884] [<ffffffffa002090e>] drm_put_dev+0x1e/0x70 [drm] [ 9132.421901] [<ffffffffa00e01e0>] i915_pci_remove+0x10/0x20 [i915] [ 9132.421910] [<ffffffff81347556>] pci_device_remove+0x36/0xb0 [ 9132.421920] [<ffffffff8140084a>] __device_release_driver+0x7a/0xf0 [ 9132.421928] [<ffffffff81400fc8>] driver_detach+0xb8/0xc0 [ 9132.421936] [<ffffffff8140054a>] bus_remove_driver+0x4a/0xb0 [ 9132.421944] [<ffffffff81401717>] driver_unregister+0x27/0x50 [ 9132.421953] [<ffffffff81346f65>] pci_unregister_driver+0x25/0x70 [ 9132.421971] [<ffffffffa00229c8>] drm_pci_exit+0x78/0xa0 [drm] [ 9132.422000] [<ffffffffa017a6d2>] i915_exit+0x20/0x94e [i915] [ 9132.422009] [<ffffffff810fb9dc>] SyS_delete_module+0x13c/0x1f0 [ 9132.422019] [<ffffffff8131c5fb>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 9132.422028] [<ffffffff816f7792>] system_call_fastpath+0x16/0x1b This means it has to be before intel_modeset_cleanup, which cleans the CRTC structures. But if we move it to before intel_fbdev_fini(), we get WARNs because intel_fbdev_fini() still tries to use the vblanks, so the only acceptable point for drm_vblank_cleanup() seems to be this place. Related commit: commit cbb47d17 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Sep 23 17:33:20 2013 -0300 drm/i915: Add some missing steps to i915_driver_load error path Testsuite: igt/drv_module_reload Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83484Signed-off-by: -
Jani Nikula authored
SPT is always in the PCH override mode, and the bit MBZ. Only set override on LPT. v2: check for PCH version (Ville) Signed-off-by:
-
Jesse Barnes authored
Some machines (like MBAs) might use a tiled framebuffer but not enable display swizzling at boot time. We want to preserve that configuration if possible to prevent a boot time mode set. On IVB+ it shouldn't affect performance anyway since the memory controller does internal swizzling anyway. For most other configs we'll be able to enable swizzling at boot time, since the initial framebuffer won't be tiled, thus we won't see any corruption when we enable it. v2: preserve swizzling if BIOS had it set (Daniel) v3: preserve swizzling only if we inherited a tiled framebuffer (Daniel) check display swizzle setting in detect_bit_6_swizzle (Daniel) use gen6 as cutoff point (Daniel) v4: fixup swizzle preserve again, had wrong init order (Daniel) Reported-by:Kristian Høgsberg <hoegsberg@gmail.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Imre Deak authored
During S4 freeze we don't call intel_suspend_complete(), which would save the gunit HW state, but during S4 thaw/restore events we call intel_resume_prepare() which restores it, thus ending up in a corrupted HW state. Fix this by calling intel_suspend_complete() from the corresponding freeze_late event handler. The issue was introduced in commit 016970be Author: Sagar Kamble <sagar.a.kamble@intel.com> Date: Wed Aug 13 23:07:06 2014 +0530 CC: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Mika Kuoppala authored
As the workaround list has the value as initialization time constant, we can do the simple checking on the go without negleting igt. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
If we build the workaround list in ring initialization and decouple it from the actual writing of values, we gain the ability to decide where and how we want to apply the values. The advantage of this will become more clear when we need to initialize workarounds on older gens where it is not possible to write all the registers through ring LRIs. v2: rebase on newest bdw workarounds Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Jani Nikula authored
The whole file is only built with CONFIG_COMPAT=y. Signed-off-by:
-
Imre Deak authored
The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw events so we don't need to care about it either. Only S3 suspend and S4 freeze events are handled. Leave an assert behind to be sure. Signed-off-by:
-
Ander Conselvan de Oliveira authored
For consistency, since that's the rule followed for internal functions. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
-
Ander Conselvan de Oliveira authored
For consistency, since that's the rule followed for internal functions. Signed-off-by:
-
Ander Conselvan de Oliveira authored
For consistency, since that's the rule followed for internal functions. Signed-off-by:
-
Ander Conselvan de Oliveira authored
In the ironlake mode set code, there was two instances of a loop through encoders to find out if one of them has INTEL_OUTPUT_LVDS type. Simplify the code by deleting some lines and use intel_pipe_has_type() instead. Signed-off-by:
-
Daniel Vetter authored
Too many new drm driver writers seem to look at i915 for inspiration. But we have two ways to do mmap, so discourage readers from the old, ugly version. In a new driver we'd just expose two mmap offsets per object, one for the gtt map and the other for the cpu map. v2: Make it clear that i915 does cpu mmaps this way for past cluelessness^W^W historical reasons. Asked for by Jani. Cc: "Cheng, Yao" <yao.cheng@intel.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Rodrigo Vivi authored
Let's clean this a bit v2: Rebase after other Mika's patch that removed some BDW production workarounds. v3: Removed stepping info. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Chris Wilson authored
Just a couple more macros that assume that they were being passed a struct drm_device when they want a struct drm_i915_private. Use our magic macro to ease transitioning over to using drm_i915_privates Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Sonika Jindal authored
Add support for 180 degree rotation for primary and sprite planes Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Chris Wilson authored
If we are not able to free anything (the shrinker leaves nothing on the global object lists), do not log anything. This is useful when other subsystems are being stress-tested for their oom behaviour and i915.ko is shouting into the logs about doing nothing. Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Chris Wilson authored
The shrinker reports the number of pages freed, but we try to log the number of bytes - which leads to some nonsense values being reportedly freed during oom. Reported-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Rodrigo Vivi authored
Avoid to expose RC6 and RC6pp to the platforms that doesn't support it. So powertop can be changed to show RC6p and RC6pp only on the platforms they are available. v2: Simplify by merging RC6p and RC6pp groups and respect the spec that mentions deep and deepest RC6 on SNB and IVB although they keep disabled by default. v3: Remove unecessary space. v4: RC6p and RC6pp is only for SNB and IVB; unify debug msg and use has_rc6p() on sanitize options instead of is gen 6 and ivb. v5: yet another fix on has_rc6p macro. final is_gen6 or is_ivb! To make sure we are excluding hsw and baytrail. References: https://bugs.freedesktop.org/show_bug.cgi?id=84524 Cc: Josh Triplett <josh.triplett@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: -
Gustavo Padovan authored
Even if the fb is the same we should still check if the sizes are valid to be set. Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by:
-
Gustavo Padovan authored
Move check inside intel_crtc_cursor_set_obj() to intel_check_cursor_plane(), we only use it there so move them out to make the merge of intel_crtc_cursor_set_obj() into intel_check_cursor_plane() easier. This is another step toward the atomic modesetting support and unification of plane operations such pin/unpin of fb objects on i915. v2: take Ville's comment: move crtc_{w,h} assignment a bit down in the code v3: take Ville's comment: kept only the restructuring changes, the rest of the code was moved to a separated patch since it is a bug fix (we weren't checking sizes when the fb was the same) Signed-off-by: -
Gustavo Padovan authored
Now that universal planes are in place we don't need this plane unref on failures. Suggested-by:
-
Gustavo Padovan authored
Fold intel_pipe_set_base() in the update primary plane path merging pieces of code that are common to both paths. Basically the the pin/unpin procedures are the same for both paths and some checks can also be shared (some of the were moved to the check() stage) v2: take Ville's comments: - remove unnecessary plane check - move mutex lock to inside the conditional - make the pin fail message a debug one - add a fixme for the fastboot hack - call intel_frontbuffer_flip() after FBC update v3: take more Ville's comments: - fold update code under if (intel_crtc->active), and do the visible/!visible split inside. - check ret inside the same conditional we assign it v4: don't use intel_enable_primary_hw_plane(), the primary_enabled check inside will break page flips v5: take more Ville's comments: - set primary_enabled to true and add BDW hack - unify if (old_fb) and if (old_fb != fb) v6: take more Ville's comments: - make was_primary bool and fix its check - add the BDW vblank wait comment Suggested-by:
-
Damien Lespiau authored
As stated in the few previous commits, IS_ULT/ULX() is better per-platform as it has different consequences depending on the platform. We now can get rid of it. Signed-off-by:
-
Damien Lespiau authored
IS_ULT() wasn't taking into account SKL so we had a warn with SPT-LP. We don't realy need those checks here, and as we don't need to introduce IS_SKL_ULT/ULX() at the moment, let's just drop them. Signed-off-by:
-
Damien Lespiau authored
hsw_get_cdclk_freq() is really just HSW, so we can use IS_HSW_ULT() instead of IS_ULT() there. Signed-off-by:
-
Damien Lespiau authored
The quality of being a ULT or ULX package doesn't tell anything across generations and so a global IS_ULT() macro doesn't make much sense, esp. as we're adding new products. So, spell out which ULT/ULX SKUs we are talking about here, namely HSW and BDW. Signed-off-by:
-
Damien Lespiau authored
HAS_IPS() has a '|| IS_BROADWELL()', no need to check for IS_BDW_ULT(). Signed-off-by:
-
Damien Lespiau authored
No need to add the BDW pci ULT/ULX checks inside a if (IS_HASWELL(dev)) code path. Signed-off-by:
-
Daniel Vetter authored
v2: Fix spelling fail. Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
This simplifies the code in the vlv irq handler. Also this now means that we correctly filter underruns on gen2-4. And as the real upshot I need to document one less function for the fifo underrun code. v2: Shorten one long line. Reviewed-by:
-
Daniel Vetter authored
Way too much copypasta all over. And this also clarifies a bit what's going on since it separates the "do we have an underrun irq" from the "should we report the underrun" check. v2: Fix excessively long lines. Reviewed-by:
-
Daniel Vetter authored
It's the new rule! Reviewed-by:
-
Daniel Vetter authored
Prep work for some nice documentation. Requires that we export the display irq enable/disable functions on ilk/ibx. But we already export them for vlv/i915. So not more inconsistency. v2: Rebase on top of skl stage 1. Reviewed-by:
-
Daniel Vetter authored
This reverts commit 8c50f10d. It's not yet solid and Dave objected to pulling the tree in its current state. Cc: Michel Thierry <michel.thierry@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> References: http://mid.mail-archive.com/CAPM=9ty2r1MLE=wzC-_vNSUzXVqAyXiGgocpSV9qOp0gzpK3xA@mail.gmail.com References: http://lists.freedesktop.org/archives/intel-gfx/2014-October/053926.htmlAcked-by:
-
- 21 Oct, 2014 1 commit
-
-
Daniel Vetter authored
So I've sent the first pull request to Dave and I expect his request for a merge tree any second now ;-) More seriously I have some pending patches for 3.19 that depend upon both trees, hence backmerge. Conflicts are all trivial. Conflicts: drivers/gpu/drm/i915/i915_irq.c drivers/gpu/drm/i915/intel_display.c v2: Of course I've forgotten the fixup script for the silent conflict. Signed-off-by:
-
