mirros/rockchip-kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
950,929 Commits 18 Branches 0 Tags
7af655bce275f49b200b552921e55673624943c5
Commit Graph

950929 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Ville Syrjälä
7af655bce2 drm/dp: Add drm_dp_downstream_mode() 
The downstream facing port caps in the DPCD can give us a hint
as to what kind of display mode the sink can use if it doesn't
have an EDID. Use that information to pick a suitable mode.

v2: Use Returns: for kdoc (Lyude)
    Add kdocs for drm_display_mode_from_cea_vic() (Lyude)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-14-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 18:33:22 +03:00
Ville Syrjälä
b7feffd584 drm/i915: Configure DP 1.3+ protocol converted HDMI mode 
DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
based on the capabilities of the sink.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-13-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 18:33:01 +03:00
Ville Syrjälä
3977cd1c1d drm/i915: Deal with TMDS DFP clock limits 
Use the new helpers to extract the TMDS clock limits from
the downstream facing port and check them in .mode_valid().

TODO: we should check these in .compute_config() too to eg.
determine if we can do deep color on the HDMI side or not

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-12-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 18:32:05 +03:00
Ville Syrjälä
6509ca051a drm/dp: Add drm_dp_downstream_{min,max}_tmds_clock() 
Add helpers to get the TMDS clock limits for HDMI/DVI downstream
facing ports.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-11-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 18:27:49 +03:00
Ville Syrjälä
fe7cf496e5 drm/i915: Reworkd DP DFP clock handling 
Move the downstream facing port dotclock check into a new function
(intel_dp_mode_valid_downstream()) so that we have a nice future
place where we can collect other related checks.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-10-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 18:26:46 +03:00
Ville Syrjälä
b770e84311 drm/dp: Redo drm_dp_downstream_max_clock() as drm_dp_downstream_max_dotclock() 
We want to differentiate between the DFP dotclock and TMDS clock
limits. Let's convert the current thing to just give us the
dotclock limit.

v2: Use Returns: for kdoc (Lyude)
    Fix up nouveau code too

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-9-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 18:25:52 +03:00
Ville Syrjälä
42f2562ca1 drm/dp: Pimp drm_dp_downstream_max_bpc() 
Deal with more cases in drm_dp_downstream_max_bpc():
- DPCD 1.0 -> assume 8bpc for non-DP
- DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
- DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap
- anything else -> assume 8bpc

v2: Use Returns: for kdoc (Lyude)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-8-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 17:12:15 +03:00
Ville Syrjälä
38784f6f88 drm/dp: Add helpers to identify downstream facing port types 
Add a few helpers to let us better identify which kind of DFP
we're dealing with.

v2: Use Returns: for kdoc (Lyude)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-7-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 17:09:32 +03:00
Ville Syrjälä
530df3c031 drm/i915: Reworkd DFP max bpc handling 
Stash the downstream facing port max bpc away during
intel_dp_set_edid(). We'll soon need the EDID in there so
we can't figure this out so easily during .compute_config() anymore.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-6-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 17:06:05 +03:00
Ville Syrjälä
57d6a6851f drm/dp: Define more downstream facing port caps 
Our definitions for the DPCD DFP capabilities are lacking.
Add the missing bits.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-5-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 17:04:53 +03:00
Ville Syrjälä
a77ed90da6 drm/dp: Define protocol converter DPCD registers 
DP 1.3 and 1.4 introduced some new registers for DP->HDMI protocol
converters. Define those.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-4-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 17:04:11 +03:00
Ville Syrjälä
f7af425dce drm/i915/lspcon: Do not send infoframes to non-HDMI sinks 
Non-HDMI sinks shouldn't be sent infoframes. Check for that when
using LSPCON.

FIXME: How do we turn off infoframes once enabled? Do we even
       have to?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-3-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 17:03:07 +03:00
Ville Syrjälä
637f7240f6 drm/dp: Dump downstream facing port caps 
It helps when the logs have a dump of the DFP capabilities.

v2: Move the dumping to the new helper

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-2-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
 2020-09-17 17:02:08 +03:00
Chris Wilson
9f9f4101fc drm/i915/selftests: Push the fake iommu device from the stack to data 
Since we store a pointer to the fake iommu device that is allocated on
the stack, as soon as we leave the function it goes out of scope and any
future dereference is undefined behaviour. Just in case we may need to
look at the fake iommu device after initialiation, move the allocation
from the stack into the data.

Fixes: 01b9d4e211 ("iommu/vt-d: Use dev_iommu_priv_get/set()")
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/20200916105022.28316-2-chris@chris-wilson.co.uk
 2020-09-16 20:50:31 +01:00
Chris Wilson
b79ffa914e drm/i915: Initialise outparam for error return from wait_for_register 
Just in case the caller passes in 0 for both slow&fast timeouts, make
sure we initialise the stack value returned. Add an assert so that we
don't make the mistake of passing 0 timeouts for the wait.

drivers/gpu/drm/i915/intel_uncore.c:2011 __intel_wait_for_register_fw() error: uninitialized symbol 'reg_value'.

References: 3f649ab728 ("treewide: Remove uninitialized_var() usage")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200916105022.28316-1-chris@chris-wilson.co.uk
 2020-09-16 20:50:31 +01:00
Anusha Srivatsa
400d4953f1 drm/i915/pll: Centralize PLL_ENABLE register lookup 
We currenty check for platform at multiple parts in the driver
to grab the correct PLL. Let us begin to centralize it through a
helper function.

v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)

v3: Clean up combo_pll_disable() (Rodrigo)

v4: s/dev_priv/i915 (Jani)
Move static and return type to the same line( Ville, Jani)

Suggested-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200914175703.15024-1-anusha.srivatsa@intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2020-09-15 15:58:43 -07:00
Ville Syrjälä
e198eea948 drm/i915: Nuke pointless variable 
No point in assigning the function return value to a local
variable if we're just going to use it the one time.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-13-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 18:01:57 +03:00
Ville Syrjälä
6d3144eb36 drm/i915: Introduce intel_hpd_hotplug_irqs() 
Introduce intel_hpd_hotplug_irqs() as a partner to
intel_hpd_enabled_irqs(). There's no need to care about the
encoders which we're not exposing, so we can avoid hardcoding
the masks in various places.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-12-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 18:01:35 +03:00
Ville Syrjälä
da51e4bafd drm/i915: Introduce HPD_PORT_TC<n> 
Make a clean split between hpd pins for DDI vs. TC. This matches
how the actual hardware is split.

And with this we move the DDI/PHY->HPD pin mapping into the encoder
init instead of having to remap yet again in the interrupt code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-11-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:52:43 +03:00
Ville Syrjälä
03c7e4f119 drm/i915: Move hpd_pin setup to encoder init 
Currently DP/HDMI/DDI encoders init their hpd_pin from the
connector init. Let's move it to the encoder init so that
we don't need to add platform specific junk to the connector
init (which is shared by all g4x+ platforms).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-10-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:49:01 +03:00
Ville Syrjälä
815f4ef21f drm/i915: Split icp_hpd_detection_setup() into ddi vs. tc parts 
No reason to stuff both DDI and TC port handling into the same
function. Split it into two.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-9-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:48:49 +03:00
Ville Syrjälä
1db9f992d6 drm/i915: Configure GEN11_{TBT,TC}_HOTPLUG_CTL for ports TC5/6 
gen11_hpd_detection_setup() is missing ports TC5/6. Add them.

TODO: Might be nice to only enable the hpd detection logic
for ports we actually have. Should be rolled out for all
platforms if/when done...

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-8-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:48:33 +03:00
Ville Syrjälä
a52bfcdd80 drm/i915: Nuke the redundant TC/TBT HPD bit defines 
We have nice parametrized GEN11_{TC,TBT}_HOTPLUG() so nuke
the overlapping defines.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-7-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:48:16 +03:00
Ville Syrjälä
5bf22ee410 drm/i915: Add VBT AUX CH H and I 
As with everything else VBT can now specify AUX CH H or I.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-6-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:47:55 +03:00
Ville Syrjälä
176430cc13 drm/i915: Add VBT DVO ports H and I 
VBT has ports H and I since version 217.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-5-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:47:36 +03:00
Ville Syrjälä
244f2e9ce3 drm/i915: Add AUX_CH_{H,I} power domain handling 
AUX CH H/I need their power domains too.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:47:21 +03:00
Ville Syrjälä
07c9b088d7 drm/i915: Add PORT_{H,I} to intel_port_to_power_domain() 
We need to go up to PORT_I (aka. TC6) these days.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:47:11 +03:00
Ville Syrjälä
5526fa0bfd drm/i915: Add more AUX CHs to the enum 
We need to go up to AUX_CH_I (aka. AUX CH USBC6) these days.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
 2020-09-15 17:46:56 +03:00
Ville Syrjälä
b81dddb909 drm/i915: Reduce INTEL_DISPLAY_ENABLED to just treat outputs as disconnected 
Since the display hardware is all there even when INTEL_DISPLAY_ENABLED
return false we have to be capable of shutting it down cleanly so
as to not anger the hw. To that end let's reduce the effect of
!INTEL_DISPLAY_ENABLE to just treating all outputs as disconnected.
Should prevent anyone from automagically enabling any of them, while
still allowing us to cleanly shut them down.

v2: Put the check into the right place for CRT

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910164256.25983-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-15 15:28:21 +03:00
Ville Syrjälä
da27bd41d0 drm/i915: Reduce INTEL_DISPLAY_ENABLED to just removing the outputs 
Having a mode where the display hardware is present but we try
to pretend it isn't just leads to massive headaches when trying
to reason what the fallout might be from skipping some random
bits of programming.

Let's just neuter INTEL_DISPLAY_ENABLED so that we treat the
hardware as fully present, except we just don't register any
outputs. That's still rather sketchy if the outputs are already
enabled when the driver is loaded. I think the simplest solution
would be to probe everything as normal and just return
disconnected" from all .detect() hooks. That would avoid anything
automagically enabling those outputs, but the driver could then
shut things down using the normal codepaths.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200909213824.12390-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-15 14:57:13 +03:00
Rodrigo Vivi
ac03de1f5e drm/i915: Update DRIVER_DATE to 20200914 
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2020-09-14 15:34:23 -04:00
Rodrigo Vivi
5c8d1244c0 drm/i915: Update DRIVER_DATE to 20200914 
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2020-09-14 15:03:18 -04:00
Rodrigo Vivi
301ed83397 Merge tag 'gvt-next-2020-09-10' of https://github.com/intel/gvt-linux into drm-intel-next-queued 
gvt-next-2020-09-10

- Cleanup command access flag (Yan)
- New workaround cmd access fix (Colin)
- MIA reset state fix (Colin)

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910053720.GK28614@zhen-hp.sh.intel.com
 2020-09-14 14:34:20 -04:00
Ville Syrjälä
4de962300b drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV check 
g4x+ sprites have an extra cdclk limitation listed for RGB formats.
For some random reason I chose to use cpp>=4 as the check for that.
While that does actually work let's deobfuscate it by checking
for !is_yuv instead. I suspect is_yuv didn't exist way back when
I originally write the code.

Also drop the duplicate comment.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200206201204.31704-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-14 16:50:09 +03:00
Ville Syrjälä
23d3e3799f drm/i915: Fix g4x+ sprite dotclock limit for upscaling 
Even if we're not doing downscaling we should account for
some of the extra dotclock limitations for g4x+ sprites. In
particular we must never exceed the 90% rule, and with RGB
that limits actually drops to 80%.

So instead of bailing out when upscaling let's clamp the
scaling factor appropriately and go through the rest of
calculation normally. By luck we already did the full
calculations for the 1:1 case.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200206201204.31704-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-14 16:49:19 +03:00
Ville Syrjälä
8dec2fc11b drm/i915: Nuke CACHE_MODE_0 save/restore 
The CACHE_MODE_0 save/restore was added without explanation in
commit 1f84e550a8 ("drm/i915 more registers for S3 (DSPCLK_GATE_D,
CACHE_MODE_0, MI_ARB_STATE)"). If there are any bits we care about
those should be set explicitly during some appropriate init function.
Let's assume it's all good and just nuke this magic save/restore.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-4-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-14 16:20:57 +03:00
Ville Syrjälä
b41e58ffe4 drm/i915: Nuke MI_ARB_STATE save/restore 
Originally added in commit 1f84e550a8 ("drm/i915 more registers for
S3 (DSPCLK_GATE_D, CACHE_MODE_0, MI_ARB_STATE)") to fix some underruns.
I suspect that was due to the trickle feed settings getting clobbered
during suspend. We've been disabling trickle feed explicitly since
commit 20f949670f ("drm/i915: Disable trickle feed via MI_ARB_STATE
for the gen4") so this magic save/restore should no longer be needed.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-14 16:17:19 +03:00
Ville Syrjälä
e8fac46c78 drm/i915: Nuke the magic FBC_CONTROL save/restore 
The FBC_CONTROL save restore is there just to preserve the
compression interval setting. Since commit a68ce21ba0
("drm/i915/fbc: Store the fbc1 compression interval in the params")
we've been explicitly setting the interval to a specific
value, so the sace/restore is now entirely pointless.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-14 16:16:50 +03:00
Ville Syrjälä
0f7071c2d4 drm/i915: Kill unused savePCH_PORT_HOTPLUG 
We don't save/restore PCH_PORT_HOTPLUG so no point in reseving
space for the value.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-14 15:38:39 +03:00
Rodrigo Vivi
0ea8a56de2 Merge drm/drm-next into drm-intel-next-queued 
Sync drm-intel-gt-next here so we can have an unified fixes flow.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2020-09-11 20:00:20 -04:00
Ville Syrjälä
0560c2173e drm/i915: Nuke dpio_phy_iosf_port[] 
There's no real reason to stash away the DPIO PHY IOSF sideband port
numbers for VLV/CHV. Just compute them at runtime in the sideband code.

Gets rid of the oddball intel_init_dpio() function from the high level
init flow.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200907162709.29579-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
 2020-09-11 16:59:49 +03:00
Jani Nikula
4a1a4a4427 drm/i915: move gmbus restore to i915_restore_display 
Logically part of the display restore.

Note: This has been in place since the introduction of gmbus
support. The gmbus code also does the resets before transfers. Is this
really needed, or a historical accident?

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910095227.9466-3-jani.nikula@intel.com
 2020-09-11 13:50:37 +03:00
Jani Nikula
59c0df3cd2 drm/i915: move gen4 GCDGMBUS save/restore to display save/restore 
Logically part of the display save/restore. No functional changes.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910095227.9466-2-jani.nikula@intel.com
 2020-09-11 13:31:38 +03:00
Jani Nikula
5e0e390d02 drm/i915: disable all display features when no display 
Disable all display feature flags when there are no pipes i.e. there is
no display. This should help with not having to additionally check for
HAS_DISPLAY() when a feature flag check would suffice.

Also disable modeset and atomic driver features.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910095227.9466-1-jani.nikula@intel.com
 2020-09-11 13:16:48 +03:00
Maarten Lankhorst
166774a2c2 drm/i915: Fix slightly botched merge in __reloc_entry_gpu 
This function should be an int, not a bool.

Presumably because we had the same 2 reverts in a slightly different
way, git got confused.

Thanks to Dan for reporting. :)

The conflict is between the 3 reverts in drm-fixes:

4993a8a378 ("Revert "drm/i915: Remove i915_gem_object_get_dirty_page()"")
ad5d95e4d5 ("Revert "drm/i915/gem: Async GPU relocations only"")
20561da3a2 ("Revert "drm/i915/gem: Delete unused code"")

And the slightly different combined revert in drm-intel-gt-next, but
with the same goal:

102a0a9051 ("Revert "drm/i915/gem: Async GPU relocations only"")

In the merge commit 1f4b2aca79 ("Merge tag
'drm-intel-gt-next-2020-09-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-next") things
went wrong, but the merge commit view now doesn't show any conflict
anymore (as git tends to do when the resolution picks one or the other
branch).

The need to handle other than just true/false error codes in
__reloc_entry_gpu was added in the dma_resv locking changes in
c43ce12328 ("drm/i915: Use per object locking in execbuf, v12.")

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Dave Airlie <airlied@redhat.com>
[danvet: Explain this entire saga a lot better, adding tons of commit
references. Also note that this was merged before full intel-gfx-CI
results, only after BAT, since the breakage at the BAT run is already
severe enough to block all pre-merge testing.]
Fixes: 1f4b2aca79 ("Merge tag 'drm-intel-gt-next-2020-09-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-next")
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910111225.2184193-1-maarten.lankhorst@linux.intel.com
 2020-09-10 15:19:10 +02:00
Colin Xu
df398e33b8 drm/i915/gvt: Init vreg GUC_STATUS to GS_MIA_IN_RESET 
Although GVT doesn't support guest GuC, MIA core is still expected
to be GS_MIA_IN_RESET after uc HW reset.

Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200819010900.54598-1-colin.xu@intel.com
 2020-09-10 13:49:05 +08:00
Colin Xu
d0a011094a drm/i915/gvt: Add F_CMD_ACCESS for some GEN9 SKU WA MMIO access 
Without F_CMD_ACCESS, guest LRI cmd will fail due to "access to
non-render register" when init below WAs:
WaDisableDynamicCreditSharing: GAMT_CHKN_BIT_REG
WaCompressedResourceSamplerPbeMediaNewHashMode: MMCD_MISC_CTRL

So add F_CMD_ACCESS to the two MMIO.

Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200819010801.53411-1-colin.xu@intel.com
 2020-09-10 13:48:50 +08:00
Yan Zhao
b2feabc6eb drm/i915/gvt: remove F_CMD_ACCESS flag for some registers 
some registers cannot be cmd accessible. remove them from the list

Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Wang Zhi <zhi.a.wang@intel.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200811072720.3525-1-yan.y.zhao@intel.com
 2020-09-10 13:48:30 +08:00
Yan Zhao
7e93a0806f drm/i915/gvt: add/modify interfaces for flag F_CMD_ACCESS 
flag F_CMD_ACCESS represents whether an MMIO is able to be accessed by
GPU commands.
In this patch,
1. add interface to set this flag
2. rename intel_gvt_mmio_is_cmd_access() to
intel_gvt_mmio_is_cmd_accessible() and update its description message.

Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200811070233.3387-1-yan.y.zhao@intel.com
 2020-09-10 13:48:09 +08:00
Yan Zhao
a6c5817a38 drm/i915/gvt: remove flag F_CMD_ACCESSED 
Flag F_CMD_ACCESSED is not used. just remove it.

Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200811063744.3272-1-yan.y.zhao@intel.com
 2020-09-10 13:47:52 +08:00