Ville Syrjälä [Tue, 2 May 2023 14:38:59 +0000 (17:38 +0300)]
drm/i915: Fix FEC pipe A vs. DDI A mixup
On pre-TGL FEC is a port level feature, not a transcoder
level feature, and it's DDI A which doesn't have it, not
trancoder A. Check for the correct thing when determining
whether FEC is supported or not.
Jani Nikula [Tue, 5 Sep 2023 17:11:22 +0000 (20:11 +0300)]
drm/i915/dsc: have intel_dsc_pps_read() return the value
Register read functions usually return the value instead of passing via
pointer parameters. Return the multiple register verification results
via a pointer parameter, which can also be NULL to skip the extra
checks.
Make the name conform to existing style better while at it.
Jani Nikula [Tue, 5 Sep 2023 17:11:20 +0000 (20:11 +0300)]
drm/i915/dsc: improve clarity of the pps reg read/write helpers
Make it clear what's the number of vdsc per pipe, and what's the number
of registers to grab. Have intel_dsc_get_pps_reg() return the registers
it knows even if the requested amount is bigger.
Ville Syrjälä [Fri, 8 Sep 2023 05:25:27 +0000 (08:25 +0300)]
drm/i915: Only check eDP HPD when AUX CH is shared
Apparently Acer Chromebook C740 (BDW-ULT) doesn't have the
eDP HPD line properly connected, and thus fails the new
HPD check during eDP probe. The result is that we lose the
eDP output.
I suspect all such machines would be Chromebooks or other
Linux exclusive systems as the Windows driver likely wouldn't
work either. I did check a few other BDW machines here and
those do have eDP HPD connected, one of them even is a
different Chromebook (Samus).
To account for these funky machines let's skip the HPD check when
it looks like the eDP port is the only one using that specific AUX
channel. In case of multiple ports sharing the same AUX CH (eg. on
Asrock B250M-HDV) we still do the check and thus should correctly
ignore the eDP port in favor of the other DP port (usually a DP->VGA
converter).
Matt Roper [Wed, 6 Sep 2023 23:47:37 +0000 (16:47 -0700)]
drm/i915/display: Apply workarounds during display init
Rather than applying display workarounds as part of
intel_clock_gating_init() (which in turn is confusingly called from
i915_gem_init during device probe), handle them at the point we're
actually initializing the display hardware. This will also ensure that
these workarounds are properly applied during display initialization on
the Xe driver, which re-uses i915's display code, but does not call
i915's gem init.
Matt Roper [Thu, 7 Sep 2023 00:10:10 +0000 (17:10 -0700)]
drm/i915/display: Extract display workarounds from clock gating init
Several of the register updates that are currently done in the clock
gating init functions are actually display workarounds that should move
into the display-specific part of the code. Furthermore, some of the
registers being programmed don't even have anything to do with clock
gating at all.
Extract the display workarounds for gen11 and later platforms to a
dedicated display/intel_display_wa.c file to keep these separate from
the SOC / sgunit clock gating that we need on some platforms. The gen11
cutoff here is selected somewhat arbitrarily; this is the point where
workarounds were first assigned dedicated lineage numbers that can be
easily looked up and confirmed in the modern workaround database. It
also avoids any confusion on older platforms where the exact boundaries
between display/GT/other IP blocks wasn't as well-defined as it is
today.
The only programming that happens in gen12lp_init_clock_gating is for
display workarounds that are specific to display version 12 and are not
relevant to ADL-P's display version 13.
Matt Roper [Wed, 6 Sep 2023 23:47:34 +0000 (16:47 -0700)]
drm/i915: Stop forcing clock gating init for future platforms
In the early days of i915, pretty much every platform needed to
initialize _something_ in the clock gating init functions. In some
cases the items initialized were inside the GT (and really should have
been initialized through the GT workaround infrastructure instead).
In other cases they were display programming (sometimes not even related
to "clock gating" at all!) which probably needs to move inside the
display-specific code. The number of initialization tasks that are
truly "clock gating" and don't fall within the GT or display domains is
relatively limited. Let's stop forcing future platforms to always
define a clock gating init hook.
Ville Syrjälä [Tue, 6 Jun 2023 19:14:51 +0000 (22:14 +0300)]
drm/i915/dsb: Avoid corrupting the first register write
i915_gem_object_create_internal() does not hand out zeroed
memory. Thus we may confuse whatever stale garbage is in
there as a previous register write and mistakenly handle the
first actual register write as an indexed write. This can
end up corrupting the instruction sufficiently well to lose
the entire register write.
Make sure we've actually emitted a previous instruction before
attemting indexed register write merging.
Gustavo Sousa [Wed, 30 Aug 2023 12:15:24 +0000 (09:15 -0300)]
drm/i915/cx0: Check and increase msgbus timeout threshold
We have experienced timeout issues when going through the sequence to
access C20 SRAM registers. Experimentation showed that bumping the
message bus timer threshold helped on getting display Type-C connection
on the C20 PHY to work.
While the timeout is still under investigation with the HW team, having
logic to allow forward progress (with the proper warnings) seems useful.
Thus, let's bump the threshold when a timeout is detected.
The bumped value of 0x200 pclk cycles was somewhat arbitrary - 2x the
default value. That value was successfully tested on real hardware that
was displaying timeouts otherwise.
v2:
- Reword commit message to indicate that access to C20 SRAM registers
is not direct. (Radhakrishna)
- Prefer not to use REG_FIELD_PREP() in intel_cx0_phy.c.
(Radhakrishna)
- Simplify intel_cx0_bus_check_and_bump_timer() to use a fixed bumped
value instead of progressively increasing the threshold. (Mika)
Jim Cromie [Sun, 3 Sep 2023 18:46:00 +0000 (12:46 -0600)]
drm/i915: add trailing newlines to msgs
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in maintainer sized chunks.
Jouni Högander [Mon, 28 Aug 2023 08:31:07 +0000 (11:31 +0300)]
drm/i915/psr: Add psr sink error status into sink status debugfs
Normally PSR errors detected by the panel are triggering HPD interrupt and
seen as error in dmesg. Some panels are not triggering the interrupt even
it is requested and they are detecting error. Due to this it would be good
to have possibility to check panel detected errors. Add PSR error status
into PSR sink status debugfs interface.
Luca Coelho [Fri, 25 Aug 2023 08:16:38 +0000 (11:16 +0300)]
drm/i915/tc: remove "fia" from intel_tc_port_fia_max_lane_count()
It is irrelevant for the caller that the max lane count is being
derived from a FIA register, so having "fia" in the function name is
irrelevant. Rename the function accordingly.
This function doesn't really return the pin assignment mask, but the
max lane count derived from that. So rename the function to
mtl_tc_port_get_max_lane_count() to better reflect what it really does.
Suraj Kandpal [Mon, 28 Aug 2023 05:43:00 +0000 (11:13 +0530)]
drm/i915/vdsc: Fill the intel_dsc_get_pps_config function
We have setup both the read and write functions so we can
move ahead and fill in all the readout state from PPS register
into the crtc_state so we can send it for comparision.
--v2
-Shorten comment to just PPSX rather than having the whole
"Readout PPSX register" [Jani]
-Remove pps_temp reinitialization as its being initialized in
the read function [Jani]
-Use REG_FIELD_GET to readout certain fields of dsc registers
[Jani]
--v9
-Place the masks at a more appropriate place [Ankit]
Suraj Kandpal [Mon, 28 Aug 2023 05:42:57 +0000 (11:12 +0530)]
drm/i915/vdsc: Add function to read any PPS register
Add function to read any PPS register based on the
intel_dsc_pps enum provided. Add a function which will call the
new pps read function and place it in crtc state. Only PPS0 and
PPS1 are readout the rest of the registers will be read in upcoming
patches.
--v2
-Changes in read function as PPS enum is removed
-Initialize pps_val as 0 in pps_read func itself [Jani]
-Create a function that gets the required register and call that
in the common read function [Jani]
-Move the drm_WARN_ON one abstraction layer above [Jani]
--v3
-Send both reg values regardless of dsc engine no [Jani]
-Don't use num_vdsc_instances stick to dsc_split field [Ankit]
--v4
-Manipulate the reg values instead of creating MACRO to change
name of pps [Ankit]
--v5
-Read dsc reg values using array rather than individual variables
[Ankit]
-Loop the verification of all dsc engine reads to future proof it
[Ankit]
-Keep the fix me comment in this patch and remove it in later one
where we add other readouts [Ankit]
-Add switch statement that fills in the required registers based on
no of vdsc engines per pipe.
--v7
-Pass no of vdsc instances from read_reg function [Ankit]
-Fix issue where arrays do not get freed on return for read_and_verify
func [Ankit]
--v8
-Simplify reading and verifying of register and remove dynamically
allocated arrays [Jani]
-Remove no_ from no_vdsc_per_pipe and wherever else it applies [Ankit]
--v9
-change variable name to dsc_reg_size rather than vdsc_per_pipe [Ankit]
--v10
-remove switch case as we never enter case1 [Ankit]
--v11
-Add _ prefix for register that are not supposed to be used directly
[Jani]
-Remove REG suffix from register macros [Jani]
-Do not duplicate register read [Jani]
--v12
-Use vdsc_per_pipe rather than array size of dsc_reg [Jani]
Suraj Kandpal [Mon, 28 Aug 2023 05:42:55 +0000 (11:12 +0530)]
drm/i915/vdsc: Add a check for dsc split cases
In intel_vdsc_get_config we only read the primary dsc engine register
and not take into account if the other dsc engine is in use and if
both registers have the same value or not this patche fixes that by
adding a check.
--v3
-Remove superfluos new line [Jani]
-Fix register naming [Jani]
--v5
-pps_temp0/pps_temp1 can be assigned where they are used [Ankit]
Suraj Kandpal [Mon, 28 Aug 2023 05:42:54 +0000 (11:12 +0530)]
drm/i915/vdsc: Refactor dsc register field macro
This patch refactors dsc register related macros that prepares
the values to be written in the register. The current bit shifting
looks bad and going forward will not serve our purpose to readout
dsc register field values the change was suggested by Jani Nikula.
Take into account dma fences in dirtyfb callback. If there is no
unsignaled dma fences perform flush immediately. If there are
unsignaled dma fences perform invalidate and add callback which will
queue flush when the fence gets signaled.
v4:
- Move invalidate before callback is added
v3:
- Check frontbuffer bits before adding any fence fb
- Flush only when adding fence cb succeeds
v2: Use dma_resv_get_singleton
drm/i915: Add new frontbuffer tracking interface to queue flush
We want to wait dma fences in dirtyfb ioctl. As we don't want to make
dirtyfb ioctl as blocking call we need to use
dma_fence_add_callback. Callback used for dma_fence_add_callback is
called from atomic context. Due to this we need to add a new
frontbuffer tracking interface to queue flush.
v3:
- Check schedule work success rather than work being pending
- Init flush work when frontbuffer struct is initialized
v2: Check if flush work is already pending
We are planning to move flush performed from work queue. This
means it is possible to have invalidate -> flip -> flush sequence.
Handle this by clearing possible busy bits on flip.
We are planning to move flush performed from work queue. This
means it is possible to have invalidate -> flip -> flush sequence.
Handle this by clearing possible busy bits on flip.
Jani Nikula [Thu, 31 Aug 2023 10:51:44 +0000 (13:51 +0300)]
media: cec: core: add note about *_from_edid() function usage in drm
In the drm subsystem, the source physical address is, in most cases,
available without having to parse the EDID again. Add notes about
preferring to use the pre-parsed address instead.
Jani Nikula [Fri, 25 Aug 2023 13:01:20 +0000 (16:01 +0300)]
drm/cec: add drm_dp_cec_attach() as the non-edid version of set edid
Connectors have source physical address available in display
info. There's no need to parse the EDID again for this. Add
drm_dp_cec_attach() to do this.
Seems like the set_edid/unset_edid naming is a bit specific now that
there's no need to pass the EDID at all, so aim for attach/detach going
forward.
Suraj Kandpal [Wed, 30 Aug 2023 07:34:38 +0000 (13:04 +0530)]
drm/i915/hdcp: Use correct aux for capability check scenario
Send the correct aux rather than the one derived
from intel_digital_port so that the HDCP version of both monitors
are fetched rather than just the primary one's
Suraj Kandpal [Wed, 30 Aug 2023 07:34:37 +0000 (13:04 +0530)]
drm/i915/hdcp: Use intel_connector as argument for hdcp_2_2_capable
Use intel_connector as argument instead of intel_digital_port in
hdcp_2_2_capable function and dig_port can be later derived from
connector. This will help with getting the correct hdcp version of
particular monitor in a MST setup.
Split out frontbuffer related declarations and static inlines from
gem/i915_gem_object.h into new gem/i915_gem_object_frontbuffer.h.
The main goal is to reduce header interdependencies. With
gem/i915_gem_object.h including display/intel_frontbuffer.h,
modification of the latter causes a whopping 300+ objects to be rebuilt,
while many of the source files actually needing it aren't explicitly
including it at all.
After the change, only 21 objects depend on display/intel_frontbuffer.h,
directly or indirectly.
Imre Deak [Wed, 30 Aug 2023 14:04:21 +0000 (17:04 +0300)]
drm/i915/mtl: Add TC port lockdep assert to AUX power well enabling
Similarly to earlier platforms, assert in the MTL AUX power well
enabling handler for TC AUX CH power wells that the TC port using the
AUX CH is locked.
Imre Deak [Wed, 30 Aug 2023 14:04:20 +0000 (17:04 +0300)]
drm/i915/dp: Drop redundant AUX power get/put in intel_dp_force()
intel_dp_force() takes the AUX power reference as required by the DP AUX
transactions in intel_dp_set_edid(). However the low level AUX handler
takes this reference already so the get/put in intel_dp_force() can be
dropped. This also fixes a problem where the TC port mode changed while
the AUX power well was enabled.
Ville Syrjälä [Fri, 25 Aug 2023 13:44:30 +0000 (16:44 +0300)]
drm/i915/sdvo: Rework DDC bus handling
Each SDVO device can have up to three sets of DDC pins.
Currently we just register a single i2c_adapter for the
entire SDVO device and semi-randomly pick the "correct"
set of DDC pins during intel_sdvo_tmds_sink_detect().
This doesn't make any real sense especially if we have
multiple outputs each with their own dedicated DDC bus.
Let's clean up this mess and register a dedicated
i2c_adapter for each of the possible pin pairs. Each
output (ie. connector) can then pick the correct i2c_adapter
to use for its DDC bus. And we can just switch over to
drm_connector_init_with_ddc() to take care of the
connector->ddc association, which also populates the
"ddc" sysfs symlink as a bonus.
And now that things are based on the actual connector we can
also nuke the sketchy sdvo->controller_output thing.
Ville Syrjälä [Fri, 25 Aug 2023 13:44:29 +0000 (16:44 +0300)]
drm/i915/sdvo: Get rid of the per-connector i2c symlink
We should switch over to the standard "ddc" per-connector
symlink instead of rolling our own thing. The i2c specific
symlink is also in the way of reworking the SDVO DDC handling
(which is a mess atm) so get rid of it.
Ville Syrjälä [Fri, 25 Aug 2023 13:44:26 +0000 (16:44 +0300)]
drm/i915/sdvo: Nuke attached_output tracking
Instead of operating on the output the user specified (via the
connector) the current code tends to operate on whichever outputs
it has detected as attached. That is not how the kms uapi is supposed
to work. So simply get rid of attached_outputs and instead directly
operate on the output the user has specified.
Suraj Kandpal [Mon, 28 Aug 2023 06:34:01 +0000 (12:04 +0530)]
drm/i915/hdcp: Adjust timeout for read in DPMST Scenario
For dpmst hdcp scenario increase the message timeout based
on the number of ports connected as each port needs to be
validated and each will take the prescribed amount of time
for the respective msg_id and total timeout will be
original_timeout * num_ports.
--v2
-Add justification for Adjusting the timeout [Arun]
Suraj Kandpal [Mon, 28 Aug 2023 06:34:00 +0000 (12:04 +0530)]
drm/i915/hdcp: Send the correct aux for DPMST HDCP scenario
Up until now we were sending the base aux stored in dig_port which
is not correct as this causes an issue when monitor is connected via
a DPMST hub causing it to be remote hence we end up seeing AUX
failures so let's send the remote aux in case of DPMST.
Suraj Kandpal [Mon, 28 Aug 2023 06:38:51 +0000 (12:08 +0530)]
drm/i915/hdcp: Propagate aux info in DP HDCP functions
We were propagating dig_port info to dp hdcp2 specific functions.
Let us clean that up and send intel_connector in the following
functions: intel_dp_hdcp2_wait_for_msg, get_receiver_id_list_rx_info,
intel_dp_hdcp2_read_rx_status.
This optimises mst scenarios where aux ends up being remote and not
stored in dig_port and dig_port can always be derived from
intel_connector if needed.
Suraj Kandpal [Mon, 28 Aug 2023 06:33:58 +0000 (12:03 +0530)]
drm/i915/hdcp: Use intel_connector argument in intel_hdcp_shim
Update intel_hdcp_shim funcs specifically read_2_2_message,
write_2_2_message and config_stream_type to use intel_connector
argument instead of intel_digital_port as this will help in getting
correct aux later for dp mst scenarios also already hdcp funcs
derive digital_port from connector and then many funcs again get back
the connector from dig_port which doesn't seem right.
Connector specific hdcp functions can derive dig_port on need basis.
Jani Nikula [Thu, 17 Aug 2023 15:53:08 +0000 (18:53 +0300)]
drm/i915/color: move pre-SKL gamma and CSC enable read to intel_color
Abstract the register access better. The DSPCNTR read could be moved to
either i9xx_plane.c or intel_color.c. The latter feels better, even if
the register is written in the former.
Jani Nikula [Thu, 17 Aug 2023 15:53:04 +0000 (18:53 +0300)]
drm/i915/color: move CHV CGM pipe mode read to intel_color
Add color .get_config hook to read config other than LUTs and CSCs, and
start off with CHV CGM pipe mode to abstract the platform specific
register access better.
Ville Syrjälä [Wed, 5 Jul 2023 20:21:15 +0000 (23:21 +0300)]
drm/i915/sdvo: Pick the TV dotclock from adjusted_mode
port_clock is what the encoder/dpll code is supposed to calculate,
it is not the input clock. Use the dotclock as the target we're
trying to achieve instead.
TODO: the SDVO TV clocking is a mess atm and needs further work
Ville Syrjälä [Wed, 5 Jul 2023 20:21:14 +0000 (23:21 +0300)]
drm/i915: Fully populate crtc_state->dpll
Call *_calc_dpll_params() even in cases where the encoder has
computed the DPLL params for us.
The SDVO TV output code doesn't populate crtc_state->dpll.dot
leading to the dotclock getting calculated as zero, and that
leads to all kinds of real problems. The g4x DP code also
doesn't populate the derived dividers nor .vco, which could
also create some confusion.
Ville Syrjälä [Wed, 5 Jul 2023 20:21:13 +0000 (23:21 +0300)]
drm/i915: Don't warn about zero N/P in *_calc_dpll_params()
Allow *_calc_dpll_params() to be called even if the N/P dividers
are zero without warning. We'll want to call these to make sure the
derived values are fully computed, but not all users (VLV DSI in
particular) even enable the DPLL and thus the dividers will
be left at zero.
It could also be possible that the BIOS has misprogrammed the DPLL
(IIRC happened with some SNB machines with 4k+ displays) and thus
we'll currently generate a lot of dmesg spew. Better be silent and
just let the normal state checker/etc. deal with any driver bugs.
Ville Syrjälä [Wed, 5 Jul 2023 20:21:10 +0000 (23:21 +0300)]
drm/i915/sdvo: Issue SetTargetOutput prior to GetAttachedDisplays
I have at least one SDVO device (some Lenovo DVI-I ADD2 card,
based on Conexant CX25904) where GetAttachedDisplays returns
success but fails to report any attached displays unless we
precede the command with a SetTargetOutput. Make it so.
I wasn't able to spot anything in the SDVO spec stating that
this should be necessary, but real world wins over spec.
Imre Deak [Tue, 22 Aug 2023 11:30:15 +0000 (14:30 +0300)]
drm/i915: Fix HPD polling, reenabling the output poll work as needed
After the commit in the Fixes: line below, HPD polling stopped working
on i915, since after that change calling drm_kms_helper_poll_enable()
doesn't restart drm_mode_config::output_poll_work if the work was
stopped (no connectors needing polling) and enabling polling for a
connector (during runtime suspend or detecting an HPD IRQ storm).
After the above change calling drm_kms_helper_poll_enable() is a nop
after it's been called already and polling for some connectors was
disabled/re-enabled.
Fix this by calling drm_kms_helper_poll_reschedule() added in the
previous patch instead, which reschedules the work whenever expected.
Fixes: d33a54e3991d ("drm/probe_helper: sort out poll_running vs poll_enabled") CC: stable@vger.kernel.org # 6.4+ Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230822113015.41224-2-imre.deak@intel.com
Imre Deak [Tue, 22 Aug 2023 11:30:14 +0000 (14:30 +0300)]
drm: Add an HPD poll helper to reschedule the poll work
Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was disabled for all connectors and hence
output_poll_work was not running).
This is needed by the next patch fixing HPD polling on i915.
Matt Roper [Mon, 21 Aug 2023 18:06:28 +0000 (11:06 -0700)]
drm/i915/display: Eliminate IS_METEORLAKE checks
Most of the IS_METEORLAKE checks in the display code shouldn't actually
be tied to MTL as a platform, but rather to the Xe_LPD+ display IP
(which is used in MTL, but may show up again in future platforms). In
cases where we're trying to match that specific IP, use a version check
against IP_VER(14, 0). For cases where we're just handling new behavior
introduced by this IP (but which may also be inherited by future IP as
well), use a ver >= 14 check.
The one exception here is the stolen memory workaround Wa_13010847436
(which is mislabelled as "Wa_22018444074" in the code). That's truly a
MTL-specific issue rather than being tied to any of the IP blocks, so
leaving the condition as IS_METEORLAKE is correct there.
Matt Roper [Mon, 21 Aug 2023 18:06:26 +0000 (11:06 -0700)]
drm/i915: Eliminate IS_MTL_DISPLAY_STEP
Stepping-specific display behavior shouldn't be tied to MTL as a
platform, but rather specifically to the Xe_LPD+ IP. Future non-MTL
platforms may re-use this IP and will need to follow the exact same
logic and apply the same workarounds. IS_MTL_DISPLAY_STEP() is dropped
in favor of a new macro IS_DISPLAY_IP_STEP() that only checks the
display IP version.
v2:
- Rename macro to IS_DISPLAY_IP_STEP for consistency with the
corresponding GT macro and handle steppings the same way.
v3:
- Drop the automatic "STEP_" pasting.
v4:
- Implement IS_DISPLAY_IP_STEP on top of IS_DISPLAY_IP_RANGE /
IS_DISPLAY_STEP building blocks and make the parameters from/until
instead of begin/fixed. (Jani)
- Fix usage details in comment.
v5:
- Tweak macro comment. (Gustavo)
Ankit Nautiyal [Thu, 17 Aug 2023 14:24:59 +0000 (19:54 +0530)]
drm/i915/dp: Check if force_dsc_output_format is possible
Currently for testing an output format with DSC, we just force the
output format, without checking if it can be supported.
This also creates an issue where there is a PCON which might need to
convert from forced output format to the format to sink format.
Ankit Nautiyal [Thu, 17 Aug 2023 14:24:57 +0000 (19:54 +0530)]
drm/i915/dp: Get optimal link config to have best compressed bpp
Currently, we take the max lane, rate and pipe bpp, to get the maximum
compressed bpp possible. We then set the output bpp to this value.
This patch provides support to have max bpp, min rate and min lanes,
that can support the min compressed bpp.
v2:
-Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
-Fix the checks for limits->max/min_bpp while iterating over list of
valid DSC bpcs. (Stan)
v3:
-Refactor the code to have pipe bpp/compressed bpp computation and slice
count calculation separately for different cases.
v4:
-Separate the pipe_bpp calculation for eDP and DP.
v5:
-Get rid of magic numbers for max and min bpp,
and improve documentation. (Stan).
-Use functions for {src_sink}_{min_max}_compressed_bpp (Ville).
v6:
-Remove lines to set link config to max.
v7:
-Split the part to separate edp and dp functions for computing DSC BPP
into separate patch.
v8:
-Separate mechanism to get compressed bpp for ICL,TGL and XELPD+.
projects / thirdparty / kernel / linux.git / log
