XE_LPD continues to use the same "skylake-style" watermark
programming as other recent platforms. The only change to the watermark
calculations compared to Display12 is that XE_LPD now allows a
maximum of 255 lines vs the old limit of 31.
Due to the larger possible lines value, the corresponding bits
representing the value in PLANE_WM are also extended, so make sure we
read/write enough bits. Let's also take this opportunity to switch over
to the REG_FIELD notation.
Bspec: 49325
Bspec: 50419
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210514153711.2359617-3-matthew.d.roper@intel.com
The DDI naming template for display version 12 went A-C, TC1-TC6. With
XE_LPD, that naming scheme for DDI's has now changed to A-E, TC1-TC4.
The XE_LPD design keeps the register offsets and bitfields relating to
the TC outputs in the same location they were previously. The new "D"
and "E" outputs now take the locations that were previously used by TC5
and TC6 outputs, or what we would have considered to be outputs "H" and
"I" under the legacy lettering scheme.
For the most part everything will just work as long as we initialize the
output with the proper 'enum port' value. However we do need to take
care to pick the correct AUX channel when parsing the VBT (e.g., a
reference to 'AUX D' is actually asking us to use the 8th aux channel,
not the fourth). We should also make sure that our encoders and aux
channels are named appropriately so that it's easier to correlate driver
debug messages with the bspec instructions.
v2:
- Update handling of TGL_TRANS_CLK_SEL_PORT. (Jose)
v3:
- Add hpd_pin to handle outputs D and E (Jose)
- Fixed conversion of BIOS port to aux ch for TC ports (Jose)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210514153711.2359617-2-matthew.d.roper@intel.com
Aside from the hardware-managed PG0, XE_LPD has power wells 1-2 and
A-D. These power wells should be enabled/disabled according to the
following dependency tree (enable top to bottom, disable bottom to top):
PG0
|
--PG1--
/ \
PGA --PG2--
/ | \
PGB PGC PGD
PWR_WELL_CTL follows the general ICL/TGL design and places PG A-D in the
bits that would have been PG 6-9 under the old scheme.
PWR_WELL_CTL_{DDI,AUX}'s bit indexing for DDI's A-C and TC1 is the same
as TGL, but DDI-D is placed at index 7 (bits 14 & 15).
v2:
- Squash in LPSP status patch from Uma since it's also a
powerwell-specific change.
Bspec: 49233
Bspec: 49503
Bspec: 49504
Bspec: 49505
Bspec: 49296
Bspec: 50090
Bspec: 53920
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-4-matthew.d.roper@intel.com
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
AMDGPU had nearly the exact same issue. This problem description is
therefore copied from my commit message of the AMDGPU patch.
On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-4-wse@tuxedocomputers.com
Couples the decission between RGB and YCbCr420 mode and the check if the
port clock can archive the required frequency. Other checks and
configuration steps that where previously done in between can also be done
before or after.
This allows for are cleaner implementation of retrying different color
encodings.
A slight change in behaviour occurs with this patch: If YCbCr420 is not
allowed but display is YCbCr420 only it no longer fails, but just prints
an error and tries to fallback on RGB.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-3-wse@tuxedocomputers.com
Direction on gen9+ was to stop reading the straps and only rely on the
VBT for marking the port presence. This happened while dealing with
WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
normal flow. See commit 885d3e5b6f ("drm/i915/display: fix comment on
skl straps").
For gen 10 it's hard to say if this will work or not since I can't test
it, so leave it with the same behavior as before.
For PCH_TGP we should still rely on the VBT to make ports E and F not
available.
v2 (Ville):
- use display ver >= 9 to make it consistent with the rest of the
driver instead of checking for == 9
- also handle CNL and only initialize port F if it is
IS_CNL_WITH_PORT_F. Eventually CNL may be removed, but while it
isn't let's keep it consistent everywhere
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-4-lucas.demarchi@intel.com
Since commit 45c0673aac ("drm/i915/bios: start using the
intel_bios_encoder_data directly") we lookup the devdata for each port
in intel_ddi_init() and just return if the port is not present in VBT
(or if we didn't create a fake devdata for it if VBT is not available).
So in intel_display.c we don't have to check
intel_bios_is_port_present(), just rely on the check in
intel_ddi_init().
v2: Rebase on commit 45c0673aac ("drm/i915/bios: start using the
intel_bios_encoder_data directly") re-using that check in intel_ddi_init()
instead of adding a new one.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-2-lucas.demarchi@intel.com
Add support for DPT (display page table). DPT is a
slightly peculiar two level page table scheme used for
tiled scanout buffers (linear uses direct ggtt mapping
still). The plane surface address will point at a page
in the DPT which holds the PTEs for 512 actual pages.
Thus we require 1/512 of the ggttt address space
compared to a direct ggtt mapping.
We create a new DPT address space for each framebuffer and
track two vmas (one for the DPT, another for the ggtt).
TODO:
- Is the i915_address_space approaach sane?
- Maybe don't map the whole DPT to write the PTEs?
- Deal with remapping/rotation? Need to create a
separate DPT for each remapped/rotated plane I
guess. Or else we'd need to make the per-fb DPT
large enough to support potentially several
remapped/rotated vmas. How large should that be?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com>
Cc: Wilson Chris P <Chris.P.Wilson@intel.com>
Cc: Tang CQ <cq.tang@intel.com>
Cc: Auld Matthew <matthew.auld@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Wilson Chris P <Chris.P.Wilson@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-5-imre.deak@intel.com
When scanning out NV12 if we at any time have the plane enabled
while the scaler is disabled we get a pretty catastrophic
underrun.
Let's reorder the operations so that we try to avoid that happening
even if our vblank evade fails and the scaler enable/disable and
the plane enable/disable get latched during two diffent frames.
This takes care of the most common cases. I suppose there is still
at least a theoretical possibility of hitting this if one plane
takes the scaler away from another plane before the second plane
had a chance to set up another scaler for its use. But that
is starting to get a bit complicated, especially since the plane
commit order already has to be carefully sequenced to avoid any
dbuf overlaps. So plugging this 100% may prove somewhat hard...
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506073836.14848-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
I doubt anyone has used the display error state since CS flips
went the way of the dodo. Just nuke it.
It might be semi interesting to have something like this for
FIFO underruns and the like, but as it stands this wouldn't
provide a sufficient amount of information. So would need
an extensive rewrite anyway.
The lockless power well handling is also racy, so this could
just be contributing noise to test results if we end up
accessing something with the relevant power well already
disabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210505191140.14215-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
