- 29 Oct, 2021 7 commits
-
-
José Roberto de Souza authored
New workaround added to specification, requiring bit 15 of GEN8_CHICKEN_DCPR_1 to be programed before power well 1 is enabled. BSpec: 54369 Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211028230449.115832-1-jose.souza@intel.com
-
Jouni Högander authored
This reverts commit 1f61f065. Now we are supporting selective fetch for biplanar formats. We can revert WA patch which forced using full fetch for biplanar formats. Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
Jouni Högander authored
Biplanar formats are using two planes (Y and UV). This patch adds handling of Y selective fetch area by utilizing existing linked plane mechanism. Also UV plane Y offset configuration is modified according to Bspec. Signed-off-by:
-
Imre Deak authored
By using the modifier plane capability flags to encode the modifiers' CCS type and tiling attributes, it becomes simpler to the check for any of these capabilities when providing the list of supported modifiers. This also allows distinguishing modifiers on future platforms where platforms with the same display version support different modifiers. An example is DG2 and ADLP, both being D13, where DG2 supports only F and X tiling, while ADLP supports only Y and X tiling. With the INTEL_PLANE_CAP_TILING_* flags added in this patch we can provide the correct modifiers for each platform. v2: - Define PLANE_HAS_* with macros instead of an enum. (Jani) - Rename PLANE_HAS_*_ANY to PLANE_HAS_*_MASK. (Jani) - Rename PLANE_HAS_* to INTEL_PLANE_CAP_*. - Set the CCS_RC_CC cap only for DISPLAY_VER >= 12. - Set the TILING_Y cap only for DISPLAY_VER < 13 || ADLP. - Simplify the SKL plane cap display version checks and move them to a separate function. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027125150.2891371-1-imre.deak@intel.com
-
Imre Deak authored
Variables of enum types can contain only the values listed at the enums definition, so don't store bitmasks in intel_plane_caps enum variables. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
Remove the MC CCS plane capability on GEN<12, since it's not present there. This didn't cause a problem, since the display version check filtered out the MC CCS modifiers before GEN12. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Jani Nikula authored
Backmerge to get the DP 2.0 MST changes merged to drm-next. This also syncs us up to v5.15-rc7. Signed-off-by:Jani Nikula <jani.nikula@intel.com>
-
- 28 Oct, 2021 8 commits
-
-
Ville Syrjälä authored
Our lane power down defines already include the necessary shift, don't shift them a second time. Fortunately we masked off the correct bits, so we accidentally left all lanes powered up all the time. Bits 8-11 where we end up writing our misdirected lane mask are documented as MBZ, but looks like you can actually write there so they're not read only bits. No idea what side effect the bogus register write might have. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4151Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-17-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
Looks like we never updated intel_bios_is_port_dp_dual_mode() when the VBT port mapping became erratic on modern platforms. This is causing us to look up the wrong child device and thus throwing the heuristic off (ie. we might end looking at a child device for a genuine DP++ port when we were supposed to look at one for a native HDMI port). Fix it up by not using the outdated port_mapping[] in intel_bios_is_port_dp_dual_mode() and rely on intel_bios_encoder_data_lookup() instead. Cc: stable@vger.kernel.org Tested-by:
Randy Dunlap <rdunlap@infradead.org> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138Signed-off-by:
-
José Roberto de Souza authored
PSR2 is supported in transcoder A and B on Alderlake-P. v2: - explicity checking for transcoder A and B to avoid invalid transcoder BSpec: 49185 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jouni Hogander <jouni.hogander@intel.com> Signed-off-by:
-
Jani Nikula authored
The PPS, RC_RANGE_PARAM, and RC_BUF_THRESH logging are clearly for debugging, and should not be info level messages. Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Laurent Pinchart authored
Add FourCCs for 10- and 12-bit red formats with padding to 16 bits. They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10 and V4L2_PIX_FMT_Y12) formats, as well as the Bayer formats with the same bit depth (V4L2_PIX_FMT_SBGGR{10,12} and all other Bayer pattern permutations). These formats are not used by any kernel driver at this point, but need to be exposed to applications by libcamera, which uses DRM FourCCs for pixel formats. Signed-off-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027233140.12268-1-laurent.pinchart@ideasonboard.com
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
* eDP support in DP sub-driver (for newer SoCs with native eDP output) * dpu irq handling cleanup * CRC support for making igt happy * Support for NO_CONNECTOR bridges * dsi: 14nm phy support for msm8953 * mdp5: support for msm8x53, sdm450, sdm632 * various smaller fixes and cleanups Signed-off-by:
-
Dave Airlie authored
The msm next tree is based on rc3, so let's just backmerge rc7 before pulling it in. Signed-off-by: -
Dave Airlie authored
Merge tag 'topic/amdgpu-dp2.0-mst-2021-10-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next UAPI Changes: Nope! Cross-subsystem Changes: drm_dp_update_payload_part1() takes a new argument for specifying what the VCPI slot start is Core Changes: Make the DP MST helpers aware of the current starting VCPI slot/VCPI total slot count... Driver Changes: ...and then add support for taking advantage of this for 128b/132b links on DP 2.0 for amdgpu Signed-off-by:
-
- 27 Oct, 2021 12 commits
-
-
Alex Deucher authored
Need to guard some things with CONFIG_DRM_AMD_DC_DCN. Fixes: 41724ea2 ("drm/amd/display: Add DP 2.0 MST DM Support") Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Dave Airlie <airlied@gmail.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
Now that the bigjoiner state readout/computation has been made to do the right thing nuke the related state checker quirk. Reviewed-by:
-
Ville Syrjälä authored
Try to make bigjoiner pipes less special. The main things here are that each pipe now does full clock computation/readout with its own shared_dpll reference. Also every pipe's cpu_transcoder always points correctly at the master transcoder. Due to the above changes state readout is now complete and all the related hacks can go away. The actual modeset sequence code is still a mess, but I think in order to clean that up properly we're probably going to have to redesign the modeset logic to treat transcoders vs. pipes separately. That is going to require significant amounts of work. Reviewed-by:
-
Ville Syrjälä authored
Read out cpu_transcoder correctly for the bigjoiner slave pipes. Reviewed-by:
-
Ville Syrjälä authored
The PPS SDP is fed into the transcoder whereas the DSC block is (or at least can be) per pipe. Let's split these into two distinct operations in an effort to untagle the bigjoiner mess where we have two pipes feeding a single transcoder. Reviewed-by:
-
Ville Syrjälä authored
Rewrite intel_crtc_copy_uapi_to_hw_state_nomodeset() in a slightly more straightforward manner. Reviewed-by:
-
Ville Syrjälä authored
Add a helper to determine the master crtc for bigjoiner usage. Also name the variables consistently. Reviewed-by:
-
Ville Syrjälä authored
Let's disable planes on all pipes affected by the modeset before we start doing the actual modeset. This means we have less random planes enabled during the modeset, and it also mirrors what we already do when enabling pipes on skl+ since we enable planes on all pipes as the very last step. As a bonus we also nuke a bunch og bigjoiner special casing. I've occasionally pondered about going even furher here and doing the pre_plane_update() stuff for all pipes first, then actually disabling the planes, and finally running the rest of the modeset sequence. This would potentially allow parallelizing all the extra vblank waits across multiple pipes, and would make the plane disable even more atomic. But let's go one step a time here. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Disabling planes in the middle of the modeset seuqnece does not make sense since userspace can anyway disable planes before the modeset even starts. So when the modeset seuqence starts the set of enabled planes is entirely arbitrary. Trying to sprinkle the plane disabling into the modeset sequence just means more randomness and potential for hard to reproduce bugs. So it makes most sense to just disable all planes first so that the rest of the modeset sequence remains identical regardless of which planes happen to be enabled by userspace at the time. This reverts commit 84030adb. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Ville Syrjälä authored
PSR2 apparently requires some planes to be enabled for some silly reason, and so we are now trying to turn PSR off before planes go off. Except during a full modeset that is handled less clearly through reorganization of the modeset sequence. That is not great as it makes the code mode complex, and prevents us from doing nice things such as just turning off all the planes at the very start of the modeset. So let's move the PSR pre_plane_update() thing to a spot where it will handle both full modesets and everything else. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Mullati, Siva authored
The asm/iosf_mbi.h header is x86-only. Let's make IOSF_MBI kconfig selection conditional to x86 and provide a header with stubs for other architectures. This helps getting i915 available for other architectures in future. Signed-off-by:
Mullati, Siva <siva.mullati@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.16-2021-10-22' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.16-2021-10-22: amdgpu: - PSP fix for resume - XGMI fixes - Interrupt fix in device tear down - Renoir USB-C DP alt mode fix for resume - DP 2.0 fixes - Yellow Carp display fixes - Misc display fixes - RAS fixes - IP Discovery enumeration fixes - VGH fixes - SR-IOV fixes - Revert ChromeOS workaround in display code - Cyan Skillfish fixes amdkfd: - Fix error handling in gpu memory allocation - Fix build warnings with some configs - SVM fixes Signed-off-by:
-
- 26 Oct, 2021 8 commits
-
-
José Roberto de Souza authored
Alderlake-P was getting 'max time under evasion' messages when PSR2 is enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a period of time longer than VBLANK_EVASION_TIME_US. For PSR1 we had the same issue so intel_psr_wait_for_idle() was implemented to wait for PSR1 to get into idle state but nothing was done for PSR2. For PSR2 we can't only wait for idle state as PSR2 tends to keep into sleep state(ready to send selective updates). Waiting for any state below deep sleep proved to be effective in avoiding the evasion messages and also not wasted a lot of time. v2: - dropping the additional wait_for loops, only the _wait_for_atomic() is necessary - waiting for states below EDP_PSR2_STATUS_STATE_DEEP_SLEEP v3: - dropping intel_wait_for_condition_atomic() function Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005231851.67698-1-jose.souza@intel.com
-
Arnd Bergmann authored
Some randconfig builds fail when drm/drm_bridge.h is not included implicitly in this file: drivers/gpu/drm/msm/dp/dp_parser.c:279:25: error: implicit declaration of function 'devm_drm_panel_bridge_add' [-Werror,-Wimplicit-function-declaration] parser->panel_bridge = devm_drm_panel_bridge_add(dev, panel); Fixes: 4b296d15 ("drm/msm/dp: Allow attaching a drm_panel") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20211026083254.3396322-1-arnd@kernel.orgSigned-off-by:
Rob Clark <robdclark@chromium.org>
-
Nathan Chancellor authored
Clang warns: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:162:6: error: variable 'commit' is uninitialized when used here [-Werror,-Wuninitialized] if (commit) ^~~~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:106:32: note: initialize the variable 'commit' to silence this warning struct drm_crtc_commit *commit; ^ = NULL 1 error generated. The assignment and use of commit in the main body of dpu_crtc_set_crc_source() were removed from v1 to v2 but the call to drm_crtc_commit_put() at the end was not. Do that now so there is no more warning. Fixes: 78d9b458 ("drm/msm/dpu: Add CRC support for DPU") Link: https://github.com/ClangBuiltLinux/linux/issues/1493Reported-by:"kernelci.org bot" <bot@kernelci.org> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211026142435.3606413-1-nathan@kernel.orgSigned-off-by:
-
Jani Nikula authored
The intermediate value 1000000 * 10 * 9671 overflows 32 bits, so force promotion to a bigger type. From the logs: [drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available -580783288 v2: Use mul_u32_u32() (Ville) Fixes: 48efd014 ("drm/i915/dp: add max data rate calculation for UHBR rates") Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Bhawanpreet Lakha authored
[Why] Add DP2 MST and debugfs support [How] Update the slot info based on the link encoding format Reviewed-by:
"Lin, Wayne" <Wayne.Lin@amd.com> Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by:
-
Fangzhi Zuo authored
[Why] configure/call DC interface for DP2 mst support. This is needed to make DP2 mst work. [How] - add encoding type, logging, mst update/reduce payload functions Use the link encoding to determine the DP type (1.4 or 2.0) and add a flag to dc_stream_update to determine whether to increase/reduce payloads. v2: * add DP_UNKNOWN_ENCODING handling Signed-off-by:
-
Bhawanpreet Lakha authored
8b/10b encoding format requires to reserve the first slot for recording metadata. Real data transmission starts from the second slot, with a total of available 63 slots available. In 128b/132b encoding format, metadata is transmitted separately in LLCP packet before MTP. Real data transmission starts from the first slot, with a total of 64 slots available. v2: * Move total/start slots to mst_state, and copy it to mst_mgr in atomic_check v3: * Only keep the slot info on the mst_state * add a start_slot parameter to the payload function, to facilitate non atomic drivers (this is a temporary workaround and should be removed when we are moving out the non atomic driver helpers) v4: *fixed typo and formatting v5: (no functional changes) * Fixed formatting in drm_dp_mst_update_slots() * Reference mst_state instead of mst_state->mgr for debugging info Signed-off-by:
-
Bhawanpreet Lakha authored
This code path is used during commit, and we dont expect things to fail during the commit stage, so remove this. Signed-off-by:
-
- 25 Oct, 2021 5 commits
-
-
Linus Torvalds authored
-
Matthew Wilcox (Oracle) authored
Commit 11086054 ("mm/secretmem: use refcount_t instead of atomic_t") attempted to fix the problem of secretmem_users wrapping to zero and allowing suspend once again. But it was reverted in commit 87066fdd ("Revert 'mm/secretmem: use refcount_t instead of atomic_t'") because of the problems it caused - a refcount_t was not semantically the right type to use. Instead prevent secretmem_users from wrapping to zero by forbidding new users if the number of users has wrapped from positive to negative. This stops a long way short of reaching the necessary 4 billion users where it wraps to zero again, so there's no need to be clever with special anti-wrap types or checking the return value from atomic_inc(). Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Jordy Zomer <jordy@pwning.systems> Cc: Kees Cook <keescook@chromium.org>, Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Commit efafec27 ("spi: Fix tegra20 build with CONFIG_PM=n") already fixed the build without PM support once. There was an alternative fix by Guenter in commit 2bab9409 ("spi: tegra20-slink: Declare runtime suspend and resume functions conditionally"), and Mark then merged the two correctly in ffb1e76f ("Merge tag 'v5.15-rc2' into spi-5.15"). But for some inexplicable reason, Mark then merged things _again_ in commit 59c4e190 ("Merge tag 'v5.15-rc3' into spi-5.15"), and screwed things up at that point, and the __maybe_unused attribute on tegra_slink_runtime_resume() went missing. Reinstate it, so that alpha (and other architectures without PM support) builds cleanly again. Btw, this is another prime example of how random back-merges are not good. Just don't do them. Subsystem developers should not merge my tree in any normal circumstances. Both of those merge commits pointed to above are bad: even the one that got the merge result right doesn't even mention _why_ it was done, and the one that got it wrong is obviously broken. Reported-by:
Guenter Roeck <linux@roeck-us.net> Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
-
git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: - Fix clang-related relocation warning in futex code - Fix incorrect use of get_kernel_nofault() - Fix bad code generation in __get_user_check() when kasan is enabled - Ensure TLB function table is correctly aligned - Remove duplicated string function definitions in decompressor - Fix link-time orphan section warnings - Fix old-style function prototype for arch_init_kprobes() - Only warn about XIP address when not compile testing - Handle BE32 big endian for keystone2 remapping * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9148/1: handle CONFIG_CPU_ENDIAN_BE32 in arch/arm/kernel/head.S ARM: 9141/1: only warn about XIP address when not compile testing ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype ARM: 9138/1: fix link warning with XIP + frame-pointer ARM: 9134/1: remove duplicate memcpy() definition ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned ARM: 9132/1: Fix __get_user_check failure with ARM KASAN images ARM: 9125/1: fix incorrect use of get_kernel_nofault() ARM: 9122/1: select HAVE_FUTEX_CMPXCHG
-
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libataLinus Torvalds authored
Pull libata fix from Damien Le Moal: "A single fix in this pull request addressing an invalid error code return in the sata_mv driver (from Zheyu)" * tag 'libata-5.15-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: ata: sata_mv: Fix the error handling of mv_chip_id()
-
