- 20 Oct, 2020 20 commits
-
-
Ville Syrjälä authored
Sort the CFL PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-12-ville.syrjala@linux.intel.comReviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com>
-
Ville Syrjälä authored
Sort the CML PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sort the KBL PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sort the SKL PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sort the HSW PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Most of the HSW PCI IDs are upper case hex numbers, but a few are lower case. Make it consistent so these don't stick out like a sore thumb. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Bunch of the SKL SKUs currently documented as GT3/4 seem to actually be GT3e/4e. Fix up the comments. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Alexei Podtelezhnikov authored
Add three new devices 0x1913, 0x1915, and 0x1917 also known as iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Signed-off-by:
Alexei Podtelezhnikov <apodtele@gmail.com> [vsyrjala: Split separate changes into separate patchs, Sort the IDs] Signed-off-by:
-
Alexei Podtelezhnikov authored
Reclassify 0x1923, 0x1927 according to specifications. Of note, the second to last digit seems to correspond to GT#. Signed-off-by:
-
Alexei Podtelezhnikov authored
Reclassify 0x192A according to specifications. Of note, the second to last digit seems to correspond to GT#. Signed-off-by:
-
Alexei Podtelezhnikov authored
Reclassify 0x0426 as GT3 (GT2+) according to specifications and the second least significant digit. Signed-off-by:
-
Ville Syrjälä authored
Move the DSC stuff out from the middle of the ICP HPD register definitions. The location seems to have been selected by a dice roll. SHPD_FILTER_CNT addition also went astray due to the DSC mess, so we also fix that vs. ICP_TC_HPD_{SHORT,LONG}_DETECT(). Signed-off-by:Lucas De Marchi <lucas.demarchi@intel.com>
-
Ville Syrjälä authored
Add a small wrapper for .hpd_irq_setup() which does the "do we even have the hook?" and "are display interrupts enabled?" checks. Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
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 15239099 ("drm/i915: enable irqs earlier when resuming") on account of moving the irq enable earlier. This then got removed in commit 50c3dc97 ("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 0e32b39c ("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 e8a8fedd ("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:Lyude Paul <lyude@redhat.com>
-
Ville Syrjälä authored
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ä authored
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:
-
Chris Wilson authored
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 3be0bf5a ("drm/i915: Create vGPU specific MMIO operations to reduce traps"). References: 3be0bf5a ("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 authored
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:
-
José Roberto de Souza authored
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 authored
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:
-
- 16 Oct, 2020 6 commits
-
-
Ville Syrjälä authored
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:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
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ä authored
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ä authored
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:
-
Ville Syrjälä authored
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: -
Matt Roper authored
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:
-
- 15 Oct, 2020 11 commits
-
-
Michel Thierry authored
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:
-
Anshuman Gupta authored
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:
-
Anshuman Gupta authored
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:
-
Stuart Summers authored
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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Matt Atwood authored
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 authored
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:
Aditya Swarup <aditya.swarup@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-6-lucas.demarchi@intel.com
-
Aditya Swarup authored
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 authored
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:
-
Lucas De Marchi authored
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 authored
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:
-
Aditya Swarup authored
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:
-
- 14 Oct, 2020 1 commit
-
-
Tejas Upadhyay authored
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:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201013192948.63470-1-tejaskumarx.surendrakumar.upadhyay@intel.com
-
- 12 Oct, 2020 2 commits
-
-
Aaron Ma authored
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:
-
Aaron Ma authored
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:
-
