<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v5.4.175</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.175</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.175'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-01-29T09:25:11+00:00</updated>
<entry>
<title>drm/vmwgfx: Fix stale file descriptors on failed usercopy</title>
<updated>2022-01-29T09:25:11+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@grsecurity.net</email>
</author>
<published>2022-01-27T08:34:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=84b1259fe36ae0915f3d6ddcea6377779de48b82'/>
<id>urn:sha1:84b1259fe36ae0915f3d6ddcea6377779de48b82</id>
<content type='text'>
commit a0f90c8815706981c483a652a6aefca51a5e191c upstream.

A failing usercopy of the fence_rep object will lead to a stale entry in
the file descriptor table as put_unused_fd() won't release it. This
enables userland to refer to a dangling 'file' object through that still
valid file descriptor, leading to all kinds of use-after-free
exploitation scenarios.

Fix this by deferring the call to fd_install() until after the usercopy
has succeeded.

Fixes: c906965dee22 ("drm/vmwgfx: Add export fence to file descriptor support")
Signed-off-by: Mathias Krause &lt;minipli@grsecurity.net&gt;
Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: Flush TLBs before releasing backing store</title>
<updated>2022-01-29T09:25:09+00:00</updated>
<author>
<name>Tvrtko Ursulin</name>
<email>tvrtko.ursulin@intel.com</email>
</author>
<published>2021-10-19T12:27:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1b5553c79d52f17e735cd924ff2178a2409e6d0b'/>
<id>urn:sha1:1b5553c79d52f17e735cd924ff2178a2409e6d0b</id>
<content type='text'>
commit 7938d61591d33394a21bdd7797a245b65428f44c upstream.

We need to flush TLBs before releasing backing store otherwise userspace
is able to encounter stale entries if a) it is not declaring access to
certain buffers and b) it races with the backing store release from a
such undeclared execution already executing on the GPU in parallel.

The approach taken is to mark any buffer objects which were ever bound
to the GPU and to trigger a serialized TLB flush when their backing
store is released.

Alternatively the flushing could be done on VMA unbind, at which point
we would be able to ascertain whether there is potential a parallel GPU
execution (which could race), but essentially it boils down to paying
the cost of TLB flushes potentially needlessly at VMA unbind time (when
the backing store is not known to be going away so not needed for
safety), versus potentially needlessly at backing store relase time
(since we at that point cannot tell whether there is anything executing
on the GPU which uses that object).

Thereforce simplicity of implementation has been chosen for now with
scope to benchmark and refine later as required.

Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Reported-by: Sushma Venkatesh Reddy &lt;sushma.venkatesh.reddy@intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Acked-by: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/radeon: fix error handling in radeon_driver_open_kms</title>
<updated>2022-01-27T08:19:51+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2022-01-17T09:31:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=227afbfe47b505a56e34f0fd8d288ce5bbab2032'/>
<id>urn:sha1:227afbfe47b505a56e34f0fd8d288ce5bbab2032</id>
<content type='text'>
commit 4722f463896cc0ef1a6f1c3cb2e171e949831249 upstream.

The return value was never initialized so the cleanup code executed when
it isn't even necessary.

Just add proper error handling.

Fixes: ab50cb9df889 ("drm/radeon/radeon_kms: Fix a NULL pointer dereference in radeon_driver_open_kms()")
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Tested-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Tested-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: analogix_dp: Make PSR-exit block less</title>
<updated>2022-01-27T08:19:50+00:00</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2021-11-03T20:52:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=db531b57cb506ddd6023d93ef68b49caae04fdcc'/>
<id>urn:sha1:db531b57cb506ddd6023d93ef68b49caae04fdcc</id>
<content type='text'>
commit c4c6ef229593366ab593d4d424addc7025b54a76 upstream.

Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
"PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor
started using the blocking variant, for a variety of reasons -- quoting
Sean Paul's potentially-faulty memory:

"""
 - To avoid racing a subsequent PSR entry (if exit takes a long time)
 - To avoid racing disable/modeset
 - We're not displaying new content while exiting PSR anyways, so there
   is minimal utility in allowing frames to be submitted
 - We're lying to userspace telling them frames are on the screen when
   we're just dropping them on the floor
"""

However, I'm finding that this blocking transition is causing upwards of
60+ ms of unneeded latency on PSR-exit, to the point that initial cursor
movements when leaving PSR are unbearably jumpy.

It turns out that we need to meet in the middle somewhere: Sean is right
that we were "lying to userspace" with a non-blocking PSR-exit, but the
new blocking behavior is also waiting too long:

According to the eDP specification, the sink device must support PSR
entry transitions from both state 4 (ACTIVE_RESYNC) and state 0
(INACTIVE). It also states that in ACTIVE_RESYNC, "the Sink device must
display the incoming active frames from the Source device with no
visible glitches and/or artifacts."

Thus, for our purposes, we only need to wait for ACTIVE_RESYNC before
moving on; we are ready to display video, and subsequent PSR-entry is
safe.

Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin),
where this saves about 60ms of latency, for PSR-exit that used to
take about 80ms.

Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Zain Wang &lt;wzz@rock-chips.com&gt;
Cc: Tomasz Figa &lt;tfiga@chromium.org&gt;
Cc: Heiko Stuebner &lt;heiko@sntech.de&gt;
Cc: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Robert Foss &lt;robert.foss@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20211103135112.v3.1.I67612ea073c3306c71b46a87be894f79707082df@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/nouveau/kms/nv04: use vzalloc for nv04_display</title>
<updated>2022-01-27T08:19:50+00:00</updated>
<author>
<name>Ilia Mirkin</name>
<email>imirkin@alum.mit.edu</email>
</author>
<published>2021-03-07T17:48:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=17d492d39e17fa5a1d06a8c1ea5faf18f44e2884'/>
<id>urn:sha1:17d492d39e17fa5a1d06a8c1ea5faf18f44e2884</id>
<content type='text'>
commit bd6e07e72f37f34535bec7eebc807e5fcfe37b43 upstream.

The struct is giant, and triggers an order-7 allocation (512K). There is
no reason for this to be kmalloc-type memory, so switch to vmalloc. This
should help loading nouveau on low-memory and/or long-running systems.

Reported-by: Nathan E. Egge &lt;unlord@xiph.org&gt;
Signed-off-by: Ilia Mirkin &lt;imirkin@alum.mit.edu&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Reviewed-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Signed-off-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: limit submit sizes</title>
<updated>2022-01-27T08:19:50+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2021-12-17T10:59:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0d0e56a1a94586c1b166970fc9aa7694dbf3f3f7'/>
<id>urn:sha1:0d0e56a1a94586c1b166970fc9aa7694dbf3f3f7</id>
<content type='text'>
commit 6dfa2fab8ddd46faa771a102672176bee7a065de upstream.

Currently we allow rediculous amounts of kernel memory being allocated
via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put
some reasonable limits in to fix this.

The commandstream size is limited to 64KB, which was already a soft limit
on older kernels after which the kernel only took submits on a best effort
base, so there is no userspace that tries to submit commandstreams larger
than this. Even if the whole commandstream is a single incrementing address
load, the size limit also limits the number of potential relocs and
referenced buffers to slightly under 64K, so use the same limit for those
arguments. The performance monitoring infrastructure currently supports
less than 50 performance counter signals, so limiting them to 128 on a
single submit seems like a reasonably future-proof number for now. This
number can be bumped if needed without breaking the interface.

Cc: stable@vger.kernel.org
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Reviewed-by: Christian Gmeiner &lt;christian.gmeiner@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: fixup bad vram size on gmc v8</title>
<updated>2022-01-27T08:19:45+00:00</updated>
<author>
<name>Zongmin Zhou</name>
<email>zhouzongmin@kylinos.cn</email>
</author>
<published>2021-12-15T09:23:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7c366d75a44ad81be92793eb2886724179396f06'/>
<id>urn:sha1:7c366d75a44ad81be92793eb2886724179396f06</id>
<content type='text'>
[ Upstream commit 11544d77e3974924c5a9c8a8320b996a3e9b2f8b ]

Some boards(like RX550) seem to have garbage in the upper
16 bits of the vram size register.  Check for
this and clamp the size properly.  Fixes
boards reporting bogus amounts of vram.

after add this patch,the maximum GPU VRAM size is 64GB,
otherwise only 64GB vram size will be used.

Signed-off-by: Zongmin Zhou&lt;zhouzongmin@kylinos.cn&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: megachips: Ensure both bridges are probed before registration</title>
<updated>2022-01-27T08:19:41+00:00</updated>
<author>
<name>Martyn Welch</name>
<email>martyn.welch@collabora.com</email>
</author>
<published>2021-11-25T10:53:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=50ad94f8654a53ec9ca3604a7a23cbaf166e0119'/>
<id>urn:sha1:50ad94f8654a53ec9ca3604a7a23cbaf166e0119</id>
<content type='text'>
[ Upstream commit 11632d4aa2b3f126790e81a4415d6c23103cf8bb ]

In the configuration used by the b850v3, the STDP2690 is used to read EDID
data whilst it's the STDP4028 which can detect when monitors are connected.

This can result in problems at boot with monitors connected when the
STDP4028 is probed first, a monitor is detected and an attempt is made to
read the EDID data before the STDP2690 has probed:

[    3.795721] Unable to handle kernel NULL pointer dereference at virtual address 00000018
[    3.803845] pgd = (ptrval)
[    3.806581] [00000018] *pgd=00000000
[    3.810180] Internal error: Oops: 5 [#1] SMP ARM
[    3.814813] Modules linked in:
[    3.817879] CPU: 0 PID: 64 Comm: kworker/u4:1 Not tainted 5.15.0 #1
[    3.824161] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[    3.830705] Workqueue: events_unbound deferred_probe_work_func
[    3.836565] PC is at stdp2690_get_edid+0x44/0x19c
[    3.841286] LR is at ge_b850v3_lvds_get_modes+0x2c/0x5c
[    3.846526] pc : [&lt;805eae10&gt;]    lr : [&lt;805eb138&gt;]    psr: 80000013
[    3.852802] sp : 81c359d0  ip : 7dbb550b  fp : 81c35a1c
[    3.858037] r10: 81c73840  r9 : 81c73894  r8 : 816d9800
[    3.863270] r7 : 00000000  r6 : 81c34000  r5 : 00000000  r4 : 810c35f0
[    3.869808] r3 : 80e3e294  r2 : 00000080  r1 : 00000cc0  r0 : 81401180
[    3.876349] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    3.883499] Control: 10c5387d  Table: 1000404a  DAC: 00000051
[    3.889254] Register r0 information: slab kmem_cache start 81401180 pointer offset 0
[    3.897034] Register r1 information: non-paged memory
[    3.902097] Register r2 information: non-paged memory
[    3.907160] Register r3 information: non-slab/vmalloc memory
[    3.912832] Register r4 information: non-slab/vmalloc memory
[    3.918503] Register r5 information: NULL pointer
[    3.923217] Register r6 information: non-slab/vmalloc memory
[    3.928887] Register r7 information: NULL pointer
[    3.933601] Register r8 information: slab kmalloc-1k start 816d9800 pointer offset 0 size 1024
[    3.942244] Register r9 information: slab kmalloc-2k start 81c73800 pointer offset 148 size 2048
[    3.951058] Register r10 information: slab kmalloc-2k start 81c73800 pointer offset 64 size 2048
[    3.959873] Register r11 information: non-slab/vmalloc memory
[    3.965632] Register r12 information: non-paged memory
[    3.970781] Process kworker/u4:1 (pid: 64, stack limit = 0x(ptrval))
[    3.977148] Stack: (0x81c359d0 to 0x81c36000)
[    3.981517] 59c0:                                     80b2b668 80b2b5bc 000002e2 0000034e
[    3.989712] 59e0: 81c35a8c 816d98e8 81c35a14 7dbb550b 805bfcd0 810c35f0 81c73840 824addc0
[    3.997906] 5a00: 00001000 816d9800 81c73894 81c73840 81c35a34 81c35a20 805eb138 805eadd8
[    4.006099] 5a20: 810c35f0 00000045 81c35adc 81c35a38 80594188 805eb118 80d7c788 80dd1848
[    4.014292] 5a40: 00000000 81c35a50 80dca950 811194d3 80dca7c4 80dca944 80dca91c 816d9800
[    4.022485] 5a60: 81c34000 81c760a8 816d9800 80c58c98 810c35f0 816d98e8 00001000 00001000
[    4.030678] 5a80: 00000000 00000000 8017712c 81c60000 00000002 00000001 00000000 00000000
[    4.038870] 5aa0: 816d9900 816d9900 00000000 7dbb550b 805c700c 00000008 826282c8 826282c8
[    4.047062] 5ac0: 00001000 81e1ce40 00001000 00000002 81c35bf4 81c35ae0 805d9694 80593fc0
[    4.055255] 5ae0: 8017a970 80179ad8 00000179 00000000 81c35bcc 81c35b00 80177108 8017a950
[    4.063447] 5b00: 00000000 81c35b10 81c34000 00000000 81004fd8 81010a38 00000000 00000059
[    4.071639] 5b20: 816d98d4 81fbb718 00000013 826282c8 8017a940 81c35b40 81134448 00000400
[    4.079831] 5b40: 00000178 00000000 e063b9c1 00000000 c2000049 00000040 00000000 00000008
[    4.088024] 5b60: 82628300 82628380 00000000 00000000 81c34000 00000000 81fbb700 82628340
[    4.096216] 5b80: 826283c0 00001000 00000000 00000010 816d9800 826282c0 801766f8 00000000
[    4.104408] 5ba0: 00000000 81004fd8 00000049 00000000 00000000 00000001 80dcf940 80178de4
[    4.112601] 5bc0: 81c35c0c 7dbb550b 80178de4 81fbb700 00000010 00000010 810c35f4 81e1ce40
[    4.120793] 5be0: 81c40908 0000000c 81c35c64 81c35bf8 805a7f18 805d94a0 81c35c3c 816d9800
[    4.128985] 5c00: 00000010 81c34000 81c35c2c 81c35c18 8012fce0 805be90c 81c35c3c 81c35c28
[    4.137178] 5c20: 805be90c 80173210 81fbb600 81fbb6b4 81c35c5c 7dbb550b 81c35c64 81fbb700
[    4.145370] 5c40: 816d9800 00000010 810c35f4 81e1ce40 81c40908 0000000c 81c35c84 81c35c68
[    4.153565] 5c60: 805a8c78 805a7ed0 816d9800 81fbb700 00000010 00000000 81c35cac 81c35c88
[    4.161758] 5c80: 805a8dc4 805a8b68 816d9800 00000000 816d9800 00000000 8179f810 810c42d0
[    4.169950] 5ca0: 81c35ccc 81c35cb0 805e47b0 805a8d18 824aa240 81e1ea80 81c40908 81126b60
[    4.178144] 5cc0: 81c35d14 81c35cd0 8060db1c 805e46cc 81c35d14 81c35ce0 80dd90f8 810c4d58
[    4.186338] 5ce0: 80dd90dc 81fe9740 fffffffe 81fe9740 81e1ea80 00000000 810c4d6c 80c4b95c
[    4.194531] 5d00: 80dd9a3c 815c6810 81c35d34 81c35d18 8060dc9c 8060d8fc 8246b440 815c6800
[    4.202724] 5d20: 815c6810 eefd8e00 81c35d44 81c35d38 8060dd80 8060dbec 81c35d6c 81c35d48
[    4.210918] 5d40: 805e98a4 8060dd70 00000000 815c6810 810c45b0 81126e90 81126e90 80dd9a3c
[    4.219112] 5d60: 81c35d8c 81c35d70 80619574 805e9808 815c6810 00000000 810c45b0 81126e90
[    4.227305] 5d80: 81c35db4 81c35d90 806168dc 80619514 80625df0 80623c80 815c6810 810c45b0
[    4.235498] 5da0: 81c35e6c 815c6810 81c35dec 81c35db8 80616d04 80616800 81c35de4 81c35dc8
[    4.243691] 5dc0: 808382b0 80b2f444 8116e310 8116e314 81c35e6c 815c6810 00000003 80dd9a3c
[    4.251884] 5de0: 81c35e14 81c35df0 80616ec8 80616c60 00000001 810c45b0 81c35e6c 815c6810
[    4.260076] 5e00: 00000001 80dd9a3c 81c35e34 81c35e18 80617338 80616e90 00000000 81c35e6c
[    4.268269] 5e20: 80617284 81c34000 81c35e64 81c35e38 80614730 80617290 81c35e64 8171a06c
[    4.276461] 5e40: 81e220b8 7dbb550b 815c6810 81c34000 815c6854 81126e90 81c35e9c 81c35e68
[    4.284654] 5e60: 8061673c 806146a8 8060f5e0 815c6810 00000001 7dbb550b 00000000 810c5080
[    4.292847] 5e80: 810c5320 815c6810 81126e90 00000000 81c35eac 81c35ea0 80617554 80616650
[    4.301040] 5ea0: 81c35ecc 81c35eb0 80615694 80617544 810c5080 810c5080 810c5094 81126e90
[    4.309233] 5ec0: 81c35efc 81c35ed0 80615c6c 8061560c 80615bc0 810c50c0 817eeb00 81412800
[    4.317425] 5ee0: 814c3000 00000000 814c300d 81119a60 81c35f3c 81c35f00 80141488 80615bcc
[    4.325618] 5f00: 81c60000 81c34000 81c35f24 81c35f18 80143078 817eeb00 81412800 817eeb18
[    4.333811] 5f20: 81412818 81003d00 00000088 81412800 81c35f74 81c35f40 80141a48 80141298
[    4.342005] 5f40: 81c35f74 81c34000 801481ac 817efa40 817efc00 801417d8 817eeb00 00000000
[    4.350199] 5f60: 815a7e7c 81c34000 81c35fac 81c35f78 80149b1c 801417e4 817efc20 817efc20
[    4.358391] 5f80: ffffe000 817efa40 801499a8 00000000 00000000 00000000 00000000 00000000
[    4.366583] 5fa0: 00000000 81c35fb0 80100130 801499b4 00000000 00000000 00000000 00000000
[    4.374774] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.382966] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    4.391155] Backtrace:
[    4.393613] [&lt;805eadcc&gt;] (stdp2690_get_edid) from [&lt;805eb138&gt;] (ge_b850v3_lvds_get_modes+0x2c/0x5c)
[    4.402691]  r10:81c73840 r9:81c73894 r8:816d9800 r7:00001000 r6:824addc0 r5:81c73840
[    4.410534]  r4:810c35f0
[    4.413073] [&lt;805eb10c&gt;] (ge_b850v3_lvds_get_modes) from [&lt;80594188&gt;] (drm_helper_probe_single_connector_modes+0x1d4/0x84c)
[    4.424240]  r5:00000045 r4:810c35f0
[    4.427822] [&lt;80593fb4&gt;] (drm_helper_probe_single_connector_modes) from [&lt;805d9694&gt;] (drm_client_modeset_probe+0x200/0x1384)
[    4.439074]  r10:00000002 r9:00001000 r8:81e1ce40 r7:00001000 r6:826282c8 r5:826282c8
[    4.446917]  r4:00000008
[    4.449455] [&lt;805d9494&gt;] (drm_client_modeset_probe) from [&lt;805a7f18&gt;] (__drm_fb_helper_initial_config_and_unlock+0x54/0x5b4)
[    4.460713]  r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:00000010
[    4.468556]  r4:81fbb700
[    4.471095] [&lt;805a7ec4&gt;] (__drm_fb_helper_initial_config_and_unlock) from [&lt;805a8c78&gt;] (drm_fbdev_client_hotplug+0x11c/0x1b0)
[    4.482434]  r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:816d9800
[    4.490276]  r4:81fbb700
[    4.492814] [&lt;805a8b5c&gt;] (drm_fbdev_client_hotplug) from [&lt;805a8dc4&gt;] (drm_fbdev_generic_setup+0xb8/0x1a4)
[    4.502494]  r7:00000000 r6:00000010 r5:81fbb700 r4:816d9800
[    4.508160] [&lt;805a8d0c&gt;] (drm_fbdev_generic_setup) from [&lt;805e47b0&gt;] (imx_drm_bind+0xf0/0x130)
[    4.516805]  r7:810c42d0 r6:8179f810 r5:00000000 r4:816d9800
[    4.522474] [&lt;805e46c0&gt;] (imx_drm_bind) from [&lt;8060db1c&gt;] (try_to_bring_up_master+0x22c/0x2f0)
[    4.531116]  r7:81126b60 r6:81c40908 r5:81e1ea80 r4:824aa240
[    4.536783] [&lt;8060d8f0&gt;] (try_to_bring_up_master) from [&lt;8060dc9c&gt;] (__component_add+0xbc/0x184)
[    4.545597]  r10:815c6810 r9:80dd9a3c r8:80c4b95c r7:810c4d6c r6:00000000 r5:81e1ea80
[    4.553440]  r4:81fe9740
[    4.555980] [&lt;8060dbe0&gt;] (__component_add) from [&lt;8060dd80&gt;] (component_add+0x1c/0x20)
[    4.563921]  r7:eefd8e00 r6:815c6810 r5:815c6800 r4:8246b440
[    4.569589] [&lt;8060dd64&gt;] (component_add) from [&lt;805e98a4&gt;] (dw_hdmi_imx_probe+0xa8/0xe8)
[    4.577702] [&lt;805e97fc&gt;] (dw_hdmi_imx_probe) from [&lt;80619574&gt;] (platform_probe+0x6c/0xc8)
[    4.585908]  r9:80dd9a3c r8:81126e90 r7:81126e90 r6:810c45b0 r5:815c6810 r4:00000000
[    4.593662] [&lt;80619508&gt;] (platform_probe) from [&lt;806168dc&gt;] (really_probe+0xe8/0x460)
[    4.601524]  r7:81126e90 r6:810c45b0 r5:00000000 r4:815c6810
[    4.607191] [&lt;806167f4&gt;] (really_probe) from [&lt;80616d04&gt;] (__driver_probe_device+0xb0/0x230)
[    4.615658]  r7:815c6810 r6:81c35e6c r5:810c45b0 r4:815c6810
[    4.621326] [&lt;80616c54&gt;] (__driver_probe_device) from [&lt;80616ec8&gt;] (driver_probe_device+0x44/0xe0)
[    4.630313]  r9:80dd9a3c r8:00000003 r7:815c6810 r6:81c35e6c r5:8116e314 r4:8116e310
[    4.638068] [&lt;80616e84&gt;] (driver_probe_device) from [&lt;80617338&gt;] (__device_attach_driver+0xb4/0x12c)
[    4.647227]  r9:80dd9a3c r8:00000001 r7:815c6810 r6:81c35e6c r5:810c45b0 r4:00000001
[    4.654981] [&lt;80617284&gt;] (__device_attach_driver) from [&lt;80614730&gt;] (bus_for_each_drv+0x94/0xd8)
[    4.663794]  r7:81c34000 r6:80617284 r5:81c35e6c r4:00000000
[    4.669461] [&lt;8061469c&gt;] (bus_for_each_drv) from [&lt;8061673c&gt;] (__device_attach+0xf8/0x190)
[    4.677753]  r7:81126e90 r6:815c6854 r5:81c34000 r4:815c6810
[    4.683419] [&lt;80616644&gt;] (__device_attach) from [&lt;80617554&gt;] (device_initial_probe+0x1c/0x20)
[    4.691971]  r8:00000000 r7:81126e90 r6:815c6810 r5:810c5320 r4:810c5080
[    4.698681] [&lt;80617538&gt;] (device_initial_probe) from [&lt;80615694&gt;] (bus_probe_device+0x94/0x9c)
[    4.707318] [&lt;80615600&gt;] (bus_probe_device) from [&lt;80615c6c&gt;] (deferred_probe_work_func+0xac/0xf0)
[    4.716305]  r7:81126e90 r6:810c5094 r5:810c5080 r4:810c5080
[    4.721973] [&lt;80615bc0&gt;] (deferred_probe_work_func) from [&lt;80141488&gt;] (process_one_work+0x1fc/0x54c)
[    4.731139]  r10:81119a60 r9:814c300d r8:00000000 r7:814c3000 r6:81412800 r5:817eeb00
[    4.738981]  r4:810c50c0 r3:80615bc0
[    4.742563] [&lt;8014128c&gt;] (process_one_work) from [&lt;80141a48&gt;] (worker_thread+0x270/0x570)
[    4.750765]  r10:81412800 r9:00000088 r8:81003d00 r7:81412818 r6:817eeb18 r5:81412800
[    4.758608]  r4:817eeb00
[    4.761147] [&lt;801417d8&gt;] (worker_thread) from [&lt;80149b1c&gt;] (kthread+0x174/0x190)
[    4.768574]  r10:81c34000 r9:815a7e7c r8:00000000 r7:817eeb00 r6:801417d8 r5:817efc00
[    4.776417]  r4:817efa40
[    4.778955] [&lt;801499a8&gt;] (kthread) from [&lt;80100130&gt;] (ret_from_fork+0x14/0x24)
[    4.786201] Exception stack(0x81c35fb0 to 0x81c35ff8)
[    4.791266] 5fa0:                                     00000000 00000000 00000000 00000000
[    4.799459] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.807651] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    4.814279]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801499a8
[    4.822120]  r4:817efa40
[    4.824664] Code: e3a02080 e593001c e3a01d33 e3a05000 (e5979018)

Split the registration from the STDP4028 probe routine and only perform
registration once both the STDP4028 and STDP2690 have probed.

Signed-off-by: Martyn Welch &lt;martyn.welch@collabora.com&gt;
CC: Peter Senna Tschudin &lt;peter.senna@gmail.com&gt;
CC: Martyn Welch &lt;martyn.welch@collabora.co.uk&gt;
CC: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
CC: Robert Foss &lt;robert.foss@linaro.org&gt;
CC: Laurent Pinchart &lt;Laurent.pinchart@ideasonboard.com&gt;
CC: Jonas Karlman &lt;jonas@kwiboo.se&gt;
CC: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Signed-off-by: Robert Foss &lt;robert.foss@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/43552c3404e8fdf92d8bc5658fac24e9f03c2c57.1637836606.git.martyn.welch@collabora.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm: panel-orientation-quirks: Add quirk for the Lenovo Yoga Book X91F/L</title>
<updated>2022-01-27T08:19:41+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2021-11-06T13:02:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a6252398812951206124027cc393aa951b65f386'/>
<id>urn:sha1:a6252398812951206124027cc393aa951b65f386</id>
<content type='text'>
[ Upstream commit bc30c3b0c8a1904d83d5f0d60fb8650a334b207b ]

The Lenovo Yoga Book X91F/L uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.

Cc: Yauhen Kharuzhy &lt;jekhor@gmail.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Simon Ser &lt;contact@emersion.fr&gt;
Tested-by: Yauhen Kharuzhy &lt;jekhor@gmail.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20211106130227.11927-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/nouveau/pmu/gm200-: avoid touching PMU outside of DEVINIT/PREOS/ACR</title>
<updated>2022-01-27T08:19:40+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2021-02-24T09:29:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c9ec3d85c0eef7c71cdc68db758e0f0e378132c0'/>
<id>urn:sha1:c9ec3d85c0eef7c71cdc68db758e0f0e378132c0</id>
<content type='text'>
[ Upstream commit 1d2271d2fb85e54bfc9630a6c30ac0feb9ffb983 ]

There have been reports of the WFI timing out on some boards, and a
patch was proposed to just remove it.  This stuff is rather fragile,
and I believe the WFI might be needed with our FW prior to GM200.

However, we probably should not be touching PMU during init on GPUs
where we depend on NVIDIA FW, outside of limited circumstances, so
this should be a somewhat safer change that achieves the desired
result.

Reported-by: Diego Viola &lt;diego.viola@gmail.com&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Reviewed-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Signed-off-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
