In thunderbolt mode the PHY is owned by the thunderbolt controller.
We are not supposed to touch it. So skip the vswing programming
as well (we already skipped the other steps not applicable to TBT).
Touching this stuff could supposedly interfere with the PHY
programming done by the thunderbolt controller.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Atm, the driver programs explicitly the default transparent link
training mode (0x55) to DP_PHY_REPEATER_MODE even if no LTTPRs are
detected.
This conforms to the spec (3.6.6.1):
"DP upstream devices that do not enable the Non-transparent mode of
LTTPRs shall program the PHY_REPEATER_MODE register (DPCD Address
F0003h) to 55h (default) prior to link training"
however writing the default value to this DPCD register seems to cause
occasional link training errors at least for a DELL WD19TB TBT dock, when
no LTTPRs are detected.
Writing to DP_PHY_REPEATER_MODE will also cause an unnecessary timeout
on systems without any LTTPR.
To fix the above two issues let's assume that setting the default mode
is redundant when no LTTPRs are detected. Keep the existing behavior and
program the default mode if more than 8 LTTPRs are detected or in case
the read from DP_PHY_REPEATER_CNT returns an invalid value.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2801
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118183143.1145707-1-imre.deak@intel.com
Add support for async flips on vlv/chv. Unlike all the other
platforms vlv/chv do not use the async flip bit in DSPCNTR and
instead we select between async vs. sync flips based on the
surface address register. The normal DSPSURF generates sync
flips DSPADDR_VLV generates async flips. And as usual the
interrupt bits are different from the other platforms.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-12-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Add support for async flips on ivb/hsw. Again no need for any
workarounds and just have to deal with the interrupt bits being
shuffled around a bit.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-11-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Add support for async flips on ivb/hsw. Unlike bdw+ we don't need
any workarounds to disable async flips. Apart from that the only
real difference from the bdw implementation is the location of the
flip_done interrupt bits.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-10-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Implement async flip support for BDW. The implementation is
similar to the skl+ code. And just like skl/bxt/glk bdw also
needs the disable w/a, thus we need to plumb the desired state
of the async flip all the way down to i9xx_plane_ctl_crtc().
According to the spec we do need to bump the surface alignment
to 256KiB for this. Async flips require an X-tiled buffer so
we don't have to worry about linear.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-9-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Limit pre-skl plane stride to below 4k or 8k pixels (depending on
the platform). We do this in order guarantee that TILEOFF/OFFSET.x
does not get too big.
Currently this is not a problem as we align SURF to 4k, and so
TILEOFF/OFFSET only have to deal with a single tile's worth of
pixels. But for async flips we're going to have to bump SURF
alignment to 256k, and thus we can no longer guarantee
TILEOFF/OFFSET.x will stay within acceptable bounds. We can avoid
this by borrowing a trick from the skl+ code and limit the max
plane stride to whatever value we can fit into TILEOFF/OFFSET.x.
The slight downside is that we may end up doing GTT remapping in
a few more cases where previously we did not have to. But since
that will only happen with huge buffers I'm not really concerned
about it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-3-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Up to now we were reading some DRAM information from MCHBAR register
and from pcode what is already not good but some GEN12(TGL-H and ADL-S)
platforms have MCHBAR DRAM information in different offsets.
This was notified to HW team that decided that the best alternative is
always apply the 16gb_dimm watermark adjustment for GEN12+ platforms
and read the remaning DRAM information needed to other display
programming from pcode.
So here moving the DRAM pcode function to intel_dram.c, removing
the duplicated fields from intel_qgv_info, setting and using
information from dram_info.
v2:
- bring back num_points to intel_qgv_info as num_qgv_point can be
overwritten in icl_get_qgv_points()
- add gen12_get_dram_info() and simplify gen11_get_dram_info()
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210128164312.91160-2-jose.souza@intel.com
- Fix DP vswing settings and handling (Imre, Ville)
- Various display code clean-up (Jani, Ville)
- Various display refactoring, including split out of pps, aux, and fdi (Ja\
ni, Dave)
- Add DG1 missing workarounds (Jose)
- Fix display color conversion (Chris, Ville)
- Try to guess PCH type even without ISA bridge (Zhenyu)
- More backlight refactor (Lyude)
- Support two CSC module on gen11 and later (Lee)
- Async flips for all ilk+ platforms (Ville)
- Clear color support for TGL (RK)
- Add a helper to read data from a GEM object page (Imre)
- VRR/Adaptive Sync Enabling on DP/eDP for TGL+ (Manasi, Ville Aditya)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmARc1oACgkQ+mJfZA7r
E8ovFAgAhBlnhrquGrgtuRmS5tkpLQShqiwrPv7ogDBkcayJ6Is+AO+FoE8kuzZO
q/TW2enkcRKFHhQnm9RA0Ayk+rwYqkEOcBU5gvzusdwbEjkygJfH/yA2ukAmaw32
QxP9A2pW+iWsEcqtMuOEu1ahu0Z8gnkCe8DakuBMf/0y5D9DairwaCC8nyZQdEJq
YFTxp+pILE57PhOVbKS3EZPbnl5t28NgCtMc8hjlPTWZxRSVV0eDrY2tx9vyhFhU
Eq8aLDxPKCRm18sg+J+lDytOvFoljXcglAEwPODVMmDNolG8R6aRQ9T6tG6qfxyI
UO1KyeYUHHEIJ4IBJKK+KWeUWLLBhA==
=3Jc8
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2021-01-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (Anshuman)
- Fix DP vswing settings and handling (Imre, Ville)
- Various display code clean-up (Jani, Ville)
- Various display refactoring, including split out of pps, aux, and fdi (Ja\
ni, Dave)
- Add DG1 missing workarounds (Jose)
- Fix display color conversion (Chris, Ville)
- Try to guess PCH type even without ISA bridge (Zhenyu)
- More backlight refactor (Lyude)
- Support two CSC module on gen11 and later (Lee)
- Async flips for all ilk+ platforms (Ville)
- Clear color support for TGL (RK)
- Add a helper to read data from a GEM object page (Imre)
- VRR/Adaptive Sync Enabling on DP/eDP for TGL+ (Manasi, Ville Aditya)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210127140822.GA711686@intel.com
Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit)
value for MST streams if the link parameters (link rate or lane count)
are limited in a way independent of the sink capabilities (reported by
DPCD).
One example of such a limitation is when a MUX between the sink and
source connects only a limited number of lanes to the display and
connects the rest of the lanes to other peripherals (USB).
Another issue is that atm MST core calculates the divider based on the
backwards compatible DPCD (at address 0x0000) vs. the extended
capability info (at address 0x2200). This can result in leaving some
part of the MST BW unused (For instance in case of the WD19TB dock).
Fix the above two issues by calculating the PBN divider value based on
the rate and lane count link parameters that the driver uses for all
other computation.
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com
The HDCP 1.4 spec does not require the QUERY_STREAM_ENCRYPTION_STATUS
check, it was always a nice-to-have. After deploying this across various
devices, we've determined that some MST bridge chips do not properly
support this call for HDCP 1.4 (namely Synaptics and Realtek).
I had considered creating a quirk for this, but I think it's more
prudent to just disable the check entirely since I don't have an idea
how widespread support is.
Changes in v2:
-Rebased on -tip
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210106223909.34476-1-sean@poorly.run #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20210121172620.33066-1-sean@poorly.run
Prevent the ICL HDR plane pipeline from performing YUV color range
correction twice when the input is in limited range. This is done by
removing the limited-range code from icl_program_input_csc().
Before this patch the following could happen: user space gives us a YUV
buffer in limited range; per the pipeline in [1], the plane would first
go through a "YUV Range correct" stage that expands the range; the plane
would then go through the "Input CSC" stage which would also expand the
range because icl_program_input_csc() would use a matrix and an offset
that assume limited-range input; this would ultimately cause dark and
light colors to appear darker and lighter than they should respectively.
This is an issue because if a buffer switches between being scanned out
and being composited with the GPU, the user will see a color difference.
If this switching happens quickly and frequently, the user will perceive
this as a flickering.
[1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281
Cc: stable@vger.kernel.org
Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215224219.3896256-1-andrescj@google.com
DSI transcoder does not support VRR and hence skip the HW state
readout if its a DSI transcoder.
Fixes: c7f0f4372b ("drm/i915/display: Add HW state readout for VRR")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210126185224.32340-1-manasi.d.navare@intel.com
ADL-S switches up which PHYs are considered a master to other PHYs;
PHY-C is no longer a master, but PHY-D is now.
Bspec: 49291
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-11-aditya.swarup@intel.com
- ADL-S driver internal mapping uses PORT D, E, F, G for Combo phy B, C,
D and E.
- Add ADLS specific port mappings for vbt port dvo settings.
- Select appropriate AUX CH specific to ADLS based on port mapping.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-10-aditya.swarup@intel.com
ADL-S requires TC pins to set up ddc for Combo PHY B, C, D and E.
Combo PHY A still uses the old ddc pin mapping.
From VBT, ddc pin info suggests the following mapping:
VBT DRIVER
DDI B->ddc_pin=2 should translate to PORT_D->0x9
DDI C->ddc_pin=3 should translate to PORT_E->0xa
DDI D->ddc_pin=4 should translate to PORT_F->0xb
DDI E->ddc_pin=5 should translate to PORT_G->0xc
Adding pin map to facilitate this translation as we cannot use existing
icl ddc pin map due to conflict with DDI B and DDI C info.
Bspec:20124
v2: Replace IS_ALDERLAKE_S() with HAS_PCH_ADP() as the pin map pairing
depends on the PCH being used rather than the platform.(mdroper)
v3:
- Modify adls_port_to_ddc_pin() to make PHY_A the special case for
check, else return pin mapping based on correct arithmetic with phy
offset. Remove redundant platform checks and use HAS_PCH_ADP() instead
of IS_ALDERLAKE_S() in intel_hdmi_ddc_pin().(mdroper)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-9-aditya.swarup@intel.com
Initialize display outputs for ADL-S. ADL-S has 5 display
outputs -> 1 eDP, 2 HDMI and 2 DP++ outputs.
v2:
- Use PORT_TCx instead of PORT_D,E.. to stay consistent
with other platforms.(mdroper)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-8-aditya.swarup@intel.com
Add changes to configure port clock registers for ADL-S. Combo phy port
clocks are configured by DPCLKA_CFGCR0 and DPCLKA_CFGCR1 registers.
The DDI to internal clock mappings in DPCLKA_CFGCR0 register for ADL-S
translates to
DDI A -> DDIA
DDI B -> USBC1
DDI I -> USBC2
For DPCLKA_CFGCR1
DDI J -> USBC3
DDI K -> USBC4
Bspec: 50287
Bspec: 53812
Bspec: 53723
v2: Replace I915_READ() with intel_de_read().(Jani)
v3:
- Use reg variable to assign ADLS specific registers inorder to replace
branching with intel_de_read/write() calls.(mdroper)
- Reuse icl_get_ddi_pll() for ADLS to fix issue with updating active
dpll on driver load.(aswarup)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-7-aditya.swarup@intel.com
Add changes for configuring DPLL for ADL-S
- Reusing DG1 DPLL 2 & DPLL 3 for ADL-S
- Extend CNL macro to choose DPLL_ENABLE
for ADL-S.
- Select CFGCR0 and CFGCR1 for ADL-S plls.
On BSpec: 53720 PLL arrangement dig for adls:
DPLL2 cfgcr is programmed using _ADLS_DPLL3_CFGCR(0/1)
DPLL3 cfgcr is programmed using _ADLS_DPLL4_CFGCR(0/1)
v2 (Lucas): add missing update_ref_clks
Bspec: 50288
Bspec: 50289
Bspec: 49443
v3 : Adding another bit to HDPORT_DPLL_USED_MASK bitfield
for DPLL3_USED.(mdroper)
Bspec: 53707
v4: BSpec 53723 has been updated with note - DPLL2 is
controlled by DPLL4 CFGCR 0/1.(mdroper)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-6-aditya.swarup@intel.com
Alderlake-S has 5 combo phys, add reg definitions for
combo phys and update the port to phy helper for ADL-S.
v2:
- Change IS_GEN() >= 12 to IS_TIGERLAKE() in intel_phy_is_tc()
and return false for platforms RKL,DG1 and ADLS.(mdroper)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-5-aditya.swarup@intel.com
The MH PHY vswing table does have all the entries these days. Get
rid of the old hacks in the code which claim otherwise.
This hack was totally bogus anyway. The correct way to handle the
lack of those two entries would have been to declare our max
vswing and pre-emph to both be level 2.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Fixes: 9f7ffa2979 ("drm/i915/tc/icl: Update TC vswing tables")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201207203512.1718-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit 5ec346476e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In order to make the dbuf state computation less fragile
let's make it stand on its own feet by not requiring someone
to peek into a crystall ball ahead of time to figure out
which pipes need to be added to the state under which potential
future conditions. Instead we compute each piece of the state
as we go along, and if any fallout occurs that affects more than
the current set of pipes we add the affected pipes to the state
naturally.
That requires that we track a few extra thigns in the global
dbuf state: dbuf slices for each pipe, and the weight each
pipe has when distributing the same set of slice(s) between
multiple pipes. Easy enough.
We do need to follow a somewhat careful sequence of computations
though as there are several steps involved in cooking up the dbuf
state. Thoguh we could avoid some of that by computing more things
on demand instead of relying on earlier step of the algorithm to
have filled it out. I think the end result is still reasonable
as the entire sequence is pretty much consolidated into a single
function instead of being spread around all over.
The rough sequence is this:
1. calculate active_pipes
2. calculate dbuf slices for every pipe
3. calculate total enabled slices
4. calculate new dbuf weights for any crtc in the state
5. calculate new ddb entry for every pipe based on the sets of
slices and weights, and add any affected crtc to the state
6. calculate new plane ddb entries for all crtcs in the state,
and add any affected plane to the state so that we'll perform
the requisite hw reprogramming
And as a nice bonus we get to throw dev_priv->wm.distrust_bios_wm
out the window.
v2: Keep crtc_state->wm.skl.ddb
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122205633.18492-8-ville.syrjala@linux.intel.com
With vrr enabled the hardware no longer latches the registers
automagically at vblank start. The point at which it will do the
latching even when no push has been sent is the vmax decision
boundary. That is the thing we need to evade to avoid our
register latching to get split between two frames.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-18-manasi.d.navare@intel.com
To get sensible vblank timestamping behaviour we need to feed
the vmax based timings to the vblank code, otherwise it'll chop
off the scanline counter when it exceeds the minumum vtotal.
Additionally with VRR we have three cases to consider when we
generate the vblank timestamp:
1) we are in vertical active
-> nothing special needs to be done, just return the current
scanout position and the core will calculate the timestamp
corresponding to the past time when the current vertical
active started
2) we are in vertical blank and no push has been sent
-> the hardware will keep extending the vblank presumably
to its maximum length, so we make the timestmap match the
expected time when the max length vblank will end. Since
the timings used for this are now based on vmax nothing
special actually needs to be done
3) we are in vblank and a push has been sent so the vblank is
about to terminate
-> presumably we want the timestmap to accurately reflect
when the vblank will terminate, so we use the sampled
frame timestamp vs. current timestamp to guesstimate
how far along the vblank exit we are, and then we
adjust the reported scanout position accordingly so
that the core will see that the vblank is close to
ending.
v2:
* Fix the else if (use_scanline_Counter) (Manasi)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-17-manasi.d.navare@intel.com
With VRR the earliest the registers can get latched are at
flipline decision boundary, calculate that as vrr_vmin_vblank_start()
and the latest the regsiters can get latched are vmax decision boundary
calculate that as vrr_vmax_vblank_start()
v2:
* Remove TODO and adjust extra scanline const (Manasi)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-15-manasi.d.navare@intel.com
This functions gets the VRR config from the VRR registers
to match the crtc state variables for VRR.
v2:
* Rebase (Manasi)
* Use HAS_VRR (Jani N)
v3:
* Get pipeline_full, flipline (Ville)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-14-manasi.d.navare@intel.com
If VRR is enabled, the sink should ignore MSA parameters
and regenerate incoming video stream without depending
on these parameters. Hence set the MSA_TIMING_PAR_IGNORE_EN
bit if VRR is enabled.
Reset this bit on VRR disable.
v2:
* ACtually set the dpcd msa ignore bit (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-13-manasi.d.navare@intel.com
This patch disables the VRR enable and VRR PUSH
bits in the HW during commit modeset disable sequence.
Thsi disable will happen when the port is disabled
or when the userspace sets VRR prop to false and
requests to disable VRR.
v2:
* Use intel_de_rmw (Jani N)
v3:
* Remove rmw (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-12-manasi.d.navare@intel.com
VRR achieves vblank stretching using the HW PUSH functionality.
So once the VRR is enabled during modeset then for each flip
request from userspace, in the atomic tail pipe_update_end()
we need to set the VRR push bit in HW for it to terminate
the vblank at configured flipline or anytime after flipline
or latest at the Vmax.
The HW clears the PUSH bit after the double buffer updates
are completed.
v2:
* Move send push to after irq en (Manasi)
* Call send push unconditionally (Jani N)
v3:
* Stall w.r.t Vrr vmax (Manasi, Gary Smith)
v4:
* Remove the rmw (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gary Smith <gary.k.smith@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-11-manasi.d.navare@intel.com
This patch computes the VRR parameters from VRR crtc states
and configures them in VRR registers during CRTC enable in
the modeset enable sequence.
v2:
* Remove initialization to 0 (Jani N)
* Use correct pipe %c (Jani N)
v3:
* Remove debug prints (Ville)
* Use cpu_trans instead of pipe for TRANS_VRR regs (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-10-manasi.d.navare@intel.com
Even though our HW supports PSR + VRR, the available panels
do not work reliably with PSR and VRR together. So if user
requested VRR and is supported by HW enable that and do not
enable PSR in that case.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-7-manasi.d.navare@intel.com
This forces a complete modeset if vrr drm crtc state goes
from enabled to disabled and vice versa.
This patch also computes vrr state variables from the mode timings
and based on the vrr property set by userspace as well as hardware's
vrr capability.
v2:
*Rebase
v3:
* Vmin = max (vtotal, vmin) (Manasi)
v4:
* set crtc_state->vrr.enable = 0 for disable request
v5:
* drm_dbg_kms, squash crtc states def patch (Jani N)
v6:
* Move vrr modeset check to separate function (Jani N)
v7:
* Ville's fixes - vmin, vmax rename, fix rounding dir
* Add pipeline full, flipline to crtc state
* Pass conn state to vrr_compute_config (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-6-manasi.d.navare@intel.com
We want to calculate the vblank_start for vblank evasion
differently for vrr. To make that nicer lets first extract
the current non-vrr case to a helper.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-4-manasi.d.navare@intel.com
The vrr calculations will need to know the framestart delay value
we use. Currently we program it always to zero, but should that change
we probably want to stash it somewhere.
Could stick it into the crtc_state I suppose, but since we never
change it let's just stuff it into dev_priv for now.
v2:
* Rebase on drm-tip (Manasi)
v3:
* Framestart_delay as 1 - 4 to align with HW
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-3-manasi.d.navare@intel.com
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v8:
* Use HAS_VRR, remove drm_conn declaration (Jani N)
* Fix typos in Comment (Jani N)
v7:
* Move the helper to separate file (Manasi)
v6:
* Remove unset of prop
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect (Manasi)
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for debugfs, make it
non static (Manasi)
v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-2-manasi.d.navare@intel.com
We create a new file for all VRR related helpers.
Also add a function to check vrr capability based on
platform support, DPCD bits and EDID monitor range.
v2:
* Remove author (Jani N)
* Define HAS_VRR (Jani N)
* Ensure intel_dp can be obtained from conn (Jani N)
v3:
* Fix the header indent (Manasi)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125200818.2015-1-manasi.d.navare@intel.com
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmAOFRIeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG4lcH/jFAG+AXR6T2K3dG
adJmdAWQKdDj71Ruoyefx5GSbD0B+rM1UcxOQgmZem2127RJgfDBBVYyjSwh7H1F
LRJdN6+NKReL2OW/HMnufvpVMvWICTWHInyvsqKqp+Yo4GC5z46OtsmzSayYgTaP
v2G9auC/rSUlzmQux9EAbTKDeNGMum3dt2rfsmnIDymBSHoPbizXF93/2hoo9jwx
BZQCq0nYBCa9pEdsmgvqKkb/Y5+CSFoe02qdUZFIuwh6qd/XPfeDPSu4O3z4J9g6
x8G+f7doeU0nzsAP+K0lG7ulAygxRHm5Bn2rwVdlYfihAuPNyF+Ua3duxBvjOBEY
7w/UQ64=
=ZWS9
-----END PGP SIGNATURE-----
Merge tag 'v5.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next
Backmerge v5.11-rc5 into drm-next to clean up a bunch of conflicts we are dragging around.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Render Decompression is supported with Y-Tiled main surface. The CCS is
linear and has 4 bits of data for each main surface cache line pair, a
ratio of 1:256. Additional Clear Color information is passed from the
user-space through an offset in the GEM BO. Add a new modifier to identify
and parse new Clear Color information and extend Gen12 render decompression
functionality to the newly added modifier.
v2: Fix has_alpha flag for modifiers, omit CC modifier during initial
plane config(Matt). Fix Lookup error.
v3: Fix the panic while running kms_cube
v4: Add alignment check and reuse the comments for ge12_ccs_formats(Matt)
v5: Fix typos and wrap comments(Matt)
v6:
- Use format block descriptors to get the subsampling calculations for
the CCS surface right.
- Use helpers to convert between main and CCS surfaces.
- Prevent coordinate checks for the CC surface.
- Simplify reading CC value from surface map, add description of CC val
layout.
- Remove redundant ccval variable from skl_program_plane().
v7:
- Move the CC value readout after syncing against any GPU write on the
FB obj (Nanley, Chris)
- Make sure the CC value readout works on platforms w/o struct pages
(dGFX) and other non-coherent platforms wrt. CPU reads (none atm).
(Chris)
v8:
- Rebase on the function param order change of
i915_gem_object_read_from_page().
- Clarify code comment on the clear color value format and the required
FB obj pinning/syncing by the caller.
- Remove redundant variables in
intel_atomic_prepare_plane_clear_colors().
v9:
- Fix s/sizeof(&ccval)/sizeof(ccval)/ typo.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Nanley G Chery <nanley.g.chery@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115213952.1040398-1-imre.deak@intel.com
Move (num_hdcp_streams > 0) condition to stream_encryption()
code block, where it actually belongs.
This fixes the static analysis error of uninitialized symbol 'ret'.
v2:
- return 0 as the return value is already checked. [Ankit]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210120103032.15198-1-anshuman.gupta@intel.com
Initialize no. of streams transmitted on a port to zero
such that intel_hdcp_required_content_stream() can
prepared the content stream after subsequemt attmept to
enable hdcp after a HDCP failure.
v2:
- Initialize k at top level instead of else branch. [Jani]
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119064655.1605-2-anshuman.gupta@intel.com
We haven't yet implemented support for backlights that need to be
enabled/disabled via PWM instead of AUX, which means we'll break things if
we enable DPCD backlight control on these machines. Luckily though since
most of these machines work fine just using the plain PWM backlight
controls anyway, there shouldn't be any issue with just leaving DPCD
backlight controls disabled in such situations.
This should fix the issues with PWM being left on that were being observed
on fi-bdw-samus.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Fixes: 4a8d79901d ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)")
Testcase: igt/gem_exec_suspend/basic-s0 # fi-bdw-samus
Cc: Lyude Paul <lyude@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210121183644.2627282-1-lyude@redhat.com
Get rid of the "I like my random new style best" approach and unify
the handling for the DDI buf trans table sanity checks once again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201207203512.1718-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
The MH PHY vswing table does have all the entries these days. Get
rid of the old hacks in the code which claim otherwise.
This hack was totally bogus anyway. The correct way to handle the
lack of those two entries would have been to declare our max
vswing and pre-emph to both be level 2.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Fixes: 9f7ffa2979 ("drm/i915/tc/icl: Update TC vswing tables")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201207203512.1718-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Split out the DP aux functionality to a new intel_dp_aux.[ch]. This is a
surprisingly clean cut.
v2:
- Remove intel_dp_pack_aux declaration from intel_dp.h (Anshuman)
- Fixed some whitespace/comment checkpatch warnings
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210120101834.19813-4-jani.nikula@intel.com
intel_display.c has some pps functions that belong to intel_pps.c. Move
them over.
While at it, refactor the duplicate intel_pps_init() in intel_display.c
into an orthogonal intel_pps_setup() in intel_pps.c, and call it earlier
in intel_modeset_init_nogem().
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210120101834.19813-2-jani.nikula@intel.com
Once you realize there is no need to hold the pps mutex when calling
pps_init_timestamps() in intel_pps_init(), we can reuse
intel_pps_encoder_reset() which has the same code.
Since intel_dp_pps_init() is only called from one place now, move it
inline to remove one "init" function altogether.
Finally, remove some initialization from
vlv_initial_power_sequencer_setup() and do it in the caller to highlight
the similarity, not the difference, in the platforms.
v2: Fix comment (Anshuman)
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210120101834.19813-1-jani.nikula@intel.com
Simplify the frontbuffer unpin by removing the lock requirement. The LRU
bumping was primarily to protect the GTT from being evicted and from
frontbuffers being eagerly shrunk. Now we protect frontbuffers from the
shrinker, and we avoid accidentally evicting from the GTT, so the
benefit from bumping LRU is no more, and we can save more time by not.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119214336.1463-6-chris@chris-wilson.co.uk
In the shrinker, we protect framebuffers from light reclaim as we
typically expect framebuffers to be reused in the near future (and with
low latency requirements). We can apply the same logic to the GGTT
eviction and defer framebuffers to the second pass only used if the
caller is desperate enough to wait for space to become available.
In most cases, the caller will use a smaller partial vma instead of
trying to force the object into the GGTT if doing so will cause other
users to be evicted.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119214336.1463-5-chris@chris-wilson.co.uk
The obj->stolen is currently used to identify an object allocated from
stolen memory. This dates back to when there were just 1.5 types of
objects, an object backed by shmemfs and an object backed by shmemfs
with a contiguous physical address. Now that we have several different
types of objects, we no longer want to treat stolen objects as a special
case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119214336.1463-3-chris@chris-wilson.co.uk
TGL adds another level of indirection for applying WA based on stepping
information rather than PCI REVID. So change TGL_REVID enum into
stepping enum and use PCI REVID as index into revid to stepping table to
fetch correct display and GT stepping for application of WAs as
suggested by Matt Roper.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119192931.1116500-1-lucas.demarchi@intel.com
Currently, if a modeset/pageflip needs to wait for render completion to
an object, we boost the priority of that rendering above all other work.
We can apply the same interactive priority boosting to explicit fences
that we can unwrap into a native i915_request (i.e. sync_file).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119204454.10343-1-chris@chris-wilson.co.uk
This reverts commit 0883ce8146. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.
At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.
As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.
v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
intel_edp_init_connector()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-6-lyude@redhat.com
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.
So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).
v3:
* Rebase
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-5-lyude@redhat.com
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.
On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.
For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:
* If the panel's VBT reports VESA backlight support, assume it really
does support it
* If the panel's VBT reports DDI backlight controls:
* First probe for Intel's HDR backlight interface
* If that fails, probe for VESA's backlight interface
* If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
doesn't have DPCD backlight controls
Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-4-lyude@redhat.com
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.
So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:
* We now keep track of two separate backlight level ranges, one for the
high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
enablement separately
* Since the currently set backlight level might not be the same as the
currently programmed PWM backlight level, we stop setting
panel->backlight.level with the currently programmed PWM backlight
level in panel->backlight.pwm_funcs->setup(). Instead, we rely
on the higher level backlight control functions to retrieve the
current PWM backlight level (in this case, intel_pwm_get_backlight()).
Note that there are still a few PWM backlight setup callbacks that
do actually need to retrieve the current PWM backlight level, although
we no longer save this value in panel->backlight.level like before.
Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.
v9:
* Drop the intel_panel_invert_pwm_level() call in lpt_setup_backlight()
* Remove leftover detritus from lpt_setup_backlight()
v8:
* Go back to getting initial brightness level with
intel_pwm_get_backlight(), the other fix we had was definitely wrong.
v7:
* Use panel->backlight.pwm_funcs->get() to get the backlight level in
intel_pwm_setup_backlight(), lest we upset lockdep
* Rebase
* Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level()
v6:
* Make sure to grab connection_mutex before calling
intel_pwm_get_backlight() in intel_pwm_setup_backlight()
v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-3-lyude@redhat.com
On some platforms we need to trigger an extra async flip with
the async flip bit disabled, and then wait for the next vblank
until the async flip bit off state will actually latch.
Currently the w/a is just open coded for skl+ universal planes.
Instead of doing that lets reuse the .async_flip() hook for this
purpose since it needs to write the exact same set of registers.
In order to do this we'll just have the caller pass in the state
of the async flip bit explicitly.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-8-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Set up the async flip PLANE_CTL bit directly in the
.async_flip() hook. Neither .update_plane() nor .disable_plane()
ever need to set this so having it done by skl_plane_ctl_crtc()
is rather pointless.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-7-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Prepare for more platforms with async flip support by turning
the flip_done interrupt enable/disable into plane vfuncs.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-6-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Only assign the plane->async_flip() vfunc when the plane supports
async flips. For now we keep this artificially limited to the primary
plane since thats the only thing the legacy page flip uapi can target
and there is no async flip support in the atomic uapi yet.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-5-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
I accidentally added the compliance test hacks only to
intel_dp_hotplug() which doesn't even get used on any DDI
platform. Put the same crap into intel_ddi_hotplug().
Cc: Imre Deak <imre.deak@intel.com>
Fixes: 193af12cd6 ("drm/i915: Shove the PHY test into the hotplug work")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-7-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Currently we claim to use TPS7 when using TPS4. That is just
confusing, so let's fix the debug print.
And while we're touching this let's add the customary
encoder id/name as well.
v2: Add MISSING_CASE() (Manasi)
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-2-ville.syrjala@linux.intel.com
DP spec says:
"The Source device shall start sending the idle pattern after
it has cleared the Training_Pattern byte in the DPCD."
Currently we do these in operations in the opposite order.
Swap them around to match the spec.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118162107.18424-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
There are two CSC on pipeline on gen11 and later platform.
User space application is allowed to enable CTM and RGB
to YCbCr coversion at the same time now.
v2: check csc capability in {}_color_check function.
v3: can't support two CSC at the same time in {ivb,glk}_color_check.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Shankar Uma <uma.shankar@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118022753.8798-1-shawn.c.lee@intel.com
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes: a6597faa2d ("drm/i915: Protect workers against disappearing connectors")
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-3-anshuman.gupta@intel.com
(cherry picked from commit b3c6661aad)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.
This issue is caught with DP MST setup, where we have multiple
connector in same DP_MST topology. When disabling HDCP on one of
DP MST connector leads to set the crtc state need_modeset to true
for all other crtc driving the other DP-MST topology connectors.
This turns up other DP MST connectors CP property to be DESIRED
despite the actual hdcp->value is ENABLED.
Above scenario fails the DP MST HDCP IGT test, disabling HDCP on
one MST stream should not cause to disable HDCP on another MST
stream on same DP MST topology.
v2:
- Fixed connector->base.registration_state == DRM_CONNECTOR_REGISTERED
WARN_ON.
v3:
- Commit log improvement. [Uma]
- Added a comment before scheduling prop_work. [Uma]
Fixes: 33f9a623bf ("drm/i915/hdcp: Update CP as per the kernel internal state")
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-2-anshuman.gupta@intel.com
(cherry picked from commit d276e16702)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This pulls a large chunk of the pll calculation code out of
intel_display.c to a new file.
One function makes sense to be an inline, otherwise this
is pretty much a straight copy cover. Also all the
remaining hooks for g45 and older end up the same now.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[Jani: cleaned up intel_dpll.h a bit, de-duped intel_panel_use_ssc().]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/74b58e0572858b5d1734818ca594a23040d7d44f.1610622609.git.jani.nikula@intel.com
In the next commit where we split PWM related backlight functions from
higher-level backlight functions, we'll want to be able to retrieve the
backlight level for the current display panel from the
intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since
intel_panel_bl_funcs->setup() is called before we've fully read in the
current hardware state into our atomic state, we can't grab atomic
modesetting locks safely anyway in intel_panel_bl_funcs->setup(), and some
PWM backlight functions (vlv_get_backlight() in particular) require knowing
the currently used pipe we need to be able to discern the current display
pipe through other means. Luckily, we're already passing the current
display pipe to intel_panel_bl_funcs->setup() so all we have to do in order
to achieve this is pass down that parameter to intel_panel_bl_funcs->get().
So, fix this by accepting an additional pipe parameter in
intel_panel_bl_funcs->get(), and leave figuring out the current display
pipe up to the caller.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-2-lyude@redhat.com
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op?
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op?
drivers/gpu/drm/i915/display/intel_dp.c:6923 intel_dp_update_420() warn: should this be a bitwise op?
Inside drm_dp_downstream_rgb_to_ycbcr_conversion(), that parameter
'color_spc' is used as return port_cap[3] & color_spc, implying that it
is indeed a mask and not a boolean value.
Fixes: 522508b665 ("drm/i915/display: Let PCON convert from RGB to YCbCr if it can")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201223103917.14687-1-chris@chris-wilson.co.uk
UAPI Changes:
- Deprecate I915_PMU_LAST and optimize state tracking (Tvrtko)
Avoid relying on last item ABI marker in i915_drm.h, add a
comment to mark as deprecated.
Cross-subsystem Changes:
Core Changes:
Driver Changes:
- Restore clear residuals security mitigations for Ivybridge and
Baytrail (Chris)
- Close#1858: Allow sysadmin to choose applied GPU security mitigations
through i915.mitigations=... similar to CPU (Chris)
- Fix for #2024: GPU hangs on HSW GT1 (Chris)
- Fix for #2707: Driver hang when editing UVs in Blender (Chris, Ville)
- Fix for #2797: False positive GuC loading error message (Chris)
- Fix for #2859: Missing GuC firmware for older Cometlakes (Chris)
- Lessen probability of GPU hang due to DMAR faults [reason 7,
next page table ptr is invalid] on Tigerlake (Chris)
- Fix REVID macros for TGL to fetch correct stepping (Aditya)
- Limit frequency drop to RPe on parking (Chris, Edward)
- Limit W/A 1406941453 to TGL, RKL and DG1 (Swathi)
- Make W/A 22010271021 permanent on DG1 (Lucas)
- Implement W/A 16011163337 to prevent a HS/DS hang on DG1 (Swathi)
- Only disable preemption on gen8 render engines (Chris)
- Disable arbitration around Braswell's PDP updates (Chris)
- Disable arbitration on no-preempt requests (Chris)
- Check for arbitration after writing start seqno before busywaiting (Chris)
- Retain default context state across shrinking (Venkata, CQ)
- Fix mismatch between misplaced vma check and vma insert for 32-bit
addressing userspaces (Chris, CQ)
- Propagate error for vmap() failure instead kernel NULL deref (Chris)
- Propagate error from cancelled submit due to context closure
immediately (Chris)
- Fix RCU race on HWSP tracking per request (Chris)
- Clear CMD parser shadow and GPU reloc batches (Matt A)
- Populate logical context during first pin (Maarten)
- Optimistically prune dma-resv from the shrinker (Chris)
- Fix for virtual engine ownership race (Chris)
- Remove timeslice suppression to restore fairness for virtual engines (Chris)
- Rearrange IVB/HSW workarounds properly between GT and engine (Chris)
- Taint the reset mutex with the shrinker (Chris)
- Replace direct submit with direct call to tasklet (Chris)
- Multiple corrections to virtual engine dequeue and breadcrumbs code (Chris)
- Avoid wakeref from potentially hard IRQ context in PMU (Tvrtko)
- Use raw clock for RC6 time estimation in PMU (Tvrtko)
- Differentiate OOM failures from invalid map types (Chris)
- Fix Gen9 to have 64 MOCS entries similar to Gen11 (Chris)
- Ignore repeated attempts to suspend request flow across reset (Chris)
- Remove livelock from "do_idle_maps" VT-d W/A (Chris)
- Cancel the preemption timeout early in case engine reset fails (Chris)
- Code flow optimization in the scheduling code (Chris)
- Clear the execlists timers upon reset (Chris)
- Drain the breadcrumbs just once (Chris, Matt A)
- Track the overall GT awake/busy time (Chris)
- Tweak submission tasklet flushing to avoid starvation (Chris)
- Track timelines created using the HWSP to restore on resume (Chris)
- Use cmpxchg64 for 32b compatilibity for active tracking (Chris)
- Prefer recycling an idle GGTT fence to avoid GPU wait (Chris)
- Restructure GT code organization for clearer split between GuC
and execlists (Chris, Daniele, John, Matt A)
- Remove GuC code that will remain unused by new interfaces (Matt B)
- Restructure the CS timestamp clocks code to local to GT (Chris)
- Fix error return paths in perf code (Zhang)
- Replace idr_init() by idr_init_base() in perf (Deepak)
- Fix shmem_pin_map error path (Colin)
- Drop redundant free_work worker for GEM contexts (Chris, Mika)
- Increase readability and understandability of intel_workarounds.c (Lucas)
- Defer enabling the breadcrumb interrupt to after submission (Chris)
- Deal with buddy alloc block sizes beyond 4G (Venkata, Chris)
- Encode fence specific waitqueue behaviour into the wait.flags (Chris)
- Don't cancel the breadcrumb interrupt shadow too early (Chris)
- Cancel submitted requests upon context reset (Chris)
- Use correct locks in GuC code (Tvrtko)
- Prevent use of engine->wa_ctx after error (Chris, Matt R)
- Fix build warning on 32-bit (Arnd)
- Avoid memory leak if platform would have more than 16 W/A (Tvrtko)
- Avoid unnecessary #if CONFIG_PM in PMU code (Chris, Tvrtko)
- Improve debugging output (Chris, Tvrtko, Matt R)
- Make file local variables static (Jani)
- Avoid uint*_t types in i915 (Jani)
- Selftest improvements (Chris, Matt A, Dan)
- Documentation fixes (Chris, Jose)
Signed-off-by: Dave Airlie <airlied@redhat.com>
# Conflicts:
# drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
# drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
# drivers/gpu/drm/i915/gt/intel_lrc.c
# drivers/gpu/drm/i915/gvt/mmio_context.h
# drivers/gpu/drm/i915/i915_drv.h
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114152232.GA21588@jlahtine-mobl.ger.corp.intel.com
We dropped the other redundant master_transcoder assignments
earlier, but this one slipped through. Get rid of it as well.
The crtc state gets fully reset before readout so there is
no point in doing this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201019214337.19330-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
There are a number of functions that "init" pps in various ways. Try to
find some more consistency in the naming.
Rename:
- intel_dp_init_panel_power_sequencer -> pps_init_delays
- intel_dp_init_panel_power_sequencer_registers -> pps_init_registers
- intel_dp_init_panel_power_timestamps -> pps_init_timestamps
as this is what the functions do. Skip the intel_ prefix here to
emphasize these are static and not exported.
No functional changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/15260c28060f3f90276ab395da4d3999ccdb641f.1610127741.git.jani.nikula@intel.com
Add an "encoder reset" call to hide some more pps functions, and clean
up the callers. A minor functional change is not holding the pps lock
across the whole operation in intel_dp_encoder_reset, but instead doing
it in two steps.
v2: rename intel_pps_reinit to intel_pps_encoder_reset for clarity
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/84a50f2700b19c6719cd3e1e931c64f1e2027551.1610127741.git.jani.nikula@intel.com
In a long overdue refactoring, split out all panel sequencer code from
intel_dp.c to new intel_pps.[ch].
The first part is mostly just code movement as-is, without cleanups or
functional changes.
We need to add a vlv_get_dpll() helper to get at the vlv/chv dpll from
pps code.
v2: Rebase.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/14cc59d5734432ad976cd49ff8efce8fa413e5b2.1610127741.git.jani.nikula@intel.com
Always prefer the kernel types over stdint types in i915.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113141158.25513-1-jani.nikula@intel.com
The DP PHY vswing/pre-emphasis level programming the driver does is
related to the DPTX -> first LTTPR link segment only. Accordingly it
should be only programmed when link training the first LTTPR and kept
as-is when training subsequent LTTPRs and the DPRX. For these latter
PHYs the vs/pe levels will be set in response to writing the
DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR
TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY).
The above is also described in DP Standard v2.0 under 3.6.6.1.
While at it simplify and add the LTTPR that is link trained to the debug
message in intel_dp_set_signal_levels().
Fixes: b30edfd8d0 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-2-imre.deak@intel.com
Authenticate and enable port encryption only once for
an active HDCP 2.2 session, once port is authenticated
and encrypted enable encryption for each stream that
requires encryption on this port.
Similarly disable the stream encryption for each encrypted
stream, once all encrypted stream encryption is disabled,
disable the port HDCP encryption and deauthenticate the port.
v2:
- Add connector details in drm_err. [Ram]
- 's/port_auth/hdcp_auth_status'. [Ram]
- Added a debug print for stream enc.
v3:
- uniformity for connector detail in DMESG. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-19-anshuman.gupta@intel.com
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
v2:
- Added a WARN_ON() instead of drm_err. [Uma]
- Cosmetic changes. [Uma]
v3:
- 's/port_data/hdcp_port_data' [Ram]
- skip redundant link check. [Ram]
v4:
- use pipe instead of port to access HDCP2_STREAM_STATUS
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-18-anshuman.gupta@intel.com
This requires for HDCP 2.2 MST check link.
As for DP/HDMI shims check_2_2_link retrieves the connector
from dig_port, this is not sufficient or DP MST connector,
there can be multiple DP MST topology connector associated
with same dig_port.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-16-anshuman.gupta@intel.com
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
Security f/w doesn't have any provision to mark the stream_type
for each stream separately, it just take single input of
stream_type while authenticating the port and applies the
same stream_type to all streams. So driver mark each stream_type
with common highest supported content type for all streams
in DP MST Topology.
Security f/w supports RepeaterAuthStreamManage msg and m'
validation only once during port authentication and encryption.
Though it is not compulsory, security fw should support dynamic
update of content_type and should support RepeaterAuthStreamManage
msg and m' validation whenever required.
v2:
- Init the hdcp port data k for HDMI/DP SST stream.
v3:
- Cosmetic changes. [Uma]
v4:
- 's/port_auth/hdcp_port_auth'. [Ram]
- Commit log improvement.
v5:
- Comment and commit log improvement. [Ram]
v6:
- Check first connector connected status before intel_encoder_is_mst
to avoid any NULL pointer dereference.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Tested-by: Juston Li <juston.li@intel.com>
Acked-by: Juston Li <juston.li@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-15-anshuman.gupta@intel.com
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
v2:
- 's/port_data/hdcp_port_data'. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-12-anshuman.gupta@intel.com
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-11-anshuman.gupta@intel.com
Enable HDCP 1.4 DP MST stream encryption.
Enable stream encryption once encryption is enabled on
the DP transport driving the link for each stream which
has requested encryption.
Disable stream encryption for each stream that no longer
requires encryption before disabling HDCP encryption on
the link.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
v3:
- Cosmetic change, removed the value less comment. [Uma]
v4:
- Split the Gen12 HDCP enablement patch. [Ram]
- Add connector details in drm_err.
v5:
- uniformity for connector detail in DMESG. [Ram]
- comments improvement. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-9-anshuman.gupta@intel.com
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link
in order to enable/disable the stream encryption.
Both of above requirement are same for all Gen with respect to
B.Spec Documentation.
v2:
- Cosmetic changes function name, error msg print and
stream typo fixes. [Uma]
v3:
- uniformity for connector detail in DMESG. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-8-anshuman.gupta@intel.com
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used by both HDCP{1.x,2.x} stream status timeout.
Related: 'commit 7e90e8d0c0 ("drm/i915: Increase timeout for Encrypt
status change")'
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-7-anshuman.gupta@intel.com
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and HDCP 2.2 over DP MST
on Gen12.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-6-anshuman.gupta@intel.com
There can be situation when DP MST connector is created without
mst modeset being done, in those cases connector->encoder will be
NULL. MST connector->encoder initializes after modeset.
Don't enable HDCP in such cases to prevent any crash.
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Juston Li <juston.li@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-5-anshuman.gupta@intel.com
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-4-anshuman.gupta@intel.com
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes: a6597faa2d ("drm/i915: Protect workers against disappearing connectors")
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-3-anshuman.gupta@intel.com
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.
This issue is caught with DP MST setup, where we have multiple
connector in same DP_MST topology. When disabling HDCP on one of
DP MST connector leads to set the crtc state need_modeset to true
for all other crtc driving the other DP-MST topology connectors.
This turns up other DP MST connectors CP property to be DESIRED
despite the actual hdcp->value is ENABLED.
Above scenario fails the DP MST HDCP IGT test, disabling HDCP on
one MST stream should not cause to disable HDCP on another MST
stream on same DP MST topology.
v2:
- Fixed connector->base.registration_state == DRM_CONNECTOR_REGISTERED
WARN_ON.
v3:
- Commit log improvement. [Uma]
- Added a comment before scheduling prop_work. [Uma]
Fixes: 33f9a623bf ("drm/i915/hdcp: Update CP as per the kernel internal state")
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-2-anshuman.gupta@intel.com
DG1's vswing tables are the same for eDP and HDMI but have slight
differences from ICL/TGL for DP.
v2:
- Use a "_hbr2_hbr3" suffix on the table name to make it more clear
that the same table is used for both HBR2 and HBR3 link rates.
(Swathi)
Bspec: 49291
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108222528.1954514-1-matthew.d.roper@intel.com
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max parameters.
To solve these two conflicting requirements let's start with the optimal
setup, and if that fails we start again with the max parameters. The
downside is probably an extra modeset when we switch strategies but
I don't see a good way to avoid that.
For a bit of history we first tried to go for the fast+narrow in
commit 7769db5883 ("drm/i915/dp: optimize eDP 1.4+ link config
fast and narrow"). but that had to be reverted due to regression
on older panels in commit f11cb1c19a ("drm/i915/dp: revert back
to max link rate and lane count on eDP"). So now we try to get
the best of both worlds by using both strategies.
v2: Deal with output_bpp and uapi vs. hw state split
Reword some comments
v3: Rebase
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
References: https://gitlab.freedesktop.org/drm/intel/issues/272
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com
Eliminate checkpatch warnings from intel_cursor.c:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: Possible repeated word: 'by'
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110175624.3524-2-ville.syrjala@linux.intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
For an enabled DSC during HW readout the corresponding power reference
is taken along the CRTC power domain references in
get_crtc_power_domains(). Remove the incorrect get ref from the DSI
encoder hook.
Fixes: 2b68392e63 ("drm/i915/dsi: add support for DSC")
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201209153952.3397959-1-imre.deak@intel.com
(cherry picked from commit 3a9ec563a4)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
There was some misinterpretation of specification, when DDIX_USED is
set, the next bit means 0 for DP and 1 for HDMI.
Anyways this misinterpretation is not causing any issues, this change
is just to comply with specification.
Also as for us it do not matters if it is HDMI or DP, not checking the
port type that HTI is using.
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108134802.21280-1-jose.souza@intel.com
The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
functions operate directly on the hardware registers. If inverting the
value is needed, using intel_panel_compute_brightness(), it should only
be done in the interface between hardware registers and
panel->backlight.level.
The CPU mode takeover code added in commit 5b1ec9ac7a
("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the
hardware register and converts to panel->backlight.level correctly,
however the value written back should remain in the hardware register
"domain".
This hasn't been an issue, because GM45 machines are the only known
users of i915.invert_brightness and the brightness invert quirk, and
without one of them no conversion is made. It's likely nobody's ever hit
the problem.
Fixes: 5b1ec9ac7a ("drm/i915/backlight: Fix backlight takeover on LPT, v3.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v5.1+
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com
(cherry picked from commit 0d4ced1c5b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Commit 25b4620ee8 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
added an intel_dsi_msleep() helper which skips sleeping if the
MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
and it moved a bunch of msleep-s over to this new helper.
This was based on my reading of the big comment around line 730 which
starts with "Panel enable/disable sequences from the VBT spec.",
where the "v3 video mode seq" column does not have any wait t# entries.
Given that this code has been used on a lot of different devices without
issues until now, it seems that my interpretation of the spec here is
mostly correct.
But now I have encountered one device, an Acer Aspire Switch 10 E
SW3-016, where the panel will not light up unless we do actually honor the
panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.
What seems to set this model apart is that it is lacking a
MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
delay usually happens.
Fix the panel not lighting up on this model by using an unconditional
msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
no MIPI_SEQ_DEASSERT_RESET sequence.
Fixes: 25b4620ee8 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201118124058.26021-1-hdegoede@redhat.com
(cherry picked from commit 6fdb335f1c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
functions operate directly on the hardware registers. If inverting the
value is needed, using intel_panel_compute_brightness(), it should only
be done in the interface between hardware registers and
panel->backlight.level.
The CPU mode takeover code added in commit 5b1ec9ac7a
("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the
hardware register and converts to panel->backlight.level correctly,
however the value written back should remain in the hardware register
"domain".
This hasn't been an issue, because GM45 machines are the only known
users of i915.invert_brightness and the brightness invert quirk, and
without one of them no conversion is made. It's likely nobody's ever hit
the problem.
Fixes: 5b1ec9ac7a ("drm/i915/backlight: Fix backlight takeover on LPT, v3.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v5.1+
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com
We need a power_domain wakeref in pps_{lock,unlock} to prevent
a race while resetting pps state in intel_power_sequencer_reset().
intel_power_sequencer_reset() need a pps_mutex to access pps_pipe
but it can't grab pps_mutex due to deadlock with power_well
functions are called while holding pps_mutex.
intel_power_sequencer_reset() is called by power_well function
associated with legacy platforms like vlv and chv therefore re-use
the POWER_DOMAIN_DISPLAY_CORE power domain, which only used
by vlv and chv display power domain.
This will avoids the unnecessary noise of unrelated power wells
in pps_{lock,unlock}.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210107112500.16216-1-anshuman.gupta@intel.com
Commit 25b4620ee8 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
added an intel_dsi_msleep() helper which skips sleeping if the
MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
and it moved a bunch of msleep-s over to this new helper.
This was based on my reading of the big comment around line 730 which
starts with "Panel enable/disable sequences from the VBT spec.",
where the "v3 video mode seq" column does not have any wait t# entries.
Given that this code has been used on a lot of different devices without
issues until now, it seems that my interpretation of the spec here is
mostly correct.
But now I have encountered one device, an Acer Aspire Switch 10 E
SW3-016, where the panel will not light up unless we do actually honor the
panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.
What seems to set this model apart is that it is lacking a
MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
delay usually happens.
Fix the panel not lighting up on this model by using an unconditional
msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
no MIPI_SEQ_DEASSERT_RESET sequence.
Fixes: 25b4620ee8 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201118124058.26021-1-hdegoede@redhat.com
Add support for DP-HDMI2.1 PCON
From the series cover letter:
This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299
The details are mentioned in:
VESA DP-to-HDMI PCON Specification Standalone Document
https://groups.vesa.org/wg/DP/document/15651
This series starts with adding support for FRL (Fixed Rate Link)
Training between the PCON and HDMI2.1 sink.
As per HDMI2.1 specification, a new data-channel or lane is added in
FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher
bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4
lanes).
With these patches, the HDMI2.1 PCON can be configured to achieve FRL
training based on the maximum FRL rate supported by the panel, source
and the PCON.
The approach is to add the support for FRL training between PCON and
HDMI2.1 sink and gradually add other blocks for supporting higher
resolutions and other HDMI2.1 features, that can be supported by pcon
for the sources that do not natively support HDMI2.1.
This is done before the DP Link training between the source and PCON
is started. In case of FRL training is not achieved, the PCON will
work in the regular TMDS mode, without HDMI2.1 feature support.
Any interruption in FRL training between the PCON and HDMI2.1 sink is
notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD
registers are read and FRL training is re-attempted.
Currently, we have tested the FRL training and are able to enable 4K
display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting
panel.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87lfdpndkt.fsf@intel.com
UAPI Changes:
- Not necessarily one, but we document that userspace needs to force probe connectors.
Cross-subsystem Changes:
- Require FB_ATY_CT for aty on sparc64.
- video: Fix documentation, and a few compiler warnings.
- Add devicetree bindings for DP connectors.
- dma-buf: Update kernel-doc, and add might_lock for resv objects in begin/end_cpu_access.
Core Changes:
- ttm: Warn when releasing a pinned bo.
- ttm: Cleanup bo size handling.
- cma-helper: Remove prime infix, and implement mmap as GEM CMA functions.
- Split drm_prime_sg_to_page_addr_arrays into 2 functions.
- Add a new api to install irq using devm.
- Update panel kerneldoc to inline style.
- Add DP support to drm/bridge.
- Assorted small fixes to ttm, fb-helper, scheduler.
- Add atomic_commit_setup function callback.
- Automatically use the atomic gamma_set, instead of forcing drivers to declare the default atomic version.
- Allow using degamma for legacy gamma if gamma is not available.
- Clarify that primary/cursor planes are not tied to 1 crtc (depending on possible_crtcs).
- ttm: Cleanup the lru handler.
Driver Changes:
- Add pm support to ingenic.
- Assorted small fixes in radeon, via, rockchip, omap2fb, kmb, gma500, nouveau, virtio, hisilicon, ingenic, s6e63m0 panel, ast, udlfb.
- Add BOE NV110WTM-N61, ys57pss36bh5gq, Khadas TS050 panels.
- Stop using pages with drm_prime_sg_to_page_addr_arrays, and switch all callers to use ttm_sg_tt_init.
- Cleanup compiler and docbook warnings in a lot of fbdev devices.
- Use the drmm_vram_helper in hisilicon.
- Add support for BCM2711 DSI1 in vc4.
- Add support for 8-bit delta RGB panels to ingenic.
- Add documentation on how to test vkms.
- Convert vc4 to atomic helpers.
- Use degamma instead of gamma table in omap, to add support for CTM and color encoding/range properties.
- Rework omap DSI code, and merge all omapdrm modules now that the last omap panel is now a drm panel.
- More refactoring of omap dsi code.
- Enable 10/12 bpc outputs in vc4.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl/bLtAACgkQ/lWMcqZw
E8M5mBAAs6iA3giF+LrzQzszZqOFmtExwjHsvJXDtiINrVubdRov2XbbaOZ+8Eax
Cnnc5QzokJV8v1IReImz+cP7i4uXyWmwQsthY2WvHYLXZmZfZUV+rK4cCtJIKXlR
9EvkEFtdPZ6OpyJ8p1G0r/UNqXxqOl4pEhp6NZdSj1mscz2yux/BuqX+1tX1j5+G
SIfwcKIY+nIwnVpKwhJplJNfFwthRzENxq2KMt+PGLcpOWLHEgwqzKoR+ddTcKf2
Nk1w2OERbnBVRt8NzCIeyczlSp4QuB+NpE5mFEBedmLatGYqwAIwPMt22AVRP9rc
SdXqjVxg3UJ5UNMYXQwjrnJq1nIm1ViYt7za/e2aMC8g9oI7tNQ5uI7XViO6+tk5
3vQV40pHVfMLGzkzqGhv9qHYAkkc+gPMAXwObuzmYppVVZn8dnrkAco7Ib8WPrRc
g8JD0bpIsOrgqCTj2W54fC/ZP7hQZpffOrxWY7alhlriEl4E7To6OvTwEavIzxCm
ajkO129oItOcATDTGiUV3JRWCTdCj4cNz7cQi4pC2QgaUIy8twjm57V8nnFDUCNg
ifi1dIY24DOrHxdmZ8sAWZRoPzcl5a84c8EqEkGZieEsdr3Za4XMZD8tqI2uSJrU
x+OfqgfvqNZenkuc+SUDZJQ855iqdkzJcqZnkAn61VpPh7XCtxk=
=orEC
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2020-12-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v5.12:
UAPI Changes:
- Not necessarily one, but we document that userspace needs to force probe connectors.
Cross-subsystem Changes:
- Require FB_ATY_CT for aty on sparc64.
- video: Fix documentation, and a few compiler warnings.
- Add devicetree bindings for DP connectors.
- dma-buf: Update kernel-doc, and add might_lock for resv objects in begin/end_cpu_access.
Core Changes:
- ttm: Warn when releasing a pinned bo.
- ttm: Cleanup bo size handling.
- cma-helper: Remove prime infix, and implement mmap as GEM CMA functions.
- Split drm_prime_sg_to_page_addr_arrays into 2 functions.
- Add a new api to install irq using devm.
- Update panel kerneldoc to inline style.
- Add DP support to drm/bridge.
- Assorted small fixes to ttm, fb-helper, scheduler.
- Add atomic_commit_setup function callback.
- Automatically use the atomic gamma_set, instead of forcing drivers to declare the default atomic version.
- Allow using degamma for legacy gamma if gamma is not available.
- Clarify that primary/cursor planes are not tied to 1 crtc (depending on possible_crtcs).
- ttm: Cleanup the lru handler.
Driver Changes:
- Add pm support to ingenic.
- Assorted small fixes in radeon, via, rockchip, omap2fb, kmb, gma500, nouveau, virtio, hisilicon, ingenic, s6e63m0 panel, ast, udlfb.
- Add BOE NV110WTM-N61, ys57pss36bh5gq, Khadas TS050 panels.
- Stop using pages with drm_prime_sg_to_page_addr_arrays, and switch all callers to use ttm_sg_tt_init.
- Cleanup compiler and docbook warnings in a lot of fbdev devices.
- Use the drmm_vram_helper in hisilicon.
- Add support for BCM2711 DSI1 in vc4.
- Add support for 8-bit delta RGB panels to ingenic.
- Add documentation on how to test vkms.
- Convert vc4 to atomic helpers.
- Use degamma instead of gamma table in omap, to add support for CTM and color encoding/range properties.
- Rework omap DSI code, and merge all omapdrm modules now that the last omap panel is now a drm panel.
- More refactoring of omap dsi code.
- Enable 10/12 bpc outputs in vc4.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/78381a4f-45fd-aed4-174a-94ba051edd37@linux.intel.com
The bspec has been updated with new vswing programming for RKL DP. No
data is provided for HDMI or eDP, so for now we'll continue to assume
that those are the same as TGL.
Bspec: 49291
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218040535.45492-1-matthew.d.roper@intel.com
Reviewed-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
After boot into kernel. Driver configured ddc pin mapping based on
predefined table in parse_ddi_port(). Now driver configure rkl
ddc pin mapping depends on icp_ddc_pin_map[]. Then this table will
give incorrect gmbus port number to cause HDMI can't work.
Refer to commit cd0a89527d ("drm/i915/rkl: Add DDC pin mapping").
Create two ddc pin table for rkl TGP and CMP pch. Then HDMI can
works properly on rkl.
v2: update patch based on latest dinq branch.
v3: update ddc table for RKL+TGP sku.
RKL+CNP sku will load cnp_ddc_pin_map[] setting.
v4: modify the if/else judgment to avoid nesting.
v5: fix typo in v4.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2577
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117142629.28729-1-shawn.c.lee@intel.com
It programs Plane's calculated x, y, offset to Plane SF register.
It does the calculation of x and y offsets using
skl_calc_main_surface_offset().
v3: Update commit message
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210104205654.238928-4-jose.souza@intel.com
The calculation the offsets of the main surface will be needed by PSR2
selective fetch code so here splitting and exporting it.
No functional changes were done here.
v3: Rebased
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210104205654.238928-3-jose.souza@intel.com
Now using plane damage clips property to calcualte the damaged area.
Selective fetch only supports one region to be fetched so software
needs to calculate a bounding box around all damage clips.
Now that we are not complete fetching each plane, there is another
loop needed as all the plane areas that intersect with the pipe
damaged area needs to be fetched from memory so the complete blending
of all planes can happen.
v2:
- do not shifting new_plane_state->uapi.dst only src is in 16.16 format
v4:
- setting plane selective fetch area using the whole pipe damage area
- mark the whole plane area damaged if plane visibility or alpha
changed
v5:
- taking in consideration src.y1 in the damage coordinates
- adding to the pipe damaged area planes that were visible but are
invisible in the new state
v6:
- consider old state plane coordinates when visibility changes or it
moved to calculate damaged area
- remove from damaged area the portion not in src clip
v7:
- intersec every damage clip with src to minimize damaged area
v8:
- adjust pipe_damaged area to 4 lines grouping
- adjust calculation now that is understood that uapi.src is the
framebuffer coordinates that plane will start to fetch from
v9:
- Only add plane dst or src to damaged_area if visible
- Early skip plane damage calculation if it was not visible in old and
new state
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210104205654.238928-2-jose.souza@intel.com
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a
single global pm_qos does not suffice. (One connector may disable the
dma-latency boost prematurely while the second is still depending on
it.) Instead of a single global pm_qos, track the pm_qos request for
each intel_dp.
v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini
Fixes: 9ee32fea5f ("drm/i915: irq-drive the dp aux communication")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201230202309.23982-1-chris@chris-wilson.co.uk
(cherry picked from commit b3304591f1)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a
single global pm_qos does not suffice. (One connector may disable the
dma-latency boost prematurely while the second is still depending on
it.) Instead of a single global pm_qos, track the pm_qos request for
each intel_dp.
v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini
Fixes: 9ee32fea5f ("drm/i915: irq-drive the dp aux communication")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201230202309.23982-1-chris@chris-wilson.co.uk
accesses, inefficient and disfunctional code. The goal is to remove the
export of irq_to_desc() to prevent these things from creeping up again.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAl/ifgsTHHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoYm6EACAo8sObkuY3oWLagtGj1KHxon53oGZ
VfDw2LYKM+rgJjDWdiyocyxQU5gtm6loWCrIHjH2adRQ4EisB5r8hfI8NZHxNMyq
8khUi822NRBfFN6SCpO8eW9o95euscNQwCzqi7gV9/U/BAKoDoSEYzS4y0YmJlup
mhoikkrFiBuFXplWI0gbP4ihb8S/to2+kTL6o7eBoJY9+fSXIFR3erZ6f3fLjYZG
CQUUysTywdDhLeDkC9vaesXwgdl2XnaPRwcQqmK8Ez0QYNYpawyILUHLD75cIHDu
bHdK2ZoDv/wtad/3BoGTK3+wChz20a/4/IAnBIUVgmnSLsPtW8zNEOPWNNc0aGg+
rtafi5bvJ1lMoSZhkjLWQDOGU6vFaXl9NkC2fpF+dg1skFMT2CyLC8LD/ekmocon
zHAPBva9j3m2A80hI3dUH9azo/IOl1GHG8ccM6SCxY3S/9vWSQChNhQDLe25xBEO
VtKZS7DYFCRiL8mIy9GgwZWof8Vy2iMua2ML+W9a3mC9u3CqSLbCFmLMT/dDoXl1
oHnMdAHk1DRatA8pJAz83C75RxbAS2riGEqtqLEQ6OaNXn6h0oXCanJX9jdKYDBh
z6ijWayPSRMVktN6FDINsVNFe95N4GwYcGPfagIMqyMMhmJDic6apEzEo7iA76lk
cko28MDqTIK4UQ==
=BXv+
-----END PGP SIGNATURE-----
Merge tag 'irq-core-2020-12-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq updates from Thomas Gleixner:
"This is the second attempt after the first one failed miserably and
got zapped to unblock the rest of the interrupt related patches.
A treewide cleanup of interrupt descriptor (ab)use with all sorts of
racy accesses, inefficient and disfunctional code. The goal is to
remove the export of irq_to_desc() to prevent these things from
creeping up again"
* tag 'irq-core-2020-12-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (30 commits)
genirq: Restrict export of irq_to_desc()
xen/events: Implement irq distribution
xen/events: Reduce irq_info:: Spurious_cnt storage size
xen/events: Only force affinity mask for percpu interrupts
xen/events: Use immediate affinity setting
xen/events: Remove disfunct affinity spreading
xen/events: Remove unused bind_evtchn_to_irq_lateeoi()
net/mlx5: Use effective interrupt affinity
net/mlx5: Replace irq_to_desc() abuse
net/mlx4: Use effective interrupt affinity
net/mlx4: Replace irq_to_desc() abuse
PCI: mobiveil: Use irq_data_get_irq_chip_data()
PCI: xilinx-nwl: Use irq_data_get_irq_chip_data()
NTB/msi: Use irq_has_action()
mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc
pinctrl: nomadik: Use irq_has_action()
drm/i915/pmu: Replace open coded kstat_irqs() copy
drm/i915/lpe_audio: Remove pointless irq_to_desc() usage
s390/irq: Use irq_desc_kstat_cpu() in show_msi_interrupt()
parisc/irq: Use irq_desc_kstat_cpu() in show_interrupts()
...
No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-7-lyude@redhat.com
Since we're about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.
v3:
* Rebase
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-6-lyude@redhat.com
Instead of using intel_panel->backlight.level, have the caller provide us
with the current panel backlight value. We'll need this for when we
separate PWM-related backlight callbacks from other means of backlight
control (like DPCD backlight controls), as the caller of each PWM callback
will be responsible for converting the current brightness value to it's
respective PWM level.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-4-lyude@redhat.com
Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight functions is a bit more obvious.
This introduces no functional changes.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-3-lyude@redhat.com
Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.
We also take care not to reprogram the source OUI if it already matches
what we expect. This is just to be careful so that we don't accidentally
take the panel out of any backlight control modes we found it in.
v2:
* Add careful parameter to intel_edp_init_source_oui() to avoid
re-writing the source OUI if it's already been set during driver
initialization
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-2-lyude@redhat.com
If PCON has capability to convert RGB->YCbCr colorspace and also
to 444->420 downsampling then for any YUV420 only mode, we can
let the PCON do all the conversion. If the PCON supports
RGB->YCbCr conversion for all BT2020, BT709, BT601, choose
the one that is selected by userspace via connector colorspace
property, otherwise default to BT601.
v2: As suggested by Uma Shankar, considered case for colorspace
BT709 and BT2020, and default to BT601. Also appended dir
'display' in commit message.
v3: Fixed typo in condition for printing one of the error msg.
v4: As suggested by Uma Shankar:
-Fixed bug in determining the colorspace for RGB->YCbCr conversion.
-Fixed minor formatting issues
Also updated the commit message as per latest changes.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
[Jani: Fixed checkpatch PARENTHESIS_ALIGNMENT.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-16-ankit.k.nautiyal@intel.com
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based
on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder
capabilities.
v2: Addressed review comments from Uma Shankar:
-fixed the error in packing pps parameter values
-added check for pcon in the pcon related function
-appended display in commit message
v3: Only consider non-zero DSC FRL b/w for determining max FRL b/w
supported by sink.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
[Jani: Fixed checkpatch BRACES, LINE_SPACING, PARENTHESIS_ALIGNMENT.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-15-ankit.k.nautiyal@intel.com
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to calculate these PPS paremeters as
per the HDMI2.1 specification.
v2: Addressed review comments given by Uma Shankar:
-added documentation for functions
-fixed typos and errors
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
[Jani: Fixed checkpatch SUSPECT_CODE_INDENT, TYPO_SPELLING]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-14-ankit.k.nautiyal@intel.com
This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to override the existing PPS-metadata, by either
writing the entire new PPS metadata, or by writing only the
PPS override parameters.
v2: Restructured the code to read all capability DPCDs at once and store
in an array in intel_dp structure.
v3: rebase
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
[Jani: Fixed checkpatch PARENTHESIS_ALIGNMENT.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-13-ankit.k.nautiyal@intel.com
In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the PCON → HDMI 2.1 link status is off; reinitiate frl link
training to recover. Also, report HDMI FRL link error count range for
each individual FRL active lane is indicated by
DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
v2: Checked for dpcd read and write failures and added debug message.
(Uma Shankar)
v3: Rearranged code to re-start FRL link training or fall back to
TMDS mode.
v4: Resused function to check frl which inturn restarts FRL and
fallback to TMDS mode.
Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com> (v2)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-12-ankit.k.nautiyal@intel.com
This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.
v2: moved check_frl_training() just after FEC READY, before
starting DP link training.
v3: rebase
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-11-ankit.k.nautiyal@intel.com
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
v2: As suggested by Uma Shankar:
-renamed couple of variables for better clarity
-tweaked the macros used for correct semantics for true/false
-fixed other styling issues.
v3: Completed the TODO for condition for going to FRL mode.
Modified the condition to determine the required FRL b/w
based only on the Pcon and Sink's max FRL values.
Moved the frl structure initialization to intel_dp_init_connector().
v4: Fixed typo in initialization of frl structure.
v5: Always use FRL if its possible, instead of enabling only for
higher modes as done in v3.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com> (v2)
[Jani: Fixed checkpatch BRACES, CONSTANT_COMPARISON.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-10-ankit.k.nautiyal@intel.com
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON.
This patch captures this in dfp cap structure in intel_dp and uses
this to prune connector modes that cannot be supported by the PCON
and FRL bandwidth.
v2: Addressed review comments from Uma Shankar:
-tweaked the comparison of target bw and pcon frl bw to avoid roundup errors.
-minor modification of field names and comments.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-9-ankit.k.nautiyal@intel.com
Ville suggested this as a good idea, let's move this before moving
the crtc code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[Jani: fixed i915xx_plane.h standalone build.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201221110957.18215-1-jani.nikula@intel.com
This file is a monster, let's start simple, the cursor plane code
seems pretty standalone, and splits out easily enough.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
[Jani: cleaned up intel_cursor.h a bit.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201221090449.8288-4-jani.nikula@intel.com
Nothing uses the result and nothing should ever use it in driver code.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20201210194043.862572239@linutronix.de
To support legacy gamma ioctls the drivers need to set
drm_crtc_funcs.gamma_set either to a custom implementation or to
drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the
latter.
We can simplify this by making the core handle it automatically.
Move the drm_atomic_helper_legacy_gamma_set() functionality into
drm_color_mgmt.c to make drm_mode_gamma_set_ioctl() use
drm_crtc_funcs.gamma_set if set or GAMMA_LUT property if not.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Philippe Cornu <philippe.cornu@st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201211114237.213288-2-tomi.valkeinen@ti.com
core:
- documentation updates
- deprecate DRM_FORMAT_MOD_NONE
- atomic crtc enable/disable rework
- GEM convert drivers to gem object functions
- remove SCATTER_LIST_MAX_SEGMENT
sched:
- avoid infinite waits
ttm:
- remove AGP support
- don't modify caching for swapout
- ttm pinning rework
- major TTM reworks
- new backend allocator
- multihop support
vram-helper:
- top down BO placement fix
- TTM changes
- GEM object support
displayport:
- DP 2.0 DPCD prep work
- DP MST extended DPCD caps
fbdev:
- mark as orphaned
amdgpu:
- Initial Vangogh support
- Green Sardine support
- Dimgrey Cavefish support
- SG display support for renoir
- SMU7 improvements
- gfx9+ modiifier support
- CI BACO fixes
radeon:
- expose voltage via hwmon on SUMO
amdkfd:
- fix unique id handling
i915:
- more DG1 enablement
- bigjoiner support
- integer scaling filter support
- async flip support
- ICL+ DSI command mode
- Improve display shutdown
- Display refactoring
- eLLC machine fbdev loading fix
- dma scatterlist fixes
- TGL hang fixes
- eLLC display buffer caching on SKL+
- MOCS PTE seeting for gen9+
msm:
- Shutdown hook
- GPU cooling device support
- DSI 7nm and 10nm phy/pll updates
- sm8150/sm2850 DPU support
- GEM locking re-work
- LLCC system cache support
aspeed:
- sysfs output config support
ast:
- LUT fix
- new display mode
gma500:
- remove 2d framebuffer accel
panfrost:
- move gpu reset to a worker
exynos:
- new HDMI mode support
mediatek:
- MT8167 support
- yaml bindings
- MIPI DSI phy code moved
etnaviv:
- new perf counter
- more lockdep annotation
hibmc:
- i2c DDC support
ingenic:
- pixel clock reset fix
- reserved memory support
- allow both DMA channels at once
- different pixel format support
- 30/24/8-bit palette modes
tilcdc:
- don't keep vblank irq enabled
vc4:
- new maintainer added
- DSI registration fix
virtio:
- blob resource support
- host visible and cross-device support
- uuid api support
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJf0upGAAoJEAx081l5xIa+1EoP/2OkZnl5d9S26qPja15EoRFl
S69OjNci331Br9Y111jD2OCtyqA7w3ppnvCmzpHOBK1IZjhkxOVNC6PSUFSV4M3V
oVOxZK0KaMHpLU2p90NbURWHa2TOktj7IWb9FrhPaEeBECbFuORZ2TbloFhaoyyt
9auEAwqYRPgF8CSYOjQGGZJ85MQN4ImExTdY13+BZgQlGLiSPHfpnLVJ1Q5TPt6A
BLgcU/DFcqOZqyjeu+CuA+LZSHjHeVJxTOGRX65PoTtU3Xus8TRZ/qL4r8e6mAI1
boFLmsevvQlzaQ9GFohc+l9QR/dtnm6SpZxuEelewh7sQvsz2GI+SNF+OHcwHCph
TYIEtyZNaz1bf7ip75FGbhEVaWh2PUMn3zkGlYt+zqAtznYB+dFPc31hhuVn3o5X
c8UwLDUUJLzTePKPZ0UtzIu4Gm2RYTyRsnUAP0OKP/0WaZRyxnoQMYm5Llg7RBe0
5ZJSWjJPBlv1YMWAHQ0YMZ+MhnFE8k4eV/8WfBQnb2INosgzKfJXEmu6ffAkPqSq
jxBsrVQwtOMF2P9VEfdQDv3fs0GKDuZN5ezTFuW59Dt4VYfCUe2FTssSwFBIp5X9
erPJ/nk883rcI6F0PdArNYvWpwPlVSDJyfTxQbYYxVAf8X1ARJCU3PT6iBnGO3i4
d5tveSc8HoOXr4W3eIjn
=c9rl
-----END PGP SIGNATURE-----
Merge tag 'drm-next-2020-12-11' of git://anongit.freedesktop.org/drm/drm
Pull drm updates from Dave Airlie:
"Not a huge amount of big things here, AMD has support for a few new HW
variants (vangogh, green sardine, dimgrey cavefish), Intel has some
more DG1 enablement. We have a few big reworks of the TTM layers and
interfaces, GEM and atomic internal API reworks cross tree. fbdev is
marked orphaned in here as well to reflect the current reality.
core:
- documentation updates
- deprecate DRM_FORMAT_MOD_NONE
- atomic crtc enable/disable rework
- GEM convert drivers to gem object functions
- remove SCATTER_LIST_MAX_SEGMENT
sched:
- avoid infinite waits
ttm:
- remove AGP support
- don't modify caching for swapout
- ttm pinning rework
- major TTM reworks
- new backend allocator
- multihop support
vram-helper:
- top down BO placement fix
- TTM changes
- GEM object support
displayport:
- DP 2.0 DPCD prep work
- DP MST extended DPCD caps
fbdev:
- mark as orphaned
amdgpu:
- Initial Vangogh support
- Green Sardine support
- Dimgrey Cavefish support
- SG display support for renoir
- SMU7 improvements
- gfx9+ modiifier support
- CI BACO fixes
radeon:
- expose voltage via hwmon on SUMO
amdkfd:
- fix unique id handling
i915:
- more DG1 enablement
- bigjoiner support
- integer scaling filter support
- async flip support
- ICL+ DSI command mode
- Improve display shutdown
- Display refactoring
- eLLC machine fbdev loading fix
- dma scatterlist fixes
- TGL hang fixes
- eLLC display buffer caching on SKL+
- MOCS PTE seeting for gen9+
msm:
- Shutdown hook
- GPU cooling device support
- DSI 7nm and 10nm phy/pll updates
- sm8150/sm2850 DPU support
- GEM locking re-work
- LLCC system cache support
aspeed:
- sysfs output config support
ast:
- LUT fix
- new display mode
gma500:
- remove 2d framebuffer accel
panfrost:
- move gpu reset to a worker
exynos:
- new HDMI mode support
mediatek:
- MT8167 support
- yaml bindings
- MIPI DSI phy code moved
etnaviv:
- new perf counter
- more lockdep annotation
hibmc:
- i2c DDC support
ingenic:
- pixel clock reset fix
- reserved memory support
- allow both DMA channels at once
- different pixel format support
- 30/24/8-bit palette modes
tilcdc:
- don't keep vblank irq enabled
vc4:
- new maintainer added
- DSI registration fix
virtio:
- blob resource support
- host visible and cross-device support
- uuid api support"
* tag 'drm-next-2020-12-11' of git://anongit.freedesktop.org/drm/drm: (1754 commits)
drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs
drm/amdgpu: fix size calculation with stolen vga memory
drm/amdgpu: remove amdgpu_ttm_late_init and amdgpu_bo_late_init
drm/amdgpu: free the pre-OS console framebuffer after the first modeset
drm/amdgpu: enable runtime pm using BACO on CI dGPUs
drm/amdgpu/cik: enable BACO reset on Bonaire
drm/amd/pm: update smu10.h WORKLOAD_PPLIB setting for raven
drm/amd/pm: remove one unsupported smu function for vangogh
drm/amd/display: setup system context for APUs
drm/amd/display: add S/G support for Vangogh
drm/amdkfd: Fix leak in dmabuf import
drm/amdgpu: use AMDGPU_NUM_VMID when possible
drm/amdgpu: fix sdma instance fw version and feature version init
drm/amd/pm: update driver if version for dimgrey_cavefish
drm/amd/display: 3.2.115
drm/amd/display: [FW Promotion] Release 0.0.45
drm/amd/display: Revert DCN2.1 dram_clock_change_latency update
drm/amd/display: Enable gpu_vm_support for dcn3.01
drm/amd/display: Fixed the audio noise during mode switching with HDCP mode on
drm/amd/display: Add wm table for Renoir
...
Reduce the module/device probe error into a mere debug to hide issues
where the initial modeset is failing (after lies told by hw probe) and
the system hangs with a livelock in cleaning up the failed commit.
Reported-by: H.J. Lu <hjl.tools@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=210619
Fixes: b3bf99daae ("drm/i915/display: Defer initial modeset until after GGTT is initialised")
Fixes: ccc9e67ab2 ("drm/i915/display: Defer initial modeset until after GGTT is initialised")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: H.J. Lu <hjl.tools@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201210230741.17140-1-chris@chris-wilson.co.uk
For an enabled DSC during HW readout the corresponding power reference
is taken along the CRTC power domain references in
get_crtc_power_domains(). Remove the incorrect get ref from the DSI
encoder hook.
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201209153952.3397959-1-imre.deak@intel.com
Move the initialization of the rc_model_size from the common code into
encoder code, allowing different encoders to specify the size according
to their needs. Keep using the hard coded value in the encoders for now
to make this a non-functional change.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6843c4f6958619f7389180aa92fded7b9fdbb4ba.1607429866.git.jani.nikula@intel.com
The rc_model_size is specified in the DSC config, and the hardware
programming should respect that instead of hard coding a value of 8192.
Regardless, the rc_model_size in DSC config is currently hard coded to
the same value, so this should have no impact, other than allowing the
use of other sizes as needed.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/27d86ad25832bbb985f6e996f3d02dca01a66895.1607429866.git.jani.nikula@intel.com
This patch fixes the slice count computation algorithm
for calculating the slice count based on Peak pixel rate
and the max slice width allowed on the DSC engines.
We need to ensure slice count > min slice count req
as per DP spec based on peak pixel rate and that it is
greater than min slice count based on the max slice width
advertised by DPCD. So use max of these two.
In the prev patch we were using min of these 2 causing it
to violate the max slice width limitation causing a blank
screen on 8K@60.
Fixes: d9218c8f6c ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com
(cherry picked from commit d371d6ea92)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This patch fixes the slice count computation algorithm
for calculating the slice count based on Peak pixel rate
and the max slice width allowed on the DSC engines.
We need to ensure slice count > min slice count req
as per DP spec based on peak pixel rate and that it is
greater than min slice count based on the max slice width
advertised by DPCD. So use max of these two.
In the prev patch we were using min of these 2 causing it
to violate the max slice width limitation causing a blank
screen on 8K@60.
Fixes: d9218c8f6c ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com
The Bspec does not mention polling the FEC Enable
Live status bit. That is only there for debug purposes.
So remove the polling from driver.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201125072634.27664-1-manasi.d.navare@intel.com
Let's do the kill_bigjoiner_slave() thing from
intel_bigjoiner_add_affected_crtcs() since it's related to
what we do there. This cleans up the logic in the
compute_config() loop a bit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201124201156.17095-4-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
If either of the bigjoiner pipes needs a modeset then we need
a modeset on both pipes. Make it so.
v2: Split out the kill_bigjoiner_slave() change (Manasi)
Add affected connectors/planes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201124201156.17095-3-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
drm_atomic_add_affected_planes() only considers planes which
are logically enabled in the uapi state. For bigjoiner we need
to consider planes logically enabled in the hw state. Add a
helper for that.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201124201156.17095-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Currently crtc_state->uapi.plane_mask only tracks logically
enabled planes on the uapi level. For bigjoiner purposes
we want to do the same for the hw state. Let's follow the
pattern established by active_planes & co. here.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201124201156.17095-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
All the display power domain references are wakeref tracked now, so we
can mark intel_display_power_put_unchecked() as an internal function
(for suppressing wakeref tracking in non-debug builds).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130212200.2811939-10-imre.deak@intel.com
Add wakeref tracking for the display power domain reference taken to
keep the display power well functionality disabled.
v2: Add missing wakeref zeroing to intel_power_domains_driver_remove()
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20201201161340.2879202-2-imre.deak@intel.com
Rename power_domains.wakeref to power_domains.init_wakeref to make the
use of this reference clearer. The next patch adds tracking for another
power reference user of the power_domains functionality.
While at it add a missing zero wakeref assert when setting the wakeref.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130212200.2811939-8-imre.deak@intel.com
Factor out helper functions to get/put a set of power domains that are
tracked using their wakeref handles. The same is needed by the next
patch adding tracking for enabled CRTC power domains.
v2: s/uint64_t/u64/ (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20201201161340.2879202-1-imre.deak@intel.com
The for_each_oldnew_intel_crtc_in_state() iterator index does match
crtc->pipe, but using the same thing as array index when getting and
putting CRTC power domains makes things clearer.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130212200.2811939-2-imre.deak@intel.com
This moves the functions into static const instead of having
funcs and data in the same struct.
It leaves the power callback alone, as it is used in a different
manner.
v2: leave power callback alone (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130210945.31850-1-airlied@gmail.com
drm/i915 features for v5.11:
Highlights:
- Enable big joiner to join two pipes to one port to overcome pipe restrictions
(Manasi, Ville, Maarten)
Display:
- More DG1 enabling (Lucas, Aditya)
- Fixes to cases without display (Lucas, José, Jani)
- Initial PSR state improvements (José)
- JSL eDP vswing updates (Tejas)
- Handle EDID declared max 16 bpc (Ville)
- Display refactoring (Ville)
Other:
- GVT features
- Backmerge
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87czzzkk1s.fsf@intel.com
!HAS_DISPLAY() implies !HAS_OVERLAY(), skipping overlay setup anyway, so
return earlier from intel_modeset_init() for clarity.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-4-lucas.demarchi@intel.com
(cherry picked from commit 71c8415d0d)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next scanout frame causing a tear. If we overestimate, we
may unnecessarily delay the update to the next frame, causing visible
jitter.
Replace the warning that we exceed some arbitrary threshold for the
vblank update with a histogram for debugfs.
v2: Add a per-crtc debugfs entry so that the information is easier to
extract when testing individual CRTC, and so that it can be reset before
a test.
v3: Flip the graph on its side; creates space to label the time axis.
Updates: 4684
|
1us |
|
4us |********
|**********
16us |***********
|*****
66us |
|
262us |
|
1ms |
|
4ms |
|
17ms |
|
Min update: 5918ns
Max update: 54781ns
Average update: 16628ns
Overruns > 250us: 0
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1982
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20201202212814.26320-1-chris@chris-wilson.co.uk
Good riddance! Remove the macros and their remaining references in
comments.
The following functions should be used instead, depending on the use
case:
- intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read()
- intel_de_read(), intel_de_write(), intel_de_posting_read()
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130111601.2817-10-jani.nikula@intel.com
There are some corner cases wrt underrun when we enable
FBC with PSR2 on TGL. Recommendation from hardware is to
keep this combination disabled.
Bspec: 50422 HSD: 14010260002
v2: Added psr2 enabled check from crtc_state (Anshuman)
Added Bspec link and HSD referneces (Jose)
v3: Moved the logic to disable fbc to intel_fbc_update_state_cache
and removed the crtc->config usages, as per Ville's recommendation.
v4: Introduced a variable in fbc state_cache instead of the earlier
plane.visible WA, as suggested by Jose.
v5: Dropped an extra check for fbc in intel_fbc_enable and addressed
review comments by Jose.
v6: Move WA to end of function and added Jose's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201201190406.1752-2-uma.shankar@intel.com
Implement Read back of HDR metadata infoframes i.e Dynamic Range
and Mastering Infoframe for LSPCON devices.
v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.
v3: Dropped a redundant wrapper as per Ville's comment.
v4: Dropped a redundant print, added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-14-uma.shankar@intel.com
Implemented Infoframes enabled readback for LSPCON devices.
This will help align the implementation with state readback
infrastructure.
v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.
v3: Added pcon specific infoframe types instead of using the HSW
one's, as recommended by Ville.
v4: Addressed Ville's review comment by adding HDMI infoframe
versions directly instead of DIP wrappers.
v5: Re-ordered the patches to avoid potential break in usage,
as suggested by Ville.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-13-uma.shankar@intel.com
Lspcon has Infoframes as well as DIP for HDR metadata(DRM Infoframe).
Create a separate mechanism for lspcon compared to HDMI in order to
address the same and ensure future scalability.
v2: Streamlined this as per Ville's suggestions, making sure that
HDMI infoframe versions are directly returned instead of a redundant
and confusing DIP overhead.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-12-uma.shankar@intel.com
Enable HDR for LSPCON based on Parade along with MCA.
v2: Added a helper for status reg as suggested by Ville.
v3: Removed a redundant variable, added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Vipin Anand <vipin.anand@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-11-uma.shankar@intel.com
Enable HDMI Colorspace for LSPCON based devices. Sending Colorimetry
data for HDR using AVI infoframe. LSPCON firmware expects this and though
SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
which transfers the same to HDMI sink.
v2: Dropped state managed in drm core as per Jani Nikula's suggestion.
v3: Aligned colorimetry handling for lspcon as per compute_avi_infoframes,
as suggested by Ville.
v4: Finally fixed this with Ville's help, re-phrased the commit header
and description.
v5: Register HDMI colorspace for lspcon and move this to
intel_dp_add_properties as we can't create property at late_register.
Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-9-uma.shankar@intel.com
With LSPCON we use the AVI infoframe to convey the colorimetry
information (as opposed to DP MSA/SDP), so the property we expose
should match the values we can stuff into the infoframe. Ie. we
must use the HDMI variant of the property, even though we drive
LSPCON in PCON mode. To that end just split
intel_attach_colorspace_property() into HDMI and DP variants
and let the caller worry about which one it wants to use.
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-8-uma.shankar@intel.com
Content type is supported on HDMI sink devices. Attached the
property for the same for LSPCON based devices.
v2: Added the content type programming when we are attaching
the property to connector, as suggested by Ville.
v3: Need to attach content type on intel_dp_add_properties
as creating of new properties is not possible at late_register.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-7-uma.shankar@intel.com
Attach HDR property for Gen9 devices with MCA LSPCON
chips.
v2: Cleaned HDR property attachment logic based on capability
as per Jani Nikula's suggestion.
v3: Fixed the HDR property attachment logic as per the new changes
by Kai-Feng to align with lspcon detection failure on some devices.
v4: Add HDR proprty in late_register to handle lspcon detection,
as suggested by Ville.
v5: Init Lspcon only if advertized from BIOS.
v6: Added a Todo to plan a cleanup later, added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-4-uma.shankar@intel.com
Gen9 hardware supports HDMI2.0 through LSPCON chips.
Extending HDR support for MCA LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
Mastering Infoframe (DRM packets) and send it to HDR capable
HDMI sink devices.
v2: Re-used hsw infoframe write implementation for HDR metadata
for LSPCON as per Ville's suggestion.
v3: Addressed Jani Nikula's review comments.
v4: Addressed Ville's review comments, removed redundant wrapper
and checks, passed arguments instead of hardcodings.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-3-uma.shankar@intel.com
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
DPCD register. LSPCON implementations capable of supporting
HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
reads the same, detects the HDR capability and adds this to
intel_lspcon struct.
v2: Addressed Jani Nikula's review comment and fixed the HDR
capability detection logic
v3: Deferred HDR detection from lspcon_init (Ville)
v4: Addressed Ville's minor review comments, added his RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-2-uma.shankar@intel.com
Add the calculations to set plane selective fetch registers depending
in the value of the area damaged.
It is still using the whole plane area as damaged but that will change
in next patches.
v2:
- fixed new_plane_state->uapi.dst.y2 typo in
intel_psr2_sel_fetch_update()
- do not shifthing new_plane_state->uapi.dst only src is in 16.16 format
BSpec: 55229
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130125750.17820-1-jose.souza@intel.com
We know a problem exists in the ifwi shipped with the early
pre-production Tigerlake and DG1 prototypes, later revisions are fine.
However, CI still relies on the earlier ifwi and we grow tired of
the volume of warnings as we wait for replacements.
Since the warning is a bug, we do not want to lose the warning in its
entirety, so only suppress the warning for the platforms currently
exhibiting the issue.
Suggested-by: José Roberto de Souza <gitlab@gitlab.freedesktop.org>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2411
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201127210059.10702-1-chris@chris-wilson.co.uk
For DG1 we have a little of mix up wrt to DDI/port names and indexes.
Bspec refers to the ports as DDIA, DDIB, DDI USBC1 and DDI USBC2
(besides the DDIA, DDIB, DDIC, DDID), but the previous naming is the
most unambiguous one. This means that for any register on Display Engine
we should use the index of A, B, D and E. However in some places this is
not true:
- VBT: uses C and D and have to be mapped to D/E
- IO/Combo: uses C and D, but we already differentiate those when
we created the phy vs port distinction.
This additional mapping for VBT and phy are already covered in previous
patches, so now we can initialize all the DDIs as A, B, D and E.
v2: Squash previous patch enabling just ports A and B since most of the
pumbling code is already merged now
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117084836.2318234-1-lucas.demarchi@intel.com
EDID can declare the maximum supported bpc up to 16,
and apparently there are displays that do so. Currently
we assume 12 bpc is tha max. Fix the assumption and
toss in a MISSING_CASE() for any other value we don't
expect to see.
This fixes modesets with a display with EDID max bpc > 12.
Previously any modeset would just silently fail on platforms
that didn't otherwise limit this via the max_bpc property.
In particular we don't add the max_bpc property to HDMI
ports on gmch platforms, and thus we would see the raw
max_bpc coming from the EDID.
I suppose we could already adjust this to also allow 16bpc,
but seeing as no current platform supports that there is
little point.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2632
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110210447.27454-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit 2ca5a7b85b)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
We can't call drm_plane_state_src() this late for the slave plane since
it would consult the wrong uapi state. We've alreayd done the correct
uapi->hw copy earlier, so let's just preserve the unclipped src/dst
rects using a temp copy across the intel_atomic_plane_check_clipping()
call.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-14-manasi.d.navare@intel.com
Dump debugfs and planar links as well, this will make it easier to debug
when things go wrong.
v4:
* Rebase
Changes since v1:
- Report planar slaves as such, now that we have the plane_state switch.
Changes since v2:
- Rebase on top of the new plane format dumping
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-12-manasi.d.navare@intel.com
We need to look at hw.fb for the framebuffer, and add the translation
for the slave_plane_state. With these changes we set the correct
rectangle on the bigjoiner slave, and don't set incorrect
src/dst/visibility on the slave plane.
v2:
* Manual rebase (Manasi)
v3:
* hw.rotation instead of uapi.rotation (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-11-manasi.d.navare@intel.com
When using bigjoiner userspace is only controlling the "master"
plane, so use its uapi state for the "slave" plane as well.
hw.crtc needs a bit of magic since we don't want to copy that from
the uapi state (as it points to the wrong pipe for the "slave
" plane). Instead we pass the right crtc in explicitly but only
assign it when the uapi state indicates the plane to be logically
enabled (ie. uapi.crtc != NULL).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-10-manasi.d.navare@intel.com
Make sure both the bigjoiner "master" and "slave" plane are
in the state whenever either of them is in the state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-9-manasi.d.navare@intel.com
Skip iterating over bigjoiner slaves, only the master has the state we
care about.
Add the width of the bigjoiner slave to the reconstructed fb.
Hide the bigjoiner slave to userspace, and double the mode on bigjoiner
master.
And last, disable bigjoiner slave from primary if reconstruction fails.
v3:
* Fix the ddi_get_config slave error (Ankit Nautiyal)
v2:
* Unsupported bigjoiner config for initial fb (Ville)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
[vsyrjala:
* Don't do any hw->uapi state copy for bigjoiner slave
* We still have hw.mode so no need to pass it in
* Appease checkpatch]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-7-manasi.d.navare@intel.com
Enabling is done in a special sequence and so should plane updates
be. Ideally the end user never notices the second pipe is used.
This way ideally everything will be tear free, and updates are
really atomic as userspace expects it.
This uses generic modeset_enables() calls like trans port sync
but still has special handling for disable since for slave we
should not disable things like encoder, plls that are not enabled
for slave.
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
[vsyrjala: Appease checkpatch]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-6-manasi.d.navare@intel.com
Make vdsc work when no output is enabled. The big joiner needs VDSC
on the slave, so enable it and set the appropriate bits.
So remove encoder usage from dsc functions.
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-5-manasi.d.navare@intel.com
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
programming is done yet. Blobs are also copied from the master's
crtc_state, so it doesn't depend at commit time on the other
crtc_state.
v6:
* Enable dSC for any mode->hdisplay > 5120
v5:
* Remove intel_dp_max_dotclock (Manasi)
v4:
* Fixes in intel_crtc_compute_config (Ville)
v3:
* Manual Rebase (Manasi)
Changes since v1:
- Rename pipe timings to transcoder timings, as they are now different.
Changes since v2:
- Rework bigjoiner checks; always disable slave when recalculating
master. No need to have a separate bigjoiner pass any more.
- Use pipe_mode instead of transcoder_mode, to clean up the code.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
[vsyrjala:
* hskew isn't a thing
* Do the dsc compute if bigjoiner is enabled, not the other way around]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-4-manasi.d.navare@intel.com
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
v13:
* Allow bigjoiner if hdisplay >5120
v12:
* slice_count logic simplify (Ville)
* Fix unnecessary changes in downstream_mode_valid (Ville)
v11:
* Make intel_dp_can_bigjoiner non static
so it can be used in intel_display (Manasi)
v10:
* Simplify logic (Ville)
* Allow bigjoiner on edp (Ville)
v9:
* Restric Bigjoiner on PORT A (Ville)
v8:
* use source dotclock for max dotclock (Manasi)
v7:
* Add can_bigjoiner() helper (Ville)
* Pass bigjoiner to plane_size validation (Ville)
v6:
* Rebase after dp_downstream mode valid changes (Manasi)
v5:
* Increase max plane width to support 8K with bigjoiner (Maarten)
v4:
* Rebase (Manasi)
Changes since v1:
- Disallow bigjoiner on eDP.
Changes since v2:
- Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
and split off the downstream and source checking to its own function.
(Ville)
v3:
* Rebase (Manasi)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[vsyrjala:
* Keep bigjoiner disabled until everything is ready
* Appease checkpatch]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
When doing the plane state copy from the UV plane to the Y plane
let's just copy the hw state directly instead of using the original
uapi state. The UV plane has already had its uapi state copied into
its hw state, so this extra detour via the uapi state for the Y plane
is pointless.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-2-manasi.d.navare@intel.com
I totally fumbled the ?: usage when generating the DDI encoder
names. Reverse the things that need reversing, and to make it
a bit less messy add a few macros to hide the arithmetic on the
port enums.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Fixes: 2d709a5a62 ("drm/i915: Give DDI encoders even better names")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117154028.8516-1-ville.syrjala@linux.intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
The WA specifies that we need to toggle a SDE chicken bit on and then
off as the final step in preparation for s0ix entry.
Bspec: 33450
Bspec: 8402
However, something is happening after we toggle the bit that causes
the WA to be invalidated. This makes dispcnlunit1_cp_xosc_clkreq
active being already in s0ix state i.e SLP_S0 counter incremented.
Tweaking the Wa_14010685332 by setting the bit on suspend and clearing
it on resume turns down the dispcnlunit1_cp_xosc_clkreq.
B.Spec has Documented this tweaked sequence of WA as an alternative.
Let keep this tweaked WA for Gen11 platforms and keep untweaked WA for
other platforms which never observed this issue.
v2 (MattR):
- Change the comment on the workaround to give PCH names rather than
platform names. Although the bspec is setup to list workarounds by
platform, the hardware team has confirmed that the actual issue being
worked around here is something that was introduced back in the
Cannon Lake PCH and carried forward to subsequent PCH's.
- Extend the untweaked version of the workaround to include PCH_CNP as
well. Note that since PCH_CNP is used to represent CMP, this will
apply on CML and some variants of RKL too.
- Cap the untweaked version of the workaround so that it won't apply to
"fake" PCH's (i.e., DG1). The issue we're working around really is
an issue in the PCH itself, not the South Display, so it shouldn't
apply when there isn't a real PCH.
v3:
- use intel_de_rmw(). [Rodrigo]
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110121700.4338-1-anshuman.gupta@intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
EDID can declare the maximum supported bpc up to 16,
and apparently there are displays that do so. Currently
we assume 12 bpc is tha max. Fix the assumption and
toss in a MISSING_CASE() for any other value we don't
expect to see.
This fixes modesets with a display with EDID max bpc > 12.
Previously any modeset would just silently fail on platforms
that didn't otherwise limit this via the max_bpc property.
In particular we don't add the max_bpc property to HDMI
ports on gmch platforms, and thus we would see the raw
max_bpc coming from the EDID.
I suppose we could already adjust this to also allow 16bpc,
but seeing as no current platform supports that there is
little point.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2632
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110210447.27454-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Currently the DPLL .get_freq() uses pll->state.hw_state which
is not the thing we actually read out (except during driver
load/resume). Outside of that pll->state.hw_state is just the
thing we committed last time around. During state check we
just read the thing into crtc_state->dpll_hw_state, so that
is what we should use for calculating the DPLL output frequency.
I think we used to do this so that the results of the readout
were actually used, but somehow it got changed when the
.get_freq() refactoring happened.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201109231239.17002-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
On icl+ we want to populate both crtc_state.{shared_dpll,dpll_hw_state}
and crtc_state.port_dplls[] during readout, whereas on pre-icl we
want to leave the latter stuff untouched. Rather than adding more ifs
into hsw_get_ddi_port_state() to copy the DPLL hw state around let's
just move the whole dpll readout into hsw_get_ddi_dpll() & co.
Slightly repetitive, but meh.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201109231239.17002-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Store the relative data rate for planes in the crtc state
so that we don't have to use
intel_atomic_crtc_state_for_each_plane_state() to compute
it even for the planes that are no part of the current state.
Should probably just nuke this stuff entirely an use the normal
plane data rate instead. The two are slightly different since this
relative data rate doesn't factor in the actual pixel clock, so
it's a bit odd thing to even call a "data rate". And since the
watermarks are computed based on the actual data rate anyway
I don't really see what the point of this relative data rate
is. But that's for the future...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201106173042.7534-6-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
In order to remove intel_atomic_crtc_state_for_each_plane_state()
from skl_crtc_can_enable_sagv() we can simply precompute whether
each wm level can tolerate the SAGV block time latency or not.
This has the nice side benefit that we remove the duplicated
wm level latency calculation. In fact the copy of that code
we had in skl_crtc_can_enable_sagv() didn't even handle
WaIncreaseLatencyIPCEnabled/Display WA #1141 whereas the copy
in skl_compute_plane_wm() did. So now we just have the one
copy which handles all the w/as.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201106173042.7534-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
intel_atomic_crtc_state_for_each_plane_state() peeks at the
plane's current state without holding the plane's mutex, trusting
that the crtc's mutex will protect it. In practice that does work
since our planes can't move between pipes, but it sets a bad
example. intel_atomic_crtc_state_for_each_plane_state() also
relies on crtc_state.uapi.plane_mask which may be full of lies
when it comes to the bigjoiner stuff, so soon we can't use it as
is anyway. So best to just get rid of it entirely. Which we can
easily do by switching to the g4x/vlv "raw" watermark approach.
Later on we should even be able to move the "raw" watermark
computation into the normal .plane_check() code, leaving only
the merging/clamping of the final watermarks to the later
stages. But that will require adjusting the ilk+ wm code
similarly as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201106173042.7534-3-ville.syrjala@linux.intel.com
No functional changes here, just adds a from_crtc_state
as a prep for bigjoiner
v2:
* More prep with intel_atomic_state (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201113155656.17630-2-manasi.d.navare@intel.com
No functional changes, to align with previous cleanups pass
intel_atomic_state instead of drm_atomic_state.
Also pass this intel_atomic_state with crtc_state to
some of the atomic_check functions.
v2:
* Squash some changes from next patch (Ville)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201113155656.17630-1-manasi.d.navare@intel.com
With bigjoiner, there will be 2 pipes driving 2 halves of 1 transcoder,
because of this, we need a pipe_mode for various calculations, including
for example watermarks, plane clipping, etc.
v10:
* remove redundant pipe_mode assignment (Ville)
v9:
* pipe_mode in state dump nd state check (Ville)
v8:
* Add pipe_mode in readout in verify_crtc_state (Ville)
v7:
* Remove redundant comment (Ville)
* Just keep mode instead of pipe_mode (Ville)
v6:
* renaming in separate function, only pipe_mode here (Ville)
* Add description (Maarten)
v5:
* Rebase (Manasi)
v4:
* Manual rebase (Manasi)
v3:
* Change state to crtc_state, fix rebase err (Manasi)
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
[vsyrjala:
* Fix state checker
* Fix state dump
* Use pipe_mode for linetime watermarks
* Make sure pipe_mode normal timings are correct since the
silly ddb code uses them
* Drop the redundant pipe_mode copies from intel_modeset_pipe_config()
and intel_crtc_copy_uapi_to_hw_state()
* Use drm_mode_copy() all over]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201112191718.16683-7-ville.syrjala@linux.intel.com
Collect up a bunch of derived state "readout" into
a common helper, which we can call from both
intel_encoder_get_config() and intel_crtc_get_pipe_config().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201112191718.16683-6-ville.syrjala@linux.intel.com
Generalize intel_mode_from_pipe_config() to work on any two
arbitrary modes. Also relocate the code for the future, and
make it static since it's not needed elsewhere.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201112191718.16683-5-ville.syrjala@linux.intel.com
No reason to make the callers of intel_crtc_get_pipe_config()
populate hw.active. Let's do it in intel_crtc_get_pipe_config()
itself. hw.enable we leave up to the callers since it's slightly
different for readout vs. state check.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201112191718.16683-4-ville.syrjala@linux.intel.com
Create a new function intel_crtc_get_pipe_config()
that calls platform specific hooks for get_pipe_config()
No functional change here.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
[vsyrjala: Conform to modern i915 coding style, fix patch subject]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201112191718.16683-3-ville.syrjala@linux.intel.com
No functional changes, create a separate intel_encoder_get_config()
function that calls encoder->get_config hook.
This is needed so that later we can add beigjoienr related
readout here.
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
[vsyrjala: Move the code around for the future]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201112191718.16683-2-ville.syrjala@linux.intel.com
No functional changes. This patch just moves some mode checks
around to prepare for adding bigjoiner related mode validation
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201112023954.12301-1-manasi.d.navare@intel.com
