Eliminate the PIPECONF RMWs from .comit_commit() so
that we can finally declare the whole vblank evade part
(and the noarm() part) of the pipe commit free of register
reads. Or at least I hope that's the last read...
Only the i9xx/ilk codepaths need this for now, but let's
add the same thing for hsw+ just in case we want to start
calling that during fastsets at some point (eg. to change
dithering settings/etc.).
Should open up the way to start experimenting with
different DSB usage approaches for pipe commits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413192607.27533-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Atm the port -> DDI and AUX power domain mapping is specified by relying
on the aliasing of the platform specific intel_display_power_domain enum
values. For instance D12+ platforms refer to the 'D' port and power
domain instances, which doesn't match the bspec terminology, on these
platforms the corresponding port is TC1. To make it clear what
port/domain the code refers to add a mapping between them which matches
the bspec terms on different display versions.
This also allows for removing the aliasing in enum values in a follow-up
patch.
v2: Add the functions to intel_display_power.c, use
intel_display_power_ prefix.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-14-imre.deak@intel.com
Get rid of the inflexible bigjoiner_linked_crtc pointer thing
and just track things as a bitmask of pipes instead. We can
also nuke the bigjoiner_slave boolean as the role of the pipe
can be determined from its position in the bitmask.
It might be possible to nuke the bigjoiner boolean as well
if we make encoder.compute_config() do the bitmask assignment
directly for the master pipe. But for now I left that alone so
that encoer.compute_config() will just flag the state as needing
bigjoiner, and the intel_atomic_check_bigjoiner() is still
responsible for determining the bitmask. But that may have to change
as the encoder may be in the best position to determine how
exactly we should populate the bitmask.
Most places that just looked at the single bigjoiner_linked_crtc
now iterate over the whole bitmask, eliminating the singular
slave pipe assumption.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-11-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Make life simpler by always programming DP M2/N2 with a consistent
value. This will lets use do state readout+chec unconditionally.
I was first going to just set M2/N2=M1/N1 but then it occurred
to me that it might interfere with fastboot on account of BIOS
likely leaving the registers zeroed. So let's zero out the values
instead (except TU where a zero register value actually means '1').
Still not sure that's the best approach but lets go with it for
now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-14-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Make things a bit more explicit by splitting
intel_cpu_transcoder_set_m_n() into separate variants for M1/N1 vs.
M2/N2. Makes the DRRS M/N programming at least more obvious.
Note that for the MST and DRRS cases we don't need to call the
M2/N2 variant at all since the transcoders that support those
do not have the M2/N2 registers.
Same could be said for i9xx_crtc_enable() but I want to do a
higher level code sharing between that valleyview_crtc_enable()
later in which case we do need the M2/N2 variant. This is also
why I keep the transcoder_has_m2_n2() in intel_cpu_transcoder_set_m2_n2()
so the caller doesn't have necessarily care what the chosen
transcoder supports.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
intel_device_info.h references struct pci_dev but does not ensure that
the struct has been declared, causing build failures if something in
other headers changes so that the implicit dependency it is relying on
is no longer satisfied:
In file included from drivers/gpu/drm/i915/intel_device_info.h:32,
from drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:11,
from drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:11:
drivers/gpu/drm/i915/display/intel_display.h:643:39: error: 'struct pci_dev' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
643 | bool intel_modeset_probe_defer(struct pci_dev *pdev);
| ^~~~~~~
cc1: all warnings being treated as errors
Add a declaration of the struct to fix this.
Signed-off-by: Mark Brown <broonie@kernel.org>
Fixes: 94b541f53d ("drm/i915: Add intel_modeset_probe_defer() helper")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211213170753.3680209-1-broonie@kernel.org
Collect the dipslay related mask under the display sub-structure
in intel_device_info.
Note that there is a slight change in behaviour in that we zero
out .display entirely when !HAS_DISPLAY (aka. pipe_mask==0), so
now we also zero out the other masks (although cpu_transocder_mask
should already be zero of pipe_mask is zero). abox_mask is
only used by the display core init when HAS_DISPLAY is true, so
the actual behaviour of the system shouldn't change despite the
zeroing of these masks.
There is a lot more display stuff directly in device info that
could be moved over. Maybe someone else will be inspired to do it...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211210122726.12577-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Nuke the hsw_get_ddi_port_state() eyesore by putting the
readout code into intel_pch_display.c, and calling it directly
from hsw_crt_get_config().
Note that the nuked TRANS_DDI_FUNC_CTL readout from
hsw_get_ddi_port_state() is now etirely redundant since we
get called from the encoder->get_config() so we already know
we're dealing with the correct DDI port. Previously the
code was called from a place where that wasn't known so
it had to checked manually.
v2: Clarify the TRANS_DDI_FUNC_CTL change (Dave)
Nuke the now unused *TRANS_DDI_FUNC_CTL_VAL_TO_PORT() (Dave)
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018153525.21597-1-ville.syrjala@linux.intel.com
Reviewed-by: Dave Airlie <airlied@redhat.com>
A follow-up change will start to disconnect/re-connect PHYs around AUX
transfers and modeset enable/disables. To prepare for that add a new
TypeC PHY disconnected mode, to help tracking the TC-cold blocking power
domain status (no power domain in disconnected state, mode dependent
power domain in connected state).
v2: Move the !disconnected mode and phy-owned asserts in
__intel_tc_port_lock() later in the patchset, when the asserts will
hold. (Jose)
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929132833.2253961-3-imre.deak@intel.com
PIPECONF becamse TRANSCONF when HSW introduced the EDP transcoder.
Bigjoiner is making life even more confusing by introducing
a N:1 relationship between pipes and transcoders. In that case
we only enable/configure the transcoder corresponding to the
master pipe. Let's do some renames to make it clear we're dealing
with the transcoder rather than pipe when it comes to
PIPECONF/TRANSCONF.
I decided to leave the _cpu_ part out from the function/macro
names since the PCH transcoder related stuff already has a
_pch_ in their name. So shouldn't be possible to confuse them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210913144440.23008-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@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
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
