- 01 7月, 2020 1 次提交
-
-
由 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
-
- 06 6月, 2020 1 次提交
-
-
由 Matt Roper 提交于
We accidentally dropped matching for DVO_PORT_DPE from the VBT mapping table when we refactored the function. Restore it. Fixes: 4628142a ("drm/i915/rkl: provide port/phy mapping for vbt") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200606031803.3309624-1-matthew.d.roper@intel.com
-
- 05 6月, 2020 8 次提交
-
-
由 José Roberto de Souza 提交于
This parameter is meant to be used when PSR issues are found as some issues in the past was due wrong values set in VBT so this would be a quick and easy way to ask users or for us to check if the issue is due VBT values. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200520212756.354623-1-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
RKL doesn't have PSR2 HW tracking, it was replaced by software/manual tracking. The driver is required to track the areas that needs update and program hardware to send selective updates. So until the software tracking is implemented, PSR2 needs to be disabled for platforms without PSR2 HW tracking. BSpec: 50422 BSpec: 50424 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-15-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
RKL uses DDI's A, B, TC1, and TC2 which need to map to combo PHY's A-D. Bspec: 49181 Cc: Imre Deak <imre.deak@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-6-matthew.d.roper@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
-
由 José Roberto de Souza 提交于
As latest update we have now 2 voltage swing tables for DP over DKL PHY with only one difference in Level 0 pre-emphasis 3. So with 2 tables for DP is time to have one single function to return all DKL voltage swing tables. BSpec: 49292 Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Tested-by: NKhaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Khaled Almahallawy<khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200602205424.138143-1-jose.souza@intel.com
-
由 Stanislav Lisovskiy 提交于
Previous patch didn't take into account all pipes but only those in state, which could cause wrong CDCLK conclcusions and calculations. Also there was a severe issue with min_cdclk being assigned to 0 every compare cycle. Too bad this was found by me only after merge. This could be also causing the issues in test, however not clear - anyway marking this as fixing the "Adjust CDCLK accordingly to our DBuf bw needs". v2: - s/pipe/crtc->pipe/ - save a bit of instructions by skipping inactive pipes, without getting 0 DBuf slice mask for it. Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: cd191546 ("drm/i915: Adjust CDCLK accordingly to our DBuf bw needs") Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NManasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200601173058.5084-1-stanislav.lisovskiy@intel.com
-
由 Matt Roper 提交于
Certain combo PHYs act as a compensation master to other PHYs and need to be initialized with a special irefgen bit in the PORT_COMP_DW8 register. Previously PHY A was the only compensation master (for PHYs B & C), but RKL adds a fourth PHY which is slaved to PHY C instead. Bspec: 49291 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-12-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
The pin mapping for the final two outputs varies according to which PCH is present on the platform: with TGP the pins are remapped into the TC range, whereas with CMP they stay in the traditional combo output range. Bspec: 49181 Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-9-matthew.d.roper@intel.com
-
由 Lucas De Marchi 提交于
RKL uses the DDI A, DDI B, DDI USBC1, DDI USBC2 from the DE point of view, so all DDI/pipe/transcoder register use these indexes to refer to them. Combo phy and IO functions follow another namespace that we keep as "enum phy". The VBT in theory would use the DE point of view, but that does not happen in practice. Provide a table to convert the child devices to the "correct" port numbering we use. Now this is the output we get while reading the VBT: DDIA: [drm:intel_bios_port_aux_ch [i915]] using AUX A for port A (VBT) [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:275:DDI A] [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:275:DDI A] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x1 for port A (VBT) DDIB: [drm:intel_bios_port_aux_ch [i915]] using AUX B for port B (platform default) [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:291:DDI B] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x2 for port B (VBT) DDI USBC1: [drm:intel_bios_port_aux_ch [i915]] using AUX D for port D (VBT) [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:295:DDI D] [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:295:DDI D] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x3 for port D (VBT) DDI USBC2: [drm:intel_bios_port_aux_ch [i915]] using AUX E for port E (VBT) [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:306:DDI E] [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:306:DDI E] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x9 for port E (VBT) Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-7-matthew.d.roper@intel.com
-
- 03 6月, 2020 3 次提交
-
-
由 Ville Syrjälä 提交于
Use max() instead of hand rolling it. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-8-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>
-
由 Ville Syrjälä 提交于
The DP spec says: "When the combination of the requested pre-emphasis level and voltage swing exceeds the capability of a DPTX, the DPTX shall set the pre-emphasis level according to the request and use the highest voltage swing it can output with the given pre-emphasis level." and "When a DPTX reads a request beyond the limits of this Standard, the DPTX shall set the pre-emphasis level according to the request and set the highest voltage swing level it can output with the given pre-emphasis level. If a DPTX is requested for 9.5dB of pre-emphasis level (may be supported for a DPTX) and cannot support that level, it shall set the pre-emphasis level to the next highest level, 6dB." Ie. we should first validate the pre-emphasis, and then select the appropriate vswing for it. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-6-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>
-
由 Ville Syrjälä 提交于
Different platforms have different max vswing/preemph settings. Turn that into a pair vfuncs so we can decouple intel_dp.c and intel_ddi.c further. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-5-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>
-