José Roberto de Souza [Wed, 29 Jun 2022 13:47:21 +0000 (06:47 -0700)]
drm/i915: Drain freed object after suspend display
Display is turned off by i915_drm_suspend() during the suspend
procedure, removing the last reference of some gem objects that were
used by display.
The issue is that those objects are only actually freed when
mm.free_work executed and that can happen very late in the suspend
process causing issues.
So here draining all freed objects released by display fixing suspend
issues.
Jani Nikula [Tue, 21 Jun 2022 12:37:32 +0000 (15:37 +0300)]
drm/i915/bios: debug log ddi port info after parsing
The ddc pin and aux channel sanitization may disable DVI/HDMI and DP,
respectively, of ports parsed earlier, in "last one wins" fashion. With
parsing and printing interleaved, we'll end up logging support first and
disabling later anyway.
Now that we've split ddi port info parsing and printing, take it further
by doing the printing in a separate loop, fixing the logging.
Note that this also changes the logging order from VBT child device
order to port number order.
Hangyu Hua [Fri, 24 Jun 2022 13:04:06 +0000 (06:04 -0700)]
drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()
If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.
Dan Carpenter [Fri, 24 Jun 2022 06:39:24 +0000 (09:39 +0300)]
drm/i915: Fix error code in icl_compute_combo_phy_dpll()
This function is supposed to return zero or negative error codes but it
accidentally returns true on failure.
Fixes: 92a020747d6c ("drm/i915: Split shared dpll .get_dplls() into compute and get phases") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YrVcHArNMTGCSy+9@kili Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Thu, 23 Jun 2022 13:08:58 +0000 (16:08 +0300)]
drm/i915: Use _MMIO_PIPE2() where appropriate
Stop hand rolling _MMIO_TRANS2() and just use the real thing.
Note that this register isn't even used atm, hence why this
builds despite the _PIPE2() macro not actually existing.
Ville Syrjälä [Wed, 13 Apr 2022 19:26:07 +0000 (22:26 +0300)]
drm/i915: Eliminate PIPECONF RMWs from .color_commit()
Eliminate the PIPECONF RMWs from .comit_commit() so
that we can finally declare the whole vblank evade part
(and the noarm() part) of the pipe commit free of register
reads. Or at least I hope that's the last read...
Only the i9xx/ilk codepaths need this for now, but let's
add the same thing for hsw+ just in case we want to start
calling that during fastsets at some point (eg. to change
dithering settings/etc.).
Should open up the way to start experimenting with
different DSB usage approaches for pipe commits.
Anshuman Gupta [Thu, 16 Jun 2022 12:22:49 +0000 (17:52 +0530)]
drm/i915/dgfx: Disable d3cold at gfx root port
Currently i915 disables d3cold for i915 pci dev.
This blocks D3 for i915 gfx pci upstream bridge (VSP).
Let's disable d3cold at gfx root port to make sure that
i915 gfx VSP can transition to D3 to save some power.
We don't need to disable/enable d3cold in rpm, s2idle
suspend/resume handlers. Disabling/Enabling d3cold at
gfx root port in probe/remove phase is sufficient.
José Roberto de Souza [Fri, 17 Jun 2022 19:06:29 +0000 (12:06 -0700)]
drm/i915: Call i915_gem_suspend() only after display is turned off
When the last reference of a gem object is removed it is added to the
mm.free_list list and mm.free_work is queued to actually free the
object.
So gem objects that had their last reference removed by display during
drm_atomic_helper_shutdown() are added to mm.free_list what could
cause that mm.free_work is executed at the same time as
intel_runtime_pm_driver_release() causing raw-wakerefs warning.
So here only calling i915_gem_suspend() and by consequence
i915_gem_drain_freed_objects() only after display is down making
sure all display gem objecs are freed when
intel_runtime_pm_driver_release() is executed.
Animesh Manna [Mon, 20 Jun 2022 06:51:38 +0000 (12:21 +0530)]
drm/i915/bios: calculate panel type as per child device index in VBT
Each LFP may have different panel type which is stored in LFP data
data block. Based on the child device index respective panel-type/
panel-type2 field will be used.
v1: Initial rfc verion.
v2: Based on review comments from Jani,
- Used panel-type instead addition panel-index variable.
- DEVICE_HANDLE_* name changed and placed before DEVICE_TYPE_*
macro.
v3:
- passing intel_bios_encoder_data as argument of
intel_bios_init_panel(). Passing NULL to indicate encoder is not
initialized yet for dsi as current focus is to enable dual EDP. [Jani]
v4:
- encoder->devdata used which is initialized before from vbt
structure. [Jani]
Jason A. Donenfeld [Mon, 13 Jun 2022 10:22:41 +0000 (12:22 +0200)]
drm/i915/display: Re-add check for low voltage sku for max dp source rate
This reverts commit 73867c8709b5 ("drm/i915/display: Remove check for
low voltage sku for max dp source rate"), which, on an i7-11850H iGPU
with a Thinkpad X1 Extreme Gen 4, attached to a LG LP160UQ1-SPB1
embedded panel, causes wild flickering glitching technicolor
pyrotechnics on resumption from suspend. The display shows strobing
colors in an utter disaster explosion of pantone, as though bombs were
dropped on the leprechauns at the base of the rainbow.
Rebooting the machine fixes the issue, presumably because the display is
initialized by firmware rather than by i915. Otherwise, the GPU appears
to work fine.
Bisection traced it back to this commit, which makes sense given the
issues.
Note: This re-opens, and puts back to the drawing board,
https://gitlab.freedesktop.org/drm/intel/-/issues/5272 which was fixed
by the regressing commit.
Fixes: 73867c8709b5 ("drm/i915/display: Remove check for low voltage sku for max dp source rate") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220613102241.9236-1-Jason@zx2c4.com
Jani Nikula [Thu, 16 Jun 2022 09:48:15 +0000 (12:48 +0300)]
drm/i915/display: split out modeset verification code
Add new file intel_modeset_verify.c for high level modeset verification
code to declutter intel_display.h. The new file is supposed to be about
crtc/encoder/connector verification; the state verification for very
specific functionality such as plls or wm should be placed next to the
code it verifies.
Ville Syrjälä [Wed, 15 Jun 2022 15:14:44 +0000 (18:14 +0300)]
drm/i915/bios: Don't parse the DPS panel type when the VBT does not have it
Older VBTs don't have all the stuff we've defined for the
LVDS options block (40). In particular we're currently parsing
the DPS panel type bits even though they may not exist, which
could mean we end up flagging the machine as supporting static
DRRS when the VBT declared no such thing.
We don't actually have a clear idea which VBT versions have
which bits so we rely on the block size instead.
Here's a quick list from my VBT stash:
mgm version 108 -> 4 bytes
alv version 120 -> 4 bytes
cst version 134 -> 14 bytes
pnv version 144 -> 14 bytes
cl version 142 -> 16 bytes
ctg version 155 -> 24 bytes
Ville Syrjälä [Wed, 15 Jun 2022 15:14:43 +0000 (18:14 +0300)]
drm/i915/bios: Move panel_type stuff out of parse_panel_options()
Parsing the panel_type is a bit special and should be done
before we parse anything else potentially panel-specific from
the VBT. So move it out from parse_panel_options(). It doesn't
neet to be there anyway since it'll do its own LVDS options
block lookup.
Ville Syrjälä [Thu, 16 Jun 2022 09:55:30 +0000 (12:55 +0300)]
drm/i915: Remove bogus LPT iCLKIP WARN
The WARN shouldn't have been added yet. For the moment the
clock that gets passed here is just what the user has requested
(via the modeline) and may not be exactly what iCLKIP can
generate.
Later on the plan is to change things so that we already get
passed the exact clock here, at which point the WARN should
be reintroduced.
Ville Syrjälä [Wed, 15 Jun 2022 17:48:51 +0000 (20:48 +0300)]
drm/i915: Sanitize underrun reporting before turning off any pipes
Make sure FIFO underrun reporting is flagged as disabled very
early during the state readout so that we don't get any
spurious FIFO underruns reports from intel_crtc_disable_noatomic().
Jouni Högander [Fri, 10 Jun 2022 08:54:28 +0000 (11:54 +0300)]
drm/i915: Do not start connector polling if display is disabled
Currently we are starting connector polling if display is disabled
using disable_display module parameter. Polling is just returning
always "not connected" state. This can be optimized by not starting
polling at all.
Jouni Högander [Fri, 10 Jun 2022 08:54:27 +0000 (11:54 +0300)]
drm/i915/opregion: add function to check if headless sku
Export headless sku bit (bit 13) from opregion->header->pcon as an
interface to check if our device is headless configuration.
This is mainly targeted for hybrid gfx systems. E.g. when display
is not supposed to be connected discrete graphics card it's
opregion can inform this is headless graphics card.
v3: Dummy version is now static inline function
v2: Check also opregion version
Ville Syrjälä [Tue, 3 May 2022 18:22:30 +0000 (21:22 +0300)]
drm/i915: Skip FDI vs. dotclock sanity check during readout
The VBIOS/GOP may not program the FDI M/n vs. dotclock entirely
consistently. Eg. on a SNB Thinkpad X220 LVDS I see dotclock of
69.286 MHz (the best the DPLL can do) vs. FDI M/N 69.3 MHz
(matches what the EDID actually declares).
Ville Syrjälä [Wed, 4 May 2022 21:21:09 +0000 (00:21 +0300)]
drm/i915: Introduce struct iclkip_params
Pull the various iCLKIP parameters into a struct. Later on
we'll reuse this during the state computation to determine
the exact dotclock the hardware will be generating for us.
v2: Don't lose the phaseinc calculation
v3: Drop the misplaced '#include <intel_pch_refclk.h>' from intel_crt.c (Jani)
Ville Syrjälä [Wed, 4 May 2022 12:33:50 +0000 (15:33 +0300)]
drm/i915: Extract intel_crtc_dotclock()
Extract intel_crtc_dotclock() from ddi_dotclock_get(). We'll reuse
this during state computation in order to determine the actual final
dotclcok after the DPLL computation has been done (which may not give
us the exact same port_clock that we fed in).
José Roberto de Souza [Wed, 8 Jun 2022 20:33:44 +0000 (13:33 -0700)]
drm/i915/display: Fix handling of enable_psr parameter
Commit 3cf050762534 ("drm/i915/bios: Split VBT data into per-panel vs.
global parts") cause PSR to be disabled when enable_psr has the
default value and there is at least one DP port that do not supports
PSR.
That was happening because intel_psr_init() is called for every DP
port and then enable_psr is globaly set to 0 based on the PSR support
of the DP port.
Here dropping the enable_psr overwritten and using the VBT PSR value
when enable_psr is set as default.
Fixes: 3cf050762534 ("drm/i915/bios: Split VBT data into per-panel vs. global parts") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220608203344.513082-1-jose.souza@intel.com
Ville Syrjälä [Thu, 2 Jun 2022 20:56:49 +0000 (23:56 +0300)]
drm/i915: Update eDP fast link training link rate parsing
We're not parsing the 5.4 Gbps value for the old eDP fast link
training link rate, nor are we parsing the new fast link training
link rate field. Remedy both.
Also we'll now use the actual link rate instead of the DPCD BW
register value.
Note that we're not even using this information for anything
currently, so should perhaps just nuke it all unless someone
is planning on implementing fast link training finally...
v2: Stop using the DPCD BW values (Jani)
*20 instead of *2 to get the rate in correct units (Jani)
Ville Syrjälä [Fri, 3 Jun 2022 16:58:41 +0000 (19:58 +0300)]
drm/i915: Initialize eDP source rates after per-panel VBT parsing
We'll need to know the VBT panel_type before we can determine the
maximum link rate for eDP. To that end move
intel_dp_set_source_rates() & co. to be called after the per-panel
VBT parsing has been done.
intel_dp_mst_encoder_init() depends on the source rates so we'll
have to do it a bit later as well.
Luca Coelho [Tue, 7 Jun 2022 07:44:33 +0000 (10:44 +0300)]
drm/i915: remove noisy logs in intel_dp_dsc_get_output_bpp()
The intel_dp_dsc_get_output_bpp() function outputs two lines of
unconditional logs, which was okay when it was called only once. But
now, we also call this function from intel_dp_mode_valid(), which is
in turn called for every mode we need to validate. This causes a lot
of useless noise.
Remove the unconditional prints to avoid spamming the logs. Also
remove one more print that is not unconditional, but is related.
Jani Nikula [Thu, 2 Jun 2022 09:45:42 +0000 (12:45 +0300)]
drm/i915/regs: split out intel audio register definitions
Split out audio registers to a header of its own to reduce the size of
i915_reg.h.
TODO: Remove direct audio register access from intel_ddi.c. However,
unification of audio get config is cumbersome due to the audio enable
bit being in the DP or HDMI registers on older platforms.
Ville Syrjälä [Tue, 31 May 2022 19:18:44 +0000 (22:18 +0300)]
drm/i915: Treat DMRRS as static DRRS
Some machines declare DRRS type = seamless, DRRS = no, DMRRS = yes.
I *think* DMRRS stands for "dynamcic media refresh rate", and
I suspect the way it's meant to work is that it lets the driver
switch refresh rates to match the frame rate for media playback.
Obviously for us all that kind of policy stuff is entirely up to
userspace, so the only thing we may do is make the extra refresh
rate(s) available.
So let's treat this case as just static DRRS for now. In the
future We might want to differentiate the "seamless w/ downclocking"
vs. "seamless w/o downclocking" cases so that we could do seamless
refresh rate changes for systems that only claim to support DMRRS.
Ville Syrjälä [Tue, 31 May 2022 19:18:42 +0000 (22:18 +0300)]
drm/i915/bios: Fix aggressiveness typos
Fix various typos around "aggressiveness". Note that
the VBT spec also sometimes missspells it as
"agressiveness" so I guess that's where some of the typos
came from.
Ville Syrjälä [Tue, 31 May 2022 19:18:41 +0000 (22:18 +0300)]
drm/i915: Accept more fixed modes with VRR panels
It seem that when dealing with VRR capable eDP panels we need
to accept fixed modes with variable vblank length (which is what
VRR varies dynamically). Typically the preferred mode seems to be
a non-VRR more (lowish dotclock/refresh rate + short vblank).
We also have examples where it looks like even the hblank length
is a bit different between the preferred mode vs. VRR mode(s).
So let's just accept anything that has matching hdisp+vdisp+flags.
v2: Document that is_alt_drrs_mode() is a subset of is_alt_vrr_mode() (Jani)
Ville Syrjälä [Tue, 3 May 2022 18:22:36 +0000 (21:22 +0300)]
drm/i915: Check hw.enable and hw.active in intel_pipe_config_compare()
Don't see a real reson not to check hw.active and hw.enable in
intel_pipe_config_compare(). We do have some checks for them
at a higher level, but I think better check them also in
intel_pipe_config_compare() in case something else doesn't
do a thorough enough job.
Also shuffle the mst_master_transcoder check next to the
cpu_transcoder check for a bit of consistency.
Use the state+crtc calling convention for intel_modeset_pipe_config()
and othere related functions. Many of these need the full atomic state
anyway so passing it all the way through is just nicer than having to
worry about whether it can actually be extracted from eg. the crtc
state passed in.
Ville Syrjälä [Tue, 3 May 2022 18:22:19 +0000 (21:22 +0300)]
drm/i915: Clean up DPLL related debugs
The debugs in lower level DPLL code don't really provide any
useful extra information AFAICS. Better just streamline the
code and just put the necessary debugs (to identify at which
step the modeset failed) into the higher level code. In
addition we'll get the full state dump as well, which should
hopefully have enough information to figure out what went wrong.
Ville Syrjälä [Tue, 3 May 2022 18:22:17 +0000 (21:22 +0300)]
drm/i915: Split shared dpll .get_dplls() into compute and get phases
Split the DPLL state computation into a separate function
from the current .get_dplls() which currently serves a dual duty
by also reserving the shared DPLLs.
Commit 30e114ef4b16 ("drm/i915/tc: Check for DP-alt, legacy sinks before
taking PHY ownership") defaults any disconnected Type-C ports to TBT-alt
mode which presents a problem (which could most likely result in a system
hang) when userspace forces a modeset on a Type-C port that is wired for
legacy HDMI. The following warning is seen when Weston forces a modeset
on a disconnected legacy Type-C port (HDMI) on a TGL based Gigabyte system:
(https://www.gigabyte.com/Mini-PcBarebone/GB-BSi3-1115G4-rev-10#ov)
Continuing with the modeset without setting the DDI clock results in
more warnings and eventually a system hang. This does not seem to
happen with disconnected legacy or DP-alt DP ports because the clock
rate defaults to 162000 (which is a valid TBT clock) during the link
training process. Therefore, to fix this issue, this patch avoids
setting disconnected Type-C legacy ports to TBT-alt mode which prevents
the selection of TBT PLL when a modeset is forced.
v2: (Imre)
- Retain the check for legacy hotplug live status to account for
incorrect VBTs.
Ville Syrjälä [Tue, 10 May 2022 10:42:40 +0000 (13:42 +0300)]
drm/i915/bios: Determine panel type via PNPID match
Apparently when the VBT panel_type==0xff we should trawl through
the PNPID table and check for a match against the EDID. If a
match is found the index gives us the panel_type.
Tried to match the Windows behaviour here with first looking
for an exact match, and if one isn't found we fall back to
looking for a match w/o the mfg year/week.
v2: Rebase due to vlv_dsi changes
v3: Adjust to .get_panel_type() vfunc
Ville Syrjälä [Tue, 10 May 2022 10:42:39 +0000 (13:42 +0300)]
drm/i915/bios: Split VBT data into per-panel vs. global parts
Move the panel specific VBT parsing to happen during the
output probing stage. Needs to be done because the VBT
parsing will need to look at the EDID to determine
the correct panel_type on some machines.
We split the parsed VBT data (i915->vbt) along the same
boundary. For the moment we just hoist all the panel
specific stuff into connector->panel.vbt since that seems
like the most convenient place for eg. the backlight code.
Note that we simply drop the drrs type check from
intel_drrs_frontbuffer_update() since that operates on the whole
device rather than a specific connector/encoder. But the check
was just a micro optimization so removing it doesn't actually
mattter for correctness.
TODO: Lot's of cleanup to be done in the future. Eg. most of
the DSI stuff could probably be eliminated entirely and just
parsed on demand during DSI init.
v2: Note the intel_drrs_frontbuffer_update() change
Ville Syrjälä [Tue, 10 May 2022 10:42:38 +0000 (13:42 +0300)]
drm/i915/bios: Split VBT parsing to global vs. panel specific parts
Parsing the panel specific data (anything that depends on panel_type)
from VBT is currently happening too early. Split the whole thing
into global vs. panel specific parts so that we can start doing
the panel specific parsing at a later time.
v2: Clarify that this is about panel_type (Jani)
Split out the leak checks (Jani)
Ville Syrjälä [Tue, 10 May 2022 10:42:37 +0000 (13:42 +0300)]
drm/i915/bios: Split parse_driver_features() into two parts
We use the "driver features" block for two different kinds
of data: global data, and per panel data. Split the function
into two parts along that line so that we can start doing the
parsing in two different locations.
Ville Syrjälä [Tue, 10 May 2022 10:42:36 +0000 (13:42 +0300)]
drm/i915/pps: Keep VDD enabled during eDP probe
Disable the delayed VDD off work during the eDP probe.
If we never turn off the VDD then we can't violate the
panel's power sequencing delays despite not having read
them out yet from the VBT.
This is mostly a belt+suspenders type of thing since the
the timeout we'd use for the delayed work should be long
enough that this won't normally happen. But I don't really
like relying on timeouts for correctless so might as well
make sure.
Ville Syrjälä [Tue, 10 May 2022 10:42:35 +0000 (13:42 +0300)]
drm/i915/pps: Reinit PPS delays after VBT has been fully parsed
During the eDP probe we may not yet know the panel_type used
to index the VBT panel tables. So the initial eDP probe will have
to be done without that, and thus we won't yet have the PPS delays
from the VBT. Once the VBT has been fully parse we should reinit
the PPS delays to make sure it's fully accounted for.
Ville Syrjälä [Tue, 10 May 2022 10:42:33 +0000 (13:42 +0300)]
drm/i915/pps: Stash away original BIOS programmed PPS delays
In order to do the panel VBT parsing after the EDID read
(needed to determine panel_type from PNPID) we need to stash
away the original BIOS programmed PPS delays so that we
can consult them again when we reinit the PPS delays after
the VBT parsing has been done.
Ville Syrjälä [Tue, 10 May 2022 10:42:32 +0000 (13:42 +0300)]
drm/i915/pps: Don't apply quirks/etc. to the VBT PPS delays if they haven't been initialized
Skip QUIRK_INCREASE_T12_DELAY and the t11_t12 adjustment of the
VBT PPS delays if we've not yet initialized them. Will be important
later when the PPS delay init can happen before VBT parsing.
Balasubramani Vivekanandan [Thu, 26 May 2022 06:49:35 +0000 (12:19 +0530)]
drm/i915/display/adl_p: Updates to HDMI combo PHY voltage swing table
New updates to HDMI combo PHY voltage swing tables. Actually with this
update (bspec updated on 08/17/2021), the values are reverted back to be
same as icelake for HDMI combo PHY.
Vandita Kulkarni [Wed, 25 May 2022 08:04:01 +0000 (13:34 +0530)]
drm/i915/dg2: Support 4k@30 on HDMI
This patch adds a fix to support 297MHz of dot clock by calculating
the pll values using synopsis algorithm.
This will help to support 4k@30 mode for HDMI monitors on DG2.
v2: As per the algorithm, set MPLLB VCO range control bits to 3,
in register SNPS_PHY_MPLLB_DIV for 297Mhz. (Matt)
Based on a bspec update the DMC firmware's flip queue handling events
need to be disabled before enabling DC5/6. i915 doesn't use the flip
queue feature atm, so disable it already after loading the firmware.
This removes some overhead of the event handler which runs at a 1 kHz
frequency.
Bspec: 49193, 72486, 72487
v2:
- Fix the DMC pipe A register offsets for GEN12.
- Disable the events on DG2 only on pipe A..D .
v3: (Lucas)
- Add TODO: to clarify the disabling sequence on all D13+
- s/intel_dmc_has_fw_payload/has_dmc_id_fw/
- s/simple_flipq/flipq/
- s/_GEN12,_GEN13/TGL_,ADLP_/
- s/MAINDMC/DMC/
v4:
- Only disable flip queues on TGL/DG2, as on other platforms the
corresponding event handlers don't exist.
Ville Syrjälä [Thu, 19 May 2022 14:00:10 +0000 (17:00 +0300)]
drm/i915: Rename block_size()/block_offset()
Give block_size()/block_offset() a "raw_" prefix since they
both operate on the "raw" (as in not duplicated) BDB block
contents.
What actually spurred this was a conflict between intel_bios.c
block_size() vs. block_size() from blkdev.h. That only
happened to me on a custom tree where we somehow manage to
include blkdev.h into intel_bios.c. But I think the rename
makes sense anyway to clarify the purpose of these functions.
Jani Nikula [Fri, 20 May 2022 09:46:00 +0000 (12:46 +0300)]
drm/i915/dsi: fix VBT send packet port selection for ICL+
The VBT send packet port selection was never updated for ICL+ where the
2nd link is on port B instead of port C as in VLV+ DSI.
First, single link DSI needs to use the configured port instead of
relying on the VBT sequence block port. Remove the hard-coded port C
check here and make it generic. For reference, see commit f915084edc5a
("drm/i915: Changes related to the sequence port no for") for the
original VLV specific fix.
Second, the sequence block port number is either 0 or 1, where 1
indicates the 2nd link. Remove the hard-coded port C here for 2nd
link. (This could be a "find second set bit" on DSI ports, but just
check the two possible options.)
Third, sanity check the result with a warning to avoid a NULL pointer
dereference.
Dale B Stimson [Thu, 19 May 2022 08:57:32 +0000 (09:57 +0100)]
drm/i915/pcode: Add a couple of pcode helpers
Some dGfx pcode commands take additional sub-commands and parameters. Add a
couple of helpers to help formatting these commands to improve code
readability.
v2: Fixed commit author (Rodrigo)
v3: Function rename and convert to new uncore interface for pcode functions
Remove unnecessary #define's (Andi)
v4: Another function rename
Ashutosh Dixit [Thu, 19 May 2022 08:57:31 +0000 (09:57 +0100)]
drm/i915/pcode: Extend pcode functions for multiple gt's
Each gt contains an independent instance of pcode. Extend pcode functions
to interface with pcode on different gt's. To avoid creating dependency of
display functionality on intel_gt, pcode function interfaces are exposed in
terms of uncore rather than intel_gt. Callers have been converted to pass
in the appropritate (i915 or intel_gt) uncore to the pcode functions.
v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo)
v3: Retain previous function names to eliminate needless #defines (Rodrigo)
v4: Move out i915_pcode_init() to a separate patch (Tvrtko)
Remove duplicated drm_err/drm_dbg from intel_pcode_init() (Tvrtko)
Ashutosh Dixit [Thu, 19 May 2022 08:57:30 +0000 (09:57 +0100)]
drm/i915: Introduce has_media_ratio_mode
Media ratio mode (the ability for media IP to work at a different frequency
from the GT) is available for a subset of dGfx platforms supporting
GuC/SLPC. Introduce 'has_media_ratio_mode' flag in intel_device_info to
identify these platforms and set it for XEHPSDV and DG2/ATS-M.
projects / users / jedix / linux-maple.git / log