- 22 Aug, 2017 6 commits
-
-
Ville Syrjälä authored
The PSR enable/disable need to know things about the crtc state, so plumb it through. This will become even more important when we start to reuse the generic infoframe code for the VSC DIP programming as the infoframe code wants the crtc state as well. v2: Fix kernel docs Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-7-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
DP ports may want to use the video DIP for SDP transmission, so let's initialize the vfuncs for DP encoders as well. The only exception is port A eDP prior to HSW as that one doesn't have a video DIP instance. Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-6-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
DP ports will also want to utilize the video DIP for SDP transmission. So let's move the vfuncs into the dig_port. v2: Rebase due to DDI changes Signed-off-by:
-
Ville Syrjälä authored
Disabling the video DIP when shutting the port down seems like a good idea. Bspec says: "When disabling both the DIP port and DIP transmission, first disable the port and then disable DIP." and "Restriction : GCP is only supported with HDMI when the bits per color is not equal to 8. GCP must be enabled prior to enabling TRANS_DDI_FUNC_CTL for HDMI with bits per color not equal to 8 and disabled after disabling TRANS_DDI_FUNC_CTL" So let's do it in the .post_disable() hook. v2: Remove double "dpms off" caused by rebase fail Signed-off-by:
-
Ville Syrjälä authored
has_infoframe is what tells us whether infoframes should be enabled, so let's pass that instead of has_hdmi_sink to .set_infoframes(). Reviewed-by:
-
Michel Thierry authored
The corruption in CSB mmio reads we were seeing has been tracked down to incorrectly touching forcewake of all domains, following an engine reset. It is still a mistery why we only catched this in Broxton, since it could happen in any platform. With that fix already merged, commit 4055dc75 ("drm/i915: Stop touching forcewake following a gen6+ engine reset"), lets try to enable per-engine resets in Broxton one more time. This reverts commit f188258bde0f ("drm/i915: Disable per-engine reset for Broxton"). Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818172342.7282-1-michel.thierry@intel.comTested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 21 Aug, 2017 2 commits
-
-
Jani Nikula authored
Expose across driver for future work. No functional changes. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818093020.19160-2-jani.nikula@intel.com
-
Jani Nikula authored
Emphasize that this is based on the port, not intel_dp. This is also in line with the underlying intel_bios_is_port_edp() function. No functional changes. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
-
- 18 Aug, 2017 16 commits
-
-
Rodrigo Vivi authored
This bit enables hardware that will change the approximation used for distances calculations for AA wide lines so that they are rendered more accurately. The default value for this bit leaves the legacy behavior. There is no good reason to not enable the new approximation except if comparing to previous GEN rendered images. v2: Rebase v3: Fix author. Rebased by Rodrigo who also added a comment as suggested by Oscar. Since it is surrounded by Workarounds let's just add a comment to make clear it is not an Wa. Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170815231651.975-4-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
WA forTDS handle reallocation getting dropped by SDE, which may result in PS attribute corruption. Disable enhanced SBE vertex caching in COMMON_SLICE_CHICKEN2 offset. v2: Make it until B0 as spec tells. (by Mika). Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
WA to disable replay buffer destination buffer arbitration optimization. Same Wa on previous platforms has a different name: WaToEnableHwFixForPushConstHWBug Signed-off-by:
-
Rodrigo Vivi authored
Let's inherit workarounds from previous platforms that according to wa_database and BSpec are still valid for Cannonlake. v2: Add missed workarounds. v3: Rebase v4: Remove bad chunk that was added to rc6 disable. (Ander) Also remove A0 W/a that are not needed anymore. v5: Rebase on top of CFL. v6: Remove empty gen9_init_perctx_bb and gen9_init_indirectctx_bb since they don't carry any gen10 related W/a. (by Oscar). Also Remove A0 exclusive workaround. v7: Remove more A0 exclusive workarounds. As pointed out by Oscar many workarounds were changed to be A0 only so let's remove them. Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: -
Chris Wilson authored
During a global reset, we disable the irq. As we disable the irq, the hardware may be raising a GT interrupt that we then ignore, leaving it pending in the GTIIR. After the reset, we then re-enable the irq, triggering the pending interrupt. However, that interrupt was for the stale state from before the reset, and the contents of the CSB buffer are now invalid. v2: Add a comment to make it clear that the double clear is purely my paranoia. Reported-by:
"Dong, Chuanxiao" <chuanxiao.dong@intel.com> Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
Andy Shevchenko authored
The commit 213e08ad ("drm/i915/bxt: add bxt dsi gpio element support") enables GPIO support for Broxton based platforms. While using that API we might get into troubles in the future, because we can't rely on label name in the driver since vendor firmware might provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in which case the request will fail). To avoid inconsistency and potential issues we have two options: a) generate GPIO ACPI mapping table and supply it via acpi_dev_add_driver_gpios(), or b) just pass NULL as connection ID. The b) approach is much simpler and would work since the driver relies on GPIO indices only. Moreover, the _CRS fallback mechanism, when requesting GPIO, has been made stricter, and supplying non-NULL connection ID when neither _DSD, nor GPIO ACPI mapping is present, is making request fail. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921 Fixes: f10e4bf6 ("gpio: acpi: Even more tighten up ACPI GPIO lookups") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Tested-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
In a synchronous setup, we may retire the last request before we complete allocating the next request. As the last request is retired, we queue a timer to mark the device as idle, and promptly have to execute ad cancel that timer once we complete allocating the request and need to keep the device awake. If we rearrange the mark_busy() to occur before we retire the previous request, we can skip this ping-pong. v2: Joonas pointed out that unreserve_seqno() was now doing more than doing seqno handling and should be renamed to reflect its wider purpose. That also highlighted the new asymmetry with reserve_seqno(), so fixup that and rename both to [un]reserve_engine(). Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
The word out was dropped from the sentence across the line break, put it back. Signed-off-by:
-
Chris Wilson authored
This was the competing idea long ago, but it was only with the rewrite of the idr as an radixtree and using the radixtree directly ourselves, along with the realisation that we can store the vma directly in the radixtree and only need a list for the reverse mapping, that made the patch performant enough to displace using a hashtable. Though the vma ht is fast and doesn't require any extra allocation (as we can embed the node inside the vma), it does require a thread for resizing and serialization and will have the occasional slow lookup. That is hairy enough to investigate alternatives and favour them if equivalent in peak performance. One advantage of allocating an indirection entry is that we can support a single shared bo between many clients, something that was done on a first-come first-serve basis for shared GGTT vma previously. To offset the extra allocations, we create yet another kmem_cache for them. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since the introduction of being able to perform a lockless lookup of an object (i915_gem_object_get_rcu() in fbbd37b3 ("drm/i915: Move object release to a freelist + worker") we no longer need to split the object/vma lookup into 3 phases and so combine them into a much simpler single loop. Signed-off-by:
-
Chris Wilson authored
When userspace is doing most of the work, avoiding relocs (using NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we still spend a lot of time processing the arrays in execbuf, even though we now should have nothing to do most of the time. One issue that becomes readily apparent in profiling anv is that iterating over the large execobj[] is unfriendly to the loop prefetchers of the CPU and it much prefers iterating over a pair of arrays rather than one big array. v2: Clear vma[] on construction to handle errors during vma lookup Signed-off-by:
-
Chris Wilson authored
Since we keep the context around across the slow lookup where we may drop the struct_mutex, we should double check that the context is still valid upon reacquisition. Signed-off-by:
-
Chris Wilson authored
MI_STORE_DWORD_IMM just doesn't work on the video decode engine under Sandybridge, so refrain from using it. Then switch the selftests over to using the now common test prior to using MI_STORE_DWORD_IMM. Fixes: 7dd4f672 ("drm/i915: Async GPU relocation processing") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Forcewake is not affected by the engine reset on gen6+. Indeed the reason why we added intel_uncore_forcewake_reset() to gen6_reset_engines() was to keep the bookkeeping intact because the reset did not touch the forcewake bit (yet we cancelled the forcewake consumers)! This was done in commit 521198a2: Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. That futzing of the forcewake bookkeeping was dropped in commit 0294ae7b ("drm/i915: Consolidate forcewake resetting to a single function"), but it did not make the realisation that the remaining intel_uncore_forcewake_reset() was redundant. The new danger with using intel_uncore_forcewake_reset() with per-engine resets is that the driver and hw are still in an active state as we perform the reset. We may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. Reported-by:
-
Daniel Vetter authored
For a bunch of reasons[1] I've decided to step down as maintainer and let some other folks enjoy the reputation and hang out in the spotlight. Jani is going to stick around with his expertise in kms and having done the fixes flow for a long time now. Joonas will join and bring in his knowledge on all things GEM. Rodrigo has been less visible because he's been doing tons of work taking care of the internal branch, and it'd be good to have more continuity between these two worlds also on the maintainer side. 1: They all boil down to: This is going to happen sooner or later anyway, we have a great team, with the process improvements over the last few years things work rather well, now is as good as any time to do this. With that change I'll have more time for other aspects of the stack development than maintainership. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dave Airlie <airlied@gmail.com> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170815160101.1683-1-daniel.vetter@ffwll.ch
-
- 17 Aug, 2017 2 commits
-
-
Anusha Srivatsa authored
Cleanup the code. Map the pins in accordance to individual platforms rather than according to ports. Create separate functions for platforms. v2: - Add missing condition for CoffeeLake. Make platform specific functions static. Add function i915_ddc_pin_mapping(). v3: - Rename functions to x_port_to_ddc_pin() which directly indicates the purpose. Correct default return values on CNP and BXT. Rename i915_port_to_ to g4x_port_to since that was the first platform to run this. Correct code style. (Paulo) Sugested-by Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Jani Nikula authored
Sometimes it would be most enlightening to debug systems by replacing the VBT to be used. For example, in the referenced bug the BIOS provides different VBT depending on the boot mode (UEFI vs. legacy). It would be interesting to try the failing boot mode with the VBT from the working boot, and see if that makes a difference. Add a module parameter to load the VBT using the firmware loader, not unlike the EDID firmware mechanism. As a starting point for experimenting, one can pick up the BIOS provided VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt. v2: clarify firmware load return value check (Bob) v3: kfree the loaded firmware blob References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83Reviewed-by:
Bob Paauwe <bob.j.paauwe@intel.com> Acked-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 16 Aug, 2017 4 commits
-
-
Rodrigo Vivi authored
Otherwise it reuses the ilk that has a completely different wm. Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170809205248.11917-6-rodrigo.vivi@intel.com
-
Paulo Zanoni authored
They're slightly different than the gen 9 calculations. v2: Remove TODO comment. Code matches recent spec. v3: Rebase on top of latest skl code using new fp16.16 and fixing a logic issue. Auto rebase bot has apparently made some bad decisions that changed the logic of the code. (Noticed by Manesh, updated by Rodrigo). Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:Mahesh Kumar <mahesh1.kumar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170811233825.32083-1-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
When LSPCON support was extended to CNL one part was missed on lspcon_init. So, instead of adding check per platform on lspcon_init let's use HAS_LSPCON that is already there for that purpose. Fixes: ff15947e ("drm/i915/cnl: LSPCON support is gen9+") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Jani Nikula authored
Ever since we've parsed VBT child devices, starting from 6acab15a ("drm/i915: use the HDMI DDI buffer translations from VBT"), we've ignored the child device information if more than one child device references the same port. The rationale for this seems lost in time. Since commit 311a2094 ("drm/i915: don't init DP or HDMI when not supported by DDI port") we started using this information more to skip HDMI/DP init if the port wasn't there per VBT child devices. However, at the same time it added port defaults without further explanation. Thus, if the child device info was skipped due to multiple child devices referencing the same port, the device info would be retrieved from the somewhat arbitrary defaults. Finally, when commit bb1d1329 ("drm/i915/vbt: split out defaults that are set when there is no VBT") stopped initializing the defaults whenever VBT is present, thus trusting the VBT more, we stopped initializing ports which were referenced by more than one child device. Apparently at least Asus UX305UA, UX305U, and UX306U laptops have VBT child device blocks which cause this behaviour. Arguably they were shipped with a broken VBT. Relax the rules for multiple references to the same port, and use the first child device info to reference a port. Retain the logic to debug log about this, though. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101745 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196233 Fixes: bb1d1329 ("drm/i915/vbt: split out defaults that are set when there is no VBT") Tested-by:
Oliver Weißbarth <mail@oweissbarth.de> Reported-by:
Didier G <didierg-divers@orange.fr> Reported-by:
Giles Anderson <agander@gmail.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: <stable@vger.kernel.org> # v4.12+ Reviewed-by:
-
- 15 Aug, 2017 10 commits
-
-
Rodrigo Vivi authored
Different from previous platforms, on CNL+ there's separated registers for separated indexes. v2: Remove comments regarding uncertainty around the table. v3: Remove extra line (by Ben) Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Jim Bride authored
Some fixed resolution panels actually support more than one mode, with the only thing different being the refresh rate. Having this alternate mode available to us is desirable, because it allows us to test PSR on panels whose setup time at the preferred mode is too long. With this patch we allow the use of the alternate mode if it's available and it was specifically requested. v2 and v3: Rebase v4: * Fix up some leaky mode stuff (Chris) * Rebase v5: * Fix a NULL pointer derefrence (David Weinehall) v6: * Whitespace / spelling / checkpatch clean-up; no functional change. (David) * Rebase Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
Jason Ekstrand authored
This commit adds support for waiting on or signaling DRM syncobjs as part of execbuf. It does so by hijacking the currently unused cliprects pointer to instead point to an array of i915_gem_exec_fence structs which containe a DRM syncobj and a flags parameter which specifies whether to wait on it or to signal it. This implementation theoretically allows for both flags to be set in which case it waits on the dma_fence that was in the syncobj and then immediately replaces it with the dma_fence from the current execbuf. v2: - Rebase on new syncobj API v3: - Pull everything out into helpers - Do all allocation in gem_execbuffer2 - Pack the flags in the bottom 2 bits of the drm_syncobj* v4: - Prevent a potential race on syncobj->fence Testcase: igt/gem_exec_fence/syncobj* Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/1499289202-25441-1-git-send-email-jason.ekstrand@intel.comReviewed-by:
-
Chris Wilson authored
The wait-ioctl is optionally supplied a timeout with nanosecond precision in a s64 field. We use nsecs_to_jiffies64() to convert that into the jiffies consumed by the scheduler, but internally nsecs_to_jiffies64() does not guard against overflow (as it's purpose is for use by the scheduler and not drivers!). So we must guard against the overflow ourselves, and in the process note that we may then return much earlier than the timeout selected by the user, so don't report ETIME unless we do hit the timeout. (Woe betold us though if the user waits for a year (32bit) and the request is still not complete!) v2: Refine overflow detection (to not include an overffow itself) Reported-by:
Jason Ekstrand <jason.ekstrand@intel.com> Signed-off-by:
-
Chris Wilson authored
Another month, another story in the cache coherency saga. This time, we come to the realisation that i915_gem_object_is_coherent() has been reporting whether we can read from the target without requiring a cache invalidate; but we were using it in places for testing whether we could write into the object without requiring a cache flush. So split the tracking into two, one to decide before reads, one after writes. See commit e27ab73d ("drm/i915: Mark CPU cache as dirty on every transition for CPU writes") for the previous entry in this saga. v2: Be verbose v3: Remove unused function (i915_gem_object_is_coherent) v4: Fix inverted coherency check prior to execbuf (from v2) v5: Add comment for nasty code where we are optimising on gcc's behalf. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101109 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101555 Testcase: igt/kms_mmap_write_crc Testcase: igt/kms_pwrite_crc Signed-off-by:
-
Imre Deak authored
Future platforms increase the number of power wells which require additional control registers. A convenient way to select the correct register is to use the high bits of the power well ID as index. This patch only prepares for this, while upcoming platform enabling patches will add the actual new power well IDs and corresponding power well control registers. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Animesh Manna <animesh.manna@intel.com> Reviewed-by:
Rakshmi Bhatia <rakshmi.bhatia@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-2-imre.deak@intel.com
-
Imre Deak authored
GCC 4.4 can't cope with anonymous union initializers which seems to be a bug in that version (see the Reference) and is fixed since GCC version 4.6. A workaround which is also used elsewhere in the kernel for the same purpose is to wrap the initialization in curly braces, so do the same here. Fixes: b5565a2e ("drm/i915/bxt, glk: Give a proper name to the power well struct phy field") Reference: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Signed-off-by:
-
https://github.com/01org/gvt-linuxDaniel Vetter authored
gvt-next-2017-08-15 gvt update for 4.14 - MMIO save/restore optimization (Changbin) - Split workload scan vs. dispatch for more parallel exec (Ping) - vGPU full 48bit ppgtt support (Joonas, Tina) - vGPU hw id expose for perf (Zhenyu) - other misc cleanup and fixes Signed-off-by:
-
Balasubramaniam, Hari Chand authored
variable 'data' may be used uninitialized in this function. thus, 'function dcs_get_backlight' will return unwanted value/fail. Thus, adding NULL initialized to 'data' variable will solve the return failure happening. v2: Change commit message to reflect upstream with proper message Fixes: 90198355 ("drm/i915/dsi: Add DCS control for Panel PWM") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Yetunde Adebisi <yetundex.adebisi@intel.com> Cc: Deepak M <m.deepak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Balasubramaniam, Hari Chand <hari.chand.balasubramaniam@intel.com> Reviewed-by:
-
Manasi Navare authored
Validate the compliance test link parameters when the compliance test dpcd registers are read. Also validate them in compute_config before using them since the max values might have been reduced due to link training fallback. If either the link rate or lane count is invalid, we still bail from using the test parameters since the combination would not work and instead use the fallback values. v2: * Added commit message to explain why we still bail when either of of the params is invalid (Ville Syrjala) * Add reason for validating in the comment (Jani Nikula) * Also check if index >= 0 after validating (Jani Nikula) Signed-off-by:
Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Signed-off-by:
-
