Lyude Paul [Thu, 25 Jul 2019 19:40:01 +0000 (15:40 -0400)]
drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUX
While I had thought I had fixed this issue in:
commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")
It turns out that while I did fix the error messages I was seeing on my
P50 when trying to access i2c busses with the GPU in runtime suspend, I
accidentally had missed one important detail that was mentioned on the
bug report this commit was supposed to fix: that the CPU would only lock
up when trying to access i2c busses _on connected devices_ _while the
GPU is not in runtime suspend_. Whoops. That definitely explains why I
was not able to get my machine to hang with i2c bus interactions until
now, as plugging my P50 into it's dock with an HDMI monitor connected
allowed me to finally reproduce this locally.
Now that I have managed to reproduce this issue properly, it looks like
the problem is much simpler then it looks. It turns out that some
connected devices, such as MST laptop docks, will actually ACK i2c reads
even if no data was actually read:
[ 275.063043] nouveau 0000:01:00.0: i2c: aux 000a: 1: 0000004c 1
[ 275.063447] nouveau 0000:01:00.0: i2c: aux 000a: 00 0110100010040000
[ 275.063759] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000001
[ 275.064024] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
[ 275.064285] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
[ 275.064594] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
Because we don't handle the situation of i2c ack without any data, we
end up entering an infinite loop in nvkm_i2c_aux_i2c_xfer() since the
value of cnt always remains at 0. This finally properly explains how
this could result in a CPU hang like the ones observed in the
aforementioned commit.
So, fix this by retrying transactions if no data is written or received,
and give up and fail the transaction if we continue to not write or
receive any data after 32 retries.
Yongxin Liu [Mon, 1 Jul 2019 01:46:22 +0000 (09:46 +0800)]
drm/nouveau: fix memory leak in nouveau_conn_reset()
In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomic_helper_connector_reset(),
where newly allocated asyc->state will be assigned to connector->state.
So using nouveau_conn_atomic_destroy_state() instead of
__drm_atomic_helper_connector_destroy_state to free the "old" asyc.
Ralph Campbell [Fri, 14 Jun 2019 20:20:03 +0000 (13:20 -0700)]
drm/nouveau/dmem: missing mutex_lock in error path
In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before
calling nouveau_dmem_chunk_alloc() as shown when CONFIG_PROVE_LOCKING
is enabled:
Ben Skeggs [Fri, 5 Jul 2019 05:11:42 +0000 (15:11 +1000)]
drm/nouveau: fix bogus GPL-2 license header
The bulk SPDX addition made all these files into GPL-2.0 licensed files.
However the remainder of the project is MIT-licensed, these files
were simply missing the boiler plate and got caught up in the global update.
Ilia Mirkin [Thu, 20 Jun 2019 00:13:43 +0000 (20:13 -0400)]
drm/nouveau: fix bogus GPL-2 license header
The bulk SPDX addition made all these files into GPL-2.0 licensed files.
However the remainder of the project is MIT-licensed, these files
(primarily header files) were simply missing the boiler plate and got
caught up in the global update.
Fixes: b24413180f5 (License cleanup: add SPDX GPL-2.0 license identifier to files with no license) Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Emil Velikov <[email protected]> Acked-by: Karol Herbst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
Lyude Paul [Wed, 26 Jun 2019 18:10:27 +0000 (14:10 -0400)]
drm/nouveau/i2c: Enable i2c pads & busses during preinit
It turns out that while disabling i2c bus access from software when the
GPU is suspended was a step in the right direction with:
commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")
We also ended up accidentally breaking the vbios init scripts on some
older Tesla GPUs, as apparently said scripts can actually use the i2c
bus. Since these scripts are executed before initializing any
subdevices, we end up failing to acquire access to the i2c bus which has
left a number of cards with their fan controllers uninitialized. Luckily
this doesn't break hardware - it just means the fan gets stuck at 100%.
This also means that we've always been using our i2c busses before
initializing them during the init scripts for older GPUs, we just didn't
notice it until we started preventing them from being used until init.
It's pretty impressive this never caused us any issues before!
So, fix this by initializing our i2c pad and busses during subdev
pre-init. We skip initializing aux busses during pre-init, as those are
guaranteed to only ever be used by nouveau for DP aux transactions.
Ben Skeggs [Mon, 17 Jun 2019 02:52:48 +0000 (12:52 +1000)]
drm/nouveau/core: recognise TU116 chipset
Modesetting only, still waiting on ACR/GR firmware from NVIDIA for Turing
graphics/compute bring-up.
Each subsystem was compared with traces, along with various tests to check
that things generally work as they should, and appears compatible enough
with the current TU117 code to enable support.
Ben Skeggs [Tue, 28 May 2019 23:58:18 +0000 (09:58 +1000)]
drm/nouveau/kms: disallow dual-link harder if hdmi connection detected
The fallthrough cases (pre-Fermi) would accidentally allow dual-link pixel
clocks even where they shouldn't be. This leads to a high resolution HDMI
displays, connected via a DVI->HDMI adapter, to fail on the original NV50.
Previously center scaling would get scaling applied to it (when it was
only supposed to center the image), and aspect-corrected scaling did not
always correctly pick whether to reduce width or height for a particular
combination of inputs/outputs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660 Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
Ilia Mirkin [Sat, 25 May 2019 22:41:48 +0000 (18:41 -0400)]
drm/nouveau/disp/nv50-: force scaler for any non-default LVDS/eDP modes
Higher layers tend to add a lot of modes not actually in the EDID, such
as the standard DMT modes. Changing this would be extremely intrusive to
everyone, so just force the scaler more often. There are no practical
cases we're aware of where a LVDS/eDP panel has multiple resolutions
exposed, and i915 already does it this way.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660 Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
The mm changes in there we premature and not fully ack or reviewed by core mm folks,
I dropped the ball by merging them via this tree, so lets take em all back out.
Dave Airlie [Mon, 15 Jul 2019 05:16:20 +0000 (15:16 +1000)]
mm: adjust apply_to_pfn_range interface for dropped token.
mm/pgtable: drop pgtable_t variable from pte_fn_t functions
drops the token came in via the hmm tree, this caused lots of
conflicts, but applying this cleanup patch should reduce it
to something easier to handle. Just accept the token is unused
at this point.
- Fix a saturation bit position in the colorspace converter
configuration memory.
- Fully describe colorspace conversions in the API to the imx-media driver.
- Add support for limited range and Rec.709 YUV encoding.
- Enable colorimetry configuration via the media-controller API.
- Enable the double write reduction feature for memory bandwidth savings
when the image converter writes YUV 4:2:0 output.
- Enable a scanout FIFO watermark feature that can increase priority of
scanout read transfers at the memory controller whenever the FIFO runs
low.
Dave Airlie [Thu, 11 Jul 2019 20:57:16 +0000 (06:57 +1000)]
Merge tag 'drm-next-5.3-2019-07-09' of git://people.freedesktop.org/~agd5f/linux into drm-next
drm-next-5.3-2019-07-09:
amdgpu:
- GPU reset for navi10
- Powerplay fixes for navi10
- GFX fixes for navi10
- Prepare for hmm_range_register API change
- XGMI fixes
- clang warning fixes
- Fixes for various kconfig scenarios
- Misc fixes and cleanups
amdkfd:
- Add workaround for soft hangs with oversubscribed runlists
- Remove duplicated pcie atomics request
Marek Olšák [Fri, 28 Jun 2019 22:31:26 +0000 (18:31 -0400)]
drm/amdgpu: don't invalidate caches in RELEASE_MEM, only do the writeback
This RELEASE_MEM use has the Release semantic, which means we should write
back but not invalidate. Invalidations only make sense with the Acquire
semantic (ACQUIRE_MEM), or when RELEASE_MEM is used to do the combined
Acquire-Release semantic, which is a barrier, not a fence.
The undesirable side effect of doing invalidations for the Release semantic
is that it invalidates caches while shaders are running, because the Release
can execute in the middle of the next IB.
UMDs should use ACQUIRE_MEM at the beginning of IBs. Doing cache
invalidations for a fence (like in this case) doesn't do anything
for correctness.
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4be ("drm/amd/display: Move link functions from dc to dc_link") Fixes: f18bc4e53ad6 ("drm/amd/display: update calculated bounding box logic for NV") Acked-by: Slava Abramov <[email protected]> Tested-by: Slava Abramov <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Without this header, we get a compiler error in some configurations:
.../dc/dcn20/dcn20_hwseq.c: In function 'dcn20_hwss_wait_for_blank_complete':
.../dc/dcn20/dcn20_hwseq.c:1493:3: error: implicit declaration of function 'udelay' [-Werror=implicit-function-declaration]
Note: the use of udelay itself may be problematic, as can occupy
the CPU for 200ms in a busy-loop here.
Fixes: 7ed4e6352c16 ("drm/amd/display: Add DCN2 HW Sequencer and Resource") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
When CONFIG_PERF_EVENTS is disabled, we cannot compile the pmu
portion of the amdgpu driver:
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:48:38: error: no member named 'hw' in 'struct perf_event'
struct hw_perf_event *hwc = &event->hw;
~~~~~ ^
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:51:13: error: no member named 'attr' in 'struct perf_event'
if (event->attr.type != event->pmu->type)
~~~~~ ^
...
drm/amd/powerplay: Zero initialize current_rpm in vega20_get_fan_speed_percent
clang warns (trimmed for brevity):
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:3023:8: warning:
variable 'current_rpm' is used uninitialized whenever '?:' condition is
false [-Wsometimes-uninitialized]
ret = smu_get_current_rpm(smu, ¤t_rpm);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
smu_get_current_rpm expands to a ternary operator conditional on
smu->funcs->get_current_rpm being not NULL. When this is false,
current_rpm will be uninitialized. Zero initialize current_rpm to
avoid using random stack values if that ever happens.
drm/amd/powerplay: Zero initialize freq in smu_v11_0_get_current_clk_freq
clang warns (trimmed for brevity):
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1098:10: warning:
variable 'freq' is used uninitialized whenever '?:' condition is false
[-Wsometimes-uninitialized]
ret = smu_get_current_clk_freq_by_table(smu, clk_id, &freq);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If get_current_clk_freq_by_table is ever NULL, freq will fail to be
properly initialized. Zero initialize it to avoid using uninitialized
stack values.
smu_get_current_clk_freq_by_table expands to a ternary operator
conditional on smu->funcs->get_current_clk_freq_by_table being not NULL.
When this is false, freq will be uninitialized. Zero initialize freq to
avoid using random stack values if that ever happens.
drm/amd/powerplay: Use memset to initialize metrics structs
clang warns:
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:601:33: warning:
suggest braces around initialization of subobject [-Wmissing-braces]
static SmuMetrics_t metrics = {0};
^
{}
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:905:26: warning:
suggest braces around initialization of subobject [-Wmissing-braces]
SmuMetrics_t metrics = {0};
^
{}
2 warnings generated.
One way to fix these warnings is to add additional braces like clang
suggests; however, there has been a bit of push back from some
maintainers[1][2], who just prefer memset as it is unambiguous, doesn't
depend on a particular compiler version[3], and properly initializes all
subobjects. Do that here so there are no more warnings.
Fixes: 98e1a543c7b1 ("drm/amd/powerplay: add function get current clock freq interface for navi10") Fixes: ab43c4bf1cc8 ("drm/amd/powerplay: fix fan speed show error (for hwmon pwm)") Link: https://github.com/ClangBuiltLinux/linux/issues/583 Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
In file included from drivers/gpu/drm/amd/amdgpu/nv.c:53:
drivers/gpu/drm/amd/amdgpu/../amdgpu/mes_v10_1.h:24:9: warning:
'__MES_V10_1_H__' is used as a header guard here, followed by #define of
a different macro [-Wheader-guard]
#ifndef __MES_V10_1_H__
^~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../amdgpu/mes_v10_1.h:25:9: note:
'__MES_v10_1_H__' is defined here; did you mean '__MES_V10_1_H__'?
#define __MES_v10_1_H__
^~~~~~~~~~~~~~~
__MES_V10_1_H__
1 warning generated.
Flora Cui [Mon, 24 Jun 2019 08:48:33 +0000 (16:48 +0800)]
drm/amdgpu: fix scheduler timeout calc
scheduler timeout is in jiffies
v2: move timeout check to amdgpu_device_get_job_timeout_settings after
parsing the value
v3: add lockup_timeout param check. 0: keep default value. negative:
infinity timeout.
v4: refactor codes.
Philip Yang [Tue, 2 Jul 2019 22:39:45 +0000 (18:39 -0400)]
drm/amdgpu: Prepare for hmm_range_register API change (v2)
An upcoming change in the hmm_range_register API requires passing in
a pointer to an hmm_mirror instead of mm_struct. To access the
hmm_mirror we need pass bo instead of ttm to amdgpu_ttm_tt_get_user_pages
because mirror is part of amdgpu_mn structure, which is accessible from bo.
Yrjan Skrimstad [Thu, 30 May 2019 00:08:21 +0000 (02:08 +0200)]
drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking
This driver currently contains a repeated 500ms blocking delay call
which causes frequent major buffer underruns in PulseAudio. This patch
fixes this issue by replacing the blocking delay with a non-blocking
sleep call.
drm/amdgpu: Use kmemdup rather than duplicating its implementation
kmemdup is introduced to duplicate a region of memory in a neat way.
Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
write the size twice (sometimes lead to mistakes), kmemdup improves
readability, leads to smaller code and also reduce the chances of mistakes.
Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy.
Dave Airlie [Thu, 4 Jul 2019 04:08:07 +0000 (14:08 +1000)]
Merge tag 'for-airlie-armada' of git://git.armlinux.org.uk/~rmk/linux-arm into drm-next
Armada DRM updates:
- Fix interlace support.
- use __drm_atomic_helper_plane_reset in overlay reset.
- since the overlay and video planes use essentially the same format
registers, precompute their values while validating.
- fix a long-standing deficiency with overlay planes and interlace modes
- calculate plane starting address at atomic_check stage rather than
when we're programming the registers.
- add gamma support.
- ensure mode adjustments made by other components are properly handled
in the driver and applied to the CRTC-programmed mode.
- add and use register definitions for the "REG4F" register.
- use drm_atomic_helper_shutdown() when tearing down to ensure that the
hardware is properly shutdown.
- add CRTC-level mode validation to ensure that we don't allow a mode
that the CRTC-level hardware can not support.
- improve the clocking selection for Armada 510 support.
- move CRTC debugfs files into the crtc-specific directory, using the
DRM helper to create these files.
- patch from Lubomir Rintel to replace a simple framebuffer.
- use the OF graph walker rather than open-coding this.
- eliminate a useless check for the availability of the remote's parent
which isn't required.
Dave Airlie [Thu, 4 Jul 2019 01:46:02 +0000 (11:46 +1000)]
Merge tag 'exynos-drm-next-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
- Drop the use of drmP.h header file
drmP.h header file has been deprecated so this patch drops the use of
this header, and instead includes appropriate header files required.
- Add COMPILE_TEST flag
This patch adds COMPILE_TEST dependency to exynos drm driver to
increase build test coverage. And also, it includes vmalloc.h
header file to fix one build warning which is introduced when
building the Linux kernel using sh.
Felix Kuehling [Thu, 20 Jun 2019 18:50:52 +0000 (14:50 -0400)]
drm/amdkfd: Add chained_runlist_idle_disable flag to pm4_mes_runlist
New flag to disable an idle runlist optimization that is causing soft
hangs with some diffult-to-reproduce customer workloads. This will
serve as a workaround until the problem can be reproduced and the
root-cause determined.
Felix Kuehling [Fri, 7 Jun 2019 15:33:21 +0000 (11:33 -0400)]
drm/amdgpu: Use FENCE_OWNER_KFD in process_sync_pds_resv
We don't want eviction fences to trigger when waiting for page table
updates to complete during restore. In theory there shouldn't be any
unsignaled eviction fences in the PD reservation object, but I'm
seeing them in instrumented code for reasons not fully understood.
Felix Kuehling [Thu, 20 Jun 2019 19:37:37 +0000 (15:37 -0400)]
drm/amdkfd: Print a warning when the runlist becomes oversubscribed
Oversubscription of queues or processes results in poor performance
mostly because HWS blinbly schedules busy and idle queues, resulting
in poor occupancy if many queues are idle.
Let users know with a warning message when transitioning from a
non-oversubscribed to an oversubscribed runlist.
Jack Xiao [Wed, 29 May 2019 05:24:22 +0000 (13:24 +0800)]
drm/amdgpu: add field indicating if has PCIE atomics support
The new field in amdgpu device is used to record whether the
system has PCIE atomics support. The field can be exposed to
UMD or kfd whether PCIE atomics have supported.
Lyude Paul [Thu, 20 Jun 2019 23:21:26 +0000 (19:21 -0400)]
drm/amdgpu: Don't skip display settings in hwmgr_resume()
I'm not entirely sure why this is, but for some reason:
921935dc6404 ("drm/amd/powerplay: enforce display related settings only on needed")
Breaks runtime PM resume on the Radeon PRO WX 3100 (Lexa) in one the
pre-production laptops I have. The issue manifests as the following
messages in dmesg:
[drm] UVD and UVD ENC initialized successfully.
amdgpu 0000:3b:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring vce1 test failed (-110)
[drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <vce_v3_0> failed -110
[drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-110).
And happens after about 6-10 runtime PM suspend/resume cycles (sometimes
sooner, if you're lucky!). Unfortunately I can't seem to pin down
precisely which part in psm_adjust_power_state_dynamic that is causing
the issue, but not skipping the display setting setup seems to fix it.
Hopefully if there is a better fix for this, this patch will spark
discussion around it.
Lubomir Rintel [Mon, 21 Jan 2019 06:01:57 +0000 (07:01 +0100)]
drm/armada: replace the simple-framebuffer
If there's a simple-framebuffer carried over from boot firmware, it's going
to stop working once we setup the LCDC for use via DRM. Kick it off from
the hardware.
Dave Airlie [Thu, 27 Jun 2019 23:34:25 +0000 (09:34 +1000)]
Merge tag 'drm-msm-next-2019-06-25' of https://gitlab.freedesktop.org/drm/msm into drm-next
+ usual progress on cleanups
+ dsi vs EPROBE_DEFER fixes
+ msm8998 (snapdragon 835 support)
+ a540 gpu support (mesa support already landed)
+ dsi, dsi-phy support
+ mdp5 and dpu interconnect (bus/memory scaling) support
+ initial prep work for per-context pagetables (at least the parts that
don't have external dependencies like iommu/arm-smmu)
There is one more patch for fixing DSI cmd mode panels (part of a set of
patches to get things working on nexus5), but it would be conflicty with 1cff7440a86e04a613665803b42034 in drm-next without rebasing or back-merge,
and since it doesn't conflict with anything in msm-next, I think it best
if Sean merges that through drm-mix-fixes instead.
(In other news, I've been making some progress w/ getting efifb working
properly on sdm850 laptop without horrible hacks, and drm/msm + clk stuff
not totally falling over when bootloader enables display and things are
already running when driver probes.. but not quite ready yet, hopefully
we can post some of that for 5.4.. should help for both the sdm835 and
sdm850 laptops.)
Felix Kuehling [Wed, 26 Jun 2019 06:32:43 +0000 (02:32 -0400)]
drm/ttm: return -EBUSY if waiting for busy BO fails
Returning -EAGAIN prevents ttm_bo_mem_space from trying alternate
placements and can lead to live-locks in amdgpu_cs, retrying
indefinitely and never succeeding.
Fixes: d367bd2a5e2b12 ("drm/ttm: fix busy memory to fail other user v10") Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Sam Ravnborg [Thu, 27 Jun 2019 11:00:54 +0000 (20:00 +0900)]
drm/exynos: trigger build of all modules
Add COMPILE_TEST dependency to force exynos driver to
built for more than arm and to built modules
that otherwise required other symbols to be de-selected.
This will increase build coverage of the exynos driver
thus allowing most trivial build errors to be detected/fixed early.
This introduces one warning when built using sh:
exynos7_drm_decon.c: In function ‘decon_remove’:
exynos7_drm_decon.c:769:24: warning: unused variable ‘ctx’
struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
This is due to the definition of iounmap() in sh,
and nothing that exynos driver can fix.
Dave Airlie [Thu, 27 Jun 2019 02:33:56 +0000 (12:33 +1000)]
Merge tag 'drm-next-5.3-2019-06-25' of git://people.freedesktop.org/~agd5f/linux into drm-next
drm-next-5.3-2019-06-25:
Merge drm-next
amdgpu:
- SR-IOV L1 policy fixes
- Removed no longer needed vram_page_split module parameter
- Add module parameter to override default ABM level
- Gamma fixes
- No need to check return values for debugfs
- Improve HMM error handling
- Avoid possible OOM situations when lots of thread are submitting with
memory contention
- Improve hw i2c access abritration
- DSC (Display Stream Compression) support in DC
- Initial navi10 support
* DC support
* GFX/Compute support
* SDMA support
* Power Management support
* VCN support
- Static checker fixes
- Misc cleanups
- fix long udelay on arm
amdkfd:
- Implement priority controls for gfx9
- Enable VEGAM
- Rework mqd allocation and init
- Circular locking fix
- Fix SDMA queue allocation race condition
- No need to check return values for debugfs
- Add proc style process information
- Initial navi10 support
radeon:
- No need to check return values for debugfs
UAPI changes:
- GDDR6 added to vram type query
- New Navi10 details added gpu info query
- Navi family added to asic family query
Dave Airlie [Thu, 27 Jun 2019 01:48:02 +0000 (11:48 +1000)]
Merge tag 'for-airlie-tda998x' of git://git.armlinux.org.uk/~rmk/linux-arm into drm-next
TDA998x updates:
- improve the driver's approach to audio, adding support for more I2S
based formats, particularly other justifications, and preparing the
driver to support other bclk ratios.
- add support for pixel repeated modes, tested with a Panasonic TV.
- correct the quantisation range handling; in particular, do not send
full range RGB to the sink when the sink does not support full range
RGB.
Merge tag 'topic/remove-fbcon-notifiers-2019-06-26' into drm-misc-next-fixes
topic/remove-fbcon-notifiers:
- Export fbcon_update_vcs to fix sh_mobile_lcdcfb.c compilation.
- Rely on fbcon being builtin when vgaswitcheroo is builtin.
Daniel Vetter [Mon, 24 Jun 2019 09:21:53 +0000 (11:21 +0200)]
vga_switcheroo: Depend upon fbcon being built-in, if enabled
Fixes linking fail when fbcon/fbdev is modular and vgaswitcheroo is
enabled:
x86_64-linux-gnu-ld: drivers/gpu/vga/vga_switcheroo.o: in function `vga_switchto_stage2':
vga_switcheroo.c:(.text+0x997): undefined reference to `fbcon_remap_all'
Unfortunately this means that in a default allmodconfig we will disable vgaswitcheroo.
v2: I first tried to fix this with an EXPORT_SYMBOL, but vga_switcheroo is
never a module, so this doesn't work.
drm/amd/display: update infoframe after dig fe is turned on (v2)
[Why]
The AVI infoframe is incorrectly programmed on DCN1/2 when enabling a
stream - causing the wrong pixel encoding to be used for display.
This is because the AVI infoframe is programmed before the DIG BE is
connected to the FE and turned on, so enabling the AFMT block doesn't
actually work and the registers subsequently can't be written to.
[How]
Program the infoframe *after* turning on the DIG FE. This was the
behavior previously used but it was incorrectly reverted
when adding the DCN2 HW sequencer code.
v2: Don't call update_info_frame twice
Fixes: 7ed4e6352c16fe01 ("drm/amd/display: Add DCN2 HW Sequencer and Resource") Signed-off-by: Nicholas Kazlauskas <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Prike Liang [Mon, 24 Jun 2019 09:25:26 +0000 (17:25 +0800)]
drm/amd/powerplay:clean up the residual mutex for smu_hw_init
The mutex for procting SMU during hw_init was removed as system
will be deadlock when smu_populate_umd_state_clk try get SMU mutex.
Therefore need remove the residual mutex from failed path.
Ernst Sjöstrand [Mon, 24 Jun 2019 15:15:42 +0000 (17:15 +0200)]
drm/amd/amdgpu: Check stream in amdgpu_dm_commit_planes
Reported by smatch:
amdgpu_dm.c:5637 amdgpu_dm_commit_planes() error: we previously assumed 'acrtc_state->stream' could be null
This seems to be checked for null pretty consistently elsewhere.
projects / linux.git / log