- 04 Apr, 2019 4 commits
-
-
Jani Nikula authored
The below commits added dummy files to test that certain headers are self-contained, i.e. compilable as standalone units: 39e2f501 ("drm/i915: Split struct intel_context definition to its own header") 3a891a62 ("drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h") 8b74594a ("drm/i915: Split out i915_priolist_types into its own header") The idea is fine, but the implementation is a bit tedious and inflexible, and does not really scale well. Implement the same in make using autogenerated dummy sources to include the headers. v2 by Chris: - Use patsubst - Add .gitignore - Add clean-files for generated dummy sources v3 by Jani: - Fix make clean - Add the tests to i915-y instead of extra-y v4 by Jani: - quiet_cmd whitespace fix Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@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/20190403135236.8398-1-jani.nikula@intel.com
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_cdclk.c:2116: warning: Function parameter or member 'dev_priv' not described in 'intel_cdclk_needs_cd2x_update' Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190404073357.18795-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Mixing u8 and -1u together leads to zero-extended integer expansion, and comparing 0x000000ff against 0xffffffff, causing us to report a mixed uabi-class request as not busy. The input flag is a u8, and we want to generate a u32 uABI response, mark our functions so. Fixes: c8b50242 ("drm/i915: Remove last traces of exec-id (GEM_BUSY)") Testcase: igt/gem_exec_balance/busy Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190404101914.7231-1-chris@chris-wilson.co.uk
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 03 Apr, 2019 15 commits
-
-
Ville Syrjälä authored
On ivb+ we can select between the regular 10bit LUT mode with 1024 entries, and the split mode where the LUT is split into seprate degamma and gamma halves (each with 512 entries). Currently we expose the split gamma size of 512 as the GAMMA/DEGAMMA_LUT_SIZE. When using only degamma or gamma (not both) we are wasting half of the hardware LUT entries. Let's flip that around so that we expose the full 1024 entries and just throw away half of the user provided entries when using the split gamma mode. Cc: Matt Roper <matthew.d.roper@intel.com> Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
Just so we don't leave gen2/3 out in the cold let's advertize the legacy LUT via the GAMMA_LUT/GAMMA_LUT_SIZE props. Without the GAMMA_LUT prop we can't actually load a LUT using the atomic ioctl (in preparation for the day of 100% atomic driver). Supposedly some gen2/3 platforms have an interpolated 10bit gamma mode as well. It's slightly funkier than the i965+ mode since you have to specify the slope for the interpolation by hand. But when I tried it I couldn't get it to work, the hardware just insisted on using the 8bit more regardless of the state of the relevant PIPECONF bit. Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
i965+ have an interpolate 10bit LUT mode. Let's expose that so that we can actually enjoy real 10bpc. v2: Don't use I915_WRITE_FW() yet Reviewed-by:
-
Ville Syrjälä authored
Plop in support for 10bit LUT on ilk/snb. There is no split gamma mode on these platforms, so we have to choose between degamma and gamma. That could be a runtime choice but for now let's just advertize the gamma as having 1024 entries. We'll also keep the ctm hidden for now. v2: Don't use I915_WRITE_FW() yet Introduce bool has_ctm (Maarten) Call drm_crtc_enable_color_mgmt() uncoditionally (Maarten) Reviewed-by: -
Ville Syrjälä authored
Reuse the bdw+ code to get split/10bit gamma for ivb/hsw. The hardware is nearly identical. The only slight snag is that on ivb/hsw the precision palette auto increment mode does not work. So we must increment the index manually. We'll probably want to stick to the auto increment mode on bdw+ in the name of efficiency. Also we want to avoid using the CSC for limited range RGB output as PIPECONF will take care of that on IVB. v2: Rebase due to EXT_GC_MAX/EXT2_GC_MAX changes Reviewed-by:
-
Ville Syrjälä authored
Using the split gamma mode when we don't have to has the annoying requirement of loading a linear LUT to the unused half. Instead let's make life simpler by switching to the 10bit gamma mode and duplicating each entry. This also allows us to load the software gamma LUT into the hardware degamma LUT, thus removing some of the buggy configurations we currently allow (YCbCr/limited range RGB + gamma LUT). We do still have other configurations that are also buggy, but those will need more complicated fixes or they just need to be rejected. Sadly GLK doesn't have this flexibility anymore and the degamma and gamma LUTs are very different so no help there. v2: Apply a mask when checking gamma_mode on icl since it contains more bits than just the gamma mode v3: Rebase due to EXT_GC_MAX/EXT2_GC_MAX changes v4: s/advertize/advertise/ (Uma) Signed-off-by: -
Ville Syrjälä authored
Extract a helper to calculate the ILK+ 10bit gamma LUT entry. It's already duplicated twice, and soon we'll have more. v2: s/it/bit/ (Matt) Reviewed-by:
-
Ville Syrjälä authored
If we have only a single active pipe and the cdclk change only requires the cd2x divider to be updated bxt+ can do the update with forcing a full modeset on the pipe. Try to hook that up. v2: - Wait for vblank after an optimized CDCLK change. - Avoid optimization if the pipe needs a modeset (or was disabled). - Split CDCLK change to a pre/post plane update step. v3: - Use correct version of CDCLK state as old state. (Ville) - Remove unused intel_cdclk_can_skip_modeset() v4: - For consistency call intel_set_cdclk_post_plane_update() only during modesets (and not fastsets). v5: - Remove the logic to update the CD2X divider on-the-fly on ICL, since only a divider of 1 is supported there. Clint also noticed that the pipe select bits in CDCLK_CTL are oddly defined on ICL, it's not clear yet whether that's only an error in the specification. Signed-off-by:
Abhay Kumar <abhay.kumar@intel.com> Tested-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190327101321.3095-1-imre.deak@intel.com
-
Imre Deak authored
We copied the original state into the atomic state already earlier in the function, so no need to do it a second time. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
The old state will be needed by an upcoming patch to determine if the commit increases or decreases CDCLK, so move the old state to the atomic state (while keeping the new one in dev_priv). cdclk.logical and cdclk.actual in the atomic state isn't used atm anywhere after the atomic check phase, so this should be safe. v2: - Use swap() instead of opencoding it. (Ville) Suggested-by:
-
Ville Syrjälä authored
CDCLK has to be at least twice the BLCK regardless of audio. Audio driver has to probe using this hook and increase the clock even in absence of any display. v2: Use atomic refcount for get_power, put_power so that we can call each once(Abhay). v3: Reset power well 2 to avoid any transaction on iDisp link during cdclk change(Abhay). v4: Remove Power well 2 reset workaround(Ville). v5: Remove unwanted Power well 2 register defined in v4(Abhay). v6: - Use a dedicated flag instead of state->modeset for min CDCLK changes - Make get/put audio power domain symmetric - Rebased on top of intel_wakeref tracking changes. Signed-off-by: -
Chris Wilson authored
Use the engine->flags to store whether we want to kick the submission tasklet on receipt of a breadcrumb interrupt, so that this decision can be made by the submission backend and not dependent on a limited feature test within the interrupt handler. This should make it easier to adapt to different submission backends. Signed-off-by:
-
Tvrtko Ursulin authored
Mask need to be initialized to zero since device id checks may not match. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 805446c8 ("drm/i915: Introduce concept of a sub-platform") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jose Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
Add "_mmio" postfix to be consistent from the init/fini phase they're called from. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Suggested-by:
-
Daniele Ceraolo Spurio authored
Encapsulate the uncore early init and be consistent with the "_early" naming. Signed-off-by:
-
- 02 Apr, 2019 5 commits
-
-
Bob Paauwe authored
Unlike ICL, all of the output ports are combo phys so just return true in intel_port_is_combophy for all EHL ports to indicate that. v2: Return false in intel_port_is_tc since no EHL ports are TC. (Jose) Cc: Jose Souza <jose.souza@intel.com> Signed-off-by:
Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190320211547.519266-1-bob.j.paauwe@intel.com
-
Chris Wilson authored
Ideally we only need one semaphore per ring to accommodate waiting on multiple engines in parallel. However, since we do not know which fences we will finally be waiting on, we emit a semaphore for every fence. It turns out to be quite easy to trick ourselves into exhausting our ringbuffer causing an error, just by feeding in a batch that depends on several thousand contexts. Since we never can be waiting on more than one semaphore in parallel (other than perhaps the desire to busywait on multiple engines), just pick the first fence for our semaphore. If we pick the wrong fence to busywait on, we just miss an opportunity to reduce latency. An adaption might be to use sched.flags as either a semaphore counter, or to track the first busywait on each engine, converting it back to a single use bit prior to closing the request. v2: Track first semaphore used per-engine (this caters for our basic igt that semaphores are working). Reported-by:
Mika Kuoppala <mika.kuoppala@intel.com> Testcase: igt/gem_exec_fence/long-history Fixes: e8861964 ("drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+") Signed-off-by:
-
Chris Wilson authored
For more intel_engine_mask_t detangling. This time so that we can use intel_engine_mask_t inside the scheduling structs. Signed-off-by:
-
Chris Wilson authored
We want to use intel_engine_mask_t inside i915_request.h, which means extracting it from the general header file mess and placing it inside a types.h. A knock on effect is that the compiler wants to warn about type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare for the worst. v2: Use intel_engine_mask_t consistently v3: Move I915_NUM_ENGINES to its natural home at the end of the enum Signed-off-by:
-
Chris Wilson authored
If the user passes in a pointer to a GGTT mmaping of the same buffer being written to, we can hit a deadlock in acquiring the shmemfs page (once as the write destination and then as the read source). [<0>] io_schedule+0xd/0x30 [<0>] __lock_page+0x105/0x1b0 [<0>] find_lock_entry+0x55/0x90 [<0>] shmem_getpage_gfp+0xbb/0x800 [<0>] shmem_read_mapping_page_gfp+0x2d/0x50 [<0>] shmem_get_pages+0x158/0x5d0 [i915] [<0>] ____i915_gem_object_get_pages+0x17/0x90 [i915] [<0>] __i915_gem_object_get_pages+0x57/0x70 [i915] [<0>] i915_gem_fault+0x1b4/0x5c0 [i915] [<0>] __do_fault+0x2d/0x80 [<0>] __handle_mm_fault+0xad4/0xfb0 [<0>] handle_mm_fault+0xe6/0x1f0 [<0>] __do_page_fault+0x18f/0x3f0 [<0>] page_fault+0x1b/0x20 [<0>] copy_user_enhanced_fast_string+0x7/0x10 [<0>] _copy_from_user+0x37/0x60 [<0>] shmem_pwrite+0xf0/0x160 [i915] [<0>] i915_gem_pwrite_ioctl+0x14e/0x520 [i915] [<0>] drm_ioctl_kernel+0x81/0xd0 [<0>] drm_ioctl+0x1a7/0x310 [<0>] do_vfs_ioctl+0x88/0x5d0 [<0>] ksys_ioctl+0x35/0x70 [<0>] __x64_sys_ioctl+0x11/0x20 [<0>] do_syscall_64+0x39/0xe0 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 We can reduce (but not eliminate!) the chance of this happening by faulting the user_data before we take the page lock in pagecache_write_begin(). One way to eliminate the potential recursion here is by disabling pagefaults for the copy, and handling the fallback to use an alternative method -- so convert to use kmap_atomic (which should disable preemption and pagefaulting for the copy) and report ENODEV instead of EFAULT so that our caller tries again with a different copy mechanism -- we already check that the page should have been faultable so a false negative should be rare. Testcase: igt/gem_pwrite/self Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190401133909.31203-1-chris@chris-wilson.co.uk
-
- 01 Apr, 2019 5 commits
-
-
Rodrigo Vivi authored
Let's reserve EHL stolen memory for graphics. ElkhartLake is a gen11 platform which is compatible with ICL changes. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190315191938.22211-2-rodrigo.vivi@intel.com
-
Tvrtko Ursulin authored
Concept of a sub-platform already exist in our code (like ULX and ULT platform variants and similar),implemented via the macros which check a list of device ids to determine a match. With this patch we consolidate device ids checking into a single function called during early driver load. A few low bits in the platform mask are reserved for sub-platform identification and defined as a per-platform namespace. At the same time it future proofs the platform_mask handling by preparing the code for easy extending, and tidies the very verbose WARN strings generated when IS_PLATFORM macros are embedded into a WARN type statements. v2: Fixed IS_SUBPLATFORM. Updated commit msg. v3: Chris was right, there is an ordering problem. v4: * Catch-up with new sub-platforms. * Rebase for RUNTIME_INFO. * Drop subplatform mask union tricks and convert platform_mask to an array for extensibility. v5: * Fix subplatform check. * Protect against forgetting to expand subplatform bits. * Remove platform enum tallying. * Add subplatform to error state. (Chris) * Drop macros and just use static inlines. * Remove redundant IRONLAKE_M. (Ville) v6: * Split out Ironlake change. * Optimize subplatform check. * Use __always_inline. (Lucas) * Add platform_mask comment. (Paulo) * Pass stored runtime info in error capture. (Chris) v7: * Rebased for new AML ULX device id. * Bump platform mask array size for EHL. * Stop mentioning device ids in intel_device_subplatform_init by using the trick of splitting macros i915_pciids.h. (Jani) * AML seems to be either a subplatform of KBL or CFL so express it like that. v8: * Use one device id table per subplatform. (Jani) Signed-off-by:
-
Tvrtko Ursulin authored
This will enable the following patch to consolidate most device ids into i915_pciids.h. While cross-referencing the ids listed in i915_drv.h, with the ones listed in i915_pciids.h, and also the comments in the latter, a bug for bug approach was used. This means two things: 1. Some ids are only present in i915_drv.h - obviously this means those parts would not have been probed at all so they were not added to i915_pciids.h 2. Some part type comments in i915_pciids.h were in disagreement with i915_drv.h. For instance parts labeled as ULT or ULX were not considered as such in i915_drv.h. The existing behaviour takes precedence here. Signed-off-by:
-
Tvrtko Ursulin authored
IS_IRONLAKE_M can use the already defined intel_device_info.is_mobile for this platform, so remove the instance of Ironlake's mobile device id from the header file and replace it with an IS_MOBILE check. v2: * Improved commit text. (Chris) v3: * Rebased for EHL. Signed-off-by:
-
Tvrtko Ursulin authored
This allows the IS_PINEVIEW_<G|M> macros to be removed and avoid duplication of device ids already defined in i915_pciids.h. !IS_MOBILE check can be used in place of existing IS_PINEVIEW_G call sites. Signed-off-by:
-
- 31 Mar, 2019 2 commits
-
-
Chris Wilson authored
When we return pages to the system, we release control over them and should defensively return them to the CPU write domain so that we catch any external writes on reacquiring them (e.g. to transparently swapout/swapin). While we did this defensive clflushing for ordinary shmem pages, it was forgotten for userptr. Fortunately, userptr objects are normally cache coherent and so oblivious to the forgotten domain tracking. References: a679f58d ("drm/i915: Flush pages on acquisition") References: 754a2544 ("drm/i915: Skip object locking around a no-op set-domain ioctl") Signed-off-by:
-
Chris Wilson authored
As we only set ctx->file_priv on registering the GEM context after construction, it is invalid to try and use it in the middle for setting various parameters. Indeed, we put the file_priv into struct create_ext so that we have the right file_private available without having to look at ctx->file_priv. However, it helps to use it! Reported-by:
Jordan Justen <jordan.l.justen@intel.com> Fixes: b9171541 ("drm/i915: Extend CONTEXT_CREATE to set parameters upon construction") Signed-off-by:
-
- 30 Mar, 2019 1 commit
-
-
Robert M. Fosha authored
Currently we only retry to load GuC firmware if the load fails due to timeout. On Gen9 GuC loading may fail for different reasons, not just hang/timeout. Direction from the GuC team is to retry for all cases of GuC load failure on Gen9, not just for timeout. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108593Signed-off-by:
Robert M. Fosha <robert.m.fosha@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
- 29 Mar, 2019 5 commits
-
-
Chris Wilson authored
If drm_modeset_lock() reports a deadlock it sets the ctx->contexted field and insists that the caller calls drm_modeset_backoff() or else it generates a WARN on cleanup. <4> [1601.870376] WARNING: CPU: 3 PID: 8445 at drivers/gpu/drm/drm_modeset_lock.c:228 drm_modeset_drop_locks+0x35/0x40 <4> [1601.870395] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal i915 coretemp crct10dif_pclmul <6> [1601.870403] Console: switching <4> [1601.870403] snd_hda_intel <4> [1601.870406] to colour frame buffer device 320x90 <4> [1601.870406] crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel e1000e snd_hda_core cdc_ether ptp usbnet mii pps_core snd_pcm i2c_i801 mei_me mei prime_numbers <4> [1601.870422] CPU: 3 PID: 8445 Comm: cat Tainted: G U 5.0.0-rc7-CI-CI_DRM_5650+ #1 <4> [1601.870424] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.2402.AD3.1810170014 10/17/2018 <4> [1601.870427] RIP: 0010:drm_modeset_drop_locks+0x35/0x40 <4> [1601.870430] Code: 29 48 8b 43 60 48 8d 6b 60 48 39 c5 74 19 48 8b 43 60 48 8d b8 70 ff ff ff e8 87 ff ff ff 48 8b 43 60 48 39 c5 75 e7 5b 5d c3 <0f> 0b eb d3 0f 1f 80 00 00 00 00 41 56 41 55 41 54 55 53 48 8b 6f <4> [1601.870432] RSP: 0018:ffffc90000d67ce8 EFLAGS: 00010282 <4> [1601.870435] RAX: 00000000ffffffdd RBX: ffffc90000d67d00 RCX: 5dbbe23d00000000 <4> [1601.870437] RDX: 0000000000000000 RSI: 0000000093e6194a RDI: ffffc90000d67d00 <4> [1601.870439] RBP: ffff88849e62e678 R08: 0000000003b7329a R09: 0000000000000001 <4> [1601.870441] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888492100410 <4> [1601.870442] R13: ffff88849ea50958 R14: ffff8884a67eb028 R15: ffff8884a67eb028 <4> [1601.870445] FS: 00007fa7a27745c0(0000) GS:ffff8884aff80000(0000) knlGS:0000000000000000 <4> [1601.870447] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [1601.870449] CR2: 000055af07e66000 CR3: 00000004a8cc2006 CR4: 0000000000760ee0 <4> [1601.870451] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [1601.870453] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 <4> [1601.870454] PKRU: 55555554 <4> [1601.870456] Call Trace: <4> [1601.870505] i915_dsc_fec_support_show+0x91/0x190 [i915] <4> [1601.870522] seq_read+0xdb/0x3c0 <4> [1601.870531] full_proxy_read+0x51/0x80 <4> [1601.870538] __vfs_read+0x31/0x190 <4> [1601.870546] ? __se_sys_newfstat+0x3c/0x60 <4> [1601.870552] vfs_read+0x9e/0x150 <4> [1601.870557] ksys_read+0x50/0xc0 <4> [1601.870564] do_syscall_64+0x55/0x190 <4> [1601.870569] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [1601.870572] RIP: 0033:0x7fa7a226d081 <4> [1601.870574] Code: fe ff ff 48 8d 3d 67 9c 0a 00 48 83 ec 08 e8 a6 4c 02 00 66 0f 1f 44 00 00 48 8d 05 81 08 2e 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53 <4> [1601.870576] RSP: 002b:00007ffcc05140c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 <4> [1601.870579] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fa7a226d081 <4> [1601.870581] RDX: 0000000000020000 RSI: 000055af07e63000 RDI: 0000000000000007 <4> [1601.870583] RBP: 0000000000020000 R08: 000000000000007b R09: 0000000000000000 <4> [1601.870585] R10: 000055af07e60010 R11: 0000000000000246 R12: 000055af07e63000 <4> [1601.870587] R13: 0000000000000007 R14: 000055af07e634bf R15: 0000000000020000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109745 Fixes: e845f099 ("drm/i915/dsc: Add Per connector debugfs node for DSC support/enable") Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190329165152.29259-1-chris@chris-wilson.co.uk
-
Uma Shankar authored
EXT2 GC MAX registers are introduced from Gen10+ to program values from 3.0 to 7.0. Enabled the same, but currently limiting it to 1.0 as userspace ABI is limited at that currently. v2: Updated the 1.0 programming and aligned as per GLK, also added GLK along with GEN10+ check, as per Ville's feedback. Signed-off-by:
-
Uma Shankar authored
GC MAX register is used to program values from 1.0 to less than 3.0. A different register was used instead of the intended one. Fixed the same. Currently limiting it to 1.0 due to ABI limitations. v2: Updated the 1.0 programming and aligned as per GLK, based on Ville's feedback. Reported-by:
-
Daniele Ceraolo Spurio authored
Those functions are used on gen4 as well and gen4 does have a non-RCS engine, so remove the BUG_ON and flip back the logic to what it was before the ENGINE_READ/WRITE update v2: update the posting read as well (Chris, Ville). Fixes: baba6e57 ("drm/i915: take a reference to uncore in the engine and use it") Signed-off-by:
-
Daniele Ceraolo Spurio authored
edram is not part of uncore and there is no requirement for the detection to be done before we initialize the uncore functions. The first check on HAS_EDRAM is in the ggtt_init path, so move it to i915_driver_init_hw, where other dram-related detection happens. While at it, save the size in MB instead of the capabilities because the size is the only thing we look at outside of the init function. Signed-off-by:
-
- 28 Mar, 2019 3 commits
-
-
Ville Syrjälä authored
Don't load the linear degamma LUT on ICL. The hardware no longer has any silly linkages between the CSC enable and degamma LUT enable so the degamma LUT is only needed when it's actually enabled. Also add comments to explain the situation on GLK. v2: Drop useless parens around 1<<16 v3: Add missing const Signed-off-by:
-
Ville Syrjälä authored
We now bypass the legacy LUT when it's not needed, so no point in filling it up with a linear LUT. Signed-off-by:
-
Ville Syrjälä authored
With everything else moved out of the way only ilk+ remains using _intel_color_check(). Streamline the logic into ilk_color_check(). v2: Add some comments explaining we that we don't expose the full hardware capabilities currently (Matt) Signed-off-by:
-
