Age | Commit message (Collapse) | Author |
|
Make sure uvm_obj_init() is only called once. Call uvm_obj_destroy()
when we release the GEM object that wraps an uvm object for which we
called uvm_obj_init().
ok mpi@, jsg@
|
|
From Matthew Auld
d35d95e8b9da638d27bce9552262e0c486138343 in linux 5.10.y/5.10.71
c83ff0186401169eb27ce5057d820b7a863455c3 in mainline linux
|
|
From Hawking Zhang
9f382e1edf90ae03be43dbd4976c2a332cd7ce2d in linux 5.10.y/5.10.71
9f52c25f59b504a29dda42d83ac1e24d2af535d4 in mainline linux
|
|
From Charlene Liu
c331fad63b6d527193ae8b7c056b2f10fef53c81 in linux 5.10.y/5.10.71
d942856865c733ff60450de9691af796ad71d7bc in mainline linux
|
|
as asavvycomputist@disroot.org reported this occurs on gm45 (gen 4).
|
|
From Simon Ser
526261c1b706fec0ea80ce9f14c8fe8468bee34d in linux 5.10.y/5.10.70
7bbee36d71502ab9a341505da89a017c7ae2e6b2 in mainline linux
|
|
From Sami Tolvanen
55e6f8b3c0f5cc600df12ddd0371d2703b910fd7 in linux 5.10.y/5.10.70
4f0f586bf0c898233d8f316f471a21db2abd522d in mainline linux
|
|
From Lijo Lazar
68d4fbe6220cd1f3d07cab0a4901e62f8c12cc68 in linux 5.10.y/5.10.70
ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa in mainline linux
|
|
|
|
From Alex Deucher
8f0c93f454bd7ab04eaec1d3c436c4c7c2378f07 in mainline linux
|
|
From Koba Ko
45bd9dd1bee8aedc4cbd409b1ba7f9b4f941eea6 in linux 5.10.y/5.10.69
b3dc549986eb7b38eba4a144e979dc93f386751f in mainline linux
|
|
From Ernst Sjoestrand
8f95553f0016c3994d9c022b5af4a1a433d6714e in linux 5.10.y/5.10.68
67a44e659888569a133a8f858c8230e9d7aad1d5 in mainline linux
|
|
From Jerry (Fangzhi) Zuo
b80a99e048275d566d63f2463a2f640065ccbf75 in linux 5.10.y/5.10.67
a7a9d11e12fcc32160d55e8612e72e5ab51b15dc in mainline linux
|
|
From Aurabindo Pillai
583c4f3d09c3e980a683b59febbb0c775bdff1db in linux 5.10.y/5.10.67
0bbf06d888734041e813b916d7821acd4f72005a in mainline linux
|
|
From Andrey Grodzovsky
7b1abace16a9dff6804d4eb94750beb60d9502b4 in linux 5.10.y/5.10.67
ea7acd7c5967542353430947f3faf699e70602e5 in mainline linux
|
|
From Rajkumar Subbiah
bb693c114e8b53e3e0b8228be218d907d35959a5 in linux 5.10.y/5.10.67
92bd92c44d0d9be5dcbcda315b4be4b909ed9740 in mainline linux
|
|
From Sean Keely
0e9f4492219f8f991163691aad43897da8478c4e in linux 5.10.y/5.10.67
1ec06c2dee679e9f089e78ed20cb74ee90155f61 in mainline linux
|
|
From Tuo Li
83449db3aac0895147eac723bf23d0739720b968 in linux 5.10.y/5.10.67
554594567b1fa3da74f88ec7b2dc83d000c58e98 in mainline linux
|
|
access in amdgpu_i2c_router_select_ddc_port()
From Tuo Li
2254383788ff93a423e20068333b9f8376d56cb4 in linux 5.10.y/5.10.67
a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 in mainline linux
|
|
From Roy Chan
63ebc1f1df813ebb40d19449c356480555008166 in linux 5.10.y/5.10.67
781e1e23131cce56fb557e6ec2260480a6bd08cc in mainline linux
|
|
From Roy Chan
d763afc4ea2b251217ec87cf4c1e006c9f0aef99 in linux 5.10.y/5.10.67
82367e7f22d085092728f45fd5fbb15e3fb997c0 in mainline linux
|
|
From Anson Jacob
6f51f4241253974a6a147daecd5c20beb7450330 in linux 5.10.y/5.10.67
1a394b3c3de2577f200cb623c52a5c2b82805cec in mainline linux
|
|
From Oak Zeng
a5999d18a8d8c4c767c60d67fe6a6fe51b9a203d in linux 5.10.y/5.10.67
95f71f12aa45d65b7f2ccab95569795edffd379a in mainline linux
|
|
From Oliver Logush
f462a39eb8334b52e332cc0cbffb705660b7d87b in linux 5.10.y/5.10.67
23e55639b87fb16a9f0f66032ecb57060df6c46c in mainline linux
|
|
From Desmond Cheong Zhi Xi
34609faad0c9f9f08d4b59d25c94b78bf5710d93 in linux 5.10.y/5.10.67
56f0729a510f92151682ff6c89f69724d5595d6e in mainline linux
|
|
From Desmond Cheong Zhi Xi
06a553a99bacb00d3bc25f79e75c8e0fbf7a5025 in linux 5.10.y/5.10.67
0b0860a3cf5eccf183760b1177a1dcdb821b0b66 in mainline linux
|
|
From Desmond Cheong Zhi Xi
54e51d288b38377e8cd645a83e1ad08cc9d20ccc in linux 5.10.y/5.10.67
5eff9585de220cdd131237f5665db5e6c6bdf590 in mainline linux
|
|
From Luben Tuikov
10a135969fd7419695c003ddb67ef8a7820a808b in linux 5.10.y/5.10.67
dce4400e6516d18313d23de45b5be8a18980b00e in mainline linux
|
|
hardware is incorrect. In this case, make sure the amount of "stolen"
memory is at least as large as the EFI framebuffer such that the
driver doesn't use this memory until we've switched to the framebuffer
allocated by the amdgpu(4) driver.
Needs further investigation why the size reported by the hardware is
incorrect.
Tested by djm@
ok jsg@, deraadt@
|
|
From Kai-Heng Feng
1f60072320b5f8071946e4b765cbf78a34d22a67 in linux 5.10.y/5.10.65
aff890288de2d818e4f83ec40c9315e2d735df07 in mainline linux
|
|
From Mark Yacoub
6fd6e20520ccd05a1ac3321404dd498cc28576cb in linux 5.10.y/5.10.62
fa0b1ef5f7a694f48e00804a391245f3471aa155 in mainline linux
|
|
From Kenneth Feng
b00ca567579a4c2f9a4cd6f9a63946f793e8b506 in linux 5.10.y/5.10.62
93c5701b00d50d192ce2247cb10d6c0b3fe25cd8 in mainline linux
|
|
From Kenneth Feng
3c37ec4350220a548ffc6753646913899e86b1c7 in linux 5.10.y/5.10.62
2fd31689f9e44af949f60ff4f8aca013e628ab81 in mainline linux
|
|
From Matthew Brost
257ea8a5edc04d5199db83137fbaa24e1de98e9e in linux 5.10.y/5.10.62
a63bcf08f0efb5348105bb8e0e1e8c6671077753 in mainline linux
|
|
From Michel Daenzer
da3067eadcc156b742657c0694beae0a7c49d157 in linux 5.10.y/5.10.62
32bc8f8373d2d6a681c96e4b25dca60d4d1c6016 in mainline linux
|
|
when loading fails, it will just confuse people
ok jsg
|
|
This is currently a NOOP but will become necessary to unlock the UVM
object with the upcoing "vmobjlock" diff.
Tested by patrick@ and robert@
ok jsg@
|
|
use uvm_obj_init() to initialize the pager ops and initial reference count.
This will help future uvm unlocking diffs.
ok mpi@, jsg@
|
|
doesn't deal with non-GTT mappings. What the Linux code does here isn't
possible on OpenBSD and probably unecessary.
Seems to fix a crash reported by sthen@
ok jsg@
|
|
From Qingqing Zhuo
2e6cc93e1b8cf3ec2966961c1e98722ee7281023 in linux 5.10.y/5.10.61
c4152b297d56d3696ad0a9003169bc5b98ad7b72 in mainline linux
|
|
From Bing Guo
dcc8c5fb8d8595f5061c7b000ca1d16449a5e865 in linux 5.10.y/5.10.61
06050a0f01dbac2ca33145ef19a72041206ea983 in mainline linux
|
|
From Yifan Zhang
7525f2e4de0069983497a9d3eab1ca9813ae1b4b in linux 5.10.y/5.10.61
1c0539a6fc8a4a4b77278e35d763073890de96b9 in mainline linux
|
|
From Matt Roper
65395b053d03cb662e63cbf2c7e0faef8c15cb8c in linux 5.10.y/5.10.60
24d032e2359e3abc926b3d423f49a7c33e0b7836 in mainline linux
|
|
From Alex Deucher
95de3592f87e46df63119dd52b4a0e544e519c6b in linux 5.10.y/5.10.60
202ead5a3c589b0594a75cb99f080174f6851fed in mainline linux
|
|
From Anson Jacob
bd80d11a516c78fb74d11e69c67082f36f8ef8e3 in linux 5.10.y/5.10.60
0cde63a8fc4d9f9f580c297211fd05f91c0fd66d in mainline linux
|
|
From Eric Bernstein
ae311a7418f13be375c29ec4178baa51cd9101ba in linux 5.10.y/5.10.60
c90f6263f58a28c3d97b83679d6fd693b33dfd4e in mainline linux
|
|
prompted by jcs@ reporting a protection fault trap in
drm_mode_rmfb_work_fn() while playing a youtube video in firefox on a
kaby lake machine. He later saw the same trace on tiger lake.
The previous attempt to avoid this situation by changing work flush
functions from taskq_barrier() to taskq_del_barrier() resulted in
suspend sometimes not working on various intel based thinkpads.
The only code we build which calls destroy_work_on_stack() is in
drm_framebuffer.c so the scope of this change is more limited.
Linux only uses destroy_work_on_stack() for debugging so the workqueue
behaviour still doesn't match.
This version is confirmed to not break suspend on x260 by sthen@ and
x280 by tb@ and still avoids the original problem according to jcs@
|
|
From Alex Deucher
bb65051dcd1fd380a73ca52c87f89522e15bf62d in linux 5.10.y/5.10.58
f2ad3accefc63e72e9932e141c21875cc04beec8 in mainline linux
|
|
From Matt Roper
7397034905acaecbc64f6838779bdc81667e682f in linux 5.10.y/5.10.58
9c9c6d0ab08acfe41c9f7efa72c4ad3f133a266b in mainline linux
|
|
From Shirish S
dd3f7c5c890450ab2ad6f269a3fdf7bcd6fc2908 in linux 5.10.y/5.10.58
0e99e960ce6d5ff586fc0733bc393c087f52c27b in mainline linux
|