aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2016-04-12drm/i915: Reject panel_type > 0xf from VBTVille Syrjälä1-1/+4
VBT can only contain 16 panel entries, indexed with the panel_type. To play it safe we should reject panel_type > 0xf, so that we don't read past the valid data. v2: Add debug logging (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rob Kramer <rob@solution-space.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460359329-10817-1-git-send-email-ville.syrjala@linux.intel.com
2016-04-12drm/i915: Make GMBUS timeout message DRM_DEBUG_KMSVille Syrjälä1-2/+2
There's no real reason the user should care that we're about to fall back to bitbanging, so let's change the message from DRM_INFO to DRM_DEBUG_KMS. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-5-git-send-email-ville.syrjala@linux.intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94890 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Restore GMBUS operation after a failed bit-banging fallbackVille Syrjälä2-3/+8
When the GMBUS based i2c transfer times out, we try to fall back to bit-banging and retry the operation that way. However if the bit-banging attempt also fails, we should probably go back to the GMBUS method for the next attempt. Maybe there simply wasn't anyone one the bus at this time. There's also a bit of a mess going on with the force_bit handling. It's supposed to be a ref count actually, and it is as far as intel_gmbus_force_bit() is concerned. But it's treated as just a flag by the timeout based bit-banging fallback. I suppose that's fine since we should never end up in the timeout fallback case if force_bit was already non-zero. However now that we want to restore things back to where they were after the bit-banging attempt failed, we're going to have to do things a bit differently to avoid clobbering the force_bit count as set up by intel_gmbus_force_bit(). So let's dedicate the high bit as a flag for the low level timeout based fallback and treat the rest of the bits as a ref count just as before. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Protect force_bit with gmbus_mutexVille Syrjälä1-0/+5
Extend the protection of gmbus_mutex around the force_bit RMW in intel_gmbus_force_bit(), in case someone gets the idea of calling it from a separate thread while there's other stuff happening on the same bus. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-11drm/i915/userptr: Store i915 backpointer for i915_mm_structChris Wilson1-5/+5
Since we only ever use the drm_i915_private from the stored i915_mm_struct->dev, save some electrons by storing the right backpointer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459864801-28606-3-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915/userptr: Hold mmref whilst calling get-user-pagesChris Wilson1-11/+16
Holding a reference to the containing task_struct is not sufficient to prevent the mm_struct from being reaped under memory pressure. If this happens whilst we are calling get_user_pages(), explosions erupt - sometimes an immediate GPF, sometimes page flag corruption. To prevent the target mm from being reaped as we are reading from it, acquire a reference before we begin. Testcase: igt/gem_shrink/*userptr Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459864801-28606-2-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returnsChris Wilson1-1/+47
In order to ensure that all invalidations are completed before the operation returns to userspace (i.e. before the munmap() syscall returns) we need to wait upon the outstanding operations. We are allowed to block inside the invalidate_range_start callback, and as struct_mutex is the inner lock with mmap_sem we can wait upon the struct_mutex without provoking lockdep into warning about a deadlock. However, we don't actually want to wait upon outstanding rendering whilst holding the struct_mutex if we can help it otherwise we also block other processes from submitting work to the GPU. So first we do a wait without the lock and then when we reacquire the lock, we double check that everything is ready for removing the invalidated pages. Finally to wait upon the outstanding unpinning tasks, we create a private workqueue as a means to conveniently wait upon all at once. The drawback is that this workqueue is per-mm, so any threads concurrently invalidating objects will wait upon each other. The advantage of using the workqueue is that we can wait in parallel for completion of rendering and unpinning of several objects (of particular importance if the process terminates with a whole mm full of objects). v2: Apply a cup of tea to the changelog. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94699 Testcase: igt/gem_userptr_blits/sync-unmap-cycles Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459864801-28606-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-04-11drm/i915: Update DRIVER_DATE to 20160411Daniel Vetter1-1/+1
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-04-11Merge tag 'v4.6-rc3' into drm-intel-next-queuedDaniel Vetter183-3812/+6433
Linux 4.6-rc3 Backmerge requested by Chris Wilson to make his patches apply cleanly. Tiny conflict in vmalloc.c with the (properly acked and all) patch in drm-intel-next: commit 4da56b99d99e5a7df2b7f11e87bfea935f909732 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 4 14:46:42 2016 +0100 mm/vmap: Add a notifier for when we run out of vmap address space and Linus' tree. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-04-11drm/i915: Avoid allocating a vmap arena for a single pageChris Wilson1-5/+14
If we want a contiguous mapping of a single page sized object, we can forgo using vmap() and just use a regular kmap(). Note that this is only suitable if the desired pgprot_t is compatible. v2: Use is_vmalloc_addr() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-7-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
2016-04-11drm,i915: Introduce drm_malloc_gfp()Chris Wilson4-21/+12
I have instances where I want to use drm_malloc_ab() but with a custom gfp mask. And with those, where I want a temporary allocation, I want to try a high-order kmalloc() before using a vmalloc(). So refactor my usage into drm_malloc_gfp(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-6-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915/shrinker: Restrict vmap purge to objects with vmapsChris Wilson2-1/+10
When called because we have run out of vmap address space, we only need to recover objects that have vmappings and not all. v2: Start using is_vmalloc_addr() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-5-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
2016-04-11drm/i915: Refactor duplicate object vmap functionsChris Wilson4-72/+84
We now have two implementations for vmapping a whole object, one for dma-buf and one for the ringbuffer. If we couple the mapping into the obj->pages lifetime, then we can reuse an obj->mapping for both and at the same time couple it into the shrinker. There is a third vmapping routine in the cmdparser that maps only a range within the object, for the time being that is left alone, but will eventually use these routines in order to cache the mapping between invocations. v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala) v3: Call unpin_vmap from the right dmabuf unmapper v4: Rename vmap to map as we don't wish to imply the type of mapping involved, just that it contiguously maps the object into kernel space. Add kerneldoc and lockdep annotations Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-4-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
2016-04-11drm/i915: Consolidate common error handling in intel_pin_and_map_ringbuffer_objChris Wilson1-13/+12
After we pin the ringbuffer into the GGTT, all error paths need to unpin it again. Move this common step into one block, and make the unable to iomap error code consistent (i.e. treat it as out of memory to avoid confusing it with a invalid argument). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-3-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_bufChris Wilson1-3/+1
We only need the struct_mutex to manipulate the pages_pin_count on the object, we do not need to hold our BKL when freeing the exported scatterlist. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-2-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915: implement WaClearTdlStateAckDirtyBitsTim Gore2-0/+31
This is to fix a GPU hang seen with mid thread pre-emption and pooled EUs. v2. Use IS_BXT_REVID instead of IS_BROXTON and INTEL_REVID v3. And use correct type for register addresses Signed-off-by: Tim Gore <tim.gore@intel.com> Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458571049-854-1-git-send-email-tim.gore@intel.com
2016-04-11drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bitDongwon Kim1-1/+9
For BXT, description of polarities of PORT_PLL_REF_SEL has been reversed for newer Gen9LP steppings according to the recent update in Bspec. This bit now should be set for "Non-SSC" mode for all Gen9LP starting from B0 stepping. v2: Only B0 and newer stepping should be affected by this change. Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94866 Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458176773-26925-1-git-send-email-dongwon.kim@intel.com
2016-04-11drm/i915: Rename hw state checker to hw state verifier.Maarten Lankhorst1-30/+30
Check functions are used by atomic to see if the new state will be allowed. There's also a hw state checker which checks afterwards that the committed state is correct. Rename it to hw state verifier to reduce some confusion. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56FB8785.8020506@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2016-04-11drm/i915: Move modeset state verifier calls.Maarten Lankhorst1-19/+5
The modeset state verifier no longer has full access to the hardware, instead it should only verify affected crtc's. Looking for disabled stuff can be verified immediately after all crtc disables have completed, while each enabled crtc can be verified right after being enabled. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458741487-23801-3-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [mlankhorst: check -> verify]
2016-04-11drm/i915: Make modeset state verifier take crtc as argument.Maarten Lankhorst1-133/+183
This will make it easier to keep the crtc checker when atomic commit is reworked for asynchronous commits. This prevents checking crtc's that were not part of the state. It's safe to verify disabled encoders, connectors and dpll's that are not part of the state, because during modeset connection_mutex is held. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458741487-23801-2-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [mlankhorst: Extend commit message and rename check to verify.]
2016-04-11Merge tag 'drm-intel-fixes-2016-04-07' of git://anongit.freedesktop.org/drm-intel into drm-fixesDave Airlie4-12/+7
misc i915 fixes. * tag 'drm-intel-fixes-2016-04-07' of git://anongit.freedesktop.org/drm-intel: drm/i915: fix deadlock on lid open drm/i915: Exit cherryview_irq_handler() after one pass drm/i915: Call intel_dp_mst_resume() before resuming displays drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
2016-04-11Merge tag 'topic/drm-fixes-2016-04-07' of git://anongit.freedesktop.org/drm-intel into drm-fixesDave Airlie3-9/+16
The qxl fix I've picked up quite some time ago, and unfortunately neglected. Then there's established timing fixes, of which particularly "drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor" is quite surprising. It looks like we've never got any of them right. I am not sure what the full implications of this are. That combined with lack of any details of real world bugs fixed made me decide against cc: stable. * tag 'topic/drm-fixes-2016-04-07' of git://anongit.freedesktop.org/drm-intel: drm/edid: Fix DMT 1024x768@43Hz (interlaced) timings drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor drm/edid: Fix EDID Established Timings I and II drm/qxl: fix cursor position with non-zero hotspot
2016-04-09drm/i915: Replace manual barrier() with READ_ONCE() in HWS accessorChris Wilson1-4/+2
When reading from the HWS page, we use barrier() to prevent the compiler optimising away the read from the volatile (may be updated by the GPU) memory address. This is more suited to READ_ONCE(); make it so. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460195877-20520-5-git-send-email-chris@chris-wilson.co.uk
2016-04-09drm/i915: Use simplest form for flushing the single cacheline in the HWSChris Wilson1-2/+3
Rather than call a function to compute the matching cachelines and clflush them, just call the clflush *instruction* directly. We also know that we can use the unpatched plain clflush rather than the clflushopt alternative. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460195877-20520-4-git-send-email-chris@chris-wilson.co.uk
2016-04-09drm/i915: Harden detection of missed interruptsChris Wilson3-16/+35
Only declare a missed interrupt if we find that the GPU is idle with waiters and a hangcheck interval has passed in which no new user interrupts have been raised. v2: Clear the stuck interrupt marker between successful batches Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460195877-20520-3-git-send-email-chris@chris-wilson.co.uk
2016-04-09drm/i915: Separate out the seqno-barrier from engine->get_seqnoChris Wilson8-42/+51
In order to simplify future patches, extract the lazy_coherency optimisation our of the engine->get_seqno() vfunc into its own callback. v2: Rename the barrier to engine->irq_seqno_barrier to try and better reflect that the barrier is only required after the user interrupt before reading the seqno (to ensure that the seqno update lands in time as we do not have strict seqno-irq ordering on all platforms). Reviewed-by: Dave Gordon <david.s.gordon@intel.com> [#v2] v3: Comments for hangcheck paranoia. Mika wanted to keep the extra barrier inside the hangcheck, just in case. I can argue that it doesn't provide a barrier against anything, but the side-effects of applying the barrier may prevent a false declaration of a hung GPU. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460195877-20520-2-git-send-email-chris@chris-wilson.co.uk
2016-04-09drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+Chris Wilson1-2/+11
In order to ensure seqno/irq coherency, we currently read a ring register. The mmio transaction following the interrupt delays the inspection of the seqno long enough for the MI_STORE_DWORD_IMM to update the CPU cache. However, it is only the memory timing that is important for the purposes of the delay, we do not need nor desire the extra forcewake. v3: Update commentary Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [v2] Link: http://patchwork.freedesktop.org/patch/msgid/1460195877-20520-1-git-send-email-chris@chris-wilson.co.uk
2016-04-09drm/i915: Fixup the free space logic in ring_prepareAkash Goel2-6/+6
Currently for the case where there is enough space at the end of Ring buffer for accommodating only the base request, the wrapround is done immediately and as a result the base request gets added at the start of Ring buffer. But there may not be enough free space at the beginning to accommodate the base request, as before the wraparound, the wait was effectively done for the reserved_size free space from the start of Ring buffer. In such a case there is a potential of Ring buffer overflow, the instructions at the head of Ring (ACTHD) can get overwritten. Since the base request can fit in the remaining space, there is no need to wraparound immediately. The wraparound will anyway happen later when the reserved part starts getting used. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1457688402-10411-1-git-send-email-akash.goel@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org
2016-04-08drm/gma500/mdfld_dsi: remove bogus if checkAlan1-5/+1
Both cases produce the same result. Kill the junk code. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2016-04-08drm/gma500: Fix possible out of bounds readItai Handler1-1/+1
Fix possible out of bounds read, by adding missing comma. The code may read pass the end of the dsi_errors array when the most significant bit (bit #31) in the intr_stat register is set. This bug has been detected using CppCheck (static analysis tool). Cc: stable@vger.kernel.org Signed-off-by: Itai Handler <itai_handler@hotmail.com> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2016-04-08drm/gma500: fix double freeingSudip Mukherjee1-9/+4
We are allocating backing using psbfb_alloc() and so backing->stolen is always true. So we were freeing backing two times. Moreover if we follow the execution path then we should be freeing backing after we have released the helper. So remove the one which frees backing before the helper is released. While at it the error labels are also renamed to give a meaningful name. [Patrik: Fixed conflict with removal of struct_mutex] Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2016-04-08drm/i915: Simplify check for idleness in hangcheckChris Wilson1-3/+2
Having fixed the tracking of the engine's last_submitted_seqno, we can now rely on it for detecting when the engine is idle (and not have to touch the requests pointer). Testcase: igt/gem_exec_whisper Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-9-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2016-04-08drm/i915: Apply a mb between emitting the request and hangcheckChris Wilson2-18/+24
Seal the request and mark it as pending execution before we submit it to hardware. We assume that the actual submission cannot fail (that guarantee is provided by preallocating space in the request for the submission). As we may inspect this state without holding any locks during hangcheck we should apply a barrier to ensure that we do not see a more recent value in the HWS than we are tracking. Based on a patch by Mika Kuoppala. Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-8-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2016-04-08drm/i915: Reset engine->last_submitted_seqnoChris Wilson1-0/+1
When we change the current seqno, we also need to remember to reset the last_submitted_seqno for the engine. Testcase: igt/gem_exec_whisper Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-7-git-send-email-chris@chris-wilson.co.uk
2016-04-08drm/i915: Reset semaphore page for gen8Chris Wilson1-0/+8
An oversight is that when we wrap the seqno, we need to reset the hw semaphore counters to 0. We did this for gen6 and gen7 and forgot to do so for the new implementation required for gen8 (legacy). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-6-git-send-email-chris@chris-wilson.co.uk
2016-04-08drm/i915: Refactor gen8 semaphore offset calculationChris Wilson1-6/+5
We reuse the same calculation into two macros, and I want to add a third user. Time to refactor. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-5-git-send-email-chris@chris-wilson.co.uk
2016-04-08drm/i915: Move the hw semaphore initialisation from GEM to the engineChris Wilson2-6/+13
Since we are setting engine local values that are tied to the hardware, move it out of i915_gem_init_seqno() into the intel_ring_init_seqno() backend, next to where the other hw semaphore registers are written. v2: Make the explanatory comment about always resetting the semaphores to 0 irrespective of the value of the reset seqno. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-4-git-send-email-chris@chris-wilson.co.uk
2016-04-08drm/i915: Remove unneeded drm_device pointer from intel_ring_init_seqno()Chris Wilson1-4/+3
We only use drm_i915_private within the function, so delete the unneeded drm_device local. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-3-git-send-email-chris@chris-wilson.co.uk
2016-04-08drm/i915: On GPU reset, set the HWS breadcrumb to the last seqnoChris Wilson1-0/+2
After the GPU reset and we discard all of the incomplete requests, mark the GPU as having advanced to the last_submitted_seqno (as having completed the requests and ready for fresh work). The impact of this is negligible, as all the requests will be considered completed by this point, it just brings the HWS into line with expectations for external viewers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-2-git-send-email-chris@chris-wilson.co.uk
2016-04-08drm/i915: Include engine->last_submitted_seqno in GPU error stateChris Wilson3-2/+7
It's useful to look at the last seqno submitted on a particular engine and compare it against the HWS value to check for irregularities. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-1-git-send-email-chris@chris-wilson.co.uk
2016-04-07drm/amd/amdgpu: fix irq domain remove for tonga ihJunwei Zhang1-1/+1
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-07drm/i915/BXT: Get pipe conf from the port registersRamalingam C1-0/+60
At BXT DSI, PIPE registers are inactive. So we can't get the PIPE's mode parameters from them. The possible option is retriving them from the PORT registers. The required changes are added for BXT in intel_dsi_get_config (encoder->get_config). v2: Addressed the Jani's comments -removed the redundant call to encoder->get_config -read bpp from port register -removed retrival of src_size from encoder->get_config v3: pipe_config->pipe_bpp is fixed Jani's review comments addressed: Few horizontal timing parameters dropped from the patch to make progress, as there seems to be some disagreement on best/feasible/possible options. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Previously Reviewed at: https://lists.freedesktop.org/archives/intel-gfx/2016-April/091737.html Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460019967-26501-2-git-send-email-ramalingam.c@intel.com
2016-04-07drm/i915: Sharing the pixel_format_from_vbt to whole i915Ramalingam C3-20/+22
Shared the function pixel_format_from_vbt for whole display module. Function declaration is added to intel_dsi.h. V2: Moved the function to intel_dsi.c and renamed as per the purpose of the function. Suggested by Jani. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Previously reviewed at https://lists.freedesktop.org/archives/intel-gfx/2016-April/091736.html Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460019967-26501-1-git-send-email-ramalingam.c@intel.com
2016-04-07drm/i915/dsi: use a temp variable for referencing the gpio tableJani Nikula1-6/+9
The shorthand is easier. Also change the struct name. 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/6572c108424a67b02367ea69cbbe00a03af9b958.1459884518.git.jani.nikula@intel.com
2016-04-07drm/i915/dsi: abstract VLV gpio element execution to a separate functionJani Nikula1-32/+35
Prepare for future. No functional changes. v2: Move earlier in the series. Use bool for gpio value. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [Jani: restored fixme comment while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/ee791fed271d7f31c34163de6c6be37d1b704ef3.1459884518.git.jani.nikula@intel.com
2016-04-07drm/i915/dsi: clean up vlv gpio table and definitionsJani Nikula1-48/+39
Define and store the pad base offset in the array, and reference the pconf0 and padval registers through macros. Add VLV prefixes to macros. Use spec nomenclature for pconf0 and padval. v2: Address Ville's review comments, squash another patch here. v3: Use the names Ville dug up in the specs. 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/34932140b78a3de7f825c78380a08c930694651b.1459884518.git.jani.nikula@intel.com
2016-04-07drm/i915: Do not use {HAS_*, IS_*, INTEL_INFO}(dev_priv->dev)Joonas Lahtinen15-55/+56
dev_priv is what the macro works hard to extract, pass it directly. > sed 's/\([A-Z].*(dev_priv\)->dev)/\1)/g' v2: - Include all wrapper macros too (Chris) v3: - Include sed cmdline (Chris) v4: - Break long line - Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460016485-8089-1-git-send-email-joonas.lahtinen@linux.intel.com
2016-04-07drm/i915: Do not WARN_ON in i915_vm_to_ppgttJoonas Lahtinen1-1/+0
According to Chris, use of i915_vm_to_ppgtt is visible in benchmark unless WARN_ON is removed, so lets get rid of it. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2016-04-07drm/i915: Use i915_vm_to_ppgtt instead of manual container_ofJoonas Lahtinen1-28/+16
Looks much better without container_of everywhere. v2: - In i915_gem_restore_gtt_mappings too (Chris) v3: - Do not cause WARN by calling on non PPGTT object (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-07drm/i915: fix deadlock on lid openBjørn Mork1-4/+1
commit e2c8b8701e2d moved modeset locking inside resume/suspend functions, but missed a code path only executed on lid close/open on older hardware. The result was a deadlock when closing and opening the lid without suspending on such hardware: ============================================= [ INFO: possible recursive locking detected ] 4.6.0-rc1 #385 Not tainted --------------------------------------------- kworker/0:3/88 is trying to acquire lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] but task is already holding lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dev->mode_config.mutex); lock(&dev->mode_config.mutex); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by kworker/0:3/88: #0: ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #1: ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65 #3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915] #4: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] #5: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm] #6: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm] stack backtrace: CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 Workqueue: kacpi_notify acpi_os_execute_deferred 0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0 ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70 000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0 Call Trace: [<ffffffff8124af06>] dump_stack+0x67/0x90 [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71 [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4 [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm] [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm] [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915] [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65 [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16 [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button] [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button] [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64 [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20 [<ffffffff81068f17>] process_one_work+0x265/0x50b [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff8106e2d6>] kthread+0xe0/0xe8 [<ffffffff8107bc47>] ? local_clock+0x19/0x22 [<ffffffff81484f42>] ret_from_fork+0x22/0x40 [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5 Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no (cherry picked from commit 9f54d4bd5808b5c892a44c539c126b71d299f341) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.