aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-03-21x86/lib: Fix indentation issue, remove extra tabColin Ian King1-1/+1
The increment of buff is indented one level too deeply, clean this up by removing a tab. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: "H . Peter Anvin" <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-03-21x86/boot: Restrict header scope to make Clang happyNick Desaulniers1-1/+2
The inclusion of <linux/kernel.h> was causing issue as the definition of __arch_hweight64 from arch/x86/include/asm/arch_hweight.h eventually gets included. The definition is problematic when compiled with -m16 (all code in arch/x86/boot/ is) as the "D" inline assembly constraint is rejected by both compilers when passed an argument of type long long (regardless of signedness, anything smaller is fine). Because GCC performs inlining before semantic analysis, and __arch_hweight64 is dead in this translation unit, GCC does not report any issues at compile time. Clang does the semantic analysis in the front end, before inlining (run in the middle) can determine the code is dead. I consider this another case of PR33587, which I think we can do more work to solve. It turns out that arch/x86/boot/string.c doesn't actually need linux/kernel.h, simply linux/limits.h and linux/compiler.h. Suggested-by: Stephen Rothwell <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Cc: [email protected] Cc: [email protected] Cc: "H. Peter Anvin" <[email protected]> Cc: Chao Fan <[email protected]> Cc: Uros Bizjak <[email protected]> Link: https://bugs.llvm.org/show_bug.cgi?id=33587 Link: https://github.com/ClangBuiltLinux/linux/issues/347 Link: https://lkml.kernel.org/r/[email protected]
2019-03-21irqchip/mbigen: Don't clear eventid when freeing an MSIJianguo Chen1-0/+3
mbigen_write_msg clears eventid bits of a mbigen register when free a interrupt, because msi_domain_deactivate memset struct msg to zero. Then multiple mbigen pins with zero eventid will report the same interrupt number. The eventid clear call trace: free_irq __free_irq irq_shutdown irq_domain_deactivate_irq __irq_domain_deactivate_irq __irq_domain_deactivate_irq msi_domain_deactivate platform_msi_write_msg mbigen_write_msg Signed-off-by: Jianguo Chen <[email protected]> [maz: massaged subject] Signed-off-by: Marc Zyngier <[email protected]>
2019-03-21irqchip/stm32: Don't set rising configuration registers at initFabien Dessenne1-5/+0
The rising configuration status register (rtsr) is not banked. As it is shared with the co-processor, it should not be written at probe time, else the co-processor configuration will be lost. Fixes: f9fc1745501e ("irqchip/stm32: Add host and driver data structures") Signed-off-by: Fabien Dessenne <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-03-21irqchip/stm32: Don't clear rising/falling config registers at initFabien Dessenne1-5/+0
Falling and rising configuration and status registers are not banked. As they are shared with M4 co-processor, they should not be cleared at probe time, else M4 co-processor configuration will be lost. Fixes: f9fc1745501e ("irqchip/stm32: Add host and driver data structures") Signed-off-by: Loic Pallardy <[email protected]> Signed-off-by: Fabien Dessenne <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-03-21dt-bindings: irqchip: renesas-irqc: Document r8a774c0 supportFabrizio Castro1-0/+1
Document RZ/G2E (R8A774C0) SoC bindings. Signed-off-by: Fabrizio Castro <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-03-21irqchip/mmp: Make mmp_irq_domain_ops staticYueHaibing1-1/+1
Fix sparse warning: drivers/irqchip/irq-mmp.c:182:29: warning: symbol 'mmp_irq_domain_ops' was not declared. Should it be static? Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-03-21irqchip/brcmstb-l2: Make two init functions staticYueHaibing1-2/+2
Fix sparse warnings: drivers/irqchip/irq-brcmstb-l2.c:278:12: warning: symbol 'brcmstb_l2_edge_intc_of_init' was not declared. Should it be static? drivers/irqchip/irq-brcmstb-l2.c:285:12: warning: symbol 'brcmstb_l2_lvl_intc_of_init' was not declared. Should it be static? Signed-off-by: YueHaibing <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-03-21objtool: Move objtool_file struct off the stackJosh Poimboeuf1-1/+2
Objtool uses over 512k of stack, thanks to the hash table embedded in the objtool_file struct. This causes an unnecessarily large stack allocation and breaks users with low stack limits. Move the struct off the stack. Fixes: 042ba73fe7eb ("objtool: Add several performance improvements") Reported-by: Vassili Karpov <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/df92dcbc4b84b02ffa252f46876df125fb56e2d7.1552954176.git.jpoimboe@redhat.com
2019-03-21workqueue: Only unregister a registered lockdep keyBart Van Assche1-2/+3
The recent change to prevent use after free and a memory leak introduced an unconditional call to wq_unregister_lockdep() in the error handling path. If the lockdep key had not been registered yet, then the lockdep core emits a warning. Only call wq_unregister_lockdep() if wq_register_lockdep() has been called first. Fixes: 009bb421b6ce ("workqueue, lockdep: Fix an alloc_workqueue() error path") Reported-by: [email protected] Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Qian Cai <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-03-21genirq: Fix typo in comment of IRQD_MOVE_PCNTXTPeter Xu1-1/+1
Signed-off-by: Peter Xu <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Dou Liyang <[email protected]> Cc: Julien Thierry <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-03-21mmc: renesas_sdhi: limit block count to 16 bit for old revisionsWolfram Sang1-1/+7
R-Car Gen2 has two different SDHI incarnations in the same chip. The older one does not support the recently introduced 32 bit register access to the block count register. Make sure we use this feature only after the first known version. Thanks to the Renesas Testing team for this bug report! Fixes: 5603731a15ef ("mmc: tmio: fix access width of Block Count Register") Reported-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Phong Hoang <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2019-03-21mmc: alcor: fix DMA readsDaniel Drake1-6/+19
Setting max_blk_count to 1 here was causing the mmc block layer to always use the MMC_READ_SINGLE_BLOCK command here, which the driver does not DMA-accelerate. Drop the max_blk_ settings here. The mmc host defaults suffice, along with the max_segs and max_seg_size settings, which I have now documented in more detail. Now each MMC command reads 4 512-byte blocks, using DMA instead of PIO. On my SD card, this increases read performance (measured with dd) from 167kb/sec to 4.6mb/sec. Link: http://lkml.kernel.org/r/CAD8Lp47L5T3jnAjBiPs1cQ+yFA3L6LJtgFvMETnBrY63-Zdi2g@mail.gmail.com Signed-off-by: Daniel Drake <[email protected]> Reviewed-by: Oleksij Rempel <[email protected]> Fixes: c5413ad815a6 ("mmc: add new Alcor Micro Cardreader SD/MMC driver") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2019-03-21mmc: sdhci-omap: Set caps2 to indicate no physical write protect pinKishon Vijay Abraham I1-0/+3
After commit 6d5cd068ee59fba ("mmc: sdhci: use WP GPIO in sdhci_check_ro()") and commit 39ee32ce486756f ("mmc: sdhci-omap: drop ->get_ro() implementation"), sdhci-omap relied on SDHCI_PRESENT_STATE to check if the card is read-only, if wp-gpios is not populated in device tree. However SDHCI_PRESENT_STATE in sdhci-omap does not have correct read-only state. sdhci-omap can be used by platforms with both micro SD slot and standard SD slot with physical write protect pin (using GPIO). Set caps2 to MMC_CAP2_NO_WRITE_PROTECT based on if wp-gpios property is populated or not. This fix is required since existing device-tree node doesn't have "disable-wp" property and to preserve old-dt compatibility. Fixes: 6d5cd068ee59fba ("mmc: sdhci: use WP GPIO in sdhci_check_ro()") Fixes: 39ee32ce486756f ("mmc: sdhci-omap: drop ->get_ro() implementation") Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2019-03-21powerpc/security: Fix spectre_v2 reportingMichael Ellerman1-15/+8
When I updated the spectre_v2 reporting to handle software count cache flush I got the logic wrong when there's no software count cache enabled at all. The result is that on systems with the software count cache flush disabled we print: Mitigation: Indirect branch cache disabled, Software count cache flush Which correctly indicates that the count cache is disabled, but incorrectly says the software count cache flush is enabled. The root of the problem is that we are trying to handle all combinations of options. But we know now that we only expect to see the software count cache flush enabled if the other options are false. So split the two cases, which simplifies the logic and fixes the bug. We were also missing a space before "(hardware accelerated)". The result is we see one of: Mitigation: Indirect branch serialisation (kernel only) Mitigation: Indirect branch cache disabled Mitigation: Software count cache flush Mitigation: Software count cache flush (hardware accelerated) Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush") Cc: [email protected] # v4.19+ Signed-off-by: Michael Ellerman <[email protected]> Reviewed-by: Michael Neuling <[email protected]> Reviewed-by: Diana Craciun <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-03-21mmc: mxcmmc: "Revert mmc: mxcmmc: handle highmem pages"Alexander Shiyan1-12/+4
This reverts commit b189e7589f6d3411e85c6b7ae6eef158f08f388f. Unable to handle kernel paging request at virtual address c8358000 pgd = efa405c3 [c8358000] *pgd=00000000 Internal error: Oops: 805 [#1] PREEMPT ARM CPU: 0 PID: 711 Comm: kworker/0:2 Not tainted 4.20.0+ #30 Hardware name: Freescale i.MX27 (Device Tree Support) Workqueue: events mxcmci_datawork PC is at mxcmci_datawork+0xbc/0x2ac LR is at mxcmci_datawork+0xac/0x2ac pc : [<c04e33c8>] lr : [<c04e33b8>] psr: 60000013 sp : c6c93f08 ip : 24004180 fp : 00000008 r10: c8358000 r9 : c78b3e24 r8 : c6c92000 r7 : 00000000 r6 : c7bb8680 r5 : c7bb86d4 r4 : c78b3de0 r3 : 00002502 r2 : c090b2e0 r1 : 00000880 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: a68a8000 DAC: 00000055 Process kworker/0:2 (pid: 711, stack limit = 0x389543bc) Stack: (0xc6c93f08 to 0xc6c94000) 3f00: c7bb86d4 00000000 00000000 c6cbfde0 c7bb86d4 c7ee4200 3f20: 00000000 c0907ea8 00000000 c7bb86d8 c0907ea8 c012077c c6cbfde0 c7bb86d4 3f40: c6cbfde0 c6c92000 c6cbfdf4 c09280ba c0907ea8 c090b2e0 c0907ebc c0120c18 3f60: c6cbfde0 00000000 00000000 c6cbb580 c7ba7c40 c7837edc c6cbb598 00000000 3f80: c6cbfde0 c01208f8 00000000 c01254fc c7ba7c40 c0125400 00000000 00000000 3fa0: 00000000 00000000 00000000 c01010d0 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c04e33c8>] (mxcmci_datawork) from [<c012077c>] (process_one_work+0x1f0/0x338) [<c012077c>] (process_one_work) from [<c0120c18>] (worker_thread+0x320/0x474) [<c0120c18>] (worker_thread) from [<c01254fc>] (kthread+0xfc/0x118) [<c01254fc>] (kthread) from [<c01010d0>] (ret_from_fork+0x14/0x24) Exception stack(0xc6c93fb0 to 0xc6c93ff8) 3fa0: 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e3500000 1a000059 e5153050 e5933038 (e48a3004) ---[ end trace 54ca629b75f0e737 ]--- note: kworker/0:2[711] exited with preempt_count 1 Signed-off-by: Alexander Shiyan <[email protected]> Fixes: b189e7589f6d ("mmc: mxcmmc: handle highmem pages") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2019-03-21drm/i915: Use __is_constexpr()Chris Wilson1-2/+2
gcc-4.8 and older dislike the use of __builtin_constant_p() within a constant expression context, and so we must use the magical __is_constexpr() instead. For example, with gcc-4.8.5: ../drivers/gpu/drm/i915/i915_reg.h:167:27: error: first argument to ‘__builtin_choose_expr’ not a constant ../include/linux/build_bug.h:16:45: error: bit-field ‘<anonymous>’ width not an integer constant Reported-by: Randy Dunlap <[email protected]> Reported-by: Uma Shankar <[email protected]> Fixes: baa09e7d2f42 ("drm/i915: use REG_FIELD_PREP() to define register bitfield values") Signed-off-by: Chris Wilson <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Imre Deak <[email protected]> Cc: Randy Dunlap <[email protected]> Acked-by: Randy Dunlap <[email protected]> # build-tested Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-21drm/fourcc: Fix conflicting Y41x definitionsMaarten Lankhorst4-40/+41
There has unfortunately been a conflict with the following 3 commits: commit e9961ab95af81b8d29054361cd5f0c575102cf87 Author: Ayan Kumar Halder <[email protected]> Date: Fri Nov 9 17:21:12 2018 +0000 drm: Added a new format DRM_FORMAT_XVYU2101010 commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3 Author: Brian Starkey <[email protected]> Date: Fri Oct 5 10:27:00 2018 +0100 drm/fourcc: Add AFBC yuv fourccs for Mali and commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b Author: Swati Sharma <[email protected]> Date: Mon Mar 4 17:26:33 2019 +0530 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc Unfortunately gcc didn't warn about the redefinitions, because the double defines were the set to same value, and gcc apparently no longer warns about that. Fix this by using new XYVU for i915, without alpha, and making the Y41x definitions match msdn, with alpha. Fortunately we caught it early, and the conflict hasn't even landed in drm-next yet. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: Brian Starkey <[email protected]> Cc: Swati Sharma <[email protected]> Cc: Ayan Kumar Halder <[email protected]> Cc: [email protected] Cc: Daniel Vetter <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sean Paul <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Liviu Dudau <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> #irc Acked-by: Sean Paul <[email protected]> Reviewed-by: Ayan Kumar halder <[email protected]>
2019-03-21ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286Jian-Hong Pan1-3/+14
Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot record sound from headset MIC. This patch adds the ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue. Fixes: 9f8aefed9623 ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G") Fixes: b72f936f6b32 ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G") Signed-off-by: Jian-Hong Pan <[email protected]> Reviewed-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-03-20drm/amdgpu: add one rlc version into gfxoff blacklistHuang Rui1-0/+1
RLC #53815 ucode has the noise issue on 4k playback while gfxoff enabled. Signed-off-by: Huang Rui <[email protected]> Acked-by: Alex Deucher <[email protected]> Tested-by: Tom St Denis <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amdgpu: enable gfxoff again on raven series (v2)Huang Rui5-11/+33
This patch enables gfxoff and stutter mode again, since we take more testing on raven series. For raven2 and picasso, we can enable it directly. And for raven, we need check the RLC/SMC ucode version cannot be less than #531/0x1e45. v2: add smc version checking for raven. Signed-off-by: Huang Rui <[email protected]> Reviewed-by: Alex Deucher <[email protected]> (v1) Tested-by: Likun Gao <[email protected]> (v2) Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/powerplay: fix spelling mistake "unknow" -> "unknown"Colin Ian King1-1/+1
There is a spelling mistake in pr_warn message; fix it. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/powerplay: Zero initialize num_of_levels in vega20_set_single_dpm_tableNathan Chancellor1-1/+1
When building with -Wsometimes-uninitialized, Clang warns: drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:456:2: warning: variable 'num_of_levels' is used uninitialized whenever '?:' condition is false [-Wsometimes-uninitialized] smu_read_smc_arg(smu, &num_of_levels); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:608:3: note: expanded from macro 'smu_read_smc_arg' ((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg)) : 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:457:7: note: uninitialized use occurs here if (!num_of_levels) { ^~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:456:2: note: remove the '?:' if its condition is always true smu_read_smc_arg(smu, &num_of_levels); ^ drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:608:3: note: expanded from macro 'smu_read_smc_arg' ((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg)) : 0) ^ drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:446:27: note: initialize the variable 'num_of_levels' to silence this warning uint32_t i, num_of_levels, clk; ^ = 0 1 warning generated. The if statement it mentions as potentially problematic is currently always true because the read_smc_arg callback is assigned at the bottom of this file but Clang can't tell that. If the callback were ever to disappear, num_of_levels would never be initialized. Just zero initialize it to ensure that the intent behind this code remains the same. Link: https://github.com/ClangBuiltLinux/linux/issues/425 Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/ttm: remove set but not used variable 'rdev'YueHaibing1-4/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_move_vram_ram': drivers/gpu/drm/radeon/radeon_ttm.c:254:24: warning: variable 'rdev' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_move_ram_vram': drivers/gpu/drm/radeon/radeon_ttm.c:301:24: warning: variable 'rdev' set but not used [-Wunused-but-set-variable] It's not used since a987fcaa805f ("ttm: Make parts of a struct ttm_bo_device global.") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Only put primary planes into the mode_info->planes listNicholas Kazlauskas1-10/+9
We want DRM planes to be initialized in the following order: - primary planes - overlay planes - cursor planes to support existing userspace expectations for plane z-ordering. This means that we also need to register CRTCs after all planes have been initialized since overlay planes can be placed on any CRTC. So the only reason why we have the mode_info->planes list is to remember the primary planes for use later when we need to register the CRTC. Overlay planes have no purpose being in this list. DRM will cleanup any planes that we've registered for us, so the only planes that need to be explicitly cleaned up are the ones that have failed to register. By dropping the explicit free on every plane in the mode_info->planes list this patch also fixes a double-free in the case where we fail to initialize only some of the planes. Cc: Leo Li <[email protected]> Cc: Harry Wentland <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Add debugfs dpcd interfaceDavid Francis3-1/+112
[Why] We need arbitrary read/write over DP AUX DPCD for debugging [How] Three debugfs entries Set the target address by writing to "aux_dpcd_address" (The first four bytes written are used) Set the transaction size in bytes by writing to "aux_dpcd_size" (The first four bytes written are used) Start a transaction by reading/writing "aux_dpcd_data" Do note: there is no concerrency protection at all Accessing these entries in quick succession can lead to strange behaviour Signed-off-by: David Francis <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Generic SDP message access in amdgpuLeo (Hanghong) Ma1-1/+49
[Why] We need to add DP SDP message test debugfs to make sdp message test more convenient and efficient. [How] Add sdp_message debugfs entry in amdgpu. Signed-off-by: Leo (Hanghong) Ma <[email protected]> Reviewed-by: Sun peng Li <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Acked-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Expose generic SDP message access interfaceLeo (Hanghong) Ma5-1/+97
[Why] We need to add DP SDP message test debugfs to make sdp message test more convenient and efficient. [How] Add a DM accessible SDP interface for custom data. Signed-off-by: Leo (Hanghong) Ma <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Roman Li <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: fix odm pipe managementDmytro Laktyushkin2-7/+53
There are issues removing surfaces/streams when odm is active. This is a step to fix that Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: add missing opp programming for odmDmytro Laktyushkin3-8/+6
A number of places opp programming was missing for odm second pipe. This change fixes the oversight. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: fix odm combine pipe resetDmytro Laktyushkin1-4/+2
We fail to reset the second odm combine pipe. This change fixes odm pointer management. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: fix releasing planes when exiting odmDmytro Laktyushkin1-2/+4
Releasing planes should not release the 2nd odm pipe right away, this change leaves us with 2 pipes with null planes and same stream when planes are released during odm. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: 3.2.23Aric Cyr1-1/+1
Signed-off-by: Aric Cyr <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Fix VTEM InfoPacket programmingReza Amini1-33/+111
Refactor setting bit fields. Correcting the offset of MD0. Initializing the InfoPacket header fields. Defining the field offsets and masks. Signed-off-by: Reza Amini <[email protected]> Reviewed-by: Anthony Koo <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Link train only when link is DP and backend is enabledSamson Tam1-1/+12
[Why] In certain cases we do link training when we don't have a backend. [How] In dc_link_set_preferred_link_settings(), store preferred link settings first and then verify that the link is DP and the link stream's backend is enabled. If either is false, then we will not do any link retraining. Signed-off-by: Samson Tam <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Anthony Koo <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: add global master update lock interfacesWenjing Liu2-0/+6
Add these interfacese for future use setup_global_lock() lock_global() pipe_control_lock_global() Signed-off-by: Wenjing Liu <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Use dc_is_hdmi_signal() instead of ENUMEric Bernstein2-3/+2
Signed-off-by: Eric Bernstein <[email protected]> Reviewed-by: Nevenko Stupar <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: cache additional dpcd caps for HDR capability checkHarmanprit Tatla3-5/+50
[Why] Currently we are missing a few checks to see if HDR10 is allowed. In particular we never check for the extended colorimetry bit (whether its present or set to 1). Further we don't read in the dpcd block in DC that would provide these bits. [How] - Added in DC code to read in the block containing the extended colorimetry bit. Signed-off-by: Harmanprit Tatla <[email protected]> Reviewed-by: Anthony Koo <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Update ABM crtc state on non-modesetDavid Francis1-0/+3
[Why] Somewhere in the atomic check reshuffle ABM got lost. ABM is a crtc property (copied from a connector property). It can change without a modeset, just like underscan. [How] In the skip_modeset branch of atomic check crtc updates, copy over the abm property. Signed-off-by: David Francis <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Programming correct VRR_EN bit in VTEM structureHugo Hu1-2/+2
[Why] In HDMI plugfest, MTK report our EMP with VRR_EN bit = 0. VRR_EN bit is EMP-MD0-bit 0. Currently driver set 1 to bit 3. [How] Programming correct VRR_EN bit in EMP-MD0-bit0. Signed-off-by: Hugo Hu <[email protected]> Reviewed-by: Reza Amini <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: 3.2.22Aric Cyr1-1/+1
Signed-off-by: Aric Cyr <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: extend EDID support to 1kbJun Lei1-1/+1
[why] There exist displays with EDIDs > 512 bytes, existing code will cause us to ignore all extension blocks. Signed-off-by: Jun Lei <[email protected]> Reviewed-by: Wenjing Liu <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Fix DP audio regressionWesley Chalmers1-3/+2
Audio was unmuted for HDMI only, need to do so for DP as well. Signed-off-by: Wesley Chalmers <[email protected]> Reviewed-by: Chris Park <[email protected]> Reviewed-by: Eric Bernstein <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Add a hysteresis to BTR frame multiplierAric Cyr1-2/+22
[Why] Flickering is observed on some displays when the number of inserted BTR frames changes frequently. [How] Add in a margin of drift to prevent the inserted number of frames from jumping around too frequently. Signed-off-by: Aric Cyr <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: fix DP 422 VID_M half the rate issue.Charlene Liu5-9/+31
[Description] when programming VID_TIMING, we were using the original VESA timing for DP_VIDM/N. for YCbCr420 or compressed YCbCr422, using half rate as YCbCr444. Signed-off-by: Charlene Liu <[email protected]> Reviewed-by: Nikola Cornij <[email protected]> Acked-by: Leo Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Fix setting DP_VID_N_MULEric Bernstein3-4/+11
[Why] Need to set VID_N_MUL for 4:2:0 cases [How] Move setting to enc1_stream_encoder_dp_unblank and ensure it is also set for non-4:2:0 cases. Signed-off-by: Eric Bernstein <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Move dm_read_reg_func to dc_helper.Yongqiang Sun2-17/+22
Move out of header to dc_helper.c, in preparation for future implementations. Signed-off-by: Yongqiang Sun <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Use drm helper for resetting plane stateNicholas Kazlauskas1-7/+2
[Why] To help prevent plane state not being set to the correct default value if any new properties are added in the future. [How] Use the drm helper - which seems to be the common solution among other DRM drivers. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Sun peng Li <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: change generic_reg_wait to void.Yongqiang Sun3-6/+5
we were only checking the return value in one place, thus changing generic_reg_wait from int to void and reading the register instead of getting it from generic_reg_wait, when we need the return value. Signed-off-by: Yongqiang Sun <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-20drm/amd/display: Reset alpha state for planes to the correct valuesNicholas Kazlauskas1-0/+2
[Why] The plane_reset callback is subclassed but hasn't been updated since the drm helper got updated to include resetting alpha related state (state->alpha and state->pixel_blend_mode). The overlay planes exposed by amdgpu_dm were therefore being rendered as invisible by default ever since supported was exposed for alpha blending properties on overlays. This caused regressions in igt@kms_plane_multiple@atomic-tiling-none and igt@kms_plane@plane-position-covered-pipe tests. [How] Reset the plane state values to their correct values as defined in the drm helper. This fixes the IGT test regression. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.