Ville Syrjälä [Tue, 13 Oct 2020 18:11:37 +0000 (21:11 +0300)]
drm/i915: Reorder hpd init vs. display resume
Currently we call .hpd_irq_setup() directly just before display
resume, and follow it with another call via intel_hpd_init()
just afterwards. Assuming the hpd pins are marked as enabled
during the open-coded call these two things do exactly the
same thing (ie. enable HPD interrupts). Which even makes sense
since we definitely need working HPD interrupts for MST sideband
during the display resume.
So let's nuke the open-coded call and move the intel_hpd_init()
call earlier. However we need to leave the poll_init_work stuff
behind after the display resume as that will trigger display
detection while we're resuming. We don't want that trampling over
the display resume process. To make this a bit more symmetric
we turn this into a intel_hpd_poll_{enable,disable}() pair.
So we end up with the following transformation:
intel_hpd_poll_init() -> intel_hpd_poll_enable()
lone intel_hpd_init() -> intel_hpd_init()+intel_hpd_poll_disable()
.hpd_irq_setup()+resume+intel_hpd_init() -> intel_hpd_init()+resume+intel_hpd_poll_disable()
If we really would like to prevent all *long* HPD processing during
display resume we'd need some kind of software mechanism to simply
ignore all long HPDs. Currently we appear to have that just for
fbdev via ifbdev->hpd_suspended. Since we aren't exploding left and
right all the time I guess that's mostly sufficient.
For a bit of history on this, we first got a mechanism to block
hotplug processing during suspend in commit
15239099d7a7 ("drm/i915:
enable irqs earlier when resuming") on account of moving the irq enable
earlier. This then got removed in commit
50c3dc970a09 ("drm/fb-helper:
Fix hpd vs. initial config races") because the fdev initial config
got pushed to a later point. The second ad-hoc hpd_irq_setup() for
resume was added in commit
0e32b39ceed6 ("drm/i915: add DP 1.2 MST
support (v0.7)") to be able to do MST sideband during the resume.
And finally we got a partial resurrection of the hpd blocking
mechanism in commit
e8a8fedd57fd ("drm/i915: Block fbdev HPD
processing during suspend"), but this time it only prevent fbdev
from handling hpd while resuming.
v2: Leave the poll_init_work behind
v3: Remove the extra intel_hpd_poll_disable() from display reset (Lyude)
Add the missing intel_hpd_poll_disable() to display init (Imre)
Cc: Lyude Paul <lyude@redhat.com>
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/20201013181137.30560-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Ville Syrjälä [Fri, 16 Oct 2020 19:48:00 +0000 (22:48 +0300)]
drm/i915: s/intel_dp_sink_dpms/intel_dp_set_power/
Rename intel_dp_sink_dpms() to intel_dp_set_power()
so one doesn't always have to convert from the DPMS
enum values to the actual DP D-states.
Also when dealing with a branch device this has nothing to
do with any sink, so the old name was nonsense anyway.
Also adjust the debug message accordingly, and pimp it
with the standard encoder id+name thing.
Trivial bits done with cocci:
@@
expression DP;
@@
(
- intel_dp_sink_dpms(DP, DRM_MODE_DPMS_OFF)
+ intel_dp_set_power(DP, DP_SET_POWER_D3)
|
- intel_dp_sink_dpms(DP, DRM_MODE_DPMS_ON)
+ intel_dp_set_power(DP, DP_SET_POWER_D0)
)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201016194800.25581-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Fri, 16 Oct 2020 19:47:59 +0000 (22:47 +0300)]
drm/i915: Move the lspcon resume from .reset() to intel_dp_sink_dpms()
Rather that try to trick LSPCON back into PCON mode from the .reset()
hook let's just do that as a regular part of the normal modeset
sequence, which is going to take care of the system resume case. During
a normal modeset this should normally be a nop as the mode should have
already been switched by .detect().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201016194800.25581-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Chris Wilson [Tue, 11 Aug 2020 09:25:32 +0000 (10:25 +0100)]
drm/i915: Drop runtime-pm assert from vgpu io accessors
The "mmio" writes into vgpu registers are simple memory traps from the
guest into the host. We do not need to assert in the guest that the
device is awake for the io as we do not write to the device itself.
However, over time we have refactored all the mmio accessors with the
result that the vgpu reuses the gen2 accessors and so inherits the
assert for runtime-pm of the native device. The assert though has
actually been there since commit
3be0bf5acca6 ("drm/i915: Create vGPU
specific MMIO operations to reduce traps").
References:
3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Yan Zhao <yan.y.zhao@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200811092532.13753-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 19 Oct 2020 10:15:23 +0000 (11:15 +0100)]
drm/i915: Force VT'd workarounds when running as a guest OS
If i915.ko is being used as a passthrough device, it does not know if
the host is using intel_iommu. Mixing the iommu and gfx causes a few
issues (such as scanout overfetch) which we need to workaround inside
the driver, so if we detect we are running under a hypervisor, also
assume the device access is being virtualised.
Reported-by: Stefan Fritsch <sf@sfritsch.de>
Suggested-by: Stefan Fritsch <sf@sfritsch.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Stefan Fritsch <sf@sfritsch.de>
Cc: stable@vger.kernel.org
Tested-by: Stefan Fritsch <sf@sfritsch.de>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201019101523.4145-1-chris@chris-wilson.co.uk
José Roberto de Souza [Mon, 19 Oct 2020 17:56:09 +0000 (10:56 -0700)]
drm/i915/display/fbc: Implement WA
22010751166
Underruns happens when plane height + y offset is not a modulo of 4
when FBC is enabled. It happens when scanline is at vactive - 10 but
that is not feasible to do from the software side so here completely
disabling FBC when height + y offset matches to avoid visual glitches.
Specification says that it only affects TGL display C stepping and
newer but to simply the check and as TGL is already in final costumers
hands, pre-production display stepping A and B was also included.
BSpec: 52887 ICL
BSpec: 52888 EHL/JSL
BSpec: 52890/55378 TGL
BSpec: 53508 DG1
BSpec: 53273 RKL
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/20201019175609.28715-1-jose.souza@intel.com
José Roberto de Souza [Mon, 19 Oct 2020 17:39:06 +0000 (10:39 -0700)]
drm/i915/display: Program DBUF_CTL tracker state service
This sequence is not part of "Sequences to Initialize Display" but
as noted in the MBus page the DBUF_CTL.Tracker_state_service needs
to be set to 8.
BSpec: 49213
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201019173906.18892-1-jose.souza@intel.com
Ville Syrjälä [Thu, 24 Sep 2020 18:41:56 +0000 (21:41 +0300)]
drm/i915: Inline intel_dp_ycbcr420_config()
intel_dp_ycbcr420_config() is rather pointless. Just inline it
directly into intel_dp_compute_config(). This gets rid of the
ugly double assignment of output_format.
Not really sure what the best policy would be when the user
supplies a mode classified by the display as "YCbCr 4:2:0
only", but we know that we can't do YCbCr 4:2:0 output. For
now keep the current behaviour of just silently upgrade
it to RGB 4:4:4.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924184156.24491-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Thu, 24 Sep 2020 18:41:55 +0000 (21:41 +0300)]
drm/i915: Nuke lspcon_ycbcr420_config()
Remove the lspcon special case from intel_dp_compute_config() and
just treat it like any other DFP than can do 4:4:4->4:2:0 conversion.
The only difference between the two codepaths was that the lspcon
code tried to already halve port_clock. That was just total nonsense
as we hadn't even computed the base port_clock at that time.
All that stuff happens intel_dp_compute_link_config*() and it
already takes care of the 4:2:0 clock reduction.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924184156.24491-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Thu, 24 Sep 2020 18:41:54 +0000 (21:41 +0300)]
drm/i915: Nuke lspcon_downsampling
crtc_state->lspcon_downsampling isn't particularly useful at
the moment since we can't even do proper readout for it.
Let's get rid of it. Will help with unifying the LSPCON with
the regular DFP YCbCr output support.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924184156.24491-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Wed, 7 Oct 2020 12:03:27 +0000 (15:03 +0300)]
drm/i915: Mark initial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
Currently we leave the cache_level of the initial fb obj
set to NONE. This means on eLLC machines the first pin_to_display()
will try to switch it to WT which requires a vma unbind+bind.
If that happens during the fbdev initialization rcu does not
seem operational which causes the unbind to get stuck. To
most appearances this looks like a dead machine on boot.
Avoid the unbind by already marking the object cache_level
as WT when creating it. We still do an excplicit ggtt pin
which will rewrite the PTEs anyway, so they will match whatever
cache level we set.
Cc: <stable@vger.kernel.org> # v5.7+
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007120329.17076-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Ville Syrjälä [Thu, 16 Jul 2020 19:04:26 +0000 (22:04 +0300)]
drm/i915: Apply WAC6entrylatency to kbl/cfl
WAC6entrylatency is trying to fix excessive rc6 entry latency caused
by the extra delay from FBC_LLC_READ_CTRL, which is there for some
extra sync with uncore for frame buffer caching in LLC.
Reading through the hsd the recommendation was to set the FBC_LLC_FULLY_OPEN
bit to disable this extra delay entirely. This can be done whenever fb LLC
caching is not used. The alternative suggestion was to reduce the delay to
eg. 0x5 via updated BIOS programming instructions. But all the kbl/cfl
machines I've seen still have the default 0xff programmed. As we never use
fb LLC caching let's just apply the w/a to all skl derivatives to get
consistent rc6 latencies.
I was able to measure the effect of FBC_LLC_READ_CTRL to rc6 latency
via forcewake. Here's a graph of some of the results:
sleep;fw_req=1;wait fw_ack==1;sleep;fw_req=0;wait fw_ack==0
fw_ack==1 duration
160us +----------------------------------------------------------------+
| + + $$+ + + |
| $$ $ $ ******$$ ** $ $**$* #########$$######|
140us |-$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$*$$$$$$$$$$$$$$$$ $$$$$$|
| $ * # |
| $ * # |
120us |$+ * # +-|
|$ * # |
|$ * # # |
100us |$+ ************######################## +-|
|$ * *# |
|$ ***** ######### |
80us |$+ * # #### ## +-|
|$ **** ### # # |
| ** #### FBC_LLC_READ_CTRL: 0x8000 ******* |
60us |-###### FBC_LLC_READ_CTRL: 0xffff #######-|
|## + + FBC_LLC_READ_CTRL: 0x400000ff $$$$$$$ |
+----------------------------------------------------------------+
0ms 10ms 20ms 30ms 40ms 50ms 60ms
sleep duration
The default FBC_LLC_READ_CTRL value of 0xff is documented to give us
a 170usec delay. That tracks well with the knees at 0xffff->~44msec and
0x8000->~22msec we see in the graph.
We can see that if we sleep longer than the FBC_LLC_READ_CTRL delay
we always observe the full (~145usec) rc6 wakeup latency. But if we sleep
for less than the FBC_LLC_READ_CTRL delay we see a quicker fw wakeup,
presumably due the hardware not having yet entered rc6 fully.
The other plateaus in the graph I suspect correspond to some shallower
internal rc states.
v2: s/usec/msec/ typo in commit msg
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716190426.17047-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Matt Roper [Thu, 15 Oct 2020 22:00:38 +0000 (15:00 -0700)]
drm/i915/rkl: Add new cdclk table
A recent bspec update has provided a new cdclk table for RKL. All of
the cdclk values are the same as those we've been using on ICL, TGL,
etc., but we obtain them by doubling both the PLL ratio and CD2X divider
numbers.
Bspec: 49202
Cc: Anusha Srivatsa <anusha.srivatsa@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/20201015220038.271740-1-matthew.d.roper@intel.com
Michel Thierry [Wed, 14 Oct 2020 19:19:37 +0000 (12:19 -0700)]
drm/i915/dgfx: define llc and snooping behaviour
While we do lack the faster shared LLC, we should still have support
for snooping over PCIe.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@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/20201014191937.1266226-11-lucas.demarchi@intel.com
Anshuman Gupta [Wed, 14 Oct 2020 19:19:36 +0000 (12:19 -0700)]
drm/i915/dg1: Update DMC_DEBUG register
Update the DMC_DEBUG_DC5 register to its new location and do not try
reading the DC6 counter since DG1 doesn't support DC6.
v2: Use IS_DGFX() instead of IS_DG1(). Even if not having DC6 is not
directly related to DGFX, the register move to a new location is. So in
future, if there is one supporting DC6, it would just need to add the
other register rather than fixing the case of a wrong register being
read (Matt)
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-10-lucas.demarchi@intel.com
Anshuman Gupta [Wed, 14 Oct 2020 19:19:35 +0000 (12:19 -0700)]
drm/i915/dg1: DG1 does not support DC6
DC6 is not supported on DG1, so change the allowed DC mask for DG1.
This is not yet on bspec, but it has been confirmed by HW engineers.
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@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/20201014191937.1266226-9-lucas.demarchi@intel.com
Stuart Summers [Wed, 14 Oct 2020 19:19:34 +0000 (12:19 -0700)]
drm/i915/dg1: Add initial DG1 workarounds
DG1 shares some workarounds with TGL and RKL and also has some
additional workarounds of its own.
v2: Correct location of Wa_1408615072 (JohnH).
v3: Apply WAs
1606700617,
18011464164 and
22010931296 to DG1 (José)
v4 (Anusha)
- Add Wa_22010271021
- s/Wa_14010096844/Wa_1409836686
v5:
- Extend Wa_14010919138 to all revs (Matt Atwood)
- Power gate media is global gen12 design. (Rodrigo)
- Rebase (Lucas)
v6: use REG_BIT() to fix checkpatch warning (Lucas)
BSpec: 53508
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@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/20201014191937.1266226-8-lucas.demarchi@intel.com
Matt Atwood [Wed, 14 Oct 2020 19:19:33 +0000 (12:19 -0700)]
drm/i915/dg1: Load DMC
Add support to load DMC v2.0.2 on DG1
While we're at it, make TGL use the same GEN12 firmware size definition
and remove obsolete comment.
Bpec: 49230
v2: do not replace GEN12_CSR_MAX_FW_SIZE (from José)
and replace stale comment
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-7-lucas.demarchi@intel.com
Lucas De Marchi [Wed, 14 Oct 2020 19:19:32 +0000 (12:19 -0700)]
drm/i915/dg1: Enable DPLL for DG1
Add DG1 DPLL Enable register macro and use the macro to enable the
correct DPLL based on PLL id. Although we use
_MG_PLL1_ENABLE/_MG_PLL2_ENABLE these are rather combo phys.
While at it, fix coding style: wrong newlines and use if/else chain
v2: Rewrite original patch from Aditya Swarup based on refactors
upstream
Bspec: 49443, 49206
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Aditya Swarup <aditya.swarup@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-6-lucas.demarchi@intel.com
Aditya Swarup [Wed, 14 Oct 2020 19:19:31 +0000 (12:19 -0700)]
drm/i915/dg1: Add and setup DPLLs for DG1
Add entries for dg1 plls and setup dg1_pll_mgr to reuse ICL callbacks.
Initial setup for shared dplls DPLL0/1 for DDIA/DDIB and DPLL2/3 for
DDI-TC1/DDI-TC2. Configure dpll cfgcrx registers to drive the plls on
DG1.
v2 (Lucas): Reword commit message and add missing update_ref_clks hook
(requested by Matt Roper)
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/20201014191937.1266226-5-lucas.demarchi@intel.com
Aditya Swarup [Wed, 14 Oct 2020 19:19:30 +0000 (12:19 -0700)]
drm/i915/dg1: Add DPLL macros for DG1
DG1 has 4 DPLLs where DPLL0 and DPLL1 drive DDIA/B and
DPLL2 and DPLL3 drive DDI-TC1/DDI-TC2.
Introduce DG1_DPLL_CFCRx() helper macros to configure
DPLL registers.
Bspec: 50288, 50299
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-4-lucas.demarchi@intel.com
Lucas De Marchi [Wed, 14 Oct 2020 19:19:29 +0000 (12:19 -0700)]
drm/i915/dg1: Add DG1 power wells
TGL power wells can be re-used for DG1 with the exception of the fake
power well for TC_COLD.
v2: use logic to skip power wells while copying instead of duplicating
the definition of TGL power wells (Matt Roper)
Bspec: 49182
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-3-lucas.demarchi@intel.com
Lucas De Marchi [Wed, 14 Oct 2020 19:19:28 +0000 (12:19 -0700)]
drm/i915/cnl: skip PW_DDI_F on certain skus
The skus guarded by IS_CNL_WITH_PORT_F() have port F and thus they need
those power wells. The others don't have those. Up to now we were
just overriding the number of power wells on !IS_CNL_WITH_PORT_F(),
relying on those power wells to be the last ones. Now that we have logic
in place to skip power wells by id, use it instead.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-2-lucas.demarchi@intel.com
Aditya Swarup [Wed, 14 Oct 2020 19:19:27 +0000 (12:19 -0700)]
drm/i915/display: allow to skip certain power wells
This allows us to skip power wells on a platform allowing it to re-use
the table from another one instead of having to create a new table from
scratch that is basically a copy with a few removals.
Cc: Imre Deak <imre.deak@intel.com>
Suggested-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
[ Adapt ignore logic to be based on pw id rather than adding a new
field, as suggested by Imre ]
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-1-lucas.demarchi@intel.com
Tejas Upadhyay [Tue, 13 Oct 2020 19:29:48 +0000 (00:59 +0530)]
drm/i915/jsl: Split EHL/JSL platform info and PCI ids
Recently we came across requirement to identify EHL and JSL
platform to program them differently. Thus Split the basic
platform definition, macros, and PCI IDs to differentiate
between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
with IS_JSL_EHL everywhere.
Changes since V1 :
- Rebased to avoid merge conflicts
- Added missed check for jasperlake in intel_uc_fw.c
Cc : Matt Roper <matthew.d.roper@intel.com>
Cc : Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201013192948.63470-1-tejaskumarx.surendrakumar.upadhyay@intel.com
Aaron Ma [Fri, 9 Oct 2020 08:57:50 +0000 (16:57 +0800)]
drm/i915: Force DPCD backlight mode for BOE 2270 panel
BOE 2270 panel failed to control backlight brightness.
Add it in edid quirks to force using DPCD backlight control.
Then the brightness can be controlled.
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201009085750.88490-2-aaron.ma@canonical.com
Aaron Ma [Fri, 9 Oct 2020 08:57:49 +0000 (16:57 +0800)]
drm/i915/dpcd_bl: uncheck PWM_PIN_CAP when detect eDP backlight capabilities
BOE panel with ID 2270 claims both PWM_PIN_CAP and AUX_SET_CAP backlight
control bits, but default chip backlight failed to control brightness.
Check AUX_SET_CAP and proceed to check quirks or VBT backlight type.
DPCD can control the brightness of this pannel.
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201009085750.88490-1-aaron.ma@canonical.com
Sean Paul [Fri, 18 Sep 2020 00:28:42 +0000 (20:28 -0400)]
drm/i915/dp: Tweak initial dpcd backlight.enabled value
In commit
79946723092b ("drm/i915: Assume 100% brightness when not in
DPCD control mode"), we fixed the brightness level when DPCD control was
not active to max brightness. This is as good as we can guess since most
backlights go on full when uncontrolled.
However in doing so we changed the semantics of the initial
'backlight.enabled' value. At least on Pixelbooks, they were relying
on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
boot such that enabled would be false. This causes the device to be
enabled when the brightness is set. Without this, brightness control
doesn't work. So by changing brightness to max, we also flipped enabled
to be true on boot.
To fix this, make enabled a function of brightness and backlight control
mechanism.
Fixes:
79946723092b ("drm/i915: Assume 100% brightness when not in DPCD control mode")
Cc: Lyude Paul <lyude@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Kevin Chowski <chowski@chromium.org>>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200918002845.32766-1-sean@poorly.run
Imre Deak [Wed, 7 Oct 2020 17:09:17 +0000 (20:09 +0300)]
drm/i915: Switch to LTTPR non-transparent mode link training
The DP Standard's recommendation is to use the LTTPR non-transparent
mode link training if LTTPRs are detected, so let's do this.
Besides power-saving, the advantages of this are that the maximum number
of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in
transparent mode), and it provides a way to narrow down the reason for a
link training failure to a given link segment. Non-transparent mode is
probably also the mode that was tested the most by the industry.
The changes in this patchset:
- Pass the DP PHY that is currently link trained to all LT helpers, so
that these can access the correct LTTPR/DPRX DPCD registers.
- During LT take into account the LTTPR common lane rate/count and the
per LTTPR-PHY vswing/pre-emph limits.
- Switch to LTTPR non-transparent LT mode and train each link segment
according to the sequence in DP Standard v2.0 (complete CR/EQ for
each segment before continuing with the next segment).
v2:
- Switch to non-transparent mode during connector detection, which is
required before reading the per-PHY LTTPR capabilities.
- Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville)
- Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the
same logic to intel_dp_get_link_status(). (Ville)
- Make intel_dp_lttpr_phy_caps() return a pointer to the whole array
instead of a pointer to its first element. (Ville)
- Add the intel_dp_phy_is_downstream_of_source() helper. (Ville)
- Add a code comment about the disable->enable quirk of
non-transparent mode.
- Add the intel_dp_training_pattern_set_reg() helper.
- Fix checkpatch/sparse warns.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
Imre Deak [Wed, 7 Oct 2020 17:09:16 +0000 (20:09 +0300)]
drm/i915: Switch to LTTPR transparent mode link training
By default LTTPRs should be in transparent link training mode,
nevertheless in this patch we switch to this default mode explicitly.
The DP Standard recommends this, supposedly because an LTTPR may be left
in the non-transparent mode (by BIOS, previous kernel, or after reset
due to a firmware bug). I haven't seen this happening, but let's follow
the DP Standard.
v2:
- Add a code comment about the explicit disabling of non-transparent
mode.
v3:
- Move check to prevent initing LTTPRs on eDP to init_dp_lttpr_init().
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-6-imre.deak@intel.com
Imre Deak [Wed, 7 Oct 2020 17:09:15 +0000 (20:09 +0300)]
drm/dp: Add LTTPR helpers
Add the helpers and register definitions needed to read out the common
and per-PHY LTTPR capabilities and perform link training in the LTTPR
non-transparent mode.
v2:
- Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
of adding these to i915. (Ville)
v3:
- Use memmove() to convert LTTPR to DPRX link status format. (Ville)
Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-5-imre.deak@intel.com
Imre Deak [Wed, 7 Oct 2020 17:09:14 +0000 (20:09 +0300)]
drm/i915: Factor out a helper to disable the DPCD training pattern
To prepare for a follow-up LTTPR change factor out a helper to disable
the training pattern in DPCD. We'll need to do this for each LTTPR
(without programming the port to output the idle pattern) when training
in LTTPR non-transparent mode.
While at it also move the disable-link-training logic from
intel_dp_set_link_train() to intel_dp_stop_link_train(), since the
latter is the only user of this.
v2:
- Move the disable-link-training logic to intel_dp_stop_link_train()
(Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-4-imre.deak@intel.com
Imre Deak [Wed, 7 Oct 2020 17:09:13 +0000 (20:09 +0300)]
drm/i915: Simplify the link training functions
Split the prepare, link training, fallback-handling steps into their own
functions for clarity and as a preparation for the upcoming LTTPR
changes.
While at it also:
- Unexport and inline intel_dp_set_idle_link_train(), which is used at a
single place.
- Add some documentation to functions that are exported or that can use
a better description about which part of the LT sequence they
implement.
v2: (Ville)
- Unexport/inline intel_dp_set_idle_link_train()
- Make the documentation of
intel_dp_prepare_link_train()/intel_dp_stop_link_train() more accurate
wrt. HW specific details.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-3-imre.deak@intel.com
Imre Deak [Wed, 7 Oct 2020 17:09:12 +0000 (20:09 +0300)]
drm/i915: Fix DP link training pattern mask
An LTTPR can be trained with training pattern 4 even if the DPCD
revision is < 1.4, but drm_dp_training_pattern_mask() would change
pattern 4 to pattern 3 on those DPCD revisions.
Since intel_dp_training_pattern() makes already sure that the proper
training pattern is used, all that needs to be masked out is the
scrambling disable flag, which is or'd to the mask later based on the
training pattern.
v2:
- Use a helper instead of open-coding the masking. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-2-imre.deak@intel.com
Matt Roper [Fri, 9 Oct 2020 19:44:42 +0000 (12:44 -0700)]
drm/i915: Update gen12 multicast register ranges
The updated bspec forcewake table also provides us with new multicast
ranges that should be reflected in our workaround code.
Note that there are different types of multicast registers with
different styles of replication and different steering registers. The
i915 MCR range lists we're updating here are only used to ensure we can
verify workarounds properly (i.e., if we can't steer register reads we
don't want to verify workarounds where an unsteered read might hit a
fused-off instance of the unit). Because of this, we don't need to
include any of the multicast ranges where all instances of the register
will always present and fusing doesn't play a role. Specifically, that
means that we are not including the MCR ranges designated as "SQIDI" in
the bspec.
Bspec: 66696
Cc: Caz Yokoyama <caz.yokoyama@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201009194442.3668677-4-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Matt Roper [Fri, 9 Oct 2020 19:44:41 +0000 (12:44 -0700)]
drm/i915: Update gen12 forcewake table
The bspec's forcewake page was very stale and out of date for recent
platforms. The hardware team finally provided us with an updated gen12
table (which applies to TGL, RKL, and DG1) and there are a lot of
changes.
v2:
- Add comments showing the subregions of ranges that we've combined for
ease of code review. (Jose)
- Rebase on the s/FORCEWAKE_BLITTER/FORCEWAKE_GT/ patch
Bspec: 66696
Cc: Caz Yokoyama <caz.yokoyama@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201009194442.3668677-3-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Matt Roper [Fri, 9 Oct 2020 19:44:40 +0000 (12:44 -0700)]
drm/i915: Rename FORCEWAKE_BLITTER to FORCEWAKE_GT
The power well that we've been referring to as the 'blitter' well is
actually more of a general GT power well which contains a lot of things
other than the blitter engine registers. The FORCEWAKE_BLITTER name in
the code was used for historic reasons, but no longer matches how the
bspec describes this power well and just causes confusion for people not
familiar with this area of the code. Let's rename it to FORCEWAKE_GT to
more accurately describe the role of the power well and match how the
modern bspec refers to it.
v2:
- Add a comment noting that the GT power well includes the blitter
engine. (Jose)
Bspec: 66696, 66534, 67609
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201009194442.3668677-2-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
José Roberto de Souza [Wed, 7 Oct 2020 19:52:38 +0000 (12:52 -0700)]
drm/i915/display: Program PSR2 selective fetch registers
Another step towards PSR2 selective fetch, here programming plane
selective fetch registers and MAN_TRK_CTL enabling selective fetch but
for now it is fetching the whole area of the planes.
The damaged area calculation will come as next and final step.
v2:
- removed warn on when no plane is visible in state
- removed calculations using plane damaged area in
intel_psr2_program_plane_sel_fetch()
v3:
- do not shift 16 positions the plane dst coordinates, only src is
shifted
v4:
- only setting PLANE_SEL_FETCH_CTL_ENABLE and MCURSOR_MODE in
PLANE_SEL_FETCH_CTL
v5:
- not masking bits for cursor
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007195238.53955-3-jose.souza@intel.com
José Roberto de Souza [Wed, 7 Oct 2020 19:52:37 +0000 (12:52 -0700)]
drm/i915/display: Check PSR parameter and flag only in state compute phase
Due to the debugfs flag, has_psr2 in CRTC state could have a different
value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
and selective fetch) to be set to not a expected state.
So here only taking in consideration the parameter and debugfs flag
when computing PSR state, this way the CRTC state will also have
the correct state.
intel_psr_fastset_force() was already broken as
intel_psr_compute_config() was already only enabling PSR when
psr_global_enabled() and all other PSR requirements are met.
So some changes was required in this function, now it iterates over
all connectors, if it is a eDP connector and is active force a modeset
in the CRTC driving this connector, what will cause the new PSR state
to be set based on the debugfs flag.
v2:
- end connector iterator in error cases
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007195238.53955-2-jose.souza@intel.com
José Roberto de Souza [Wed, 7 Oct 2020 19:52:36 +0000 (12:52 -0700)]
drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
For platforms without selective fetch this register is reserved so
do not write 0 to it.
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007195238.53955-1-jose.souza@intel.com
José Roberto de Souza [Thu, 8 Oct 2020 21:19:32 +0000 (14:19 -0700)]
drm/i915/vbt: Add VRR VBT toggle
This will be used in future but already adding to VBT so we are
updated with VBT changes.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-3-jose.souza@intel.com
José Roberto de Souza [Thu, 8 Oct 2020 21:19:31 +0000 (14:19 -0700)]
drm/i915/vbt: Update the version and expected size of BDB_GENERAL_DEFINITIONS map
This will remove the "Expected child device config size for VBT
version 235 not known" debug message seen in TGL, although this is not
fixing anything it good to keep our VBT parser updated.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-2-jose.souza@intel.com
José Roberto de Souza [Thu, 8 Oct 2020 21:19:30 +0000 (14:19 -0700)]
drm/i915/vbt: Fix backlight parsing for VBT 234+
Child min_brightness is obsolete from VBT 234+, instead the new
min_brightness field in the main structure should be used.
This new field is 16 bits wide, so backlight_precision_bits is needed
to check if value needs to be scaled down but it is only available in
VBT 236+ so working around it by using the also new backlight_level
in the main struct.
v2:
- missed that backlight_data->level is also obsolete
v3:
- s/backlight/brightness to better match specification
- using u16 to specify brightness level instead of a u32 : 16
BSpec: 20149
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-1-jose.souza@intel.com
Ville Syrjälä [Thu, 8 Oct 2020 10:16:08 +0000 (13:16 +0300)]
drm/i915: s/int/u32/ for aux_offset/alignment
ggtt offsets/alignments are u32 everywhere else. Don't use
a signed int for them here.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008101608.8652-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Fri, 9 Oct 2020 12:00:28 +0000 (15:00 +0300)]
drm/i915: Skip aux plane stuff when there is no aux plane
when the hardware isn't going to use the aux plane there's no
real point in dealing with the relevant hardware restrictions.
So let's just skip all that when not necessary.
We can now also remove the offset=~0xfff behaviour for unused
color planes. Let's just zero out everyting so as to not leave
stale garbage behind to confuse people debugging the code.
v2: Explicitly set AUX_DIST to zero when there is no aux plane
Reviewed-by: Imre Deak <imre.deak@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201009120028.32422-1-ville.syrjala@linux.intel.com
Ville Syrjälä [Thu, 8 Oct 2020 10:16:06 +0000 (13:16 +0300)]
drm/i915: Set all unused color plane offsets to ~0xfff again
When the number of potential color planes grew to 4 we stopped
setting all unused color plane offsets to ~0xfff. The code
still tries to do this, but actually does nothing since the
loop limits are bogus.
skl_check_main_surface() actually depends on this ~0xfff
behaviour as it will make sure to move the main surface
offset below the aux surface offset because the hardware
AUX_DIST must be a non-negative value [1], and for simplicity
it doesn't bother checking if the AUX plane is actually
needed or not. So currently it may end up shuffling the
main surface around based on some stale leftover AUX offset.
The skl+ plane code also just blindly calculates the AUX_DIST
whether or not the AUX plane is actually needed by the hw or
not, and that too will now potentially use some stale AUX
surface offset in the calculation. Would seem nicer to
guarantee a consistent non-negative AUX_DIST always.
So bring back the original ~0xfff offset behaviour for
unused color planes. Though it doesn't seem super likely
that this inconsistency would cause any real issues.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Fixes:
2dfbf9d2873a ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008101608.8652-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Mon, 5 Oct 2020 17:14:41 +0000 (20:14 +0300)]
drm/i915: Rename i915_{save,restore}_state()
i915_{save,restore}_state() are actually all about the display.
Currently they are split into display part + SWF part. But since
the SWF part is also related to the display let's just move that
part into its own thing and flip the roles around so that the
current display part is the main function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201005171441.26612-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 1 Oct 2020 15:16:40 +0000 (18:16 +0300)]
drm/i915: Wait for VLV/CHV/BXT/GLK DSI panel power cycle delay on reboot
As with eDP and LVDS we should also respect the power cycle
delay on DSI panels. We are not using the power sequencer
for these, and we have no optimizations around the sleep
duration, so we just msleep() the whole thing away.
Note that the ICL+ DSI code doesn't seem to have any power
off/power cycle delay handling whatsoever. The only thing it
handles is the power on delay. As that looks pretty busted
in general I won't bother dealing with it for the time being.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 1 Oct 2020 15:16:39 +0000 (18:16 +0300)]
drm/i915: Wait for LVDS panel power cycle delay on reboot
Just like with eDP let's wait for the power sequencer power
cycle delay before we reboot the machine, as otherwise we
can't guarantee the panel's minimum power cycle delay will
be respected.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 1 Oct 2020 15:16:38 +0000 (18:16 +0300)]
drm/i915: Wait for eDP panel power cycle delay on reboot on all platforms
Extend the eDP panel power cycle delay wait on reboot handling
to cover all platforms. No reason to think that VLV/CHV are
in any way special since the documentation states that the
hardware power cycle delay goes back to its default value on
reset, and that may not be enough for all panels.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 1 Oct 2020 15:16:37 +0000 (18:16 +0300)]
drm/i915: Replace the VLV/CHV eDP reboot notifier with the .shutdown() hook
Currently VLV/CHV use a reboot notifier to make sure the panel
power cycle delay isn't violated across a system reboot. Replace
that with the new encoder .shutdown() hook.
And let's also stop overriding the power cycle delay with the
max value. No idea why the current code does that. The already
programmed delay should be correct.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 1 Oct 2020 15:16:36 +0000 (18:16 +0300)]
drm/i915: Add an encoder .shutdown() hook
Add a new encoder hook .shutdown() which will get called at the end
of the pci .shutdown() hook. We shall use this to deal with the
panel power cycle delay issues.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 1 Oct 2020 15:16:35 +0000 (18:16 +0300)]
drm/i915: Shut down displays gracefully on reboot
Implement the pci .shutdown() hook in order to quiesce the
hardware prior to reboot. The main purpose here is to turn
all displays off. Some displays/other drivers tend to get
confused if the state after reboot isn't exactly as they
expected.
One specific example was the Dell UP2414Q in MST mode.
It would require me to pull the power cord after a reboot
or else it would just not come back to life. Sadly I don't
have that at hand anymore so not sure if it's still
misbehaving without the graceful shutdown, or if we
managed to fix something else since I last tested it.
For good measure we do a gem suspend as well, so that
we match the suspend flow more closely. Also stopping
all DMA and whatnot is probably a good idea for kexec.
I would expect that some kind of GT reset happens on
normal reboot so probably not totally necessary there.
v2: Use the pci .shutdown() hook instead of a reboot notifier (Lukas)
Do the gem suspend for kexec (Chris)
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Matt Roper [Wed, 7 Oct 2020 00:22:10 +0000 (17:22 -0700)]
drm/i915/dg1: provide port/phy mapping for vbt
As with RKL, DG1's VBT outputs are indexed according to PHY rather than
DDI.
Signed-off-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/20201007002210.3678024-8-lucas.demarchi@intel.com
Matt Roper [Wed, 7 Oct 2020 00:22:09 +0000 (17:22 -0700)]
drm/i915/dg1: Update comp master/slave relationships for PHYs
As with RKL, DG1's PHY C acts as a comp master for PHY D.
Bspec: 49291
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-7-lucas.demarchi@intel.com
Matt Roper [Wed, 7 Oct 2020 00:22:08 +0000 (17:22 -0700)]
drm/i915/dg1: Don't program PHY_MISC for PHY-C and PHY-D
The only bit we use in PHY_MISC is DE_IO_COMP_PWR_DOWN, and the bspec
details for that bit tell us that it need only be set for PHY-A and
PHY-B. It also turns out that there isn't even an instance of the
PHY_MISC register for PHY-D on this platform. Let's extend the EHL/RKL
logic that conditionally skips PHY_MISC usage to DG1 as well.
Bspec: 50107
Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-6-lucas.demarchi@intel.com
Lucas De Marchi [Wed, 7 Oct 2020 00:22:07 +0000 (17:22 -0700)]
drm/i915/dg1: gmbus pin mapping
Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
From spec we have registers GPIO_CTL[1-4], so we should not do the 4->9
mapping as in ICL/TGL.
The values for VBT seem wrong in BSpec. For the current boards we
actually have a 1:1 mapping.
BSpec: 49311, 49945, 20124
Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-5-lucas.demarchi@intel.com
Venkata Sandeep Dhanalakota [Wed, 7 Oct 2020 00:22:06 +0000 (17:22 -0700)]
drm/i915/dg1: Increase mmio size to 4MB
On DGFX the register range has been extended to go up to 8MB. However we
only actually use up to address 280000h, so let's increase it to 4MB.
v2 (Lucas): add bspec reference and reword commit message to explain
the 4 vs 8 MB used (requested by Matt Roper)
Bspec: 53616
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-4-lucas.demarchi@intel.com
Lucas De Marchi [Wed, 7 Oct 2020 00:22:05 +0000 (17:22 -0700)]
drm/i915/dg1: Define MOCS table for DG1
DG1 has a new MOCS table. We still use the old definition of the table,
but as for any dgfx card it doesn't contain the control_value values
(these values don't matter as we won't program them).
Bspec: 45101
v2: Reword the comment to state that the last few entries are reserved
instead of "the last two". DG1 reserves four instead of two from
previous platforms (from Matt Roper)
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-3-lucas.demarchi@intel.com
Matt Roper [Wed, 7 Oct 2020 00:22:04 +0000 (17:22 -0700)]
drm/i915/dg1: Initialize RAWCLK properly
DG1 always uses a 38.4 MHz rawclk rather than the 19.2/24 MHz
frequencies on CNP+. Note that register bits associated with this
frequency confusingly use 37 for the divider field rather than 38 as you
might expect.
For simplicity, let's just assume that this 38.4 MHz frequency will hold
true for other future platforms with "fake" PCH south displays and that
the CNP-style behavior will remain for other platforms with a real PCH.
Bspec: 49950
Bspec: 49309
Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@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/20201007002210.3678024-2-lucas.demarchi@intel.com
Lucas De Marchi [Wed, 7 Oct 2020 00:22:03 +0000 (17:22 -0700)]
drm/i915/dg1: add more PCI ids
Synchronize with the current list of DG1 PCI IDs.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-1-lucas.demarchi@intel.com
José Roberto de Souza [Mon, 5 Oct 2020 17:54:47 +0000 (10:54 -0700)]
drm/i915/display/ehl: Limit eDP to HBR2
Recent update in documentation defeatured eDP HBR3 for EHL and JSL.
v2:
- Remove dead code in ehl_get_combo_buf_trans()
v3:
- Rebase
BSpec: 32247
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201005175447.93430-1-jose.souza@intel.com
Imre Deak [Sat, 3 Oct 2020 00:18:46 +0000 (03:18 +0300)]
drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock
Apply Display WA #
22010492432 for combo PHY PLLs too. This should fix a
problem where the PLL output frequency is slightly off with the current
PLL fractional divider value.
I haven't seen an actual case where this causes a problem, but let's
follow the spec. It's also needed on some EHL platforms, but for that we
also need a way to distinguish the affected EHL SKUs, so I leave that
for a follow-up.
v2:
- Apply the WA at one place when calculating the PLL dividers from the
frequency and the frequency from the dividers for all the combo PLL
use cases (DP, HDMI, TBT). (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201003001846.1271151-6-imre.deak@intel.com
Imre Deak [Mon, 5 Oct 2020 23:01:54 +0000 (02:01 +0300)]
drm/i915: Add an encoder hook to sanitize its state during init/resume
Atm, if a full modeset is performed during the initial modeset the link
training will happen with uninitialized max DP rate and lane count. Make
sure the corresponding encoder state is initialized by adding an encoder
hook called during driver init and system resume.
A better alternative would be to store all states in the CRTC state and
make this state available for the link re-training code. Also instead of
the DPCD read in the hook there should be really a proper sink HW
readout in place. Both of these require a bigger rework, so for now opting
for this minimal fix to make at least full initial modesets work.
The patch is based on
https://patchwork.freedesktop.org/patch/101473/?series=10354&rev=3
v2: (Ville)
- s/sanitize_state/sync_state/
- No point in calling the hook when CRTC is disabled, remove the call.
- No point in calling the hook for MST, remove it.
v3: Check only DPCD_REV to avoid clobbering intel_dp->dpcd. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201005230154.1477653-1-imre.deak@intel.com
Imre Deak [Sat, 3 Oct 2020 00:18:44 +0000 (03:18 +0300)]
drm/i915: Check for unsupported DP link rates during initial commit
Some BIOSes set an unsupported/imprecise DP link rate (for instance on
TGL A stepping). Make sure that we do an encoder recompute and a modeset
in this case.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201003001846.1271151-4-imre.deak@intel.com
Imre Deak [Mon, 5 Oct 2020 21:53:10 +0000 (00:53 +0300)]
drm/i915: Move the initial fastset commit check to encoder hooks
Move the checks to decide whether a fastset is possible during the
initial commit to an encoder hook. This check is really encoder specific
and the next patch will also require this adding a DP encoder specific
check.
v2: Fix negated condition in gen11_dsi_initial_fastset_check().
v3: Make sure to call the hook for all encoders on the crtc. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201005215311.1475666-1-imre.deak@intel.com
Imre Deak [Tue, 6 Oct 2020 01:35:55 +0000 (04:35 +0300)]
drm/i915/skl: Work around incorrect BIOS WRPLL PDIV programming
The BIOS of at least one ASUS-Z170M system with an SKL I have programs
the 101b WRPLL PDIV divider value, which is the encoding for PDIV=7 with
bit#0 incorrectly set.
This happens with the
"3840x2160": 30 262750 3840 3888 3920 4000 2160 2163 2168 2191 0x48 0x9
HDMI mode (scaled from a 1024x768 src fb) set by BIOS and the
ref_clock=24000, dco_integer=383, dco_fraction=5802, pdiv=7, qdiv=1, kdiv=1
WRPLL parameters (assuming PDIV=7 was the intended setting). This
corresponds to 262749 PLL frequency/port clock.
Later the driver sets the same mode for which it calculates the same
dco_int/dco_frac/div WRPLL parameters (with the correct PDIV=7 encoding).
Based on the above, let's assume that PDIV=7 was intended and the HW
just ignores bit#0 in the PDIV register field for this setting, treating
100b and 101b encodings the same way.
While at it add the MISSING_CASE() for the p0,p2 divider decodings.
v2: (Ville)
- Add a define for the incorrect divider value.
- Emit only a debug message when detecting the incorrect divider value.
- Use fallthrough from the incorrect divider value case.
- Add the MISSING_CASE()s.
v3: Return 0 freq for incorrect divider values. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201006013555.1488262-1-imre.deak@intel.com
Matt Roper [Thu, 1 Oct 2020 06:39:17 +0000 (23:39 -0700)]
drm/i915/dg1: Wait for pcode/uncore handshake at startup
DG1 does some additional pcode/uncore handshaking at
boot time; this handshaking must complete before various other pcode
commands are effective and before general work is submitted to the GPU.
We need to poll a new pcode mailbox during startup until it reports that
this handshaking is complete.
The bspec doesn't give guidance on how long we may need to wait for this
handshaking to complete. For now, let's just set a really long timeout;
if we still don't get a completion status by the end of that timeout,
we'll just continue on and hope for the best.
v2 (Lucas): Rename macros to make clear the relation between command and
result (requested by José)
Bspec: 52065
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@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/20201001063917.3133475-2-lucas.demarchi@intel.com
Lucas De Marchi [Thu, 1 Oct 2020 06:39:16 +0000 (23:39 -0700)]
drm/i915: don't conflate is_dgfx with fake lmem
When using fake lmem for tests, we are overriding the setting in
device info for dgfx devices. Current users of IS_DGFX() except one are
correct. However, as we add support for DG1, we are going to use it in
additional places to trigger dgfx-only code path.
In future if we need we can use HAS_LMEM() instead of IS_DGFX() in the
places that make sense to also contemplate fake lmem use.
v2: update gen8_gmch_probe() to use HAS_LMEM(): we need to steal the
mappable aperture later(which is fine since it doesn't exist on "DGFX"),
and use it as a substitute for LMEMBAR. The !mappable aperture property
is also useful since it exercises some other parts of the code too.
(Matthew Auld)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001063917.3133475-1-lucas.demarchi@intel.com
Ville Syrjälä [Fri, 2 Oct 2020 09:04:46 +0000 (12:04 +0300)]
drm/i915: Make lspcon_init() static
Make lspcon_init() static since it's no longer needed outside
the compilation unit. This was correct in Kai-Heng's lspcon
patch, but I fumbled this when applying it.
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reported-by: kernel test robot <lkp@intel.com>
Fixes:
f542d671ffce ("drm/i915: Init lspcon after HPD in intel_dp_detect()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201002090446.21104-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Kai-Heng Feng [Wed, 10 Jun 2020 07:55:10 +0000 (15:55 +0800)]
drm/i915: Init lspcon after HPD in intel_dp_detect()
On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[ 3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[ 3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
Seems like the lspcon chip on the system only gets powered after the
cable is plugged.
Consilidate lspcon_init() into lspcon_resume() to dynamically init
lspcon chip, and make HDMI port work.
v6:
- Rebase on latest for-linux-next.
v5:
- Consolidate lspcon_resume() with lspcon_init().
- Move more logic into lspcon code.
v4:
- Trust VBT in intel_infoframe_init().
- Init lspcon in intel_dp_detect().
v3:
- Make sure it's handled under long HPD case.
v2:
- Move lspcon_init() inside of intel_dp_hpd_pulse().
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/203
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200610075542.12882-1-kai.heng.feng@canonical.com
Ville Syrjälä [Tue, 29 Sep 2020 23:34:49 +0000 (02:34 +0300)]
drm/i915: Eliminate intel_dp.regs.dp_tp_{ctl,status}
Now that we've plumbed the crtc state all the way down we can
eliminate the DP_TP_{CTL,STATUS} register offsets from intel_dp,
and instead we derive them directly from the crtc state.
And thus we can get rid of the nasty hack in intel_ddi_get_config()
which mutates intel_dp during the readout.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-12-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Thu, 1 Oct 2020 11:10:53 +0000 (14:10 +0300)]
drm/i915: Plumb crtc_state to link training
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
the short hpd handler.
v2: Add intel_crtc_state forward declaration
v3: Don't kill the PHY test code totally since it's
now in the hotplug work where we can get at the states
v4: Don't resurrect the debug scrambling disable bit (Imre)
Use intel_dp_mst_is_master_trans() (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001111053.24451-1-ville.syrjala@linux.intel.com
Ville Syrjälä [Tue, 29 Sep 2020 23:34:47 +0000 (02:34 +0300)]
drm/i915: Split TGL DKL PHY buf trans per output type
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-10-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Tue, 29 Sep 2020 23:34:46 +0000 (02:34 +0300)]
drm/i915: Split TGL combo PHY buf trans per output type
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-9-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Tue, 29 Sep 2020 23:34:45 +0000 (02:34 +0300)]
drm/i915: Split EHL combo PHY buf trans per output type
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-8-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Tue, 29 Sep 2020 23:34:44 +0000 (02:34 +0300)]
drm/i915: Split ICL MG PHY buf trans per output type
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-7-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Tue, 29 Sep 2020 23:34:43 +0000 (02:34 +0300)]
drm/i915: Split ICL combo PHY buf trans per output type
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-6-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Wed, 30 Sep 2020 10:04:12 +0000 (13:04 +0300)]
drm/i915: Shove the PHY test into the hotplug work
Doing any kind modeset stuff from the short hpd handler is
verboten. The ad-hoc PHY test modeset code violates this. And
by calling various link training related functions it's now
blocking further work to plumb the crtc state down into the
link training code.
Let's hack around that by pushing the PHY test stuff into the
hotplug work where it's less of a problem. Still not great but
at least acceptable. We take a few pages from the link retraining
handbook to handle the locking and whatnot.
v2: Fix the intel_dp_hotplug() return value
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200930100412.9313-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Tue, 29 Sep 2020 23:34:41 +0000 (02:34 +0300)]
drm/i915: Make intel_dp_process_phy_request() static
intel_dp_process_phy_request() has no business being externally
visible. Make it static.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-4-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Tue, 29 Sep 2020 23:34:40 +0000 (02:34 +0300)]
drm/i915: s/old_crtc_state/crtc_state/
intel_dp_enable_port() is called during the enable sequence,
so there is nothing old about the passed in crtc state.
Rename it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Tue, 29 Sep 2020 23:34:39 +0000 (02:34 +0300)]
drm/i915: s/pre_empemph/preemph/
I managed to fumble some functions names. Fix them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Wed, 30 Sep 2020 22:36:42 +0000 (01:36 +0300)]
drm/i915: Fix TGL DKL PHY DP vswing handling
The HDMI vs. not-HDMI check got inverted whem the bogus encoder->type
checks were eliminated. So now we're using 0 as the link rate on DP
and potentially non-zero on HDMI, which is exactly the opposite of
what we want. The original bogus check actually worked more correctly
by accident since if would always evaluate to true. Due to this we
now always use the RBR/HBR1 vswing table and never ever the HBR2+
vswing table. That is probably not a good way to get a high quality
signal at HBR2+ rates. Fix the check so we pick the right table.
Cc: stable@vger.kernel.org
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Fixes:
94641eb6c696 ("drm/i915/display: Fix the encoder type check")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200930223642.28565-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Ville Syrjälä [Thu, 24 Sep 2020 19:48:10 +0000 (22:48 +0300)]
drm/i915: Implement display WA #1142:kbl,cfl,cml
Implement display w/a #1142. This supposedly fixes some underruns
with FBC+VTd. Bspec says we should use the same programming regardless
of circumstances. Apparently we should flip the magic bits before
turning on any planes so let's put this into the early w/as.
Cc: 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/20200924194810.10293-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Tue, 29 Sep 2020 13:13:12 +0000 (16:13 +0300)]
drm/i915: Read DIMM size in Gb rather than GB
CNL+ can report DIMM sizes in .5 GB units. In order to not trauncate
away the .5 GB let's switch to storing the DIMM size in Gb units.
Cc: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929131312.12999-1-ville.syrjala@linux.intel.com
Vandita Kulkarni [Thu, 24 Sep 2020 12:42:09 +0000 (18:12 +0530)]
drm/i915/dsi: Enable software vblank counter
In case of DSI cmd mode, we get hw vblank counter updated after the TE
comes in, if we try to read the hw vblank counter in te handler we
wouldnt have the udpated vblank counter yet. This will lead to a state
where we would send the vblank event to the user space in the next te,
though the frame update would have completed in the first TE duration
itself. Hence switch to using software timestamp based vblank counter.
v2: Use mode_flags from crtc_state (Ville)
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-6-vandita.kulkarni@intel.com
Vandita Kulkarni [Mon, 28 Sep 2020 11:08:34 +0000 (16:38 +0530)]
drm/i915/dsi: Initiate frame request in cmd mode
In TE Gate mode or TE NO_GATE mode on every flip we need to set the
frame update request bit. After this bit is set transcoder hardware will
automatically send the frame data to the panel in case of TE NO_GATE
mode, where it sends after it receives the TE event in case of TE_GATE
mode. Once the frame data is sent to the panel, we see the frame counter
updating.
v2: Use intel_de_read/write
v3: remove the usage of private_flags
v4: Use icl_dsi in func names if non static,
fix code formatting issues. (Jani)
v5: Send frame update request at the beginning of
pipe_update_end, use crtc_state mode_flags (Ville)
v6: Add platform and dsi checks (Ville)
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200928110834.15077-1-vandita.kulkarni@intel.com
Vandita Kulkarni [Thu, 24 Sep 2020 12:42:07 +0000 (18:12 +0530)]
drm/i915/dsi: Add TE handler for dsi cmd mode.
In case of dual link, we get the TE on slave. So clear the TE on slave
DSI IIR.
If we are operating in TE_GATE mode, after we do a frame update, the
transcoder will send the frame data to the panel, after it receives a
TE. Whereas if we are operating in NO_GATE mode then the transcoder will
immediately send the frame data to the panel. We are not dealing with
the periodic command mode here.
v2: Pass only relevant masked bits to the handler (Jani)
v3: Fix the check for cmd mode in TE handler function.
v4: Use intel_handle_vblank instead of drm_handle_vblank (Jani)
v3: Use static on handler func (Jani)
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-4-vandita.kulkarni@intel.com
Vandita Kulkarni [Thu, 24 Sep 2020 12:42:06 +0000 (18:12 +0530)]
i915/dsi: Configure TE interrupt for cmd mode
Configure TE interrupt as part of the vblank enable call flow.
v2: Hide the private flags check inside configure_te (Jani)
v3: Fix the position of masking de_port_masked for DSI_TE.
v4: Simplify the caller of configure_te (Jani)
v5: Clear IIR, remove the usage of private_flags
v6: including icl_dsi header is not needed
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-3-vandita.kulkarni@intel.com
Vandita Kulkarni [Thu, 24 Sep 2020 12:42:05 +0000 (18:12 +0530)]
drm/i915/dsi: Add details about TE in get_config
We need details about enabling TE on which port before we enable TE
through vblank enable path. This is based on the configuration that we
receive from the VBT wrt ports, dual_link.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-2-vandita.kulkarni@intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:56 +0000 (16:16 +0300)]
drm/i915: Replace some gamma_mode ifs with switches
Since gamma_mode can have more than two values on ilk+
let's use switch statements when interpreting them.
v2: Fix typo (Uma)
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-10-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:55 +0000 (16:16 +0300)]
drm/i915: Polish bdw_read_lut_10() a bit
Since bdw_read_lut_10() uses the auto-increment mode we must
have an equal number of entries in the software LUT and the
hardware LUT. WARN if that is not the case.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-9-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:54 +0000 (16:16 +0300)]
drm/i915: Relocate CHV CGM gamma masks
CGM_PIPE_GAMMA_RED_MASK & co. are misplaced. Move then below the
relevant register. And while at it add the degamma counterparts.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-8-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:53 +0000 (16:16 +0300)]
drm/i915: Shuffle chv_cgm_gamma_pack() around a bit
Move chv_cgm_gamma_pack() next to the other CGM gamma functions.
Right now it's stuck in the middle of the CGM degamma functions.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-7-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:52 +0000 (16:16 +0300)]
drm/i915: Reset glk degamma index after programming/readout
Just for some extra consistency let's reset the glk degamma LUT
index back to 0 after we're dong trawling the LUT.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-6-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:51 +0000 (16:16 +0300)]
drm/i915: s/glk_read_lut_10/bdw_read_lut_10/
glk_read_lut_10() works just fine for all bdw+ platforms, so
rename it.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-5-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:50 +0000 (16:16 +0300)]
drm/i915: Include the LUT sizes in the state dump
Dump the sizes of the software LUTs in the state dump. Makes
it a bit easier to see which is present without having to
decode it from the gamma_mode and other bits of state.
v2: Drop a spurious "is" in commit msg (Uma)
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-4-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:49 +0000 (16:16 +0300)]
drm/i915: Move MST master transcoder dump earlier
Move the MST master transcoder dump next to the other transcoder
bits.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-3-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 13:16:48 +0000 (16:16 +0300)]
drm/i915: Fix state checker hw.active/hw.enable readout
Previously intel_dump_pipe_config() used to dump the full crtc state
whether or not the crtc was logically enabled or not. As that meant
occasionally dumping confusing stale garbage I changed it to
check whether the crtc is logically enabled or not. However I did
not realize that the state checker readout code does not
populate crtc_state.hw.{active,enabled}. Hence the state checker
dump would only give us a full dump of the sw state but not the hw
state. Fix that by populating those bits of the hw state as well.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Fixes:
10d75f5428fd ("drm/i915: Fix plane state dumps")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-2-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 25 Sep 2020 12:17:49 +0000 (15:17 +0300)]
drm/i915: Don't hide the intel_crtc_atomic_check() call
Move the intel_crtc_atomic_check() call out from the variable
declarations to a place where we can actually see it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925121749.708-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>