- 02 Mar, 2020 8 commits
-
-
Ville Syrjälä authored
Switch to the preferred 'crtc' name for our crtc variables. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-2-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Supposedly both src coordinates have to even when doing 90/270 degree rotation with RGB565. This is definitely true for the X coordinate (we just get a black screen when it is odd). My experiments didn't show any misbehaviour with an odd Y coordinate, but let's trust the spec and reject that one as well. v2: Ignore ccs hsub/vsub v3: Clarify the CCS special (Maarten) Deal with tgl+ CCS modifiers where we do need to look at hsub/vsub Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v2 Signed-off-by: -
Hans de Goede authored
Some devices with a builtin panel have the panel mounted upside down, this is indicated by the rotate_180 bit in the BDB_GENERAL_FEATURES VBT block. We store this info in dev_priv->vbt.orientation, use this to set the connector's orientation property so that fbcon and userspace will show the image the right way up on devices with an upside-down mounted panel. This fixes the image being upside-down on a Teclast X89 tablet. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Hans de Goede authored
Commit 82daca29 ("drm/i915: Add "panel orientation" property to the panel connector, v6.") uses hardware state readback to determine if the GOP is rotating the image by 180 degrees to compensate for upside-down mounted panels. When I wrote that commit I tried to find the VBT bits the GOP used to decide to rotate the image, but I could not find them. Back then I only looked at the rotation bits in struct mipi_config and these read 0 on the 1 BYT device I have with an upside-down mounted panel (a GP-electronic T701 tablet). While working on a similar problem on a BYT device with an eDP panel I noticed that the new intel_dsi_get_panel_orientation() helper which gets used on newer SoCs (Apollo-Lake, etc.) checks the rotate_180 bit in the BDB_GENERAL_FEATURES VBT block. I've checked and this bit indeed is set on the GP-electronic T701 tablet, so using the generic intel_dsi_get_panel_orientation() helper there does the right thing without needing any extra readback of hw state. This commit removes the special handling of the panel orientation for DSI panels on BYT/CHT devices, bringing the handling in line with the handling of DSI panels on other devices. Reviewed-by:
-
Jani Nikula authored
Unused since commit f97108d1 ("drm/i915: add dynamic performance control support for Ironlake"). That's a little over ten years. Good riddance. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
Keep reducing i915_drv.h. Reviewed-by:
-
Jani Nikula authored
Finish the job started in d28ae3b2 ("drm/i915: split out intel_dram.[ch] from i915_drv.c") by moving struct dram_dimm_info and dram_channel_info inside intel_dram.c, the only user of the structs. Reviewed-by:
-
Jani Nikula authored
Having an array pipe_crc[I915_MAX_PIPES] in struct drm_i915_private should be an obvious clue this should be located in struct intel_crtc instead. Make it so. As a side-effect, fix some errors in indexing pipe_crc with both pipe and crtc index. And, of course, reduce the size of i915_drv.h. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 28 Feb, 2020 25 commits
-
-
Chris Wilson authored
We monitor the health of the system via periodic heartbeat pulses. The pulses also provide the opportunity to perform garbage collection. However, we interpret an incomplete pulse (a missed heartbeat) as an indication that the system is no longer responsive, i.e. hung, and perform an engine or full GPU reset. Given that the preemption granularity can be very coarse on a system, we let the sysadmin override our legacy timeouts which were "optimised" for desktop applications. The heartbeat interval can be adjusted per-engine using, /sys/class/drm/card?/engine/*/heartbeat_interval_ms Signed-off-by:
Steve Carbonari <steven.carbonari@intel.com> Tested-by:
-
Chris Wilson authored
After initialising a preemption request, we give the current resident a small amount of time to vacate the GPU. The preemption request is for a higher priority context and should be immediate to maintain high quality of service (and avoid priority inversion). However, the preemption granularity of the GPU can be quite coarse and so we need a compromise. The preempt timeout can be adjusted per-engine using, /sys/class/drm/card?/engine/*/preempt_timeout_ms and can be disabled by setting it to 0. Signed-off-by:
-
Chris Wilson authored
When we allow ourselves to sleep before a GPU reset after disabling submission, even for a few milliseconds, gives an innocent context the opportunity to clear the GPU before the reset occurs. However, how long to sleep depends on the typical non-preemptible duration (a similar problem to determining the ideal preempt-reset timeout or even the heartbeat interval). As this seems of a hard policy decision, punt it to userspace. The timeout can be adjusted using /sys/class/drm/card?/engine/*/stop_timeout_ms Signed-off-by:
-
Chris Wilson authored
We busywait on an inflight request (one that is currently executing on HW, and so might complete quickly) prior to setting up an interrupt and sleeping. The trade off is that we keep an expensive CPU core busy in order to avoid wake up latency: where that trade off should lie is best left to the sysadmin. The busywait mechanism can be compiled out with ./scripts/config --set-val DRM_I915_SPIN_REQUEST 0 The maximum busywait duration can be adjusted per-engine using, /sys/class/drm/card?/engine/*/ms_busywait_duration_ns Signed-off-by:
-
Chris Wilson authored
Execlists uses a scheduling quantum (a timeslice) to alternate execution between ready-to-run contexts of equal priority. This ensures that all users (though only if they of equal importance) have the opportunity to run and prevents livelocks where contexts may have implicit ordering due to userspace semaphores. The timeslicing mechanism can be compiled out with ./scripts/config --set-val DRM_I915_TIMESLICE_DURATION 0 The timeslice duration can be adjusted per-engine using, /sys/class/drm/card?/engine/*/timeslice_duration_ms Signed-off-by:
-
Chris Wilson authored
Use the per-engine sysfs directory to let userspace discover the mmio_base of each engine. Prior to recent generations, the user accessible registers on each engine are at a fixed offset relative to each engine -- but require absolute addressing. As the absolute address depends on the actual physical engine, this is not always possible to determine from userspace (for example icl may expose vcs1 or vcs2 as the second vcs engine). Make this easy for userspace to discover by providing the mmio_base in sysfs. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Chris Wilson authored
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so that we can expose properties on each engine to the sysadmin. To start with we have basic analogues of the i915_query ioctl so that we can pretty print engine discovery from the shell, and flesh out the directory structure. Later we will add writeable sysadmin properties such as per-engine timeout controls. An example tree of the engine properties on Braswell: /sys/class/drm/card0 └── engine ├── bcs0 │ ├── capabilities │ ├── class │ ├── instance │ ├── known_capabilities │ └── name ├── rcs0 │ ├── capabilities │ ├── class │ ├── instance │ ├── known_capabilities │ └── name ├── vcs0 │ ├── capabilities │ ├── class │ ├── instance │ ├── known_capabilities │ └── name └── vecs0 ├── capabilities ├── class ├── instance ├── known_capabilities └── name v2: Include stringified capabilities v3: Include all known capabilities for futureproofing. v4: Combine the two caps loops into one v5: Hide underneath Kconfig.unstable for wider discussion Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Tested-by:
-
Dan Carpenter authored
The assert_mmap_offset() returns type bool so if we return an error pointer that is "return true;" or success. If we have an error, then we should return false. Fixes: 3d81d589 ("drm/i915: Test exhaustion of the mmap space") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Ville Syrjälä authored
WaDDIIOTimeout is only for A1 (pre-prod) glk steppings. Nuke it. Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
TGL+ supposedly do not need Wa_1405510057 so limit it to gen11 only. Signed-off-by:
-
Ville Syrjälä authored
w/a #1139 is only needed for pre-production GLK. Nuke it. Signed-off-by:
-
Chris Wilson authored
An odd and highly unlikely path caught us out. On delayed submission (due to an asynchronous reset handler), we poked the priority_hint and kicked the tasklet. However, we had already marked the device as wedged and swapped out the tasklet for a no-op. The result was that we never cleared the priority hint and became upset when we later checked. <0> [574.303565] i915_sel-6278 2.... 481822445us : __i915_subtests: Running intel_execlists_live_selftests/live_error_interrupt <0> [574.303565] i915_sel-6278 2.... 481822472us : __engine_unpark: 0000:00:02.0 rcs0: <0> [574.303565] i915_sel-6278 2.... 481822491us : __gt_unpark: 0000:00:02.0 <0> [574.303565] i915_sel-6278 2.... 481823220us : execlists_context_reset: 0000:00:02.0 rcs0: context:f4ee reset <0> [574.303565] i915_sel-6278 2.... 481824830us : __intel_context_active: 0000:00:02.0 rcs0: context:f51b active <0> [574.303565] i915_sel-6278 2.... 481825258us : __intel_context_do_pin: 0000:00:02.0 rcs0: context:f51b pin ring:{start:00006000, head:0000, tail:0000} <0> [574.303565] i915_sel-6278 2.... 481825311us : __i915_request_commit: 0000:00:02.0 rcs0: fence f51b:2, current 0 <0> [574.303565] i915_sel-6278 2d..1 481825347us : __i915_request_submit: 0000:00:02.0 rcs0: fence f51b:2, current 0 <0> [574.303565] i915_sel-6278 2d..1 481825363us : trace_ports: 0000:00:02.0 rcs0: submit { f51b:2, 0:0 } <0> [574.303565] i915_sel-6278 2.... 481826809us : __intel_context_active: 0000:00:02.0 rcs0: context:f51c active <0> [574.303565] <idle>-0 7d.h2 481827326us : cs_irq_handler: 0000:00:02.0 rcs0: CS error: 1 <0> [574.303565] <idle>-0 7..s1 481827377us : process_csb: 0000:00:02.0 rcs0: cs-irq head=3, tail=4 <0> [574.303565] <idle>-0 7..s1 481827379us : process_csb: 0000:00:02.0 rcs0: csb[4]: status=0x10000001:0x00000000 <0> [574.305593] <idle>-0 7..s1 481827385us : trace_ports: 0000:00:02.0 rcs0: promote { f51b:2*, 0:0 } <0> [574.305611] <idle>-0 7..s1 481828179us : execlists_reset: 0000:00:02.0 rcs0: reset for CS error <0> [574.305611] i915_sel-6278 2.... 481828284us : __intel_context_do_pin: 0000:00:02.0 rcs0: context:f51c pin ring:{start:00007000, head:0000, tail:0000} <0> [574.305611] i915_sel-6278 2.... 481828345us : __i915_request_commit: 0000:00:02.0 rcs0: fence f51c:2, current 0 <0> [574.305611] <idle>-0 7dNs2 481847823us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence f51b:2, current 1 <0> [574.305611] <idle>-0 7dNs2 481847857us : execlists_hold: 0000:00:02.0 rcs0: fence f51b:2, current 1 on hold <0> [574.305611] <idle>-0 7.Ns1 481847863us : intel_engine_reset: 0000:00:02.0 rcs0: flags=4 <0> [574.305611] <idle>-0 7.Ns1 481847945us : execlists_reset_prepare: 0000:00:02.0 rcs0: depth<-1 <0> [574.305611] <idle>-0 7.Ns1 481847946us : intel_engine_stop_cs: 0000:00:02.0 rcs0: <0> [574.305611] <idle>-0 7.Ns1 538584284us : intel_engine_stop_cs: 0000:00:02.0 rcs0: timed out on STOP_RING -> IDLE <0> [574.305611] <idle>-0 7.Ns1 538584347us : __intel_gt_reset: 0000:00:02.0 engine_mask=1 <0> [574.305611] <idle>-0 7.Ns1 538584406us : execlists_reset_rewind: 0000:00:02.0 rcs0: <0> [574.305611] <idle>-0 7dNs2 538585050us : __i915_request_reset: 0000:00:02.0 rcs0: fence f51b:2, current 1 guilty? yes <0> [574.305611] <idle>-0 7dNs2 538585063us : __execlists_reset: 0000:00:02.0 rcs0: replay {head:0000, tail:0068} <0> [574.306565] <idle>-0 7.Ns1 538588457us : intel_engine_cancel_stop_cs: 0000:00:02.0 rcs0: <0> [574.306565] <idle>-0 7dNs2 538588462us : __i915_request_submit: 0000:00:02.0 rcs0: fence f51c:2, current 0 <0> [574.306565] <idle>-0 7dNs2 538588471us : trace_ports: 0000:00:02.0 rcs0: submit { f51c:2, 0:0 } <0> [574.306565] <idle>-0 7.Ns1 538588474us : execlists_reset_finish: 0000:00:02.0 rcs0: depth->1 <0> [574.306565] kworker/-202 2.... 538588755us : i915_request_retire: 0000:00:02.0 rcs0: fence f51c:2, current 2 <0> [574.306565] ksoftirq-46 7..s. 538588773us : process_csb: 0000:00:02.0 rcs0: cs-irq head=11, tail=1 <0> [574.306565] ksoftirq-46 7..s. 538588774us : process_csb: 0000:00:02.0 rcs0: csb[0]: status=0x10000001:0x00000000 <0> [574.306565] ksoftirq-46 7..s. 538588776us : trace_ports: 0000:00:02.0 rcs0: promote { f51c:2!, 0:0 } <0> [574.306565] ksoftirq-46 7..s. 538588778us : process_csb: 0000:00:02.0 rcs0: csb[1]: status=0x10000018:0x00000020 <0> [574.306565] ksoftirq-46 7..s. 538588779us : trace_ports: 0000:00:02.0 rcs0: completed { f51c:2!, 0:0 } <0> [574.306565] kworker/-202 2.... 538588826us : intel_context_unpin: 0000:00:02.0 rcs0: context:f51c unpin <0> [574.306565] i915_sel-6278 6.... 538589663us : __intel_gt_set_wedged.part.32: 0000:00:02.0 start <0> [574.306565] i915_sel-6278 6.... 538589667us : execlists_reset_prepare: 0000:00:02.0 rcs0: depth<-0 <0> [574.306565] i915_sel-6278 6.... 538589710us : intel_engine_stop_cs: 0000:00:02.0 rcs0: <0> [574.306565] i915_sel-6278 6.... 538589732us : execlists_reset_prepare: 0000:00:02.0 bcs0: depth<-0 <0> [574.307591] i915_sel-6278 6.... 538589733us : intel_engine_stop_cs: 0000:00:02.0 bcs0: <0> [574.307591] i915_sel-6278 6.... 538589757us : execlists_reset_prepare: 0000:00:02.0 vcs0: depth<-0 <0> [574.307591] i915_sel-6278 6.... 538589758us : intel_engine_stop_cs: 0000:00:02.0 vcs0: <0> [574.307591] i915_sel-6278 6.... 538589771us : execlists_reset_prepare: 0000:00:02.0 vcs1: depth<-0 <0> [574.307591] i915_sel-6278 6.... 538589772us : intel_engine_stop_cs: 0000:00:02.0 vcs1: <0> [574.307591] i915_sel-6278 6.... 538589778us : execlists_reset_prepare: 0000:00:02.0 vecs0: depth<-0 <0> [574.307591] i915_sel-6278 6.... 538589780us : intel_engine_stop_cs: 0000:00:02.0 vecs0: <0> [574.307591] i915_sel-6278 6.... 538589786us : __intel_gt_reset: 0000:00:02.0 engine_mask=ff <0> [574.307591] i915_sel-6278 6.... 538591175us : execlists_reset_cancel: 0000:00:02.0 rcs0: <0> [574.307591] i915_sel-6278 6.... 538591970us : execlists_reset_cancel: 0000:00:02.0 bcs0: <0> [574.307591] i915_sel-6278 6.... 538591982us : execlists_reset_cancel: 0000:00:02.0 vcs0: <0> [574.307591] i915_sel-6278 6.... 538591996us : execlists_reset_cancel: 0000:00:02.0 vcs1: <0> [574.307591] i915_sel-6278 6.... 538592759us : execlists_reset_cancel: 0000:00:02.0 vecs0: <0> [574.307591] i915_sel-6278 6.... 538592977us : execlists_reset_finish: 0000:00:02.0 rcs0: depth->0 <0> [574.307591] i915_sel-6278 6.N.. 538592996us : execlists_reset_finish: 0000:00:02.0 bcs0: depth->0 <0> [574.307591] i915_sel-6278 6.N.. 538593023us : execlists_reset_finish: 0000:00:02.0 vcs0: depth->0 <0> [574.307591] i915_sel-6278 6.N.. 538593037us : execlists_reset_finish: 0000:00:02.0 vcs1: depth->0 <0> [574.307591] i915_sel-6278 6.N.. 538593051us : execlists_reset_finish: 0000:00:02.0 vecs0: depth->0 <0> [574.307591] i915_sel-6278 6.... 538593407us : __intel_gt_set_wedged.part.32: 0000:00:02.0 end <0> [574.307591] kworker/-210 7d..1 551958381us : execlists_unhold: 0000:00:02.0 rcs0: fence f51b:2, current 2 hold release <0> [574.307591] i915_sel-6278 0.... 559490788us : i915_request_retire: 0000:00:02.0 rcs0: fence f51b:2, current 2 <0> [574.307591] i915_sel-6278 0.... 559490793us : intel_context_unpin: 0000:00:02.0 rcs0: context:f51b unpin <0> [574.307591] i915_sel-6278 0.... 559490798us : __engine_park: 0000:00:02.0 rcs0: parked <0> [574.307591] i915_sel-6278 0.... 559490982us : __intel_context_retire: 0000:00:02.0 rcs0: context:f51c retire runtime: { total:30004ns, avg:30004ns } <0> [574.307591] i915_sel-6278 0.... 559491372us : __engine_park: __engine_park:261 GEM_BUG_ON(engine->execlists.queue_priority_hint != (-((int)(~0U >> 1)) - 1)) Signed-off-by: -
Chris Wilson authored
Give the reset worker a kick before losing help when waiting for hang recovery, as the CPU scheduler is a little unreliable. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-15-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
Detect GLK pre-production steppings. Not 100% of A2 being pre-prod since the spec is a bit of a mess but feels more or less correct. Suggested-by:
-
Chris Wilson authored
As we require a context switch to ensure that the current context is switched out and saved to memory, perform an explicit switch to the kernel context and wait for it. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1336Signed-off-by:
-
Chris Wilson authored
The engine->kernel_context is a special case for request emission. Since it is used as the barrier within the engine's wakeref, we must acquire the wakeref before submitting a request to the kernel_context. Reported-by:
-
Chris Wilson authored
Inside the general i915_oa_init_reg_state() we avoid using the perf->mutex. However, we rely on perf->exclusive_stream being valid to access at that point, and for that we have to control the race with disabling perf. This relies on the disabling being a heavy barrier that inspects all active contexts, after marking the perf->exclusive_stream as not available. This should ensure that there are no more concurrent accesses to the perf->exclusive_stream as we destroy it. Mark up the races around the perf->exclusive_stream so that they stand out much more. (And hopefully we will be running kcsan to start validating that the only races we have are carefully controlled.) Signed-off-by:
-
Anshuman Gupta authored
As a disabled pipe in pipe_mask is not having a valid intel crtc, driver wrongly populates the possible_crtcs mask while initializing the plane for a CRTC. Fixing up the plane possible_crtcs mask. changes since RFC: - Simplify the possible_crtcs initialization. [Ville] v2: - Removed the unnecessary stack garbage possible_crtcs to drm_universal_plane_init. [Ville] v3: - Combine the intel_crtc assignment and declaration. [Ville] v4: - Fix possible_crtcs abused bits from intel_{primary,curosr,sprite}_plane_create(). [Ville] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Chris Wilson authored
We need to be extremely careful inside i915_request_await_start() as it needs to walk the list of requests in the foreign timeline with very little protection. As we hold our own timeline mutex, we can not nest inside the signaler's timeline mutex, so all that remains is our RCU protection. However, to be safe we need to tell the compiler that we may be traversing the list only under RCU protection, and furthermore we need to start declaring requests as elements of the timeline from their construction. Fixes: 9ddc8ec0 ("drm/i915: Eliminate the trylock for awaiting an earlier request") Fixes: 6a79d848 ("drm/i915: Lock signaler timeline while navigating") Signed-off-by:
-
Chris Wilson authored
Check that we can recover if the LRC is totally corrupted. Based on a very simple theory that anything that can be adjusted via the context (i.e. on behalf of the user), should be under the purview of the per-engine-reset. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-13-chris@chris-wilson.co.uk
-
Chris Wilson authored
Record the LRC registers before/after a preemption event to ensure that the first context sees nothing from the second client; at least in the normal per-context register state. References: https://gitlab.freedesktop.org/drm/intel/issues/1233Signed-off-by:
-
Chris Wilson authored
Pull the final atomic_dec of vm->open (marking the vm as closed) underneath the same vm->mutex as used to close it. This is required to correctly serialise with attempting to reuse the vma as the vm is closed by a second thread. References: 00de702c ("drm/i915: Check that the vma hasn't been closed before we insert it") Signed-off-by:
-
Chris Wilson authored
As we drop the engine-pm on retiring, that may happen while there are still CS events in the buffer. As such we cannot assert the engine is still active on reset, until we know that the current request is still in flight. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1338Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227204727.2009346-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Still chasing the mystery of the stray idle flush, let's ensure that the heartbeat does not run at the same time as our test and confuse us. References: https://gitlab.freedesktop.org/drm/intel/issues/541Signed-off-by:
-
Chris Wilson authored
Attaching to the i915_active barrier is a two stage process, and a flush is only effective when the barrier is activation. Thus it is possible for us to see a barrier, and attempt to flush, only for our flush to have no effect. As such, before attempting to activate signaling on the fence we need to double check it is a fence! Fixes: d13a3177 ("drm/i915: Flush idle barriers when waiting") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1333Signed-off-by:
-
- 27 Feb, 2020 7 commits
-
-
Daniele Ceraolo Spurio authored
On TGL, bits 2-4 in the GGTT PTE are not ignored anymore and are instead used for some extra VT-d capabilities. We don't (yet?) have support for those capabilities, but, given that we shared the pte_encode function betweed GGTT and PPGTT, we still set those bits to the PPGTT PPAT values. The DMA engine gets very confused when those bits are set while the iommu is enabled, leading to errors. E.g. when loading the GuC we get: [ 9.796218] DMAR: DRHD: handling fault status reg 2 [ 9.796235] DMAR: [DMA Write] Request device [00:02.0] PASID ffffffff fault addr 0 [fault reason 02] Present bit in context entry is clear [ 9.899215] [drm:intel_guc_fw_upload [i915]] *ERROR* GuC firmware signature verification failed To fix this, just have dedicated gen8_pte_encode function per type of gtt. Also, explicitly set vm->pte_encode for gen8_ppgtt, even if we don't use it, to make sure we don't accidentally assign it to the GGTT one, like we do for gen6_ppgtt, in case we need it in the future. Reported-by:
"Sodhi, Vunny" <vunny.sodhi@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Wa_1608008084 is an additional WA that applies to writes on FF_MODE2 register. We can't read it back either from CPU or GPU. Since the other bits should be 0, recommendation to handle Wa_1604555607 is to actually just write the timer value. Do a write only and don't try to read it, neither before or after the WA is applied. Fixes: ff690b21 ("drm/i915/tgl: Implement Wa_1604555607") Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200224191258.15668-1-lucas.demarchi@intel.com
-
Ville Syrjälä authored
Looks like the pipe rounding mode bit has moved from PIPE_CHICKEN to PIPE_MISC on tgl. Frob the new location. Bspec does still document the old bits as well, so I left the code for them as is until we get clarification from the hw folks on whether the old bits still do something useful. Signed-off-by:
-
Lucas De Marchi authored
This register was placed in the middle of the PP_STATUS definition instead of together with the PP_CONTROL where it should. Since it's not used and there are no current plans to use it, just remove the definition. v2: remove the define rather than moving it. Signed-off-by:
-
Jani Nikula authored
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace the sole remaining I915_WRITE() in i915_drv.c with intel_uncore_write(), although it might be better to keep the entire file void of direct register access. No functional changes. Reviewed-by:
-
Jani Nikula authored
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding uncore register accessors intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read(), intel_uncore_read_fw(), and intel_uncore_write_fw(). Rename dev_priv to i915 while at it. No functional changes. Reviewed-by:
-
Jani Nikula authored
The DRAM related routines are pretty isolated from the rest of the i915_drv.c, split it out to a separate file. Put the eDRAM stuff in the same bag, and rename the visible functions to have intel_dram_ prefix. Do some benign whitespace fixes and dev_priv -> i915 conversions while at it. Reviewed-by:
-
