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.
Define the contents of VBT block 25 (SDVO LVDS PPS).
Not 100% sure about the order of the fields as this is not
documented in the VBT spec anymore, but this order matches
what is included as part of the power sequencing SDVO commands
(struct sdvo_panel_power_sequencing). Also the real world
VBT data I have looks OK with this definition.
Define the contents of VBT block 21 (EFP List). Specs are nowhere
to be found, but real world data suggests that each entry is just
the first four bytes of the EDID PnP ID structure.
Define the contenst is VBT blocks 19,30,32 (Display Configuration
Removal Table) contents. There are three variants of this block:
pre-IVB, IVB, HSW+, with each having slightly different entries.
Curiously many HSW/BDW machines seem to have both the IVB and HSW+
variants in their VBTs simultanously. No idea why.
Define the contenst is VBT blocks 16,19,31 (Toggle List).
There are three variants of this block: pre-IVB, IVB, HSW+,
with each having slightly different entries.
Curiously many HSW/BDW machines seem to have both the IVB and
HSW+ variants in their VBTs simultanously. No idea why.
Ville Syrjälä [Fri, 3 May 2024 12:24:30 +0000 (15:24 +0300)]
drm/i915/bios: Define ALM only VBT block 9 contents
For some reason ALM VBT has two dot clock override tables.
One as the normal block 15 and a second one as block 9.
The table in block 9 has no row_size/num_rows information.
On my Fujitsu Lifebook S6010 only the block 9 table has actual
data in it. Block 15 is present but all zeroes.
Define the contents of VBT block 15 (Dot Clock Override Table)
The contents were reverse engineered by intuition. The gen2 stuff
seems solid as I can verify that against real world VBT data. The
gen3 stuff less so as all the gen3+ VBTs I have just filla the
entire block with zeroes.
Define the contents of VBT block 10 (Mode Removal Table).
There seem to be two variants:
- 8 byte entries for desktop systems
- 10 byte entries for mobile systems, with the extra
panel_flags being a bitmask of LFPs
It seems starting from HSW only the mobile variant is
used anymore.
Define the contents for VBT blocks:
- Block 6 (Extended MMIO Register Table)
- Block 7 (IO Software Flag Table)
- Block 8 (MMIO SWF Register Table)
All of these use the same basic layout, with two known variants:
- data_access_size==0xce -> offset,value tuples are u8,u8
- data_access_size==0x02 -> offset,value tuples are u32,u32
Define the contents of VBT block 5 (Generic Mode Table).
Details were mostly gleaned from some VBIOS sources.
There are apparently two variants of the block: ALM only
vs. MGM, defined here as bdb_generic_mode_table_alm
and bdb_generic_mode_table_mgm. And those are the only two
platforms where I've seen this block.
Ville Syrjälä [Fri, 3 May 2024 12:24:24 +0000 (15:24 +0300)]
drm/i915/bios: Define VBT block 4 (Mode Support List) contents
Define the contents of VBT block 4 (Mode Support List).
Slightly crazy layout with a variable length list at the start,
followed by the length of said list.
No real idea what these "Intel mode numbers" really are. What
I see in real world VBTs seems to be always the same list of
26 numbers, ranging between 0x30 and 0x84.
Ville Syrjälä [Fri, 3 May 2024 12:24:20 +0000 (15:24 +0300)]
drm/i915/bios: Define "TV" child device handle
Child device 0x2 used to be "TV" until redefined to mean
EFP5 in version 215. Add a define for the old meaning as well.
Technically it was probably deprecated a lot before version
215 since native TV encoders were last seen on CTG, and SDVO
was fully gone by HSW. So something like "???-164" might also
be a reasonable way to document this, but no real harm in
saying "???-214" since nothing else presumably occupied that
bit in the meantime.
Ville Syrjälä [Fri, 3 May 2024 12:24:16 +0000 (15:24 +0300)]
drm/i915/bios: Remove version number comment from DEVICE_HANDLE_EFP4
DEVICE_HANDLE_EFP4 has actually been in use since the very beginning,
or at least something has been occupying that bit because old
VBTs actually use it, and it definitely looks to be about external
displays given how its used. So let's ignore what the current spec
claims and remove the misleading version number comment.
Karthikeyan Ramasubramanian [Thu, 22 Feb 2024 01:06:24 +0000 (18:06 -0700)]
drm/i915/bios: Fix parsing backlight BDB data
Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to
backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB
contents") updated the backlight BDB data accordingly. This broke the
parsing of backlight BDB data in VBT for versions 236 - 238 (both
inclusive) and hence the backlight controls are not responding on units
with the concerned BDB version.
backlight_control information has been present in backlight BDB data
from at least BDB version 191 onwards, if not before. Hence this patch
extracts the backlight_control information for BDB version 191 or newer.
Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236).
Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251).
v2: removed checking the block size of the backlight BDB data
[vsyrjala: this is completely safe thanks to commit e163cfb4c96d
("drm/i915/bios: Make copies of VBT data blocks")]
Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents") Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221180622.v2.1.I0690aa3e96a83a43b3fc33f50395d334b2981826@changeid Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Matthew Auld [Tue, 30 Apr 2024 17:28:49 +0000 (10:28 -0700)]
drm/i915/display: perform transient flush
Perform manual transient cache flush prior to flip and at the end of
frontbuffer_flush. This is needed to ensure display engine doesn't see
garbage if the surface is L3:XD dirty.
Testcase: igt@xe-pat@display-vs-wb-transient Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-19-radhakrishna.sripada@intel.com
Nirmoy Das [Tue, 30 Apr 2024 17:28:48 +0000 (10:28 -0700)]
drm/xe/device: implement transient flush
Display surfaces can be tagged as transient by mapping it using one of
the various L3:XD PAT index modes on Xe2. The expectation is that KMD
needs to request transient data flush at the start of flip sequence to
ensure all transient data in L3 cache is flushed to memory. Add a
routine for this which we can then call from the display code.
v2: rebase(RK)
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Co-developed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-18-radhakrishna.sripada@intel.com
Revert "drm/i915/dgfx: DGFX uses direct VBT pin mapping"
This reverts commit 562f33836f519a235e5c5e71bcc723ab1faccd2f.
For BMG it seems that the VBT to DDI mapping does not follow DG1, and
DG2, but follows ADLP mapping given in Bspec:20124.
Matt Roper [Tue, 30 Apr 2024 17:28:42 +0000 (10:28 -0700)]
drm/i915/xe2hpd: Add max memory bandwidth algorithm
Unlike DG2, Xe2_HPD does support multiple GV points with different
maximum memory bandwidths, but uses a much simpler algorithm than igpu
platforms use.
drm/i915/xe2hpd: Add support for eDP PLL configuration
Tables for eDP PHY PLL configuration for different link rates added for
Xe2_HPD. Previous platforms were using C10 PHY for eDP port whereas
Xe2_HPD has C20 PHY.
Xe2_HPD has different offsets for C20 PHY SRAM configuration context
location. Use the display version to select the right address.
Note that Xe2_LPD uses the same C20 SRAM offsets used by Xe_LPDP (i.e.
MTL's display). According to the BSpec, currently, only Xe2_HPD has
different offsets, so make sure it is the only display using them in the
driver.
v2:
* Redesigned how the right offsets are selected for different display
IP versions.
v3: Fix white space error(RK)
Bspec: 67610 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-7-radhakrishna.sripada@intel.com
projects / users / jedix / linux-maple.git / log