linux-toradex.git/drivers/gpu/drm, branch v4.9.132

drm/nouveau/TBDdevinit: don't fail when PMU/PRE_OS is missing from VBIOS

2018-10-10T06:53:21+00:00

[ Upstream commit 0a6986c6595e9afd20ff7280dab36431c1e467f8 ]

This Falcon application doesn't appear to be present on some newer
systems, so let's not fail init if we can't find it.

TBD: is there a way to determine whether it *should* be there?

Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Update power state at the end of smu hw_init.

2018-10-04T00:01:52+00:00

[ Upstream commit 2ab4d0e74256fc49b7b270f63c1d1e47c2455abc ]

For SI/Kv, the power state is managed by function
amdgpu_pm_compute_clocks.

when dpm enabled, we should call amdgpu_pm_compute_clocks
to update current power state instand of set boot state.

this change can fix the oops when kfd driver was enabled on Kv.

Reviewed-by: Alex Deucher 
Tested-by: Michel Dänzer 
Signed-off-by: Rex Zhu 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Enable/disable gfx PG feature in rlc safe mode

2018-10-04T00:01:52+00:00

[ Upstream commit 8ef23364b654d44244400d79988e677e504b21ba ]

This is required by gfx hw and can fix the rlc hang when
do s3 stree test on Cz/St.

Reviewed-by: Alex Deucher 
Signed-off-by: Hang Zhou 
Signed-off-by: Rex Zhu 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/sun4i: Fix releasing node when enumerating enpoints

2018-10-04T00:01:46+00:00

[ Upstream commit 367c359aa8637b15ee8df6335c5a29b7623966ec ]

sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put()
when remote is equal to NULL and does nothing when remote has a valid
pointer.

Invert the logic to fix memory leak.

Signed-off-by: Jernej Skrabec 
Signed-off-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20180625120304.7543-7-jernej.skrabec@siol.net
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/vc4: Fix the "no scaling" case on multi-planar YUV formats

2018-09-29T10:07:33+00:00

commit 658d8cbd07dae22ccecf49399e18c609c4e85c53 upstream.

When there's no scaling requested ->is_unity should be true no matter
the format.

Also, when no scaling is requested and we have a multi-planar YUV
format, we should leave ->y_scaling[0] to VC4_SCALING_NONE and only
set ->x_scaling[0] to VC4_SCALING_PPF.

Doing this fixes an hardly visible artifact (seen when using modetest
and a rather big overlay plane in YUV420).

Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Cc: 
Signed-off-by: Boris Brezillon 
Reviewed-by: Eric Anholt 
Link: https://patchwork.freedesktop.org/patch/msgid/20180725122907.13702-1-boris.brezillon@bootlin.com
Signed-off-by: Sean Paul 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early

2018-09-29T10:07:33+00:00

commit 79e765ad665da4b8aa7e9c878bd2fef837f6fea5 upstream.

On most systems with ACPI hotplugging support, it seems that we always
receive a hotplug event once we re-enable EC interrupts even if the GPU
hasn't even been resumed yet.

This can cause problems since even though we schedule hpd_work to handle
connector reprobing for us, hpd_work synchronizes on
pm_runtime_get_sync() to wait until the device is ready to perform
reprobing. Since runtime suspend/resume callbacks are disabled before
the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during
this period will grab a runtime PM ref and return immediately with
-EACCES. Because we schedule hpd_work from our ACPI HPD handler, and
hpd_work synchronizes on pm_runtime_get_sync(), this causes us to launch
a connector reprobe immediately even if the GPU isn't actually resumed
just yet. This causes various warnings in dmesg and occasionally, also
prevents some displays connected to the dedicated GPU from coming back
up after suspend. Example:

usb 1-4: USB disconnect, device number 14
usb 1-4.1: USB disconnect, device number 15
WARNING: CPU: 0 PID: 838 at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nouveau_dp_detect+0x17e/0x370 [nouveau]
CPU: 0 PID: 838 Comm: kworker/0:6 Not tainted 4.17.14-201.Lyude.bz1477182.V3.fc28.x86_64 #1
Hardware name: LENOVO 20EQS64N00/20EQS64N00, BIOS N1EET77W (1.50 ) 03/28/2018
Workqueue: events nouveau_display_hpd_work [nouveau]
RIP: 0010:nouveau_dp_detect+0x17e/0x370 [nouveau]
RSP: 0018:ffffa15143933cf0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8cb4f656c400 RCX: 0000000000000000
RDX: ffffa1514500e4e4 RSI: ffffa1514500e4e4 RDI: 0000000001009002
RBP: ffff8cb4f4a8a800 R08: ffffa15143933cfd R09: ffffa15143933cfc
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cb4fb57a000
R13: ffff8cb4fb57a000 R14: ffff8cb4f4a8f800 R15: ffff8cb4f656c418
FS:  0000000000000000(0000) GS:ffff8cb51f400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f78ec938000 CR3: 000000073720a003 CR4: 00000000003606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ? _cond_resched+0x15/0x30
 nouveau_connector_detect+0x2ce/0x520 [nouveau]
 ? _cond_resched+0x15/0x30
 ? ww_mutex_lock+0x12/0x40
 drm_helper_probe_detect_ctx+0x8b/0xe0 [drm_kms_helper]
 drm_helper_hpd_irq_event+0xa8/0x120 [drm_kms_helper]
 nouveau_display_hpd_work+0x2a/0x60 [nouveau]
 process_one_work+0x187/0x340
 worker_thread+0x2e/0x380
 ? pwq_unbound_release_workfn+0xd0/0xd0
 kthread+0x112/0x130
 ? kthread_create_worker_on_cpu+0x70/0x70
 ret_from_fork+0x35/0x40
Code: 4c 8d 44 24 0d b9 00 05 00 00 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e1 09 f8 ff 85 c0 0f 85 b2 01 00 00 80 7c 24 0c 03 74 02 <0f> 0b 48 89 ef e8 b8 07 f8 ff f6 05 51 1b c8 ff 02 0f 84 72 ff
---[ end trace 55d811b38fc8e71a ]---

So, to fix this we attempt to grab a runtime PM reference in the ACPI
handler itself asynchronously. If the GPU is already awake (it will have
normal hotplugging at this point) or runtime PM callbacks are currently
disabled on the device, we drop our reference without updating the
autosuspend delay. We only schedule connector reprobes when we
successfully managed to queue up a resume request with our asynchronous
PM ref.

This also has the added benefit of preventing redundant connector
reprobes from ACPI while the GPU is runtime resumed!

Signed-off-by: Lyude Paul 
Cc: stable@vger.kernel.org
Cc: Karol Herbst 
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477182#c41
Signed-off-by: Lyude Paul 
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

2018-09-29T10:07:33+00:00

commit 6833fb1ec120bf078e1a527c573a09d4de286224 upstream.

It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely avoiding grabbing a power reference.

Signed-off-by: Lyude Paul 
Reviewed-by: Karol Herbst 
Acked-by: Daniel Vetter 
Cc: stable@vger.kernel.org
Cc: Lukas Wunner 
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement

2018-09-29T10:07:33+00:00

commit d77ef138ff572409ab93d492e5e6c826ee6fb21d upstream.

Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
drm_kms_helper_poll_enable() every time we schedule the hotplug
detection work. This is also against the advice mentioned in
drm_kms_helper_poll_enable()'s documentation:

 Note that calls to enable and disable polling must be strictly ordered,
 which is automatically the case when they're only call from
 suspend/resume callbacks.

Of course, hotplugs can't really be ordered. They could even happen
immediately after we called drm_kms_helper_poll_disable() in
nouveau_display_fini(), which can lead to all sorts of issues.

Additionally; enabling polling /after/ we call
drm_helper_hpd_irq_event() could also mean that we'd miss a hotplug
event anyway, since drm_helper_hpd_irq_event() wouldn't bother trying to
probe connectors so long as polling is disabled.

So; simply move this back into nouveau_display_init() again. The race
condition that both of these patches attempted to work around has
already been fixed properly in

  d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")

Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul 
Acked-by: Karol Herbst 
Acked-by: Daniel Vetter 
Cc: Lukas Wunner 
Cc: Peter Ujfalusi 
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/panel: type promotion bug in s6e8aa0_read_mtp_id()

2018-09-26T06:36:40+00:00

[ Upstream commit cd0e0ca69109d025b1a1b6609f70682db62138b0 ]

The ARRAY_SIZE() macro is type size_t.  If s6e8aa0_dcs_read() returns a
negative error code, then "ret < ARRAY_SIZE(id)" is false because the
negative error code is type promoted to a high positive value.

Fixes: 02051ca06371 ("drm/panel: add S6E8AA0 driver")
Signed-off-by: Dan Carpenter 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Thierry Reding 
Link: https://patchwork.freedesktop.org/patch/msgid/20180704093807.s3lqsb2v6dg2k43d@kili.mountain
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amdkfd: Fix error codes in kfd_get_process

2018-09-26T06:36:39+00:00

[ Upstream commit e47cb828eb3fca3e8999a0b9aa053dda18552071 ]

Return ERR_PTR(-EINVAL) if kfd_get_process fails to find the process.
This fixes kernel oopses when a child process calls KFD ioctls with
a file descriptor inherited from the parent process.

Signed-off-by: Wei Lu 
Reviewed-by: Felix Kuehling 
Signed-off-by: Felix Kuehling 
Acked-by: Christian König 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman