Imre Deak [Wed, 8 Feb 2023 11:42:57 +0000 (13:42 +0200)]
drm/i915: Fix system suspend without fbdev being initialized
If fbdev is not initialized for some reason - in practice on platforms
without display - suspending fbdev should be skipped during system
suspend, fix this up. While at it add an assert that suspending fbdev
only happens with the display present.
Ville Syrjälä [Wed, 8 Feb 2023 01:55:08 +0000 (03:55 +0200)]
drm/i915: Use encoder->devdata in eDP init
Since we now populate encoder->devdata for all DP capable
platforms we can consult it directly during the eDP
connector init instead of taking a detour via some global
list/array.
Unfortunately we can't quite get rid of
intel_dp_is_port_edp() since it's still used by the higher
level ilk/vlv/chv output setup code.
Ville Syrjälä [Tue, 14 Feb 2023 07:38:18 +0000 (09:38 +0200)]
drm/i915: Iterate all child devs in intel_bios_is_port_present()
Instead of consulting vbt.ports[] lets just go through the
whole child device list to check whether a specific port
was declared by the VBT or not.
Note that this doesn't change anything wrt. detecting duplicate
child devices with the same port as vbt.ports[] would also always
contain exactly one of the duplicates.
v2: Include a is_port_valid() check to deal with some broken VBTs
Mention something about duplicate port detection (Jani)
Ville Syrjälä [Wed, 8 Feb 2023 01:55:06 +0000 (03:55 +0200)]
drm/i915: Pass devdata to intel_bios_port_aux_ch()
Currently intel_bios_port_aux_ch() digs out the devdata
(VBT child device info) from the vbt.ports[] array. We
need to get rid of that, so just pass in the correct
encoder->devdata (now that we have it also for g4x+ ports)
directly.
Ville Syrjälä [Wed, 8 Feb 2023 01:55:05 +0000 (03:55 +0200)]
drm/i915: Populate encoder->devdata for g4x+ DP/HDMI ports
Let's make encoder->devdata (the VBT information for the port)
available on g4x+ platforms as well. Much easier when you can
just grab it there instead of trying to find it from some global
list array based on the port.
Note that (unlike DDI platforms) we don't currently require
that each DP/HDMI port is actually declared in VBT. Perhaps
in the future we may want to rethink that, but for now just
stick in a debug+FIXME as a reminder.
Ville Syrjälä [Wed, 8 Feb 2023 01:55:04 +0000 (03:55 +0200)]
drm/i915: Consult the registered encoders for the ICL combo PHY w/a
Display WA #1178 calls us to tweak some magic bits when doing AUX
to an external combo PHY port. Instead of looking to see if the VBT
has declared such a port (which could in theory even alias with a
declared eDP port on the same PHY) just check the real situation
based on the registered encoders.
The only slight chicken vs. egg situation here is during output
probing. But typically we'd register the eDP ports first and so
once we get to probe anything external on the combo PHY we have
already determined if it's eDP or not.
Ville Syrjälä [Wed, 8 Feb 2023 01:55:03 +0000 (03:55 +0200)]
drm/i915: Replace intel_bios_is_port_hpd_inverted() with intel_bios_encoder_hpd_invert()
intel_bios_is_port_hpd_inverted() is only used on bxt/glk on
which we always have encoder->devdata available. So consult
that instead of digging around in vbt.ports[].
And rename the function to match the common pattern.
Ville Syrjälä [Wed, 8 Feb 2023 01:55:02 +0000 (03:55 +0200)]
drm/i915: Replace intel_bios_is_lane_reversal_needed() with intel_bios_encoder_lane_reversal()
The sole user of intel_bios_is_lane_reversal_needed() has
the devdata already located, so pass it in directly instead
of digging it again from vbt.ports[].
And rename the function to follow the common pattern for
these things.
Ville Syrjälä [Wed, 8 Feb 2023 01:55:01 +0000 (03:55 +0200)]
drm/i915: Replace intel_bios_is_lspcon_present() with intel_bios_encoder_is_lspcon()
We always have encoder->devdata available on the platforms
that can have LSPCON. So let's start looking there instead
of digging it out from vbt.ports[].
And let's rename the function to fit the common pattern
for these things.
Ville Syrjälä [Wed, 8 Feb 2023 01:54:59 +0000 (03:54 +0200)]
drm/i915: Pass the whole encoder to hotplug_enables()
bxt_hotplug_enables() needs to dig out not only the
hpd_pin but also the VBT child device info, so let's just
pass in the whole encoder to avoid having to look things
up multiple times.
Suraj Kandpal [Tue, 14 Feb 2023 05:20:17 +0000 (10:50 +0530)]
drm/i915/dp: Increase slice_height for DP
According VDSC spec 1.2a Section 3.8 Options for Slice
implies that 108 lines is an optimal slice height, but any
size can be used as long as vertical active
integer multiple and maximum vertical slice count requirements are met.
Bspec: 49259
--v3
-remove previous fallback code and return slice_height as 2 [Jani]
Ville Syrjälä [Thu, 9 Feb 2023 22:25:04 +0000 (00:25 +0200)]
drm/i915: Replace wm.max_levels with wm.num_levels and use it everywhere
Replaces wm.max_level with wm.num_levels, since that generally
results in nicer looking code (for-loops can be in standard
form etc.).
Also get rid of the two different wrappers we have for this
(ilk_wm_max_level() and intel_wm_num_levels()). They don't
really do anything for us other than potentially slow things
down if the compiler actually emits the function calls every
time (num_planes*num_wm_levels*higher_level_wm_function_calls
could be a big number). The watermark code already shows up
far too prominently in cpu profiles. Though I must admit that
I didn't look at the generated code this time.
Ville Syrjälä [Thu, 9 Feb 2023 00:32:50 +0000 (02:32 +0200)]
drm/i915: Populate wm.max_level for everyone
Switch ilk+ and skl+ platforms to also setting up
wm.max_level and remove a bunch of if ladders as a result.
There will be a tiny change in the debugfs on CHV machines
that have DVFS disabled in the BIOS. Presviously debugfs
would show the latency for the DVFS level as well, but
that will no longer be the case. Which is arguably better
as that number is absolutely meaningless when DVFS can't
be enabled anyway.
0349c41b0596 ("drm/i915/hwmon: Enable PL1 power limit") is incorrect and
caused a major regression on ATSM. The change enabled the PL1 power limit
but FW sets the default value of the PL1 limit to 0 which implies HW now
works at minimum power and therefore the lowest effective frequency. This
means all workloads now run slower resulting in even GuC FW load operations
timing out, rendering ATSM unusable.
A different solution to the original issue of the PL1 limit being disabled
on ATSM is needed but till that is developed, revert 0349c41b0596.
Jani Nikula [Tue, 7 Feb 2023 11:16:26 +0000 (13:16 +0200)]
drm/i915/bios: set default backlight controller index
With backlight controller set to -1 in intel_panel_init_alloc() to
distinguish uninitialized values, and controller later being set only if
it's present in VBT, we can end up with -1 for the controller:
[drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation
frequency 200 Hz, active high, min brightness 0, level 255,
controller 4294967295
There's no harm if it happens on platforms that ignore controller due to
only one backlight controller being present, like on VLV above, but play
it safe.
Jani Nikula [Tue, 7 Feb 2023 12:40:24 +0000 (14:40 +0200)]
drm/i915/uncore: cast iomem to avoid sparse warning
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs
to be a plain void *. Cast __iomem away and back while the pointer goes
through drmm.
Ville Syrjälä [Tue, 7 Feb 2023 06:43:36 +0000 (08:43 +0200)]
drm/i915: Populate encoder->devdata for DSI on icl+
We now have some eDP+DSI dual panel systems floating around
where the DSI panel is the secondary LFP and thus needs to
consult "panel type 2" in VBT in order to locate all the
other panel type dependant stuff correctly.
To that end we need to pass in the devdata to
intel_bios_init_panel_late(), otherwise it'll just assume
we want the primary panel type. So let's try to just populate
the vbt.ports[] stuff and encoder->devdata for icl+ DSI
panels as well.
We can't do this on older platforms as there we risk a DSI
port aliasing with a HDMI/DP port, which is a totally legal
thing as the DSI ports live in their own little parallel
universe.
Ville Syrjälä [Tue, 7 Feb 2023 06:43:35 +0000 (08:43 +0200)]
drm/i915: Fix VBT DSI DVO port handling
Turns out modern (icl+) VBTs still declare their DSI ports
as MIPI-A and MIPI-C despite the PHYs now being A and B.
Remap appropriately to allow the panels declared as MIPI-C
to work.
Matt Atwood [Wed, 1 Feb 2023 23:28:01 +0000 (15:28 -0800)]
drm/i915: Fix memory leaks in scatterlist
This patch fixes memory leaks on error escapes in i915_scatterlist.c
Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist creation") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230201232801.123684-1-matthew.s.atwood@intel.com
Jonathan Gray [Mon, 6 Feb 2023 04:37:27 +0000 (15:37 +1100)]
drm/i915: Add another EHL pci id
described as "32 Execution Unit (EU) Super SKU" in:
Intel Atom x6000E Series, and Intel Pentium and Celeron N and
J Series Processors for IoT Applications
Datasheet, Volume 1
Document Number: 636112-1.6
Ashutosh Dixit [Fri, 3 Feb 2023 15:53:09 +0000 (07:53 -0800)]
drm/i915/hwmon: Enable PL1 power limit
Previous documentation suggested that PL1 power limit is always
enabled. However we now find this not to be the case on some
platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
initialization.
Bspec: 51864
v2: Add Bspec reference (Gwan-gyeong)
v3: Add Fixes tag
Ville Syrjälä [Wed, 18 Jan 2023 16:30:31 +0000 (18:30 +0200)]
drm/i915/dsb: Introduce intel_dsb_finish()
Introduce a function to emits whatever commands we need
at the end of the DSB command buffer. For the moment we
only do the tail cacheline alignment there, but eventually
we might want to eg. emit an interrupt.
Ville Syrjälä [Wed, 18 Jan 2023 16:30:30 +0000 (18:30 +0200)]
drm/i915/dsb: Split intel_dsb_wait() from intel_dsb_commit()
Starting the DSB execution vs. waiting for it stop are two
totally different things. Split intel_dsb_wait() from
intel_dsb_commit() so that we can eventually allow the DSB
to execute asynchronously.
Jouni Högander [Mon, 23 Jan 2023 07:44:37 +0000 (09:44 +0200)]
drm/i915/fbdev: Implement fb_dirty for intel custom fb helper
After disconnecting damage worker from update logic it's left to fbdev
emulation implementation to have fb_dirty function. Currently intel
fbdev doesn't have it. This is causing problems to features (PSR, FBC,
DRRS) relying on dirty callback.
Implement simple fb_dirty callback to deliver notifications about updates
in fb console.
v4: Add proper Fixes tag and modify commit message
v3: Check damage clip
v2: Improved commit message and added Fixes tag
Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230123074437.475103-1-jouni.hogander@intel.com
Jani Nikula [Thu, 2 Feb 2023 12:04:52 +0000 (14:04 +0200)]
drm/i915/dmc: check incoming dmc id validity
Add validity checks for the dmc ids computed from pipe parameters in
intel_dmc_enable_pipe() and intel_dmc_disable_pipe(). It's slightly
difficult for humans and static analyzers alike to ensure the resulting
dmc ids are within bounds. Just check them and reject invalid ones.
Ville Syrjälä [Tue, 31 Jan 2023 00:21:27 +0000 (02:21 +0200)]
drm/i915: Expose SAGV state via debugfs
Since SAGV is controlled via unidirectional pcode commands
we have no way to query the current state. So instead let's
expose the last programmed state via debugfs. This way we
can at least know whether SAGV should be enabled or not
(which can be important to know when dealing with underruns/etc.).
Ville Syrjälä [Tue, 31 Jan 2023 00:21:26 +0000 (02:21 +0200)]
drm/i915: Keep sagv status updated on icl+
On icl+ SAGV is controlled by masking of the QGV points.
Reduce the QGV point mask to the same kind of enabled vs.
disable information that we had on previous platforms.
Will be useful in answering the question whether SAGV is
actually enabled or not.
Ville Syrjälä [Tue, 31 Jan 2023 00:21:25 +0000 (02:21 +0200)]
drm/i915: Introduce HAS_SAGV()
Introuce a HAS_SAGV() macro to answer the question whether
the platform in general supports SAGV. intel_has_sagv() will
keep on giving us the more specific answer whether the current
device supports SAGV or not.
Ville Syrjälä [Tue, 31 Jan 2023 00:21:24 +0000 (02:21 +0200)]
drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabled
Due to a workaround we have to make sure the WM1 watermarks block/lines
values are sensible even when WM1 is disabled. To that end we copy those
values from WM0.
However since we now keep each wm level enabled on a per-plane basis
it doesn't seem necessary to do that copy when we already have an
enabled WM1 on the current plane. That is, we might be in a situation
where another plane can only do WM0 (and thus needs the copy) but
the current plane's WM1 is still perfectly valid (ie. fits into the
current DDB allocation).
Skipping the copy could avoid reprogramming the plane's registers
needlessly in some cases.
Ville Syrjälä [Mon, 30 Jan 2023 18:05:38 +0000 (20:05 +0200)]
drm/i915/lvds: s/dev_priv/i915/
Do the customary s/dev_priv/i915/ rename and aliasing
'dev' pointer removal. Though various register definitions
still depend on the magic 'dev_priv' variable so not
a 100% conversion.
drm/i915: Implement workaround for CDCLK PLL disable/enable
It was reported that we might get a hung and loss of register access in
some cases when CDCLK PLL is disabled and then enabled, while squashing
is enabled.
As a workaround it was proposed by HW team that SW should disable squashing
when CDCLK PLL is being reenabled.
Ankit Nautiyal [Thu, 22 Dec 2022 04:08:51 +0000 (09:38 +0530)]
drm/i915/hdmi: Go for scrambling only if platform supports TMDS clock > 340MHz
There are cases, where devices have an HDMI1.4 retimer, and TMDS clock rate
is capped to 340MHz via VBT. In such cases scrambling might be supported
by the platform and an HDMI2.0 sink for lower TMDS rates, but not
supported by the retimer, causing blankouts.
So avoid enabling scrambling, if the TMDS clock is capped to <= 340MHz.
v2: Added comment, documenting the rationale to check for TMDS clock,
before going for scrambling. (Arun)
v3: Fixed the function name to check if source supports scrambling. (Jani)
Matt Roper [Fri, 27 Jan 2023 22:43:12 +0000 (14:43 -0800)]
drm/i915/dg1: Drop support for pre-production steppings
Several post-DG1 platforms have been brought up now, so we're well past
the point where we usually drop the workarounds that are only applicable
to internal/pre-production hardware.
Production DG1 hardware always has a B0 stepping for both display and
GT.
Matt Roper [Fri, 27 Jan 2023 22:43:11 +0000 (14:43 -0800)]
drm/i915/tgl: Drop support for pre-production steppings
Several post-TGL platforms have been brought up now, so we're well past
the point where we usually drop the workarounds that are only applicable
to internal/pre-production hardware.
Production TGL hardware always has display stepping C0 or later and GT
stepping B0 or later (this is true for both the original TGL and the U/Y
subplatform).
Andrzej Hajda [Fri, 27 Jan 2023 15:30:02 +0000 (16:30 +0100)]
drm/i915: implement async_flip mode per plane tracking
Current implementation of async flip w/a relies on assumption that
previous atomic commit contains valid information if async_flip is still
enabled on the plane. It is incorrect. If previous commit did not modify
the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE
errors can be observed:
i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080
i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set
v2: update async_flip_planes in more reliable places (Ville)
v3: reset async_flip_planes and do_async_flip in more scenarios (Ville)
v4: move all resets to plane loops (Ville)
Jouni Högander [Mon, 30 Jan 2023 08:06:51 +0000 (10:06 +0200)]
drm/i915/psr: Split sel fetch plane configuration into arm and noarm
SEL_FETCH_CTL registers are armed immediately when plane is disabled.
SEL_FETCH_* instances of plane configuration are used when doing
selective update and normal plane register instances for full updates.
Currently all SEL_FETCH_* registers are written as a part of noarm
plane configuration. If noarm and arm plane configuration are not
happening within same vblank we may end up having plane as a part of
selective update before it's PLANE_SURF register is written.
Fix this by splitting plane selective fetch configuration into arm and
noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm
version.
v3:
- add arm suffix into intel_psr2_disable_plane_sel_fetch
v2:
- drop color_plane parameter from arm part
- dev_priv -> i915 in arm part
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130080651.3796929-1-jouni.hogander@intel.com
To update properly bits in the register the mask should be used
to clear old value and then the result should be or-ed with new
value, for such updates there is separate helper intel_de_rmw.
Alan Previn [Wed, 25 Jan 2023 08:26:37 +0000 (00:26 -0800)]
drm/i915/pxp: Pxp hw init should be in resume_complete
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration session teardown (with
the assurance no additional GEM IOCTLs will come after that could
restart the session).
However, if other devices or drivers fail their suspend_prepare, the
system will not go into suspend and i915 will be expected to resume
operation. In this case, we need to re-initialize the PXP hardware
and this really should be done within the pm_resume_complete callback
which is the correct opposing function in the resume sequence to
match pm_suspend_prepare of the suspend sequence.
Because this callback is the last thing at the end of resuming
we expect little to no impact to the rest of the i915 resume sequence
with this change.
Alan Previn [Wed, 25 Jan 2023 08:26:36 +0000 (00:26 -0800)]
drm/i915/pxp: Trigger the global teardown for before suspending
A driver bug was recently discovered where the security firmware was
receiving internal HW signals indicating that session key expirations
had occurred. Architecturally, the firmware was expecting a response
from the GuC to acknowledge the event with the firmware side.
However the OS was in a suspended state and GuC had been reset.
Internal specifications actually required the driver to ensure
that all active sessions be properly cleaned up in such cases where
the system is suspended and the GuC potentially unable to respond.
This patch adds the global teardown code in i915's suspend_prepare
code path.
v2 : Split __pxp_global_teardown_locked helper into two variants
for teardown-with-restart vs teardown-for-suspend/shutdown.
Alan Previn [Wed, 25 Jan 2023 08:26:35 +0000 (00:26 -0800)]
drm/i915/pxp: Invalidate all PXP fw sessions during teardown
A gap was recently discovered where if an application did not
invalidate all of the stream keys (intentionally or not), and the
driver did a full PXP global teardown on the GT subsystem, we
find that future session creation would fail on the security
firmware's side of the equation. i915 is the entity that needs
ensure the sessions' state across both iGT and security firmware
are at a known clean point when performing a full global teardown.
Architecturally speaking, i915 should inspect all active sessions
and submit the invalidate-stream-key PXP command to the security
firmware for each of them. However, for the upstream i915 driver
we only support the arbitration session that can be created
so that will be the only session we will cleanup.
Client on bus have only one vtag map slot and should disregard the vtag
value when cleaning pending read flag.
Fixes read flow control message unexpectedly generated when
clent on bus send messages with different vtags.
Asynchronous runtime resume is not possible while the system
is suspending.
The power management subsystem resumes the device only in the
suspend phase, not in the prepare phase.
Force resume device in prepare to allow drivers on mei bus
to communicate in their prepare callbacks.
Lucas De Marchi [Wed, 25 Jan 2023 18:24:03 +0000 (10:24 -0800)]
drm/i915: Add _PICK_EVEN_2RANGES()
It's a constant pattern in the driver to need to use 2 ranges of MMIOs
based on port, phy, pll, etc. When that happens, instead of using
_PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged
due to some reasons like:
1) It increases the code size since the array is declared
in each call site
2) Developers need to be careful not to incur an
out-of-bounds array access
3) Developers need to be careful that the indexes match the
table. For that it may be that the table needs to contain
holes, making (1) even worse.
Add a variant of _PICK_EVEN() that works with 2 ranges and selects which
one to use depending on the index value.
v2: Fix the address expansion in the example (Anusha)
v3: Also rename macro to _PICK_EVEN_2RANGES() in the documentation
and reword it to clarify what ranges are chosen based on the index
(Jani)
Jani Nikula [Wed, 25 Jan 2023 11:10:52 +0000 (13:10 +0200)]
drm/i915/panel: move panel fixed EDID to struct intel_panel
It's a bit confusing to have two cached EDIDs in struct intel_connector
with slightly different purposes. Make the distinction a bit clearer by
moving the EDID cached for eDP and LVDS panels at connector init time to
struct intel_panel, and name it fixed_edid. That's what it is, a fixed
EDID for the panels.
Jani Nikula [Wed, 25 Jan 2023 11:10:49 +0000 (13:10 +0200)]
drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Since drm_get_edid() calls drm_connector_update_edid_property() while
drm_edid_read*() do not, we need to call drm_edid_connector_update()
separately, in part due to the EDID caching behaviour in HDMI and
DP. Especially DP depends on the details parsed from EDID. (The big
behavioural change conflating EDID reading with parsing and property
update was done in commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector"))
v6: Rebase on drm_edid_connector_add_modes()
v5: Fix potential uninitialized var use (kernel test robot <lkp@intel.com>)
v4: Call drm_edid_connector_update() after reading HDMI/DP EDID
v3: Don't leak vga switcheroo EDID in LVDS init (Ville)
Jani Nikula [Mon, 16 Jan 2023 16:46:44 +0000 (18:46 +0200)]
drm/i915/display: add intel_display_limits.h for key enums
Move a handful of key enums to a new file intel_display_limits.h. These
are the enum types, and the MAX/NUM enumerations within them, that are
used in other headers. Otherwise, there's no common theme between them.
Replace intel_display.h include with intel_display_limit.h where
relevant, and add the intel_display.h include directly in the .c files
where needed.
Since intel_display.h is used almost everywhere in display/, include it
from intel_display_types.h to avoid massive changes across the
board. There are very few files that would need intel_display_types.h
but not intel_display.h so this is neglible, and further cleanup between
these headers can be left for the future.
Overall this change drops the direct and indirect dependencies on
intel_display.h from about 300 to about 100 compilation units, because
we can drop the include from i915_drv.h.
Jani Nikula [Tue, 17 Jan 2023 12:33:07 +0000 (14:33 +0200)]
drm/i915/gmch: split out soc/intel_gmch
The GMCH related code is a bit too low level and out of place for the
high level i915_driver.c file. Split out to a separate file under
soc/. Rename the functions accordingly.
Ville Syrjälä [Tue, 24 Jan 2023 14:46:27 +0000 (16:46 +0200)]
drm/i915/audio: s/ilk/ibx/
Rename the ilk stuff to ibx, as the audio logic lives
in the PCH. The only exception are VLV/CHV but their audio
hardware was stolen from ibx so the name still fits.
Also most of the register defines also use the IBX namespace.
Ville Syrjälä [Tue, 24 Jan 2023 14:46:25 +0000 (16:46 +0200)]
drm/i915/audio: Hook up ELD into the state checker
Have the state checker validate the ELD. For now we'll
just dump it out as a hex buffer on a mismatch, maybe
someone will get inspired to decode it properly at some
point...
Ville Syrjälä [Tue, 24 Jan 2023 14:46:23 +0000 (16:46 +0200)]
drm/i915/sdvo: Only use "presence detect" for has_audio readout
Align the SDVO audio code with the native HDMI/DP audio and
use just the "presence detect" bit for the has_audio readout.
The "ELD valid" bit will be used for ELD readout soon.