- 06 Oct, 2020 3 commits
-
-
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:
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 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:
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 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:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 01 Oct, 2020 13 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:
-
Ville Syrjälä authored
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ä authored
I managed to fumble some functions names. Fix them. Signed-off-by:
-
Ville Syrjälä authored
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: 94641eb6 ("drm/i915/display: Fix the encoder type check") Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com>
-
- 30 Sep, 2020 2 commits
-
-
Ville Syrjälä authored
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ä authored
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:
-
- 28 Sep, 2020 19 commits
-
-
Vandita Kulkarni authored
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:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-6-vandita.kulkarni@intel.com
-
Vandita Kulkarni authored
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: -
Vandita Kulkarni authored
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:
-
Vandita Kulkarni authored
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:
-
Vandita Kulkarni authored
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:
-
Ville Syrjälä authored
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ä authored
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:
-
Ville Syrjälä authored
CGM_PIPE_GAMMA_RED_MASK & co. are misplaced. Move then below the relevant register. And while at it add the degamma counterparts. Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
glk_read_lut_10() works just fine for all bdw+ platforms, so rename it. Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
Move the MST master transcoder dump next to the other transcoder bits. Reviewed-by:
-
Ville Syrjälä authored
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: -
Ville Syrjälä authored
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ä authored
intel_{enable,disable}_sagv() are no longer needed outside the compilation unit. Make them static. Signed-off-by: -
Karthik B S authored
Enable asynchronous flips in i915 for gen9+ platforms. v2: -Async flip enablement should be a stand alone patch (Paulo) v3: -Move the patch to the end of the series (Paulo) v4: -Rebased. v5: -Rebased. v6: -Rebased. v7: -Rebased. v8: -Rebased. v9: -Rebased. v10: -Rebased. Signed-off-by:
Karthik B S <karthik.b.s@intel.com> Signed-off-by:
-
Karthik B S authored
Add the details of the implementation of asynchronous flips for i915. v7: -Rebased. v8: -Rebased. v9: -Rebased. v10: Move all documentation changes to this patch. (Ville) Signed-off-by:
-
Karthik B S authored
In Gen 9 and Gen 10 platforms, async address update enable bit is double buffered. Due to this, during the transition from async flip to sync flip we have to wait until this bit is updated before continuing with the normal commit for sync flip. v9: -Rename skl_toggle_async_sync() to skl_disable_async_flip_wa(). (Ville) -Place the declarations appropriately as per need. (Ville) -Take the lock before the reg read. (Ville) -Fix comment and formatting. (Ville) -Use IS_GEN_RANGE() for gen check. (Ville) -Move skl_disable_async_flip_wa() to intel_pre_plane_update(). (Ville) v10: -Rebased. Signed-off-by:
-
