- 03 7月, 2020 1 次提交
-
-
由 Lucas De Marchi 提交于
We have a mix of dport, intel_dport, intel_dig_port and dig_port to reference a intel_digital_port struct. Numbers are around 5 intel_dport 36 dport 479 intel_dig_port 352 dig_port Since we already removed the intel_ prefix from most of our other structs, do the same here and prefer dig_port. v2: rename everything in i915, not just a few display sources and reword commit message (from Matt Roper) Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701045054.23357-1-lucas.demarchi@intel.com
-
- 02 7月, 2020 1 次提交
-
-
由 Matt Atwood 提交于
intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to use before encoder_type is set. This caused GEN11+ to incorrectly strip HBR3 from source rates for edp. Move intel_dp_set_source_rates() to after encoder_type is set. Add comment to intel_dp_is_edp() describing unsafe usages. v2: Alter intel_dp_set_source_rates final position (Ville/Manasi). Remove outdated comment (Ville). Slight optimization of control flow in intel_dp_init_connector. Slight rewording in commit message. Signed-off-by: NMatt Atwood <matthew.s.atwood@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630233310.10191-1-matthew.s.atwood@intel.com
-
- 01 7月, 2020 11 次提交
-
-
由 Imre Deak 提交于
To simplify things, call the combo PHY/TBT PLL calculation functions directly from the corresponding combo/TypeC PLL get functions, instead of calling the same calculation functions after having to recheck if the given PHY is combo or TypeC. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629185848.20550-2-imre.deak@intel.com
-
由 Imre Deak 提交于
When the reference clock is 38.4MHz, using the current TBT PLL fractional divider value results in a slightly off TBT link frequency. This causes an endless loop of link training success followed by a bad link signaling and retraining at least on a Dell WD19TB TBT dock. The workaround provided by the HW team is to divide the fractional divider value by two. This fixed the link training problem on the ThinkPad dock. The same workaround is needed on some EHL platforms and for combo PHY PLLs, these will be addressed in a follow-up. Bspec: 49204 References: HSDES#22010772725 References: HSDES#14011861142 Reported-and-tested-by: NKhaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NKhaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629185848.20550-1-imre.deak@intel.com
-
由 Lucas De Marchi 提交于
We don't need intel_dig_port and dig_port to refer to the same thing. Prefer the latter. v2: fix coding style Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626234834.26864-2-lucas.demarchi@intel.com
-
由 José Roberto de Souza 提交于
Future patches will bring PSR2 selective fetch configuration validation but most of the configuration checks will be used for HW tracking and selective fetch so the reoder was necessary. Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626010151.221388-2-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
This property will be used by PSR2 software tracking, adding it to GEN12+. Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626010151.221388-1-jose.souza@intel.com
-
由 Ville Syrjälä 提交于
Often we seem to detect an underrun right after modeset on gen2. It seems to be a spurious detection (potentially the pipe is still in a wonky state when we enable the planes). An extra vblank wait seems to cure it. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-13-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
The default fbc1 compression interval we use is 500 frames. That translates to over 8 seconds typically. That's rather excessive so let's drop it to 1 second. The hardware will not attempt recompression unless at least one line has been modified, so a shorter compression interval should not cause extra bandwidth use in the purely idle scenario. Of course in the mostly idle case we are possibly going to recompress a bit more. Should really try to find some kind of sweet spot to minimize the energy usage... Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-11-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
Avoid the FBC_CONTROL rmw and just store the fbc compression interval in the params/ Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-10-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
Parametrize the FBC_CONTROL bits for neater code. Also add the one missing bit: "stop compression on modification". Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-9-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
The hardware host tracking won't nuke the entire cfb (unless the entire fb is written through the gtt) so don't clear the busy_bits for gtt tracking. Not that it really matters anymore since we've lost ORIGIN_GTT usage everywhere. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-7-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
The current fence_y_offset calculation is broken. I think it more or less used to do the right thing, but then I changed the plane code to put the final x/y source offsets back into the src rectangle so now it's just subtraacting the same value from itself. The code would never have worked if we allowed the framebuffer to have a non-zero offset. Let's do this in a better way by just calculating the fence_y_offset from the final plane surface offset. Note that we don't align the plane surface address to fence rows so with horizontal panning there's often a horizontal offset from the fence start to the surface address as well. We have no way to tell the hardware about that so we just ignore it. Based on some quick tests the invlidation still happens correctly. I presume due to the invalidation nuking at least the full line (or a segment of multiple lines). Fixes: 54d4d719 ("drm/i915: Overcome display engine stride limits via GTT remapping") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-4-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>
-
- 30 6月, 2020 3 次提交
-
-
由 Colin Ian King 提交于
Currently there is no null check for a failed memory allocation on the dsb object and without this a null pointer dereference error can occur. Fix this by adding a null check. Note: added a drm_err message in keeping with the error message style in the function. Addresses-Coverity: ("Dereference null return") Fixes: afeda4f3 ("drm/i915/dsb: Pre allocate and late cleanup of cmd buffer") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616114221.73971-1-colin.king@canonical.com
-
由 Oliver Barta 提交于
A single Ri mismatch doesn't automatically mean that the link integrity is broken. Update and check of Ri and Ri' are done asynchronously. In case an update happens just between the read of Ri' and the check against Ri there will be a mismatch even if the link integrity is fine otherwise. Signed-off-by: NOliver Barta <oliver.barta@aptiv.com> Reviewed-by: NSean Paul <sean@poorly.run> Reviewed-by: NRamalingam C <ramalingam.c@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504123524.7731-1-oliver.barta@aptiv.com
-
由 Ville Syrjälä 提交于
The linetime watermark is a 9 bit value, which gives us a maximum linetime of just below 64 usec. If the linetime exceeds that value we currently just discard the high bits and program the rest into the register, which angers the state checker. To avoid that let's just clamp the value to the max. I believe it should be perfectly fine to program a smaller linetime wm than strictly required, just means the hardware may fetch data sooner than strictly needed. We are further reassured by the fact that with DRRS the spec tells us to program the smaller of the two linetimes corresponding to the two refresh rates. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200625200003.12436-1-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
- 27 6月, 2020 1 次提交
-
-
由 Matt Atwood 提交于
Update code to reflect recent bspec changes Bspec: 52890 Bspec: 53508 Signed-off-by: NMatt Atwood <matthew.s.atwood@intel.com> Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200624215723.2316-1-matthew.s.atwood@intel.com
-
- 26 6月, 2020 1 次提交
-
-
由 Ville Syrjälä 提交于
The DP spec says: "The transmitter shall support at least three levels of voltage swing (Levels 0, 1, and 2). If only three levels of voltage swing are supported (VOLTAGE SWING SET field (bits 1:0) are programmed to 10 (Level 2)), this bit shall be set to 1, and cleared in all other cases. If all four levels of voltage swing are supported (VOLTAGE SWING SET field (bits 1:0) are programmed to 11 (Level 3)), this bit shall be set to 1,and cleared in all other cases." Let's follow that exactly instead of the current apporach where we can set those also for vswing/preemph levels 0 or 1 (or 2 when the platform max is 3). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-7-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
-
- 24 6月, 2020 1 次提交
-
-
由 Imre Deak 提交于
The spec requires enabling the MST Virtual Channel payload allocation - in a separate step - after the transcoder is enabled, follow this. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200623082411.3889-1-imre.deak@intel.com
-
- 23 6月, 2020 6 次提交
-
-
由 Imre Deak 提交于
During encoder enabling we clear the flag before starting the ACT sequence and wait for the flag, but the clearing is missing during encoder disabling, add it there too. Since nothing cleared the flag automatically we could've run subsequent disabling steps too early. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-5-imre.deak@intel.com
-
由 Imre Deak 提交于
It's not clear if the DP_TP_STATUS flags other than the ACT sent flag have some side-effect, so don't clear those; we don't depend on the state of these flags anyway. Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-4-imre.deak@intel.com
-
由 Imre Deak 提交于
During transcoder enabling we'll configure the transcoder in MST mode and enable the VC payload allocation, which will start the ACT sequence. Before waiting for the ACT sequence completion, we need to clear the ACT sent flag, but based on the above we can do this right before enabling the transcoder. For clarity, move the flag clearing closer to where we wait for it. While at it also factor out some common code. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-3-imre.deak@intel.com
-
由 Imre Deak 提交于
During the initial probing of an MST sink, MST core will determine the sink's link bandwidth based on its own version of the sink link rate/lane count caps it reads from the DPCD. At a later point (after probing and 1 or more modesets) i915 may limit the link parameters wrt. the original source/sink common caps above due to link training failures during a modeset and the resulting link training fallback logic. Based on the above a modeset following another modeset with a link training error will compute the i915 HW specific and DP protocol timing parameters (data/link M/N and MST TU values) taking into account only the unlimited source/sink common caps, but not taking into account the fallback limits. This will also let DRM core oversubscribe the actual link bandwidth during the MST payload allocation. Prevent the above problem by disabling the link training fallback on MST links for now, until the MST probe time initialization and the MST compute config logic can deal with changing link parameters. The misconfigured timings lead at least to a 'Timed out waiting for DP idle patterns' error. v2: (Ville) - Print link training error message on the MST path too. - Clarify the problem in the commit log. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616211146.23027-2-imre.deak@intel.com
-
由 Imre Deak 提交于
MST encoders must use the master MST transcoder's DP_TP_STATUS and DP_TP_CONTROL registers. Atm, during the HW readout of an MST encoder connected to a slave transcoder we reset these register addresses in intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register addresses incorrectly; fix this. One example where the above overwite happens is the encoder HW state validation after enabling multiple streams; see intel_dp_mst_enc_get_config(). After that during disabling any stream we'll get a 'Timed out waiting for ACT sent when disabling' error, due to reading from the incorrect DP_TP_STATUS register. This change replaces https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1 which just papered over the problem. v2: - Correct the failure scenario in the commit log. (José) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616211146.23027-1-imre.deak@intel.com
-
由 Jani Nikula 提交于
Start using device specific parameters instead of module parameters for most things. The module parameters become the immutable initial values for i915 parameters. The device specific parameters in i915->params start life as a copy of i915_modparams. Any later changes are only reflected in the debugfs. The stragglers are: * i915.force_probe and i915.modeset. Needed before dev_priv is available. This is fine because the parameters are read-only and never modified. * i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and I915_STATE_WARN_ON would result in massive and ugly churn. This is handled by not exposing the parameter via debugfs, and leaving the parameter writable in sysfs. This may be fixed up in follow-up work. * i915.inject_probe_failure. Only makes sense in terms of the module, not the device. This is handled by not exposing the parameter via debugfs. v2: Fix uc i915 lookup code (Michał Winiarski) Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: NMichał Winiarski <michal.winiarski@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com
-
- 16 6月, 2020 3 次提交
-
-
由 Vandita Kulkarni 提交于
For all ddi, encoder->type holds output type as ddi, assigning it to individual o/p types is no more valid. Fixes: 362bfb99 ("drm/i915/tgl: Add DKL PHY vswing table for HDMI") v2: Rebase, no functional change. Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Signed-off-by: NUma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612082237.11886-1-vandita.kulkarni@intel.com (cherry picked from commit 94641eb6) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
由 Imre Deak 提交于
According to BSpec the Data Island Packet should be disabled after disabling the transcoder, but before the transcoder clock select is set to none. On an ICL RVP, daisy-chained MST config not following this leads to a hang with the following MCE when disabling the output: [ 870.948739] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: ba00000011000402 [ 871.019212] mce: [Hardware Error]: RIP !INEXACT! 10:<ffffffff81aca652> {poll_idle+0x92/0xb0} [ 871.019212] mce: [Hardware Error]: TSC 135a261fe61 [ 871.019212] mce: [Hardware Error]: PROCESSOR 0:706e5 TIME 1591739604 SOCKET 0 APIC 0 microcode 20 [ 871.019212] mce: [Hardware Error]: Run the above through 'mcelog --ascii' [ 871.019212] mce: [Hardware Error]: Machine check: Processor context corrupt [ 871.019212] Kernel panic - not syncing: Fatal machine check [ 871.019212] Kernel Offset: disabled Bspec: 4287 Fixes: fa37a213 ("drm/i915: Stop sending DP SDPs on ddi disable") Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200609220616.6015-1-imre.deak@intel.com (cherry picked from commit c980216d) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
由 Khaled Almahallawy 提交于
Setting ln0 similar to ln1 Fixes: 3b51be4e ("drm/i915/tc: Update DP_MODE programming") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: NKhaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200608204537.28468-1-khaled.almahallawy@intel.com (cherry picked from commit 4f72a8ee) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 12 6月, 2020 1 次提交
-
-
由 Vandita Kulkarni 提交于
For all ddi, encoder->type holds output type as ddi, assigning it to individual o/p types is no more valid. Fixes: 362bfb99 ("drm/i915/tgl: Add DKL PHY vswing table for HDMI") v2: Rebase, no functional change. Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Signed-off-by: NUma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612082237.11886-1-vandita.kulkarni@intel.com
-
- 11 6月, 2020 4 次提交
-
-
由 Imre Deak 提交于
Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter, incorrectly filter out HPD short pulses with a duration less than ~540 usec, leading to MST probe failures. According to the DP Standard 2.0 section 5.1.4: - DP sinks should generate short pulses in the 500 usec -> 1 msec range - DP sources should detect short pulses in the 250 usec -> 2 msec range According to the DP Alt Mode on TypeC Standard section 3.9.2, adapters should detect and forward short pulses according to how sources should detect them as specified in the DP Standard (250 usec -> 2 msec). Based on the above filtering out short pulses with a duration less than 540 usec is incorrect. To make such adapters work add support for a driver polling on MST inerrupt flags, and wire this up in the i915 driver. The sink can clear an interrupt it raised after 110 msec if the source doesn't respond, so use a 50 msec poll period to avoid missing an interrupt. Polling of the MST interrupt flags is explicitly allowed by the DP Standard. This fixes MST probe failures I saw using this adapter and a DELL U2515H monitor. v2: - Fix the wait event timeout for the no-poll case. v3 (Ville): - Fix the short pulse duration limits in the commit log prescribed by the DP Standard. - Add code comment explaining why/how polling is used. - Factor out a helper to schedule the port's hpd irq handler and move it to the rest of hotplug handlers. - Document the new MST callback. - s/update_hpd_irq_state/poll_hpd_irq/ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200604184500.23730-2-imre.deak@intel.com
-
由 Imre Deak 提交于
Currently MST on a port can get enabled/disabled from the hotplug work and get disabled from the short pulse work in a racy way. Fix this by relying on the MST state checking in the hotplug work and just schedule a hotplug work from the short pulse handler if some problem happened during the MST interrupt handling. This removes the explicit MST disabling in case of an AUX failure, but if AUX fails, then probably the detection will also fail during the scheduled hotplug work and it's not guaranteed that we'll see intermittent errors anyway. While at it also simplify the error checking of the MST interrupt handler. v2: - Convert intel_dp_check_mst_status() to return bool. (Ville) - Change the intel_dp->is_mst check to an assert, since after this patch the condition can't change after we checked it previously. - Document the return value from intel_dp_check_mst_status(). v3: - Remove the intel_dp->is_mst check from intel_dp_check_mst_status(). There is no point in checking the same condition twice, even though there is a chance that the hotplug work running concurrently changes it. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605094801.17709-1-imre.deak@intel.com
-
由 Imre Deak 提交于
DSC is not supported on DP MST streams so just don't add this entry for MST connectors. This also fixes an OOPS, caused by the encoder->digport cast, which is not valid for MST encoders. v2: - Check encoder, which is unset for an MST connector, before it gets enabled. v3: - Just don't add this debugfs file for MST connectors. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200609184140.4937-1-imre.deak@intel.com
-
由 Imre Deak 提交于
According to BSpec the Data Island Packet should be disabled after disabling the transcoder, but before the transcoder clock select is set to none. On an ICL RVP, daisy-chained MST config not following this leads to a hang with the following MCE when disabling the output: [ 870.948739] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: ba00000011000402 [ 871.019212] mce: [Hardware Error]: RIP !INEXACT! 10:<ffffffff81aca652> {poll_idle+0x92/0xb0} [ 871.019212] mce: [Hardware Error]: TSC 135a261fe61 [ 871.019212] mce: [Hardware Error]: PROCESSOR 0:706e5 TIME 1591739604 SOCKET 0 APIC 0 microcode 20 [ 871.019212] mce: [Hardware Error]: Run the above through 'mcelog --ascii' [ 871.019212] mce: [Hardware Error]: Machine check: Processor context corrupt [ 871.019212] Kernel panic - not syncing: Fatal machine check [ 871.019212] Kernel Offset: disabled Bspec: 4287 Fixes: fa37a213 ("drm/i915: Stop sending DP SDPs on ddi disable") Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200609220616.6015-1-imre.deak@intel.com
-
- 10 6月, 2020 4 次提交
-
-
由 Khaled Almahallawy 提交于
Setting ln0 similar to ln1 Fixes: 3b51be4e ("drm/i915/tc: Update DP_MODE programming") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: NKhaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200608204537.28468-1-khaled.almahallawy@intel.com
-
由 Aditya Swarup 提交于
RKL doesn't have DSI outputs, so we shouldn't try to read out the DSI transcoder registers. v2(MattR): - Just set the 'extra panel mask' to edp | dsi0 | dsi1 and then mask against the platform's cpu_transcoder_mask to filter out the ones that don't exist on a given platform. (Ville) v3(MattR): - Only include DSI transcoders on gen11+ again. (Ville) - Use for_each_cpu_transcoder_masked() for loop. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NAditya Swarup <aditya.swarup@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200606025740.3308880-5-matthew.d.roper@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
-
由 Matt Roper 提交于
HPD pin handling for RKL+TGP is a special case; we effectively select the HPD pin based on the DDI (A,B,D,E) rather than the PHY (A,B,C,D). This differs from the regular behavior of RKL+CMP (and also TGL+TGP). v2: - Rather than providing a custom hpd_pin mapping table, just assign encoder->hpd_pin in a custom manner for this setup. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200606025740.3308880-4-matthew.d.roper@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
-
由 Matt Roper 提交于
Rocket Lake uses the same 'abox0' mechanism to handle pixel data transfers from memory that gen11 platforms used, rather than the abox1/abox2 interfaces used by TGL/DG1. For the most part this is a hardware implementation detail that's transparent to driver software, but we do have to program a couple of tuning registers (MBUS_ABOX_CTL and BW_BUDDY registers) according to which ABOX instances are used by a platform. Let's track the platform's ABOX usage in the device info structure and use that to determine which instances of these registers to program. As an exception to this rule is that even though TGL/DG1 use ABOX1+ABOX2 for data transfers, we're still directed to program the ABOX_CTL register for ABOX0; so we'll handle that as a special case. v2: - Store the mask of platform-specific abox registers in the device info structure. - Add a TLB_REQ_TIMER() helper macro. (Aditya) v3: - Squash ABOX and BW_BUDDY patches together and use a single mask for both of them, plus a special-case for programming the ABOX0 instance on all gen12. (Ville) Bspec: 50096 Bspec: 49218 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200606025740.3308880-2-matthew.d.roper@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
-
- 09 6月, 2020 1 次提交
-
-
由 Chris Wilson 提交于
Avoid a NULL dereference for a mismatched encoder type, hit when probing state for all encoders. This is a band aid to prevent the OOPS as the right fix is "probably to swap the psr vs infoframes.enable checks, or outright disappear from this function" (Ville). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1892Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200525124912.16019-1-chris@chris-wilson.co.uk (cherry picked from commit 22da5d84) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 08 6月, 2020 2 次提交
-
-
由 Stanislav Lisovskiy 提交于
This reverts commit 82ea174d. Unfortunately according to our recent findings there is still some unidentified factor, requiring CDCLK to be set higher - otherwise we still get underruns on some multipipe configurations, despite CDCLK being set according to BSpec formula. So getting again back into debug mode to indentify the cause, meanwhile setting CDCLK=Pixel rate back in order to remove regression in 10% of the cases due to FIFO underruns. Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: cd191546 ("drm/i915: Adjust CDCLK accordingly to our DBuf bw needs") Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200608065552.21728-1-stanislav.lisovskiy@intel.com
-
由 Gwan-gyeong Mun 提交于
The IO buffer Wake and Fast Wake bit size and value have been changed from Gen12+. It programs the default value of IO buffer Wake and Fast Wake on Gen12+. It adds definitions of IO buffer Wake and Fast Wake for pre Gen12 and Gen12+. And it aligns PSR2 definition macros. v2: Fix macro definitions. (José) v3: Addressed review comments from José - Add missing default values of IO_BUFFER_WAKE and FAST_WAKE for GEN9+ - Change a style of macro naming in order to use lines as input. - Update Todo comments. v4: Add parentheses to macros to avoid precedence issues. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200607143614.185246-1-gwan-gyeong.mun@intel.com
-