Display WA #1178 calls us to tweak some magic bits when doing AUX
to an external combo PHY port. Instead of looking to see if the VBT
has declared such a port (which could in theory even alias with a
declared eDP port on the same PHY) just check the real situation
based on the registered encoders.
The only slight chicken vs. egg situation here is during output
probing. But typically we'd register the eDP ports first and so
once we get to probe anything external on the combo PHY we have
already determined if it's eDP or not.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Replaces wm.max_level with wm.num_levels, since that generally
results in nicer looking code (for-loops can be in standard
form etc.).
Also get rid of the two different wrappers we have for this
(ilk_wm_max_level() and intel_wm_num_levels()). They don't
really do anything for us other than potentially slow things
down if the compiler actually emits the function calls every
time (num_planes*num_wm_levels*higher_level_wm_function_calls
could be a big number). The watermark code already shows up
far too prominently in cpu profiles. Though I must admit that
I didn't look at the generated code this time.
v2: Fix the ilk_wm_merge() off-by-one (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209222504.31478-1-ville.syrjala@linux.intel.com
Switch ilk+ and skl+ platforms to also setting up
wm.max_level and remove a bunch of if ladders as a result.
There will be a tiny change in the debugfs on CHV machines
that have DVFS disabled in the BIOS. Presviously debugfs
would show the latency for the DVFS level as well, but
that will no longer be the case. Which is arguably better
as that number is absolutely meaningless when DVFS can't
be enabled anyway.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209003251.32021-1-ville.syrjala@linux.intel.com
With backlight controller set to -1 in intel_panel_init_alloc() to
distinguish uninitialized values, and controller later being set only if
it's present in VBT, we can end up with -1 for the controller:
[drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation
frequency 200 Hz, active high, min brightness 0, level 255,
controller 4294967295
There's no harm if it happens on platforms that ignore controller due to
only one backlight controller being present, like on VLV above, but play
it safe.
Fixes: bf38bba3e7 ("drm/i915: Try to use the correct power sequencer intiially on bxt/glk")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
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/20230207111626.1839645-1-jani.nikula@intel.com
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs
to be a plain void *. Cast __iomem away and back while the pointer goes
through drmm.
drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/intel_uncore.c:2463:17: expected void volatile [noderef] __iomem *addr
drivers/gpu/drm/i915/intel_uncore.c:2463:17: got void *regs
drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in argument 3 (different address spaces)
drivers/gpu/drm/i915/intel_uncore.c:2494:16: expected void *data
drivers/gpu/drm/i915/intel_uncore.c:2494:16: got void [noderef] __iomem *regs
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-2-jani.nikula@intel.com
We now have some eDP+DSI dual panel systems floating around
where the DSI panel is the secondary LFP and thus needs to
consult "panel type 2" in VBT in order to locate all the
other panel type dependant stuff correctly.
To that end we need to pass in the devdata to
intel_bios_init_panel_late(), otherwise it'll just assume
we want the primary panel type. So let's try to just populate
the vbt.ports[] stuff and encoder->devdata for icl+ DSI
panels as well.
We can't do this on older platforms as there we risk a DSI
port aliasing with a HDMI/DP port, which is a totally legal
thing as the DSI ports live in their own little parallel
universe.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Due to a workaround we have to make sure the WM1 watermarks block/lines
values are sensible even when WM1 is disabled. To that end we copy those
values from WM0.
However since we now keep each wm level enabled on a per-plane basis
it doesn't seem necessary to do that copy when we already have an
enabled WM1 on the current plane. That is, we might be in a situation
where another plane can only do WM0 (and thus needs the copy) but
the current plane's WM1 is still perfectly valid (ie. fits into the
current DDB allocation).
Skipping the copy could avoid reprogramming the plane's registers
needlessly in some cases.
Fixes: a301cb0fca ("drm/i915: Keep plane watermarks enabled more aggressively")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
There are cases, where devices have an HDMI1.4 retimer, and TMDS clock rate
is capped to 340MHz via VBT. In such cases scrambling might be supported
by the platform and an HDMI2.0 sink for lower TMDS rates, but not
supported by the retimer, causing blankouts.
So avoid enabling scrambling, if the TMDS clock is capped to <= 340MHz.
v2: Added comment, documenting the rationale to check for TMDS clock,
before going for scrambling. (Arun)
v3: Fixed the function name to check if source supports scrambling. (Jani)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221222040851.3029514-1-ankit.k.nautiyal@intel.com
Current implementation of async flip w/a relies on assumption that
previous atomic commit contains valid information if async_flip is still
enabled on the plane. It is incorrect. If previous commit did not modify
the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE
errors can be observed:
i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080
i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set
v2: update async_flip_planes in more reliable places (Ville)
v3: reset async_flip_planes and do_async_flip in more scenarios (Ville)
v4: move all resets to plane loops (Ville)
Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127153003.2225111-1-andrzej.hajda@intel.com
SEL_FETCH_CTL registers are armed immediately when plane is disabled.
SEL_FETCH_* instances of plane configuration are used when doing
selective update and normal plane register instances for full updates.
Currently all SEL_FETCH_* registers are written as a part of noarm
plane configuration. If noarm and arm plane configuration are not
happening within same vblank we may end up having plane as a part of
selective update before it's PLANE_SURF register is written.
Fix this by splitting plane selective fetch configuration into arm and
noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm
version.
v3:
- add arm suffix into intel_psr2_disable_plane_sel_fetch
v2:
- drop color_plane parameter from arm part
- dev_priv -> i915 in arm part
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Vinod Govindapillai <vinod.govindapillai@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130080651.3796929-1-jouni.hogander@intel.com
