- 19 Mar, 2019 15 commits
-
-
Ville Syrjälä authored
The readout code thinks that kdiv of 3 is 4. Fix it. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190207173230.22368-11-ville.syrjala@linux.intel.comReviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Ville Syrjälä authored
Just store the stuff directly into crtc_state->dpll_hw_state rather than to a temp and copying the whole thing over. Signed-off-by:
-
Ville Syrjälä authored
Simplify the calling convention of the dpll funcs by plumbing the crtc state deeper. Signed-off-by:
-
Ville Syrjälä authored
Just store the stuff directly into crtc_state->dpll_hw_state rather than to a temp and copying the whole thing over. Signed-off-by:
-
Ville Syrjälä authored
Simplify the calling convention of the dpll funcs by plumbing the crtc state deeper. Signed-off-by:
-
Ville Syrjälä authored
Just store the stuff directly into crtc_state->dpll_hw_state rather than to a temp and copying the whole thing over. Signed-off-by:
-
Ville Syrjälä authored
Simplify the calling convention of the dpll funcs by plumbing the crtc state deeper. Signed-off-by:
-
Ville Syrjälä authored
Just store the stuff directly into crtc_state->dpll_hw_state rather than to a temp and copying the whole thing over. Signed-off-by:
-
Ville Syrjälä authored
Simplify the calling convention of the skl dpll funcs by plumbing the crtc state deeper. Signed-off-by:
-
Ville Syrjälä authored
Passing both crtc and its state is redundant. Pass just the state. Signed-off-by:
-
Ville Syrjälä authored
Passing both crtc and its state is redundant. Pass just the state. Signed-off-by:
-
Chris Wilson authored
For virtual engines, we need to keep the HW context alive while it remains in use. For regular HW contexts, they are created and kept alive until the end of the GEM context. For simplicity, generalise the requirements and keep an active reference to each HW context. 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/20190318212347.30146-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
On unpinning the intel_context, we remove it from the active list inside the GEM context. This list is supposed to be guarded by the GEM context mutex, so remember to take it! Fixes: 7e3d9a59 ("drm/i915: Track active engines within a context") Signed-off-by:
-
Jani Nikula authored
We've been free of deprecated drmP.h includes for a while, but one crept in. Fend it off. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190318160409.27648-1-jani.nikula@intel.com
-
Jani Nikula authored
We no longer allow mixed C99 and kernel types, and the preference is to use kernel types exclusively. Fix the C99 types that have crept in since the mass conversion. No functional changes. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Kevin Strasser <kevin.strasser@intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 18 Mar, 2019 10 commits
-
-
Chris Wilson authored
As the final request on a ring may hold the reference to this ring (via retiring the last pinned context), we may find ourselves chasing a dangling pointer on completion of the list. A quick solution is to hold a reference to the ring itself as we retire along it so that we only free it after we stop dereferencing it. Signed-off-by:
-
Chris Wilson authored
If we use the STORE_DATA_INDEX function we can use a fixed offset and avoid having to lookup up the engine HWS address. A step closer to being able to emit the final breadcrumb during request_add rather than later in the submission interrupt handler. Signed-off-by:
-
Ville Syrjälä authored
We're currently leaving the CUS enabled if we disable the master plane directly after scanning out NV12. Could perhaps cause the selected slave plane to misbehave if we try to use it for scanning out something non-NV12? Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110032
-
Ville Syrjälä authored
We must remember to actually enable the post CSC gamma if we expect the legacy LUT to work. Seems to fix NV12 crc tests on the SDR planes. Curiously we apparently managed to get 100% match for the HDR planes even without chopping off the low bits. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Joonas Lahtinen authored
Merge tag 'topic/hdr-formats-2019-03-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-intel-next-queued Add support for floating point half-width formats. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/00b96cd5-91c7-5677-9620-b138c7a92303@linux.intel.com
-
Jani Nikula authored
Slightly verbose, but does away with hand rolled shifts. Ties the field values with the mask defining the field. Unfortunately we have to make a local copy of FIELD_PREP() to evaluate to a integer constant expression. But with this, we can ensure the mask is non-zero, power of 2, fits u32, and the value fits the mask (when the value is a constant expression). Convert power sequencer registers as an example. v4: - rebase v3: - rename the macro to REG_FIELD_PREP to avoid underscore prefix and to be in line with kernel macros (Chris) - rename power of 2 check macro (Chris) v2: - add build-time checks with BUILD_BUG_ON_ZERO() - rename to just _FIELD() due to regmap.h REG_FIELD() clash Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access bitfields using the mask alone, with no need for separate shift. Indeed, the shift is redundant. We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above, in part to force u32 and for consistency with REG_BIT() and REG_GENMASK(), but also as we'll need to redefine REG_FIELD_PREP() in follow-up work to make it produce integer constant expressions. For the most part, REG_FIELD_GET() is shorter than masking followed by shift, and arguably has more clarity. REG_FIELD_PREP() can get more verbose than simply shifting in place, but it does provide masking to ensure we don't overflow the mask, something we usually don't bother with currently. Convert power sequencer registers as an example. v3: - temp variable removal (Chris) - rebase v2: - Add the REG_FIELD_GET() and REG_FIELD_PREP() wrappers to use them consistently from the start. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to define register bitfield masks. We define the above as wrappers to BIT() and GENMASK() respectively to force u32 type to go with our register size, and to add compile time checks on the bit numbers. The intention is that these are easier to get right and review against the spec than hand rolled masks. Convert power sequencer registers as an example. v4: - rebase v3: - rename macros to REG_BIT() and REG_GENMASK() to avoid underscore prefix and to be in line with kernel macros (Chris) - add compile time checks (Mika) v2: - rename macros to just _BIT() and _MASK() to reduce verbosity Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
We only need to acquire a wakeref for ourselves for a few operations, as most either already acquire their own wakeref or imply a wakeref. In particular, it is i915_gem_set_wedged() that needed us to present it with a wakeref, which is incongruous with its "use anywhere" ability. Suggested-by:
"Yokoyama, Caz" <caz.yokoyama@intel.com> Signed-off-by:
-
Chris Wilson authored
We assumed that vm_mmap() would reject an attempt to mmap past the end of the filp (our object), but we were wrong. Applications that tried to use the mmap beyond the end of the object would be greeted by a SIGBUS. After this patch, those applications will be told about the error on creating the mmap, rather than at a random moment on later access. Reported-by:
Antonio Argenziano <antonio.argenziano@intel.com> Testcase: igt/gem_mmap/bad-size Signed-off-by:
-
- 16 Mar, 2019 1 commit
-
-
Daniele Ceraolo Spurio authored
The only usage we have for it is for the regs pointer. Save a pointer to the set and ack registers instead of the register offsets to remove this requirement v2: Keep passing uncore down to the lowest levels to avoid repeated pointer chasing in the innermost loops: add/remove: 0/0 grow/shrink: 3/15 up/down: 33/-155 (-122) Function old new delta fw_domain_init 320 351 +31 hdmi_port_clock_valid 319 320 +1 g4x_pre_enable_dp 364 365 +1 ring_request_alloc 1852 1851 -1 intel_engine_lookup_user 50 49 -1 gen11_irq_handler 738 737 -1 __intel_uncore_forcewake_get 115 112 -3 intel_uncore_fw_release_timer 198 194 -4 i915_forcewake_domains 154 150 -4 fw_domain_fini 172 168 -4 __intel_uncore_forcewake_put 163 159 -4 ___force_wake_auto 138 134 -4 fw_domains_put 98 92 -6 __err_print_to_sgl 4058 4052 -6 intel_uncore_forcewake_reset 459 444 -15 fw_domains_get 563 548 -15 fw_domain_wait_ack_with_fallback 490 450 -40 fw_domains_get_with_fallback 875 828 -47 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
- 15 Mar, 2019 14 commits
-
-
Chris Wilson authored
ffs() is 1-indexed, but we want to use it as an index into an array, so use __ffs() instead. Fixes: eb8d0f5a ("drm/i915: Remove GPU reset dependence on struct_mutex") Signed-off-by:
-
Ville Syrjälä authored
Split the csc matrix handling to ilk+ and icl+ functions. This keeps the logic clear on what is loaded into which CSC unit on the hardware. We also fix the icl+ code to load the full->limited range conversion matrix into the output CSC rather than the pipe CSC which was used on earlier platforms. And we also turn on the pipe CSC only when the ctm is present. Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
Just provide precomputed CSC matrices for the identity and limited range cases. This removes the remaining nuts and bolts stuff from ilk_load_csc_matrix(), allowing one to actually see the high level logic. Signed-off-by:
-
Ville Syrjälä authored
Start splitting low level nuts and bolts stuff from ilk_load_csc_matrix(). The goal is to leave only the clear high level logic in place. Signed-off-by:
-
Ville Syrjälä authored
We have far too much messy duplicated code in the pipe/output CSC programming. Simply provide two functions (ilk_update_pipe_csc() and icl_update_output_csc()) to program the relevant CSC registers. The desired offsets and coefficients are passed in as parameters. Signed-off-by:
-
Ville Syrjälä authored
Extract a helper which determines if we need to use the pipe CSC for limited range RGB output. Signed-off-by:
-
Ville Syrjälä authored
Let's precompute the CGM mode for CHV. And naturally we also read it out and check it. Signed-off-by:
-
Ville Syrjälä authored
Add the missing readout and PIPE_CONF_CHECK() for csc_mode. Signed-off-by:
-
Lucas De Marchi authored
This is only used in intel_display() and shouldn't be needed there. We don't want to keep converting from pll id to pll type so just remove the function. Signed-off-by:
-
Lucas De Marchi authored
Like was done for MG and combo, now finish the per-type split of the vfunc by moving TBT out of the combo functions. Now we can completely remove icl_pll_id_to_enable_reg() since each PLL type passes all the information via arguments. Signed-off-by:
-
Lucas De Marchi authored
Like was done in the enable case, split the implementation of the disable for MG and Combo PLLs. Signed-off-by:
-
Lucas De Marchi authored
Create separate functions to 1) enable power, 2) write pll config, and 3) enable pll. Doing this it makes it easier to share the functions for the different PLL types by passing the right arguments. Signed-off-by:
-
Lucas De Marchi authored
Let's start using the vfuncs to differentiate MG and Combo PLLs. The end goal is to decouple the type of the PLL from the IDs since the latter are likely to change from one platform to another. This also makes the code easier to read by not having lots of if/else chains on leaf functions. Signed-off-by:
-
Chris Wilson authored
With direct submission being disabled while the reset in progress, we have a small window where we may forgo the submission of a new request and not notice its addition during execlists_reset_finish. To close this window, always schedule the submission tasklet on coming out of reset to catch any residual work. <6> [333.144082] i915: Running intel_hangcheck_live_selftests/igt_reset_engines <3> [333.296927] i915_reset_engine(rcs0:idle): failed to idle after reset <6> [333.296932] i915 0000:00:02.0: [drm] rcs0 <6> [333.296934] i915 0000:00:02.0: [drm] Hangcheck 0:a9ddf7a5 [4157 ms] <6> [333.296936] i915 0000:00:02.0: [drm] Reset count: 36048 (global 754) <6> [333.296938] i915 0000:00:02.0: [drm] Requests: <6> [333.296997] i915 0000:00:02.0: [drm] RING_START: 0x00000000 <6> [333.296999] i915 0000:00:02.0: [drm] RING_HEAD: 0x00000000 <6> [333.297001] i915 0000:00:02.0: [drm] RING_TAIL: 0x00000000 <6> [333.297003] i915 0000:00:02.0: [drm] RING_CTL: 0x00000000 <6> [333.297005] i915 0000:00:02.0: [drm] RING_MODE: 0x00000200 [idle] <6> [333.297007] i915 0000:00:02.0: [drm] RING_IMR: fffffeff <6> [333.297010] i915 0000:00:02.0: [drm] ACTHD: 0x00000000_00000000 <6> [333.297012] i915 0000:00:02.0: [drm] BBADDR: 0x00000000_00000000 <6> [333.297015] i915 0000:00:02.0: [drm] DMA_FADDR: 0x00000000_00000000 <6> [333.297017] i915 0000:00:02.0: [drm] IPEIR: 0x00000000 <6> [333.297019] i915 0000:00:02.0: [drm] IPEHR: 0x00000000 <6> [333.297021] i915 0000:00:02.0: [drm] Execlist status: 0x00000001 00000000 <6> [333.297023] i915 0000:00:02.0: [drm] Execlist CSB read 5, write 5 [mmio:7], tasklet queued? no (enabled) <6> [333.297025] i915 0000:00:02.0: [drm] ELSP[0] idle <6> [333.297027] i915 0000:00:02.0: [drm] ELSP[1] idle <6> [333.297028] i915 0000:00:02.0: [drm] HW active? 0x0 <6> [333.297044] i915 0000:00:02.0: [drm] Queue priority hint: -8186 <6> [333.297067] i915 0000:00:02.0: [drm] Q 2afac:5f2+ prio=-8186 @ 50ms: (null) <6> [333.297068] i915 0000:00:02.0: [drm] HWSP: <6> [333.297071] i915 0000:00:02.0: [drm] [0000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <6> [333.297073] i915 0000:00:02.0: [drm] * <6> [333.297075] i915 0000:00:02.0: [drm] [0040] 00000001 00000000 00000018 00000002 00000001 00000000 00000018 00000000 <6> [333.297077] i915 0000:00:02.0: [drm] [0060] 00000001 00000000 00008002 00000002 00000000 00000000 00000000 00000005 <6> [333.297079] i915 0000:00:02.0: [drm] [0080] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <6> [333.297081] i915 0000:00:02.0: [drm] * <6> [333.297083] i915 0000:00:02.0: [drm] [00c0] 00000000 00000000 00000000 00000000 a9ddf7a5 00000000 00000000 00000000 <6> [333.297085] i915 0000:00:02.0: [drm] [00e0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <6> [333.297087] i915 0000:00:02.0: [drm] * <6> [333.297089] i915 0000:00:02.0: [drm] Idle? no <6> [333.297090] i915_reset_engine(rcs0:idle): 3000 resets <3> [333.297092] i915/intel_hangcheck_live_selftests: igt_reset_engines failed with error -5 <3> [333.455460] i915 0000:00:02.0: Failed to idle engines, declaring wedged! ... <0> [333.491294] i915_sel-4916 1.... 333262143us : i915_reset_engine: rcs0 flags=4 <0> [333.491328] i915_sel-4916 1.... 333262143us : execlists_reset_prepare: rcs0: depth<-0 <0> [333.491362] i915_sel-4916 1.... 333262143us : intel_engine_stop_cs: rcs0 <0> [333.491396] i915_sel-4916 1d..1 333262144us : process_csb: rcs0 cs-irq head=5, tail=5 <0> [333.491424] i915_sel-4916 1.... 333262145us : intel_gpu_reset: engine_mask=1 <0> [333.491454] kworker/-214 5.... 333262184us : i915_gem_switch_to_kernel_context: awake?=yes <0> [333.491487] kworker/-214 5.... 333262192us : i915_request_add: rcs0 fence 2afac:1522 <0> [333.491520] kworker/-214 5.... 333262193us : i915_request_add: marking (null) as active <0> [333.491553] i915_sel-4916 1.... 333262199us : intel_engine_cancel_stop_cs: rcs0 <0> [333.491587] i915_sel-4916 1.... 333262199us : execlists_reset_finish: rcs0: depth->0 Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190313162835.30228-1-chris@chris-wilson.co.uk
-
