| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If source_support is set the platform supports PSR so no need to check
it again at every CAN_PSR().
Also removing the intel_dp_is_edp() calls, if sink_support is set
the sink connected is for sure a eDP panel.
Cc: Gwan-gyeong Mun <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Reviewed-by: Gwan-gyeong Mun <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
intel_psr2_program_trans_man_trk_ctl()
There is no support for two pipes one transcoder for PSR and if we had
that the current code should not use cpu_transcoder.
Also I can't see a scenario where crtc_state->enable_psr2_sel_fetch is
set and PSR is not enabled and if by a bug it happens PSR HW will just
ignore any value in set in PSR2_MAN_TRK_CTL.
So dropping all the rest and keeping the same behavior that we have
with intel_psr2_program_plane_sel_fetch().
Cc: Gwan-gyeong Mun <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Reviewed-by: Gwan-gyeong Mun <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
for_each_intel_encoder.*_with_psr
for_each_intel_encoder.*_"can_psr" sounds strange, in my opinion
"with_psr" is better.
Cc: Gwan-gyeong Mun <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Reviewed-by: Gwan-gyeong Mun <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Right now CI is blacklisting module reload, so we need to be able to
enable PSR2 selective fetch in run time to test this feature before
enable it by default.
Changes in IGT will also be needed.
v2:
- Fixed handling of I915_PSR_DEBUG_ENABLE_SEL_FETCH in
intel_psr_debug_set()
Cc: Gwan-gyeong Mun <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Reviewed-by: Gwan-gyeong Mun <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
According to Bspec #20124, max link rate table for DP was updated
at BDB version 230. Max link rate can support upto UHBR.
After migrate to BDB v230, the definition for LBR, HBR2 and HBR3
were changed. For backward compatibility. If BDB version was
from 216 to 229. Driver have to follow original rule to configure
DP max link rate value from VBT.
v2: split the mapping table to two for old and new BDB definition.
v3: return link rate instead of assigning it.
v4: remove the useless variable.
Cc: Ville Syrjala <[email protected]>
Cc: Imre Deak <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Cooper Chiou <[email protected]>
Cc: William Tseng <[email protected]>
Signed-off-by: Lee Shawn C <[email protected]>
[vsyrjala: Try to retain the comment that VBT version 216 added some of this]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When we sanitize planes let's wait for the scanout to stop
before we let the subsequent code tear down the ggtt mappings
and whatnot. Cures an underrun on my ivb when I boot with
VT-d enabled and the BIOS fb gets thrown out due to stolen
being considered unusable with VT-d active.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Chris Wilson <[email protected]>
|
|
We tend to use output_format!=RGB as a shorthand for YCbCr, but
this fails if we have a disabled crtc where output_format==INVALID.
We're now getting some fail from intel_color_check() when we have:
hw.enable==false
hw.ctm!=NULL
output_format==INVALID
Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the
dumpster, and thus everything defaults to RGB when the crtc
is disabled.
This does beg the deeper question of how much of the state
should we in fact be validating when hw/uapi.enable==false.
And should we even be doing the uapi->hw copy when
uapi.enable==false? So far I've not been able to come up with
satisfactory answers for myself, so I'm putting it off for the
moment.
Cc: Lee Shawn C <[email protected]>
Fixes: 0aa5c3835c8a ("drm/i915: support two CSC module on gen11 and later")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
There is nothing else to be executed after this if block.
Signed-off-by: José Roberto de Souza <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
-Wunintialized was disabled in commit c5627461490e ("drm/i915: Disable
-Wuninitialized") because there were two warnings that were false
positives. The first was due to DECLARE_WAIT_QUEUE_HEAD_ONSTACK, which
was fixed in LLVM 9.0.0. The second was in busywait_stop, which was
fixed in LLVM 10.0.0 (issue 415). The kernel's minimum version for LLVM
is 10.0.1 so this warning can be safely enabled, where it has already
caught a couple bugs.
Link: https://github.com/ClangBuiltLinux/linux/issues/220
Link: https://github.com/ClangBuiltLinux/linux/issues/415
Link: https://github.com/ClangBuiltLinux/linux/issues/499
Link: https://github.com/llvm/llvm-project/commit/2e040398f8d691cc378c1abb098824ff49f3f28f
Link: https://github.com/llvm/llvm-project/commit/c667cdc850c2aa821ffeedbc08c24bc985c59edd
Fixes: c5627461490e ("drm/i915: Disable -Wuninitialized")
References: 2ea4a7ba9bf6 ("drm/i915/gt: Avoid uninitialized use of rpcurupei in frequency_show")
References: 2034c2129bc4 ("drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state")
Reported-by: Arnd Bergmann <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Convert the remaining 'dev_priv's to 'i915's in the DDI
clock routing functions.
Cc: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Lucas De Marchi <[email protected]>
|
|
Move icl_sanitize_encoder_pll_mapping() out from the middle
of the .{enable,disable}_clock() functions.
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Instead of every new platform having yet another masive
copy of the whole PLL sanitation code, let's just reuse the
.disable_clock() hook for this purpose. We do need to plug
this into the ICL+ DSI code for that, but fortunately it
already has a suitable function we can use.
We do lose the debug message though on account of not bothering
to check if the clock is actually enabled or not before turning
it off. We could introduce yet another vfunc to query the current
state, but not sure it's worth the hassle?
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Since .{enable,disable}_clock() are already vfuncs it's a bit silly to
have if-ladders inside them. Just provide specialized version for adl-s
and rkl so we don't need any of that.
v2: s/dev_priv/i915/ (Lucas)
Fix typos in platform names (Lucas)
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
All the DPCLKA_CFGCR handling follows a common pattern. Let's
extract that to a small helper that just takes a few parameters
each caller can customize.
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The other DDI .enable_clock() functions are trying to protect us
against pll==NULL. A bit tempted to throw out all the WARNs as
just unnecessary noise, but I guess they might have some use
when poking around the shared_dpll code (not sure it wouldn't
oops elsewhere though). So let's unify it all and sprinkle in
the missing WARNs for icl/dg1.
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The current code attempts to protect the RMWs into global
clock routing registers with a mutex, but forgets to do so
in a few places. Let's remedy that.
Note that at the moment we serialize all modesets onto single
wq, so this shouldn't actually matter. But maybe one day we
wish to attempt parallel modesets again...
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The DDI clock routing programming is riddled with shared
registers, forcing us to do a lot of RMW. Switch over to
intel_de_rmw() to make that a bit less obnoxious.
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
For ICL+ we have several styles of clock routing for DDIs:
1) TC DDI + TC PHY
-> needs DDI_CLK_SEL==MG/TBT part form intel_ddi_clk_{select,disable}()
and ICL_DPCLKA_CFGCR0_TC_CLK_OFF part form icl_{map,unmap}_plls_to_ports()
2) ICL/TGL combo DDI + combo PHY
-> just need the stuff from icl_{map,unmap}_plls_to_ports()
3) JSL/EHL TC DDI + combo PHY
-> needs DDI_CLK_SEL==MG part from intel_ddi_clk_{select,disable}() and
the full combo style clock selection from icl_{map,unmap}_plls_to_ports()
4) ADLS/RKL
-> these use both TC and combo DDIs with combo PHYs, however they
always use the full combo style clock selection as per
icl_{map,unmap}_plls_to_ports() and do not use DDI_CLK_SEL at all,
thus get treated the same as 2)
We extract all that from the current mess in the following way:
1) icl_ddi_tc_{enable,disable}_clock()
2) icl_ddi_combo_{enable,disable}_clock()
3) jsl_ddi_tc_{enable,disable}_clock()
4) for now we reuse icl_ddi_combo_{enable,disable}_clock() here
v2: s/dev_priv/i915/ (Lucas)
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace dg1_{map,unmap}_plls_to_ports() with the appropriate
encoder vfuncs. And let's relocate the disable function next to
the enable function while at it.
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Extract the DDI clock routing for CNL into the new vfuncs.
v2: s/dev_priv/i915/ (Lucas)
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Extract the DDI clock routing clode for skl/derivatives
into the new encoder vfuncs.
v2: s/dev_priv/i915/ (Lucas)
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Yank out the HSW/BDW code from intel_ddi_clk_{select,disable}()
and put it into the new encoder .{enable,disable}_clock() vfuncs.
v2: s/dev_priv/i915/ (Lucas)
v3: Deal with FDI
Reviewed-by: Lucas De Marchi <[email protected]> #v2
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The current code dealing with the clock routing for DDI encoders
is a maintenance nightmare. Let's start cleaning it up by allowing
the encoder to provide vfuncs for enablign/disabling the clock.
We leave them initially unimplemented, falling back to the old
if-else approach.
v2: Convert the FDI enable sequence
Reviewed-by: Lucas De Marchi <[email protected]> #v2
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We want to put all DDI clock routing code into one place.
Unify the FDI enable sequence to use the standard function
instead of hand rolling its own. The disable sequence already
uses the normal thing.
Cc: Lucas De Marchi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Lucas De Marchi <[email protected]>
|
|
intel_init_audio_hooks() sets up hooks in the display struct and only
makes sense when we have display. Move it inside
intel_init_display_hooks() so it isn't called when we don't have
display.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Now that all display-related functions are grouped in
i915_driver_register(), move them to display/ so we reduce the amount of
display calls from the rest of the driver.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
intel_gt_driver_register() may be called earlier than
intel_opregion_register() and acpi_video_register(), so move it up.
intel_display_debugfs_register() may be called later, together with the
other display-related initializations. There is a slight change in
behavior that sysfs files will show up before the display-related
debugfs files, but that shouldn't be a problem - userspace shouldn't be
relying in debugfs.
This allows us to group all the display-related calls under a single
check for "HAS_DISPLAY()" that can be later moved to a better place.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
If drm_dev_register() fails there is no reason to continue registering
the driver and initializing.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In rare circumstances bugs in PCI programming, broken BIOS, or failing
hardware can cause the CPU to lose access to the MMIO BAR on dgfx
platforms. This is a pretty catastrophic failure since all register
reads come back with values of 0xFFFFFFFF. Let's check for this special
case while doing our usual checks for unclaimed registers; the FPGA_DBG
register we use for those checks on modern platforms has some unused
bits that will always read back as 0 when things are behaving properly;
we can use them as canaries to detect when MMIO itself has suddenly
broken and try to print a more informative error message in the logs.
v2: Let the detection function still return 'true' if we've lost our
MMIO access. We'll still get an extra false positive message about
an unclaimed register access, but we'll still honor the 'mmio_debug'
limit and not spam the log. (Lucas)
Cc: Lucas De Marchi <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Lucas De Marchi <[email protected]>
|
|
Although the bspec's description doesn't make it very clear, the
hardware architects have confirmed that the FPGA_DBG register that we
use to check for unclaimed MMIO accesses is display-specific and will
only properly flag unclaimed MMIO transactions for registers in the
display range. If a platform doesn't have display, FPGA_DBG itself will
not be available and should not be checked. Let's move the feature flag
into intel_device_info.display to more accurately reflect this.
Given that we now know FPGA_DBG is display-specific, it could be argued
that we should only check it on out intel_de_*() functions. However
let's not make that change right now; keeping the checks in all of the
existing locations still helps us catch cases where regular
intel_uncore_*() functions use bad MMIO offset math / base addresses and
accidentally wind up landing within an unused area within the display
MMIO range. It will also help catch cases where userspace-initiated
MMIO (e.g., IGT's intel_reg tool) attempt to read bad offsets within the
display range.
v2: Add missing hunk with the update to the HAS_FPGA_DBG_UNCLAIMED
macro. (CI)
Cc: Lucas De Marchi <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Apparently the new gen9_bc platforms that Intel has introduced don't
provide us with a STRAP config register to read from for initializing DDI
B, C, and D detection. So, workaround this by hard-coding our strap config
in intel_setup_outputs().
Changes since v4:
* Split this into it's own commit
Cc: Matt Roper <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjala <[email protected]>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Next, let's start introducing the HPD pin mappings for Intel's new gen9_bc
platform in order to make hotplugging display connectors work. Since
gen9_bc is just a TGP PCH along with a CML CPU, except with the same HPD
mappings as ICL, we simply add a skl_hpd_pin function that is shared
between gen9 and gen9_bc which handles both the traditional gen9 HPD pin
mappings and the Icelake HPD pin mappings that gen9_bc uses.
Changes since v4:
* Split this into its own commit
* Introduce skl_hpd_pin() like vsyrjala suggested and use that instead of
sticking our HPD pin mappings in TGP code
Cc: Matt Roper <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjala <[email protected]>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
After fixing the OA_TAIL_PTR corruption, there are no more reports with
reason field of zero. Drop the check for report reason.
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Signed-off-by: Lionel Landwerlin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
DP-MST connector encoder initializes at modeset
Adding a connector->encoder NULL check in order to
avoid any NULL pointer dereference.
intel_hdcp_enable() already handle this but debugfs
can also invoke the intel_{hdcp,hdcp2_capable}.
Handling it gracefully.
v2:
- Use necessary lock and NULL check in
i915_hdcp_sink_capability_show. [Imre]
Reviewed-by: Imre Deak <[email protected]>
Signed-off-by: Anshuman Gupta <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We are not checking for specific SKUs and feedback from HW team is that
it may not work since it was supposed to be fixed by the same time
straps stopped to be used. So, just update comment.
v2: Instead of removing the check, just update the comment since
feedback from HW team was that it actually may not work
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
With the introduction of gen9_bc, where Intel combines Cometlake CPUs with
a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this
platform in order to make all of the display connectors work. So, let's do
that.
Changes since v4:
* Split this into it's own patch - vsyrjala
Changes since v5:
* Rename gen9bc_port_to_ddc_pin() to gen9bc_tgp_port_to_ddc_pin()
Cc: Matt Roper <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjala <[email protected]>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Since Intel has introduced the gen9_bc platform, a combination of
Tigerpoint PCHs and CML CPUs, let's recognize such platforms as valid and
avoid WARNing on them.
Changes since v4:
* Split this into it's own patch - vsyrjala
Cc: Matt Roper <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjala <[email protected]>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Lane Reversal is required for some of the DDI ports. This information
is populated in VBT and driver should read the same and set the
polarity while enabling the port. This patch handles the same.
It helps fix a display blankout issue on DP ports on certain
platforms.
Signed-off-by: Uma Shankar <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Set the right BW buddy page mask for new memory types.
BSpec: 49218
Cc: Clint Taylor <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Let's scream if we are about to release a frontbuffer which
is still in use.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Chris Wilson <[email protected]>
|
|
We don't have a persistent fb holding a reference to the frontbuffer
object, so every time we do the get+put we throw the frontbuffer object
immediately away. And so the next time around we get a pristine
frontbuffer object with bits==0 even for the old vma. This confuses
the frontbuffer tracking code which understandably expects the old
frontbuffer to have the overlay's bit set.
Fix this by hanging on to the frontbuffer reference until the next
flip. And just to make this a bit more clear let's track the frontbuffer
explicitly instead of just grabbing it via the old vma.
Cc: [email protected]
Cc: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking")
Reviewed-by: Chris Wilson <[email protected]>
|
|
ilk+ planes get notably unhappy when the plane x+w exceeds
the stride. This wasn't a problem previously because we
always aligned SURF to the closest tile boundary so the
x offset never got particularly large. But now with async
flips we have to align to 256KiB instead and thus this
becomes a real issue.
On ilk/snb/ivb it looks like the accesses just wrap
early to the next tile row when scanout goes past the
SURF+n*stride boundary, hsw/bdw suffer more heavily and
start to underrun constantly. i965/g4x appear to be immune.
vlv/chv I've not yet checked.
Let's borrow another trick from the skl+ code and search
backwards for a better SURF offset in the hopes of getting the
x offset below the limit. IIRC when I ran into a similar issue
on skl years ago it was causing the hardware to fall over
pretty hard as well.
And let's be consistent and include i965/g4x in the check
as well, just in case I just got super lucky somehow when
I wasn't able to reproduce the issue. Not that it really
matters since we still use 4k SURF alignment for i965/g4x
anyway.
Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv")
Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb")
Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw")
Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Chris Wilson <[email protected]>
|
|
The TypeC FIA can be powered down if the TC-COLD power state is allowed,
so block the TC-COLD state when initializing the FIA.
Note that this isn't needed on ICL where the FIA is never modular and
which has no generic way to block TC-COLD (except for platforms with a
legacy TypeC port and on those too only via these legacy ports, not via
a DP-alt/TBT port).
Cc: <[email protected]> # v5.10+
Cc: José Roberto de Souza <[email protected]>
Reported-by: Paul Menzel <[email protected]>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3027
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jos� Roberto de Souza <[email protected]>
|
|
Gen12 supports additional OA formats as compared to what was added
earlier. Include the additional OA formats.
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Signed-off-by: Lionel Landwerlin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Variations in OA formats in the different gens has led to creation of
several sparse arrays to store the formats.
Move oa formats into a single array and format_mask to check for
platform specific oa formats.
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Signed-off-by: Lionel Landwerlin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Validity of an OA format is checked by using a sparse array of formats
per gen. Instead maintain a mask of supported formats for a platform in
the perf object.
v2: Use set_bit and test_bit style for the format_mask (Chris)
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Signed-off-by: Lionel Landwerlin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Removing force probe protection from RKL platform. Did
not observe warnings, errors, flickering or any visual
defects while doing ordinary tasks like browsing and
editing documents in a two monitor setup.
Signed-off-by: Tejas Upadhyay <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130124855.319226-1-tejaskumarx.surendrakumar.upadhyay@intel.com
|
|
Legacy LSPCON chip from MCA and Parade is only used for platforms
between GEN9 and GEN10. Fixing the HAS_LSPCON macro to reflect the same.
Signed-off-by: Ankit Nautiyal <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This moves the code from various places and consolidates it
into one new file.
v2:
- rename skl_program_plane -> skl_program_plane_scaler (Ville)
- also move skl_pfit_enable, and consequently make some skl_scaler_*
functions static to skl_scaler.c (Ville)
Signed-off-by: Dave Airlie <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/2fa703ffc7b96a41c392fd5ebbd2e6e4ffb6fb05.1612536383.git.jani.nikula@intel.com
|
|
Migrate this code out like the skylake code.
Signed-off-by: Dave Airlie <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/c003bd458a6bcc703e9e2fb05731fb7124012e8c.1612536383.git.jani.nikula@intel.com
|