summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-10drm/amdgpu: add function to creat all ras debugfs nodeTao Zhou
centralize all debugfs creation in one place for ras this is required to fix ras when the driver does not use the drm load and unload callbacks due to ordering issues with the drm device node. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-10drm/amd/powerplay: fix the coverity warning about negative check for an ↵Prike Liang
unsigned value There will be a coverity warning because min and max are both unsigned. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-10drm/amdgpu: Correct the condition of warning while bo releasexinhui pan
Only kernel bo has kfd eviction fence. This warning is to give a notice that kfd only remove eviction fence on individual bos. Tested-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: xinhui pan <xinhui.pan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-10drm/amdkfd: Consolidate duplicated bo alloc flagsYong Zhao
ALLOC_MEM_FLAGS_* used are the same as the KFD_IOC_ALLOC_MEM_FLAGS_*, but they are interweavedly used in kernel driver, resulting in bad readability. For example, KFD_IOC_ALLOC_MEM_FLAGS_COHERENT is not referenced in kernel, and it functions implicitly in kernel through ALLOC_MEM_FLAGS_COHERENT, causing unnecessary confusion. Replace all occurrences of ALLOC_MEM_FLAGS_* with KFD_IOC_ALLOC_MEM_FLAGS_* to solve the problem. Signed-off-by: Yong Zhao <Yong.Zhao@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-10drm/amdkfd: Use pr_debug to print the message of reaching event limitYong Zhao
People are inclined to think of the previous pr_warn message as an error, so use pre_debug instead. Signed-off-by: Yong Zhao <Yong.Zhao@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-10drm/amdgpu: do not set nil entry in compute_prio_schedNirmoy Das
If there are no high priority compute queues available then set normal priority sched array to compute_prio_sched[AMDGPU_GFX_PIPE_PRIO_HIGH] Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-10dt-bindings: display: Add idk-2121wr bindingFabrizio Castro
Add binding for the idk-2121wr LVDS panel from Advantech. Some panel-specific documentation can be found here: https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1583869169-1006-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
2020-03-10drm/dp_mst: Fix drm_dp_check_mstb_guid() return codeLyude Paul
We actually expect this to return a 0 on success, or negative error code on failure. In order to do that, we check whether or not we managed to write the whole GUID and then return 0 if so, otherwise return a negative error code. Also, let's add an error message here so it's a little more obvious when this fails in the middle of a link address probe. This should fix issues with certain MST hubs seemingly stopping for no reason in the middle of the link address probe process. Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings") Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Sean Paul <sean@poorly.run> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-3-lyude@redhat.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-10drm/dp_mst: Make drm_dp_mst_dpcd_write() consistent with drm_dp_dpcd_write()Lyude Paul
Noticed this while having some problems with hubs sometimes not being detected on the first plug. Every single dpcd read or write function returns the number of bytes transferred on success or a negative error code, except apparently for drm_dp_mst_dpcd_write() - which returns 0 on success. There's not really any good reason for this difference that I can tell, and having the two functions give differing behavior means that drm_dp_dpcd_write() will end up returning 0 on success for MST devices, but the number of bytes transferred for everything else. So, fix that and update the kernel doc. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 2f221a5efed4 ("drm/dp_mst: Add MST support to DP DPCD R/W functions") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-2-lyude@redhat.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-10drm/panel-simple: Fix dotclock for Ortustech COM37H3MH. Nikolaus Schaller
The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. There are two variants of the COM37H3M panel. The older one's COM37H3M05DTC data sheet specifies: MIN TYP MAX CLK frequency fCLK -- 22.4 26.3 MHz (in VGA mode) VSYNC Frequency fVSYNC 54 60 66 Hz VSYNC cycle time tv -- 650 -- H HSYNC frequency fHSYNC -- 39.3 -- kHz HSYNC cycle time th -- 570 -- CLK The newer one's COM37H3M99DTC data sheet says: MIN TYP MAX CLK frequency fCLK 18 19.8 27 MHz VSYNC Frequency fVSYNC 54 60 66 Hz VSYNC cycle time tv 646 650 700 H HSYNC frequency fHSYNC -- 39.0 50.0 kHz HSYNC cycle time th 504 508 630 CLK So we choose a parameter set that lies within the specs of both variants. We start at .vrefresh = 60, choose .htotal = 570 and .vtotal = 650 and end up in a clock of 22.230 MHz. Reported-by: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/e63a0533ad5b5142373437ef758aedbdb716152d.1583826198.git.hns@goldelico.com
2020-03-10blk-iocost: fix incorrect vtime comparison in iocg_is_idle()Tejun Heo
vtimes may wrap and time_before/after64() should be used to determine whether a given vtime is before or after another. iocg_is_idle() was incorrectly using plain "<" comparison do determine whether done_vtime is before vtime. Here, the only thing we're interested in is whether done_vtime matches vtime which indicates that there's nothing in flight. Let's test for inequality instead. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-10drm: panel: Set connector type for OrtusTech COM43H4M85ULC panelLaurent Pinchart
The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200309184210.10042-1-laurent.pinchart@ideasonboard.com
2020-03-10RDMA/mlx5: Fix the number of hwcounters of a dynamic counterMark Zhang
When we read the global counter and there's any dynamic counter allocated, the value of a hwcounter is the sum of the default counter and all dynamic counters. So the number of hwcounters of a dynamically allocated counter must be same as of the default counter, otherwise there will be read violations. This fixes the KASAN slab-out-of-bounds bug: BUG: KASAN: slab-out-of-bounds in rdma_counter_get_hwstat_value+0x36d/0x390 [ib_core] Read of size 8 at addr ffff8884192a5778 by task rdma/10138 CPU: 7 PID: 10138 Comm: rdma Not tainted 5.5.0-for-upstream-dbg-2020-02-06_18-30-19-27 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xb7/0x10b print_address_description.constprop.4+0x1e2/0x400 ? rdma_counter_get_hwstat_value+0x36d/0x390 [ib_core] __kasan_report+0x15c/0x1e0 ? mlx5_ib_query_q_counters+0x13f/0x270 [mlx5_ib] ? rdma_counter_get_hwstat_value+0x36d/0x390 [ib_core] kasan_report+0xe/0x20 rdma_counter_get_hwstat_value+0x36d/0x390 [ib_core] ? rdma_counter_query_stats+0xd0/0xd0 [ib_core] ? memcpy+0x34/0x50 ? nla_put+0xe2/0x170 nldev_stat_get_doit+0x9c7/0x14f0 [ib_core] ... do_syscall_64+0x95/0x490 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fcc457fe65a Code: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa f1 2b 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 f3 c3 0f 1f 40 00 41 55 41 54 4d 89 c5 55 RSP: 002b:00007ffc0586f868 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcc457fe65a RDX: 0000000000000020 RSI: 00000000013db920 RDI: 0000000000000003 RBP: 00007ffc0586fa90 R08: 00007fcc45ac10e0 R09: 000000000000000c R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004089c0 R13: 0000000000000000 R14: 00007ffc0586fab0 R15: 00000000013dc9a0 Allocated by task 9700: save_stack+0x19/0x80 __kasan_kmalloc.constprop.7+0xa0/0xd0 mlx5_ib_counter_alloc_stats+0xd1/0x1d0 [mlx5_ib] rdma_counter_alloc+0x16d/0x3f0 [ib_core] rdma_counter_bind_qpn_alloc+0x216/0x4e0 [ib_core] nldev_stat_set_doit+0x8c2/0xb10 [ib_core] rdma_nl_rcv_msg+0x3d2/0x730 [ib_core] rdma_nl_rcv+0x2a8/0x400 [ib_core] netlink_unicast+0x448/0x620 netlink_sendmsg+0x731/0xd10 sock_sendmsg+0xb1/0xf0 __sys_sendto+0x25d/0x2c0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x95/0x490 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 18d422ce8ccf ("IB/mlx5: Add counter_alloc_stats() and counter_update_stats() support") Link: https://lore.kernel.org/r/20200305124052.196688-1-leon@kernel.org Signed-off-by: Mark Zhang <markz@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-10MAINTAINERS: Update maintainers for HISILICON ROCE DRIVERWeihang Li
Add myself as a maintainer for HNS RoCE drivers, and update Xavier's e-amil address. Link: https://lore.kernel.org/r/1583575114-32194-1-git-send-email-liweihang@huawei.com Signed-off-by: Weihang Li <liweihang@huawei.com> Acked-by: Wei Hu (Xavier) <xavier.huwei@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-10RDMA/odp: Fix leaking the tgid for implicit ODPJason Gunthorpe
The tgid used to be part of ib_umem_free_notifier(), when it was reworked it got moved to release, but it should have been unconditional as all umem alloc paths get the tgid. As is, creating an implicit ODP will leak the tgid reference. Link: https://lore.kernel.org/r/20200304181607.GA22412@ziepe.ca Cc: stable@kernel.org Fixes: f25a546e6529 ("RDMA/odp: Use mmu_interval_notifier_insert()") Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-10Merge branch 'fix-BTF-enum'Alexei Starovoitov
Yoshiki Komachi says: ==================== btf_enum_check_member() checked if the size of "enum" as a struct member exceeded struct_size or not. Then, the function compared it with the size of "int". Although the size of "enum" is 4-byte by default (i.e., equivalent to "int"), the packing feature enables us to reduce it, as illustrated by the following example: struct A { char m; enum { E0, E1 } __attribute__((packed)) n; }; With such a setup above, the bpf loader gave an error attempting to load it: ------------------------------------------------------------------ ... [3] ENUM (anon) size=1 vlen=2 E0 val=0 E1 val=1 [4] STRUCT A size=2 vlen=2 m type_id=2 bits_offset=0 n type_id=3 bits_offset=8 [4] STRUCT A size=2 vlen=2 n type_id=3 bits_offset=8 Member exceeds struct_size libbpf: Error loading .BTF into kernel: -22. ------------------------------------------------------------------ The related issue was previously fixed by the commit 9eea98497951 ("bpf: fix BTF verification of enums"). On the other hand, this series fixes this issue as well, and adds a selftest program for it. Changes in v2: - change an example in commit message based on Andrii's review - add a selftest program for packed "enum" type members in struct/union ==================== Acked-by: Andrii Nakryiko <andriin@fb.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-03-10selftests/bpf: Add test for the packed enum member in struct/unionYoshiki Komachi
Add a simple test to the existing selftest program in order to make sure that a packed enum member in struct unexceeds the struct_size. Signed-off-by: Yoshiki Komachi <komachi.yoshiki@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/1583825550-18606-3-git-send-email-komachi.yoshiki@gmail.com
2020-03-10bpf/btf: Fix BTF verification of enum members in struct/unionYoshiki Komachi
btf_enum_check_member() was currently sure to recognize the size of "enum" type members in struct/union as the size of "int" even if its size was packed. This patch fixes BTF enum verification to use the correct size of member in BPF programs. Fixes: 179cde8cef7e ("bpf: btf: Check members of struct/union") Signed-off-by: Yoshiki Komachi <komachi.yoshiki@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/1583825550-18606-2-git-send-email-komachi.yoshiki@gmail.com
2020-03-10usb: xhci: apply XHCI_SUSPEND_DELAY to AMD XHCI controller 1022:145cAlberto Mattea
This controller timeouts during suspend (S3) with [ 240.521724] xhci_hcd 0000:30:00.3: WARN: xHC save state timeout [ 240.521729] xhci_hcd 0000:30:00.3: ERROR mismatched command completion event thus preventing the system from entering S3. Moreover it remains in an undefined state where some connected devices stop working until a reboot. Apply the XHCI_SUSPEND_DELAY quirk to make it suspend properly. CC: stable@vger.kernel.org Signed-off-by: Alberto Mattea <alberto@mattea.info> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200306150858.21904-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-10xhci: Do not open code __print_symbolic() in xhci trace eventsSteven Rostedt (VMware)
libtraceevent (used by perf and trace-cmd) failed to parse the xhci_urb_dequeue trace event. This is because the user space trace event format parsing is not a full C compiler. It can handle some basic logic, but is not meant to be able to handle everything C can do. In cases where a trace event field needs to be converted from a number to a string, there's the __print_symbolic() macro that should be used: See samples/trace_events/trace-events-sample.h Some xhci trace events open coded the __print_symbolic() causing the user spaces tools to fail to parse it. This has to be replaced with __print_symbolic() instead. CC: stable@vger.kernel.org Reported-by: Tzvetomir Stoyanov <tstoyanov@vmware.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206531 Fixes: 5abdc2e6e12ff ("usb: host: xhci: add urb_enqueue/dequeue/giveback tracers") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200306150858.21904-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-10Merge tag 'thunderbolt-fix-for-v5.6-rc6' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus Mika writes: thunderbolt: Fix for v5.6-rc6 This includes a single commit that fixes incorrect return value from tb_port_is_width_supported() if the read fails. * tag 'thunderbolt-fix-for-v5.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Fix error code in tb_port_is_width_supported()
2020-03-10Merge branch 'fix-lcdc-quirk' into fixesTony Lindgren
2020-03-10workqueue: don't use wq_select_unbound_cpu() for bound worksHillf Danton
wq_select_unbound_cpu() is designed for unbound workqueues only, but it's wrongly called when using a bound workqueue too. Fixing this ensures work queued to a bound workqueue with cpu=WORK_CPU_UNBOUND always runs on the local CPU. Before, that would happen only if wq_unbound_cpumask happened to include it (likely almost always the case), or was empty, or we got lucky with forced round-robin placement. So restricting /sys/devices/virtual/workqueue/cpumask to a small subset of a machine's CPUs would cause some bound work items to run unexpectedly there. Fixes: ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs") Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Hillf Danton <hdanton@sina.com> [dj: massage changelog] Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Tejun Heo <tj@kernel.org> Cc: Lai Jiangshan <jiangshanlai@gmail.com> Cc: linux-kernel@vger.kernel.org Signed-off-by: Tejun Heo <tj@kernel.org>
2020-03-10MAINTAINERS: update web URL for iwlwifiLuca Coelho
The current URL mentioned in iwlwifi's W entry is outdated and currently pointing to a dead link. Change it so that it points to the correct Wiki page directly. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-10Merge tag 'iwlwifi-for-kalle-2020-03-08' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes First batch of fixes intended for v5.6 * Fix a locking issue in time events handling; * A fix in rate-scaling; * Fix for a potential NULL pointer deref; * Enable antenna diversity in some devices that were erroneously not doing it; * Allow FW dumps to continue when the FW is stuck; * A fix in the HE capabilities handling; * Another fix for FW dumps where we were reading wrong addresses.
2020-03-10i2c: gpio: suppress error on probe deferHamish Martin
If a GPIO we are trying to use is not available and we are deferring the probe, don't output an error message. This seems to have been the intent of commit 05c74778858d ("i2c: gpio: Add support for named gpios in DT") but the error was still output due to not checking the updated 'retdesc'. Fixes: 05c74778858d ("i2c: gpio: Add support for named gpios in DT") Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2020-03-10macintosh: windfarm: fix MODINFO regressionWolfram Sang
Commit af503716ac14 made sure OF devices get an OF style modalias with I2C events. It assumed all in-tree users were converted, yet it missed some Macintosh drivers. Add an OF module device table for all windfarm drivers to make them automatically load again. Fixes: af503716ac14 ("i2c: core: report OF style module alias for devices registered via OF") Link: https://bugzilla.kernel.org/show_bug.cgi?id=199471 Reported-by: Erhard Furtner <erhard_f@mailbox.org> Tested-by: Erhard Furtner <erhard_f@mailbox.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org # v4.17+
2020-03-10drm/i915: Improve the start alignment of bonded pairsChris Wilson
Always wait on the start of the signaler request to reduce the problem of dequeueing the bonded pair too early -- we want both payloads to start at the same time, with no latency, and yet still allow others to make full use of the slack in the system. This reduce the amount of time we spend waiting on the semaphore used to synchronise the start of the bonded payload. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306133852.3420322-3-chris@chris-wilson.co.uk
2020-03-10drm/mm: Remove redundant assignment in drm_mm_reserve_nodeAkeem G Abodunrin
In Pete Goodliffe words, "You can improve a system by adding new code. You can also improve a system by removing code" - In this case, commit "202b52b7fbf70" added new code to initialize end of the node. So, there is no need for duplicated initialization, and this patch simply removes it. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200309151156.25040-1-akeem.g.abodunrin@intel.com
2020-03-10drm/meson: Add YUV420 output supportNeil Armstrong
This patch adds support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. In addition if pixel stream down-sampling, the Y Cb Cr components must also be mapped differently to align with the HDMI2.0 specifications. This mode needs a different clock generation scheme since the TMDS PHY clock must match the 10x ratio with the YUV420 pixel clock, but the video encoder must run at 2x the pixel clock. This patch enables the bridge bus format negociation, and handles the YUV420 case if selected by the negociation. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-12-narmstrong@baylibre.com
2020-03-10drm/meson: vclk: add support for YUV420 setupNeil Armstrong
This patch adds clocking support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. This mode needs a different clock generation scheme since the TMDS PHY clock must match the 10x ratio with the YUV420 pixel clock, but the video encoder must run at 2x the pixel clock. This patch adds the TMDS PHY clock value in all the video clock setup in order to better support these specific uses cases and switch to the Common Clock framework for clocks handling in the future. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-11-narmstrong@baylibre.com
2020-03-10drm/meson: venc: add support for YUV420 setupNeil Armstrong
This patch adds encoding support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. In addition if pixel stream down-sampling, the Y Cb Cr components must also be mapped differently to align with the HDMI2.0 specifications. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-10-narmstrong@baylibre.com
2020-03-10drm/meson: dw-hdmi: stop enforcing input_bus_formatNeil Armstrong
To allow using formats from negotiation, stop enforcing input_bus_format in the private dw-plat-data struct. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-9-narmstrong@baylibre.com
2020-03-10drm/meson: meson_dw_hdmi: add bridge and switch to drm_bridge_funcsNeil Armstrong
Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local bridge, connecting it to the dw-hdmi bridge, then implement the atomic_get_input_bus_fmts/atomic_get_output_bus_fmts. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-8-narmstrong@baylibre.com
2020-03-10drm/meson: venc: make drm_display_mode constNeil Armstrong
Before switching to bridge funcs, make sure drm_display_mode is passed as const to the venc functions. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-7-narmstrong@baylibre.com
2020-03-10drm/bridge: synopsys: dw-hdmi: allow ycbcr420 modes for >= 0x200aNeil Armstrong
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support for these modes in the connector if the platform supports them. We limit these modes to DW-HDMI IP version >= 0x200a which are designed to support HDMI2.0 display modes. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-6-narmstrong@baylibre.com
2020-03-10drm/bridge: synopsys: dw-hdmi: add bus format negociationNeil Armstrong
Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate the possible output and input formats for the current mode and monitor, and use the negotiated formats in a basic atomic_check callback. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-5-narmstrong@baylibre.com
2020-03-10drm/bridge: dw-hdmi: Plug atomic state hooks to the default implementationNeil Armstrong
Add atomic_duplicate_state/atomic_destroy_state/atomic_reset bridge funcs to allow setup of atomic bridge state. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-4-narmstrong@baylibre.com
2020-03-10drm/bridge: dw-hdmi: add max bpc connector propertyJonas Karlman
Add the max_bpc property to the dw-hdmi connector to prepare support for 10, 12 & 16bit output support. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-3-narmstrong@baylibre.com
2020-03-10drm/bridge: dw-hdmi: set mtmdsclock for deep colorJonas Karlman
Configure the correct mtmdsclock for deep colors to prepare support for 10, 12 & 16bit output. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-2-narmstrong@baylibre.com
2020-03-10i2c: designware-pci: Fix BUG_ON during device removalJarkko Nikula
Function i2c_dw_pci_remove() -> pci_free_irq_vectors() -> pci_disable_msi() -> free_msi_irqs() will throw a BUG_ON() for MSI enabled device since the driver has not released the requested IRQ before calling the pci_free_irq_vectors(). Here driver requests an IRQ using devm_request_irq() but automatic release happens only after remove callback. Fix this by explicitly freeing the IRQ before calling pci_free_irq_vectors(). Fixes: 21aa3983d619 ("i2c: designware-pci: Switch over to MSI interrupts") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2020-03-10iommu/vt-d: Silence RCU-list debugging warningsQian Cai
Similar to the commit 02d715b4a818 ("iommu/vt-d: Fix RCU list debugging warnings"), there are several other places that call list_for_each_entry_rcu() outside of an RCU read side critical section but with dmar_global_lock held. Silence those false positives as well. drivers/iommu/intel-iommu.c:4288 RCU-list traversed in non-reader section!! 1 lock held by swapper/0/1: #0: ffffffff935892c8 (dmar_global_lock){+.+.}, at: intel_iommu_init+0x1ad/0xb97 drivers/iommu/dmar.c:366 RCU-list traversed in non-reader section!! 1 lock held by swapper/0/1: #0: ffffffff935892c8 (dmar_global_lock){+.+.}, at: intel_iommu_init+0x125/0xb97 drivers/iommu/intel-iommu.c:5057 RCU-list traversed in non-reader section!! 1 lock held by swapper/0/1: #0: ffffffffa71892c8 (dmar_global_lock){++++}, at: intel_iommu_init+0x61a/0xb13 Signed-off-by: Qian Cai <cai@lca.pw> Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-03-10iommu/vt-d: Fix RCU-list bugs in intel_iommu_init()Qian Cai
There are several places traverse RCU-list without holding any lock in intel_iommu_init(). Fix them by acquiring dmar_global_lock. WARNING: suspicious RCU usage ----------------------------- drivers/iommu/intel-iommu.c:5216 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by swapper/0/1. Call Trace: dump_stack+0xa0/0xea lockdep_rcu_suspicious+0x102/0x10b intel_iommu_init+0x947/0xb13 pci_iommu_init+0x26/0x62 do_one_initcall+0xfe/0x500 kernel_init_freeable+0x45a/0x4f8 kernel_init+0x11/0x139 ret_from_fork+0x3a/0x50 DMAR: Intel(R) Virtualization Technology for Directed I/O Fixes: d8190dc63886 ("iommu/vt-d: Enable DMA remapping after rmrr mapped") Signed-off-by: Qian Cai <cai@lca.pw> Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-03-10i2c: i801: Do not add ICH_RES_IO_SMI for the iTCO_wdt deviceMika Westerberg
Martin noticed that nct6775 driver does not load properly on his system in v5.4+ kernels. The issue was bisected to commit b84398d6d7f9 ("i2c: i801: Use iTCO version 6 in Cannon Lake PCH and beyond") but it is likely not the culprit because the faulty code has been in the driver already since commit 9424693035a5 ("i2c: i801: Create iTCO device on newer Intel PCHs"). So more likely some commit that added PCI IDs of recent chipsets made the driver to create the iTCO_wdt device on Martins system. The issue was debugged to be PCI configuration access to the PMC device that is not present. This returns all 1's when read and this caused the iTCO_wdt driver to accidentally request resourses used by nct6775. It turns out that the SMI resource is only required for some ancient systems, not the ones supported by this driver. For this reason do not populate the SMI resource at all and drop all the related code. The driver now always populates the main I/O resource and only in case of SPT (Intel Sunrisepoint) compatible devices it adds another resource for the NO_REBOOT bit. These two resources are of different types so platform_get_resource() used by the iTCO_wdt driver continues to find the both resources at index 0. Link: https://lore.kernel.org/linux-hwmon/CAM1AHpQ4196tyD=HhBu-2donSsuogabkfP03v1YF26Q7_BgvgA@mail.gmail.com/ Fixes: 9424693035a5 ("i2c: i801: Create iTCO device on newer Intel PCHs") [wsa: complete fix needs all of http://patchwork.ozlabs.org/project/linux-i2c/list/?series=160959&state=*] Reported-by: Martin Volf <martin.volf.42@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2020-03-10watchdog: iTCO_wdt: Make ICH_RES_IO_SMI optionalMika Westerberg
The iTCO_wdt driver only needs ICH_RES_IO_SMI I/O resource when either turn_SMI_watchdog_clear_off module parameter is set to match ->iTCO_version (or higher), and when legacy iTCO_vendorsupport is set. Modify the driver so that ICH_RES_IO_SMI is optional if the two conditions are not met. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2020-03-10watchdog: iTCO_wdt: Export vendorsupportMika Westerberg
In preparation for making ->smi_res optional the iTCO_wdt driver needs to know whether vendorsupport is being set to non-zero. For this reason export the variable. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2020-03-10Merge tag 'gvt-fixes-2020-03-10' of https://github.com/intel/gvt-linux into ↵Jani Nikula
drm-intel-fixes gvt-fixes-2020-03-10 - Fix vgpu idr destroy causing timer destroy failure (Zhenyu) - Fix VBT size (Tina) Signed-off-by: Jani Nikula <jani.nikula@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310080933.GE28483@zhen-hp.sh.intel.com
2020-03-10Merge tag 'linux-cpupower-5.6-rc6' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux Pull cpupower utility fix for v5.6 from Shuah Khan: "This cpupower update for Linux 5.6-rc6 consists of a fix from Mike Gilbert for build failures when -fno-common is enabled. -fno-common will be default in gcc v10." * tag 'linux-cpupower-5.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux: cpupower: avoid multiple definition with gcc -fno-common
2020-03-10tee: amdtee: out of bounds read in find_session()Dan Carpenter
The "index" is a user provided value from 0-USHRT_MAX. If it's over TEE_NUM_SESSIONS (31) then it results in an out of bounds read when we call test_bit(index, sess->sess_mask). Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Acked-by: Rijo Thomas <Rijo-john.Thomas@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2020-03-10drm/exynos: Fix cleanup of IOMMU related objectsMarek Szyprowski
Store the IOMMU mapping created by the device core of each Exynos DRM sub-device and restore it when the Exynos DRM driver is unbound. This fixes IOMMU initialization failure for the second time when a deferred probe is triggered from the bind() callback of master's compound DRM driver. This also fixes the following issue found using kmemleak detector: unreferenced object 0xc2137640 (size 64): comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s) hex dump (first 32 bytes): 50 a3 14 c2 80 a2 14 c2 01 00 00 00 20 00 00 00 P........... ... 00 10 00 00 00 80 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<3acd268d>] arch_setup_dma_ops+0x4c/0x104 [<9f7d2cce>] of_dma_configure+0x19c/0x3a4 [<ba07704b>] really_probe+0xb0/0x47c [<4f510e4f>] driver_probe_device+0x78/0x1c4 [<7481a0cf>] device_driver_attach+0x58/0x60 [<0ff8f5c1>] __driver_attach+0xb8/0x158 [<86006144>] bus_for_each_dev+0x74/0xb4 [<10159dca>] bus_add_driver+0x1c0/0x200 [<8a265265>] driver_register+0x74/0x108 [<e0f3451a>] exynos_drm_init+0xb0/0x134 [<db3fc7ba>] do_one_initcall+0x90/0x458 [<6da35917>] kernel_init_freeable+0x188/0x200 [<db3f74d4>] kernel_init+0x8/0x110 [<1f3cddf9>] ret_from_fork+0x14/0x20 [<8cd12507>] 0x0 unreferenced object 0xc214a280 (size 128): comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s) hex dump (first 32 bytes): 00 a0 ec ed 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<3acd268d>] arch_setup_dma_ops+0x4c/0x104 [<9f7d2cce>] of_dma_configure+0x19c/0x3a4 [<ba07704b>] really_probe+0xb0/0x47c [<4f510e4f>] driver_probe_device+0x78/0x1c4 [<7481a0cf>] device_driver_attach+0x58/0x60 [<0ff8f5c1>] __driver_attach+0xb8/0x158 [<86006144>] bus_for_each_dev+0x74/0xb4 [<10159dca>] bus_add_driver+0x1c0/0x200 [<8a265265>] driver_register+0x74/0x108 [<e0f3451a>] exynos_drm_init+0xb0/0x134 [<db3fc7ba>] do_one_initcall+0x90/0x458 [<6da35917>] kernel_init_freeable+0x188/0x200 [<db3f74d4>] kernel_init+0x8/0x110 [<1f3cddf9>] ret_from_fork+0x14/0x20 [<8cd12507>] 0x0 unreferenced object 0xedeca000 (size 4096): comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<3acd268d>] arch_setup_dma_ops+0x4c/0x104 [<9f7d2cce>] of_dma_configure+0x19c/0x3a4 [<ba07704b>] really_probe+0xb0/0x47c [<4f510e4f>] driver_probe_device+0x78/0x1c4 [<7481a0cf>] device_driver_attach+0x58/0x60 [<0ff8f5c1>] __driver_attach+0xb8/0x158 [<86006144>] bus_for_each_dev+0x74/0xb4 [<10159dca>] bus_add_driver+0x1c0/0x200 [<8a265265>] driver_register+0x74/0x108 [<e0f3451a>] exynos_drm_init+0xb0/0x134 [<db3fc7ba>] do_one_initcall+0x90/0x458 [<6da35917>] kernel_init_freeable+0x188/0x200 [<db3f74d4>] kernel_init+0x8/0x110 [<1f3cddf9>] ret_from_fork+0x14/0x20 [<8cd12507>] 0x0 unreferenced object 0xc214a300 (size 128): comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s) hex dump (first 32 bytes): 00 a3 14 c2 00 a3 14 c2 00 40 18 c2 00 80 18 c2 .........@...... 02 00 02 00 ad 4e ad de ff ff ff ff ff ff ff ff .....N.......... backtrace: [<08cbd8bc>] iommu_domain_alloc+0x24/0x50 [<b835abee>] arm_iommu_create_mapping+0xe4/0x134 [<3acd268d>] arch_setup_dma_ops+0x4c/0x104 [<9f7d2cce>] of_dma_configure+0x19c/0x3a4 [<ba07704b>] really_probe+0xb0/0x47c [<4f510e4f>] driver_probe_device+0x78/0x1c4 [<7481a0cf>] device_driver_attach+0x58/0x60 [<0ff8f5c1>] __driver_attach+0xb8/0x158 [<86006144>] bus_for_each_dev+0x74/0xb4 [<10159dca>] bus_add_driver+0x1c0/0x200 [<8a265265>] driver_register+0x74/0x108 [<e0f3451a>] exynos_drm_init+0xb0/0x134 [<db3fc7ba>] do_one_initcall+0x90/0x458 [<6da35917>] kernel_init_freeable+0x188/0x200 [<db3f74d4>] kernel_init+0x8/0x110 [<1f3cddf9>] ret_from_fork+0x14/0x20 Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>