aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2021-11-23drm/i915/gem: placate scripts/kernel-docRandy Dunlap1-3/+4
Correct kernel-doc warnings in i915_drm_object.c: i915_gem_object.c:103: warning: expecting prototype for i915_gem_object_fini(). Prototype was for __i915_gem_object_fini() instead i915_gem_object.c:110: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Mark up the object's coherency levels for a given cache_level i915_gem_object.c:110: warning: missing initial short description on line: * Mark up the object's coherency levels for a given cache_level i915_gem_object.c:457: warning: No description found for return value of 'i915_gem_object_read_from_page' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Auld <matthew.auld@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: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211123050928.20434-1-rdunlap@infradead.org
2021-11-23drm/i915/dg2: Tile 4 plane format supportStanislav Lisovskiy10-8/+29
TileF(Tile4 in bspec) format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY which will be supported by Display13. v2: - Fixed wrong case condition(Jani Nikula) - Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak) v3: - s/I915_TILING_F/TILING_4/g - s/I915_FORMAT_MOD_F_TILED/I915_FORMAT_MOD_4_TILED/g - Removed unneeded fencing code v4: - Rebased, fixed merge conflict with new table-oriented format modifier checking(Stan) - Replaced the rest of "Tile F" mentions to "Tile 4"(Stan) v5: - Still had to remove some Tile F mentionings - Moved has_4tile from adlp to DG2(Ramalingam C) - Check specifically for DG2, but not the Display13(Imre) v6: - Moved Tile4 associating struct for modifier/display to the beginning(Imre Deak) - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier checks(Imre Deak) - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12 (Imre Deak) v7: - Fixed display_ver to { 13, 13 }(Imre Deak) - Removed redundant newline(Imre Deak) Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122211420.31584-1-stanislav.lisovskiy@intel.com
2021-11-23Merge tag 'drm-misc-next-2021-11-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-nextDave Airlie8-163/+169
drm-misc-next for 5.17: UAPI Changes: * Remove restrictions on DMA_BUF_SET_NAME ioctl * connector: State of privacy screen * sysfs: Send hotplug uevent Cross-subsystem Changes: * clk/bmc-2835: Fixes * dma-buf: Add dma_resv selftest; Error-handling fixes; Add debugfs helpers; Remove dma_resv_get_excl_unlocked(); Documentation fixes * pwm: Introduce of_pwm_single_xlate() Core Changes: * Support for privacy screens * Make drm_irq.c legacy * Fix __stack_depot_* name conflict * Documentation fixes * Fixes and cleanups * dp-helper: Reuse 8b/10b link-training delay helpers * format-helper: Update interfaces * fb-helper: Allocate shadow buffer of correct size * gem: Link GEM SHMEM and CMA helpers into separate modules; Use dma_resv iterator; Import DMA_BUF namespace into GEM-helper modules * gem/shmem-helper: Interface cleanups * scheduler: Grab fence in drm_sched_job_add_implicit_dependencies(); Lockdep fixes * kms-helpers: Link several files from core into the KMS-helper module Driver Changes: * Use dma_resv_iter in several places * Fixes and cleanups * amdgpu: Use drm_kms_helper_connector_hotplug_event(); Get all fences at once * bridge: Switch to managed MIPI DSI helpers in several places; Register and attach during probe in several places; Convert to YAML in several places * bridge/anx7625: Support MIPI DPI input; Support HDMI audio; Fixes * bridge/dw-hdmi: Allow interlace on bridge * bridge/ps8640: Enable PM; Support aux-bus * bridge/tc358768: Enabled reference clock; Support pulse mode; Modesetting fixes * bridge/ti-sn65dsi86: Use regmap_bulk_write(); Implement PWM * etnaviv: Get all fences at once * gma500: GEM object cleanups; Remove generic drivers in probe function * i915: Support VESA panel backlights * ingenic: Fixes and cleanups * kirin: Adjust probe order * kmb: Enable framebuffer console * lima: Kconfig fixes * meson: Refactoring to supperot DRM_BRIDGE_ATTACH_NO_ENCODER * msm: Fixes and cleanups * msm/dsi: Adjust probe order * omap: Fixes and cleanups * nouveau: CRC fixes; Validate LUTs in atomic check; Set HDMI AVI RGB quantization to FULL; Fixes and cleanups * panel: Support Innolux G070Y2-T02, Vivax TPC-9150, JDI R63452, Newhaven 1.8-128160EF, Wanchanglong W552964ABA, Novatek NT35950, BOE BF060Y8M, Sony Tulip Truly NT35521; Use dev_err_probe() throughout drivers; Fixes and cleanups * panel/ili9881c: Orientation fixes * radeon: Use dma_resv_wait_timeout() * rockchip: Add timeout for DSP hold; Suspend/resume fixes; PLL clock fixes; Implement mmap in GEM object functions * simpledrm: Support FB_DAMAGE_CLIPS and virtual screen sizes * sun4i: Use CMA helpers without vmap support * tidss: Fixes and cleanups * v3d: Cleanups * vc4: Fix HDMI-CEC hang when display is off; Power on HDMI controller while disabling; Support 4k@60 Hz modes; Fixes and cleanups * video: Convert to sysfs_emit() in several places * video/omapfb: Fix fall-through * virtio: Overflow fixes * xen: Implement mmap as GEM object functions Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/YZYZSypIrr+qcih3@linux-uq9g.fritz.box
2021-11-22Merge drm/drm-next into drm-intel-nextJani Nikula8-54/+22
Sync up with drm-next to get v5.16-rc2. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-11-22drm/i915/ttm: Fix error code in i915_ttm_eviction_valuable()Dan Carpenter1-1/+1
This function returns a bool type so returning -EBUSY is equivalent to returning true. It should return false instead. Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122061438.GA2492@kili
2021-11-22drm/i915/rpm: Enable runtime pm autosuspend by defaultTilak Tangudu1-0/+3
Let's enable runtime pm autosuspend by default everywhere. So, we can allow D3hot and bigger power savings on idle scenarios. But at this time let's not touch the autosuspend_delay time, what caused some regression on our previous attempt. Also, the latest identified issue on GuC PM has been fixed by commit 1a52faed3131 ("drm/i915/guc: Take GT PM ref when deregistering context") v1: Enable runtime pm autosuspend by default for Gen12 and later versions. v2: Enable runtime pm autosuspend by default for all platforms(Syrjala Ville) v3: Change commit message(Nikula Jani) Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116155238.3226516-1-tilak.tangudu@intel.com
2021-11-22Merge drm/drm-next into drm-intel-gt-nextTvrtko Ursulin22-168/+183
Thomas needs the dma_resv_for_each_fence API for i915/ttm async migration work. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2021-11-22drm/i915/pmu: Avoid with_intel_runtime_pm within spinlockUmesh Nerlige Ramappa1-9/+3
When guc timestamp ping worker runs it takes the spinlock and calls with_intel_runtime_pm. Since with_intel_runtime_pm may sleep, move the spinlock inside __update_guc_busyness_stats. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211120014201.26480-1-umesh.nerlige.ramappa@intel.com
2021-11-19drm/i915: Drain the ttm delayed workqueue tooMaarten Lankhorst1-0/+1
Lets be thorough here. Users of the TTM backend would likely expect this behaviour. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-6-matthew.auld@intel.com
2021-11-19drm/i915: Remove resv from i915_vmaMaarten Lankhorst4-11/+9
It's just an alias to vma->obj->base.resv, no need to duplicate it. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-5-matthew.auld@intel.com
2021-11-19drm/i915: vma is always backed by an object.Maarten Lankhorst4-33/+22
vma->obj and vma->resv are now never NULL, and some checks can be removed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-4-matthew.auld@intel.com
2021-11-19drm/i915: Create a full object for mock_ring, v2.Maarten Lankhorst1-10/+28
This allows us to finally get rid of all the assumptions that vma->obj is NULL. Changes since v1: - Ensure the mock_ring vma is pinned to prevent a fault. - Pin it high to avoid failure in evict_for_vma selftest. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-3-matthew.auld@intel.com
2021-11-19drm/i915: Create a dummy object for gen6 ppgttMaarten Lankhorst4-72/+100
We currently have to special case vma->obj being NULL because of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon be able to remove a few checks. As the object only exists as a fake object pointing to ggtt, we have no backing storage, so no real object is created. It just has to look real enough. Also kill pin_mutex, it's not compatible with ww locking, and we can use the vm lock instead. v2: - Drop IS_SHRINKABLE and shorten overly long line v3: - Checkpatch fix for alignment Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-2-matthew.auld@intel.com
2021-11-19drm/i915: move the pre_pin earlierMatthew Auld1-6/+6
In intel_context_do_pin_ww, when calling into the pre_pin hook(which is passed the ww context) it could in theory return -EDEADLK(which is very likely with debug kernels), once we start adding more ww locking in there, like in the next patch. If so then we need to be mindful of having to restart the do_pin at this point. If this is the kernel_context, or some other early in-kernel context where we have yet to setup the default_state, then we always inhibit the context restore, and instead rely on the delayed active_release to set the CONTEXT_VALID_BIT for us(if we even care), which should indicate that we have context switched away, and that our newly saved context state should now be valid. However, since we currently grab the active reference before the potential ww dance, we can end up setting the CONTEXT_VALID_BIT much too early, if we need to backoff, and then upon re-trying the do_pin, we could potentially cause the hardware to incorrectly load some garbage context state when later context switching to that context, but at the very least this will trigger the GEM_BUG_ON() in __engine_unpark. For now let's just move any ww dance stuff prior to arming the active reference. For normal user contexts this shouldn't be a concern, since we should already have the default_state ready when initialising the lrc state, and so there should be no concern with active_release somehow prematurely setting the CONTEXT_VALID_BIT. v2(Thomas): - Also re-order the onion unwind Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-1-matthew.auld@intel.com
2021-11-19drm/i915/dg2: Implement WM0 cursor WA for DG2Stanislav Lisovskiy1-5/+13
Bug in the register unit which results in WM1 register used when only WM0 is enabled on cursor. Software workaround is when only WM0 enabled on cursor, copy contents of CUR_WM_0[30:0] (exclude the enable bit) into CUR_WM_1[30:0]. v2: - s/dev_priv/i915/ (Ville Syrjälä) - Removed unneeded brackets (Ville Syrjälä) HSDES: 14012656716 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211118093907.18510-1-stanislav.lisovskiy@intel.com
2021-11-19drm/i915/pxp: fix includes for headers in include/drmJani Nikula2-3/+6
Use <> not "" for including headers from include/drm. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116135813.19806-1-jani.nikula@intel.com
2021-11-19drm/i915: drop intel_display.h include from intel_display_power.hJani Nikula1-1/+2
Use forward declarations instead. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-5-jani.nikula@intel.com
2021-11-19drm/i915: move structs from intel_display_power.h to .cJani Nikula2-94/+93
Anything internal to the implementation should be hidden away. Move the intel_display_power structs to the .c file. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-4-jani.nikula@intel.com
2021-11-19drm/i915/debugfs: move debug printing to intel_display_power.cJani Nikula3-21/+29
The debugfs should have no special privileges to look into the implementation guts. Move the actual debug printing of power domains to intel_display_power.c. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-3-jani.nikula@intel.com
2021-11-19drm/i915: drop intel_display.h include from intel_dpll_mgr.hJani Nikula1-1/+1
Use forward declarations instead. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-2-jani.nikula@intel.com
2021-11-19drm/i915: drop intel_display.h include from intel_ddi.hJani Nikula1-1/+3
Use forward declarations instead. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-1-jani.nikula@intel.com
2021-11-19drm/i915: Clean up CRC register definesVille Syrjälä1-36/+41
Use REG_BIT() & co. for the CRC registers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-8-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-19drm/i915: Clean up DPINVGTT/VLV_DPFLIPSTAT bitsVille Syrjälä2-48/+48
Use REG_BIT() & co. for DPINVTT/VLV_DPFLIPSTAT bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-9-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-19drm/i915: Clean up FPGA_DBG/CLAIM_ER bitsVille Syrjälä1-4/+4
Use REG_BIT() & co. for FPGA_DBG/CLAIM_ER bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-10-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-18drm/i915/: Extend VRR platform support to Gen 11Manasi Navare1-1/+1
VRR is supported on Gen 11 HW , hence extend the support in the driver to enable this for Gen 11. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116231209.28621-1-manasi.d.navare@intel.com
2021-11-18drm/i915: Disable DSB usage for nowVille Syrjälä1-1/+1
Turns out the DSB has trouble correctly loading the gamma LUT. From a cursory look maybe like some entries do not load properly, or they get loaded with some gibberish. Unfortunately our current kms_color/etc. tests do not seem to catch this. I had a brief look at the generated DSB batch and it looked correct. Tried a few quick tricks like writing the index register twice/etc. but didn't see any improvement. Also tried switching to the 10bit gamma mode in case there is yet another issue with the multi-segment mode, but even the 10bit mode was showing issues. Switching to mmio fixes all of it. I suppose one theory is that maybe the DSB bangs on the LUT too quickly and it can't keep up and instead some data either gets dropped or corrupted. To confirm that someone should try to slow down the DSB's progress a bit. Another thought was that maybe the LUT has crappy dual porting and you get contention if you try to load it during active scanout. But why then would the mmio path work, unless it's just sufficiently slow? Whatever the case, this is currently busted so let's disable it until we get to the root of the problem. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3916 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014181856.17581-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2021-11-18drm/i915: Declare .(de)gamma_lut_tests for icl+Ville Syrjälä1-1/+7
All interpolated gamma modes including the icl+ multi segment mode require non-decreasing entries for the interpolation to work correctly. For some reason we're forgetting to declare that for icl+. Let us do so. References: https://gitlab.freedesktop.org/drm/intel/-/issues/3916 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014181856.17581-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2021-11-18drm/i915: Fix framestart_delay commens in VRR codeVille Syrjälä1-3/+3
Since I originally wrote these comments we decided to change our definition of framestart_delay from 0-3 to 1-4. Adjust the comments to match that new convention. The actual code was adjusted already. Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-3-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2021-11-18drm/i915: Do vblank evasion correctly if vrr push has already been sentVille Syrjälä3-3/+20
Let's adjust the vblank evasion to account for the case where a push has already been sent. In that case the vblank exit will start at vmin vblank start (as opposed to vmax vblank start when no push has been sent). This should minimize the effects of the tiny race between sampling the frame counter vs. intel_vrr_send_push() during the previous frame. This will also be required if we want to do mailbox style updates with vrr since then we'd definitely do multiple commits per frame. Currently mailbox updates are only used by the legacy cursor, but we don't do vrr push for those. Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2021-11-18drm/i915: Move vrr push after the frame counter sampling againVille Syrjälä1-3/+16
Moving the vrr push to happen before sampling the frame counter was wrong. If we are already in vblank when the push is sent the vblank exit will start immediately which causes the sampled frame counter to correspond to the next frame instead of the current frame. So put things back into the original order (except we should keep the vrr push within the irq disable section to avoid pointless irq related delays here). We'll just have to accept the tiny race that exists between sampling the frame counter vs. vrr push. And let's at least document said race properly in a comment. I suppose we could try to minimize the race by sampling the frame counter just before sending the push, but that would require changing drm_crtc_arm_vblank_event() to accept a caller provided vblank counter value, so leave it be for now. Another thing we could do is change the vblank evasion to account for the case where a push was already sent. That would anyway be required for mailbox style updates. Currently mailbox updates are only used by the legacy cursor, but we don't do a vrr push for those. Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 6f9976bd1310 ("drm/i915: Do vrr push before sampling the frame counter") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2021-11-18drm/i915/vlv_dsi: Double pixelclock on read-back for dual-link panelsHans de Goede1-0/+5
In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk() for dual-link panels. This fixes the following WARN triggering: i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in pixel_rate (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.pipe_mode.crtc_clock (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.adjusted_mode.crtc_clock (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in port_clock (expected 235710, found 118056) ------------[ cut here ]------------ pipe state doesn't match! WARNING: CPU: 3 PID: 136 at drivers/gpu/drm/i915/display/intel_display.c:9125 intel_display_finish_reset+0x1bd3/0x2050 [i915] ... This has been tested on a Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC) tablet, with a 1536x2048 dual-link DSI panel. Note this fix was taken from icl_dsi.c which does the same in its get_config(). Cc: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211024155020.126328-1-hdegoede@redhat.com
2021-11-18Merge drm/drm-next into drm-misc-nextThomas Zimmermann21-135/+175
Backmerging from drm/drm-next for v5.16-rc1. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2021-11-17drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()Lyude Paul1-5/+11
Hooray! We've managed to hit enough bugs upstream that I've been able to come up with a pretty solid explanation for how backlight controls are actually supposed to be detected and used these days. As well, having the rest of the PWM bits in VESA's backlight interface implemented seems to have fixed all of the problematic brightness controls laptop panels that we've hit so far. So, let's actually document this instead of just calling the laptop panels liars. As well, I would like to formally apologize to all of the laptop panels I called liars. I'm sorry laptop panels, hopefully you can all forgive me and we can move past this~ Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211105183342.130810-6-lyude@redhat.com
2021-11-17drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness controlLyude Paul1-10/+34
Now that we've added support to i915 for controlling panel backlights that need PWM to be enabled/disabled, let's finalize this and add support for controlling brightness levels via PWM as well. This should hopefully put us towards the path of supporting _ALL_ backlights via VESA's DPCD interface which would allow us to finally start trusting the DPCD again. Note however that we still don't enable using this by default on i915 when it's not needed, primarily because I haven't yet had a chance to confirm if it's safe to do this on the one machine in Intel's CI that had an issue with this: samus-fi-bdw. I have done basic testing of this on other machines though, by manually patching i915 to force it into PWM-only mode on some of my laptops. v2: * Correct documentation (thanks Doug!) * Get rid of backlight caps Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Cc: Rajeev Nandan <rajeevny@codeaurora.org> Cc: Satadru Pramanik <satadru@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211105183342.130810-5-lyude@redhat.com
2021-11-17drm/i915: Add support for panels with VESA backlights with PWM enable/disableLyude Paul1-6/+21
This simply adds proper support for panel backlights that can be controlled via VESA's backlight control protocol, but which also require that we enable and disable the backlight via PWM instead of via the DPCD interface. We also enable this by default, in order to fix some people's backlights that were broken by not having this enabled. For reference, backlights that require this and use VESA's backlight interface tend to be laptops with hybrid GPUs, but this very well may change in the future. v4: * Make sure that we call intel_backlight_level_to_pwm() in intel_dp_aux_vesa_enable_backlight() - vsyrjala Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680 Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM enable/disable") Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Link: https://patchwork.freedesktop.org/patch/msgid/20211105183342.130810-2-lyude@redhat.com
2021-11-17drm/i915: Fix fastsets on TypeC ports following a non-blocking modesetImre Deak1-5/+26
After a non-blocking modeset on a TypeC port's CRTC - possibly blocked later in drm_atomic_helper_wait_for_dependencies() - a fastset on the same CRTC may copy the state of CRTC before this gets updated to reflect the up-to-date DP-alt vs. TBT-alt TypeC mode DPLL used for the CRTC. In this case after the first (non-blocking) commit completes enabling the DPLL required for the up-to-date TypeC mode the following fastset will update the CRTC state pointing to the wrong DPLL. A subsequent disabling modeset will try to disable the wrong PLL, triggering a state checker WARN (and leaving the DPLL which is actually used active for good). Fix the above race by copying the DPLL state for fastset CRTCs from the old CRTC state at the point where it's guaranteed to be up-to-date already. This could be handled in the encoder's update_prepare() hook as well, but that's a bigger change, which is better done as a follow-up. v2: Copy dpll_hw_state as well. (Ville) Testcase: igt/kms_busy/extended-modeset-hang-newfb-with-reset Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4308 Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211115181121.156197-1-imre.deak@intel.com
2021-11-17drm/i915/guc: fix NULL vs IS_ERR() checkingDan Carpenter1-2/+2
The intel_engine_create_virtual() function does not return NULL. It returns error pointers. Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116114916.GB11936@kili
2021-11-17drm/i915/guc: fix NULL vs IS_ERR() checkingDan Carpenter1-2/+2
The intel_engine_create_virtual() function does not return NULL. It returns error pointers. Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116114916.GB11936@kili (cherry picked from commit fc12b70d12d07598cde27cc17dbfafc2a2a33ff8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-17drm/i915/dsi/xelpd: Fix the bit mask for wakeup GBVandita Kulkarni2-2/+5
v2: Fix the typo, move out the hardcoding from macro(Jani, Ville) Fixes: f87c46c43175 ("drm/i915/dsi/xelpd: Add WA to program LP to HS wakeup guardband") Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211019151435.20477-2-vandita.kulkarni@intel.com (cherry picked from commit 6f07707fa09e1dc58c431d57c25ef2e68b9bec47) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-17Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"Vandita Kulkarni1-8/+2
This reverts commit 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"). The Bspec was updated recently with the pll ungate sequence similar to that of icl dsi enable sequence. Hence reverting. Bspec: 49187 Fixes: 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping") Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211109120428.15211-1-vandita.kulkarni@intel.com (cherry picked from commit 4579509ef181480f4e4510d436c691519167c5c2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-17drm/i915: use new iterator in i915_gem_object_wait_reservationChristian König1-44/+19
Simplifying the code a bit. Signed-off-by: Christian König <christian.koenig@amd.com> [mlankhorst: Handle timeout = 0 correctly, use new i915_request_wait_timeout.] Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211116102431.198905-7-christian.koenig@amd.com
2021-11-17drm/i915: Fix i915_request fence wait semanticsMaarten Lankhorst2-10/+52
The i915_request fence wait behaves differently for timeout = 0 compared to expected dma-fence behavior. i915 behavior: - Unsignaled: -ETIME - Signaled: 0 (= timeout) Expected: - Unsignaled: 0 - Signaled: 1 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116102431.198905-6-christian.koenig@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-11-17drm/i915: use new cursor in intel_prepare_plane_fb v2Christian König1-3/+4
Simplifying the code a bit. v2: rebased Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211116102431.198905-5-christian.koenig@amd.com
2021-11-17drm/i915: use the new iterator in i915_sw_fence_await_reservation v3Christian König1-42/+11
Simplifying the code a bit. v2: use dma_resv_for_each_fence instead, according to Tvrtko the lock is held here anyway. v3: back to using dma_resv_for_each_fence_unlocked. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211116102431.198905-4-christian.koenig@amd.com
2021-11-17drm/i915: use new iterator in i915_gem_object_wait_priorityChristian König1-25/+6
Simplifying the code a bit. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211116102431.198905-3-christian.koenig@amd.com
2021-11-17drm/i915: use the new iterator in i915_gem_busy_ioctl v2Christian König1-20/+13
This makes the function much simpler since the complex retry logic is now handled else where. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211116102431.198905-2-christian.koenig@amd.com
2021-11-17drm/i915/driver: add i915_driver_ prefix to functionsJani Nikula3-6/+7
Add the i915_driver_ prefix to the switcheroo functions in i915_driver.[ch]. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211111101304.13094-3-jani.nikula@intel.com
2021-11-17drm/i915/driver: rename driver to i915_drm_driverJani Nikula1-3/+3
As a name, "driver" is too generic and short to be easily located in a file this size. Rename it to i915_drm_driver. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211111101304.13094-2-jani.nikula@intel.com
2021-11-17drm/i915/driver: rename i915_drv.c to i915_driver.cJani Nikula6-13/+31
This is more about trimming i915_drv.h than the renamed i915_driver.[ch]. Split out i915_driver.[ch] out of i915_drv.h as a feasible thing to do. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211111101304.13094-1-jani.nikula@intel.com
2021-11-16drm/i915/guc: fix NULL vs IS_ERR() checkingDan Carpenter1-2/+2
The intel_engine_create_virtual() function does not return NULL. It returns error pointers. Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116114916.GB11936@kili
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.