#
a4efae87 |
|
20-Feb-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Compute DP tunnel BW during encoder state computation Compute the BW required through a DP tunnel on links with such tunnels detected and add the corresponding atomic state during a modeset. v2: - Fix error check of intel_dp_tunnel_compute_stream_bw(). (Ville) - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to this patch. (Ville) - Move intel_dp_tunnel_atomic_clear_stream_bw() to this patch. Reviewed-by: Uma Shankar <uma.shankar@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-16-imre.deak@intel.com
|
#
39818c06 |
|
20-Feb-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Add DP tunnel atomic state and check BW limit Add the atomic state during a modeset required to enable the DP tunnel BW allocation mode on links where such a tunnel was detected. This state applies to an already enabled output, the state added for a newly enabled output will be computed and added/cleared to/from the atomic state in a follow-up patch. v2: - s/old_crtc_state/crtc_state in intel_crtc_duplicate_state(). - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up patch adding the corresponding state. (Ville) - Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up patch adding the corresponding state. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-14-imre.deak@intel.com
|
#
91888b5b |
|
26-Feb-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Add support for DP tunnel BW allocation Add support to enable the DP tunnel BW allocation mode. Follow-up patches will call the required helpers added here to prepare for a modeset on a link with DP tunnels, the last change in the patchset actually enabling BWA. With BWA enabled, the driver will expose the full mode list a display supports, regardless of any BW limitation on a shared (Thunderbolt) link. Such BW limits will be checked against only during a modeset, when the driver has the full knowledge of each display's BW requirement. If the link BW changes in a way that a connector's modelist may also change, userspace will get a hotplug notification for all the connectors sharing the same link (so it can adjust the mode used for a display). The BW limitation can change at any point, asynchronously to modesets on a given connector, so a modeset can fail even though the atomic check for it passed. In such scenarios userspace will get a bad link notification and in response is supposed to retry the modeset. v2: - Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state(). (Ville) - Fix propagating the error from intel_dp_tunnel_atomic_compute_stream_bw(). (Ville) - Move tunnel==NULL checks from driver to DRM core helpers. (Ville) - Simplify return flow from intel_dp_tunnel_detect(). (Ville) - s/dp_tunnel_state/inherited_dp_tunnels (Ville) - Simplify struct intel_dp_tunnel_inherited_state. (Ville) - Unconstify object pointers (vs. states) where possible. (Ville) - Init crtc_state while declaring it in check_group_state(). (Ville) - Join obj->base.id, obj->name arg lines in debug prints to reduce LOC. (Ville) - Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the BW allocation from encoder hooks up to intel_atomic_commit_tail() later in the patchset. - Disable BW alloc mode during system suspend. - Allocate the required BW for all tunnels during system resume. - Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded sequence in a follow-up patch. - Add function documentation to all exported functions. - Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL. v3: - Rebase on intel_dp_get_active_pipes() change in previous patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226185246.1276018-4-imre.deak@intel.com
|
#
d59cf7bb |
|
31-Oct-2023 |
Jouni Högander <jouni.hogander@intel.com> |
drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence implementation. Lets drop i915_sw_fence usage from display code and use dma_fence interfaces directly. For this purpose stack dma fences from related objects into new plane state. Drm_gem_plane_helper_prepare_fb can be used for fences in new fb. Separate local implementation is used for Stacking fences from old fb into new plane state. Then wait for these stacked fences during atomic commit. There is no be need for separate GPU reset handling in intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is detected and GPU is being reset. v4: - Drop to_new_plane_state suffix from add_dma_resv_fences - Use dma_resv_usage_rw(false) (DMA_RESV_USAGE_WRITE) v3: - Rename add_fences and it's parameters - Remove signaled check - Remove waiting old_plane_state fences v2: - Add fences from old fb into new_plane_state->uapi.fence rather than into old_plane_state->uapi.fence Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231031084557.1181630-1-jouni.hogander@intel.com
|
#
16a93594 |
|
15-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement transcoder LRR for TGL+ Implement low refresh rate (LRR) where we change the vblank length by hand as requested, but otherwise keep the timing generator running in non-VRR mode (ie. fixed refresh rate). The panel itself must support VRR for this to work, and only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that we need to make the switch properly. The double buffer latching happens at the start of transcoders undelayed vblank. The other thing that we change is TRANS_VBLANK.VBLANK_END but the hardware entirely ignores that in DP mode. But I decided to keep writing it anyway just to avoid more special cases in readout/state check. v2: Document that TRANS_VBLANK.VBLANK_END is ignored by the hardware v3: Reconcile with VRR fastset Adjust update_lrr flag behaviour Make sure timings stay within VRR range v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi) Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi) TODO: Hook LRR into the automatic DRRS downclocking stuff? Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230915103800.14218-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
|
#
825edc8b |
|
01-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Adjust seamless_m_n flag behaviour Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the flag will only be set if we need to do the seamless M/N update, and in all other cases the flag is cleared. Also rename the flag to update_m_n to make it more clear it's similar to update_pipe. I believe special casing seamless_m_n like this makes sense as it also affects eg. vblank evasion. We can potentially avoid some vblank evasion tricks, simplify some checks, and hopefully will help with the VRR vs. M/N mess. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-6-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
|
#
8976b182 |
|
18-Apr-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Relocate intel_atomic_setup_scalers() Move intel_atomic_setup_scalers() next to the other scaler code in skl_scaler.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
76ec6927 |
|
28-Mar-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Flag purely internal commits to not clear crtc_state->inherited If we have to force the hardware to go through a full modeset due to eg. cdclk reprogramming, we need to preserve crtc_state->inherited for all crtcs that have not otherwise gone through the whole compute_config() stuff after connectors have been detected. Otherwise eg. cdclk induced modeset glk_force_audio_cdclk() will clear the inherited flag, and thus the first real commit coming from userspace later on will not be forced through the full .compute_config() path and so eg. audio state may not get properly recomputed. But instead of adding all kinds of ad-hoc crtc_state->inherited preservation hacks all over, let's change things so that we only clear it for the crtcs directly included in userspace/client initiated commits. Should be far less fragile since now we just need to remember to flag the internal commits, and not worry about where new crtcs might get pulled in. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5260 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230328122357.1697-1-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
#
8d4312e2 |
|
23-Dec-2022 |
Luca Coelho <luciano.coelho@intel.com> |
drm/i915/mtl: limit second scaler vertical scaling in ver >= 14 In newer hardware versions (i.e. display version >= 14), the second scaler doesn't support vertical scaling. The current implementation of the scaling limits is simplified and only occurs when the planes are created, so we don't know which scaler is being used. In order to handle separate scaling limits for horizontal and vertical scaling, and different limits per scaler, split the checks in two phases. We first do a simple check during plane creation and use the best-case scenario (because we don't know the scaler that may be used at a later point) and then do a more specific check when the scalers are actually being set up. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221223130509.43245-2-luciano.coelho@intel.com
|
#
18f1b5ae |
|
24-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce crtc_state->{pre,post}_csc_lut Add an extra remapping step between the logical state of the LUTs (hw.(de)gamma_lut) as specified via uapi/bigjoiner copy vs. the actual state of the LUTs programmed into the hardware. With this we should be finally able finish the (de)gamma readout/state checker support for the remaining platforms (ilk-skl) where the same hardware LUT can be positioned either before or after the pipe CSC unit. Where we position it depends on factors such as presence of the logical degamma LUT, RGB vs. YCbCr output, full vs. limited RGB quantization range. Without the extra remapping step the state readout doesn't really know whether the LUT read from the hardware is the degamma or gamma LUT, and so we is unable to accurately store it into our crtc state. With the remapping step we know exactly where to put it given the order of the LUT vs. CSC in the hardware state. Only the initial hw->uapi state readout done during driver load/resume still has the problem of not really knowing what to do with the LUT(s). But we can just assume 1:1 mapping there and let subsequent commits fix things up. Another benefit is that we now have a place for purely internal LUTs, without complicating the bigjoiner uapi->hw copy logic. This should prove useful for streamlining glk degamma LUT handling. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221024161514.5340-3-ville.syrjala@linux.intel.com
|
#
fe28c7c1 |
|
29-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move and group properties under display.properties Move display property related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/14b14f871e322419b10166c1bd8a5a956f5430c8.1661779055.git.jani.nikula@intel.com
|
#
254e5e88 |
|
20-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm: Remove unnecessary include statements of drm_plane_helper.h Remove the include statement for drm_plane_helper.h from all the files that don't need it. Althogh the header file is almost empty, many drivers include it somewhere. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-5-tzimmermann@suse.de
|
#
2e084371 |
|
13-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix the async flip wm0/ddb optimization The current implementation of the async flip wm0/ddb optimization does not work at all. The biggest problem is that we skip the whole intel_pipe_update_{start,end}() dance and thus never actually complete the commit that is trying to do the wm/ddb change. To fix this we need to move the do_async_flip flag to the crtc state since we handle commits per-pipe, not per-plane. Also since all planes can now be included in the first/last "async flip" (which gets converted to a sync flip to do the wm/ddb mangling) we need to be more careful when checking if the plane state is async flip comptatible. Only planes doing the async flip should be checked and other planes are perfectly fine not adhereing to any async flip related limitations. However for subsequent commits which are actually going do the async flip in hardware we want to make sure no other planes are in the state. That should never happen assuming we did our job correctly, so we'll toss in a WARN to make sure we catch any bugs here. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: c3639f3be480 ("drm/i915: Use wm0 only during async flips for DG2") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
#
5c8107dc |
|
13-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix the async flip wm0/ddb optimization The current implementation of the async flip wm0/ddb optimization does not work at all. The biggest problem is that we skip the whole intel_pipe_update_{start,end}() dance and thus never actually complete the commit that is trying to do the wm/ddb change. To fix this we need to move the do_async_flip flag to the crtc state since we handle commits per-pipe, not per-plane. Also since all planes can now be included in the first/last "async flip" (which gets converted to a sync flip to do the wm/ddb mangling) we need to be more careful when checking if the plane state is async flip comptatible. Only planes doing the async flip should be checked and other planes are perfectly fine not adhereing to any async flip related limitations. However for subsequent commits which are actually going do the async flip in hardware we want to make sure no other planes are in the state. That should never happen assuming we did our job correctly, so we'll toss in a WARN to make sure we catch any bugs here. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: c3639f3be480 ("drm/i915: Use wm0 only during async flips for DG2") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit 2e08437160d1e8f2cd3f0d56d59e74423602116e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
aeb47df3 |
|
04-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up the bigjoiner state copy logic Currently the bigjoiner state copy logic is kind of a byzantine mess. Clean it up to operate in the following manner during a full modeset: 1) master uapi -> hw state copy 2) master hw -> slave hw state copy And during a non-modeset update we do: 1) master uapi -> hw state light copy 2) master hw -> slave hw state light copy I think that is now easier to reason about since we never do any kind of master uapi -> slave hw state copy short circuit that could happen previously. Obviously this does now depend on the master uapi->hw copy always happening before the master hw -> slave hw copy, but that is guaranteed by the fact that we always add both crtcs to the state early, the crtcs are registered in pipe order (so the compute_config loop happens in pipe order), and the hardware requires the master pipe has to be lower than the slave pipe as well. And for good measure we shall add a check+WARN for this before doing the bigjoiner crtc assignment. v2: Fix uapi.ctm vs. hw.ctm copy-paste fail Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204072049.1610-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
ce2fce25 |
|
27-Jan-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Only include i915_reg.h from .c files Several of our i915 header files, have been including i915_reg.h. This means that any change to i915_reg.h will trigger a full rebuild of pretty much every file of the driver, even those that don't have any kind of register access. Let's delete the i915_reg.h include from all headers and add an explicit include from the .c files that truly need the register definitions; those that need a definition of i915_reg_t for a function definition can get it from i915_reg_defs.h instead. We also remove two non-register #define's (VLV_DISPLAY_BASE and GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the i915_reg.h include from a couple of headers. There's probably a lot more header dependency optimization possible, but the changes here roughly cut the number of files compiled after 'touch i915_reg.h' in half --- a good first step. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-7-matthew.d.roper@intel.com
|
#
cce936f4 |
|
13-Dec-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/cdclk: turn around i915_drv.h and intel_cdclk.h dependency intel_cdclk.h only needs i915_drv.h for struct intel_cdclk_config. Move the definition to intel_cdclk.h and turn the includes around to avoid including i915_drv.h from other headers. The intel cdclk state macros in intel_cdclk.h still reference struct drm_i915_private, but as macros they don't strictly require the definition until they are used. v2: Expand on the commit message wrt cdclk state macros Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211213114106.296017-1-jani.nikula@intel.com
|
#
6306d8db |
|
05-Oct-2021 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: Add privacy-screen support (v3) Add support for eDP panels with a built-in privacy screen using the new drm_privacy_screen class. Changes in v3: - Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector() Changes in v2: - Call drm_connector_update_privacy_screen() from intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a for_each_new_connector_in_state() loop to intel_atomic_commit_tail() - Move the probe-deferral check to the intel_modeset_probe_defer() helper Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005202322.700909-11-hdegoede@redhat.com
|
#
f4dc0086 |
|
18-May-2021 |
Vandita Kulkarni <vandita.kulkarni@intel.com> |
drm/i915/adl_p: MBUS programming Update MBUS_CTL register if the 2 mbus can be joined as per the current DDB allocation and active pipes, also update hashing mode and pipe select bits as per the sequence mentioned in the bspec. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-10-lucas.demarchi@intel.com
|
#
72921cdf |
|
30-Apr-2021 |
Maxime Ripard <maxime@cerno.tech> |
drm/connector: Add helper to compare HDR metadata All the drivers that support the HDR metadata property have a similar function to compare the metadata from one connector state to the next, and force a mode change if they differ. All these functions run pretty much the same code, so let's turn it into an helper that can be shared across those drivers. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-2-maxime@cerno.tech
|
#
93e7e61e |
|
12-Apr-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/display: rename display version macros While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
|
#
2b5a4562 |
|
22-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Simplify GLK display version tests GLK has always been a bit of a special case since it reports INTEL_GEN() as 9, but has version 10 display IP. Now we can properly represent the display version as 10 and simplify the display generation tests throughout the display code. Aside from manually adding the version to the glk_info structure, the rest of this patch is generated with a Coccinelle semantic patch. Note that we also need to switch any code that matches gen10 today but *not* GLK to be CNL-specific: @@ expression dev_priv; @@ - DISPLAY_VER(dev_priv) > 9 + DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ ( - DISPLAY_VER(dev_priv) >= 10 && E + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E | - DISPLAY_VER(dev_priv) >= 10 + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) | - IS_DISPLAY_RANGE(dev_priv, 10, E) + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) ) @@ expression dev_priv, E, E2; @@ ( - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) + E || E2 || IS_DISPLAY_VER(dev_priv, 10) | - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_VER(dev_priv, 10) ) @@ expression dev_priv; @@ - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 9) @@ expression dev_priv; @@ ( - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) < 10 | - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10) + E || DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_RANGE(dev_priv, 10, E) @@ expression dev_priv; @@ ( - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || IS_GEN9_LP(dev_priv) + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) | - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - !(DISPLAY_VER(dev_priv) >= E) + DISPLAY_VER(dev_priv) < E v2: - Convert gen10 conditions that don't include GLK into CNL conditions. (Ville) v3: - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." (Ville) v3.1: - Manually re-add the ".display.version = 10" to glk_info after regenerating patch via Coccinelle. v4: - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) Cc: Ville Syrjälä <ville.syrjala@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210322233840.4056851-1-matthew.d.roper@intel.com
|
#
005e9537 |
|
19-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate most usage of INTEL_GEN() Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN() in the display code to use DISPLAY_VER() comparisons instead. The following semantic patch was used: @@ expression dev_priv, E; @@ - INTEL_GEN(dev_priv) == E + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; @@ - INTEL_GEN(dev_priv) + DISPLAY_VER(dev_priv) @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_DISPLAY_RANGE(dev_priv, from, until) There are still some display-related uses of INTEL_GEN() in intel_pm.c (watermark code) and i915_irq.c. Those will be updated separately. v2: - Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
|
#
714b1cdb |
|
05-Feb-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: refactor skylake scaler code into new file. This moves the code from various places and consolidates it into one new file. v2: - rename skl_program_plane -> skl_program_plane_scaler (Ville) - also move skl_pfit_enable, and consequently make some skl_scaler_* functions static to skl_scaler.c (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2fa703ffc7b96a41c392fd5ebbd2e6e4ffb6fb05.1612536383.git.jani.nikula@intel.com
|
#
ee230706 |
|
13-Nov-2020 |
Manasi Navare <manasi.d.navare@intel.com> |
drm/i915/dp: Add from_crtc_state to copy color blobs No functional changes here, just adds a from_crtc_state as a prep for bigjoiner v2: * More prep with intel_atomic_state (Ville) 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/20201113155656.17630-2-manasi.d.navare@intel.com
|
#
66186acb |
|
02-Nov-2020 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Use initial_fastset_check() to compute and apply the initial PSR state Replace the previous approach to force compute the initial PSR state after i915 take over from firmware by the better and recently added initial_fastset_check() hook. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201102221048.104294-1-jose.souza@intel.com
|
#
e161da33 |
|
02-Sep-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove the old global state stuff With the dbuf code mostly converted over to the new global state handling we can remove the leftovers of the old global state stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200902122141.15181-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
#
a227569d |
|
29-Apr-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Replace I915_MODE_FLAG_INHERITED with a boolean There's no reason for I915_MODE_FLAG_INHERITED to exist as a flag anymore. Just make it a boolean. v2: Deal with sanitize_watermarks() CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429103936.11850-1-ville.syrjala@linux.intel.com
|
#
af157b76 |
|
29-Apr-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stop using mode->private_flags Replace the use of mode->private_flags with a truly private bitmaks in our own crtc state. We also need a copy in the crtc itself so the vblank code can get at it. We already have scanline_offset in there for a similar reason, as well as the vblank->hwmode which is assigned via drm_calc_timestamping_constants(). Fortunately we now have a nice place for doing the crtc_state->crtc copy in intel_crtc_update_active_timings() which gets called both for modesets and init/resume readout. The one slightly iffy spot is the INHERITED flag which we want to preserve until userspace/fb_helper does the first proper commit after actually calling .detecti() on the connectors. Otherwise we don't have the full sink capabilities (audio,infoframes,etc.) when .compute_config() gets called and thus we will fail to enable those features when the first userspace commit happens. The only internal commit we do prior to that should be from intel_initial_commit() and there we can simply preserve the INHERITED flag from the readout. v2: Deal with INHERITED in sanitize_watermarks() as well CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429103904.11727-1-ville.syrjala@linux.intel.com
|
#
afeda4f3 |
|
20-May-2020 |
Animesh Manna <animesh.manna@intel.com> |
drm/i915/dsb: Pre allocate and late cleanup of cmd buffer Pre-allocate command buffer in atomic_commit using intel_dsb_prepare function which also includes pinning and map in cpu domain. No functional change is dsb write/commit functions. Now dsb get/put function is removed and ref-count mechanism is not needed. Below dsb api added to do respective job mentioned below. intel_dsb_prepare - Allocate, pin and map the buffer. intel_dsb_cleanup - Unpin and release the gem object. RFC: Initial patch for design review. v2: included _init() part in _prepare(). [Daniel, Ville] v3: dsb_cleanup called after cleanup_planes. [Daniel] v4: dsb structure is moved to intel_crtc_state from intel_crtc. [Maarten] v5: dsb get/put/ref-count mechanism removed. [Maarten] v6: Based on review feedback following changes are added, - replaced intel_dsb structure by pointer in intel_crtc_state. [Maarten] - passing intel_crtc_state to dsp-api to simplify the code. [Maarten] - few dsb functions prototype modified to simplify code. v7: added few cosmetic changes suggested by Jani and null check for crtc_state in dsb_cleanup removed as suggested by Maarten. v8: changed the function parameter to intel_crtc_state* of ivb_load_lut_ext_max() from intel_crtc. [Maarten] v9: error handling improved in _write() and prepare(). [Maarten] Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200520130737.11240-1-animesh.manna@intel.com
|
#
f07fba2f |
|
06-Feb-2020 |
Wambui Karuga <wambui.karugax@gmail.com> |
drm/i915/atomic: conversion to drm_device based logging macros. Conversion of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_atomic.c This change was achieved using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were fixed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206080014.13759-4-wambui.karugax@gmail.com
|
#
f4224a4c |
|
28-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915/display: Make WARN* drm specific where drm_device ptr is available drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule4@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-20-pankaj.laxminarayan.bharadiya@intel.com
|
#
28a30b45 |
|
21-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Convert cdclk to global state Let's convert cdclk_state to be a proper global state. That allows us to use the regular atomic old vs. new state accessor, hopefully making the code less confusing. We do have to deal with a few more error cases in case the cdclk state duplication fails. But so be it. v2: Fix new plane min_cdclk vs. old crtc min_cdclk check Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121140353.25997-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
0ef1905e |
|
20-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce better global state handling Our current global state handling is pretty ad-hoc. Let's try to make it better by imitating the standard drm core private object approach. The reason why we don't want to directly use the private objects is locking; Each private object has its own lock so if we introduce any global private objects we get serialized by that single lock across all pipes. The global state apporoach instead uses a read/write lock type of approach where each individual crtc lock counts as a read lock, and grabbing all the crtc locks allows one write access. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-15-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
5f342993 |
|
20-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move intel_atomic_state_free() into intel_atomic.c Move intel_atomic_state_free() next to its counterpart. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-13-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
b4db3a8c |
|
20-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Collect more cdclk state under the same roof Move the min_cdclk[] and min_voltage_level[] arrays under the rest of the cdclk state. And while at it provide a simple helper (intel_cdclk_clear_state()) to clear the state during the ww_mutex backoff dance. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-6-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
723196f4 |
|
26-Jan-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/display: Squelch kerneldoc complaints drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'state' not described in 'intel_connector_needs_modeset' drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'connector' not described in 'intel_connector_needs_modeset' drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Function parameter or member 'state' not described in 'intel_fbc_enable' drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'crtc_state' description in 'intel_fbc_enable' drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'plane_state' description in 'intel_fbc_enable' Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200126195654.2172937-1-chris@chris-wilson.co.uk
|
#
60c6a14b |
|
06-Jan-2020 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Force the state compute phase once to enable PSR Recent improvements in the state tracking in i915 caused PSR to not be enabled when reusing firmware/BIOS modeset, this is due to all initial commits returning ealier in intel_atomic_check() as needs_modeset() is always false. To fix that here forcing the state compute phase in CRTC that is driving the eDP that supports PSR once. Enable or disable PSR do not require a fullmodeset, so user will still experience glitch free boot process plus the power savings that PSR brings. It was tried to set mode_changed in intel_initial_commit() but at this point the connectors are not registered causing a crash when computing encoder state. v2: - removed function return - change arguments to match intel_hdcp_atomic_check v3: - replaced drm includes in intel_psr.h by forward declaration(Jani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112253 Reported-by: <s.zharkoff@gmail.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200106152128.195171-1-jose.souza@intel.com
|
#
6671c367 |
|
22-Dec-2019 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/tgl: Select master transcoder for MST stream On TGL the blending of all the streams have moved from DDI to transcoder, so now every transcoder working over the same MST port must send its stream to a master transcoder and master will send to DDI respecting the time slots. So here adding all the CRTCs that shares the same MST stream if needed and computing their state again, it will pick the lowest pipe/transcoder among the ones in the same stream to be master. Most of the time skl_commit_modeset_enables() enables pipes in a crescent order but due DDB overlapping it might not happen, this scenarios will be handled in the next patch. v2: - Using recently added intel_crtc_state_reset() to set mst_master_transcoder to invalid transcoder for all non gen12 & MST code paths - Setting lowest pipe/transcoder as master, previously it was the first one but setting a predictable one will help in future MST e port sync integration - Moving to intel type as much as we can v3: - Now intel_dp_mst_master_trans_compute() returns the MST master transcoder - Replaced stdbool.h by linux/types.h - Skip the connector being checked in intel_dp_mst_atomic_master_trans_check() - Using pipe instead of transcoder to compute MST master v4: - renamed connector_state to conn_state v5: - Improved the parameters of intel_dp_mst_master_trans_compute() to simply code - Added call drm_atomic_add_affected_planes() in intel_dp_mst_atomic_master_trans_check() as helper could not do it for us - Removed "if (ret)" left over from v3 changes v6: - handled ret == I915_MAX_PIPES case in compute BSpec: 50493 BSpec: 49190 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191223010654.67037-2-jose.souza@intel.com
|
#
ee36c7c0 |
|
22-Dec-2019 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Share intel_connector_needs_modeset() intel_connector_needs_modeset() will be used outside of intel_display.c in a future patch so it would only be necessary to remove the state and add the prototype to the header file. But while at it, I simplified the arguments and moved it to a better place intel_atomic.c. No behavior changes intended here. v3: - removed digital from exported version of intel_connector_needs_modeset - rollback connector to drm type v4: - Renamed new_connector_state to new_conn_state - Going back to drm_connector_state in intel_encoders_update_prepare/complete as we also have intel_tv_connector_state Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191223010654.67037-1-jose.souza@intel.com
|
#
1aa4df7e |
|
30-Oct-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Preload LUTs if the hw isn't currently using them The LUTs are single buffered so in order to program them without tearing we'd have to do it during vblank (actually to be 100% effective it has to happen between start of vblank and frame start). We have no proper mechanism for that at the moment so we just defer loading them after the vblank waits have happened. That is not quite sufficient (especially when committing multiple pipes whose vblanks don't line up) so the LUT load will often leak into the following frame causing tearing. However in case the hardware wasn't previously using the LUT we can preload it before setting the enable bit (which is double buffered so won't tear). Let's determine if we can do such preloading and make it happen. Slight variation between the hardware requires some platforms specifics in the checks. Hans is seeing ugly colored flash on VLV/CHV macchines (GPD win and Asus T100HA) when the gamma LUT gets loaded for the first time as the BIOS has left some junk in the LUT memory. v2: Deal with uapi vs. hw crtc state split s/GCM/CGM/ typo fix Cc: Hans de Goede <hdegoede@redhat.com> Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank waits") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191030190815.7359-1-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit 0ccc42a2fd5107a7f58e62c8b35b61de9a70ce82) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit f77021372e2880237278e0ee57faadc077a8256a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
f7702137 |
|
30-Oct-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Preload LUTs if the hw isn't currently using them The LUTs are single buffered so in order to program them without tearing we'd have to do it during vblank (actually to be 100% effective it has to happen between start of vblank and frame start). We have no proper mechanism for that at the moment so we just defer loading them after the vblank waits have happened. That is not quite sufficient (especially when committing multiple pipes whose vblanks don't line up) so the LUT load will often leak into the following frame causing tearing. However in case the hardware wasn't previously using the LUT we can preload it before setting the enable bit (which is double buffered so won't tear). Let's determine if we can do such preloading and make it happen. Slight variation between the hardware requires some platforms specifics in the checks. Hans is seeing ugly colored flash on VLV/CHV macchines (GPD win and Asus T100HA) when the gamma LUT gets loaded for the first time as the BIOS has left some junk in the LUT memory. v2: Deal with uapi vs. hw crtc state split s/GCM/CGM/ typo fix Cc: Hans de Goede <hdegoede@redhat.com> Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank waits") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191030190815.7359-1-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit 0ccc42a2fd5107a7f58e62c8b35b61de9a70ce82) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
0ccc42a2 |
|
30-Oct-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Preload LUTs if the hw isn't currently using them The LUTs are single buffered so in order to program them without tearing we'd have to do it during vblank (actually to be 100% effective it has to happen between start of vblank and frame start). We have no proper mechanism for that at the moment so we just defer loading them after the vblank waits have happened. That is not quite sufficient (especially when committing multiple pipes whose vblanks don't line up) so the LUT load will often leak into the following frame causing tearing. However in case the hardware wasn't previously using the LUT we can preload it before setting the enable bit (which is double buffered so won't tear). Let's determine if we can do such preloading and make it happen. Slight variation between the hardware requires some platforms specifics in the checks. Hans is seeing ugly colored flash on VLV/CHV macchines (GPD win and Asus T100HA) when the gamma LUT gets loaded for the first time as the BIOS has left some junk in the LUT memory. v2: Deal with uapi vs. hw crtc state split s/GCM/CGM/ typo fix Cc: Hans de Goede <hdegoede@redhat.com> Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank waits") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191030190815.7359-1-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
#
f90a85e7 |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Perform automated conversions for plane uapi/hw split, base -> uapi. Split up plane_state->base to uapi. This is done using the following patch, ran after the previous commit that splits out any hw references: @@ struct intel_plane_state *T; identifier x; @@ -T->base.x +T->uapi.x @@ struct intel_plane_state *T; @@ -T->base +T->uapi Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-10-maarten.lankhorst@linux.intel.com
|
#
7b3cb17a |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Perform automated conversions for plane uapi/hw split, base -> hw. Split up plane_state->base to hw. This is done using the following patch: @@ struct intel_plane_state *T; identifier x =~ "^(crtc|fb|alpha|pixel_blend_mode|rotation|color_encoding|color_range)$"; @@ -T->base.x +T->hw.x Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-9-maarten.lankhorst@linux.intel.com
|
#
58d124ea |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Complete crtc hw/uapi split, v6. Now that we separated everything into uapi and hw, it's time to make the split definitive. Remove the union and make a copy of the hw state on modeset and fastset. Color blobs are copied in crtc atomic_check(), right before color management is checked. Changes since v1: - Copy all blobs immediately after drm_atomic_helper_check_modeset(). - Clear crtc_state->hw on disable, instead of using clear_intel_crtc_state(). Changes since v2: - Use intel_crtc_free_hw_state + clear in intel_crtc_disable_noatomic(). - Make a intel_crtc_prepare_state() function that clears the crtc_state and copies hw members. - Remove setting uapi.adjusted_mode, we now have a direct call to drm_calc_timestamping_constants(). Changes since v3: - Rename prefix copy_hw_to_uapi_state() with intel_crtc. - Copy color blobs to uapi as well. - Add a intel_crtc_copy_uapi_to_hw_state_nomodeset() function for clarity. Changes since v4: - Copy hw.adjusted_mode back to uapi.adjusted_mode, to shut up the call to drm_calc_timestamping_constants() in drm_atomic_helper_update_legacy_modeset_state(). - Use drm_property_replace_blob (Ville). Changes since v5: - Use hw->mode in intel_modeset_readout_hw_state(). (Ville) - Copy to uapi.mode using drm_atomic_set_mode_for_crtc(). (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-6-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
2225f3c6 |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Perform automated conversions for crtc uapi/hw split, base -> uapi. Split up crtc_state->base to uapi. This is done using the following patch, ran after the previous commit that splits out any hw references: @@ struct intel_crtc_state *T; @@ -T->base +T->uapi Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-5-maarten.lankhorst@linux.intel.com
|
#
2b808b3a |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Add aliases for uapi and hw to crtc_state Prepare to split up hw and uapi machinally, by adding a uapi and hw alias. We will remove the base in a bit. This is a split from the original uapi/hw patch, which did it all in one go. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-2-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
1d5a95b5 |
|
15-Oct-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Rework global state locking So far we've sort of protected the global state under dev_priv with the connection_mutex. I wan to change that so that we can change the cdclk even for pure plane updates. To that end let's formalize the protection of the global state to follow what I started with the cdclk code already (though not entirely properly) such that any crtc mutex will suffice as a read lock, and all crtcs mutexes act as the write lock. We'll also pimp intel_atomic_state_clear() to clear the entire global state, so that we don't accidentally leak stale information between the locking retries. As a slight optimization we'll only lock the crtc mutexes to protect the global state, however if and when we actually have to poke the hw (eg. if the actual cdclk changes) we must serialize commits across all crtcs so that a parallel nonblocking commit can't get ahead of the cdclk reprogamming. We do that by adding all crtcs to the state. TODO: the old global state examined during commit may still be a problem since it always looks at the _latest_ swapped state in dev_priv. Need to add proper old/new state for that too I think. v2: Remeber to serialize the commits if necessary Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015193035.25982-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
#
c750c22b |
|
20-Sep-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Do not add all planes when checking scalers on glk+ We cannot switch between HQ and normal mode on GLK+, so only add planes on platforms where it makes sense. We could probably restrict it even more to only add when scaler users toggles between 1 and 2, but lets just leave it for now. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920114235.22411-9-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
|
#
c47b7ddb |
|
20-Sep-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Rename planar linked plane variables Rename linked_plane to planar_linked_plane and slave to planar_slave, this will make it easier to keep apart bigjoiner linking and planar plane linking. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920114235.22411-8-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
|
#
c22d62e6 |
|
20-Sep-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Get rid of crtc_state->fb_changed We had this as an optimization to not do a plane update, but we killed it off because there are so many reasons we may have to do a plane update or fastset that it's best to just assume everything changed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920114235.22411-6-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
|
#
cfcbfdd8 |
|
08-Jul-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove pointless planes_changed=true assignment i915 doesn't use the crtc_state->plane_changed flag for anything, so setting it is pointless. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190708125325.16576-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
#
1d455f8d |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: rename intel_drv.h to display/intel_display_types.h Everything about the file is about display, and mostly about types related to display. Move under display/ as intel_display_types.h to reflect the facts. There's still plenty to clean up, but start off with moving the file where it logically belongs and naming according to contents. v2: fix the include guard name in the renamed file Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com
|
#
df0566a6 |
|
13-Jun-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move modesetting core code under display/ Now that we have a new subdirectory for display code, continue by moving modesetting core code. display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this is, again, a surprisingly clean operation. v2: - don't move intel_sideband.[ch] (Ville) - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-3-jani.nikula@intel.com
|