summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
2020-08-17drm/i915/ddi: Don't rewrite DDI_BUF_CTL reg during DP link trainingImre Deak
The value we program to DDI_BUF_CTL changes at the following places: - At enabling/disabling the output to configure the port width etc, and to enable/disable the DDI BUF function. - At the beginning/end of link re-training to disable/re-enable the DDI BUF function. - On HSW/BDW/SKL to change the voltage swing/pre-emph levels. Except of the above the value we program to the DDI_BUF_CTL register (intel_dp->DP) doesn't change, so no need to reprogram the register when changing the link training patterns (which is programmed via the DP_TP_CTL register on DDI platforms). v2: - Fix the commit message wrt. voltage/pre-emph level values in intel_dp->DP. (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714153141.10280-2-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/ddi: Don't frob the DP link scramble disabling flagImre Deak
According to BSpec this flag should not be changed while the DDI function is enabled. On BDW+ the DP_TP_CTL register spec also states it explicitly that the HW takes care of enabling/disabling the scrambling for training patterns (and it must stay enabled for normal pixel output). Assume that this HW automatic handling of scrambling is also true for HSW. BSpec: 8013, 7557, 50484 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714153141.10280-1-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Make i830 .get_cdclk() assignment less confusingVille Syrjälä
Explicitly check for i830 when assigning the .get_cdclk() vfunc, and then deal with the case of not having assigned the vfunc separately. Less confusing, and gets rid of the checkpatch complaint about using {} on one branch but not the others. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Fix some whitespaceVille Syrjälä
Some spaces have snuck in where we want tabs. Fix it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Pack struct intel_cdclk_valsVille Syrjälä
There's a pointless hole in struct intel_cdclk_vals, get rid of it. Fortunately we already use named initializers so the order does not matter. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/fbc: Limit cfb to the first 256MiB of stolen on g4x+Ville Syrjälä
Since g4x the CFB base only takes a 28bit offset into stolen. Not sure if the CFB is allowed to start below that limit but then extend beyond it. Let's assume not and just restrict the allocation to the first 256MiB (in the unlikely case we have more stolen than that). v2: s/BIT/BIT_ULL/ (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714201945.18959-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-07-31Merge tag 'drm-intel-next-2020-07-15' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 features for v5.9, batch #2 Highlights: - Very early DG1 enabling (Abdiel, Lucas, Anusha) Gem/GT: - Fix spinlock recursion on signaling a signaled request (Chris) - Perf: Use GTT when saving/restoring engine GPR (Umesh Nerlige Ramappa) - SSEU refactoring, debugfs move under gt/ (Daniele, Venkata Sandeep Dhanalakota) - Various GT refactoring and cleanup, preparation for future changes (Daniele) - Adjust HuC state accordingly after GuC fetch error (Michał Winiarski) - UC debugfs updates (Michał Winiarski) - Only revoke the GGTT mmappings on aperture detiling changes (Chris) - Only revoke mmap handlers if active (Chris) - Split the context's obj:vma lut into its own mutex (Chris) - Various memory, mmap and performance optimisations (Chris) - Improve system stability in case of false CS events (Chris) - Various refactorings and cleanup (Chris) - Always reset the engine on execlist failures (Chris) - Trace placement of timeline HWSP (Chris) - Update dma-attributes for our sg DMA (Chris) Display: - TGL CDCLK workaround tweaks to unbreak 8K display support (Stanislav) - A number of FBC fixes, along with i865 FBC enabling (Ville) - Validate MST modes against PBN limits (Lyude, Shawn Lee) - Do not access non-existing swizzle registers (Lucas) - Revert GEN11+ HBR3 rate fix that caused issues on TGL (Matt Atwood) - Update TGL+ combo phy initialization to match spec update (José) - Fix HDCP Content Protection property state machine (Anshuman) - Fix HDCP revoked keys handling (Ram) - Improve DDI BUF status checks and waits (Manasi) - Various SDVO+HDMI+DVI fixes around colorimetry, clocking, pixel repeat etc. (Ville) - DP voltage swing function refactoring (José) - WARN if max vswing/pre-emphasis violates the DP spec (Ville) Other: - Add new EHL PCI IDs (José) - Unify struct intel_digital_port variable naming (Lucas) - Various taint updates to aid debugging and improve CI (Michał Winiarski) - Straggler conversions to new mmio register accessors (Daniele) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87a70029vz.fsf@intel.com
2020-07-24Merge v5.8-rc6 into drm-nextDave Airlie
I've got a silent conflict + two trees based on fixes to merge. Fixes a silent merge with amdgpu Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-07-20Merge tag 'drm-misc-next-2020-07-16' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.9: UAPI Changes: Cross-subsystem Changes: - Add ckoenig as dma-buf maintainer. - Revert invalid fix for dma-fence-chain, and fix selftest. - Add fixmes to amifb about APUS support. - Use array3_size in fbcon_prepare_logo, and struct_size() in alloc_apertures. - Fix leaks in neofb, fb/savage and omapfb. - Other small fixes to fb code. - Convert some dt bindings to schema for some panels, and fix simple-framebuffer dt example. Core Changes: - Add DRM_FORMAT_MOD_GENERIC_16_16_TILE as alias to DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, as it can be used more generic. - Add support for multiple DispID extension blocks in edid. - Use https instead of http for some of the urls. - Use drm_* macros for logging in mipi-dsi and fb-helper. - Further cleanup ttm_mem_reg handling. - Remove duplicated words in comments. Driver Changes: - Use __drm_atomic_helper_crtc_reset in all atomic drivers. - Add Amlogic Video FBC support to meson and fourcc to core. - Refactor hisilicon's hibmc_drv_vdac. - Create a TXP CRTC for vc4. - Rework cursor support in ast. - Fix runtime PM in STM. - Allow bigger cursors in vkms. - Cleanup sg handling in radeon and amdgpu, and stop creating dummy gtt nodes with ttm fixed. - Rework crtc handling in mgag200. - Miscellaneous small fixes to meson, vgem, bridge/dw-hdmi, panel/auo,b116xw03, panel/LG LB070WV8, lima, bridge/sil_sii8620, virtio, tilcdc. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8b360d65-f228-9286-d247-3004156a5254@linux.intel.com
2020-07-15drm/i915: Update DRIVER_DATE to 20200715Jani Nikula
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-15drm/i915/gt: Assert the kernel context is using the HWSPChris Wilson
We need to ensure that the kernel context is using the permanently pinned HWSP so that we can always submit a pm request from any context. By construction, the engine->kernel_context should only be using the engine->status_page.vma so let's assert that is still true when we have to submit a request for parking the engine. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714114419.28713-1-chris@chris-wilson.co.uk
2020-07-15drm/i915/gt: Trace placement of timeline HWSPChris Wilson
Track the position of the HWSP for each timeline. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2169 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/20200714135002.17508-1-chris@chris-wilson.co.uk
2020-07-15drm/i915: Remove unused inline function drain_delayed_work()YueHaibing
It is not used since commit 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Signed-off-by: YueHaibing <yuehaibing@huawei.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/20200715032104.32052-1-yuehaibing@huawei.com
2020-07-14drm/i915: Recalculate FBC w/a stride when neededVille Syrjälä
Currently we're failing to recalculate the gen9 FBC w/a stride unless something more drastic than just the modifier itself has changed. This often leaves us with FBC enabled with the linear fbdev framebuffer without the w/a stride enabled. That will cause an immediate underrun and FBC will get promptly disabled. Fix the problem by checking if the w/a stride is about to change, and go through the full dance if so. This part of the FBC code is still pretty much a disaster and will need lots more work. But this should at least fix the immediate issue. v2: Deactivate FBC when the modifier changes since that will likely require resetting the w/a CFB stride Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711080336.13423-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 0428ab013fdd39dbfb8f4cd8ad2b60af3776c6b9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-14drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.Maarten Lankhorst
This fixes the following KASAN splash on module reload: [ 145.136327] ================================================================== [ 145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134 [ 145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G U T 5.5.0-rc7-valkyria+ #5783 [ 145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016 [ 145.136546] Workqueue: events drm_connector_free_work_fn [ 145.136551] Call Trace: [ 145.136560] dump_stack+0xa1/0xe0 [ 145.136571] print_address_description.constprop.0+0x1e/0x210 [ 145.136639] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136703] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136710] __kasan_report.cold+0x1b/0x37 [ 145.136790] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136863] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136870] kasan_report+0x27/0x30 [ 145.136881] __asan_report_load8_noabort+0x1c/0x20 [ 145.136946] intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136954] drm_connector_free_work_fn+0xd1/0x100 [ 145.136967] process_one_work+0x86e/0x1610 [ 145.136987] ? pwq_dec_nr_in_flight+0x2f0/0x2f0 [ 145.137004] ? move_linked_works+0x128/0x2c0 [ 145.137021] worker_thread+0x63e/0xc90 [ 145.137048] kthread+0x2f6/0x3f0 [ 145.137054] ? calculate_sigpending+0x81/0xa0 [ 145.137059] ? process_one_work+0x1610/0x1610 [ 145.137064] ? kthread_bind+0x40/0x40 [ 145.137075] ret_from_fork+0x24/0x30 [ 145.137111] Allocated by task 0: [ 145.137119] (stack is not available) [ 145.137137] Freed by task 5053: [ 145.137147] save_stack+0x28/0x90 [ 145.137152] __kasan_slab_free+0x136/0x180 [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137581] __x64_sys_delete_module+0x35b/0x470 [ 145.137586] do_syscall_64+0x99/0x4e0 [ 145.137591] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 145.137606] The buggy address belongs to the object at ffff888216640000 which belongs to the cache kmalloc-8k of size 8192 [ 145.137618] The buggy address is located 6192 bytes inside of 8192-byte region [ffff888216640000, ffff888216642000) [ 145.137630] The buggy address belongs to the page: [ 145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0 [ 145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80 [ 145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000 [ 145.137656] page dumped because: kasan: bad access detected [ 145.137668] Memory state around the buggy address: [ 145.137678] ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137687] ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137706] ^ [ 145.137715] ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137724] ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137733] ================================================================== [ 145.137742] Disabling lock debugging due to kernel taint Changes since v1: - Add fixes tags. - Use early unregister. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi") Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200212135445.1469133-1-maarten.lankhorst@linux.intel.com (cherry picked from commit a581483b1e5466d28fc50ff623fba31cea2cccb6) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-14drm/i915/gt: Only swap to a random sibling once upon creationChris Wilson
The danger in switching at random upon intel_context_pin is that the context may still actually be inflight, as it will not be scheduled out until a context switch after it is complete -- that may be a long time after we do a final intel_context_unpin. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2118 Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713160549.17344-1-chris@chris-wilson.co.uk (cherry picked from commit 90a987205c6cf74116a102ed446d22d92cdaf915) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-14drm/i915/gt: Ignore irq enabling on the virtual enginesChris Wilson
We do not use the virtual engines for interrupts (they have physical components), but we do use them to decouple the fence signaling during submission. Currently, when we submit a completed request, we try to enable the interrupt handler for the virtual engine, but we never disarm it. A quick fix is then to mark the irq as enabled, and it will then remain enabled -- and this prevents us from waking the device and never letting it sleep again. Fixes: f8db4d051b5e ("drm/i915: Initialise breadcrumb lists on the virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711203236.12330-1-chris@chris-wilson.co.uk (cherry picked from commit 4fe6abb8f51355224808ab02a9febf65d184c40b) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-14drm/i915/perf: Use GTT when saving/restoring engine GPRUmesh Nerlige Ramappa
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which translation to use when saving restoring the engine general purpose registers to and from the GT scratch. Since GT scratch is mapped to ggtt, we need to set an additional bit in the command to use GTT. Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa configurations") Suggested-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200709224504.11345-1-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit e43ff99c8deda85234e6233e0f4af6cb09566a37) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-14drm/i915/selftests: Fix compare functions provided for sortingSudeep Holla
Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value at those pointers. This will result in incorrect/unsorted list. Fix it by deferencing the pointers before comparison. Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS") Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency measurement") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.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/20200709154931.23310-1-sudeep.holla@arm.com (cherry picked from commit 2196dfea896f7027b43bae848890ce4aec5c8724) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-14drm/i915/selftest: Fix an error code in live_noa_gpr()Dan Carpenter
The error code needs to be set on this path. It currently returns success. Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across noa_wait") Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200714143652.GA337376@mwanda
2020-07-14drm/i915: Recalculate FBC w/a stride when neededVille Syrjälä
Currently we're failing to recalculate the gen9 FBC w/a stride unless something more drastic than just the modifier itself has changed. This often leaves us with FBC enabled with the linear fbdev framebuffer without the w/a stride enabled. That will cause an immediate underrun and FBC will get promptly disabled. Fix the problem by checking if the w/a stride is about to change, and go through the full dance if so. This part of the FBC code is still pretty much a disaster and will need lots more work. But this should at least fix the immediate issue. v2: Deactivate FBC when the modifier changes since that will likely require resetting the w/a CFB stride Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711080336.13423-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-07-14drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.Maarten Lankhorst
This fixes the following KASAN splash on module reload: [ 145.136327] ================================================================== [ 145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134 [ 145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G U T 5.5.0-rc7-valkyria+ #5783 [ 145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016 [ 145.136546] Workqueue: events drm_connector_free_work_fn [ 145.136551] Call Trace: [ 145.136560] dump_stack+0xa1/0xe0 [ 145.136571] print_address_description.constprop.0+0x1e/0x210 [ 145.136639] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136703] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136710] __kasan_report.cold+0x1b/0x37 [ 145.136790] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136863] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136870] kasan_report+0x27/0x30 [ 145.136881] __asan_report_load8_noabort+0x1c/0x20 [ 145.136946] intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136954] drm_connector_free_work_fn+0xd1/0x100 [ 145.136967] process_one_work+0x86e/0x1610 [ 145.136987] ? pwq_dec_nr_in_flight+0x2f0/0x2f0 [ 145.137004] ? move_linked_works+0x128/0x2c0 [ 145.137021] worker_thread+0x63e/0xc90 [ 145.137048] kthread+0x2f6/0x3f0 [ 145.137054] ? calculate_sigpending+0x81/0xa0 [ 145.137059] ? process_one_work+0x1610/0x1610 [ 145.137064] ? kthread_bind+0x40/0x40 [ 145.137075] ret_from_fork+0x24/0x30 [ 145.137111] Allocated by task 0: [ 145.137119] (stack is not available) [ 145.137137] Freed by task 5053: [ 145.137147] save_stack+0x28/0x90 [ 145.137152] __kasan_slab_free+0x136/0x180 [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137581] __x64_sys_delete_module+0x35b/0x470 [ 145.137586] do_syscall_64+0x99/0x4e0 [ 145.137591] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 145.137606] The buggy address belongs to the object at ffff888216640000 which belongs to the cache kmalloc-8k of size 8192 [ 145.137618] The buggy address is located 6192 bytes inside of 8192-byte region [ffff888216640000, ffff888216642000) [ 145.137630] The buggy address belongs to the page: [ 145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0 [ 145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80 [ 145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000 [ 145.137656] page dumped because: kasan: bad access detected [ 145.137668] Memory state around the buggy address: [ 145.137678] ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137687] ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137706] ^ [ 145.137715] ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137724] ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137733] ================================================================== [ 145.137742] Disabling lock debugging due to kernel taint Changes since v1: - Add fixes tags. - Use early unregister. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi") Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200212135445.1469133-1-maarten.lankhorst@linux.intel.com
2020-07-14drm/i915/dg1: Add fake PCHLucas De Marchi
DG1 has the south engine display on the same PCI device. Ideally we could use HAS_PCH_SPLIT(), but that macro is misused all across the code base to rather signify a range of gens. So add a fake one for DG1 to be used where needed. Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713182321.12390-6-lucas.demarchi@intel.com
2020-07-14drm/i915/dg1: Remove SHPD_FILTER_CNT register programmingAnusha Srivatsa
Bspec asks us to remove the special programming of the SHPD_FILTER_CNT register which we have been doing since CNP+. Bspec: 49305 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> 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/20200713182321.12390-5-lucas.demarchi@intel.com
2020-07-14drm/i915/dg1: add support for the master unit interruptLucas De Marchi
DG1 has master unit interrupt register which is used to indicate the correct source of interrupt. v2: fix coding style on register definition Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Daniele Spurio Ceraolo <daniele.ceraolospurio@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> 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/20200713182321.12390-4-lucas.demarchi@intel.com
2020-07-14drm/i915/dg1: add initial DG-1 definitionsAbdiel Janulgue
Bspec: 33617, 33617 v2: s/intel_dg1_info/dg1_info/ as done for other platforms before and try to shut up compiler about ununsed variable that we know shouldn't be used (Lucas) v3: replace explicit attribute with __maybe_unused (Lucas) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Vanshidhar Konda <vanshidhar.r.konda@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> 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/20200713182321.12390-2-lucas.demarchi@intel.com
2020-07-14drm/i915: Add has_master_unit_irq flagStuart Summers
Add flag to differentiate platforms with and without the master IRQ control bit. Signed-off-by: Stuart Summers <stuart.summers@intel.com> 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/20200713182321.12390-1-lucas.demarchi@intel.com
2020-07-13drm/i915: WARN if max vswing/pre-emphasis violates the DP specVille Syrjälä
According to the DP spec a DPTX must support vswing/pre-emphasis up to and including level 2. Level 3 is optional (actually DP 1.4a seems to make even level 3 mandatory for HBR2/3, while leaving it optional for RBR/HBR1). WARN if out encoders' .voltage_max()/.preemph_max() return an illegal value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200709145845.18118-1-ville.syrjala@linux.intel.com
2020-07-13drm/i915/mst: filter out the display mode exceed sink's capabilityLee Shawn C
So far, max dot clock rate for MST mode rely on physcial bandwidth limitation. It would caused compatibility issue if source display resolution exceed MST hub output ability. For example, source DUT had DP 1.2 output capability. And MST docking just support HDMI 1.4 spec. When a HDMI 2.0 monitor connected. Source would retrieve EDID from external and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps because it did not surpass DP physical bandwidth limitation. Do modeset to 4k@60fps, source output display data but MST docking can't output HDMI properly due to this resolution already over HDMI 1.4 spec. Refer to commit <fcf463807596> ("drm/dp_mst: Use full_pbn instead of available_pbn for bandwidth checks"). Source driver should refer to full_pbn to evaluate sink output capability. And filter out the resolution surpass sink output limitation. Changes since v1: * Using mgr->base.lock to protect full_pbn. Changes since v2: * Add ctx lock. Changes since v3: * s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/ intel_dp_mst_mode_clock_exceeds_pbn_bw/ * Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe down the drm_modeset_acquire_ctx that the probe helpers are using, so we can safely grab &mgr->base.lock without deadlocking Changes since v4: * Move drm_dp_calc_pbn_mode(mode->clock, bpp, false) > port->full_pbn check * Fix the bpp we use in drm_dp_calc_pbn_mode() * Drop leftover (!mgr) check * Don't check for if full_pbn is unset. To be clear - it _can_ be unset, but if it is then it's certainly a bug in DRM or a non-compliant sink as full_pbn should always be populated by the time we call ->mode_valid_ctx. We should workaround non-compliant sinks with full_pbn=0, but that should happen in the DP MST helpers so we can estimate the full_pbn value as best we can. Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Co-developed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713170746.254388-3-lyude@redhat.com
2020-07-13drm/i915: Skip signaling a signaled requestChris Wilson
Preempt-to-busy introduces various fascinating complications in that the requests may complete as we are unsubmitting them from HW. As they may then signal after unsubmission, we may find ourselves having to cleanup the signaling request from within the signaling callback. This causes us to recurse onto the same i915_request.lock. However, if the request is already signaled (as it will be before we enter the signal callbacks), we know we can skip the signaling of that request during submission, neatly evading the spinlock recursion. unsubmit(ve.rq0) # timeslice expiration or other preemption -> virtual_submit_request(ve.rq0) dma_fence_signal(ve.rq0) # request completed before preemption ack -> submit_notify(ve.rq1) -> virtual_submit_request(ve.rq1) # sees that we have completed ve.rq0 -> __i915_request_submit(ve.rq0) [ 264.210142] BUG: spinlock recursion on CPU#2, sample_multi_tr/2093 [ 264.210150] lock: 0xffff9efd6ac55080, .magic: dead4ead, .owner: sample_multi_tr/2093, .owner_cpu: 2 [ 264.210155] CPU: 2 PID: 2093 Comm: sample_multi_tr Tainted: G U [ 264.210158] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X212.B01.1909060036 09/06/2019 [ 264.210160] Call Trace: [ 264.210167] dump_stack+0x98/0xda [ 264.210174] spin_dump.cold+0x24/0x3c [ 264.210178] do_raw_spin_lock+0x9a/0xd0 [ 264.210184] _raw_spin_lock_nested+0x6a/0x70 [ 264.210314] __i915_request_submit+0x10a/0x3c0 [i915] [ 264.210415] virtual_submit_request+0x9b/0x380 [i915] [ 264.210516] submit_notify+0xaf/0x14c [i915] [ 264.210602] __i915_sw_fence_complete+0x8a/0x230 [i915] [ 264.210692] i915_sw_fence_complete+0x2d/0x40 [i915] [ 264.210762] __dma_i915_sw_fence_wake+0x19/0x30 [i915] [ 264.210767] dma_fence_signal_locked+0xb1/0x1c0 [ 264.210772] dma_fence_signal+0x29/0x50 [ 264.210871] i915_request_wait+0x5cb/0x830 [i915] [ 264.210876] ? dma_resv_get_fences_rcu+0x294/0x5d0 [ 264.210974] i915_gem_object_wait_fence+0x2f/0x40 [i915] [ 264.211084] i915_gem_object_wait+0xce/0x400 [i915] [ 264.211178] i915_gem_wait_ioctl+0xff/0x290 [i915] Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: "Nayana, Venkata Ramana" <venkata.ramana.nayana@intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713141636.29326-1-chris@chris-wilson.co.uk
2020-07-13drm/i915/gt: Only swap to a random sibling once upon creationChris Wilson
The danger in switching at random upon intel_context_pin is that the context may still actually be inflight, as it will not be scheduled out until a context switch after it is complete -- that may be a long time after we do a final intel_context_unpin. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2118 Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713160549.17344-1-chris@chris-wilson.co.uk
2020-07-13drm/i915/selftest: fix an error return path where err is not being setColin Ian King
There is an error condition where err is not being set and an uninitialized garbage value in err is being returned. Fix this by assigning err to an appropriate error return value before taking the error exit path. Addresses-Coverity: ("Uninitialized scalar value") Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across noa_wait") Signed-off-by: Colin Ian King <colin.king@canonical.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/20200713142551.423649-1-colin.king@canonical.com
2020-07-13drm/i915/gt: Ignore irq enabling on the virtual enginesChris Wilson
We do not use the virtual engines for interrupts (they have physical components), but we do use them to decouple the fence signaling during submission. Currently, when we submit a completed request, we try to enable the interrupt handler for the virtual engine, but we never disarm it. A quick fix is then to mark the irq as enabled, and it will then remain enabled -- and this prevents us from waking the device and never letting it sleep again. Fixes: f8db4d051b5e ("drm/i915: Initialise breadcrumb lists on the virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711203236.12330-1-chris@chris-wilson.co.uk
2020-07-13drm/i915/gt: Always reset the engine, even if inactive, on execlists failureChris Wilson
If something has gone awry with the CSB processing, we need to pause, unwind and restart the request submission and event processing. However, currently we skip the engine reset if we raise an error but discover no active context, in the mistaken belief that it was merely a glitch in the matrix. The glitches are real enough, and we do need to unwind even if the engine appears idle (as it has gone permanently idle!) The simplest way to unwind and recover is simply do the engine reset, which should be very fast and _safe_ as nothing is active. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711091349.28865-1-chris@chris-wilson.co.uk
2020-07-10drm/i915: Pull printing GT capabilities on error to err_print_gtChris Wilson
We try not to assume that we captured any information, and so have to check that error->gt exists before reporting. This check was missed in err_print_capabilities, so lets break up the capability info and push it into the GT dump. We are still a long way from yamlifying this output! Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 792592e72aba ("drm/i915: Move the engine mask to intel_gt_info") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200710193239.5419-1-chris@chris-wilson.co.uk
2020-07-10drm/i915/gt: Be defensive in the face of false CS eventsChris Wilson
If the HW throws a curve ball and reports either en event before it is possible, or just a completely impossible event, we have to grin and bear it. The first few events, we will likely not notice as we would be expecting some event, but as soon as we stop expecting an event and yet they still keep coming, then we enter into undefined state territory. In which case, bail out, stop processing the events, and reset the engine and our set of queued requests to recover. The sporadic hangs and warnings will continue to plague CI, but at least system stability should not be compromised. v2: Commentary and force the reset-on-error. v3: Customised user facing message for forced resets from internal errors. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2045 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/20200710133125.30194-1-chris@chris-wilson.co.uk
2020-07-10drm/i915/selftest: Check that GPR are restored across noa_waitChris Wilson
Perf implements a GPU delay (noa_wait) by looping until the CS timestamp has passed a certain point. This use MI_MATH and the general purpose registers of the user's context, and since it is clobbering the user state it must carefully save and restore the user's data around the noa_wait. We can verify this by loading some values in the GPR that we know will be clobbered by the noa_wait, and then inspecting the GPR after the noa_wait completes and confirming that they have been restored. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200709224504.11345-2-chris@chris-wilson.co.uk
2020-07-10drm/i915/perf: Use GTT when saving/restoring engine GPRUmesh Nerlige Ramappa
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which translation to use when saving restoring the engine general purpose registers to and from the GT scratch. Since GT scratch is mapped to ggtt, we need to set an additional bit in the command to use GTT. Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa configurations") Suggested-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200709224504.11345-1-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-07-09drm/i915/gt: Optimise aliasing-ppgtt allocationsChris Wilson
Since the aliasing-ppgtt remains the default for gen6/gen7, it is worth optimising the ppgtt allocation for it. In this case, we do not need to flush the GGTT page directories entries as they are fixed during setup. 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/20200709190111.5492-1-chris@chris-wilson.co.uk
2020-07-09drm/i915/bios: Parse HOBL parameterJosé Roberto de Souza
HOBL means hours of battery life, it is a power-saving feature were supported motherboards can use a special voltage swing table that uses less power. So here parsing the VBT to check if this feature is supported. BSpec: 20150 Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708205512.21625-3-jose.souza@intel.com
2020-07-09drm/i915/display: Remove port and phy from voltage swing functionsJosé Roberto de Souza
This information can be get directly from intel_encoder so no need of those parameters. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708205512.21625-2-jose.souza@intel.com
2020-07-09drm/i915/display: Replace drm_i915_private in voltage swing functions by ↵José Roberto de Souza
intel_encoder intel_encoder will be needed inside of vswing functions in a future patch, so here doing this change in all vswing functions since HSW. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708205512.21625-1-jose.souza@intel.com
2020-07-09drm/i915/selftests: Fix compare functions provided for sortingSudeep Holla
Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value at those pointers. This will result in incorrect/unsorted list. Fix it by deferencing the pointers before comparison. Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS") Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency measurement") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.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/20200709154931.23310-1-sudeep.holla@arm.com
2020-07-09drm/i915/tgl: Implement WAs 18011464164 and 22010931296José Roberto de Souza
As today those 2 WAs have different implementation between TGL and DG1 WA pages but checking the HSD it is clear that DG1 implementation should be used for both, also to do so is easier as we just need to extend WA 1407928979 to B* stepping. Both WAs are need to fix some possible render corruptions. DG1 initial patches were not merged yet, as soon it is this WAs should be applied to DG1 as well. BSpec: 53508 BSpec: 52890 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708212947.40178-1-jose.souza@intel.com
2020-07-09drm/i915: Document FBC related w/as more thoroughlyVille Syrjälä
Pimp the comments for the FBC related workarounds. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708131223.9519-4-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-07-09drm/i915: Limit WaFbcHighMemBwCorruptionAvoidance to skl and bxtVille Syrjälä
Supposedly only skl/bxt need WaFbcHighMemBwCorruptionAvoidance. Do not apply to the other gen9 platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708131223.9519-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-07-09drm/i915: Don't do WaFbcTurnOffFbcWatermark for glkVille Syrjälä
GLK supposedly does not need WaFbcTurnOffFbcWatermark, so let's not apply it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708131223.9519-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-07-09drm/i915: Move all FBC w/as to .init_clock_gating()Ville Syrjälä
Some platforms apply the FBC w/as in .init_clock_gating(), some in fbc_activate(). Move them all to .init_clock_gating() for consistentce. Also safer since we don't have to worry about the RMWs clashing with any other runtime use of the same registers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708131223.9519-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-07-09drm/i915/dvo: Make .get_modes() return the number of modesVille Syrjälä
.get_modes() is supposed to return the number of modes added to the probed_modes list (not that anyone actually checks for anything except zero vs. not zero). Let's do that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-9-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-09drm/i915/sdvo: Make .get_modes() return the number of modesVille Syrjälä
.get_modes() is supposed to return the number of modes added to the probed_modes list (not that anyone actually checks for anything except zero vs. not zero). Let's do that. Also switch over to using intel_connector_update_modes() instead of hand rolling it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-8-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 10:59:02 +0000