From: Ville Syrjälä
If we have no VBT, or the VBT didn't declare the encoder
in question, we won't have the 'devdata' for the encoder.
Instead of oopsing just bail early.
We won't be able to tell whether the port is DP++ or not,
but so be it.
Cc: sta...@vger.kernel.org
Closes:
From: Ville Syrjälä
Advertize more suitable cursor sizes via the new SIZE_HINTS
plane property.
We can't really enumerate all supported cursor sizes on
the platforms where the cursor height can vary freely, so
for simplicity we'll just expose all square+POT sizes between
each platform's min and
From: Ville Syrjälä
Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all
From: Ville Syrjälä
Final final version I hope. Mainly for CI to test against the
new IGTs.
Real userspace implementation:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165
IGT:
From: Ville Syrjälä
Our definitions for bit 7 and bit 0 of ICL_PORT_TX_DW6 are
swapped. Functionally it doesn't matter as we always set both
bits, but let's rename the bits to match bspec 100%.
And while at it, add the definition for bits 1-6 as well, just
to have it all fully documented.
From: Ville Syrjälä
Remove the pointless (void*) cast, the incoming pointer is already
the correct type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
From: Ville Syrjälä
commit 64f6a5d1922b ("container_of: add container_of_const()
that preserves const-ness of the pointer") is nice. Let's use
it so that we don't accidentally cast away the const from our
state pointers.
The only thing I don't particularly like about container_of_const()
is
From: Ville Syrjälä
The connector state passed to .atomic_get_property() is const.
We should preserve that when downcasting to our version.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
Use enc_to_intel_dsi() instead hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 3 +--
drivers/gpu/drm/i915/display/vlv_dsi.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git
From: Ville Syrjälä
Start using container_of_const() for some extra const safety.
Ville Syrjälä (4):
drm/i915/dsi: Use enc_to_intel_dsi()
drm/i915: Don't cast away const
drm/i915: Use container_of_const() for states
drm/i915: Drop pointless (void*) cast
From: Ville Syrjälä
Looks like the undelayed vblank gets signalled exactly when
the active period ends. That is a problem for DSB+VRR when
we are already in vblank and expect DSB to start executing
as soon as we send the push. Instead of starting the DSB
just keeps on waiting for the undelayed
From: Ville Syrjälä
Bspec asks us to always set the DSB_SKIP_WAITS_EN bit in
DSB_CHICKEN. This seems to instruct DSB to skip vblank and
scanline waits when PSR is entered.
I don't think we have any cases currently where we would want
to enter PSR while DSB is waiting for something, but let's
From: Ville Syrjälä
Looks like TRANS_CHICKEN bit 31 means something totally different
depending on the platform:
TGL: generate VRR "safe window" for DSB
ADL/DG2: make TRANS_SET_CONTEXT_LATENCY effective with VRR
So far we've only set this on ADL/DG2, but when using DSB+VRR
we also need to set
From: Ville Syrjälä
Make DSB vblank waits work correctly when VRR is enabled.
Ville Syrjälä (3):
drm/i915/vrr: Generate VRR "safe window" for DSB
drm/i915/dsb: Fix DSB vblank waits when using VRR
drm/i915/dsb: Always set DSB_SKIP_WAITS_EN
drivers/gpu/drm/i915/display/intel_dsb.c | 15
From: Ville Syrjälä
Stop passing in so much redundant stuff to
intel_old_crtc_state_disables(). Top level atomic state + crtc
is all we need.
And while at it constify the states to make it clear they should
not be mutated.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Follow in the footsteps of commit c610e841f19d ("drm/i915:
Do plane/etc. updates more atomically across pipes") and
do the plane disables back to back for all pipes also when
we are disabling pipes.
This should provide for a potentially more atomic user
experience, which
From: Ville Syrjälä
Copy the pipe bitmask based approach skl_commit_modeset_enables()
into intel_commit_modeset_disables(). This avoids doing so many
duplicated checks in all the loops, and also let's us WARN at the
end if we screwed up somewhere and forgot to disable some pipe.
Signed-off-by:
From: Ville Syrjälä
Make the crtc disable more atomic (in terms of plane disable).
And also also track which pipes need disabling in the same way
as skl_commit_modeset_enables(), which should make the whole
thing bit less messy as we don't have to keep on checking the
same conditions multiple
From: Ville Syrjälä
Reinstate commit 88b065943cb5 ("drm/i915/dsi: Do display on
sequence later on icl+"), for the most part. Turns out some
machines (eg. Chuwi Minibook X) really do need that updated order.
It is also the order the Windows driver uses.
However we can't just undo the revert
From: Ville Syrjälä
Reorganize the crtc disable path to only deal with the
master pipes/transcoders in intel_old_crtc_state_disables()
and offload the handling of joined pipes to hsw_crtc_disable().
This makes the whole thing much more sensible since we can
actually control the order in which we
From: Ville Syrjälä
Reorganize the crtc disable path to only deal with the
master pipes/transcoders in intel_old_crtc_state_disables()
and offload the handling of joined pipes to hsw_crtc_disable().
This makes the whole thing much more sensible since we can
actually control the order in which we
From: Ville Syrjälä
Stop passing in so much redundant stuff to
intel_old_crtc_state_disables(). Top level atomic state + crtc
is all we need.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
From: Ville Syrjälä
Follow in the footsteps of commit c610e841f19d ("drm/i915:
Do plane/etc. updates more atomically across pipes") and
do the plane disables back to back for all pipes also when
we are disabling pipes.
This should provide for a potentially more atomic user
experience, which
From: Ville Syrjälä
Copy the pipe bitmask based approach skl_commit_modeset_enables()
into intel_commit_modeset_disables(). This avoids doing so many
duplicated checks in all the loops, and also let's us WARN at the
end if we screwed up somewhere and forgot to disable some pipe.
Signed-off-by:
From: Ville Syrjälä
Unify the master vs. slave handling in
intel_ddi_post_disable_hdmi_or_sst() by looping over all the
pipes in one go.
This also lets us move the intel_crtc_vblank_off() calls to
happen in a consistent place vs. the transcoder disable.
Previously we did the master vs. slaves
From: Ville Syrjälä
Extract the "not-MST" stuff from intel_ddi_post_disable() so that
the whole thing isn't so cluttered.
The bigjoiner slave handling was outside of the !MST check,
but it really should have been inside it as its the counterpart
to the master handling inside the check. So we
From: Ville Syrjälä
Add a small helper to compute the set of pipes that the current
crtc is using.
And we have at least one trivial place in
intel_ddi_update_active_dpll() where we can use it
immediately, so let's do that.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
In preparation for doing a more sensible pipe vs. transcoder
handling for bigjoiner let's rename the crtc/crtc_state in the
top level crtc_enable/disable and the DDI encoder hooks to
include "master" in the name. This way they won't collide with
the per-pipe stuff.
Note that
From: Ville Syrjälä
Here's some prep work I cooked up while thinking how to handle
the bigjoiner stuff. I coverted the .crtc_disable() side of things
to follow the new approach of iterating the joined pipes at a lower
level. Looks pretty reasonable to me in the end. The enable side
is somewhat
From: Ville Syrjälä
Drop the pointless phy/port detour from the eDP handling
in icl_combo_phy_aux_power_well_enable(). We can just directly
consult the dig_port and determine whether it's eDP or not.
This also removes the assumption that port==phy, although that is
always trued on ICL, so it
From: Ville Syrjälä
We don't actually know whether we should be picking the PHY
simply based on the AUX_CH/power well, or based on the VBT
defined AUX_CH->DDI->PHY relationship. At the moment we are
doing the former for the ANAOVRD workaround, and the latter
for the ICL_LANE_ENABLE_AUX override.
From: Ville Syrjälä
Modernize the ICL+ combo PHY register refinitions by using
REG_BIT() & co.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_combo_phy_regs.h | 114 +-
1 file changed, 55 insertions(+), 59 deletions(-)
diff --git
From: Ville Syrjälä
ICL_AUX_ANAOVRD1 is actually ICL_PORT_TX_DW6_AUX. Give it its proper
name, and relocate to the correct file (intel_combo_phy_regs.h).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_combo_phy_regs.h | 6 ++
From: Ville Syrjälä
Create the drm_printer at the start of intel_pipe_config_compare()
and pass it on to all the mismatch() functions.
v2: Rebase
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 101 +--
1 file changed,
From: Ville Syrjälä
Just call pipe_config_mismatch() from all the more specialized
mismatch() functions instead of hand rolling the same printfs
all over.
v2: Eliminate the dpll drm_debug_enabled() in an earlier patch (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Utilize drm_printer in pipe_config_pll_mismatch() to avoid
a bit of code duplication.
To achieve this we need to plumb the printer all way to the
dpll_mgr .dump_hw_state() functions. Those are also used by
intel_crtc_state_dump() which needs to be adjusted as well.
v2:
From: Ville Syrjälä
inlined from ‘i915_ttm_get_pages’ at
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:847:2:
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:165:18: warning: ‘places[0].flags’
is used uninitialized [-Wuninitialized]
165 | places[0].flags |= TTM_PL_FLAG_DESIRED;
|
From: Ville Syrjälä
Advertize more suitable cursor sizes via the new SIZE_HINTS
plane property.
We can't really enumerate all supported cursor sizes on
the platforms where the cursor height can vary freely, so
for simplicity we'll just expose all square+POT sizes between
each platform's min and
From: Ville Syrjälä
Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all
From: Ville Syrjälä
Final version for a new plane SIZE_HINTS property to
essentially replace the cursor size caps, based on recent
discussion in this gitlab bug:
https://gitlab.freedesktop.org/drm/intel/-/issues/7687
As for userspace, so far I only did a quick modetest
blob decoder (mainly to
From: Ville Syrjälä
ADL DSI transcoders do not have the new SET_CONTEXT_LATENCY
register. Instead they supposedly use the older TGL VBLANK_START
based method of defining the vblank delay.
Completely untested due to lack of suitable hardware.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Looks like I misplaced a few hunks when I moved the audio
enable/disable out from the encoder enable/disable hooks.
So we are now doing a double audio enable/disable on SDVO
and g4x+ DP. Probably harmless as doing it twice shouldn't
really change anything, but let's do it
From: Ville Syrjälä
Just return the correct thing from within the loop to make
the code more readable. We have no ref counts/etc. to deal
with here so no point in breaking from the loop just to return
something.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_power_well.c
From: Ville Syrjälä
The icl+ power well code currently assumes that every AUX power
well maps to an encoder which is using said power well. That is
by no menas guaranteed as we:
- only register encoders for ports declared in the VBT
- combo PHY HDMI-only encoder no longer get an AUX CH since
From: Ville Syrjälä
Create the drm_printer at the start of intel_pipe_config_compare()
and pass it on to all the mismatch() functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 101 +--
1 file changed, 46 insertions(+), 55 deletions(-)
From: Ville Syrjälä
Just call pipe_config_mismatch() from all the more specialized
mismatch() functions instead of hand rolling the same printfs
all over.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 45 +---
1 file changed, 10 insertions(+),
From: Ville Syrjälä
Hoist pipe_config_mismatch() upwards a bit so that it can get
reused by the other mismatch() functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 46 ++--
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git
From: Ville Syrjälä
intel_crtc_state_dump() does a whole boatload of string formatting
which is all wasted energy if the debugs aren't even enabled. Skip
the whole thing in that case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc_state_dump.c | 3 +++
1 file
From: Ville Syrjälä
Plumb the drm_printer to all the little helpers called
by intel_crtc_state_dump() and use it there as well.
The exceptions are the ELD and infoframe stuff as they
call helpers outside of the drm and thus can't use
drm_printer.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Convert all the direct drm_dbg_kms() stuff in intel_crtc_state_dump()
over to drm_printf() since we now have the drm_printer around.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_crtc_state_dump.c | 185 --
1 file changed, 87 insertions(+),
From: Ville Syrjälä
Utilize drm_printer in pipe_config_pll_mismatch() to avoid
a bit of code duplication.
To achieve this we need to plumb the printer all way to the
dpll_mgr .dump_hw_state() functions. Those are also used by
intel_crtc_state_dump() which needs to be adjusted as well.
From: Ville Syrjälä
Utilize drm_printer in pipe_config_infoframe_mismatch() to avoid
a bit of code duplication.
print_hex_dump() doesn't know anything about the printer so
it still needs the DRM_UT_KMS check and special handling for
the loglevel. But at least we end up with a bit less
From: Ville Syrjälä
Utilize drm_printer in pipe_config_infoframe_mismatch() to avoid
a bit of code duplication.
hdmi_infoframe_log() can't use the printer of course, but for that
we can just figure out which loglevel to use. And we do need to keep
the explicit drm_debug_enabled(DRM_UT_KMS)
From: Ville Syrjälä
Most crtc state mismatches include the CRTC id+name in the
prints. Also include it in the VSC SDP mismatches.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git
From: Ville Syrjälä
intel_crtc_check_fastset() is done per-pipe, so it would be nice
to know which pipe it was that failed its checkup.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Ville Syrjälä
Most crtc state mismatches include the CRTC id+name in the
prints. Also include it in the infoframe mismatches.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git
From: Ville Syrjälä
Convert the entire state dumper and state checker to
use drm_printer.
One can perhaps consider this as the first step towards
hooking into .atomic_print_state(). Unfortunately that
stuff is a full blown midlayer currently, so we'd first
have to demidlayer it to make it work
From: Ville Syrjälä
There's nothing magical about vlv+ platforms vs. fastboot.
If it works somewhere it should work everywhere, assuming
we've not missed any crucial state checks. That seems unlikely
on older platforms with less state to check anyway.
Just enable fastboot across the board, and
From: Ville Syrjälä
Chunk up the humenguous dpll_hw_state comparison check into per-platform
variants, implemented in the dpll_mgr. This is step one in allowing
each platform (or perhaps even PLL) type to have a custom hw state
structure instead of having to smash it all into one.
From: Ville Syrjälä
GMCH platform DPLLs are similar to the IBX+ PCH DPLLs so
we can just use the same state dump function for both.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git
From: Ville Syrjälä
Most crtc state mismatches include the CRTC id+name in the
prints. Also include it in the ELD buffer mismatch
prints.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff
From: Ville Syrjälä
GMCH DPLL state check was mistakenly removed in
commit 87fc875a2b85 ("drm/i915/dg2: Skip shared DPLL handling").
Bring it back.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
From: Ville Syrjälä
Start chunking up the dpll_hw_state momnster into per-platform
pieces.
Also restore PLL state check on gmch platforms, and
flip on fastboot across the board.
Ville Syrjälä (5):
drm/i915: Fix PLL state check for gmch platforms
drm/i915: Include the CRTC name in the ELD
From: Ville Syrjälä
Limit the link rate to HBR3 or below (<=8.1Gbps) in SST mode.
UHBR (10Gbps+) link rates require 128b/132b channel encoding
which we have not yet hooked up into the SST/no-sideband codepaths.
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Prefer sizeof(*variable) to sizeof(type) to make it a bit
harder to screw things up.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/dvo_ch7017.c | 2 +-
drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 2 +-
drivers/gpu/drm/i915/display/dvo_ivch.c | 2 +-
From: Ville Syrjälä
The dvo 'dev_priv' is void* so no need for and explicit cast.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/dvo_ns2501.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/dvo_ns2501.c
From: Ville Syrjälä
Switch to drm_dbg_kms() in the ilk wm code so we see which
device generated the debugs. Need to plumb i915 a bit deeper
to make that happen.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_wm.c | 26 +++---
1 file changed, 15
From: Ville Syrjälä
Switch to drm_dbg_kms() in the pre-ilk wm code so we see which
device generated the debugs. Need to plumb i915 a bit deeper
to make that happen.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_wm.c | 28 --
1 file changed, 17
From: Ville Syrjälä
Just pass the whole i915 to intel_get_cxsr_latency() instead
of having each caller dig out bits and pieces.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_wm.c | 27 ++
1 file changed, 10 insertions(+), 17 deletions(-)
diff
From: Ville Syrjälä
Switch to per-device debugs in the hdcp code so we see at least which
device is involved. Should proably also print the connector/encoder/etc.
in there, but left that for the future.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 12
From: Ville Syrjälä
Switch to drm_dbg_kms() in the VBT code so we see which
device generated the debugs. Need to plumb i915 a bit deeper
to make that happen.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 73 ++-
From: Ville Syrjälä
Switch to drm_dbg_kms() in the fb code so we see which
device generated the debugs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
From: Ville Syrjälä
The VBT code is all about displays, so switch to UT_KMS debugs
from UT_DRIVER.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
From: Ville Syrjälä
Switch to drm_dbg_kms() in the LUT validation code so we see
which device generated the debugs. Need to plumb i915 a bit
deeper to make that happen.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 11 ++-
1 file changed, 6
From: Ville Syrjälä
Realign a bunch of code that has become messy.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 104 +++---
1 file changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
From: Ville Syrjälä
for_each_old_global_obj_in_state() gives us the old state, not the
new state. Correct the name of the macro argument.
Note that while the argument was misnamed the macro did work
correctly regardless.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Use drm_dbg_kms() instead of DRM_DEBUG_KMS() in the sdvo code
to get the device name into the debug prints.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 113 +-
1 file changed, 66 insertions(+), 47 deletions(-)
diff
From: Ville Syrjälä
Convert a bunch of lingering DRM_DEBUG_KMS() & co. to the
per-device drm_dbg_kms() variants. The stuff remining after this
are DVO encoder drivers, DMI match functions, and ACPI/DSM stuff.
And also include a bit of other house cleaning I spotted.
Ville Syrjälä (13):
From: Ville Syrjälä
cdclk_compute_crawl_and_squash_midpoint() was still assuming
that cd2x divider == 1 (ie. full divider == 2). Remove that
assumption by computing the dividers properly.
We'll also toss in a WARN in case the divider someone ends
up different between the old and new cdclk
From: Ville Syrjälä
Add a bit of documentation to briefly explain the methods
by which we can change the CDCLK frequency.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 9 +
1 file changed, 9 insertions(+)
diff --git
From: Ville Syrjälä
Have cdclk_squash_waveform() return a u16 since that's
how many bits we have in the waveform. We alreday use
u16 everywhere else.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
I missed a couple of spots when I was nuking the cd2x divider==1
assumptions from the squasher support. Remedy that.
And while I was in there I decided to pimp the docs to
describe the CDCLK update methods we support.
Ville Syrjälä (4):
drm/i915/cdclk: Extract
From: Ville Syrjälä
Extract the cdclk divider calculation into a helper. We'll have
more users of this soon. We can now also get rid of the intermediate
'unsquashed_cdclk' variable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 31 --
1 file
From: Ville Syrjälä
Annotate a few more of the failure paths on the initial
BIOS fb takeover to avoid having to guess why things
aren't working the way we expect.
Reviewed-by: Uma Shankar
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
On MTL the GOP (for whatever reason) likes to bind its framebuffer
high up in the ggtt address space. This can conflict with whatever
ggtt_reserve_guc_top() is trying to do, and the result is that
ggtt_reserve_guc_top() fails and then we proceed to explode when
trying to tear
From: Ville Syrjälä
Currently we assume that we bind the BIOS fb exactly into the same
ggtt address where the BIOS left it. That is about to change, and
in order to keep intel_reuse_initial_plane_obj() working as intended
we need to compare the original ggtt offset (called 'base' here)
as
From: Ville Syrjälä
The "io" address of an object is its dma address minus the
region.start. Subtract the latter to make smem_start correct.
The current code happens to work for genuine LMEM objects
as LMEM region.start==0, but for LMEMBAR stolen objects
region.start!=0.
TODO: perhaps just set
From: Ville Syrjälä
There's no reason the caller of intel_initial_plane_config() should
have to loop over the CRTCs. Pull the loop into the function to
make life simpler for the caller.
v2: "fix" xe
Reviewed-by: Andrzej Hajda
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Declutter initial_plane_vma() a bit by pulling the lmem and smem
readout paths into their own functions.
TODO: the smem path should still be fixed to get and validate
the dma address from the pte as well
Reviewed-by: Andrzej Hajda
Tested-by: Paz Zcharya
From: Ville Syrjälä
The address we read from the PTE is a dma address, not a physical
address. Rename the variable to say so.
Reviewed-by: Andrzej Hajda
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_plane_initial.c| 15 ---
1 file
From: Ville Syrjälä
MTL stolen memory looks more like local memory, so use the
(now fixed) lmem path when doing the initial plane readout.
Reviewed-by: Uma Shankar
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_plane_initial.c| 25 +--
From: Ville Syrjälä
On MTL the stolen region starts at offset 8MiB from the start of
LMEMBAR. The dma addresses are thus also offset by 8MiB. However the
mm_node/etc. is zero based, and i915_pages_create_for_stolen() will
add the appropriate region.start into the sg dma address. So when
we do
From: Ville Syrjälä
When multiple pipes are enabled by the BIOS we try to read out each
in turn. But we do the readout for the second only after the inherited
vma for the first has been rebound into its original place (and thus
the PTEs have been rewritten). Unlike the BIOS we set some high
From: Ville Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.
v2: Rebase
Reviewed-by: Andrzej Hajda
Acked-by: Nirmoy Das
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 ++--
From: Ville Syrjälä
Now that the GGTT PTE updates go straight to GSMBASE (bypassing
GTTMMADR) there should be no more risk of system hangs? So the
"binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer
necessary, disable it.
My main worry with the MI_UPDATE_GTT are:
- only used on this
From: Ville Syrjälä
On MTL accessing stolen memory via the BARs is somehow borked,
and it can hang the machine. As a workaround let's bypass the
BARs and just go straight to DSMBASE/GSMBASE instead.
Note that on every other platform this itself would hang the
machine, but on MTL the system
From: Ville Syrjälä
Now that intel_memory_regions_hw_probe() prints out each and every
memory region there's no reason to have ad-hoc debugs to do similar
things elsewhere.
Reviewed-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Dump the details about every memory region into dmesg at probe time.
Avoids having to dig those out from random places when debugging stuff.
Reviewed-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
mem->region is a struct resource, but mem->io_start and
mem->io_size are not for whatever reason. Let's unify this
and convert the io stuff into a struct resource as well.
Should make life a little less annoying when you don't have
juggle between two different approaches all
From: Ville Syrjälä
Attempt to fix the mess around stolen memory, especially on MTL
with it's special (and apparenly broken) not-actually-lmem stolen.
The series is made up of roughtly three parts:
1. General refactoring/debug improvement for mem regions
2. Deal with the broken BAR stuff on MTL
401 - 500 of 9010 matches
Mail list logo
