Ville Syrjälä [Fri, 17 May 2024 17:12:08 +0000 (20:12 +0300)]
drm/i915: Add skl+ plane name aliases to enum plane_id
Using PLANE_PRIMARY + PLANE_SPRITE? on skl+ results in a bunch
of unnecessary head scratching. Add aliases using the skl+ plane
names.
And for pre-skl we only need to keep PRIMARY,SPRITE0,SPRITE1
as we only ever have 0-2 sprites per pipe on those platforms.
Vidya Srinivas [Mon, 20 May 2024 16:56:34 +0000 (22:26 +0530)]
drm/i915/dpt: Make DPT object unshrinkable
In some scenarios, the DPT object gets shrunk but
the actual framebuffer did not and thus its still
there on the DPT's vm->bound_list. Then it tries to
rewrite the PTEs via a stale CPU mapping. This causes panic.
Cc: stable@vger.kernel.org Reported-by: Shawn Lee <shawn.c.lee@intel.com> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
[vsyrjala: Add TODO comment] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240520165634.1162470-1-vidya.srinivas@intel.com
Jani Nikula [Wed, 15 May 2024 16:56:50 +0000 (19:56 +0300)]
drm/i915/pciids: switch to xe driver style PCI ID macros
The PCI ID macros in xe_pciids.h allow passing in the macro to operate
on each PCI ID, making it more flexible. Convert i915_pciids.h to the
same pattern.
INTEL_IVB_Q_IDS() for Quanta transcode remains a special case, and
unconditionally uses INTEL_QUANTA_VGA_DEVICE().
Ryszard Knop [Wed, 24 Apr 2024 11:41:59 +0000 (13:41 +0200)]
MAINTAINERS: Move the drm-intel repo location to fd.o GitLab
The drm-intel repo is moving from the classic fd.o git host to GitLab.
Update its location with a URL matching other fd.o GitLab kernel trees.
Signed-off-by: Ryszard Knop <ryszard.knop@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240424114159.38719-1-ryszard.knop@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Jouni Högander [Fri, 17 May 2024 07:30:03 +0000 (10:30 +0300)]
drm/i915/psr: LunarLake IO and Fast Wake time line count maximums are 68
On LunarLake maximum for IO and Fast Wake time line counts are 68: 6 bits +
5 lines added by the HW. Take this into account in calculation and when
writing the IO Wake lines.
v2: maximum line count is 68 (6 bits + 5 lines added by HW)
Nirmoy Das [Thu, 16 May 2024 15:14:03 +0000 (17:14 +0200)]
drm/i915/selftests: Set always_coherent to false when reading from CPU
Commit 8d4ba9fc1c6c ("drm/i915/selftests: Pick correct caching mode.")
was not complete as for non LLC sharing platforms cpu read can happen
from LLC which probably doesn't have the latest changes made by GPU.
Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Fixes: 8d4ba9fc1c6c ("drm/i915/selftests: Pick correct caching mode.") Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240516151403.2875-1-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Jani Nikula [Fri, 10 May 2024 11:22:18 +0000 (14:22 +0300)]
drm/i915/pciids: don't include WHL/CML PCI IDs in CFL
It's confusing for INTEL_CFL_IDS() to include all WHL and CML PCI
IDs. Even if we treat them the same in a lot of places, CML is a
platform of its own, and the lists of PCI IDs should not conflate them.
Largely go by the idea that if a platform has a name, group its PCI IDs
together.
That said, AML is special, having both KBL and CFL variants. Leave that
alone.
Ville Syrjälä [Fri, 10 May 2024 15:23:29 +0000 (18:23 +0300)]
drm/i915: Handle SKL+ WM/DDB registers next to all other plane registers
Having the plane WM/DDB regitster write functions in skl_watermarks.c
is rather annoying when trying to implement DSB based plane updates.
Move them into the respective files that handle all other plane
register writes. Less places where I need to worry about the DSB
vs. MMIO decisions.
The downside is that we spread the wm struct details a bit further
afield. But if that becomes too annoying we can probably abstract
things a bit more with a few extra functions.
Ville Syrjälä [Fri, 10 May 2024 15:23:27 +0000 (18:23 +0300)]
drm/i915: Extract skl_plane_{wm,ddb}_reg_val()
Extract helpers to calculate the final wm/ddb register
values for skl+. Will allow me to more cleanly remove the
register write wrappers for these registers.
Currently every skl+ plane register defines some intermediate
macros to calculate the final register offset. Pull all of that
into common macros, simplifying the final register offset stuff
into just five defines:
- raw register offsets for the planes 1 and 2 on pipes A and B
- the final parametrized macro
Ville Syrjälä [Mon, 13 May 2024 16:59:09 +0000 (19:59 +0300)]
drm/i915: Shuffle the skl+ plane register definitions
Rearrange the plane skl+ universal plane register definitions:
- keep everything related to the same register in one place
- sort based on register offset
- unify the whitespace/etc a bit
v2: Define register contents after all offsets (Jani)
Jouni Högander [Fri, 10 May 2024 09:38:22 +0000 (12:38 +0300)]
drm/i915/psr: Split intel_psr2_config_valid for panel replay
Part of intel_psr2_config_valid is valid for panel replay. rename it as
intel_sel_update_config_valid. Split psr2 specific part and name it as
intel_psr2_config_valid.
v3:
- move early transport check to psr2 specific check
- check intel_psr2_config_valid only for non-Panel Replay case
v2:
- use psr2_global_enabled for panel replay as well
- goto unsupported instead of return when global enabled check fails
Jouni Högander [Fri, 10 May 2024 09:38:19 +0000 (12:38 +0300)]
drm/i915/psr: Panel replay uses SRD_STATUS to track it's status
DP Panel replay uses SRD_STATUS to track it's status despite selective
update mode.
Bspec: 53370, 68920
v4:
- use PSR2_STATUS for eDP Panel Replay
- handle intel_psr_wait_exit_locked as well
v3:
- do not use PSR2_STATUS for PSR1
v2:
- use intel_dp_is_edp to differentiate
- modify debugfs status as well
Jouni Högander [Fri, 10 May 2024 09:38:18 +0000 (12:38 +0300)]
drm/i915/psr: Modify intel_dp_get_su_granularity to support panel replay
Currently intel_dp_get_su_granularity doesn't support panel replay.
This fix modifies it to support panel replay as well.
v4:
- use drm_dp_dpcd_readb instead of drm_dp_dpcd_read
- ensure return value is 0 if drm_dp_dpcd_readb fails
v3: use correct offset for DP_PANEL_PANEL_REPLAY_CAPABILITY
v2: rely on PSR definitions on common bits
Jouni Högander [Fri, 10 May 2024 09:38:17 +0000 (12:38 +0300)]
drm/i915/psr: Detect panel replay selective update support
Add new boolean to store panel replay selective update support of sink into
intel_psr struct. Detect panel replay selective update support and store
it into this new boolean.
v3: Clear sink_panel_replay_su_support in intel_dp_detect
v2: Merge adding new boolean into this patch
Jouni Högander [Fri, 10 May 2024 09:38:14 +0000 (12:38 +0300)]
drm/i915/dp: Use always vsc revision 0x6 for Panel Replay
We are about to enable Panel Replay Selective update mode. Vsc revision 0x6
for Panel Replay no matter if it is selective update or full frame update
mode. Take this into account when preparing VSC SDP package.
Jouni Högander [Fri, 10 May 2024 09:38:13 +0000 (12:38 +0300)]
drm/i915/display: Do not print "psr: enabled" for on Panel Replay
After setting has_psr for panel replay as well crtc state dump is
improperly printing "psr: enabled" for Panel Replay as well. Fix this by
checking also has_panel_replay.
Luca Coelho [Fri, 10 May 2024 09:05:02 +0000 (12:05 +0300)]
Documentation/i915: remove kernel-doc for DMC wakelocks
The function descriptions are optional and have not yet been added to
the DMC wakelock code, so we shouldn't try to use it. Since this is a
regression, remove the kernel-doc entry for DMC wakelocks for now.
The proper documentation will be added in a future patch.
Jani Nikula [Fri, 10 May 2024 09:43:13 +0000 (12:43 +0300)]
drm/xe/display: remove unused xe->sb_lock
Nothing in xe needs xe->sb_lock. None of the i915 display code using
->sb_lock gets built with xe, and in any case that would be wrong as xe
uses gt->pcode.lock for this.
Ville Syrjälä [Fri, 10 May 2024 10:22:57 +0000 (13:22 +0300)]
drm/i915: Cleanup fbdev fb setup
We use a mix of 'intel_fb' vs. 'ifbdev->fb' in the same function.
Both should be pointing at the same thing. Make things less
confusing by just getting existing fb from 'ifbdev->fb' at the
start and then sticking with the local 'fb' (renamed from the
'intel_fb') until the very end.
Ville Syrjälä [Fri, 10 May 2024 10:22:33 +0000 (13:22 +0300)]
drm/i915: Change intel_fbdev_fb_alloc() return type
Change intel_fbdev_fb_alloc() to return struct intel_fb instead
of struct drm_framebuffer. Let's us eliminate some annoying
aliasing variables in the fbdev setup code.
v2: Assing the results to the correct variable (Jani)
Fix xe's copy
Ville Syrjälä [Mon, 6 May 2024 12:57:15 +0000 (15:57 +0300)]
drm/i915: Constify 'fb' in during pinning
Make the 'fb' pointers const in the pinning code. We never
want to mutate these. Also nuke a few aliasing fb vs. intel_fb
cases by just using the more specific type everywhere in the
same function.
Uma Shankar [Thu, 9 May 2024 05:35:08 +0000 (11:05 +0530)]
drm/i915: Implement Audio WA_14020863754
WA_14020863754: Corner case with Min Hblank Fix can cause
audio hang
Issue: Previously a fix was made to avoid issues with extremely
small hblanks, called the "Min Hblank Fix". However, this can
potentially cause an audio hang.
Workaround :
During "Audio Programming Sequence" Audio Enabling -
When DP mode is enabled Set mmio offset 0x65F1C bit 18 = 1b,
before step #1 "Enable audio Presence Detect"
During "Audio Programming Sequence" Audio Disabling -
When DP mode is enabled Clear mmio offset 0x65F1C bit 18 = 0b,
after step #6 "Disable Audio PD (Presence Detect)"
If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave = 1b)
v2: Update the platform checks (Jani Nikula)
v3: Limited the WA to LNL and BMG, added a helper (Matt Roper)
v4: Updated the bit naming, fixed redundant if statement
Suraj Kandpal [Tue, 7 May 2024 04:04:06 +0000 (09:34 +0530)]
drm/i915/dp: Enable AUX based backlight for HDR
As of now whenerver HDR is switched on we use the PWM to change the
backlight as opposed to AUX based backlight changes in terms of nits.
This patch writes to the appropriate DPCD registers to enable aux
based backlight using values in nits.
--v2
-Fix max_cll and max_fall assignment [Jani]
-Fix the size sent in drm_dpcd_write [Jani]
--v3
-Content Luminance needs to be sent only for pre-ICL after that
it is directly picked up from hdr metadata [Ville]
--v4
-Add checks for HDR TCON cap bits [Ville]
-Check eotf of hdr_output_data and sets bits base of that value.
--v5
-Fix capability check bits.
-Check colorspace before setting BT2020
--v6
-Use intel_dp_has_gamut_dip to check if we have capability
to send sdp [Ville]
-Seprate filling of all hdr tcon related bits into it's
own function.
-Check eotf data to make sure we are in HDR mode [Sebastian]
--v7
-Fix confusion function name for hdr mode check [Jani]
-Fix the condition which tells us if we are in HDR mode or not
[Sebastian]
--v8
-Call fill_hdr_tcon_param unconditionally as some parameters may not
be dependent on the fact if we are in hdr mode or not [Sebastian]
-Fix some conditions after change in hdr mode check [Sebastian]
Suraj Kandpal [Tue, 7 May 2024 04:04:04 +0000 (09:34 +0530)]
drm/i915/dp: Fix Register bit naming
Change INTEL_EDP_HDR_TCON_SDP_COLORIMETRY enable to
INTEL_EDP_HDR_TCON_SDP_OVERRIDE_AUX as this bit tells TCON to
ignore DPCD colorimetry values and take the one's sent through
SDP.
Suraj Kandpal [Tue, 7 May 2024 04:04:01 +0000 (09:34 +0530)]
drm/i915/dp: Make has_gamut_metadata_dip() non static
Make has_gamut_metadata_dip() non static so it can also be used to
at other places eg in intel_dp_aux_backlight. So that we can check
if HW is capable of sending SDP which helps us decide if we use
AUX based HDR control or via SDP.
Ville Syrjälä [Mon, 6 May 2024 12:57:14 +0000 (15:57 +0300)]
drm/i915: Polish types in fb calculations
Be a bit more consistent in our use of integer types in
the fb related calculatiosn. u32 we generally only use
for ggtt offsets and such, and everything else can be regular
(unsigned) ints.
There's also an overabundance of consts for local variables
in skl_check_main_surface() which is not something we generally
do. So get rid of those while at it.
Ville Syrjälä [Mon, 6 May 2024 12:57:10 +0000 (15:57 +0300)]
drm/i915: Split gen2 vs. gen3 .max_stride()
Plane .max_stride() is already a vfunc so having one made
up of two branches based on the display version is silly.
Split i9xx_plane_max_stride() into gen2 vs. gen3 variants
so that we get rid of said check.
Ville Syrjälä [Mon, 6 May 2024 18:33:31 +0000 (21:33 +0300)]
drm/xe: Nuke xe's copy of intel_fbdev_fb.h
For some reason xe and i915 each have an identical (fortunately)
copy of intel_fbdev_fb.h. The xe copy actually only gets included
by xe's intel_fbdev_fb.c, and the i915 copy by everyone else,
include intel_fbdev.c which is the actual caller of the
functions declared in the header.
This means the xe and i915 headers are free to define/declare
completely incompatible things and the build would still succeed
as long as the symbol names match.
That is not a good thing, so let's nuke xe's copy of the header
so that everyone will use the same header, and be forced to
agree on the same API/ABI.
Unfortunately the block has two definitions, with the cutoff
supposedly happening on ICL vs. TGL. Also according to some
notes it might be that the VBIOS (if that's still a thing)
still uses the old definition even on TGL+. Quite the mess.
Define the contents of the obsolete VBT block 55 (Compression
Parameters).
This was some early attempt at defining the compression
parameters. However the spec says:
"This block is obsolete and should not be consumed for any
compression programming."
Block 56 is the replacement that should actually be used.
So let's just name the obsolete old block but not even
bother defining the contents.
This was some easly attempt at a MIPI DSI stuff. I'm not sure
this was ever actually used (I certainly don't have any VBTs
with this block), but here's some kind of definition for it
anyway.
Define the contents of VBT block 57 (Vswing PreEmphasis Table).
The contents is highly platform specific. The columns of the
table corresponding to some set of PHY/etc registers. The rows
corresponding to all legal vswing+pre-emphasis combinations
(ie. should be 10 rows in each table). And each table
corresponds to a platform specific (mostly undocumented)
mapping based on link rate/eDP low-vswing/etc. parameters.
projects / users / hch / configfs.git / log