aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-04-10drm/amdgpu: gfx use amdgpu_ras_feature_enable_on_bootxinhui pan1-2/+2
handle ras enable on boot. Signed-off-by: xinhui pan <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-10drm/amdgpu: Introduce another ras enable functionxinhui pan2-0/+30
Many parts of the whole SW stack can program the ras enablement state during the boot. Now we handle that case by adding one function which check the ras flags and choose different code path. Reviewed-by: Evan Quan <[email protected]> Signed-off-by: xinhui pan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-10drm/amdgpu: Make default ras error type to nonexinhui pan1-9/+15
Unless IP has implemented its own ras, use ERROR_NONE as the default type. Signed-off-by: xinhui pan <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-10drm/amd/powerplay: simplify the code of [get|set]_activity_monitor_coeffKevin Wang2-74/+7
use smu_update_table_with_arg to replace old code logic Signed-off-by: Kevin Wang <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-10drm/amd/powerplay: optimization function of smu_update_tableKevin Wang2-3/+9
in fact, the firmware need 2 parameter: 1.table_id, 2.XferArg so change the function interface to match the firmware code Signed-off-by: Kevin Wang <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-10lightnvm: pblk: fix crash in pblk_end_partial_read due to multipage bvecsHans Holmberg1-22/+28
The introduction of multipage bio vectors broke pblk's partial read logic due to it not being prepared for multipage bio vectors. Use bio vector iterators instead of direct bio vector indexing. Fixes: 07173c3ec276 ("block: enable multipage bvecs") Reported-by: Klaus Jensen <[email protected]> Signed-off-by: Hans Holmberg <[email protected]> Updated description. Signed-off-by: Matias Bjørling <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10IB/hfi1: Do not flush send queue in the TID RDMA second legKaike Wan1-23/+8
When a QP is put into error state, the send queue will be flushed. This mechanism is implemented in both the first and the second leg of the send engine. Since the second leg is only responsible for data transactions in the KDETH space for the TID RDMA WRITE request, it should not perform the flushing of the send queue. This patch removes the flushing function of the second leg, but still keeps the bailing out of the QP if it is put into error state. Fixes: 70dcb2e3dc6a ("IB/hfi1: Add the TID second leg send packet builder") Reviewed-by: Mike Marciniszyn <[email protected]> Signed-off-by: Kaike Wan <[email protected]> Signed-off-by: Dennis Dalessandro <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-04-10Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds4-5/+22
Pull virtio fixes from Michael Tsirkin: "Several fixes, add more reviewers to the list" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: virtio: Honour 'may_reduce_num' in vring_create_virtqueue MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi virtio_pci: fix a NULL pointer reference in vp_del_vqs
2019-04-10ASoC: wcd9335: Fix missing regmap requirementMarc Gonzalez1-0/+1
wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip' Signed-off-by: Marc Gonzalez <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-04-10drm/i915/dp: revert back to max link rate and lane count on eDPJani Nikula1-59/+10
Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow") started to optize the eDP 1.4+ link config, both per spec and as preparation for display stream compression support. Sadly, we again face panels that flat out fail with parameters they claim to support. Revert, and go back to the drawing board. v2: Actually revert to max params instead of just wide-and-slow. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959 Fixes: 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow") Cc: Ville Syrjälä <[email protected]> Cc: Manasi Navare <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Matt Atwood <[email protected]> Cc: "Lee, Shawn C" <[email protected]> Cc: Dave Airlie <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.0+ Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Manasi Navare <[email protected]> Tested-by: Albert Astals Cid <[email protected]> # v5.0 backport Tested-by: Emanuele Panigati <[email protected]> # v5.0 backport Tested-by: Matteo Iervasi <[email protected]> # v5.0 backport Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f11cb1c19ad0563b3c1ea5eb16a6bac0e401f428) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-04-10drm/i915/icl: Fix port disable sequence for mipi-dsiVandita Kulkarni2-4/+4
Re-enable clock gating of DDI clocks. v2: Fix the default ddi clk state for mipi-dsi (Imre) Fixes: 1026bea00381 ("drm/i915/icl: Ungate DSI clocks") Signed-off-by: Vandita Kulkarni <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 942d1cf48eae3fcd7e973cfb708d5c4860f0c713) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-04-10drm/i915/icl: Ungate ddi clocks before IO enableVandita Kulkarni1-0/+6
IO enable sequencing needs ddi clocks enabled. These clocks will be gated at a later point in the enable sequence. v2: Fix the commit header (Uma) v3: Remove the redundant read (Ville) Fixes: 949fc52af19e ("drm/i915/icl: add pll mapping for DSI") Signed-off-by: Vandita Kulkarni <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit c5b81a325263a891d5811aabe938c87e03db4c37) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-04-10nvme: cancel request synchronouslyMing Lei1-1/+1
nvme_cancel_request() is used in error handler, and it is always reliable to cancel request synchronously, and avoids possible race in which request may be completed after real hw queue is destroyed. One issue is reported by our customer on NVMe RDMA, in which freed ib queue pair may be used in nvme_rdma_complete_rq(). Cc: Sagi Grimberg <[email protected]> Cc: Bart Van Assche <[email protected]> Cc: James Smart <[email protected]> Cc: [email protected] Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10blk-mq: introduce blk_mq_complete_request_sync()Ming Lei2-0/+8
In NVMe's error handler, follows the typical steps of tearing down hardware for recovering controller: 1) stop blk_mq hw queues 2) stop the real hw queues 3) cancel in-flight requests via blk_mq_tagset_busy_iter(tags, cancel_request, ...) cancel_request(): mark the request as abort blk_mq_complete_request(req); 4) destroy real hw queues However, there may be race between #3 and #4, because blk_mq_complete_request() may run q->mq_ops->complete(rq) remotelly and asynchronously, and ->complete(rq) may be run after #4. This patch introduces blk_mq_complete_request_sync() for fixing the above race. Cc: Sagi Grimberg <[email protected]> Cc: Bart Van Assche <[email protected]> Cc: James Smart <[email protected]> Cc: [email protected] Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10scsi: virtio_scsi: limit number of hw queues by nr_cpu_idsDongli Zhang1-0/+1
When tag_set->nr_maps is 1, the block layer limits the number of hw queues by nr_cpu_ids. No matter how many hw queues are used by virtio-scsi, as it has (tag_set->nr_maps == 1), it can use at most nr_cpu_ids hw queues. In addition, specifically for pci scenario, when the 'num_queues' specified by qemu is more than maxcpus, virtio-scsi would not be able to allocate more than maxcpus vectors in order to have a vector for each queue. As a result, it falls back into MSI-X with one vector for config and one shared for queues. Considering above reasons, this patch limits the number of hw queues used by virtio-scsi by nr_cpu_ids. Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Dongli Zhang <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10virtio-blk: limit number of hw queues by nr_cpu_idsDongli Zhang1-0/+2
When tag_set->nr_maps is 1, the block layer limits the number of hw queues by nr_cpu_ids. No matter how many hw queues are used by virtio-blk, as it has (tag_set->nr_maps == 1), it can use at most nr_cpu_ids hw queues. In addition, specifically for pci scenario, when the 'num-queues' specified by qemu is more than maxcpus, virtio-blk would not be able to allocate more than maxcpus vectors in order to have a vector for each queue. As a result, it falls back into MSI-X with one vector for config and one shared for queues. Considering above reasons, this patch limits the number of hw queues used by virtio-blk by nr_cpu_ids. Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Dongli Zhang <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10block, bfq: fix use after free in bfq_bfqq_expirePaolo Valente3-11/+23
The function bfq_bfqq_expire() invokes the function __bfq_bfqq_expire(), and the latter may free the in-service bfq-queue. If this happens, then no other instruction of bfq_bfqq_expire() must be executed, or a use-after-free will occur. Basing on the assumption that __bfq_bfqq_expire() invokes bfq_put_queue() on the in-service bfq-queue exactly once, the queue is assumed to be freed if its refcounter is equal to one right before invoking __bfq_bfqq_expire(). But, since commit 9dee8b3b057e ("block, bfq: fix queue removal from weights tree") this assumption is false. __bfq_bfqq_expire() may also invoke bfq_weights_tree_remove() and, since commit 9dee8b3b057e ("block, bfq: fix queue removal from weights tree"), also the latter function may invoke bfq_put_queue(). So __bfq_bfqq_expire() may invoke bfq_put_queue() twice, and this is the actual case where the in-service queue may happen to be freed. To address this issue, this commit moves the check on the refcounter of the queue right around the last bfq_put_queue() that may be invoked on the queue. Fixes: 9dee8b3b057e ("block, bfq: fix queue removal from weights tree") Reported-by: Dmitrii Tcvetkov <[email protected]> Reported-by: Douglas Anderson <[email protected]> Tested-by: Dmitrii Tcvetkov <[email protected]> Tested-by: Douglas Anderson <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-10ALSA: hda: Fix racy display power accessTakashi Iwai3-2/+6
snd_hdac_display_power() doesn't handle the concurrent calls carefully enough, and it may lead to the doubly get_power or put_power calls, when a runtime PM and an async work get called in racy way. This patch addresses it by reusing the bus->lock mutex that has been used for protecting the link state change in ext bus code, so that it can protect against racy display state changes. The initialization of bus->lock was moved from snd_hdac_ext_bus_init() to snd_hdac_bus_init() as well accordingly. Testcase: igt/i915_pm_rpm/module-reload #glk-dsi Reported-by: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: Imre Deak <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-04-10alarmtimer: Return correct remaining timeAndrei Vagin1-1/+1
To calculate a remaining time, it's required to subtract the current time from the expiration time. In alarm_timer_remaining() the arguments of ktime_sub are swapped. Fixes: d653d8457c76 ("alarmtimer: Implement remaining callback") Signed-off-by: Andrei Vagin <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: John Stultz <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-04-10locking/lockdep: Zap lock classes even with lock debugging disabledBart Van Assche1-17/+12
The following commit: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use") changed the behavior of lockdep_free_key_range() from unconditionally zapping lock classes into only zapping lock classes if debug_lock == true. Not zapping lock classes if debug_lock == false leaves dangling pointers in several lockdep datastructures, e.g. lock_class::name in the all_lock_classes list. The shell command "cat /proc/lockdep" causes the kernel to iterate the all_lock_classes list. Hence the "unable to handle kernel paging request" cash that Shenghui encountered by running cat /proc/lockdep. Since the new behavior can cause cat /proc/lockdep to crash, restore the pre-v5.1 behavior. This patch avoids that cat /proc/lockdep triggers the following crash with debug_lock == false: BUG: unable to handle kernel paging request at fffffbfff40ca448 RIP: 0010:__asan_load1+0x28/0x50 Call Trace: string+0xac/0x180 vsnprintf+0x23e/0x820 seq_vprintf+0x82/0xc0 seq_printf+0x92/0xb0 print_name+0x34/0xb0 l_show+0x184/0x200 seq_read+0x59e/0x6c0 proc_reg_read+0x11f/0x170 __vfs_read+0x4d/0x90 vfs_read+0xc5/0x1f0 ksys_read+0xab/0x130 __x64_sys_read+0x43/0x50 do_syscall_64+0x71/0x210 entry_SYSCALL_64_after_hwframe+0x49/0xbe Reported-by: shenghui <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Waiman Long <[email protected]> Cc: Will Deacon <[email protected]> Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use") # v5.1-rc1. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-04-10ASoC: pcm: fix error handling when try_module_get() fails.Ranjani Sridharan1-3/+5
Handle error before returning when try_module_get() fails to prevent inconsistent mutex lock/unlock. Fixes: 52034add7 (ASoC: pcm: update module refcount if module_get_upon_open is set) Signed-off-by: Ranjani Sridharan <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-04-10apparmor: Restore Y/N in /sys for apparmor's "enabled"Kees Cook1-1/+48
Before commit c5459b829b71 ("LSM: Plumb visibility into optional "enabled" state"), /sys/module/apparmor/parameters/enabled would show "Y" or "N" since it was using the "bool" handler. After being changed to "int", this switched to "1" or "0", breaking the userspace AppArmor detection of dbus-broker. This restores the Y/N output while keeping the LSM infrastructure happy. Before: $ cat /sys/module/apparmor/parameters/enabled 1 After: $ cat /sys/module/apparmor/parameters/enabled Y Reported-by: David Rheinsberg <[email protected]> Reviewed-by: David Rheinsberg <[email protected]> Link: https://lkml.kernel.org/r/CADyDSO6k8vYb1eryT4g6+EHrLCvb68GAbHVWuULkYjcZcYNhhw@mail.gmail.com Fixes: c5459b829b71 ("LSM: Plumb visibility into optional "enabled" state") Signed-off-by: Kees Cook <[email protected]> Signed-off-by: John Johansen <[email protected]>
2019-04-10ASoC: stm32: sai: fix master clock managementOlivier Moysan1-17/+47
When master clock is used, master clock rate is set exclusively. Parent clocks of master clock cannot be changed after a call to clk_set_rate_exclusive(). So the parent clock of SAI kernel clock must be set before. Ensure also that exclusive rate operations are balanced in STM32 SAI driver. Signed-off-by: Olivier Moysan <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-04-10ASoC: Intel: kbl: fix wrong number of channelsTzung-Bi Shih1-1/+1
Fix wrong setting on number of channels. The context wants to set constraint to 2 channels instead of 4. Signed-off-by: Tzung-Bi Shih <[email protected]> Acked-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-04-10x86/perf/amd: Remove need to check "running" bit in NMI handlerLendacky, Thomas2-12/+22
Spurious interrupt support was added to perf in the following commit, almost a decade ago: 63e6be6d98e1 ("perf, x86: Catch spurious interrupts after disabling counters") The two previous patches (resolving the race condition when disabling a PMC and NMI latency mitigation) allow for the removal of this older spurious interrupt support. Currently in x86_pmu_stop(), the bit for the PMC in the active_mask bitmap is cleared before disabling the PMC, which sets up a race condition. This race condition was mitigated by introducing the running bitmap. That race condition can be eliminated by first disabling the PMC, waiting for PMC reset on overflow and then clearing the bit for the PMC in the active_mask bitmap. The NMI handler will not re-enable a disabled counter. If x86_pmu_stop() is called from the perf NMI handler, the NMI latency mitigation support will guard against any unhandled NMI messages. Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: <[email protected]> # 4.14.x- Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Link: https://lkml.kernel.org/r/Message-ID: Signed-off-by: Ingo Molnar <[email protected]>
2019-04-10powerpc/mm: Define MAX_PHYSMEM_BITS for all 64-bit configsMichael Ellerman1-1/+1
The recent commit 8bc086899816 ("powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations") removed our definition of MAX_PHYSMEM_BITS when SPARSEMEM is disabled. This inadvertently broke some 64-bit FLATMEM using configs with eg: arch/powerpc/include/asm/book3s/64/mmu-hash.h:584:6: error: "MAX_PHYSMEM_BITS" is not defined, evaluates to 0 #if (MAX_PHYSMEM_BITS > MAX_EA_BITS_PER_CONTEXT) ^~~~~~~~~~~~~~~~ Fix it by making sure we define MAX_PHYSMEM_BITS for all 64-bit configs regardless of SPARSEMEM. Fixes: 8bc086899816 ("powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations") Reported-by: Andreas Schwab <[email protected]> Reported-by: Hugh Dickins <[email protected]> Reviewed-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-04-09Bluetooth: btusb: request wake pin with NOAUTOENBrian Norris1-1/+1
Badly-designed systems might have (for example) active-high wake pins that default to high (e.g., because of external pull ups) until they have an active firmware which starts driving it low. This can cause an interrupt storm in the time between request_irq() and disable_irq(). We don't support shared interrupts here, so let's just pre-configure the interrupt to avoid auto-enabling it. Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support") Fixes: 5364a0b4f4be ("arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node") Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-09Merge tag 'mips_fixes_5.1_2' of ↵Linus Torvalds3-3/+11
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fixes from Paul Burton: "A few minor MIPS fixes: - Provide struct pt_regs * from get_irq_regs() to kgdb_nmicallback() when handling an IPI triggered by kgdb_roundup_cpus(), matching the behavior of other architectures & resolving kgdb issues for SMP systems. - Defer a pointer dereference until after a NULL check in the irq_shutdown callback for SGI IP27 HUB interrupts. - A defconfig update for the MSCC Ocelot to enable some necessary drivers" * tag 'mips_fixes_5.1_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig MIPS: SGI-IP27: Fix use of unchecked pointer in shutdown_bridge_irq MIPS: KGDB: fix kgdb support for SMP platforms.
2019-04-09Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds2-2/+6
Pull misc fixes from Al Viro: "A few regression fixes from this cycle" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: aio: use kmem_cache_free() instead of kfree() iov_iter: Fix build error without CONFIG_CRYPTO aio: Fix an error code in __io_submit_one()
2019-04-09drm/lima: include used header file explicitlyQiang Yu1-0/+1
To prevent build fail on some platform which does not have it in the include file chain. Reviewed-by: Neil Armstrong <[email protected]> Suggested-by: Randy Dunlap <[email protected]> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/lima: add missing Kconfig dependencyQiang Yu1-0/+3
Current implementation does not support MMU-less plarforms. Suggested-by: Randy Dunlap <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/mediatek: no change parent rate in round_rate() for MT2701 hdmi phyWangyan Wang4-16/+20
This is the third step to make MT2701 HDMI stable. We should not change the rate of parent for hdmi phy when doing round_rate for this clock. The parent clock of hdmi phy must be the same as it. We change it when doing set_rate only. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09drm/mediatek: using new factor for tvdpll for MT2701 hdmi phyWangyan Wang1-5/+3
This is the second step to make MT2701 HDMI stable. The factor depends on the divider of DPI in MT2701, therefore, we should fix this factor to the right and new one. Test: search ok Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09drm/mediatek: remove flag CLK_SET_RATE_PARENT for MT2701 hdmi phyWangyan Wang4-8/+8
This is the first step to make MT2701 hdmi stable. The parent rate of hdmi phy had set by DPI driver. We should not set or change the parent rate of MT2701 hdmi phy, as a result we should remove the flags of "CLK_SET_RATE_PARENT" from the clock of MT2701 hdmi phy. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09drm/mediatek: make implementation of recalc_rate() for MT2701 hdmi phyWangyan Wang4-14/+42
Recalculate the rate of this clock, by querying hardware to make implementation of recalc_rate() to match the definition. Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09drm/meson: Add G12A support for the DW-HDMI GlueNeil Armstrong2-38/+157
The Amlogic G12A embeds the same Synopsys DW-HDMI Controller, but with : - a "backport" of the HDR signaling registers from more recent DW-HDMI controllers, this will need a tweak since it's not normally present on this version of the DW-HDMI controller - A direct mapping of TOP and DW-HDMI registers instead of an internal bus accessed using read/write registers - Support for RX-SENSE, but not yet implemented - Support for HDMI 2.1 Dynamic HDR, but not yet implemented - Different registers mapping for the HDMI PHY setup This patchs adds support for these changes while providing exact same support as the previous GXBB, GXL & GXM SoCs. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add G12A compatibleNeil Armstrong1-0/+1
Finally add the Amlogic G12A SoC compatible for the VPU driver. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add G12A Video Clock setupNeil Armstrong1-11/+108
While switching to the Common Clock Framework is still Work In Progress, this patch adds the corresponding G12A HDMI PLL setup to be on-par with the other SoCs support. The G12A has only a single tweak about the high frequency setup, where the HDMI PLL needs a specific setup to handle correctly the 5.94GHz DCO frequency. Apart that, it handls ecorrectly all the other HDMI frequencies and can achieve even better DMT clock frequency precision with the larger fractional dividier width. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add G12A support for CVBS EncoderNeil Armstrong2-9/+27
The Meson G12A SoCs uses the exact same CVBS encoder except a simple CVBS DAC register offset and settings delta. Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: fixed subject typo] Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add G12A support for plane handling in CRTC driverNeil Armstrong2-52/+221
This patch adds support for the new OSD+VD Plane blending module in the CRTC code by adding the G12A code to manage the blending module and setting the right OSD1 & VD1 plane registers. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add G12A Support for the Overlay video planeNeil Armstrong1-2/+8
Amlogic G12A SoC supports the same set of Video Planes, but now are handled by the new OSD plane blender module. This patch uses the same VD1 plane for G12A, using the exact same scaler and VD1 setup registers, except using the new blender register to disable the plane. Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: fix typo in commit log] Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add G12A support for OSD1 PlaneNeil Armstrong1-2/+13
Amlogic G12A SoC supports now up to 3 OSD planes (1 more than the previous SoCs) and a brand new OSD plane blender module. This patch uses the same OSD1 plane for G12A, using the exact same scaler and OSD1 setup registers, except using the new blender register to disable the plane. Signed-off-by: Neil Armstrong <[email protected]> [narmstrong: fixed typo in commit log] Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add G12A Support for VIU setupNeil Armstrong1-5/+67
Amlogic G12A SoC needs a different VIU setup code, handle it. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add G12A Support for VPP setupNeil Armstrong1-22/+29
Amlogic G12A needs a different VPP setup code, handle it here. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Add registers for G12A SoCNeil Armstrong1-0/+247
This patch adds the new VPU registers added since the Amlogic GXM SoCs. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/meson: Switch PLL to 5.94GHz base for 297Mhz pixel clockNeil Armstrong1-2/+2
On Amlogic G12A SoC, the 2,97GHz PLL frequency is not stable enough to provide a correct 297MHz pixel clock, so switch the PLL base frequency with a /2 OD when the 297MHz pixel clock is requested. This solves the issue on G12A and also works fine on GXBB, GXL & GXM. Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Jerome Brunet <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09drm/mediatek: fix the rate and divder of hdmi phy for MT2701Wangyan Wang1-2/+2
Due to a clerical error,there is one zero less for 12800000. Fix it for 128000000 Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623") Signed-off-by: Wangyan Wang <[email protected]> Signed-off-by: CK Hu <[email protected]>
2019-04-09dt-bindings: display: amlogic, meson-dw-hdmi: Add G12A compatible and portsNeil Armstrong1-0/+4
The Amlogic G12A SoC has a slighly modified DW-HDMI Glue with support for HDMI 2.1 and a different DW-HDMI register access. Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09dt-bindings: display: amlogic, meson-vpu: Add G12A compatible and portsNeil Armstrong1-0/+4
The Amlogic G12A VPU is very similar to the Amlogic GXM VPU but with : - an enhanced plane blender, with up to 3 OSD planes - support for AFBC 1.2 decoder (for Bifrost GPU) - support display mode up to 4k60@75Hz Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-09dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPUNeil Armstrong1-0/+92
Add the bindings for the Bifrost family of ARM Mali GPUs. The Bifrost GPU architecture is similar to the Midgard family, but with a different Shader Core & Execution Engine structures. Bindings are based on the Midgard family bindings, but the inner architectural changes makes it a separate family needing separate bindings. The Bifrost GPUs are present in a number of recent SoCs, like the Amlogic G12A Family, and many other vendors. The Amlogic vendor specific compatible is added to handle the specific IP integration differences and dependencies. Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Rob Herring <[email protected]> [narmstrong: fixed small typo in compatible description] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.