summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm/stm: prepare for drmP.h removal from drm_modeset_helper.hSam Ravnborg2019-01-242-2/+13
| | | | | | | | | | | | | | | | | | | | | | | The use of drmP.h is discouraged and removal of it from drm_modeset_helper.h caused drm/stm to fail to build. This patch introduce the necessary fixes to prepare for the drmP.h removal from drm_modeset_helper.h. Build tested on arm and x86 allmodconfig v2: - sort list of include files Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190119084014.5355-2-sam@ravnborg.org
* Merge drm/drm-next into drm-misc-nextMaxime Ripard2019-01-24159-3550/+3169
|\ | | | | | | | | | | danvet needs a backmerge to ease the upcoming drmP.h rework Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
| * Merge tag 'drm-intel-next-2019-01-10' of ↵Dave Airlie2019-01-24112-3246/+2823
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-next - Unwind failure on pinning the gen7 PPGTT (Chris) - Fastset updates to make sure DRRS and PSR are properly enabled (Hans) - Header include clean-up (Brajeswar, Jani) - Improvements and clean-up on debugfs (Chris, Jani) - Avoid division by zero on CNL clocks setup (Xiao) - Restrict PSMI context load w/a to Haswell GT1 (Chris) - Remove HW semaphores for gen7 inter-engine sync (Chris) - Pull the render flush into breadcrumb emission (Chris) - i915_params copy and free helpers and other reorgs and docs (Jani) - Remove has_pooled_eu static initializer (Tvrtko) - Updates on kerneldoc (Chris) - Remove redundant trailing request flush (Chris) - ringbuffer irq seqno fixes and clean-up (Chris) - splitting off runtime device info and other clean-up around (Jani) - Selftests improvements (Chris, Daniele) - Flush RING_IMR changes before changing the global GT IMR on gen6 and HSW (Chris) - Some improvements and fixes around GPU reset and GPU hang report (Chris) - Remove partial attempt to swizzle on pread/pwrite (Chris) - Return immediately if trylock fails for direct-reclaim (Chris) - Downgrade scare message for unknown HuC firmware (Jani) - ACPI / PMIC for MIPI / DSI (Hans) - Reduce i915_request_alloc retirement to local context (Chris) - Init per-engine WAs for all engines (Daniele) - drop DPF code for gen8+ (Daniele) - Guard error capture against unpinned vma (Chris) - Use mutex_lock_killable from inside the shrinker (Chris) - Removing pooling from struct_mutex from vmap shrinker (Chris) Signed-off-by: Dave Airlie <airlied@redhat.com> # gpg: Signature made Fri 11 Jan 2019 09:58:18 AEST # gpg: using RSA key FA625F640EEB13CA # gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>" # gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA # Conflicts: # drivers/gpu/drm/i915/intel_dp.c # drivers/gpu/drm/i915/intel_drv.h From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114183820.GA2855@intel.com
| | * drm/i915: Update DRIVER_DATE to 20190110Rodrigo Vivi2019-01-111-2/+2
| | | | | | | | | | | | Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| | * drm/i915: Removing polling for struct_mutex from vmap shrinkerChris Wilson2019-01-101-31/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wait-for-idle used from within the shrinker_lock_uninterruptible depends on the struct_mutex locking state being known and declared to i915_request_wait(). As it is conceivable that we reach the vmap notifier from underneath struct_mutex (and so keep on relying on the mutex_trylock_recursive), we should not blindly call i915_request_wait. In the process we can remove the dubious polling to acquire struct_mutex, and simply act, or not, on a successful trylock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109164204.23935-2-chris@chris-wilson.co.uk
| | * drm/i915: Use mutex_lock_killable() from inside the shrinkerChris Wilson2019-01-101-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the current process is being killed (it was interrupted with SIGKILL or equivalent), it will not make any progress in page allocation and we can abort performing the shrinking on its behalf. So we can use mutex_lock_killable() instead (although this path should only be reachable from kswapd currently). Tvrtko pointed out that it should also be reachable from debugfs, which he would prefer retain its interruptiblity. As a compromise, killable is a step in the right direction! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109164204.23935-1-chris@chris-wilson.co.uk
| | * drm/i915: Guard error capture against unpinned vmaChris Wilson2019-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we find an incompletely setup vma inside the request/engine at the time of a hang, it may not have vma->pages initialised, so skip capturing the object before we iterate over NULL. Spotted by Matthew in preparation for using unpinned vma to track engine state. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110111522.11023-1-chris@chris-wilson.co.uk
| | * drm/i915: drop DPF code for gen8+Daniele Ceraolo Spurio2019-01-102-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only gen8+ platform that has the feature is BDW, but we don't define the feature flag on any BDW platform and we only have partial support in the gen8 path (irq enabling code, but no handler). The only thing we could do in the irq handler is report the error to userspace, but no one asked/cared about that since BDW was released so it is relatively safe to assume that even if we added the message no one would look at it. Just drop the dead code from the driver instead. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190109213147.16851-1-daniele.ceraolospurio@intel.com
| | * drm/i915: init per-engine WAs for all enginesDaniele Ceraolo Spurio2019-01-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds") refactored the workaround code to have functions per-engine, but didn't call any of them from logical_xcs_ring_init. Since we do have a non-RCS workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call intel_engine_init_workarounds for non-RCS engines. Note that whitelist is still RCS-only. v2: move the call to logical_ring_init (Chris) Fixes: 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110013232.8972-2-daniele.ceraolospurio@intel.com
| | * drm/i915/selftests: recreate WA lists inside the selftestDaniele Ceraolo Spurio2019-01-102-67/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By using the wa lists inside the live driver structures, we won't catch issues where those are incorrectly setup or corrupted. To cover this gap, update the workaround framework to allow saving the wa lists to independent structures and use them in the selftests. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110013232.8972-1-daniele.ceraolospurio@intel.com [tursulin: Fixup checkpatch whitespace complaint in memset.]
| | * drm/i915: Reduce i915_request_alloc retirement to local contextChris Wilson2019-01-091-22/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the continual quest to reduce the amount of global work required when submitting requests, replace i915_retire_requests() after allocation failure to retiring just our ring. v2: Don't forget the list iteration included an early break, so we would never throttle on the last request in the ring/timeline. v3: Use the common ring_retire_requests() References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request allocation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109215932.26454-1-chris@chris-wilson.co.uk
| | * drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequencesHans de Goede2019-01-091-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for PMIC MIPI sequences using the new intel_soc_pmic_exec_mipi_pmic_seq_element function. This fixes the DSI LCD panel not lighting up when not initialized by the GOP (because an external monitor was connected) on GPD win and GPD pocket devices. Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be driven high, which is done through a PMIC MIPI sequence. Before this commit if the sequence was not executed by the GOP the pin would stay low causing the LCD panel to not work. Having the MIPI sequences properly control this GPIO should also help save some power when the panel is off. Changes in v2, v3: -Only changes to other patches in this patch-set Changes in v4: -Move decoding of the raw 15 bytes PMIC MIPI sequence element into i2c-address, register-address, value and mask into the mipi_exec_pmic() function instead of passing the raw data to intel_soc_pmic_exec_mipi_pmic_seq_element() Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-5-hdegoede@redhat.com
| | * ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element handlingHans de Goede2019-01-093-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most PMIC-s use only a single i2c-address, so after verifying the i2c-address matches, we can simply pass the call to regmap_update_bits. This commit adds support for this and hooks this up for the xpower AXP288 PMIC by setting the new pmic_i2c_address field. This fixes the following errors on display on / off on a Jumper Ezpad mini 3 and an Onda V80 plus tablet, both of which use the AXP288: intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x34 reg-addr ... [drm:mipi_exec_pmic [i915]] *ERROR* mipi_exec_pmic failed, error: -95 Instead of these errors on both devices we now correctly turn on / off DLDO3 (through direct register manipulation). On the Onda V80 plus this fixes an issue with the backlight being brighter around the borders after an off / on cycle. This should also help to save some power when the display is off. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-4-hdegoede@redhat.com
| | * ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMICHans de Goede2019-01-091-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove PMIC. On some CHT devices this fixes the LCD panel not lighting up when it was not initialized by the GOP, because an external monitor was plugged in and the GOP initialized only the external monitor. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-3-hdegoede@redhat.com
| | * ACPI / PMIC: Add support for executing PMIC MIPI sequence elementsHans de Goede2019-01-093-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DSI LCD panels describe an initialization sequence in the Video BIOS Tables using so called MIPI sequences. One possible element in these sequences is a PMIC specific element of 15 bytes. Although this is not really an ACPI opregion, the ACPI opregion code is the closest thing we have. We need to have support for these PMIC specific MIPI sequence elements somwhere. Since we already instantiate a special platform device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to, with PMIC specific implementations of the OpRegion, the handling of MIPI sequence PMIC elements fits very well in the ACPI PMIC OpRegion code. This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element() function, which is to be backed by a PMIC specific exec_mipi_pmic_seq_element callback. This function will be called by the i915 code to execture MIPI sequence PMIC elements. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-2-hdegoede@redhat.com
| | * drm/i915: drop all drmP.h includesJani Nikula2019-01-0951-51/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Needs just a few additional includes here and there. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108082709.3748-1-jani.nikula@intel.com
| | * drm/i915: Downgrade scare message for unknown HuC firmwareChris Wilson2019-01-083-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we haven't shipped and enabled firmware for a particular platform, there is nothing the user can do about it. Don't scare the user with an unactionable, unidentifiable warning! <6> [310.769452] i915 0000:00:02.0: GuC: No firmware known for this platform! <4> [310.769458] [drm] HuC: No firmware known for this platform! Unify both GuC/HuC messages to include the device for which we lack the firmware, and provide the platform name as an aide-memoire. v2: Move and refine the message to common site of intel_uc_fw_fetch. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108150246.1471-1-chris@chris-wilson.co.uk
| | * Ndrm/i915/debugfs: store rotation string buffer on stackJani Nikula2019-01-081-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | Minimal change to nuke the static buf. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107145149.10069-1-jani.nikula@intel.com
| | * drm/i915: Return immediately if trylock fails for direct-reclaimChris Wilson2019-01-083-29/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ignore trying to shrink from i915 if we fail to acquire the struct_mutex in the shrinker while performing direct-reclaim. The trade-off being (much) lower latency for non-i915 clients at an increased risk of being unable to obtain a page from direct-reclaim without hitting the oom-notifier. The proviso being that we still keep trying to hard obtain the lock for kswapd so that we can reap under heavy memory pressure. v2: Taint all mutexes taken within the shrinker with the struct_mutex subclass as an early warning system, and drop I915_SHRINK_ACTIVE from vmap to reduce the number of dangerous paths. We also have to drop I915_SHRINK_ACTIVE from oom-notifier to be able to make the same claim that ACTIVE is only used from outside context, which fits in with a longer strategy of avoiding stalls due to scanning active during shrinking. The danger in using the subclass struct_mutex is that we declare ourselves more knowledgable than lockdep and deprive ourselves of automatic coverage. Instead, we require ourselves to mark up any mutex taken inside the shrinker in order to detect lock-inversion, and if we miss any we are doomed to a deadlock at the worst possible moment. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107115509.12523-1-chris@chris-wilson.co.uk
| | * Merge drm/drm-next into drm-intel-next-queuedJani Nikula2019-01-0811181-258932/+491876
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generally catch up with 5.0-rc1, and specifically get the changes: 96d4f267e40f ("Remove 'type' argument from access_ok() function") 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page fault exception case") 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'") Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * \ Merge tag 'topic/drmp-cleanup-2019-01-02' of ↵Jani Nikula2019-01-086-11/+24
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next-queued Make some drm headers self-contained with includes and forward declarations. This topic branch has already been merged to drm-misc-next as commit 1c95f662fcee ("Merge tag 'topic/drmp-cleanup-2019-01-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next"). Now merge it to drm-intel-next-queued to unblock some further drmP.h cleanup without having to wait for a backmerge. Signed-off-by: Jani Nikula <jani.nikula@intel.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87pntfl6pa.fsf@intel.com
| | * | | drm/i915/selftests: Mark the whole mock device as DMA capableChris Wilson2019-01-072-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Being a mock device, we suffer no DMA restrictions, so set the coherent mask to 64b. v2: Fix up mock_huge_selftests Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109243 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107181856.23789-1-chris@chris-wilson.co.uk
| | * | | drm/i915: Report the number of closed vma held by each context in debugfsChris Wilson2019-01-071-77/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Include the total size of closed vma when reporting the per_ctx_stats of debugfs/i915_gem_objects. Whilst adjusting the context tracking, note that we can simply use our list of contexts in i915->contexts rather than circumlocute via dev->filelist and the per-file context idr, with the result that we can show objects allocated to different vm (i.e. contexts within a file). We change the output to show every context of each client, with its own unique set of objects (for full-ppgtt machines, i.e. gen7+, for older hardware all objects are in the global gtt and so can not be associated with a single context). That should result in no loss of information, and for gen7+, no duplication of active objects. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107115509.12523-2-chris@chris-wilson.co.uk
| | * | | drm/i915/hsw: Flush RING_IMR changes before changing the global GT IMR (vecs)Chris Wilson2019-01-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Haswell also requires the RING_IMR flush for its unique vebox setup to avoid losing interrupts, as per 476af9c26063 ("drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR"): On Baytail, notably, we can still detect missed interrupt syndrome (where we never spot a completed request). In this case, it can be alleviated by always keeping the interrupt unmasked, implying that the interrupt is being lost in the window after modifying the IMR. (This is the reason we still have the posting reads on enable_irq, if we remove them we miss interrupts!) Having narrowed the issue down to the IMR, rather than keeping it always enabled, applying the usual posting read/flush of the RING_IMR before unmasking the GT IMR also seems to prevent the missed interrupt. So be it. References: 476af9c26063 ("drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190105115647.4970-1-chris@chris-wilson.co.uk
| | * | | drm/i915: Fixup kerneldoc for intel_device_info_runtime_initChris Wilson2019-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CC [M] drivers/gpu/drm/i915/intel_device_info.o drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or member 'dev_priv' not described in 'intel_device_info_runtime_init' drivers/gpu/drm/i915/intel_device_info.c:727: warning: Excess function parameter 'info' description in 'intel_device_info_runtime_init' Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190105014652.3472-1-chris@chris-wilson.co.uk
| | * | | drm/i915: Remove partial attempt to swizzle on pread/pwriteChris Wilson2019-01-051-164/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our attempt to account for bit17 swizzling of pread/pwrite onto tiled objects was flawed due to the simple fact that we do not always know the swizzling for a particular page (due to the swizzling varying based on location in certain unbalanced configurations). Furthermore, the pread/pwrite paths are now unbalanced in that we are required to use the GTT as in some cases we do not have direct CPU access to the backing physical pages (thus some paths trying to account for the swizzle, but others neglecting, chaos ensues). There are no known users who do use pread/pwrite into a tiled object (you need to manually detile anyway, so why now just use mmap and avoid the copy?) and no user bug reports to indicate that it is being used in the wild. As no one is hitting the buggy path, we can just remove the buggy code. v2: Just use the fault allowing kmap() + normal copy_(to|from)_user v3: Avoid int overflow in computing 'length' from 'remain' (Tvrtko) References: fe115628d567 ("drm/i915: Implement pwrite without struct-mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190105120758.9237-1-chris@chris-wilson.co.uk
| | * | | drm/i915: Do not allow unwedging following a failed driver initialisationChris Wilson2019-01-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we declare the driver wedged during early initialisation, we leave the driver in an undefined state (with respect to GEM execution). As this leads to unexpected behaviour if we allow the user to unwedge the device (through debugfs, and performed by igt at test start), do not. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103213340.1669-1-chris@chris-wilson.co.uk
| | * | | drm/i915: Always try to reset the GPU on takeoverChris Wilson2019-01-038-15/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we first introduced the reset to sanitize the GPU on taking over from the BIOS and before returning control to third parties (the BIOS!), we restricted it to only systems utilizing HW contexts as we were uncertain of how stable our reset mechanism truly was. We now have reasonable coverage across all machines that expose a GPU reset method, and so we should be safe to sanitize the GPU state everywhere. v2: We _have_ to skip the reset if it would clobber the display. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103112104.19561-1-chris@chris-wilson.co.uk
| | * | | drm/i915: Show machine type in error stateChris Wilson2019-01-031-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the question of 32b/64b kernels became relevant in the light of certain bugs, include that information in the error state. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103101245.15100-1-chris@chris-wilson.co.uk
| | * | | drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMRChris Wilson2019-01-031-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Baytail, notably, we can still detect missed interrupt syndrome (where we never spot a completed request). In this case, it can be alleviated by always keeping the interrupt unmasked, implying that the interrupt is being lost in the window after modifying the IMR. (This is the reason we still have the posting reads on enable_irq, if we remove them we miss interrupts!) Having narrowed the issue down to the IMR, rather than keeping it always enabled, applying the usual posting read/flush of the RING_IMR before unmasking the GT IMR also seems to prevent the missed interrupt. So be it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190102163524.19353-1-chris@chris-wilson.co.uk
| | * | | drm/i915/selftests: Take a breath during check_partial_mappings()Chris Wilson2019-01-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With kasan on a slow machine, it can take an age to check all the partial mappings in a single iteration, so break it up with a cond_resched) to avoid RCU stall reports. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190102114431.23022-1-chris@chris-wilson.co.uk
| | * | | drm/i915: rename dev_priv info to __info to avoid usageJani Nikula2019-01-021-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Encourage use of INTEL_INFO() to access dev_priv->info to not accumulate more direct users of ->info, making further changes easier. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5f5d81880046331f77624d00278528abc1cf30c6.1546267488.git.jani.nikula@intel.com
| | * | | drm/i915: drop intel_device_info_dump()Jani Nikula2019-01-023-18/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The debugfs, error state and regular dmesg logging dump needs seem to be different. Remove the generic dump function only used for the welcome message. This may be added back later when better abstractions are identified, but at the moment this seems to be the simplest considering the device info rework in progress. No longer rely on device info being a substruct of dev_priv. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/70ff0c7c0ec3ef8747af3c78e272b5a82be3d55b.1546267488.git.jani.nikula@intel.com
| | * | | drm/i915: always use INTEL_INFO() to access device infoJani Nikula2019-01-024-53/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hide the way device info is stored, in preparation of making device info a pointer to the const rodata in i915_pci.c. No functional changes. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3cd626f248c0d6638f1288938bbb577a12286050.1546267488.git.jani.nikula@intel.com
| | * | | drm/i915: pass dev_priv to intel_device_info_runtime_init()Jani Nikula2019-01-023-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the static/runtime device info split, this makes more sense. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ad5b448e4e318df0d292d73e6c3378f3e6b9bae5.1546267488.git.jani.nikula@intel.com
| | * | | drm/i915/reg: abstract display_mmio_offset accessJani Nikula2019-01-021-93/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a macro wrapper for display_mmio_offset access in register definitions. Prep work for reducing direct dev_priv->info usage. No functional changes. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/aa4e8fd85e0445ec5be6c55151239072b4315fda.1546267488.git.jani.nikula@intel.com
| | * | | drm/i915: start moving runtime device info to a separate structJani Nikula2019-01-0220-94/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First move the low hanging fruit, the fields that are only initialized runtime. Use RUNTIME_INFO() exclusively to access the fields. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c24fe7a4b0492a888690c46814c0ff21ce2f12b1.1546267488.git.jani.nikula@intel.com
| | * | | drm/i915: Drop unused engine->irq_seqno_barrier w/aChris Wilson2018-12-319-161/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have eliminated the CPU-side irq_seqno_barrier by moving the delays on the GPU before emitting the MI_USER_INTERRUPT, we can remove the engine->irq_seqno_barrier infrastructure. Though intentionally slowing down the GPU is nasty, so is the code we can now remove! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228171641.16531-6-chris@chris-wilson.co.uk
| | * | | drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5Chris Wilson2018-12-311-17/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The irq_seqno_barrier is a tradeoff between doing work on every request (on the GPU) and doing work after every interrupt (on the CPU). We presume we have many more requests than interrupts! However, for Ironlake, the workaround is a pretty hideous usleep() and so even though it was found we need to repeat the MI_STORE_DWORD_IMM 8 times, or about 1us of GPU time, doing so is preferrable than requiring a sleep of 125-250us on the CPU where we desire to respond immediately (ideally from within the interrupt handler)! The additional MI_STORE_DWORD_IMM also have the side-effect of flushing MI operations from userspace which are not caught by MI_FLUSH! Testcase: igt/gem_sync Testcase: igt/gem_exec_whisper Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228171641.16531-5-chris@chris-wilson.co.uk
| | * | | drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7Chris Wilson2018-12-311-36/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The irq_seqno_barrier is a tradeoff between doing work on every request (on the GPU) and doing work after every interrupt (on the CPU). We presume we have many more requests than interrupts! However, the current w/a for Ivybridge is an implicit delay that currently fails sporadically and consistently if we move the w/a into the irq handler itself. This makes the CPU barrier untenable for upcoming interrupt handler changes and so we need to replace it with a delay on the GPU before we send the MI_USER_INTERRUPT. As it turns out that delay is 32x MI_STORE_DWORD_IMM, or about 0.6us per request! Quite nasty, but the lesser of two evils looking to the future. Testcase: igt/gem_sync Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228171641.16531-4-chris@chris-wilson.co.uk
| | * | | drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcsChris Wilson2018-12-311-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MI_FLUSH_DW does appear coherent with the following MI_USER_INTERRUPT, but only on Sandybridge. Ivybridge requires a heavier hammer, but on Sandybridge we can stop requiring the irq_seqno barrier. Testcase: igt/gem_sync Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228171641.16531-3-chris@chris-wilson.co.uk
| | * | | drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcsChris Wilson2018-12-311-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having transitioned to using PIPECONTROL to combine the flush with the breadcrumb write using their post-sync functions, assume that this will resolve the serialisation with the subsequent MI_USER_INTERRUPT. That is when inspecting the breadcrumb after an interrupt we can rely on the write being posted (i.e. the HWSP will be coherent). Testing using gem_sync shows that the PIPECONTROL + CS stall does serialise the command streamer sufficient that the breadcrumb lands before the MI_USER_INTERRUPT. The same is not true for MI_FLUSH_DW. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228171641.16531-2-chris@chris-wilson.co.uk
| | * | | drm/i915: Remove redundant trailing request flushChris Wilson2018-12-314-35/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we perform the request flushing inline with emitting the breadcrumb, we can remove the now redundant manual flush. And we can also remove the infrastructure that remained only for its purpose. v2: emit_breadcrumb_sz is in dwords, but rq->reserved_space is in bytes Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228171641.16531-1-chris@chris-wilson.co.uk
| | * | | drm/i915: Update kerneldoc for intel_wm_need_update()Chris Wilson2018-12-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers/gpu/drm/i915/intel_display.c:10708: warning: Function parameter or member 'cur' not described in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Function parameter or member 'new' not described in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Excess function parameter 'plane' description in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Excess function parameter 'state' description in 'intel_wm_need_update' References: cd1d3ee90e5e ("drm/i915: Use intel_ types more consistently for watermark code (v2)") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181231143505.2523-1-chris@chris-wilson.co.uk
| | * | | drm/i915/params: document I915_PARAMS_FOR_EACH()Jani Nikula2018-12-311-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Macros with this much magic in them deserve some explanatory text. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6f012851a54433b23cb4752f9d4ef523165b1e58.1545920737.git.jani.nikula@intel.com
| | * | | drm/i915: Remove has_pooled_eu static initializerTvrtko Ursulin2018-12-311-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is only initialized to zero once so does not need an explicit initializer. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181231122212.1667-1-jani.nikula@intel.com
| | * | | drm/i915/params: set i915.enable_hangcheck permissions to 0600Jani Nikula2018-12-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915.enable_hangcheck has been an outlier since its introduction in commit 3e0dc6b01f53 ("drm/i915: hangcheck disable parameter") with 0644 permissions, while all the rest are either 0400 or 0600. Follow suit with 0600. IGT never reads the value, so there should be no impact. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5c8f7d1a1654436d38919b7419a209c129db8ad0.1545920737.git.jani.nikula@intel.com
| | * | | drm/i915/uc: add dev_priv parameter to intel_uc_is_using_* functionsJani Nikula2018-12-314-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reveals the build fail fixed in the last hunk. Also prep work. v2: name it i915 instead of dev_priv (Michal) Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8e02dcf1b85462d17e96fb183440dd90261b7411.1545920737.git.jani.nikula@intel.com
| | * | | drm/i915: add a helper to free the members of i915_paramsJani Nikula2018-12-313-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Abstract the one user in anticipation of more. Set the dangling pointers to NULL while at it. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8637d1e5049dc003718772f19d664aeaf9540856.1545920737.git.jani.nikula@intel.com
| | * | | drm/i915: add a helper to make a copy of i915_paramsJani Nikula2018-12-313-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Abstract the one user in anticipation of more. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c6a94b4da8dc723df025b1f602fe46d76d00d53f.1545920737.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 14:25:58 +0100