summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/gen8: Flip the 48b switchMichel Thierry2015-10-192-2/+7
| | | | | | | | | | | | | | | | Use 48b addresses if hw supports it (i915.enable_ppgtt=3). Update the sanitize_enable_ppgtt for 48 bit PPGTT mode. Note, aliasing PPGTT remains 32b only. v2: s/full_64b/full_48b/. (Akash) v3: Add sanitize_enable_ppgtt changes until here. (Akash) v4: Update param description (Chris) Cc: Akash Goel <akash.goel@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Only call commit_planes when there are things to commit.Maarten Lankhorst2015-10-191-1/+2
| | | | | | | | | | | The atomic helpers set planes_changed on a crtc_state if there is any plane_state bound to that crtc. If there's none and there is no pipe update required the crtc has nothing to update, so vblank evasion can be skipped. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Only run commit when crtc is active, v2.Maarten Lankhorst2015-10-192-13/+5Star
| | | | | | | | | | | | The crtc->active guards are no longer needed now that all state updates are outside the commit. Changes since v1: - Only check crtc->state->active before calling commit_planes_on_crtc. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Only commit active planes when updating planes during reset.Maarten Lankhorst2015-10-191-2/+1Star
| | | | | | | | | | In the next commit commit_plane will no longer check if the crtc is active. To prevent issues with legacy page flips the check should be performed inside update_primary_planes. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Update legacy primary state outside the commit hook, v2.Maarten Lankhorst2015-10-191-7/+12
| | | | | | | | | | | | | | | | | This should allow not running plane commit when the crtc is off. While the atomic helpers update those, crtc->x/y is only updated during modesets, and primary plane is updated after this function returns. Unfortunately non-atomic watermarks and fbc still depend on this state inside i915, so it has to be kept in sync. Changes since v1: - Add comment that the legacy state is updated for fbc. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make prepare_plane_fb fully interruptible.Maarten Lankhorst2015-10-191-6/+5Star
| | | | | | | | | | | | | | | | Now that we agreed on not preserving framebuffers pinning is finally allowed to fail because of signals. Use this to make pinning and acquire the mutex in an interruptible way too. Unpinning is still uninterruptible, because it happens as a cleanup of old state, or undoing pins after one of the pins failed. The intel_pin_and_fence_fb_obj in page_flip will also wait interruptibly, and can be aborted now. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make plane fb tracking work correctly, v2.Maarten Lankhorst2015-10-192-30/+18Star
| | | | | | | | | | | | | | | | | | | | atomic->disabled_planes is a hack that had to exist because prepare_fb was only called when a new fb was set. This messed up fb tracking in some circumstances like aborts from interruptible waits. As a result interruptible waiting in prepare_plane_fb was forbidden, but other errors could still cause frontbuffer tracking to be messed up. Now that prepare_fb is always called, this hack is no longer required and prepare_fb may fail without consequences. Changes since v1: - Clean up a few fb tracking warnings by changing plane->fb to plane->state->fb. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Making DC6 entry is the last call in suspend flow.Animesh Manna2015-10-193-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mmio register access after dc6/dc5 entry is not allowed when DC6 power states are enabled according to bspec (bspec-id 0527), so enabling dc6 as the last call in suspend flow. Addtional note from Imre: Currently we keep DC6 enabled during modesets and DPAUX transfers, which is not allowed according to the specification. This can lead at least to PLL locking failures, DPAUX timeouts and prevent deeper package power states (PC9/10). Fix this for now by enabling DC6 only when we know the above events (modeset, DPAUX) can't happen. This a temporary solution as some issues are still unsolved as described in [1] and [2], we'll address those as a follow-up. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077669.html [2] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077787.html v1: Initial version. v2: Based on review comment from Daniel, - created a seperate patch for csr uninitialization set call. v3: Rebased on top of latest code. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Kill the leftover RMW from ivb_sprite_disable()Ville Syrjälä2015-10-151-1/+1
| | | | | | | | | We still had one lingering RMW in ivb_sprite_disable(), all the other RMWs were killed off from the sprite code some time ago. Kill the straggler too. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: restore ggtt double-bind avoidanceDaniel Vetter2015-10-151-12/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was accidentally lost in commit 75d04a3773ecee617847de963ae4195d6aa74c28 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Tue Apr 28 17:56:17 2015 +0300 drm/i915/gtt: Allocate va range only if vma is not bound While at it implement an improved version suggested by Chris which avoids the double-bind irrespective of what type of bind is done first. Note that this exact bug was already addressed in commit d0e30adc42d979e4adc36b6c112b57337423b70c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jul 29 20:02:48 2015 +0100 drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt but the problem is still that originally in commit 0875546c5318c85c13d07014af5350e9000bc9e9 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Apr 20 09:04:05 2015 -0700 drm/i915: Fix up the vma aliasing ppgtt binding if forgotten to take into account there case where we have a GLOBAL_BIND before a LOCAL_BIND. This patch here fixes that. v2: Pimp commit message and revert the partial fix. v3: Split into two functions to specialize on aliasing_ppgtt y/n. v4: WARN_ON for paranoia in the init sequence, since the ggtt probe and aliasing ppgtt setup are far apart. v5: Style nits. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://mid.gmane.org/1444911781-32607-1-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Enable pipe gamma for sprite planes.Bob Paauwe2015-10-151-0/+1
| | | | | | | | | | | | | | Since SKL has universal planes, we should configure the sprite planes and the primary plane the same. For the primary plane we do enable the pipe gamma on the plane so do the same for the non-primary planes. Without this, the pipe CRC values will be different for something displayed on the primary plane and something displayed on a sprite plane when the ARGB8888 format is used. Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl+: Enable pipe CSC on cursor planes. (v2)Bob Paauwe2015-10-151-1/+1
| | | | | | | | | Extend this to SKL and BXT as it's needed for these platforms as well. v2: Change if condition to HAS_DDI() instead of listing each platform Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Move skl/bxt gt specific workarounds to ring initMika Kuoppala2015-10-132-61/+43Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some registers are, naturally, lost in gpu reset/suspend cycle. And some registers, for example in display domain, are not subject to gpu reset so they retain their contents. As hang recovery triggers a reset, recoverable gpu hang can currently flush out essential workarounds and cause havoc later on. When register GEN8_GARBNTL is missing the WaEnableGapsTsvCreditFix:skl, it can cause random system hangs [1]. This workaround was added in: commit 245d96670d26 ("drm/i915:skl: Add WaEnableGapsTsvCreditFix") But another set of system hangs were observed and the failure pattern indicated that there was random gpu hang preceding the system hang [2]. This lead to the realization that we lose this workaround and BDW_SCRATCH1 on reset. Add these workarounds setup in display init to skl/bxt ring init where LRI workarounds are also setup. This way their setup is not dependent on display side init. References: [1] https://bugs.freedesktop.org/show_bug.cgi?id=90854 References: [2] https://bugs.freedesktop.org/show_bug.cgi?id=92315 Reported-by: Tomi Sarvela <tomix.p.sarvela@intel.com> Cc: Tomi Sarvela <tomix.p.sarvela@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-levelChris Wilson2015-10-131-21/+78
| | | | | | | | | | | | | | | | Since the remove of the pin-ioctl, we only care about not changing the cache level on buffers pinned to the hardware as indicated by obj->pin_display. By knowing that only objects pinned to the hardware will have an elevated vma->pin_count, so we can coallesce many of the linear walks over the obj->vma_list. v2: Try and retrospectively add comments explaining the steps in rebinding the active VMA. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: revert a few more watermark commitsPaulo Zanoni2015-10-136-199/+293
| | | | | | | | | | | | | | | | | | | | | | | This is a squash of the following commits: Revert "drm/i915: Drop intel_update_sprite_watermarks" This reverts commit 47c99438b52d12df50e182583634a4cfede3c920. Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check" This reverts commit 7809e5ae35b9d8d0710f0874b2e3f10be144e38b. Revert "drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)" This reverts commit 3a05f5e2e78eab7ffe816abb59b6769e331a1957. With these reverts, SKL finally stops failing every single FBC test with FIFO underrun error messages. After some brief testing, it also seems that this commit prevents the machine from completely freezing when we run igt/kms_fbc_crc (see fd.o #92355). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92355 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKEVille Syrjälä2015-10-131-8/+8
| | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Clean up LVDS register handlingVille Syrjälä2015-10-131-16/+14Star
| | | | | | | | | | | | Keep single 'lvds_reg' and 'lvds' variable around in intel_lvds_init(), and read it just once at the start. Also intel_lvds_get_config() doesn't need to figure out which reg to use since it can just consult lvds_encoder->reg. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Throw out some useless variablesVille Syrjälä2015-10-133-60/+28Star
| | | | | | | | | | Drop some useless 'reg' variables when we only use them once. v2: A few more, including a few variable moves Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Parametrize and fix SWF registersVille Syrjälä2015-10-133-25/+50
| | | | | | | | | | | Parametrize the SWF registers. This also fixes the register offsets, which were mostly garbage in the old defines. Also save/restore only as many SWF registers that each platform has. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.Ville Syrjälä2015-10-133-11/+11
| | | | | | | | | | The PIPE_FRMCOUNT_GM45 and PIPE_FLIPCOUNT_GM45 names have bothered me for a long time. The work equally well for ELK and onwards, so let's s/GM45/G4X/. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a functionVille Syrjälä2015-10-131-14/+17
| | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix a few bad hex numbers in register definesVille Syrjälä2015-10-131-2/+2
| | | | | | | | | | A few register mask defines were missing the '0x' from hex numbers. Or at least I assume those were meant to be hex numbers. Put the '0x' in place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Protect register macro argumentsVille Syrjälä2015-10-131-46/+46
| | | | | | | | Always put parens around macro argument evaluations. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Include gpio_mmio_base in GMBUS reg definesVille Syrjälä2015-10-132-37/+29Star
| | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Parametrize HSW video DIP data registersVille Syrjälä2015-10-133-28/+32
| | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Eliminate weird parameter inversion from BXT PPS registersVille Syrjälä2015-10-131-4/+4
| | | | | | | | | v2: Keep using the same registers (PCH_*) instead of accidentally starting to use the other ones (BXT_*)2) (Jesse) Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Hold dev->event_lock whilst inspecting intel_crtc->unpin_workChris Wilson2015-10-131-25/+32
| | | | | | | | | | | | | | | | | We should serialise access to the intel_crtc->unpin_work through the dev->event_lock spinlock. It should not be possible for it to disappear without severe error as the mmio_flip worker has not tagged the unpin_work pending flip-completion. Similarly if the error exists, just taking the unpin_work whilst holding the spinlock and then using it unserialised just masks the race. (It is supposed to be valid as the unpin_work exists until the flip completion interrupt which should not fire until we flush the mmio writes to update the display base which is the last time we access the unpin_work from the kthread.) References: https://bugs.freedesktop.org/show_bug.cgi?id=92335 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* i915: switch from acpi_os_ioremap to memremapWilliams, Dan J2015-10-135-62/+62
| | | | | | | | | | | | | | i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly map it with memremap rather than the implied cache setting of acpi_os_ioremap(). Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Drop unnecessary #include <linux/vga_switcheroo.h>Lukas Wunner2015-10-131-1/+0Star
| | | | | | | | | | Commit 599bbb9de0fe ("drm/i915: i915 cannot provide switcher services.") removed all remaining vga_switcheroo symbols from intel_acpi.c but left the include. Drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Update DRIVER_DATE to 20151010Daniel Vetter2015-10-101-1/+1
| | | | Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Partial revert of atomic watermark seriesMatt Roper2015-10-094-202/+151Star
| | | | | | | | | | | | | | | | | | | It's been reported that the atomic watermark series triggers some regressions on SKL, which we haven't been able to track down yet. Let's temporarily revert these patches while we track down the root cause. This commit squashes the reverts of: 76305b1 drm/i915: Calculate watermark configuration during atomic check (v2) a4611e4 drm/i915: Don't set plane visible during HW readout if CRTC is off a28170f drm/i915: Calculate ILK-style watermarks during atomic check (v3) de4a9f8 drm/i915: Calculate pipe watermarks into CRTC state (v3) de165e0 drm/i915: Refactor ilk_update_wm (v3) Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-October/077190.html Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com> Cc: "Vetter, Daniel" <daniel.vetter@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Early exit from semaphore_waits_for for execlist mode.Tomas Elf2015-10-091-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When submitting semaphores in execlist mode the hang checker crashes in this function because it is only runnable in ring submission mode. The reason this is of particular interest to the TDR patch series is because we use semaphores as a mean to induce hangs during testing (which is the recommended way to induce hangs for gen8+). It's not clear how this is supposed to work in execlist mode since: 1. This function requires a ring buffer. 2. Retrieving a ring buffer in execlist mode requires us to retrieve the corresponding context, which we get from a request. 3. Retieving a request from the hang checker is not straight-forward since that requires us to grab the struct_mutex in order to synchronize against the request retirement thread. 4. Grabbing the struct_mutex from the hang checker is nothing that we will do since that puts us at risk of deadlock since a hung thread might be holding the struct_mutex already. Therefore it's not obvious how we're supposed to deal with this. For now, we're doing an early exit from this function, which avoids any kernel panic situation when running our own internal TDR ULT. * v2: (Chris Wilson) Turned the execlist mode check into a ringbuffer NULL check to make it more submission mode agnostic and less of a layering violation. Signed-off-by: Tomas Elf <tomas.elf@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove wrong warning from i915_gem_context_cleanTvrtko Ursulin2015-10-091-1/+1
| | | | | | | | | | | | | | | | | commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Mon Oct 5 13:26:36 2015 +0100 drm/i915: Clean up associated VMAs on context destruction Introduced a wrong assumption that all contexts have a ppgtt instance. This is not true when full PPGTT is not active so remove the WARN_ON_ONCE from the context cleanup code. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Determine the stolen memory base address on gen2Ville Syrjälä2015-10-091-11/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable [ 0.000000] BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data [ 0.000000] BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen memory would start there would place it on top of some ACPI memory regions. So not a good idea as already stated. The 9MB region after the ACPI regions at 0x1f700000 however looks promising given that the macine reports the stolen memory size to be 8MB. Looking at the PGTBL_CTL register, the GTT entries are at offset 0x1fee00000, and given that the GTT entries occupy 128KB, it looks like the stolen memory could start at 0x1f700000 and the GTT entries would occupy the last 128KB of the stolen memory. After some more digging through chipset documentation, I've determined the BIOS first allocates space for something called TSEG (something to do with SMM) from the top of memory, and then it allocates the graphics stolen memory below that. Accordind to the chipset documentation TSEG has a fixed size of 1MB on 855. So that explains the top 1MB in the e820 region. And it also confirms that the GTT entries are in fact at the end of the the stolen memory region. Derive the stolen memory base address on gen2 the same as the BIOS does (TOM-TSEG_SIZE-stolen_size). There are a few differences between the registers on various gen2 chipsets, so a few different codepaths are required. 865G is again bit more special since it seems to support enough memory to hit 4GB address space issues. This means the PCI allocations will also affect the location of the stolen memory. Fortunately there appears to be the TOUD register which may give us the correct answer directly. But the chipset docs are a bit unclear, so I'm not 100% sure that the graphics stolen memory is always the last thing the BIOS steals. Someone would need to verify it on a real system. I tested this on the my 830 and 855 machines, and so far everything looks peachy. v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods v3: Fix TSEG size for 830 v4: Add missing 'else' (Chris) Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix FBC buffer size checksPaulo Zanoni2015-10-091-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to my experiments (and later confirmation from the hardware developers), the maximum sizes mentioned in the specification delimit how far in the buffer the hardware tracking can go. And the hardware calculates the size based on the plane address we provide - and the provided plane address might not be the real x:0,y:0 point due to the compute_page_offset() function. On platforms that do the x/y offset adjustment trick it will be really hard to reproduce a bug, but on the current SKL we can reproduce the bug with igt/kms_frontbuffer_tracking/fbc-farfromfence. With this patch, we'll go from "CRC assertion failure" to "FBC unexpectedly disabled", which is still a failure on the test suite but is not a perceived user bug - you will just not save as much power as you could if FBC is disabled. v2, rewrite patch after clarification from the Hadware guys: - Rename function so it's clear what the check is for. - Use the new intel_fbc_get_plane_source_sizes() function in order to get the proper sizes as seen by FBC. v3: - Rebase after the s/sizes/size/ on the previous patch. - Adjust comment wording (Ville). - s/used_/effective_/ (Ville). Testcase: igt/kms_frontbuffer_tracking/fbc-farfromfence (SKL) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix CFB size calculationPaulo Zanoni2015-10-091-5/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were considering the whole framebuffer height, but the spec says we should only consider the active display height size. There were still some unclear questions based on the spec, but the hardware guys clarified them for us. According to them: - CFB size = CFB stride * Number of lines FBC writes to CFB - CFB stride = plane stride / compression limit - Number of lines FBC writes to CFB = MIN(plane source height, maximum number of lines FBC writes to CFB) - Plane source height = - pipe source height (PIPE_SRCSZ register) (before SKL) - plane size register height (PLANE_SIZE register) (SKL+) - Maximum number of lines FBC writes to CFB = - plane source height (before HSW) - 2048 (HSW+) For the plane source height, I could just have made our code do I915_READ() in order to be more future proof, but since it's not cool to do register reads I decided to just recalculate the values we use when we actually write to those registers. With this patch, depending on your machine configuration, a lot of the kms_frontbuffer_tracking subtests that used to result in a SKIP due to not enough stolen memory still start resulting in a PASS. v2: Use the clipped src size instead of pipe_src_h (Ville). v3: Use the appropriate information provided by the hardware guys. v4: Bikesheds: s/sizes/size/, s/fb_cpp/cpp/ (Ville). v5: - Don't use crtc->config->pipe_src_x for BDW- (Ville). - Fix the register name written in the comment. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove pre-atomic check from SKL update_primary_planePaulo Zanoni2015-10-091-21/+13Star
| | | | | | | | | | | | The comment suggests the check was there for some non-fully-atomic case, and I couldn't find a case where we wouldn't correctly initialize plane_state, so remove the check. Let's leave a WARN there just in case. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't allocate fbcon from stolen memory if it's too bigPaulo Zanoni2015-10-092-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Technology has evolved and now we have eDP panels with 3200x1800 resolution. In the meantime, the BIOS guys didn't change the default 32mb for stolen memory. On top of that, we can't assume our users will be able to increase the default stolen memory size to more than 32mb - I'm not even sure all BIOSes allow that. So just the fbcon buffer alone eats 22mb of my stolen memroy, and due to the BDW/SKL restriction of not using the last 8mb of stolen memory, all that's left for FBC is 2mb! Since fbcon is not the coolest feature ever, I think it's better to save our precious stolen resource to FBC and the other guys. On the other hand, we really want to use as much stolen memory as possible, since on some older systems the stolen memory may be a considerable percentage of the total available memory. This patch tries to achieve a little balance using a simple heuristic: if the fbcon wants more than half of the available stolen memory, don't use stolen memory in order to leave some for FBC and the other features. The long term plan should be to implement a way to set priorities for stolen memory allocation and then evict low priority users when the high priority ones need the memory. While we still don't have that, let's try to make FBC usable with the simple solution. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Revert "drm/i915: Call encoder hotplug for init and resume cases"Daniel Vetter2015-10-082-11/+1Star
| | | | | | | | | | | | | This reverts commit 5d250b05918c002b63632c7db91c3c5f924c6a3b. It results on a deadlock on platforms where we need to (at least partially) re-init hpd interrupts from power domain code, since ->hot_plug might again grab a power well reference (to do edid/dp_aux transactions. At least chv is affected. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> References: http://mid.gmane.org/20151008133548.GX26517@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* Revert "drm/i915: Add hot_plug hook for hdmi encoder"Daniel Vetter2015-10-081-43/+11Star
| | | | | | | | | This reverts commit 0b5e88dc25ee6c9040c0355e6e025dcbc9c8de92. It completely breaks booting on at least bsw (and maybe more). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88081 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/i915: use error pathSudip Mukherjee2015-10-081-9/+14
| | | | | | | | | | | | Use goto to handle the error path to avoid duplicating the same code. In the error path intel_dig_port is the last one to be released as it was the first one to be allocated and ideally the error path should be the reverse of the execution path. 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>
* drm/i915/irq: Fix misspelled word register in kernel-docJavier Martinez Canillas2015-10-081-1/+1
| | | | | | | | There is a typo in the function i915_handle_error() kernel-doc and the word register is spelled wrongly. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/irq: Fix kernel-doc warningsJavier Martinez Canillas2015-10-081-0/+2
| | | | | | | | | | | Add the dev parameter for the functions i915_enable_asle_pipestat() and i915_reset_and_wakeup() to the kernel-doc to fix the following warnings: .//drivers/gpu/drm/i915/i915_irq.c:586: warning: No description found for parameter 'dev' .//drivers/gpu/drm/i915/i915_irq.c:2400: warning: No description found for parameter 'dev' Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Hook up ring workaround writes at context creation time on Gen6-7.Francisco Jerez2015-10-071-1/+1
| | | | | | | | | | intel_rcs_ctx_init() emits all workaround register writes on the list to the ring, in addition to calling i915_gem_render_state_init(). The workaround list is currently empty on Gen6-7 so this shouldn't cause any functional changes. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't warn if the workaround list is empty.Francisco Jerez2015-10-071-1/+1
| | | | | | | | | | It's not an error for the workaround list to be empty if no workarounds are needed. This will avoid spamming the logs unnecessarily on Gen6 after the workaround list is hooked up on pre-Gen8 hardware by the following commits. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Resurrect golden context on gen6/7Daniel Vetter2015-10-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | In commit 8f0e2b9d95a88ca5d8349deef2375644faf184ae Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Dec 2 16:19:07 2014 +0100 drm/i915: Move golden context init into ->init_context I've shuffled around per-ctx init code a bit for legacy contexts but accidentally dropped the render state init call on gen6/7. Resurrect it. Reported-by: Francisco Jerez <currojerez@riseup.net> Cc: Francisco Jerez <currojerez@riseup.net> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Thomas Daniel <thomas.daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/chv: remove pre-production hardware workaroundsJani Nikula2015-10-071-34/+22Star
| | | | | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Appease gcc and remove the unused variable.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/snb: remove pre-production hardware workaroundJani Nikula2015-10-071-17/+1Star
| | | | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bxt: Set time interval unit to 0.833usAkash Goel2015-10-071-1/+4
| | | | | | | | | | | | Note that in Bspec you have to dig around in a section called "Timestamp bases" and Bspec update request is filed. Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com> Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Add note about state of Bspec.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Kill DRI1 cliprectsChris Wilson2015-10-072-138/+31Star
| | | | | | | | | | | | | | | | | | | Passing cliprects into the kernel for it to re-execute the batch buffer with different CMD_DRAWRECT died out long ago. As DRI1 support has been removed from the kernel, we can now simply reject any execbuf trying to use this "feature". To keep Daniel happy with the prospect of being able to reuse these fields in the next decade, continue to ensure that current userspace is not passing garbage in through the dead fields. v2: Fix the cliprects_ptr check Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-19 18:43:48 +0200