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]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240507040407.1056061-7-suraj.kandpal@intel.com
Drop comments for EDP HDR DPCD registers as the code and
conditions will tell us what can be written where.
--v2
-Drop the comments altogether instead of just renaming them
[Sebastian]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240507040407.1056061-6-suraj.kandpal@intel.com
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.
--v2
-Fix typo in commit message [Arun]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240507040407.1056061-5-suraj.kandpal@intel.com
Rename intel to intel cap which is present inside panel.edp struct
to make it more sensible to tell us what it contains.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240507040407.1056061-3-suraj.kandpal@intel.com
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.
--v2
-State reason the function is needed [Arun]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240507040407.1056061-2-suraj.kandpal@intel.com
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240506125718.26001-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240506125718.26001-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Disable HDCP Line Rekeying when HDCP ver > 1.4 and when we are
on HDMI TMDS operation for DISPLAY_VER >= 14.
--v2
-Wa to be mentioned in comments not in commit message [Jani]
-Remove blankline [Jani]
--v3
-No need to write what is being done in comments when code
is self explanatory [Jani]
--v4
-Add comment regarding need of this WA when in TMDS mode
[Chaitanya]
-Write in chicken register for MTL [CHaitanya]
--v5
-Fix comment [Chaitanya]
-Use correct set and clear value in intel_de_rmw [Chaitanya]
--v6
-No need to define C, D chicken bits it gets calculated [Animesh]
Bspec: 49273
Bspec: 69964
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240507062243.1076047-2-suraj.kandpal@intel.com
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240506183331.7720-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Define the contents of VBT block 253 (PRD Table).
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-36-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-34-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Define the contents of VBT block 50 (MIPI).
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-33-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-32-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-25-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-21-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-20-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-17-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-16-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-14-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-12-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
