- 03 Dec, 2021 25 commits
-
-
Ville Syrjälä authored
In order to better encapsulate the FBC implementation introduce a small helper to do the plane<->FBC instance association. We'll also try to structure the plane init code such that introducing multiple FBC instances will be easier down the line. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-13-ville.syrjala@linux.intel.comReviewed-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
In order to encapsulate FBC harder let's just move the debugfs stuff into intel_fbc.c. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
The underrun code doesn't need to know any details about FBC, so just pass in the whole device rather than a specific FBC instance. We could make this a bit more fine grained by also passing in the pipe to intel_fbc_handle_fifo_underrun_irq() and letting the FBC code figure which FBC instance (if any) is active on said pipe. But that seems a bit overkill for this so don't bother. Signed-off-by:
-
Ville Syrjälä authored
Use an early return to flatten most of __intel_fbc_pre_update(). Signed-off-by:
-
Ville Syrjälä authored
In the future we may have multiple planes on the same pipe capable of using FBC. Prepare for that by tracking FBC usage per-plane rather than per-crtc. v2: s/intel_get_crtc_for_pipe/intel_crtc_for_pipe/ Signed-off-by:
-
Ville Syrjälä authored
Pass the FBC instance instead of the crtc to a bunch of places. We also adjust intel_fbc_post_update() to do the intel_fbc_get_reg_params() things instead of doing it from the lower level function (which also gets called for front buffer tracking). Nothing in there will change during front buffer updates. Signed-off-by:
-
Ville Syrjälä authored
The FBC state cache and params are now nearly identical. Just use the same structure for both. Signed-off-by:
-
Ville Syrjälä authored
There isn't a good reason why we'd have to cache all this plane state stuff in the FBC state. Instead we can just pre-calculate what FBC will really need. Signed-off-by:
-
Ville Syrjälä authored
Move intel_fbc_override_cfb_stride() next to its cousins. Helps with later patches. Signed-off-by:
-
Ville Syrjälä authored
There's no need to store all this stuff in intel_fbc_state_cache. Just check it all against the plane/crtc states and store only what we need. Probably more should get nuked still, but this is a start. So what we'll do is: - each plane will check its own state and update its local no_fbc_reason - the per-plane no_fbc_reason (if any) then gets propagated to the cache->no_fbc_reason while doing the actual update - fbc->no_fbc_reason gets updated in the end with either the value from the cache or directly from frontbuffer tracking It's still a bit messy, but should hopefuly get cleaned up more in the future. At least now we can observe each plane's reasons for rejecting FBC now more consistently, and we don't have so mcuh redundant state store all over the place. v2: store no_fbc_reason per-plane instead of per-pipe Signed-off-by:
-
Ville Syrjälä authored
No reason to burden the caller with the details on how the minimum compression limit is calculated, so just pass in the whole plane state instead of just the cpp value. Signed-off-by:
-
Ville Syrjälä authored
The ilk fbc watermark computation uses intel_fbc_is_active() which is racy since we don't know whether FBC will be enabled or not at some point. So let's just assume it will be if both HAS_FBC() and the modparam agree. Signed-off-by:
-
Ville Syrjälä authored
Rename the PLANE_CUS_CTL Y plane selection bits to actually say "Y plane". Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
Rename the YUV byte order bits to be a bit more consistent. v2: Deal with gvt Signed-off-by:
-
Ville Syrjälä authored
Let's just stick to 32bit mmio accesses so we can get rid of the bare "uncore" reg access in display code. The register are defined as 32bit in the spec anyway. We could define a 64bit "de" variant I suppose, but doesn't really make much sense just for this one case, and when we start to use the DSB for this stuff we'd also need another 64bit variant for that. Just easier to do 32bit always. While at it we can reorder stuff a bit so that we write the registers in order of increasing offset (more or less). Signed-off-by:
-
Jani Nikula authored
Break the dependency on i915_drv.h. Signed-off-by:
-
Jani Nikula authored
Avoid looking into the guts of struct drm_i915_private in headers. Again, converting an inline function to a macro is less than ideal, but avoids having to pull in i915_drv.h just for the to_i915() part. Signed-off-by:
-
Jani Nikula authored
It's not the ideal location, but a better alternative than i915_drv.h. The goal is to break the intel_display_types.h to i915_drv.h dependency. Signed-off-by:
-
Jani Nikula authored
This is far from ideal, but it reduces the i915_drv.h dependency from intel_display_types.h. Maybe in the future we'll need a better split. Signed-off-by:
-
Jani Nikula authored
Move fb functions where they belong, and un-inline to avoid looking into struct drm_i915_private guts in header files. Signed-off-by:
-
Jani Nikula authored
Move a number of crtc/pipe related functions to intel_crtc.[ch], and un-inline to avoid looking into struct drm_i915_private guts in header files. Signed-off-by:
-
Anshuman Gupta authored
gt_pm selftest calculates engine ticks cycles and wall time cycles by delta of respective engine elapsed TIMESTAMP and ktime for period of 1000us. It compares the engine ticks cycles with wall time cycles. Disable local cpu interrupt so that interrupt handler does not switch out the thread during measure_clocks() and prevent miscalculation of engine tick cycles. v2: - nuke preempt_{disable,enable}, as disable_local_irq() disable the preemption. (Chris) Cc: Chris P Wilson <chris.p.wilson@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211130132005.6305-1-anshuman.gupta@intel.com
-
Matt Atwood authored
Extend existing workaround 1409120013 to DG2. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116174818.2128062-6-matthew.d.roper@intel.com
-
Matt Roper authored
This workaround is documented a bit strangely in the bspec; it's listed as an A0 workaround, but the description clarifies that the workaround is implicitly handled by the hardware and what the driver really needs to do is program a chicken bit to reenable some internal behavior. Signed-off-by:
-
Matt Roper authored
Commit cd0fcf5a ("drm/i915: rename DISP_STEPPING->DISPLAY_STEP and GT_STEPPING->GT_STEP") renamed all platforms' display stepping tests, but the DG2 patches were still in-flight at that time and did not incorporate the new naming scheme. Rename DG2's macro now for consistency with other platforms. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 02 Dec, 2021 5 commits
-
-
Vidya Srinivas authored
PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE and scaler size registers supports max 5120. Take care of this restriction in max_width. Without this patch, when 5k content is sent on HDR plane with NV12 content, FIFO underrun is seen and screen blanks out. v2: Addressed review comments from Ville. Added separate functions for max_width - for HDR and SDR v3: Addressed review comments from Ville. Changed names of HDR and SDR max_width functions to icl_hdr_plane_max_width and icl_sdr_plane_max_width v4: Fixed paranthesis alignment. No code change Reviewed-by:
Vidya Srinivas <vidya.srinivas@intel.com> [vsyrjala: Fix alignment] Signed-off-by:
-
Jani Nikula authored
There are only three call sites remaining for intel_wait_for_vblank(). Remove the function, and open code it to avoid new users from showing up. v2: - Use intel_crtc_wait_for_next_vblank() (Ville) Signed-off-by:
-
Jani Nikula authored
The "get" in the name implies reference counting, remove it. This also makes the function conform to naming style. Suggested-by:
-
Jani Nikula authored
The "get" in the name implies reference counting, remove it. This also makes the function conform to naming style. Suggested-by:
-
Jani Nikula authored
intel_wait_for_vblank() goes through a pipe to crtc lookup, while in most cases we already have the crtc available. Avoid the extra lookups by adding an intel_crtc based helper. v2: - Add intel_crtc_wait_for_next_vblank() helper (Ville) Signed-off-by:
-
- 01 Dec, 2021 1 commit
-
-
Lyude Paul authored
While working on supporting the Intel HDR backlight interface, I noticed that there's a couple of laptops that will very rarely manage to boot up without detecting Intel HDR backlight support - even though it's supported on the system. One example of such a laptop is the Lenovo P17 1st generation. Following some investigation Ville Syrjälä did through the docs they have available to them, they discovered that there's actually supposed to be a 30ms wait after writing the source OUI before we begin setting up the rest of the backlight interface. This seems to be correct, as adding this 30ms delay seems to have completely fixed the probing issues I was previously seeing. So - let's start performing a 30ms wait after writing the OUI, which we do in a manner similar to how we keep track of PPS delays (e.g. record the timestamp of the OUI write, and then wait for however many ms are left since that timestamp right before we interact with the backlight) in order to avoid waiting any longer then we need to. As well, this also avoids us performing this delay on systems where we don't end up using the HDR backlight interface. V3: * Move last_oui_write into intel_dp V2: * Move panel delays into intel_pps Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
-
- 29 Nov, 2021 1 commit
-
-
Imre Deak authored
The drm.mode_config state is not initialized in case of !HAS_DISPLAY so taking the fb_lock and iterating the fb list won't work on those platforms. Skip the suspend/resume with an explicit check for this. Fixes: 9755f055 ("drm/i915: Restore memory mapping for DPT FBs across system suspend/resume") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
- 24 Nov, 2021 1 commit
-
-
Stanislav Lisovskiy authored
Tile4 patch still needs an ack from userspace, IGT tests and some essential fixes, related to new .plane_caps attribute being added. This reverts commit 3c542cfa. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by:
-
- 23 Nov, 2021 5 commits
-
-
Jani Nikula authored
Follow the convention of corresponding .h for .c. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122111504.223248-4-jani.nikula@intel.com
-
Jani Nikula authored
Follow the convention of corresponding .h for .c. Signed-off-by:
-
Jani Nikula authored
Follow the convention of corresponding .h for .c. Signed-off-by:
-
Jani Nikula authored
Follow the convention of corresponding .h for .c. Signed-off-by:
-
Stanislav Lisovskiy authored
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:Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122211420.31584-1-stanislav.lisovskiy@intel.com
-
- 22 Nov, 2021 2 commits
-
-
Jani Nikula authored
Sync up with drm-next to get v5.16-rc2. Signed-off-by: -
Tilak Tangudu authored
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 1a52faed ("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:
-
