- 09 Oct, 2020 13 commits
-
-
José Roberto de Souza authored
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 authored
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:
-
José Roberto de Souza authored
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:
-
Ville Syrjälä authored
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.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
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ä authored
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: 2dfbf9d2 ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine") Signed-off-by:
-
Ville Syrjälä authored
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:Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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:Chris Wilson <chris@chris-wilson.co.uk>
-
- 07 Oct, 2020 9 commits
-
-
Matt Roper authored
As with RKL, DG1's VBT outputs are indexed according to PHY rather than DDI. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
As with RKL, DG1's PHY C acts as a comp master for PHY D. Bspec: 49291 Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-7-lucas.demarchi@intel.com
-
Matt Roper authored
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:
-
Lucas De Marchi authored
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:
-
Venkata Sandeep Dhanalakota authored
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 authored
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: -
Matt Roper authored
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:
-
Lucas De Marchi authored
Synchronize with the current list of DG1 PCI IDs. Signed-off-by:
-
José Roberto de Souza authored
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:
-
- 06 Oct, 2020 5 commits
-
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
- 05 Oct, 2020 2 commits
-
-
Matt Roper authored
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:
-
Lucas De Marchi authored
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:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001063917.3133475-1-lucas.demarchi@intel.com
-
- 02 Oct, 2020 1 commit
-
-
Ville Syrjälä authored
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: f542d671 ("drm/i915: Init lspcon after HPD in intel_dp_detect()") Signed-off-by:
-
- 01 Oct, 2020 10 commits
-
-
Kai-Heng Feng authored
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/203Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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: -
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
intel_dp_process_phy_request() has no business being externally visible. Make it static. Signed-off-by:
-
