- 20 Jun, 2023 9 commits
-
-
Lee Shawn C authored
Update preset 15 setting to align the latest bspec value. Bspec: 74104 Signed-off-by:
Lee Shawn C <shawn.c.lee@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606104238.31953-1-shawn.c.lee@intel.com
-
Ville Syrjälä authored
Make HSW/BDW use port_mask for output probing as well. To achieve that the strap checks are moved into intel_ddi_init() itself. Or should we move them to the runtime port_mask init instead? Maybe not since the hardware is still there, just not connected to anything. v2: Account for DDI-E in strap detection Keep to the old CRT->DDI init order Reviewed-by:Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230616140820.11726-8-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Instead of listing every platform's possible DDI outputs in intel_setup_outputs() just loop over the new port_mask to achieve the same thing. HSW/BDW were left as is since they still look at the straps as well. DSI is still a mess. For now just check for the relevant platforms explicitly. Reviewed-by:
-
Ville Syrjälä authored
The SDVO code already warns when the port in question doesn't actually support SDVO. Let's make that also bail the encoder registration like the generic assert_port_valid() we added. And add a similar thing for g4x HDMI, mainly because on g4x itsefl port D only supports DP but not SDVO/HDMI. For the other platforms the generic port_mask check should actually be sufficient, but since we're here might as well list the ports. Reviewed-by:
-
Ville Syrjälä authored
Sprinkle some asserts to catch any mishaps in the port_mask vs. output init. For DDI/DP/HDMI/SDVO I decided that we want to bail out for an invalid port since those are the encoder types where we might want consider driving the whole thing from the VBT child device list, and bogus VBTs could be a real issue (if for no other reason than the i915.vbt_firmware). For DVO and HSW/BDW CRT port I just threw the assert in there for good measure. Reviewed-by:
-
Ville Syrjälä authored
Sprinkle in some BUILD_BUG_ON()s to make sure some of the bitmasks used in the device info have enough bits. Do we have a better place for this sort of stuff? v2: Relocate to the new place Reviewed-by:
-
Ville Syrjälä authored
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the device info. The other outputs (LVDS/TV/DSI/VGA) are left out since for most of them we don't consider them as "ports". DSI we should probably perhaps include somehow in the device info. Just not sure how. Or we just introduce a HAS_DSI() and call it a day? TODO: figure out what to do about the subplatform stuff. Would it be better to declare those directly with a different device info or not? Also not sure the icl port-f stuff matters even. Bspec claims there are icl SKUs with far less ports than that and we don't seem to check for those either? v2: Fix TC5 vs. TC6 mixup on TGL (Jani) Drop DDI C for now on TGL, and add a FIXME (Jani) Reviewed-by:Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Ville Syrjälä authored
HSW/BDW don't have DDI-F so don't go looking for one. Seems to have been accidentally left behind when the skl+ stuff got split out in commit 097d9e90 ("drm/i915/display: remove strap checks from gen 9"). Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Imre Deak authored
A recent bspec update added a restriction on when DC states can be enabled: [Before enabling DC states:] """ PG2 can be kept enabled only because PGB requires PG2. Do not use PG2 functions, such as type-C DDIs. DMC will dynamically control PG1, PGA, PG2, PGB. """ Accordingly prevent DC states if PW2 (aka PG2) is enabled for any other functionality. Bpsec: 49193 Fixes: 88c48793 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2") Reported-by:
Kai Vehmanen <kai.vehmanen@intel.com> Tested-by:
Ambica Pramod <ambica.pramod@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606172822.1891897-1-imre.deak@intel.com
-
- 16 Jun, 2023 13 commits
-
-
Ville Syrjälä authored
All known issues fixed now, so re-enable PSR1 on hsw/bdw. Signed-off-by:
Jouni Högander <jouni.hogander@intel.com>
-
Ville Syrjälä authored
Can't see why we'd want the sprite blocking PSR entry. Mask it out. Signed-off-by:
-
Ville Syrjälä authored
WA 0479 says: "Do not skip both TP1 and TP2/TP3". Let's just stick the minimum 100us TP2/3 time in there to avoid that. Signed-off-by:
-
Ville Syrjälä authored
hsw/bdw lack the pipe register vs. display register distinction in their PSR masking capabilities. So to keep our CURSURFLIVE tricks working we need to just unmask all display register writes on these platforms. The downside being that any display regitster (eg. even SWF regs) will cause a PSR exit. Note that WaMaskMMIOWriteForPSR asks us to mask this on bdw, but that won't work since we need those CURSURFLIVE tricks. Observations on actual hardware show that this causes one extra PSR exit ~every 10 seconds, which is pretty much irrelevant. I suspect this is due to the pcode poking at IPS_CTL. Disabling IPS does not stop it however, so either I'm wrong or pcode pokes at the register regardless of whether it's actually trying to enable/disable IPS. Also when the machine is busy (eg. just running 'find /') these extra PSR exits cease, which again points at pcode or some other PM entity as being the culprit. Signed-off-by:
-
Ville Syrjälä authored
Bspec asks us to unmask "vblank to registers" in the DPRS unit. Note that I was unable to observe any change in hardware behviour due to this bit on HSW. But let's do this anyway in case it matters in some cases, and the corresponding bit on BDW is abolutely critical as without it the hardware won't generate any vblanks whatsoever after PSR exit. Signed-off-by:
-
Ville Syrjälä authored
Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware generate the extra vblank between link training and first frame being transmitted. This is the same thing that's controlled by TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering it's effectively always at the rest value after DC5 exit). So for consistent behaviour we want every platform to generate said vblank. BDW is already setting this up correctly. Signed-off-by:
-
Ville Syrjälä authored
Add the PSR interrupt handling code back for HSW. Looks like the removal was never completed anyway since the irq setup code was lest untouched. Signed-off-by:
-
Ville Syrjälä authored
Deal with HSW/BDW in transcoder_has_psr2(). Signed-off-by:
-
Ville Syrjälä authored
Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all of it was even removed (BDW AUX data registers were left behind). Update the code to use REG_BIT() & co. while at it. v2: Define the SRD_AUX_CTL bits in terms of DP_AUX_CTL bits (Jouni) Add a comment explaining the hand rolled DPCD write (Jouni) Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: -
Ville Syrjälä authored
Add back hsw'w special SRD/PSR1 registers. Signed-off-by:
-
Ville Syrjälä authored
In preparation for re-introducing HSW's different PSR1 register offeets let's just wrap all the registers into functions. Avoids having to make the register macros more complex. Signed-off-by:
-
Ville Syrjälä authored
The multiplication got replaced by an addition in some cleanup. This means we never write the correct data to some of the BDW PSR data registers and thus we fail to actually wake up the panel from PSR. Fixes: 4ab4fa10 ("drm/i915/psr: Make PSR registers relative to transcoders") Signed-off-by:
-
Ville Syrjälä authored
PC8+ clobbers a bunch of displays registers which need to be restored by hand or else we lost a bunch of workarounds. The important ones for us are at least CHICKEN_PAR2* and CHICKEN_PIPESL*. Curiously at least some CHICKEN_PAR1* registers are preserved by the hardware/firmware. Unfortunately Bspec doens't really specify what gets clobbered vs. preserved so further reverse engieering might be warranted to figure out the specifics. Note that PCH_LP_PARTITION_LEVEL_DISABLE is also set by lpt_init_clock_gating() so the rmw in hsw_disable_pc8() is now redundant. Remove it. TODO: I suspect most gt stuff doesn't need this and we should finish moving all of them from init_clock_gating() to a more appropriate place... Signed-off-by:
-
- 15 Jun, 2023 1 commit
-
-
Mika Kahola authored
From PICA message bus we wait for acknowledgment from read/write commands. In case of an error, we reset the bus for the next command. Current implementation ends up resetting message bus twice in cases where error is not the timeout. Since, we only need to reset message bus once, let's move reset to corresponding timeout error and drop the excess reset function calls from read/write functions. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
- 14 Jun, 2023 1 commit
-
-
Suraj Kandpal authored
Allocate a multipage object that can be used for input and output for intel_hdcp_gsc_message so that corruption of output message can be avoided by the current overwriting method. Modify intel_gsc_send_sync() to take into account header_out and addr_out so as to use them to verify the message send status. Check link for comment and review history https://patchwork.freedesktop.org/series/118499/ --v2 -Change approach from allocating two objects to just one multipage object [Daniele] --v3 -Squash the two patches together [Daniele] -No need to allocate twice the size of intel_hdcp_gsc_message [Daniele] Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230602105113.1791104-1-suraj.kandpal@intel.com
-
- 13 Jun, 2023 13 commits
-
-
Ville Syrjälä authored
No idea why the DSI code is feeling the need to assert that has_pch_encoder must not be set. PCH encoders aren't even a thing on any platform that has DSI. Reviewed-by:
-
Ville Syrjälä authored
The encoder hooks already get passed the crtc state so just grab the crtc from there instead of from the connector state. This is generally what everyone else does, so no reason for icl_dsi.c to be different. Reviewed-by:
-
Ville Syrjälä authored
Follow what Windows does and do the DSI panel reset+power off after everything else. v2: s/intel_dsi_msleep/msleep/ Reviewed-by:
-
Ville Syrjälä authored
icl+ DSI isn't respecting the panel power_off_delay. Remedy that. Reviewed-by:
-
Ville Syrjälä authored
Do the scaler disable in the spot where bspec has specfied it for TGL+. And also move the DSC disable to match what intel_ddi.c does. Reviewed-by:
-
Ville Syrjälä authored
encoder->disable() is supposed to happen before the pipe/transcoder gets disabled. The icl+ DSI code screwed that up and put most things (including the transcoder disable itself) into encoder->disable(). Follow the common rules and hoist most things into the encoder->post_disable() hook. Reviewed-by:
-
Ville Syrjälä authored
Plug in the encoder->shutdown() hook for icl+ DSI so that we are guaranteed to respect the power cycle delay during reboots and whatnot. Reviewed-by:
-
Ville Syrjälä authored
Handle the DSI panel power cycle delay on icl+. Reviewed-by:
-
Ville Syrjälä authored
The clock gating step is in the wrong spot compared to the TGL+ bspec sequence. Move it the right place. Windows also seems to use the TGL+ order here always. Reviewed-by:
-
Ville Syrjälä authored
The programming of the DPHY vs. DSI _TIMING registers are two separate steps in the TGL+ bspec sequence, with some other stuff in between. Implement the same split. Windows also seems follow the bspec TGL+ sequence, even on ICL/JSL. Reviewed-by:
-
Ville Syrjälä authored
Help out debugging things by printing out how long the VBT delay sequence is supposed to wait. Reviewed-by:
-
Ville Syrjälä authored
Doing the init OTP and display on DSI sequences back to back doesn't really make any sense (a single sequence would suffice then). Move the display on sequence to be done just before backlight on, which is also what Windows does. Reviewed-by:
-
Ville Syrjälä authored
Looks like we're trying to talk to the DSI panel even before turning it on, on icl+. Bspec doesn't actually specify when these should be done, but certainly we need to turn the panel on at least before talking to it. So let's move the power on + reset deassert steps to be the first thing we do. This is also what Windows does. v2: s/intel_dsi_msleep/msleep/ Reviewed-by:
-
- 12 Jun, 2023 1 commit
-
-
Arnd Bergmann authored
When CONFIG_PNP is disabled, the mchbar_addr variable is only written but not read: drivers/gpu/drm/i915/soc/intel_gmch.c: In function 'intel_alloc_mchbar_resource': drivers/gpu/drm/i915/soc/intel_gmch.c:41:13: error: variable 'mchbar_addr' set but not used [-Werror=unused-but-set-variable] 41 | u64 mchbar_addr; | ^~~~~~~~~~~ No idea why this showed up now, but it's easy to fix by changing the #ifdef to an IS_ENABLED() check that the compiler can see through. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 10 Jun, 2023 2 commits
-
-
Jani Nikula authored
Sync up with changes from drm-intel-gt-next. Signed-off-by: -
Luca Coelho authored
Instead of using a global workqueue for the SW fence selftest, allocate a separate one temporarily only while running the test. Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
