- 21 Jan, 2021 2 commits
-
-
Jani Nikula authored
intel_display.c has some pps functions that belong to intel_pps.c. Move them over. While at it, refactor the duplicate intel_pps_init() in intel_display.c into an orthogonal intel_pps_setup() in intel_pps.c, and call it earlier in intel_modeset_init_nogem(). Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210120101834.19813-2-jani.nikula@intel.com
-
Jani Nikula authored
Once you realize there is no need to hold the pps mutex when calling pps_init_timestamps() in intel_pps_init(), we can reuse intel_pps_encoder_reset() which has the same code. Since intel_dp_pps_init() is only called from one place now, move it inline to remove one "init" function altogether. Finally, remove some initialization from vlv_initial_power_sequencer_setup() and do it in the caller to highlight the similarity, not the difference, in the platforms. v2: Fix comment (Anshuman) Reviewed-by:
-
- 19 Jan, 2021 12 commits
-
-
Lyude Paul authored
This reverts commit 0883ce81. Originally these quirks were added because of the issues with using the eDP backlight interfaces on certain laptop panels, which made it impossible to properly probe for DPCD backlight support without having a whitelist for panels that we know have working VESA backlight control interfaces over DPCD. As well, it should be noted it was impossible to use the normal sink OUI for recognizing these panels as none of them actually filled out their OUIs, hence needing to resort to checking EDIDs. At the time we weren't really sure why certain panels had issues with DPCD backlight controls, but we eventually figured out that there was a second interface that these problematic laptop panels actually did work with and advertise properly: Intel's proprietary backlight interface for HDR panels. So far the testing we've done hasn't brought any panels to light that advertise this interface and don't support it properly, which means we finally have a real solution to this problem. As a result, we now have no need for the force DPCD backlight quirk, and furthermore this also removes the need for any kind of EDID quirk checking in DRM. So, let's just revert it for now since we were the only driver using this. v3: * Rebase v2: * Fix indenting error picked up by checkpatch in intel_edp_init_connector() Signed-off-by:
Lyude Paul <lyude@redhat.com> Acked-by:
-
Lyude Paul authored
Since we now support controlling panel backlights through DPCD using both the standard VESA interface, and Intel's proprietary HDR backlight interface, we should allow the user to be able to explicitly choose between one or the other in the event that we're wrong about panels reliably reporting support for the Intel HDR interface. So, this commit adds support for this by introducing two new enable_dpcd_backlight options: 2 which forces i915 to only probe for the VESA interface, and 3 which forces i915 to only probe for the Intel backlight interface (might be useful if we find panels in the wild that report the VESA interface in their VBT, but actually only support the Intel backlight interface). v3: * Rebase Signed-off-by:
-
Lyude Paul authored
So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() Signed-off-by:
-
Lyude Paul authored
Currently, every different type of backlight hook that i915 supports is pretty straight forward - you have a backlight, probably through PWM (but maybe DPCD), with a single set of platform-specific hooks that are used for controlling it. HDR backlights, in particular VESA and Intel's HDR backlight implementations, can end up being more complicated. With Intel's proprietary interface, HDR backlight controls always run through the DPCD. When the backlight is in SDR backlight mode however, the driver may need to bypass the TCON and control the backlight directly through PWM. So, in order to support this we'll need to split our backlight callbacks into two groups: a set of high-level backlight control callbacks in intel_panel, and an additional set of pwm-specific backlight control callbacks. This also implies a functional changes for how these callbacks are used: * We now keep track of two separate backlight level ranges, one for the high-level backlight, and one for the pwm backlight range * We also keep track of backlight enablement and PWM backlight enablement separately * Since the currently set backlight level might not be the same as the currently programmed PWM backlight level, we stop setting panel->backlight.level with the currently programmed PWM backlight level in panel->backlight.pwm_funcs->setup(). Instead, we rely on the higher level backlight control functions to retrieve the current PWM backlight level (in this case, intel_pwm_get_backlight()). Note that there are still a few PWM backlight setup callbacks that do actually need to retrieve the current PWM backlight level, although we no longer save this value in panel->backlight.level like before. Additionally, we drop the call to lpt_get_backlight() in lpt_setup_backlight(), and avoid unconditionally writing the PWM value that we get from it and only write it back if we're in CPU mode, and switching to PCH mode. The reason for this is because in the original codepath for this, it was expected that the intel_panel_bl_funcs->setup() hook would be responsible for fetching the initial backlight level. On lpt systems, the only time we could ever be in PCH backlight mode is during the initial driver load - meaning that outside of the setup() hook, lpt_get_backlight() will always be the callback used for retrieving the current backlight level. After this patch we still need to fetch and write-back the PCH backlight value if we're switching from CPU mode to PCH, but because intel_pwm_setup_backlight() will retrieve the backlight level after setup() using the get() hook, which always ends up being lpt_get_backlight(). Thus - an additional call to lpt_get_backlight() in lpt_setup_backlight() is made redundant. v9: * Drop the intel_panel_invert_pwm_level() call in lpt_setup_backlight() * Remove leftover detritus from lpt_setup_backlight() v8: * Go back to getting initial brightness level with intel_pwm_get_backlight(), the other fix we had was definitely wrong. v7: * Use panel->backlight.pwm_funcs->get() to get the backlight level in intel_pwm_setup_backlight(), lest we upset lockdep * Rebase * Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level() v6: * Make sure to grab connection_mutex before calling intel_pwm_get_backlight() in intel_pwm_setup_backlight() v5: * Fix indenting warnings from checkpatch v4: * Fix commit message * Remove outdated comment in intel_panel.c * Rename pwm_(min|max) to pwm_level_(min|max) * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of indirection * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of intel_panel_init_backlight_funcs() quite yet v3: * Reuse intel_panel_bl_funcs() for pwm_funcs * Explain why we drop lpt_get_backlight() Signed-off-by:
-
Ville Syrjälä authored
On some platforms we need to trigger an extra async flip with the async flip bit disabled, and then wait for the next vblank until the async flip bit off state will actually latch. Currently the w/a is just open coded for skl+ universal planes. Instead of doing that lets reuse the .async_flip() hook for this purpose since it needs to write the exact same set of registers. In order to do this we'll just have the caller pass in the state of the async flip bit explicitly. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-8-ville.syrjala@linux.intel.comReviewed-by:
Karthik B S <karthik.b.s@intel.com>
-
Ville Syrjälä authored
Set up the async flip PLANE_CTL bit directly in the .async_flip() hook. Neither .update_plane() nor .disable_plane() ever need to set this so having it done by skl_plane_ctl_crtc() is rather pointless. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Prepare for more platforms with async flip support by turning the flip_done interrupt enable/disable into plane vfuncs. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Only assign the plane->async_flip() vfunc when the plane supports async flips. For now we keep this artificially limited to the primary plane since thats the only thing the legacy page flip uapi can target and there is no async flip support in the atomic uapi yet. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Drop the pointless extra parens. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
I accidentally added the compliance test hacks only to intel_dp_hotplug() which doesn't even get used on any DDI platform. Put the same crap into intel_ddi_hotplug(). Cc: Imre Deak <imre.deak@intel.com> Fixes: 193af12c ("drm/i915: Shove the PHY test into the hotplug work") Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Currently we claim to use TPS7 when using TPS4. That is just confusing, so let's fix the debug print. And while we're touching this let's add the customary encoder id/name as well. v2: Add MISSING_CASE() (Manasi) Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
DP spec says: "The Source device shall start sending the idle pattern after it has cleared the Training_Pattern byte in the DPCD." Currently we do these in operations in the opposite order. Swap them around to match the spec. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
- 18 Jan, 2021 1 commit
-
-
Lee Shawn C authored
There are two CSC on pipeline on gen11 and later platform. User space application is allowed to enable CTM and RGB to YCbCr coversion at the same time now. v2: check csc capability in {}_color_check function. v3: can't support two CSC at the same time in {ivb,glk}_color_check. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Shankar Uma <uma.shankar@intel.com> Signed-off-by:Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
-
- 15 Jan, 2021 10 commits
-
-
Rodrigo Vivi authored
Syncing drm-intel-next and drm-intel-gt-next to unblock ADL enabling. Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Dave Airlie authored
This just refactors out the fdi code to a separate file. Signed-off-by:
Dave Airlie <airlied@redhat.com> [Jani: cleaned up intel_fdi.h a bit.] Signed-off-by:
-
Dave Airlie authored
This pulls a large chunk of the pll calculation code out of intel_display.c to a new file. One function makes sense to be an inline, otherwise this is pretty much a straight copy cover. Also all the remaining hooks for g45 and older end up the same now. Signed-off-by:
-
Dave Airlie authored
There may be more crtc code that can be pulled out, but this is a good start. v2: move plane before this. Signed-off-by:
-
Ville Syrjälä authored
Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're actually outputting YCbCr 4:4:4. It would appear some protocol converters blindy consult this bit even when the source is outputting RGB, resulting in a visual mess. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2914Signed-off-by:
-
Lyude Paul authored
In the next commit where we split PWM related backlight functions from higher-level backlight functions, we'll want to be able to retrieve the backlight level for the current display panel from the intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since intel_panel_bl_funcs->setup() is called before we've fully read in the current hardware state into our atomic state, we can't grab atomic modesetting locks safely anyway in intel_panel_bl_funcs->setup(), and some PWM backlight functions (vlv_get_backlight() in particular) require knowing the currently used pipe we need to be able to discern the current display pipe through other means. Luckily, we're already passing the current display pipe to intel_panel_bl_funcs->setup() so all we have to do in order to achieve this is pass down that parameter to intel_panel_bl_funcs->get(). So, fix this by accepting an additional pipe parameter in intel_panel_bl_funcs->get(), and leave figuring out the current display pipe up to the caller. Signed-off-by:
-
Zhenyu Wang authored
Some vmm like hyperv and crosvm don't supply any ISA bridge to their guest, when igd passthrough is equipped on these vmm, guest i915 display may couldn't work as guest i915 detects PCH_NONE pch type. When i915 runs as guest, this patch guess pch type through gpu type even without ISA bridge. v2: Fix CI warning v3: Add HAS_DISPLAY()= true condition beforce guessing virt pch, then refactori. v4: Fix CI warning Signed-off-by:Zhenyu Wang <zhenyuw@linux.intel.com> Co-developed-by:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op? drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op? drivers/gpu/drm/i915/display/intel_dp.c:6923 intel_dp_update_420() warn: should this be a bitwise op? Inside drm_dp_downstream_rgb_to_ycbcr_conversion(), that parameter 'color_spc' is used as return port_cap[3] & color_spc, implying that it is indeed a mask and not a boolean value. Fixes: 522508b6 ("drm/i915/display: Let PCON convert from RGB to YCbCr if it can") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2021-01-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - Deprecate I915_PMU_LAST and optimize state tracking (Tvrtko) Avoid relying on last item ABI marker in i915_drm.h, add a comment to mark as deprecated. Cross-subsystem Changes: Core Changes: Driver Changes: - Restore clear residuals security mitigations for Ivybridge and Baytrail (Chris) - Close #1858: Allow sysadmin to choose applied GPU security mitigations through i915.mitigations=... similar to CPU (Chris) - Fix for #2024: GPU hangs on HSW GT1 (Chris) - Fix for #2707: Driver hang when editing UVs in Blender (Chris, Ville) - Fix for #2797: False positive GuC loading error message (Chris) - Fix for #2859: Missing GuC firmware for older Cometlakes (Chris) - Lessen probability of GPU hang due to DMAR faults [reason 7, next page table ptr is invalid] on Tigerlake (Chris) - Fix REVID macros for TGL to fetch correct stepping (Aditya) - Limit frequency drop to RPe on parking (Chris, Edward) - Limit W/A 1406941453 to TGL, RKL and DG1 (Swathi) - Make W/A 22010271021 permanent on DG1 (Lucas) - Implement W/A 16011163337 to prevent a HS/DS hang on DG1 (Swathi) - Only disable preemption on gen8 render engines (Chris) - Disable arbitration around Braswell's PDP updates (Chris) - Disable arbitration on no-preempt requests (Chris) - Check for arbitration after writing start seqno before busywaiting (Chris) - Retain default context state across shrinking (Venkata, CQ) - Fix mismatch between misplaced vma check and vma insert for 32-bit addressing userspaces (Chris, CQ) - Propagate error for vmap() failure instead kernel NULL deref (Chris) - Propagate error from cancelled submit due to context closure immediately (Chris) - Fix RCU race on HWSP tracking per request (Chris) - Clear CMD parser shadow and GPU reloc batches (Matt A) - Populate logical context during first pin (Maarten) - Optimistically prune dma-resv from the shrinker (Chris) - Fix for virtual engine ownership race (Chris) - Remove timeslice suppression to restore fairness for virtual engines (Chris) - Rearrange IVB/HSW workarounds properly between GT and engine (Chris) - Taint the reset mutex with the shrinker (Chris) - Replace direct submit with direct call to tasklet (Chris) - Multiple corrections to virtual engine dequeue and breadcrumbs code (Chris) - Avoid wakeref from potentially hard IRQ context in PMU (Tvrtko) - Use raw clock for RC6 time estimation in PMU (Tvrtko) - Differentiate OOM failures from invalid map types (Chris) - Fix Gen9 to have 64 MOCS entries similar to Gen11 (Chris) - Ignore repeated attempts to suspend request flow across reset (Chris) - Remove livelock from "do_idle_maps" VT-d W/A (Chris) - Cancel the preemption timeout early in case engine reset fails (Chris) - Code flow optimization in the scheduling code (Chris) - Clear the execlists timers upon reset (Chris) - Drain the breadcrumbs just once (Chris, Matt A) - Track the overall GT awake/busy time (Chris) - Tweak submission tasklet flushing to avoid starvation (Chris) - Track timelines created using the HWSP to restore on resume (Chris) - Use cmpxchg64 for 32b compatilibity for active tracking (Chris) - Prefer recycling an idle GGTT fence to avoid GPU wait (Chris) - Restructure GT code organization for clearer split between GuC and execlists (Chris, Daniele, John, Matt A) - Remove GuC code that will remain unused by new interfaces (Matt B) - Restructure the CS timestamp clocks code to local to GT (Chris) - Fix error return paths in perf code (Zhang) - Replace idr_init() by idr_init_base() in perf (Deepak) - Fix shmem_pin_map error path (Colin) - Drop redundant free_work worker for GEM contexts (Chris, Mika) - Increase readability and understandability of intel_workarounds.c (Lucas) - Defer enabling the breadcrumb interrupt to after submission (Chris) - Deal with buddy alloc block sizes beyond 4G (Venkata, Chris) - Encode fence specific waitqueue behaviour into the wait.flags (Chris) - Don't cancel the breadcrumb interrupt shadow too early (Chris) - Cancel submitted requests upon context reset (Chris) - Use correct locks in GuC code (Tvrtko) - Prevent use of engine->wa_ctx after error (Chris, Matt R) - Fix build warning on 32-bit (Arnd) - Avoid memory leak if platform would have more than 16 W/A (Tvrtko) - Avoid unnecessary #if CONFIG_PM in PMU code (Chris, Tvrtko) - Improve debugging output (Chris, Tvrtko, Matt R) - Make file local variables static (Jani) - Avoid uint*_t types in i915 (Jani) - Selftest improvements (Chris, Matt A, Dan) - Documentation fixes (Chris, Jose) Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
- PSR fixes and improvements for selective fetch (Jose) - GVT build fixed and cleanup (Jani) - RKL display fixes (Lee, Matt) - DSI fix (Hans) - Panel Power and Backlight fixes (Anshuman, Jani) - RPM fix (Chris) - Fix HTI port checking (Jose) - Clean-up in cursor code (Ville) - Once again, trying to use fast+narrow link on eDP (Ville) - DG1 display fix (Matt) Signed-off-by:
-
- 14 Jan, 2021 15 commits
-
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.12-2021-01-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.12-2021-01-08: amdgpu: - Rework IH ring handling on vega and navi - Rework HDP handling for vega and navi - swSMU documenation updates - Overdrive support for Sienna Cichlid and newer asics - swSMU updates for vangogh - swSMU updates for renoir - Enable FP16 on DCE8-11 - Misc code cleanups and bug fixes radeon: - Fixes for platforms that can't access PCI resources correctly - Misc code cleanups From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108221811.3868-1-alexander.deucher@amd.comSigned-off-by:
-
Ville Syrjälä authored
We dropped the other redundant master_transcoder assignments earlier, but this one slipped through. Get rid of it as well. The crtc state gets fully reset before readout so there is no point in doing this. Signed-off-by:
-
José Roberto de Souza authored
DG1 is missing those two WA so instead of copy and paste it to the DG1 function, here calling the function that implements it. While at it also renaming tgl_init_clock_gating to gen12lp_init_clock_gating as it is also used by DG1, RKL and ADL-S. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210113133759.72055-1-jose.souza@intel.com
-
Jani Nikula authored
Always prefer the kernel types over stdint types in i915. Reviewed-by:
-
Jani Nikula authored
There are a number of functions that "init" pps in various ways. Try to find some more consistency in the naming. Rename: - intel_dp_init_panel_power_sequencer -> pps_init_delays - intel_dp_init_panel_power_sequencer_registers -> pps_init_registers - intel_dp_init_panel_power_timestamps -> pps_init_timestamps as this is what the functions do. Skip the intel_ prefix here to emphasize these are static and not exported. No functional changes. Reviewed-by:
-
Jani Nikula authored
This function is a bit of an outlier, but try to change to a name that is more in line with the rest of the intel_pps functions. No functional changes. Reviewed-by:
-
Jani Nikula authored
Prefer keeping the unlocked variants hidden if possible. No functional changes. Reviewed-by:
-
Jani Nikula authored
Follow the usual naming pattern for functions. "reset all" because it iterates over all DP encoders. No functional changes. Reviewed-by:
-
Jani Nikula authored
Follow the usual naming pattern for functions. No functional changes. Reviewed-by:
-
Jani Nikula authored
Add an "encoder reset" call to hide some more pps functions, and clean up the callers. A minor functional change is not holding the pps lock across the whole operation in intel_dp_encoder_reset, but instead doing it in two steps. v2: rename intel_pps_reinit to intel_pps_encoder_reset for clarity Reviewed-by:
-
Jani Nikula authored
Add a new init call to be called only once, unlike some of the other various init calls. This lets us hide more functions within intel_pps.c. No functional changes. Reviewed-by:
-
Jani Nikula authored
Add a locked version of intel_pps_vdd_off_sync_unlocked() that does everything the callers expect it to. No functional changes. v2: Fix typo (Anshuman) Reviewed-by:
-
Jani Nikula authored
Follow the usual naming pattern for functions, both for the prefix and the _unlocked suffix for functions that expect the lock to be held when calling. No functional changes. Reviewed-by:
-
Jani Nikula authored
Follow the usual naming pattern for functions. We don't need to repeat "panel" here. No functional changes. v2: Fix comment (Anshuman) Reviewed-by:
-
Jani Nikula authored
Follow the usual naming pattern for functions. No functional changes. Reviewed-by:
-
