[Bug 109007] radeonsi cache format changed, causes mesa crash on startup
https://bugs.freedesktop.org/show_bug.cgi?id=109007 Daniel Drake changed: What|Removed |Added CC||mar...@gmail.com --- Comment #1 from Daniel Drake --- The on-disk cache format change was introduced by radeonsi: move max_simd_waves computation into a separate function https://github.com/mesa3d/mesa/commit/c02c9ee550d137fbea3ed105131d621d6af5813b -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD
On 11.12.2018 00:45, Inki Dae wrote: > Hi Andrzej, > > 18. 12. 10. 오후 4:35에 Andrzej Hajda 이(가) 쓴 글: >> Hi Inki, >> >> On 10.12.2018 03:25, Inki Dae wrote: >>> Hi Andrzej, >>> >>> 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글: Hi Inki, This small patchset adds dynamic zpos support for DECON and FIMD. >>> This patch will allow user space to change zpos. However, DECON and FIMD >>> devices have fixed priority of HW overlays. >>> This would mean that zpos change by user space doesn't guarantee correct HW >>> overlay priority. >>> >>> Why do you want to support mutable zpos? >> >> Practically you have patches which proves it works, you can see that >> changing zpos value results in adequate change in displayed image. >> >> Conceptually it is just a matter of disconnecting hardware windows >> present in DECON and FIMD from DRM planes which are software entities. >> >> You can reason about it this way: >> >> - drm plane is a framebuffer plus informations how it should be >> transformed/displayed on DECON/FIMD, >> >> - hw window in DECON/FIMD is just a channel through which plane is send >> to the display. >> >> DECON and FIMD has fixed hw windows order - windows with lower numbers >> are displayed below windows with higher number. To display planes in >> given z-order you just need to send them via windows with appropriate >> index - farthest plane should go always via win0, closer one via win1, >> ..., till the last plane. >> >> So for example if you have three planes and want to display them in >> following order (first one farthest, last one closest): >> >> plane2, plane1, plane3 >> >> you should map them to planes as follow: >> >> plane2 -> win0, plane1 -> win1, plane3 -> win2 >> >> then for example plane2 is disabled, we will have following mapping: >> >> plane1 -> win0, plane3 -> win1, win2 - disabled > Plane1 is displayed below Plane3. And this is what we wanted, the initial order was: plane2, plane1, plane3, first farthest (or lowest if you prefer this naming schema). > >> then if you change zorder of planes to: plane3, plane1: >> >> plane3 -> win0, plane1 -> win1 > Plane3 is displayed below Plane1 because DECON/FIMD HW aren't able to change > HW overlay priroty. No, plane3 is displayed below plane1 because we sent it via win0, if we want inverse we can send plane3 via win1 and plane1 via win0. > However, user space wanted that Plane1 is displayed below Plane3. Like this, > zpos change by user space doesn't guarantee correct HW overlay priority. As I said before in this example userspace wanted plane3 below plane1, and as I wrote in comment above any order of planes user want driver is able to realize with this patch. > And there is no any reason to change zpos in user space excepting Mixer > device which supports HW overlay priority change. Lack of special registry for manipulating windows order does not mean it cannot support dynamic zpos. > In fact, we supported mutable zpos before but changed it to immutable with > same reason. It was just broken if I remember correctly. > > Lastly, your patch made real user broken. Who? How? Regards Andrzej > > Thanks, > Inki Dae > >> >> As you see there is no relation between plane number and window number, >> but window number is equal to plane's position in zpos-ordered list of >> planes and this is exact value of normalized_zpos field in drm_plane_state. >> >> >> I hope this extended explanation will clarify things. >> >> >> Regards >> >> Andrzej >> >> >> >>> Thanks, >>> Inki Dae >>> It was tested on tm2 and trats2. Regards Andrzej Andrzej Hajda (3): drm/exynos/decon5433: add dynamic zpos support drm/exynos/fimd: create local helper for disabling hardware window drm/exynos/fimd: add dynamic zpos support drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 23 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 --- 2 files changed, 29 insertions(+), 36 deletions(-) >> >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109007] radeonsi cache format changed, causes mesa crash on startup
https://bugs.freedesktop.org/show_bug.cgi?id=109007 Bug ID: 109007 Summary: radeonsi cache format changed, causes mesa crash on startup Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: d...@reactivated.net QA Contact: dri-devel@lists.freedesktop.org Having upgraded from Mesa-17.3 to Mesa-18.1 in Endless OS, many users on AMD-based platforms are now reporting that the system fails to boot into the UI. I've reproduced and confirm that Xorg is crashing very early on. Thread 4 "si_shader:0" received signal SIGSEGV, Segmentation fault. __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1533 Backtrace: #0 __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1533 #1 0x7fffeeba2038 in memcpy (__len=3221880836, __src=0x7fffe4000e70, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 read_data (size=3221880836, data=, ptr=0x7fffe4000e70) at ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:95 #3 read_chunk (ptr=0x7fffe4000e70, ptr@entry=0x7fffe4000e6c, data=data@entry=0x7fffe4000998, size=size@entry=0x7fffe4000980) at ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:121 #4 0x7fffeeba21b3 in si_load_shader_binary ( shader=shader@entry=0x7fffe40008c0, binary=binary@entry=0x7fffe4000e00) at ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:187 #5 0x7fffeeba4810 in si_shader_cache_load_shader (shader=0x7fffe40008c0, ir_binary=0x7fffe4000a50, sscreen=0x55a393a0) at ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:275 #6 si_init_shader_selector_async (job=job@entry=0x55b8dfa0, thread_index=thread_index@entry=0) at ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1875 #7 0x7fffee747a55 in util_queue_thread_func ( input=input@entry=0x55a39fb0) at ../../../src/util/u_queue.c:271 #8 0x7fffee7476c7 in impl_thrd_routine (p=) at ../../../include/c11/threads_posix.h:87 #9 0x7574d494 in start_thread (arg=0x7fffebe06700) The problem here is that the on-disk radeonsi cache format changed without consideration for this in the code. The affected codepath is si_load_shader_binary() which does: uint32_t size = *ptr++; uint32_t crc32 = *ptr++; [...] ptr = read_data(ptr, >config, sizeof(shader->config)); ptr = read_data(ptr, >info, sizeof(shader->info)); ptr = read_chunk(ptr, (void**)>binary.code, >binary.code_size); So, the blob format is: 4 bytes size, 4 bytes CRC, shader config, shader info, code. In mesa-17.3 the si_shader_config was 48 bytes in size, but in Mesa-18.1 and current master, si_shader_config is 52 bytes in size, because the max_simd_wave field was added. After upgrading mesa to 18.1, with shaders compiled and cached by mesa-17.3, now the above code will obviously not behave as intended. We enter into read_chunk() with the offsets slightly wrong: *size = *ptr++; assert(*data == NULL); if (!*size) return ptr; *data = malloc(*size); return read_data(ptr, *data, *size); and when this code executes, *size has value 3221880836, for a shader that was only 884 bytes uncompressed. read_data then tries to memcpy this much data, and that causes the crash. In addition to the lack of invalidation of existing disk caches after the on-disk format was changed, this code also seems rather suspect in that it does not verify that it is not reading beyond the end of the shader. As an attacker I could maliciously rewrite the size field read by the read_chunk() code above to be very large, fixup the CRC and recompress, and then I could cause other apps to crash in this way. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108671] Massive Screen Artifacting on linux 4.19+
https://bugs.freedesktop.org/show_bug.cgi?id=108671 coolo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from coolo...@gmail.com --- Also working on 4.19.8 closing -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau-next 4.21
Hey Dave, Mostly just initial support for Turing TU104/TU106 chipsets. Support for TU102 is missing as I don't yet have HW, but it should be trivial to add in later in the merge window (in theory). It's a bit of a rough first pass that'll get improved in future releases as a finish figuring out some of the other HW changes, but it's good enough as it stands for modesetting and suspend/resume etc. Acceleration bring-up is incomplete due to NVIDIA not yet having provided FW images for me to use, though command submission and copy engines are functional already. Thanks, Ben. The following changes since commit e69aa5f9b97f7f871643336deb281db5cb14878b: Merge tag 'drm-misc-next-2018-12-06' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-12-07 11:23:05 +1000) are available in the Git repository at: git://github.com/skeggsb/linux linux-4.21 for you to fetch changes up to 8ff01abcccbb563fbf50b84a476bd9b22c42c0a3: drm/nouveau/ce/tu106: initial support (2018-12-11 15:38:01 +1000) Ben Skeggs (72): drm/nouveau/core: support multiple nvdec instances drm/nouveau/bios: translate additional memory types drm/nouveau/bios: translate USB-C connector type drm/nouveau/devinit/gm200-: export function to upload+execute PMU/PRE_OS drm/nouveau/tmr: detect stalled gpu timer and break out of waits drm/nouveau/imem/nv50: support pinning objects in BAR2 and returning address drm/nouveau/fault: remove manual mapping of fault buffers into BAR2 drm/nouveau/fault: store get/put pri address in nvkm_fault_buffer drm/nouveau/fault: add explicit control over fault buffer interrupts drm/nouveau/mmu: add more general vmm free/node handling functions drm/nouveau/disp/gv100: fix name of window channels in debug output drm/nouveau/fifo/gf100-: call into BAR to reset BARs after MMU fault drm/nouveau/fifo/gk104-: return channel instance in ctor args drm/nouveau/fifo/gk104-: support enabling privileged ce functions drm/nouveau/fifo/gk104-: separate runlist building from committing to hw drm/nouveau/fifo/gk104-: group pbdma functions together drm/nouveau/fifo/gk104-: virtualise pbdma enable function drm/nouveau/fifo/gm200-: read pbdma count more directly drm/nouveau/fifo/gv100: allocate method buffer drm/nouveau/fifo/gv100: return work submission token in channel ctor args drm/nouveau: remove left-over struct member drm/nouveau/kms/nv50-: allow more flexibility with lut formats drm/nouveau/core: recognise TU104 drm/nouveau/pci/tu104: initial support drm/nouveau/bios/tu104: initial support drm/nouveau/devinit/tu104: initial support drm/nouveau/top/tu104: initial support drm/nouveau/ibus/tu104: initial support drm/nouveau/gpio/tu104: initial support drm/nouveau/i2c/tu104: initial support drm/nouveau/fuse/tu104: initial support drm/nouveau/mc/tu104: initial support drm/nouveau/bus/tu104: initial support drm/nouveau/tmr/tu104: initial support drm/nouveau/imem/tu104: initial support drm/nouveau/fb/tu104: initial support drm/nouveau/ltc/tu104: initial support drm/nouveau/mmu/tu104: initial support drm/nouveau/bar/tu104: initial support drm/nouveau/fault/tu104: initial support drm/nouveau/pmu/tu104: initial support drm/nouveau/therm/tu104: initial support drm/nouveau/dma/tu104: initial support drm/nouveau/disp/tu104: initial support drm/nouveau/fifo/tu104: initial support drm/nouveau/ce/tu104: initial support drm/nouveau/kms/tu104: initial support drm/nouveau/core: increase maximum number of nvdec instances to 3 drm/nouveau/core: recognise TU106 drm/nouveau/pci/tu106: initial support drm/nouveau/bios/tu106: initial support drm/nouveau/devinit/tu106: initial support drm/nouveau/top/tu106: initial support drm/nouveau/ibus/tu106: initial support drm/nouveau/gpio/tu106: initial support drm/nouveau/i2c/tu106: initial support drm/nouveau/fuse/tu106: initial support drm/nouveau/mc/tu106: initial support drm/nouveau/bus/tu106: initial support drm/nouveau/tmr/tu106: initial support drm/nouveau/imem/tu106: initial support drm/nouveau/fb/tu106: initial support drm/nouveau/ltc/tu106: initial support drm/nouveau/mmu/tu106: initial support drm/nouveau/bar/tu106: initial support drm/nouveau/fault/tu106: initial support drm/nouveau/pmu/tu106: initial support drm/nouveau/therm/tu106: initial support drm/nouveau/dma/tu106: initial support drm/nouveau/disp/tu106: initial support drm/nouveau/fifo/tu106: initial support drm/nouveau/ce/tu106: initial support Lyude Paul (4): drm/nouveau: Add strap_peek to debugfs drm/nouveau: Add size to
[Bug 108671] Massive Screen Artifacting on linux 4.19+
https://bugs.freedesktop.org/show_bug.cgi?id=108671 --- Comment #13 from coolo...@gmail.com --- Seems fixed on 4.20rc5 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109001] Freezes when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=109001 --- Comment #5 from L.S.S. --- I'm not sure about the freeze you experienced. I'm having similar issues on latest Manjaro (4.18-4.19) that after wakeup, there are intermittent screen freezes for a few seconds every 2-3 minutes. Aside from the good old VBLANK-related error messages (like those in the attached dmesg), no more errors are being recorded in the log except the system keeps freezing like that unless I reboot. The patches in my old bug report (which were eventually merged at some time around 4.17) did not fix the root cause but at least fixed the 100% reproducible kernel panic I used to have. The problem has been observed on the same laptop I use for work (which was also the one I used to test and report the previous bug), and for that reason, I'm still not confident about locking the screen (since LightDM GTK Greeter doesn't honor the "Timeout until the screen blanks", nor related settings in power options), as the risk of losing unsaved work is still there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau-fixes 4.20
Hey Dave, Single fix for a Tegra regression. Thanks, Ben. The following changes since commit 4a07c0a59fa372b069d879971ba4d9e341979cf: drm/nouveau/secboot/acr: fix memory leak (2018-10-11 09:54:10 +1000) are available in the Git repository at: git://github.com/skeggsb/linux linux-4.20 for you to fetch changes up to 4ac0a807da6f79d5f2a65f991030aee503fece3a: drm/nouveau/drm/nouveau: tegra: Call nouveau_drm_device_init() (2018-12-11 14:55:28 +1000) Thierry Reding (1): drm/nouveau/drm/nouveau: tegra: Call nouveau_drm_device_init() drivers/gpu/drm/nouveau/nouveau_drm.c | 6 ++ 1 file changed, 6 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] New: amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 Bug ID: 201957 Summary: amdgpu: ring gfx timeout Product: Drivers Version: 2.5 Kernel Version: 4.19.8, 4.20-rc5 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: felix.adria...@gmail.com Regression: No Error message: [Dec 5 22:08] amdgpu :23:00.0: GPU fault detected: 146 0x480c for process yuzu pid 2920 thread yuzu:cs0 pid 2935 [ +0.05] amdgpu :23:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ +0.02] amdgpu :23:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0604800C [ +0.03] amdgpu :23:00.0: VM fault (0x0c, vmid 3, pasid 32770) at page 0, read from 'TC4' (0x54433400) (72) [ +10.053011] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=37241, emitted seq=37244 [ +0.07] [drm] GPU recovery disabled. How to reproduce the issue: 1. Playing with yuzu-emulator 2. Load Super Mario Odyssey 3. Start new game 4. When Mario is about to jump for the first time after being woken up by Cappy, this bug must occur. During the issue, the following occured: 1. Graphic locked up. 2. System can be access through SSH. System specification: Debian Sid Radeon RX 580 I have tried the following combination: 1. Kernel 4.17, 4.18, 4.19, 4.20, drm-next-4.21.wip 2. Mesa 18.2, 18.3, 19.0-development branch But none of the above combination fixes the issue. Let me know if you need more information and more testing from me. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109006] Hotplugging DP1.2 monitor(s) causes machine to hang waiting for page flip
https://bugs.freedesktop.org/show_bug.cgi?id=109006 Bug ID: 109006 Summary: Hotplugging DP1.2 monitor(s) causes machine to hang waiting for page flip Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: h...@is.fucking.moe Created attachment 142774 --> https://bugs.freedesktop.org/attachment.cgi?id=142774=edit dmesg: DRM call stack Greetings, I am using kernel 4.19.8, I have two 4K panels which have DP1.2 inputs as well as an AMD RX560 GPU[1]. I am experiencing an issue where my machine softlocks when they are disconnected & subsequently reconnected. If the monitors are power-cycled ,or the DP cable is hotplugged, my kernel log slowly accumulates messages like "*ERROR* [PLANE:36:plane-0] flip_done timed out" meanwhile my graphical environment hangs, waiting for the pageflip which never successfully happens. One of my monitors also happens be HDMI2.0 capable, and when connected via HDMI that monitor *does not* lock up the machine in this way, so I believe this issue to be DisplayPort specific. Attached is a dmesg from a recent session exhibiting such a softlock, the relevant portions are near the end. All my softlocks have `RIP: 0010:prepare_flip_isr+0x5f/0x70 [amdgpu]` in common. I will note that the driver does seem to at least partially initialize the monitors upon reconnection, as they do not display "no signal" nor enter sleep mode. [1]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] [1002:67ff] (rev cf) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/5] drm/dp: Implement I2C_M_STOP for i2c-over-aux
On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Consult the I2C_M_STOP flag to determine whether to set the MOT bit
> or
> not. Makes it possible to send multiple messages in one go with
> stop+start generated between the messages (as opposed nothing or
> repstart depending on whether thr address/rw changed).
>
> Not sure anyone has actual use for this but figured I'd handle it
> since I started to look at that flag for MST remote i2c xfers.
>
Don't see the I2C_M_STOP flag anywhere in drm_edid.c, but the change
introduced here does make sense.
Reviewed-by: Dhinakaran Pandiyan
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 37c01b6076ec..e85cea299d2a 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -884,7 +884,8 @@ static void drm_dp_i2c_msg_set_request(struct
> drm_dp_aux_msg *msg,
> {
> msg->request = (i2c_msg->flags & I2C_M_RD) ?
> DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
> - msg->request |= DP_AUX_I2C_MOT;
> + if (!(i2c_msg->flags & I2C_M_STOP))
> + msg->request |= DP_AUX_I2C_MOT;
> }
>
> /*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 2/2] drm/sched: Rework HW fence processing.
I don't think adding cb to sched job would work as soon as their lifetime is
different with fence.
Unless you make the sched job reference, otherwise we will get trouble sooner
or later.
-David
> -Original Message-
> From: amd-gfx On Behalf Of
> Andrey Grodzovsky
> Sent: Tuesday, December 11, 2018 5:44 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ckoenig.leichtzumer...@gmail.com; e...@anholt.net;
> etna...@lists.freedesktop.org
> Cc: Zhou, David(ChunMing) ; Liu, Monk
> ; Grodzovsky, Andrey
>
> Subject: [PATCH v3 2/2] drm/sched: Rework HW fence processing.
>
> Expedite job deletion from ring mirror list to the HW fence signal callback
> instead from finish_work, together with waiting for all such fences to signal
> in
> drm_sched_stop we garantee that already signaled job will not be processed
> twice.
> Remove the sched finish fence callback and just submit finish_work directly
> from the HW fence callback.
>
> v2: Fix comments.
>
> v3: Attach hw fence cb to sched_job
>
> Suggested-by: Christian Koenig
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 58 --
>
> include/drm/gpu_scheduler.h| 6 ++--
> 2 files changed, 30 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index cdf95e2..f0c1f32 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -284,8 +284,6 @@ static void drm_sched_job_finish(struct work_struct
> *work)
> cancel_delayed_work_sync(>work_tdr);
>
> spin_lock_irqsave(>job_list_lock, flags);
> - /* remove job from ring_mirror_list */
> - list_del_init(_job->node);
> /* queue TDR for next job */
> drm_sched_start_timeout(sched);
> spin_unlock_irqrestore(>job_list_lock, flags); @@ -293,22
> +291,11 @@ static void drm_sched_job_finish(struct work_struct *work)
> sched->ops->free_job(s_job);
> }
>
> -static void drm_sched_job_finish_cb(struct dma_fence *f,
> - struct dma_fence_cb *cb)
> -{
> - struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
> - finish_cb);
> - schedule_work(>finish_work);
> -}
> -
> static void drm_sched_job_begin(struct drm_sched_job *s_job) {
> struct drm_gpu_scheduler *sched = s_job->sched;
> unsigned long flags;
>
> - dma_fence_add_callback(_job->s_fence->finished, _job-
> >finish_cb,
> -drm_sched_job_finish_cb);
> -
> spin_lock_irqsave(>job_list_lock, flags);
> list_add_tail(_job->node, >ring_mirror_list);
> drm_sched_start_timeout(sched);
> @@ -359,12 +346,11 @@ void drm_sched_stop(struct drm_gpu_scheduler
> *sched, struct drm_sched_job *bad,
> list_for_each_entry_reverse(s_job, >ring_mirror_list, node)
> {
> if (s_job->s_fence->parent &&
> dma_fence_remove_callback(s_job->s_fence->parent,
> - _job->s_fence->cb)) {
> + _job->cb)) {
> dma_fence_put(s_job->s_fence->parent);
> s_job->s_fence->parent = NULL;
> atomic_dec(>hw_rq_count);
> - }
> - else {
> + } else {
> /* TODO Is it get/put neccessey here ? */
> dma_fence_get(_job->s_fence->finished);
> list_add(_job->finish_node, _list); @@ -
> 417,31 +403,34 @@ EXPORT_SYMBOL(drm_sched_stop); void
> drm_sched_start(struct drm_gpu_scheduler *sched, bool unpark_only) {
> struct drm_sched_job *s_job, *tmp;
> - unsigned long flags;
> int r;
>
> if (unpark_only)
> goto unpark;
>
> - spin_lock_irqsave(>job_list_lock, flags);
> + /*
> + * Locking the list is not required here as the sched thread is parked
> + * so no new jobs are being pushed in to HW and in drm_sched_stop
> we
> + * flushed all the jobs who were still in mirror list but who already
> + * signaled and removed them self from the list. Also concurrent
> + * GPU recovers can't run in parallel.
> + */
> list_for_each_entry_safe(s_job, tmp, >ring_mirror_list,
> node) {
> - struct drm_sched_fence *s_fence = s_job->s_fence;
> struct dma_fence *fence = s_job->s_fence->parent;
>
> if (fence) {
> - r = dma_fence_add_callback(fence, _fence->cb,
> + r = dma_fence_add_callback(fence, _job->cb,
> drm_sched_process_job);
> if (r == -ENOENT)
> - drm_sched_process_job(fence, _fence-
> >cb);
> + drm_sched_process_job(fence, _job->cb);
>
Re: next/master boot bisection: Oops in nouveau driver on jetson-tk1
On Mon, Dec 10, 2018 at 05:26:22PM +0100, Thierry Reding wrote: > On Mon, Dec 10, 2018 at 02:25:59PM +, Mark Brown wrote: > > This has been broken for a considerable time now with no response from > > Ben - is there some other path we can use to get the fix merged? > I suppose we could go directly via Dave. But Ben's usually pretty > responsive, so he probably just missed it. Let me ping him on IRC, maybe > that'll get his attention. This is at least the third go at reporting this as a boot failure IIRC so these clearly aren't doing the trick :/ . Perhaps a resend as well? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: fix arm64 build error
On Mon, Dec 10, 2018 at 3:56 PM Arnd Bergmann wrote:
>
> The new a200 GPU MMU support fails to build on arm64 because
> of a conflicting macro name:
>
> drivers/gpu/drm/msm/msm_gpummu.c:17: error: "VA_START" redefined [-Werror]
> #define VA_START SZ_16M
>
> In file included from arch/arm64/include/asm/pgtable-hwdef.h:19,
> from arch/arm64/include/asm/processor.h:48,
> from include/linux/mutex.h:19,
> from include/linux/notifier.h:14,
> from include/linux/clk.h:17,
> from drivers/gpu/drm/msm/msm_drv.h:23,
> from drivers/gpu/drm/msm/msm_gpummu.c:4:
> arch/arm64/include/asm/memory.h:51: note: this is the location of the
> previous definition
> #define VA_START (UL(0x) - \
>
> Rename this and the related macros with a GPU_ prefix.
>
> Fixes: 1c0088f255ae ("drm/msm: implement a2xx mmu")
> Signed-off-by: Arnd Bergmann
fyi I've updated this patch in msm-next/linux-next with a fixup from
Jonathan which prefixes these with GPUMMU_*
not entirely sure why I didn't hit this build error locally, but
thanks to you and kbuild-robot for noticing so we could fix
BR,
-R
> ---
> drivers/gpu/drm/msm/msm_gpummu.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpummu.c
> b/drivers/gpu/drm/msm/msm_gpummu.c
> index f1dc2b7e5fd3..2a7ddd449d3d 100644
> --- a/drivers/gpu/drm/msm/msm_gpummu.c
> +++ b/drivers/gpu/drm/msm/msm_gpummu.c
> @@ -14,10 +14,10 @@ struct msm_gpummu {
> };
> #define to_msm_gpummu(x) container_of(x, struct msm_gpummu, base)
>
> -#define VA_START SZ_16M
> -#define VA_RANGE (0xfff * SZ_64K)
> -#define MMU_PAGE_SIZE SZ_4K
> -#define TABLE_SIZE (sizeof(uint32_t) * VA_RANGE / MMU_PAGE_SIZE)
> +#define GPU_VA_START SZ_16M
> +#define GPU_VA_RANGE (0xfff * SZ_64K)
> +#define GPU_MMU_PAGE_SIZE SZ_4K
> +#define GPU_TABLE_SIZE (sizeof(uint32_t) * GPU_VA_RANGE / GPU_MMU_PAGE_SIZE)
>
> static int msm_gpummu_attach(struct msm_mmu *mmu, const char * const *names,
> int cnt)
> @@ -34,7 +34,7 @@ static int msm_gpummu_map(struct msm_mmu *mmu, uint64_t
> iova,
> struct sg_table *sgt, unsigned len, int prot)
> {
> struct msm_gpummu *gpummu = to_msm_gpummu(mmu);
> - unsigned idx = (iova - VA_START) / MMU_PAGE_SIZE;
> + unsigned idx = (iova - GPU_VA_START) / GPU_MMU_PAGE_SIZE;
> struct scatterlist *sg;
> unsigned prot_bits = 0;
> unsigned i, j;
> @@ -46,9 +46,9 @@ static int msm_gpummu_map(struct msm_mmu *mmu, uint64_t
> iova,
>
> for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> dma_addr_t addr = sg->dma_address;
> - for (j = 0; j < sg->length / MMU_PAGE_SIZE; j++, idx++) {
> + for (j = 0; j < sg->length / GPU_MMU_PAGE_SIZE; j++, idx++) {
> gpummu->table[idx] = addr | prot_bits;
> - addr += MMU_PAGE_SIZE;
> + addr += GPU_MMU_PAGE_SIZE;
> }
> }
>
> @@ -62,10 +62,10 @@ static int msm_gpummu_map(struct msm_mmu *mmu, uint64_t
> iova,
> static int msm_gpummu_unmap(struct msm_mmu *mmu, uint64_t iova, unsigned len)
> {
> struct msm_gpummu *gpummu = to_msm_gpummu(mmu);
> - unsigned idx = (iova - VA_START) / MMU_PAGE_SIZE;
> + unsigned idx = (iova - GPU_VA_START) / GPU_MMU_PAGE_SIZE;
> unsigned i;
>
> - for (i = 0; i < len / MMU_PAGE_SIZE; i++, idx++)
> + for (i = 0; i < len / GPU_MMU_PAGE_SIZE; i++, idx++)
> gpummu->table[idx] = 0;
>
> gpu_write(gpummu->gpu, REG_A2XX_MH_MMU_INVALIDATE,
> @@ -78,7 +78,7 @@ static void msm_gpummu_destroy(struct msm_mmu *mmu)
> {
> struct msm_gpummu *gpummu = to_msm_gpummu(mmu);
>
> - dma_free_attrs(mmu->dev, TABLE_SIZE, gpummu->table, gpummu->pt_base,
> + dma_free_attrs(mmu->dev, GPU_TABLE_SIZE, gpummu->table,
> gpummu->pt_base,
> DMA_ATTR_FORCE_CONTIGUOUS);
>
> kfree(gpummu);
> @@ -100,7 +100,7 @@ struct msm_mmu *msm_gpummu_new(struct device *dev, struct
> msm_gpu *gpu)
> if (!gpummu)
> return ERR_PTR(-ENOMEM);
>
> - gpummu->table = dma_alloc_attrs(dev, TABLE_SIZE + 32,
> >pt_base,
> + gpummu->table = dma_alloc_attrs(dev, GPU_TABLE_SIZE + 32,
> >pt_base,
> GFP_KERNEL | __GFP_ZERO, DMA_ATTR_FORCE_CONTIGUOUS);
> if (!gpummu->table) {
> kfree(gpummu);
> @@ -119,5 +119,5 @@ void msm_gpummu_params(struct msm_mmu *mmu, dma_addr_t
> *pt_base,
> dma_addr_t base = to_msm_gpummu(mmu)->pt_base;
>
> *pt_base = base;
> - *tran_error = base + TABLE_SIZE; /* 32-byte aligned */
> + *tran_error = base + GPU_TABLE_SIZE; /* 32-byte aligned */
> }
> --
> 2.20.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD
Hi Andrzej, 18. 12. 10. 오후 4:35에 Andrzej Hajda 이(가) 쓴 글: > Hi Inki, > > On 10.12.2018 03:25, Inki Dae wrote: >> Hi Andrzej, >> >> 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글: >>> Hi Inki, >>> >>> This small patchset adds dynamic zpos support for DECON and FIMD. >> This patch will allow user space to change zpos. However, DECON and FIMD >> devices have fixed priority of HW overlays. >> This would mean that zpos change by user space doesn't guarantee correct HW >> overlay priority. >> >> Why do you want to support mutable zpos? > > > Practically you have patches which proves it works, you can see that > changing zpos value results in adequate change in displayed image. > > Conceptually it is just a matter of disconnecting hardware windows > present in DECON and FIMD from DRM planes which are software entities. > > You can reason about it this way: > > - drm plane is a framebuffer plus informations how it should be > transformed/displayed on DECON/FIMD, > > - hw window in DECON/FIMD is just a channel through which plane is send > to the display. > > DECON and FIMD has fixed hw windows order - windows with lower numbers > are displayed below windows with higher number. To display planes in > given z-order you just need to send them via windows with appropriate > index - farthest plane should go always via win0, closer one via win1, > ..., till the last plane. > > So for example if you have three planes and want to display them in > following order (first one farthest, last one closest): > > plane2, plane1, plane3 > > you should map them to planes as follow: > > plane2 -> win0, plane1 -> win1, plane3 -> win2 > > then for example plane2 is disabled, we will have following mapping: > > plane1 -> win0, plane3 -> win1, win2 - disabled Plane1 is displayed below Plane3. > > then if you change zorder of planes to: plane3, plane1: > > plane3 -> win0, plane1 -> win1 Plane3 is displayed below Plane1 because DECON/FIMD HW aren't able to change HW overlay priroty. However, user space wanted that Plane1 is displayed below Plane3. Like this, zpos change by user space doesn't guarantee correct HW overlay priority. And there is no any reason to change zpos in user space excepting Mixer device which supports HW overlay priority change. In fact, we supported mutable zpos before but changed it to immutable with same reason. Lastly, your patch made real user broken. Thanks, Inki Dae > > > As you see there is no relation between plane number and window number, > but window number is equal to plane's position in zpos-ordered list of > planes and this is exact value of normalized_zpos field in drm_plane_state. > > > I hope this extended explanation will clarify things. > > > Regards > > Andrzej > > > >> >> Thanks, >> Inki Dae >> >>> It was tested on tm2 and trats2. >>> >>> Regards >>> Andrzej >>> >>> >>> Andrzej Hajda (3): >>> drm/exynos/decon5433: add dynamic zpos support >>> drm/exynos/fimd: create local helper for disabling hardware window >>> drm/exynos/fimd: add dynamic zpos support >>> >>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 23 +- >>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 --- >>> 2 files changed, 29 insertions(+), 36 deletions(-) >>> >> > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC] MAINTAINERS: Daniel for drm co-maintainer
Daniel Vetter writes: > lkml and Linus gained a CoC, and it's serious this time. Which means > my no 1 reason for declining to officially step up as drm maintainer > is gone, and I didn't find any new good excuse. > > I chatted with a few people in private already, and the biggest > concern is that I mislay my community hat and start running around > with my intel hat only. Or some other convenient abuse of trust. > > That's why this patch doesn't just need a lot of acks that mean "yeah > seems fine to me", but a lot of acks that mean "yeah we'll tell you > when you're over the line and usurp you from that comfy chair if you > don't get it". Which I think we've been done a fairly good job here at > dri-devel in general, but better to be clear. > > Rough idea is that I'll do this for maybe 2-3 years, helping Dave > figure out a group model for drm overall. And getting the tooling and > infrastructure for that off the ground. Then step down again because > some other shiny thing that needs chasing. Of course as plans tend to > do, this one will probably pan out a bit different in reality. You've been an excellent leader of our community so far, and I don't expect that to change just because you officially wear a new hat. Acked-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5/rc6, amdgpu error
https://bugs.freedesktop.org/show_bug.cgi?id=108992 --- Comment #2 from Brian Schott --- I have the same issue with a 2700U in a Dell Inspiron 7375. All of the 4.20 RC versions that I have tried show the same problem. The system is able to boot with a 4.19 kernel. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware
https://bugs.freedesktop.org/show_bug.cgi?id=108919 --- Comment #8 from Timothy Arceri --- (In reply to Alexander Walker from comment #7) > (In reply to Timothy Arceri from comment #5) > > Can somebody try to get an apitrace of the issue [1]? Thanks. > > > > [1] https://github.com/apitrace/apitrace/wiki/Steam > > Never used that tool before but I uploaded a trace that shows it immediately > visible on the main menu. > > Lots of these in the console if they're relevant: > apitrace: warning: _gl_param_size: unknown GLenum 0x8267 > apitrace: warning: _gl_param_size: unknown GLenum 0x92F5 I'm not sure, I don't see these when replying the trace. Aside from some calls to unsupported debug functions I don't see any obvious issues in the trace. Do you think you could try grabbing a capture in renderdoc [1]? Once you unzip it somewhere you can add the following to the launch options for the game in steam: LD_PRELOAD=/your path to renderdoc here/renderdoc_1.2/lib/librenderdoc.so %command% When you lanuch the game you should see some text overlayed at the top of the screen saying you can create a capture by pressing F12. Once you have a capture you can find it in a folder in the /tmp/ directory. [1] https://renderdoc.org/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
On Mon, 2018-12-10 at 23:29 +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT
> > bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a type. We're just preserving MOT. What makes you think it
> should always be set?
>
The table defining request commands (2-148) has the MOT bit set for
Write_Status_Update_Request, doesn't make it look like an option when
querying the status. Checking the callers again, I see that we could
get a defer when ending an i2c transaction and that will require a
Write_Status_Update_Request with MOT unset. Sorry for the noise.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain
> > partial I2C_WRITE requests")
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 2d6c491a0542..d98805b517f0 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -677,7 +677,7 @@ static void
> > drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
> > * rest of the message
> > */
> > if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
> > - msg->request &= DP_AUX_I2C_MOT;
> > + msg->request |= DP_AUX_I2C_MOT;
> > msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
> > }
> > }
> > --
> > 2.17.1
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] host1x: cdma: use completion instead of semaphore
In this usage, the two are completely equivalent, but the
completion documents better what is going on, and we generally
try to avoid semaphores these days.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/host1x/cdma.c | 6 +++---
drivers/gpu/host1x/cdma.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 6bfb3e6f43d7..bdc80a303cec 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -204,7 +204,7 @@ unsigned int host1x_cdma_wait_locked(struct host1x_cdma
*cdma,
cdma->event = event;
mutex_unlock(>lock);
- down(>sem);
+ wait_for_completion(>complete);
mutex_lock(>lock);
}
@@ -308,7 +308,7 @@ static void update_cdma_locked(struct host1x_cdma *cdma)
if (signal) {
cdma->event = CDMA_EVENT_NONE;
- up(>sem);
+ complete(>complete);
}
}
@@ -410,7 +410,7 @@ int host1x_cdma_init(struct host1x_cdma *cdma)
int err;
mutex_init(>lock);
- sema_init(>sem, 0);
+ init_completion(>complete);
INIT_LIST_HEAD(>sync_queue);
diff --git a/drivers/gpu/host1x/cdma.h b/drivers/gpu/host1x/cdma.h
index c628070b94d7..ba790f9bfebc 100644
--- a/drivers/gpu/host1x/cdma.h
+++ b/drivers/gpu/host1x/cdma.h
@@ -20,7 +20,7 @@
#define __HOST1X_CDMA_H
#include
-#include
+#include
#include
struct host1x_syncpt;
@@ -70,7 +70,7 @@ enum cdma_event {
struct host1x_cdma {
struct mutex lock; /* controls access to shared state */
- struct semaphore sem; /* signalled when event occurs */
+ struct completion complete; /* signalled when event occurs */
enum cdma_event event; /* event that sem is waiting for */
unsigned int slots_used;/* pb slots used in current submit */
unsigned int slots_free;/* pb slots free in current submit */
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
On Mon, Dec 10, 2018 at 11:29:06PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a type.
^
But this is :P
> We're just preserving MOT. What makes you think it
> should always be set?
>
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
> > I2C_WRITE requests")
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 2d6c491a0542..d98805b517f0 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -677,7 +677,7 @@ static void drm_dp_i2c_msg_write_status_update(struct
> > drm_dp_aux_msg *msg)
> > * rest of the message
> > */
> > if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
> > - msg->request &= DP_AUX_I2C_MOT;
> > + msg->request |= DP_AUX_I2C_MOT;
> > msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
> > }
> > }
> > --
> > 2.17.1
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/sched: Rework HW fence processing.
Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit finish_work
directly from the HW fence callback.
v2: Fix comments.
v3: Attach hw fence cb to sched_job
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 58 --
include/drm/gpu_scheduler.h| 6 ++--
2 files changed, 30 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index cdf95e2..f0c1f32 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -284,8 +284,6 @@ static void drm_sched_job_finish(struct work_struct *work)
cancel_delayed_work_sync(>work_tdr);
spin_lock_irqsave(>job_list_lock, flags);
- /* remove job from ring_mirror_list */
- list_del_init(_job->node);
/* queue TDR for next job */
drm_sched_start_timeout(sched);
spin_unlock_irqrestore(>job_list_lock, flags);
@@ -293,22 +291,11 @@ static void drm_sched_job_finish(struct work_struct *work)
sched->ops->free_job(s_job);
}
-static void drm_sched_job_finish_cb(struct dma_fence *f,
- struct dma_fence_cb *cb)
-{
- struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
-finish_cb);
- schedule_work(>finish_work);
-}
-
static void drm_sched_job_begin(struct drm_sched_job *s_job)
{
struct drm_gpu_scheduler *sched = s_job->sched;
unsigned long flags;
- dma_fence_add_callback(_job->s_fence->finished, _job->finish_cb,
- drm_sched_job_finish_cb);
-
spin_lock_irqsave(>job_list_lock, flags);
list_add_tail(_job->node, >ring_mirror_list);
drm_sched_start_timeout(sched);
@@ -359,12 +346,11 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
struct drm_sched_job *bad,
list_for_each_entry_reverse(s_job, >ring_mirror_list, node) {
if (s_job->s_fence->parent &&
dma_fence_remove_callback(s_job->s_fence->parent,
- _job->s_fence->cb)) {
+ _job->cb)) {
dma_fence_put(s_job->s_fence->parent);
s_job->s_fence->parent = NULL;
atomic_dec(>hw_rq_count);
- }
- else {
+ } else {
/* TODO Is it get/put neccessey here ? */
dma_fence_get(_job->s_fence->finished);
list_add(_job->finish_node, _list);
@@ -417,31 +403,34 @@ EXPORT_SYMBOL(drm_sched_stop);
void drm_sched_start(struct drm_gpu_scheduler *sched, bool unpark_only)
{
struct drm_sched_job *s_job, *tmp;
- unsigned long flags;
int r;
if (unpark_only)
goto unpark;
- spin_lock_irqsave(>job_list_lock, flags);
+ /*
+* Locking the list is not required here as the sched thread is parked
+* so no new jobs are being pushed in to HW and in drm_sched_stop we
+* flushed all the jobs who were still in mirror list but who already
+* signaled and removed them self from the list. Also concurrent
+* GPU recovers can't run in parallel.
+*/
list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
- struct drm_sched_fence *s_fence = s_job->s_fence;
struct dma_fence *fence = s_job->s_fence->parent;
if (fence) {
- r = dma_fence_add_callback(fence, _fence->cb,
+ r = dma_fence_add_callback(fence, _job->cb,
drm_sched_process_job);
if (r == -ENOENT)
- drm_sched_process_job(fence, _fence->cb);
+ drm_sched_process_job(fence, _job->cb);
else if (r)
DRM_ERROR("fence add callback failed (%d)\n",
r);
} else
- drm_sched_process_job(NULL, _fence->cb);
+ drm_sched_process_job(NULL, _job->cb);
}
drm_sched_start_timeout(sched);
- spin_unlock_irqrestore(>job_list_lock, flags);
unpark:
kthread_unpark(sched->thread);
@@ -590,18 +579,27 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
*/
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb)
{
- struct drm_sched_fence *s_fence =
-
[PATCH v3 1/2] drm/sched: Refactor ring mirror list handling.
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
v2: Fix resubmission of guilty job into HW after refactoring.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 8 +--
drivers/gpu/drm/scheduler/sched_main.c | 110 ++---
drivers/gpu/drm/v3d/v3d_sched.c| 11 +--
include/drm/gpu_scheduler.h| 10 ++-
5 files changed, 95 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ef36cc5..42111d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3292,17 +3292,16 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
/* block all schedulers and reset given job's ring */
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
+ bool park_only = job && job->base.sched != >sched;
if (!ring || !ring->sched.thread)
continue;
- kthread_park(ring->sched.thread);
+ drm_sched_stop(>sched, job ? >base : NULL,
park_only);
- if (job && job->base.sched != >sched)
+ if (park_only)
continue;
- drm_sched_hw_job_reset(>sched, job ? >base : NULL);
-
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
@@ -3445,6 +3444,7 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
struct amdgpu_job *job)
{
int i;
+ bool unpark_only;
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -3456,10 +3456,13 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
* or all rings (in the case @job is NULL)
* after above amdgpu_reset accomplished
*/
- if ((!job || job->base.sched == >sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(>sched);
+ unpark_only = (job && job->base.sched != >sched) ||
+ adev->asic_reset_res;
+
+ if (!unpark_only)
+ drm_sched_resubmit_jobs(>sched);
- kthread_unpark(ring->sched.thread);
+ drm_sched_start(>sched, unpark_only);
}
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..fab3b51 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- kthread_park(gpu->sched.thread);
- drm_sched_hw_job_reset(>sched, sched_job);
+ drm_sched_stop(>sched, sched_job, false);
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
+ drm_sched_resubmit_jobs(>sched);
+
/* restart scheduler after GPU is usable again */
- drm_sched_job_recovery(>sched);
- kthread_unpark(gpu->sched.thread);
+ drm_sched_start(>sched);
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..cdf95e2 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
*cb);
-static void drm_sched_expel_job_unlocked(struct drm_sched_job *s_job);
-
/**
* drm_sched_rq_init - initialize a given run queue struct
*
@@ -342,13 +340,21 @@ static void drm_sched_job_timedout(struct work_struct
*work)
* @bad: bad scheduler job
*
*/
-void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
+void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job *bad,
+ bool park_only)
{
struct drm_sched_job *s_job;
struct drm_sched_entity *entity, *tmp;
unsigned long flags;
+ struct list_head wait_list;
int i;
+ kthread_park(sched->thread);
+ if (park_only)
+ return;
+
+ INIT_LIST_HEAD(_list);
+
spin_lock_irqsave(>job_list_lock,
Re: [PATCH 0/7] legacy helper cleanup
On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter wrote: > > Hi all, > > Just a small cleanup motivated by the last patch. After this series atomic > drivers do no longer need the drm_crtc_helper.h header, and none of them > use it. Except for the 2 that support both atomic and legacy kms in the > same driver module (nouveau and amdgpu). > > Last patch is a bit huge, but splitting it up will make the churn only > worse. > > Comments and review very much appreciated. Some comments on patch 4, 1-3,4-6 are: Reviewed-by: Alex Deucher Assuming the build issues reported with patch 7 are fixed: Reviewed-by: Alex Deucher > > Cheers, Daniel > > Daniel Vetter (7): > drm/ch7006: Stop using drm_crtc_force_disable > drm/nouveau: Stop using drm_crtc_force_disable > drm: Unexport drm_crtc_force_disable > drm: Move the legacy kms disable_all helper to crtc helpers > drm/qxl: Don't set the dpms hook > drm/xen: Don't set the dpms hook > drm: Split out drm_probe_helper.h > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > drivers/gpu/drm/armada/armada_510.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > drivers/gpu/drm/armada/armada_drv.c | 2 +- > drivers/gpu/drm/armada/armada_fb.c| 2 +- > drivers/gpu/drm/ast/ast_drv.c | 1 + > drivers/gpu/drm/ast/ast_mode.c| 1 + > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > drivers/gpu/drm/bridge/panel.c| 2 +- > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > drivers/gpu/drm/bridge/tc358764.c | 2 +- > drivers/gpu/drm/bridge/tc358767.c | 2 +- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_crtc.c| 41 --- > drivers/gpu/drm/drm_crtc_helper.c | 35 + > drivers/gpu/drm/drm_crtc_internal.h | 1 + > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > drivers/gpu/drm/drm_probe_helper.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +- > drivers/gpu/drm/gma500/psb_intel_drv.h| 1 + > .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +- >
Re: [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> The Write_Status_Update_Request I2C transaction requires the MOT bit to
> be set, Change the logical AND to OR to fix what looks like a typo.
It's not a type. We're just preserving MOT. What makes you think it
should always be set?
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
> I2C_WRITE requests")
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2d6c491a0542..d98805b517f0 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -677,7 +677,7 @@ static void drm_dp_i2c_msg_write_status_update(struct
> drm_dp_aux_msg *msg)
>* rest of the message
>*/
> if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
> - msg->request &= DP_AUX_I2C_MOT;
> + msg->request |= DP_AUX_I2C_MOT;
> msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
> }
> }
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] arm64: meson-gxm: Add support for the Mali T820 GPU
Neil Armstrong writes: > This patchset adds : > - Optional reset properties in the midgard bindings > - Mali T820 Node in Amlogic Meson GXM DTSI > > Christian Hewitt (1): > arm64: dts: meson-gxm: Add Mali-T820 node > > Neil Armstrong (1): > dt-bindings: gpu: mali-midgard: Add resets property Queued for v4.21 (branch: dt64) Thanks, Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
The Write_Status_Update_Request I2C transaction requires the MOT bit to
be set, Change the logical AND to OR to fix what looks like a typo.
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
I2C_WRITE requests")
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2d6c491a0542..d98805b517f0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -677,7 +677,7 @@ static void drm_dp_i2c_msg_write_status_update(struct
drm_dp_aux_msg *msg)
* rest of the message
*/
if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
- msg->request &= DP_AUX_I2C_MOT;
+ msg->request |= DP_AUX_I2C_MOT;
msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
}
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: fix arm64 build error
The new a200 GPU MMU support fails to build on arm64 because
of a conflicting macro name:
drivers/gpu/drm/msm/msm_gpummu.c:17: error: "VA_START" redefined [-Werror]
#define VA_START SZ_16M
In file included from arch/arm64/include/asm/pgtable-hwdef.h:19,
from arch/arm64/include/asm/processor.h:48,
from include/linux/mutex.h:19,
from include/linux/notifier.h:14,
from include/linux/clk.h:17,
from drivers/gpu/drm/msm/msm_drv.h:23,
from drivers/gpu/drm/msm/msm_gpummu.c:4:
arch/arm64/include/asm/memory.h:51: note: this is the location of the previous
definition
#define VA_START (UL(0x) - \
Rename this and the related macros with a GPU_ prefix.
Fixes: 1c0088f255ae ("drm/msm: implement a2xx mmu")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/msm/msm_gpummu.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpummu.c b/drivers/gpu/drm/msm/msm_gpummu.c
index f1dc2b7e5fd3..2a7ddd449d3d 100644
--- a/drivers/gpu/drm/msm/msm_gpummu.c
+++ b/drivers/gpu/drm/msm/msm_gpummu.c
@@ -14,10 +14,10 @@ struct msm_gpummu {
};
#define to_msm_gpummu(x) container_of(x, struct msm_gpummu, base)
-#define VA_START SZ_16M
-#define VA_RANGE (0xfff * SZ_64K)
-#define MMU_PAGE_SIZE SZ_4K
-#define TABLE_SIZE (sizeof(uint32_t) * VA_RANGE / MMU_PAGE_SIZE)
+#define GPU_VA_START SZ_16M
+#define GPU_VA_RANGE (0xfff * SZ_64K)
+#define GPU_MMU_PAGE_SIZE SZ_4K
+#define GPU_TABLE_SIZE (sizeof(uint32_t) * GPU_VA_RANGE / GPU_MMU_PAGE_SIZE)
static int msm_gpummu_attach(struct msm_mmu *mmu, const char * const *names,
int cnt)
@@ -34,7 +34,7 @@ static int msm_gpummu_map(struct msm_mmu *mmu, uint64_t iova,
struct sg_table *sgt, unsigned len, int prot)
{
struct msm_gpummu *gpummu = to_msm_gpummu(mmu);
- unsigned idx = (iova - VA_START) / MMU_PAGE_SIZE;
+ unsigned idx = (iova - GPU_VA_START) / GPU_MMU_PAGE_SIZE;
struct scatterlist *sg;
unsigned prot_bits = 0;
unsigned i, j;
@@ -46,9 +46,9 @@ static int msm_gpummu_map(struct msm_mmu *mmu, uint64_t iova,
for_each_sg(sgt->sgl, sg, sgt->nents, i) {
dma_addr_t addr = sg->dma_address;
- for (j = 0; j < sg->length / MMU_PAGE_SIZE; j++, idx++) {
+ for (j = 0; j < sg->length / GPU_MMU_PAGE_SIZE; j++, idx++) {
gpummu->table[idx] = addr | prot_bits;
- addr += MMU_PAGE_SIZE;
+ addr += GPU_MMU_PAGE_SIZE;
}
}
@@ -62,10 +62,10 @@ static int msm_gpummu_map(struct msm_mmu *mmu, uint64_t
iova,
static int msm_gpummu_unmap(struct msm_mmu *mmu, uint64_t iova, unsigned len)
{
struct msm_gpummu *gpummu = to_msm_gpummu(mmu);
- unsigned idx = (iova - VA_START) / MMU_PAGE_SIZE;
+ unsigned idx = (iova - GPU_VA_START) / GPU_MMU_PAGE_SIZE;
unsigned i;
- for (i = 0; i < len / MMU_PAGE_SIZE; i++, idx++)
+ for (i = 0; i < len / GPU_MMU_PAGE_SIZE; i++, idx++)
gpummu->table[idx] = 0;
gpu_write(gpummu->gpu, REG_A2XX_MH_MMU_INVALIDATE,
@@ -78,7 +78,7 @@ static void msm_gpummu_destroy(struct msm_mmu *mmu)
{
struct msm_gpummu *gpummu = to_msm_gpummu(mmu);
- dma_free_attrs(mmu->dev, TABLE_SIZE, gpummu->table, gpummu->pt_base,
+ dma_free_attrs(mmu->dev, GPU_TABLE_SIZE, gpummu->table, gpummu->pt_base,
DMA_ATTR_FORCE_CONTIGUOUS);
kfree(gpummu);
@@ -100,7 +100,7 @@ struct msm_mmu *msm_gpummu_new(struct device *dev, struct
msm_gpu *gpu)
if (!gpummu)
return ERR_PTR(-ENOMEM);
- gpummu->table = dma_alloc_attrs(dev, TABLE_SIZE + 32, >pt_base,
+ gpummu->table = dma_alloc_attrs(dev, GPU_TABLE_SIZE + 32,
>pt_base,
GFP_KERNEL | __GFP_ZERO, DMA_ATTR_FORCE_CONTIGUOUS);
if (!gpummu->table) {
kfree(gpummu);
@@ -119,5 +119,5 @@ void msm_gpummu_params(struct msm_mmu *mmu, dma_addr_t
*pt_base,
dma_addr_t base = to_msm_gpummu(mmu)->pt_base;
*pt_base = base;
- *tran_error = base + TABLE_SIZE; /* 32-byte aligned */
+ *tran_error = base + GPU_TABLE_SIZE; /* 32-byte aligned */
}
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108979] Graphical glitch of popupping missing texture on Mesa version >18.0.5 (Padoka Stable + Unstable/Oibaf/ubuntu-x-swat PPAs)
https://bugs.freedesktop.org/show_bug.cgi?id=108979 --- Comment #4 from emm...@linuxmail.org --- Created attachment 142773 --> https://bugs.freedesktop.org/attachment.cgi?id=142773=edit Popupping grahpical glitch highligted I have highlighted with a red circle the glitch, that glitch appear in other games with all version >18.0.5 of Mesa -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/5] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers
On Mon, 2018-12-10 at 18:39 +0200, Ville Syrjälä wrote: > On Fri, Dec 07, 2018 at 12:45:25PM -0800, Dhinakaran Pandiyan wrote: > > On Fri, 2018-09-28 at 21:03 +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > We aren't supposed to force a stop+start between every i2c msg > > > when performing multi message transfers. This should eg. cause > > > the DDC segment address to be reset back to 0 between writing > > > the segment address and reading the actual EDID extension block. > > > > > > To quote the E-DDC spec: > > > "... this standard requires that the segment pointer be > > > reset to 00h when a NO ACK or a STOP condition is received." > > > > Related question, do you know why the segment and ddc addresses are > > defined as 0x30 and 0x50? The E-DDC spec says they should be at > > 0x60 > > and 0xA0/0xA1. > > The spec uses 'slave_address << 1 | r/w'. Got it, thanks. -DK ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #18 from quirin.blae...@freenet.de --- Bug is still alive: v4.19.7 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC] MAINTAINERS: Daniel for drm co-maintainer
On Mon, Dec 10, 2018 at 5:30 AM Daniel Vetter wrote: > > lkml and Linus gained a CoC, and it's serious this time. Which means > my no 1 reason for declining to officially step up as drm maintainer > is gone, and I didn't find any new good excuse. > > I chatted with a few people in private already, and the biggest > concern is that I mislay my community hat and start running around > with my intel hat only. Or some other convenient abuse of trust. > > That's why this patch doesn't just need a lot of acks that mean "yeah > seems fine to me", but a lot of acks that mean "yeah we'll tell you > when you're over the line and usurp you from that comfy chair if you > don't get it". Which I think we've been done a fairly good job here at > dri-devel in general, but better to be clear. > > Rough idea is that I'll do this for maybe 2-3 years, helping Dave > figure out a group model for drm overall. And getting the tooling and > infrastructure for that off the ground. Then step down again because > some other shiny thing that needs chasing. Of course as plans tend to > do, this one will probably pan out a bit different in reality. > > Cc: David Airlie > Cc: Linus Torvalds > Signed-off-by: Daniel Vetter Acked-by: Alex Deucher > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7e05aa20b0ab..2c4cd038df2a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4849,6 +4849,7 @@ F:include/uapi/drm/vmwgfx_drm.h > > DRM DRIVERS > M: David Airlie > +M: Daniel Vetter > L: dri-devel@lists.freedesktop.org > T: git git://anongit.freedesktop.org/drm/drm > B: https://bugs.freedesktop.org/ > -- > 2.20.0.rc1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware
https://bugs.freedesktop.org/show_bug.cgi?id=108919 --- Comment #7 from Alexander Walker --- (In reply to Timothy Arceri from comment #5) > Can somebody try to get an apitrace of the issue [1]? Thanks. > > [1] https://github.com/apitrace/apitrace/wiki/Steam Never used that tool before but I uploaded a trace that shows it immediately visible on the main menu. Lots of these in the console if they're relevant: apitrace: warning: _gl_param_size: unknown GLenum 0x8267 apitrace: warning: _gl_param_size: unknown GLenum 0x92F5 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware
https://bugs.freedesktop.org/show_bug.cgi?id=108919 --- Comment #6 from Alexander Walker --- Created attachment 142771 --> https://bugs.freedesktop.org/attachment.cgi?id=142771=edit Apitrace -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
From: Christoph Hellwig Date: Mon, 10 Dec 2018 20:22:28 +0100 > On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote: >> From: Christoph Hellwig >> Date: Mon, 10 Dec 2018 17:32:56 +0100 >> >> > Dave, can you pick the series up through the sparc tree? I could also >> > merge it through the dma-mapping tree, but given that there is no >> > dependency on it the sparc tree seem like the better fit. >> >> I thought that some of this is a prerequisite for the DMA mapping >> work and overall consolidation you are doing. So I kinda assumed >> you wanted to merge it via your tree. >> >> I anticipate no conflicts at all, even until the next merge window, >> so it could very easily go through your tree. >> >> Let me know if you still want me to merge this. > > These patches are purely cleanups I found while auditing the DMA > mapping code, at least as of now there are no dependencies. > > That being said now that I looked into it a bit more they do however > depend on the ->mapping_error removal, so I'll take them through > the dma-mapping tree. Ok, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] arm64/iommu: don't remap contiguous allocations for coherent devices
On Mon, Dec 10, 2018 at 07:19:30PM +, Robin Murphy wrote:
> On 08/12/2018 17:36, Christoph Hellwig wrote:
>> There is no need to have an additional kernel mapping for a contiguous
>> allocation if the device already is DMA coherent, so skip it.
>
> FWIW, the "need" was that it kept the code in this path simple and the
> mapping behaviour consistent with the regular iommu_dma_alloc() case. One
> could quite easily retort that there is no need for the extra complexity of
> this patch, since vmalloc is cheap on a 64-bit architecture ;)
Heh. Well, without the remap we do less work, we prepare for a simple
implementation of DMA_ATTR_NON_CONSISTENT, and also prepapre the code
to be better reusable for architectures that don't do remapping of
DMA allocations at all.
>> if (addr) {
>> memset(addr, 0, size);
>> -if (!coherent)
>> -__dma_flush_area(page_to_virt(page), iosize);
>> +__dma_flush_area(page_to_virt(page), iosize);
>
> Oh poo - seems I missed it at the time but the existing logic here is
> wrong. Let me send a separate fix to flip those statements into the correct
> order...
Yes, flushing the remapped alias only after zeroing it looks odd.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote: > From: Christoph Hellwig > Date: Mon, 10 Dec 2018 17:32:56 +0100 > > > Dave, can you pick the series up through the sparc tree? I could also > > merge it through the dma-mapping tree, but given that there is no > > dependency on it the sparc tree seem like the better fit. > > I thought that some of this is a prerequisite for the DMA mapping > work and overall consolidation you are doing. So I kinda assumed > you wanted to merge it via your tree. > > I anticipate no conflicts at all, even until the next merge window, > so it could very easily go through your tree. > > Let me know if you still want me to merge this. These patches are purely cleanups I found while auditing the DMA mapping code, at least as of now there are no dependencies. That being said now that I looked into it a bit more they do however depend on the ->mapping_error removal, so I'll take them through the dma-mapping tree. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] arm64/iommu: don't remap contiguous allocations for coherent devices
On 08/12/2018 17:36, Christoph Hellwig wrote:
There is no need to have an additional kernel mapping for a contiguous
allocation if the device already is DMA coherent, so skip it.
FWIW, the "need" was that it kept the code in this path simple and the
mapping behaviour consistent with the regular iommu_dma_alloc() case.
One could quite easily retort that there is no need for the extra
complexity of this patch, since vmalloc is cheap on a 64-bit architecture ;)
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4c0f498069e8..d39b60113539 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -255,13 +255,18 @@ static void *__iommu_alloc_attrs(struct device *dev,
size_t size,
size >> PAGE_SHIFT);
return NULL;
}
+
+ if (coherent) {
+ memset(addr, 0, size);
+ return addr;
+ }
+
addr = dma_common_contiguous_remap(page, size, VM_USERMAP,
prot,
__builtin_return_address(0));
if (addr) {
memset(addr, 0, size);
- if (!coherent)
- __dma_flush_area(page_to_virt(page), iosize);
+ __dma_flush_area(page_to_virt(page), iosize);
Oh poo - seems I missed it at the time but the existing logic here is
wrong. Let me send a separate fix to flip those statements into the
correct order...
Robin.
} else {
iommu_dma_unmap_page(dev, *handle, iosize, 0, attrs);
dma_release_from_contiguous(dev, page,
@@ -309,7 +314,9 @@ static void __iommu_free_attrs(struct device *dev, size_t
size, void *cpu_addr,
iommu_dma_unmap_page(dev, handle, iosize, 0, attrs);
dma_release_from_contiguous(dev, page, size >> PAGE_SHIFT);
- dma_common_free_remap(cpu_addr, size, VM_USERMAP);
+
+ if (!dev_is_dma_coherent(dev))
+ dma_common_free_remap(cpu_addr, size, VM_USERMAP);
} else if (is_vmalloc_addr(cpu_addr)){
struct vm_struct *area = find_vm_area(cpu_addr);
@@ -336,11 +343,12 @@ static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
return ret;
if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
- /*
-* DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,
-* hence in the vmalloc space.
-*/
- unsigned long pfn = vmalloc_to_pfn(cpu_addr);
+ unsigned long pfn;
+
+ if (dev_is_dma_coherent(dev))
+ pfn = virt_to_pfn(cpu_addr);
+ else
+ pfn = vmalloc_to_pfn(cpu_addr);
return __swiotlb_mmap_pfn(vma, pfn, size);
}
@@ -359,11 +367,12 @@ static int __iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
struct vm_struct *area = find_vm_area(cpu_addr);
if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
- /*
-* DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,
-* hence in the vmalloc space.
-*/
- struct page *page = vmalloc_to_page(cpu_addr);
+ struct page *page;
+
+ if (dev_is_dma_coherent(dev))
+ page = virt_to_page(cpu_addr);
+ else
+ page = vmalloc_to_page(cpu_addr);
return __swiotlb_get_sgtable_page(sgt, page, size);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/10] arm: implement DMA_ATTR_NON_CONSISTENT
On Sat, Dec 08, 2018 at 07:52:04PM -0300, Ezequiel Garcia wrote:
> > #ifdef CONFIG_DMA_API_DEBUG
> > @@ -773,7 +791,7 @@ static void *__dma_alloc(struct device *dev, size_t
> > size, dma_addr_t *handle,
> >
> > if (cma)
> > buf->allocator = _allocator;
> > - else if (is_coherent)
> > + else if (is_coherent || (attrs & DMA_ATTR_NON_CONSISTENT))
> > buf->allocator = _allocator;
>
> Reading through your code I can't really see where the pgprot is changed
> for non-consistent requests. Namely, __get_dma_pgprot only
> returns writecombine or coherent memory.
We don't look at the pgprot at all for the simple allocator, and
don't look at prot for the DMA_ATTR_NON_CONSISTENT case in the
CMA allocator, so this should not be a problem. However we need to
take DMA_ATTR_NON_CONSISTENT into account for calculating the mmap
pgprot, with something like this as an incremental patch:
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index b3b66b41c450..6ac7e430a47c 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -873,7 +873,8 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct
*vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
+ if (!(attrs & DMA_ATTR_NON_CONSISTENT))
+ vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
return __arm_dma_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: fbcon: Fix unregister crash when more than one framebuffer
When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:
[ 76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442
__queue_work+0x2d4/0x41c
[ 76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight
bcm2835_rng rng_core [last unloaded: tinydrm]
[ 76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[ 76.478933] Hardware name: BCM2835
[ 76.478949] Backtrace:
[ 76.478995] [] (dump_backtrace) from []
(show_stack+0x20/0x24)
[ 76.479022] r6: r5:c0bc73be r4: r3:6fb5bf81
[ 76.479060] [] (show_stack) from []
(dump_stack+0x20/0x28)
[ 76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c)
[ 76.479134] [] (__warn) from []
(warn_slowpath_null+0x4c/0x58)
[ 76.479165] r9:c0eb6944 r8:0001 r7:c0e927f8 r6:c0bc73be r5:05a2
r4:c0139e84
[ 76.479197] [] (warn_slowpath_null) from []
(__queue_work+0x2d4/0x41c)
[ 76.479222] r6:d7666a00 r5:c0e918ee r4:dbc4e700
[ 76.479251] [] (__queue_work) from []
(queue_work_on+0x60/0x88)
[ 76.479281] r10:c0496bf8 r9:0100 r8:c0e92ae0 r7:0001 r6:d9403700
r5:d7666a00
[ 76.479298] r4:2113
[ 76.479348] [] (queue_work_on) from []
(cursor_timer_handler+0x30/0x54)
[ 76.479374] r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[ 76.479413] [] (cursor_timer_handler) from []
(call_timer_fn+0x100/0x230)
[ 76.479435] r4:c0e9192f r3:d758a340
[ 76.479465] [] (call_timer_fn) from []
(expire_timers+0x10c/0x12c)
[ 76.479495] r10:4000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280
r5:c0496bf8
[ 76.479513] r4:d8a8fabc
[ 76.479541] [] (expire_timers) from []
(run_timer_softirq+0xa8/0x184)
[ 76.479570] r9:0001 r8:c0e19280 r7: r6:c0e08088 r5:c0e1a3e0
r4:c0e19280
[ 76.479603] [] (run_timer_softirq) from []
(__do_softirq+0x1ac/0x3fc)
[ 76.479632] r10:c0e91680 r9:d8afc020 r8:000a r7:0100 r6:0001
r5:0002
[ 76.479650] r4:c0eb65ec
[ 76.479686] [] (__do_softirq) from []
(irq_exit+0xe8/0x168)
[ 76.479716] r10:d8d1a9b0 r9:d8afc000 r8:0001 r7:d949c000 r6:
r5:c0e8b3f0
[ 76.479734] r4:
[ 76.479764] [] (irq_exit) from []
(__handle_domain_irq+0x94/0xb0)
[ 76.479793] [] (__handle_domain_irq) from []
(bcm2835_handle_irq+0x3c/0x48)
[ 76.479823] r8:d8afdebc r7:d8afddfc r6: r5:c0e089f8 r4:d8afddc8
r3:d8afddc8
[ 76.479851] [] (bcm2835_handle_irq) from []
(__irq_svc+0x70/0x98)
The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.
Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from
unregister_framebuffer")
Signed-off-by: Noralf Trønnes
Reviewed-by: Mikulas Patocka
---
Mikulas,
If you have forgotten about this, here's where you gave your r-b:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182728.html
drivers/video/fbdev/core/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 8958ccc8b1ac..8976190b6c1f 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3064,7 +3064,7 @@ static int fbcon_fb_unbind(int idx)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
con2fb_map[i] != -1) {
- new_idx = i;
+ new_idx = con2fb_map[i];
break;
}
}
--
2.19.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108985] Visual Novel "The Fruit of Grisaia" has flickering glitches
https://bugs.freedesktop.org/show_bug.cgi?id=108985 Fabian Maurer changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #5 from Fabian Maurer --- Sorry, that's was a C bug. I'm running mesa 18.3.0-1 and tested with 106052.95d62baac5-git. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
From: Christoph Hellwig Date: Mon, 10 Dec 2018 17:32:56 +0100 > Dave, can you pick the series up through the sparc tree? I could also > merge it through the dma-mapping tree, but given that there is no > dependency on it the sparc tree seem like the better fit. I thought that some of this is a prerequisite for the DMA mapping work and overall consolidation you are doing. So I kinda assumed you wanted to merge it via your tree. I anticipate no conflicts at all, even until the next merge window, so it could very easily go through your tree. Let me know if you still want me to merge this. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/5] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers
On Fri, Dec 07, 2018 at 12:45:25PM -0800, Dhinakaran Pandiyan wrote: > On Fri, 2018-09-28 at 21:03 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We aren't supposed to force a stop+start between every i2c msg > > when performing multi message transfers. This should eg. cause > > the DDC segment address to be reset back to 0 between writing > > the segment address and reading the actual EDID extension block. > > > > To quote the E-DDC spec: > > "... this standard requires that the segment pointer be > > reset to 00h when a NO ACK or a STOP condition is received." > Related question, do you know why the segment and ddc addresses are > defined as 0x30 and 0x50? The E-DDC spec says they should be at 0x60 > and 0xA0/0xA1. The spec uses 'slave_address << 1 | r/w'. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC] MAINTAINERS: Daniel for drm co-maintainer
On Mon, Dec 10, 2018 at 11:30:01AM +0100, Daniel Vetter wrote: > lkml and Linus gained a CoC, and it's serious this time. Which means > my no 1 reason for declining to officially step up as drm maintainer > is gone, and I didn't find any new good excuse. > > I chatted with a few people in private already, and the biggest > concern is that I mislay my community hat and start running around > with my intel hat only. Or some other convenient abuse of trust. > > That's why this patch doesn't just need a lot of acks that mean "yeah > seems fine to me", but a lot of acks that mean "yeah we'll tell you > when you're over the line and usurp you from that comfy chair if you > don't get it". Which I think we've been done a fairly good job here at > dri-devel in general, but better to be clear. > > Rough idea is that I'll do this for maybe 2-3 years, helping Dave > figure out a group model for drm overall. And getting the tooling and > infrastructure for that off the ground. Then step down again because > some other shiny thing that needs chasing. Of course as plans tend to > do, this one will probably pan out a bit different in reality. > > Cc: David Airlie > Cc: Linus Torvalds > Signed-off-by: Daniel Vetter You've done a great job as i915 and drm-misc maintainer. You are a great leader of this drm community in general. Acked-by: Rodrigo Vivi > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7e05aa20b0ab..2c4cd038df2a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4849,6 +4849,7 @@ F: include/uapi/drm/vmwgfx_drm.h > > DRM DRIVERS > M: David Airlie > +M: Daniel Vetter > L: dri-devel@lists.freedesktop.org > T: git git://anongit.freedesktop.org/drm/drm > B: https://bugs.freedesktop.org/ > -- > 2.20.0.rc1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109001] Freezes when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=109001 --- Comment #4 from Julio --- (In reply to Michel Dänzer from comment #3) > The Xorg log file doesn't have any messages corresponding to those in dmesg. > Was it really captured after reproducing the problem? > > Does > https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/ > 15 help or the freezes by any chance? I checked again, but it doesn't print anything on Xorg log. Those "device removed" are always shown after the freeze, not sure if related. I tried that patch but it doesn't seem to make any difference. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: Refactor CEC support
From: Thierry Reding
Most of the CEC support code already lives in the "output" library code.
Move registration and unregistration to the library code as well to make
use of the same code with HDMI on Tegra210 and later via the SOR.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.h| 2 +-
drivers/gpu/drm/tegra/hdmi.c | 9 -
drivers/gpu/drm/tegra/output.c | 11 +--
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 019862a41cb4..dbc9e11b0aec 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -132,7 +132,7 @@ struct tegra_output {
struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
- struct cec_notifier *notifier;
+ struct cec_notifier *cec;
unsigned int hpd_irq;
int hpd_gpio;
enum of_gpio_flags hpd_gpio_flags;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 0082468f703c..d19973945614 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -22,8 +22,6 @@
#include
-#include
-
#include "hdmi.h"
#include "drm.h"
#include "dc.h"
@@ -1709,10 +1707,6 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
return PTR_ERR(hdmi->vdd);
}
- hdmi->output.notifier = cec_notifier_get(>dev);
- if (hdmi->output.notifier == NULL)
- return -ENOMEM;
-
hdmi->output.dev = >dev;
err = tegra_output_probe(>output);
@@ -1771,9 +1765,6 @@ static int tegra_hdmi_remove(struct platform_device *pdev)
tegra_output_remove(>output);
- if (hdmi->output.notifier)
- cec_notifier_put(hdmi->output.notifier);
-
return 0;
}
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index c662efc7e413..9c2b9dad55c3 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -36,7 +36,7 @@ int tegra_output_connector_get_modes(struct drm_connector
*connector)
else if (output->ddc)
edid = drm_get_edid(connector, output->ddc);
- cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
+ cec_notifier_set_phys_addr_from_edid(output->cec, edid);
drm_connector_update_edid_property(connector, edid);
if (edid) {
@@ -73,7 +73,7 @@ tegra_output_connector_detect(struct drm_connector
*connector, bool force)
}
if (status != connector_status_connected)
- cec_notifier_phys_addr_invalidate(output->notifier);
+ cec_notifier_phys_addr_invalidate(output->cec);
return status;
}
@@ -174,11 +174,18 @@ int tegra_output_probe(struct tegra_output *output)
disable_irq(output->hpd_irq);
}
+ output->cec = cec_notifier_get(output->dev);
+ if (!output->cec)
+ return -ENOMEM;
+
return 0;
}
void tegra_output_remove(struct tegra_output *output)
{
+ if (output->cec)
+ cec_notifier_put(output->cec);
+
if (gpio_is_valid(output->hpd_gpio)) {
free_irq(output->hpd_irq, output);
gpio_free(output->hpd_gpio);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
Dave, can you pick the series up through the sparc tree? I could also merge it through the dma-mapping tree, but given that there is no dependency on it the sparc tree seem like the better fit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > I do not see any scheduler guys Cced and it would be really great to get
> > > their opinion here.
> > >
> > > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > > > In some special cases we must not block, but there's not a
> > > > spinlock, preempt-off, irqs-off or similar critical section already
> > > > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > > > pair to annotate these.
> > > >
> > > > This will be used in the oom paths of mmu-notifiers, where blocking is
> > > > not allowed to make sure there's forward progress.
> > >
> > > Considering the only alternative would be to abuse
> > > preempt_{disable,enable}, and that really has a different semantic, I
> > > think this makes some sense. The cotext is preemptible but we do not
> > > want notifier to sleep on any locks, WQ etc.
> >
> > I'm confused... what is this supposed to do?
> >
> > And what does 'block' mean here? Without preempt_disable/IRQ-off we're
> > subject to regular preemption and execution can stall for arbitrary
> > amounts of time.
>
> The notifier is called from quite a restricted context - oom_reaper -
> which shouldn't depend on any locks or sleepable conditionals.
You want to exclude spinlocks too? We could maybe frob something with
lockdep if you need that?
> The code
> should be swift as well but we mostly do care about it to make a forward
> progress. Checking for sleepable context is the best thing we could come
> up with that would describe these demands at least partially.
OK, no real objections to the thing. Just so long we're all on the same
page as to what it does and doesn't do ;-)
I suppose you could extend the check to include schedule_debug() as
well, maybe something like:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f66920173370..b1aaa278f1af 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3278,13 +3278,18 @@ static noinline void __schedule_bug(struct task_struct
*prev)
/*
* Various schedule()-time debugging checks and statistics:
*/
-static inline void schedule_debug(struct task_struct *prev)
+static inline void schedule_debug(struct task_struct *prev, bool preempt)
{
#ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ if (!preempt && prev->state && prev->non_block_count)
+ // splat
+#endif
+
if (unlikely(in_atomic_preempt_off())) {
__schedule_bug(prev);
preempt_count_set(PREEMPT_DISABLED);
@@ -3391,7 +3396,7 @@ static void __sched notrace __schedule(bool preempt)
rq = cpu_rq(cpu);
prev = rq->curr;
- schedule_debug(prev);
+ schedule_debug(prev, preempt);
if (sched_feat(HRTICK))
hrtick_clear(rq);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon, Dec 10, 2018 at 05:20:10PM +0100, Michal Hocko wrote:
> > OK, no real objections to the thing. Just so long we're all on the same
> > page as to what it does and doesn't do ;-)
>
> I am not really sure whether there are other potential users besides
> this one and whether the check as such is justified.
It's a debug option...
> > I suppose you could extend the check to include schedule_debug() as
> > well, maybe something like:
>
> Do you mean to make the check cheaper?
Nah, so the patch only touched might_sleep(), the below touches
schedule().
If there were a patch that hits schedule() without going through a
might_sleep() (rare in practise I think, but entirely possible) then you
won't get a splat without something like the below on top.
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index f66920173370..b1aaa278f1af 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -3278,13 +3278,18 @@ static noinline void __schedule_bug(struct
> > task_struct *prev)
> > /*
> > * Various schedule()-time debugging checks and statistics:
> > */
> > -static inline void schedule_debug(struct task_struct *prev)
> > +static inline void schedule_debug(struct task_struct *prev, bool preempt)
> > {
> > #ifdef CONFIG_SCHED_STACK_END_CHECK
> > if (task_stack_end_corrupted(prev))
> > panic("corrupted stack end detected inside scheduler\n");
> > #endif
> >
> > +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> > + if (!preempt && prev->state && prev->non_block_count)
> > + // splat
> > +#endif
> > +
> > if (unlikely(in_atomic_preempt_off())) {
> > __schedule_bug(prev);
> > preempt_count_set(PREEMPT_DISABLED);
> > @@ -3391,7 +3396,7 @@ static void __sched notrace __schedule(bool preempt)
> > rq = cpu_rq(cpu);
> > prev = rq->curr;
> >
> > - schedule_debug(prev);
> > + schedule_debug(prev, preempt);
> >
> > if (sched_feat(HRTICK))
> > hrtick_clear(rq);
>
> --
> Michal Hocko
> SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master boot bisection: Oops in nouveau driver on jetson-tk1
On Mon, Dec 10, 2018 at 02:25:59PM +, Mark Brown wrote: > On Mon, Dec 10, 2018 at 10:00:08AM +, Guillaume Tucker wrote: > > On 08/12/2018 00:08, Lyude Paul wrote: > > > uh > > > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > > > nouveau_drm_device_init()" > > > > Yes here's the fix from Thierry: > > > > https://patchwork.freedesktop.org/patch/263587/ > > > > > > and I can confirm that it does fix the Oops when applied on top > > of next-20181206 (what I used for the bisection last week): > > > > http://lava.baylibre.com:10080/scheduler/job/71109 > > > > > > However the fix doesn't appear to have been applied in any > > upstream tree yet. > > This has been broken for a considerable time now with no response from > Ben - is there some other path we can use to get the fix merged? I suppose we could go directly via Dave. But Ben's usually pretty responsive, so he probably just missed it. Let me ping him on IRC, maybe that'll get his attention. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: TK1: DRM, Nouveau and VIC
gt; > > > like > > > > above albeit VIC loading and Tegra DRM now at least showing > > > > something > > > > on HDMI. > > > > > > Yeah, this is a fairly common pitfall. The general rule of thumb is > > > that > > > the firmware has to live on the same medium as the module. So if > > > you've > > > built Tegra DRM as a loadable kernel module and installed it in the > > > root > > > filesystem, then that's where your firmware file also needs to be. > > > If > > > the driver is built-in (or a loadable module installed in the > > > initial > > > ramdisk), then the firmware needs to be in the initial ramdisk (or > > > built > > > into the kernel image itself). That's somewhat annoying, but it is > > > what > > > it is. At least it's logical. > > > > > > > Just reverting above mentioned commit still leaves Nouveau > > > > crashing. > > > > > > > > This has been observed using latest next-20181207. > > > > > > > > Does anybody know what exactly is going on and how exactly one > > > > may get > > > > graphics working again as before? > > > > > > So this is something that should be fixed by this: > > > > > > https://patchwork.freedesktop.org/patch/260547/ > > > > > > And there's another patch that fixes a subsequent crash when you > > > actually start to use the GPU: > > > > > > https://patchwork.freedesktop.org/patch/263588/ > > > > > > It'd be great if you could apply both and verify that they fix the > > > crash > > > for you. If so, can you provide a Tested-by? Both were Cc'ed to > > > linux-tegra, so you should have a copy to reply to. If not, let me > > > know > > > and I can bounce it. > > > > > > Ben, can you pick up the two patches above? They're kind of high- > > > priority because they fix issues that crept into v4.20-rc1, so > > > should > > > ideally be fixed before v4.20 final. > > > > Actually, it looks as if only the last patch is needed, since it > > superseeds the first. The second one calls drm_mode_config_init() via > > nouveau_display_create() and nouveau_drm_device_init(), making the > > first patch obsolete. > > > > There's more confirmation here: > > > > > > https://lists.freedesktop.org/archives/nouveau/2018-December/031636.html > > > > So Ben, correction, please only apply: > > > > https://patchwork.freedesktop.org/patch/263587/ > > Yes, that fixes it and I sent my tested-by. Thanks! Excellent, thanks! > > > Preferably in time for v4.20 final. > > BTW: During testing I was also brave enough to try rmmodding nouveau > which unfortunately also seems to fail: > > root@apalis-tk1-mainline:~# rmmod nouveau > [ 3044.432527] [TTM] Finalizing pool allocator > [ 3044.440007] [TTM] Zone kernel: Used memory at exit: 0 kiB > [ 3044.445631] [TTM] Zone highmem: Used memory at exit: 0 kiB > [ 3044.452841] Unable to handle kernel NULL pointer dereference at > virtual address 038a > [ 3044.461167] pgd = 537c0ac4 > [ 3044.463891] [038a] *pgd=fb95b835 > [ 3044.467487] Internal error: Oops: 17 [#1] PREEMPT SMP ARM > [ 3044.472901] Modules linked in: nouveau(-) btusb btrtl btbcm btintel > tegra_drm xhci_tegra host1x iova ttm > [ 3044.482415] CPU: 3 PID: 616 Comm: rmmod Not tainted 4.20.0-rc6-next- > 20181210-1-gd70a977fd0d5-dirty #115 > [ 3044.492176] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) > [ 3044.498455] PC is at pci_disable_device+0x8/0xd4 > [ 3044.503165] LR is at nouveau_drm_device_remove+0x50/0x7c [nouveau] > [ 3044.509350] pc : []lr : []psr: 6113 > [ 3044.515638] sp : ee3abedc ip : ed625000 fp : 0001 > [ 3044.520879] r10: 0081 r9 : ee3aa000 r8 : ee9eb834 > [ 3044.526107] r7 : ed624000 r6 : r5 : c0f08c48 r4 : > > [ 3044.532649] r3 : 5dfe844b r2 : 5dfe844b r1 : 2e135000 r0 : > > [ 3044.539181] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA > ARM Segment none > [ 3044.546333] Control: 10c5387d Table: acbc006a DAC: 0051 > [ 3044.552098] Process rmmod (pid: 616, stack limit = 0xfc4e79a2) > [ 3044.557934] Stack: (0xee3abedc to 0xee3ac000) > [ 3044.562304] > bec0:ed > 62d400 > [ 3044.570503] bee0: c0f08c48 bf254820 eda76808 5dfe844b ee9f1c8c > ee9f1c10 ee9f1c10 bf2f9c5c > [ 3044.578701] bf00: ee9eb800 bf255914 ee9f1c10 c056aba8 ee9f1c10 > ee9f1c44 bf2f9c5c c05693bc > [ 3044.587298] bf20: ee9f1c10 bf2f9c5c 0001f10c 0800 c0101204 > c05694cc bf2f9c5c bf2fb980 > [ 3044.596316] bf40: 0001f10c c056829c c0f08c48 c01b3c34 76756f6e > 00756165 > [ 3044.605356] bf60: c0f08c48 ec415000 0002 5dfe844b 0001 > c0141c10 ec415000 ec415000 > [ 3044.614431] bf80: ed67c100 5dfe844b 5dfe844b > 0002 bebb5ba8 > [ 3044.623529] bfa0: 0081 c0101000 0002 bebb5ba8 0001f10c > 0800 000a > [ 3044.632631] bfc0: 0002 bebb5ba8 0081 bebb5e9b > 0001f0d0 bebb5d8c 0001 > [ 3044.641739] bfe0: b6e74730 bebb5b64 00012bdf b6e7473c 600d0010 > 0001f10c > [ 3044.650884] [] (pci_disable_device) from [] > (0xee9f1c8c) > [ 3044.658410] Code: eaf0 ebf25973 e92d4030 e1a04000 (e5d0338a) > [ 3044.665141] ---[ end trace 810af3dad648a902 ]--- > Segmentation fault > > Looks like with pci_disable_device() it may take a rather strange > path... Yikes... it has no business at all calling pci_disable_device() on Tegra. Unless if you happen to have a GPU plugged into the PCIe slot. I'm assuming that's not what you're doing? I'll see if I can reproduce (and fix) that crash on unload. Admittedly it's not something that I regularly test. Perhaps that's something that I should change... Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/7] drm/ch7006: Stop using drm_crtc_force_disable
On Mon, Dec 10, 2018 at 11:03:53AM +0100, Daniel Vetter wrote:
> The correct way for legacy drivers to update properties that need to
> do a full modeset, is to do a full modeset.
>
> Note that we don't need to call the drm_mode_config_internal helper
> because we're not changing any of the refcounted paramters.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/i2c/ch7006_drv.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c
> b/drivers/gpu/drm/i2c/ch7006_drv.c
> index 544a8a2d3562..719c79d3fac9 100644
> --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> @@ -359,10 +359,10 @@ static int ch7006_encoder_set_property(struct
> drm_encoder *encoder,
> if (modes_changed) {
> drm_helper_probe_single_connector_modes(connector, 0, 0);
>
> - /* Disable the crtc to ensure a full modeset is
> - * performed whenever it's turned on again. */
> if (crtc)
> - drm_crtc_force_disable(crtc);
> + return drm_crtc_helper_set_mode(crtc, >mode,
> + crtc->x, crtc->y,
> + crtc->primary->fb);
That guy seems to return a bool.
> }
>
> return 0;
> --
> 2.20.0.rc1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon 10-12-18 16:22:53, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> > On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > > I do not see any scheduler guys Cced and it would be really great to get
> > > > their opinion here.
> > > >
> > > > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > > > > In some special cases we must not block, but there's not a
> > > > > spinlock, preempt-off, irqs-off or similar critical section already
> > > > > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > > > > pair to annotate these.
> > > > >
> > > > > This will be used in the oom paths of mmu-notifiers, where blocking is
> > > > > not allowed to make sure there's forward progress.
> > > >
> > > > Considering the only alternative would be to abuse
> > > > preempt_{disable,enable}, and that really has a different semantic, I
> > > > think this makes some sense. The cotext is preemptible but we do not
> > > > want notifier to sleep on any locks, WQ etc.
> > >
> > > I'm confused... what is this supposed to do?
> > >
> > > And what does 'block' mean here? Without preempt_disable/IRQ-off we're
> > > subject to regular preemption and execution can stall for arbitrary
> > > amounts of time.
> >
> > The notifier is called from quite a restricted context - oom_reaper -
> > which shouldn't depend on any locks or sleepable conditionals.
>
> You want to exclude spinlocks too? We could maybe frob something with
> lockdep if you need that?
Spinlocks are less of a problem because you cannot have a (in)direct
dependency on the page allocator that would deadlock. Spinlocks, or
preemption disabled in general should be short enough to guarantee a
forward progress.
> > The code
> > should be swift as well but we mostly do care about it to make a forward
> > progress. Checking for sleepable context is the best thing we could come
> > up with that would describe these demands at least partially.
>
> OK, no real objections to the thing. Just so long we're all on the same
> page as to what it does and doesn't do ;-)
I am not really sure whether there are other potential users besides
this one and whether the check as such is justified.
> I suppose you could extend the check to include schedule_debug() as
> well, maybe something like:
Do you mean to make the check cheaper?
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f66920173370..b1aaa278f1af 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3278,13 +3278,18 @@ static noinline void __schedule_bug(struct
> task_struct *prev)
> /*
> * Various schedule()-time debugging checks and statistics:
> */
> -static inline void schedule_debug(struct task_struct *prev)
> +static inline void schedule_debug(struct task_struct *prev, bool preempt)
> {
> #ifdef CONFIG_SCHED_STACK_END_CHECK
> if (task_stack_end_corrupted(prev))
> panic("corrupted stack end detected inside scheduler\n");
> #endif
>
> +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> + if (!preempt && prev->state && prev->non_block_count)
> + // splat
> +#endif
> +
> if (unlikely(in_atomic_preempt_off())) {
> __schedule_bug(prev);
> preempt_count_set(PREEMPT_DISABLED);
> @@ -3391,7 +3396,7 @@ static void __sched notrace __schedule(bool preempt)
> rq = cpu_rq(cpu);
> prev = rq->curr;
>
> - schedule_debug(prev);
> + schedule_debug(prev, preempt);
>
> if (sched_feat(HRTICK))
> hrtick_clear(rq);
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/msm/adreno: Make adreno_gpu_state_get() return void
On Mon, Dec 10, 2018 at 05:34:21PM +0530, Sharat Masetty wrote:
> We are not really checking the state of the adreno_gpu_state_get()
> function at the callers and in addition the state capture is mostly a
> best effort service, so make the function return void.
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 +---
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 +-
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 1ca4bea..40bcf32 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -380,7 +380,7 @@ bool adreno_idle(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring)
> return false;
> }
>
> -int adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state)
> +void adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> int i, count = 0;
> @@ -437,8 +437,6 @@ int adreno_gpu_state_get(struct msm_gpu *gpu, struct
> msm_gpu_state *state)
>
> state->nr_registers = count;
> }
> -
> - return 0;
> }
>
> void adreno_gpu_state_destroy(struct msm_gpu_state *state)
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index 4973c8c..d4834b3 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -235,7 +235,7 @@ int adreno_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
>
> void adreno_gpu_state_destroy(struct msm_gpu_state *state);
>
> -int adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state);
> +void adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state);
> int adreno_gpu_state_put(struct msm_gpu_state *state);
>
> /* ringbuffer helpers (the parts that are adreno specific) */
> --
> 1.9.1
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm: Move the legacy kms disable_all helper to crtc helpers
On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter wrote:
>
> It's not a core function, and the matching atomic functions are also
> not in the core. Plus the suspend/resume helper is also already there.
>
> Needs a tiny bit of open-coding, but less midlayer beats that I think.
>
> Cc: Sam Bobroff
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Ben Skeggs
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: Rex Zhu
> Cc: Andrey Grodzovsky
> Cc: Huang Rui
> Cc: Shaoyun Liu
> Cc: Monk Liu
> Cc: nouv...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> drivers/gpu/drm/drm_crtc.c | 31 ---
> drivers/gpu/drm/drm_crtc_helper.c | 35 ++
> drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
> drivers/gpu/drm/radeon/radeon_display.c| 2 +-
> include/drm/drm_crtc.h | 2 --
> include/drm/drm_crtc_helper.h | 1 +
> 7 files changed, 39 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index c75badfa5c4c..e669297ffefb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2689,7 +2689,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
> amdgpu_irq_disable_all(adev);
> if (adev->mode_info.mode_config_initialized){
> if (!amdgpu_device_has_dc_support(adev))
> - drm_crtc_force_disable_all(adev->ddev);
> + drm_helper_force_disable_all(adev->ddev);
> else
> drm_atomic_helper_shutdown(adev->ddev);
> }
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f660819d406e..7dabbaf033a1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -104,37 +104,6 @@ int drm_crtc_force_disable(struct drm_crtc *crtc)
> return drm_mode_set_config_internal();
> }
>
> -/**
> - * drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
> - * @dev: DRM device whose CRTCs to turn off
> - *
> - * Drivers may want to call this on unload to ensure that all displays are
> - * unlit and the GPU is in a consistent, low power state. Takes modeset
> locks.
> - *
> - * Note: This should only be used by non-atomic legacy drivers. For an atomic
> - * version look at drm_atomic_helper_shutdown().
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_crtc_force_disable_all(struct drm_device *dev)
> -{
> - struct drm_crtc *crtc;
> - int ret = 0;
> -
> - drm_modeset_lock_all(dev);
> - drm_for_each_crtc(crtc, dev)
> - if (crtc->enabled) {
> - ret = drm_crtc_force_disable(crtc);
> - if (ret)
> - goto out;
> - }
> -out:
> - drm_modeset_unlock_all(dev);
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_crtc_force_disable_all);
> -
> static unsigned int drm_num_crtcs(struct drm_device *dev)
> {
> unsigned int num = 0;
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a3c81850e755..23159eb494f1 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -984,3 +984,38 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
> drm_modeset_unlock_all(dev);
> }
> EXPORT_SYMBOL(drm_helper_resume_force_mode);
> +
> +/**
> + * drm_helper_force_disable_all - Forcibly turn off all enabled CRTCs
> + * @dev: DRM device whose CRTCs to turn off
> + *
> + * Drivers may want to call this on unload to ensure that all displays are
> + * unlit and the GPU is in a consistent, low power state. Takes modeset
> locks.
> + *
> + * Note: This should only be used by non-atomic legacy drivers. For an atomic
> + * version look at drm_atomic_helper_shutdown().
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_helper_force_disable_all(struct drm_device *dev)
Maybe put crtc somewhere in the function name so it's clear what we
are disabling. With that fixed:
Reviewed-by: Alex Deucher
> +{
> + struct drm_crtc *crtc;
> + int ret = 0;
> +
> + drm_modeset_lock_all(dev);
> + drm_for_each_crtc(crtc, dev)
> + if (crtc->enabled) {
> + struct drm_mode_set set = {
> + .crtc = crtc,
> + };
> +
> + ret = drm_mode_set_config_internal();
> + if (ret)
> + goto out;
> + }
> +out:
> + drm_modeset_unlock_all(dev);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_helper_force_disable_all);
> diff
Re: [PATCH 2/2] drm/msm/a6xx: Fix NULL dereference during crashstate capture
On Mon, Dec 10, 2018 at 05:34:22PM +0530, Sharat Masetty wrote:
> The gpu crashstate's base objects registers pointer can be NULL if the
> target implementation decides to capture the register dump on its own.
> This patch simply checks for NULL before dereferencing.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 40bcf32..a39cebc 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -415,6 +415,9 @@ void adreno_gpu_state_get(struct msm_gpu *gpu, struct
> msm_gpu_state *state)
> }
> }
>
> + if (!adreno_gpu->registers)
> + return;
> +
This looks good - we should get it in the 4.21 pull.
> /* Count the number of registers */
> for (i = 0; adreno_gpu->registers[i] != ~0; i += 2)
> count += adreno_gpu->registers[i + 1] -
> @@ -550,12 +553,14 @@ void adreno_show(struct msm_gpu *gpu, struct
> msm_gpu_state *state,
> }
> }
>
> - drm_puts(p, "registers:\n");
> + if (state->nr_registers > 0) {
> + drm_puts(p, "registers:\n");
>
> - for (i = 0; i < state->nr_registers; i++) {
> - drm_printf(p, " - { offset: 0x%04x, value: 0x%08x }\n",
> - state->registers[i * 2] << 2,
> - state->registers[(i * 2) + 1]);
> + for (i = 0; i < state->nr_registers; i++) {
> + drm_printf(p, " - { offset: 0x%04x, value: 0x%08x }\n",
> + state->registers[i * 2] << 2,
> + state->registers[(i * 2) + 1]);
> + }
I don't think we need the extra indentation here - something like
for (i = 0; i < state->nr_registers; i++) {
+ if (i == 0)
+ drm_puts(p, "Registers:\n");
drm_printf(p, " - { offset: 0x%04x, value: 0x%08x }\n",
would suffice since we won't go into the loop if state->nr_registers == 0.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109001] Freezes when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=109001 --- Comment #3 from Michel Dänzer --- The Xorg log file doesn't have any messages corresponding to those in dmesg. Was it really captured after reproducing the problem? Does https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/15 help or the freezes by any chance? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109001] Freezes when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=109001 Michel Dänzer changed: What|Removed |Added Attachment #142770|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109001] Freezes when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=109001 --- Comment #2 from Julio --- Created attachment 142770 --> https://bugs.freedesktop.org/attachment.cgi?id=142770=edit Xorg Log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > I do not see any scheduler guys Cced and it would be really great to get
> > their opinion here.
> >
> > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > > In some special cases we must not block, but there's not a
> > > spinlock, preempt-off, irqs-off or similar critical section already
> > > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > > pair to annotate these.
> > >
> > > This will be used in the oom paths of mmu-notifiers, where blocking is
> > > not allowed to make sure there's forward progress.
> >
> > Considering the only alternative would be to abuse
> > preempt_{disable,enable}, and that really has a different semantic, I
> > think this makes some sense. The cotext is preemptible but we do not
> > want notifier to sleep on any locks, WQ etc.
>
> I'm confused... what is this supposed to do?
>
> And what does 'block' mean here? Without preempt_disable/IRQ-off we're
> subject to regular preemption and execution can stall for arbitrary
> amounts of time.
The notifier is called from quite a restricted context - oom_reaper -
which shouldn't depend on any locks or sleepable conditionals. The code
should be swift as well but we mostly do care about it to make a forward
progress. Checking for sleepable context is the best thing we could come
up with that would describe these demands at least partially.
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109001] Freezes when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=109001 Michel Dänzer changed: What|Removed |Added CC||harry.wentl...@amd.com, ||nicholas.kazlaus...@amd.com --- Comment #1 from Michel Dänzer --- Please attach the corresponding Xorg log file. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109001] Freezes when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=109001 Julio changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=105018 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105018] Kernel panic when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=105018 Julio changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=109001 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> I do not see any scheduler guys Cced and it would be really great to get
> their opinion here.
>
> On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > pair to annotate these.
> >
> > This will be used in the oom paths of mmu-notifiers, where blocking is
> > not allowed to make sure there's forward progress.
>
> Considering the only alternative would be to abuse
> preempt_{disable,enable}, and that really has a different semantic, I
> think this makes some sense. The cotext is preemptible but we do not
> want notifier to sleep on any locks, WQ etc.
I'm confused... what is this supposed to do?
And what does 'block' mean here? Without preempt_disable/IRQ-off we're
subject to regular preemption and execution can stall for arbitrary
amounts of time.
The Changelog doesn't yield any clues.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109001] Freezes when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=109001 Bug ID: 109001 Summary: Freezes when waking up after screen goes blank. Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: juliolok...@gmail.com Created attachment 142769 --> https://bugs.freedesktop.org/attachment.cgi?id=142769=edit Dmesg-output Similar to bug 105018, but instead of kernel panic, system freezes for some time after waking screen up. Tested on ArchLinux, it can be reproduced on Linux 4.18 and 4.19, using an AMD RX550. It always happens when using DPMS/Screen blanking, after leaving the screen blank for some minutes and waking it up. It keeps freezing for some time, sometimes for seconds others for minutes. The attached dmesg output is similar to bug 105018. Every time the system is frozen, those 2 lines are shown: "[drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'! [ 1701.356720] [drm:dm_vblank_get_counter [amdgpu]] *ERROR* dc_stream_state is NULL for crtc '1'!" Tried removing xf86-video-amdgpu (DDX Driver), and while the freezes disappear, it takes longer to wake up the screen and dmesg only shows "[amdgpu]] *ERROR* Failed to get VBLANK!" several times. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master boot bisection: Oops in nouveau driver on jetson-tk1
On Mon, Dec 10, 2018 at 10:00:08AM +, Guillaume Tucker wrote: > On 08/12/2018 00:08, Lyude Paul wrote: > > uh > > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > > nouveau_drm_device_init()" > > Yes here's the fix from Thierry: > > https://patchwork.freedesktop.org/patch/263587/ > > > and I can confirm that it does fix the Oops when applied on top > of next-20181206 (what I used for the bisection last week): > > http://lava.baylibre.com:10080/scheduler/job/71109 > > > However the fix doesn't appear to have been applied in any > upstream tree yet. This has been broken for a considerable time now with no response from Ben - is there some other path we can use to get the fix merged? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5/rc6, amdgpu error
https://bugs.freedesktop.org/show_bug.cgi?id=108992 chris changed: What|Removed |Added Summary|Regression: Lenovo e585 |Regression: Lenovo e585 |(ryzen 2500u) freezes |(ryzen 2500u) freezes |during boot with 4.20-rc5, |during boot with |amdgpu error|4.20-rc5/rc6, amdgpu error --- Comment #1 from chris --- Hi, tested with the newly released rc6, same issue. Many thanks ! Christian -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] kernel.h: Add non_block_start/end()
I do not see any scheduler guys Cced and it would be really great to get
their opinion here.
On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used in the oom paths of mmu-notifiers, where blocking is
> not allowed to make sure there's forward progress.
Considering the only alternative would be to abuse
preempt_{disable,enable}, and that really has a different semantic, I
think this makes some sense. The cotext is preemptible but we do not
want notifier to sleep on any locks, WQ etc.
> Suggested by Michal Hocko.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Signed-off-by: Daniel Vetter
> ---
> include/linux/kernel.h | 10 +-
> include/linux/sched.h | 4
> kernel/sched/core.c| 6 +++---
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index d6aac75b51ba..c2cf31515b3d 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -251,7 +251,9 @@ extern int _cond_resched(void);
> * might_sleep - annotation for functions that can sleep
> *
> * this macro will print a stack trace if it is executed in an atomic
> - * context (spinlock, irq-handler, ...).
> + * context (spinlock, irq-handler, ...). Additional sections where blocking
> is
> + * not allowed can be annotated with non_block_start() and non_block_end()
> + * pairs.
> *
> * This is a useful debugging help to be able to catch problems early and not
> * be bitten later when the calling function happens to sleep when it is not
> @@ -260,6 +262,10 @@ extern int _cond_resched(void);
> # define might_sleep() \
> do { __might_sleep(__FILE__, __LINE__, 0); might_resched(); } while (0)
> # define sched_annotate_sleep() (current->task_state_change = 0)
> +# define non_block_start() \
> + do { current->non_block_count++; } while (0)
> +# define non_block_end() \
> + do { WARN_ON(current->non_block_count-- == 0); } while (0)
> #else
>static inline void ___might_sleep(const char *file, int line,
> int preempt_offset) { }
> @@ -267,6 +273,8 @@ extern int _cond_resched(void);
> int preempt_offset) { }
> # define might_sleep() do { might_resched(); } while (0)
> # define sched_annotate_sleep() do { } while (0)
> +# define non_block_start() do { } while (0)
> +# define non_block_end() do { } while (0)
> #endif
>
> #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index ecffd4e37453..41249dbf8f27 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -916,6 +916,10 @@ struct task_struct {
> struct mutex_waiter *blocked_on;
> #endif
>
> +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> + int non_block_count;
> +#endif
> +
> #ifdef CONFIG_TRACE_IRQFLAGS
> unsigned intirq_events;
> unsigned long hardirq_enable_ip;
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 6fedf3a98581..969d7a71f30c 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6113,7 +6113,7 @@ void ___might_sleep(const char *file, int line, int
> preempt_offset)
> rcu_sleep_check();
>
> if ((preempt_count_equals(preempt_offset) && !irqs_disabled() &&
> - !is_idle_task(current)) ||
> + !is_idle_task(current) && !current->non_block_count) ||
> system_state == SYSTEM_BOOTING || system_state > SYSTEM_RUNNING ||
> oops_in_progress)
> return;
> @@ -6129,8 +6129,8 @@ void ___might_sleep(const char *file, int line, int
> preempt_offset)
> "BUG: sleeping function called from invalid context at %s:%d\n",
> file, line);
> printk(KERN_ERR
> - "in_atomic(): %d, irqs_disabled(): %d, pid: %d, name: %s\n",
> - in_atomic(), irqs_disabled(),
> + "in_atomic(): %d, irqs_disabled(): %d, non_block: %d, pid: %d,
> name: %s\n",
> + in_atomic(), irqs_disabled(), current->non_block_count,
> current->pid, current->comm);
>
> if (task_stack_end_corrupted(current))
> --
> 2.20.0.rc1
>
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-18.30 1/1] include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file
tree: git://people.freedesktop.org/~agd5f/linux.git amd-18.30 head: 656ec78b706b16480ab37fc0751de0c3a709aa6e commit: 656ec78b706b16480ab37fc0751de0c3a709aa6e [1/1] drm/amdgpu/vcn: Update vcn.cur_state during suspend config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 656ec78b706b16480ab37fc0751de0c3a709aa6e # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file -- >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file drivers/gpu/drm/amd/amdgpu/vce_v2_0.c:645:38: warning: symbol 'vce_v2_0_ip_block' was not declared. Should it be static? -- >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:70:25: warning: mixing different enum types drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:70:25: int enum dce_version versus drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:70:25: unsigned int enum dce_environment drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:76:25: warning: mixing different enum types drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:76:25: int enum dce_version versus drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:76:25: unsigned int enum dce_environment -- >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/hw_factory.c:96:6: warning: symbol 'dal_hw_factory_destroy' was not declared. Should it be static? -- >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:621:22: warning: Variable length array is used. drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:671:22: warning: Variable length array is used. drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:721:22: warning: Variable length array is used. -- >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:171:32: warning: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:172:21: warning: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:174:39: warning: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:175:22: warning: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:177:39: warning: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:388:30: warning: incorrect type in initializer (different address spaces) drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:388:30:expected void [noderef] *ptr drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:388:30:got void * -- >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:417:30: warning: incorrect type in initializer (different address spaces) drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:417:30:expected void [noderef] *ptr drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:417:30:got void * -- >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file drivers/gpu/drm/amd/amdgpu/atombios_dp.c:78:30: warning: incorrect type in assignment (different base types) drivers/gpu/drm/amd/amdgpu/atombios_dp.c:78:30:expected unsigned short [unsigned] [addressable] [usertype] lpAuxRequest drivers/gpu/drm/amd/amdgpu/atombios_dp.c:78:30:got restricted __le16 [usertype] drivers/gpu/drm/amd/amdgpu/atombios_dp.c:79:27: warning: incorrect type in assignment (different base types) drivers/gpu/drm/amd/amdgpu/atombios_dp.c:79:27:expected unsigned short [unsigned] [addressable] [usertype] lpDataOut drivers/gpu/drm/amd/amdgpu/atombios_dp.c:79:27:got restricted __le16 [usertype] -- >> include/kcl/kcl_drm_global.h:46:30: warning: no newline at end of file drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2938:25: warning: incorrect type in assignment (different base types) drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2938:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2938:25:got restricted __le32 [usertype] drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2939:25: warning: incorrect type in assignment (different base types) drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2939:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2939:25:got restricted __le32 [usertype] drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2940:25: warning: incorrect type in assignment (different base types) drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2940:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2940:25:got restricted __le32 [usertype] drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2941:25: warning: incorrect type in
[Bug 108981] Kernel 4.19 won't boot with amdgpu (black screen) for some video cards
https://bugs.freedesktop.org/show_bug.cgi?id=108981 MirceaKitsune changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from MirceaKitsune --- Seems to be resolved in openSUSE Tumbleweed snapshot 20181208. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108981] Kernel 4.19 won't boot with amdgpu (black screen) for some video cards
https://bugs.freedesktop.org/show_bug.cgi?id=108981 --- Comment #2 from MirceaKitsune --- It seems further debugging might not be needed: As of kernel 4.19.7 the issue appears to go away, I'm able to boot with amdgpu normally like before. The last kernel I still saw the problem with is 4.19.5. Anyone know what could have changed in between them, so perhaps we can keep a lookout for such an issue in the future and prevent it? Perhaps this might have been a package issue in openSUSE: Michel Dänzer suggested that as of 4.19, the kernel loads all firmware from "path/firmware/amdgpu/" instead of falling back to "path/firmware/radeon/" when something is missing. Did the Tumbleweed snapshot 20181208 make any updates in this regard? In any case, I'll mark this as resolved and reopen in case the issue ever returns. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm: Split out drm_probe_helper.h
Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard a écrit : > > Le lun. 10 déc. 2018 à 11:24, Thierry Reding > a écrit : > > > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > > Having the probe helper stuff (which pretty much everyone needs) in > > > the drm_crtc_helper.h file (which atomic drivers should never need) is > > > confusing. Split them out. > > > > > > To make sure I actually achieved the goal here I went through all > > > drivers. And indeed, all atomic drivers are now free of > > > drm_crtc_helper.h includes. > > > > > I have difficulties to apply this with git on top of drm-misc-next. > It is because of that I got errors (encoder and connector types not > found) while compiling adv7511_audio.c and exynos_dp.c ? > Nack on this patch because it break compiling at least on sti driver. drm_probe_helper.h doesn't bring the same includes than drm_crtc_helper.h: #include #include #include so some types, structures and functions proptotypes are missing while compiling. > Benjamin > > > Signed-off-by: Daniel Vetter > > > Cc: linux-arm-ker...@lists.infradead.org > > > Cc: virtualizat...@lists.linux-foundation.org > > > Cc: etna...@lists.freedesktop.org > > > Cc: linux-samsung-...@vger.kernel.org > > > Cc: intel-...@lists.freedesktop.org > > > Cc: linux-media...@lists.infradead.org > > > Cc: linux-amlo...@lists.infradead.org > > > Cc: linux-arm-...@vger.kernel.org > > > Cc: freedr...@lists.freedesktop.org > > > Cc: nouv...@lists.freedesktop.org > > > Cc: spice-de...@lists.freedesktop.org > > > Cc: amd-...@lists.freedesktop.org > > > Cc: linux-renesas-...@vger.kernel.org > > > Cc: linux-rockc...@lists.infradead.org > > > Cc: linux-st...@st-md-mailman.stormreply.com > > > Cc: linux-te...@vger.kernel.org > > > Cc: xen-de...@lists.xen.org > > > --- > > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > > > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > > > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > > > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > > > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > > > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > > > drivers/gpu/drm/armada/armada_510.c | 2 +- > > > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > > > drivers/gpu/drm/armada/armada_drv.c | 2 +- > > > drivers/gpu/drm/armada/armada_fb.c| 2 +- > > > drivers/gpu/drm/ast/ast_drv.c | 1 + > > > drivers/gpu/drm/ast/ast_mode.c| 1 + > > > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > > > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > > > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > > > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > > > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > > > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > > > drivers/gpu/drm/bridge/panel.c| 2 +- > > > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > > > drivers/gpu/drm/bridge/tc358764.c | 2 +- > > > drivers/gpu/drm/bridge/tc358767.c | 2 +- > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > > > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > > > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > > > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > > > drivers/gpu/drm/drm_atomic_helper.c | 1 - > > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > > > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > > > drivers/gpu/drm/drm_probe_helper.c| 2 +- > > > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > > > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > > > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > > > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > > >
Re: [PATCH 0/5] drm: ti-tfp410 improvements
On 06/12/18 22:26, Laurent Pinchart wrote: > Hello, > > This small patch series improves the ti-tfp410 driver with three new features, > in patch 2/5 to 5/5. Patch 1/5 has been previously posted by Stefan, and I've > included it here to support patch 5/5 that needs to store other polarity > information in the bridge timings than the sampling edges. > > These changes are meant to support the missing tfp410 features currently > implemented in the omapdrm custom tfp410 driver, in order to move to > drm_bridge. > > The series is based on top of the "[PATCH v2 0/2] Clarify display info PIXDATA > bus flags" series [1] previously posted on the mailing list. > > [1] https://lists.freedesktop.org/archives/dri-devel/2018-December/199204.html > > Laurent Pinchart (4): > dt-bindings: display: tfp410: Add bus parameters properties > drm/bridge: ti-tfp410: Set connector type based on DT connector node > drm/bridge: ti-tfp410: Add support for the powerdown GPIO > drm/bridge: ti-tfp410: Report input bus config through bridge timings > > Stefan Agner (1): > drm/bridge: use bus flags in bridge timings > > .../bindings/display/bridge/ti,tfp410.txt | 24 +++- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 109 +- > include/drm/drm_bridge.h | 12 +- > 4 files changed, 131 insertions(+), 20 deletions(-) For the series: Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
On Mon 10-12-18 11:36:38, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 mmu notifiers and
> whether we could use the newly-introduced return value to handle some
> corner cases. Until we realized that these are only for when a task
> has been killed by the oom reaper.
>
> An alternative approach would be to split the callback into two
> versions, one with the int return value, and the other with void
> return value like in older kernels. But that's a lot more churn for
> fairly little gain I think.
>
> Summary from the m-l discussion on why we want something at warning
> level: This allows automated tooling in CI to catch bugs without
> humans having to look at everything. If we just upgrade the existing
> pr_info to a pr_warn, then we'll have false positives. And as-is, no
> one will ever spot the problem since it's lost in the massive amounts
> of overall dmesg noise.
OK, fair enough. If this is going to help with testing then I do not
have any objections of course.
> v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> the problematic case (Michal Hocko).
Thanks!
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Christian König"
> Cc: David Rientjes
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: Paolo Bonzini
> Signed-off-by: Daniel Vetter
> ---
> mm/mmu_notifier.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 5119ff846769..ccc22f21b735 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -190,6 +190,9 @@ int __mmu_notifier_invalidate_range_start(struct
> mm_struct *mm,
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
>
> mn->ops->invalidate_range_start, _ret,
> !blockable ? "non-" : "");
> + if (blockable)
> + pr_warn("%pS callback failure not
> allowed\n",
> +
> mn->ops->invalidate_range_start);
> ret = _ret;
> }
> }
> --
> 2.20.0.rc1
>
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: gpu: mali-midgard: Add resets property
The Amlogic ARM Mali Midgard requires reset controls to power on and software reset the GPU, adds these as optional in the bindings. Signed-off-by: Neil Armstrong --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 18a2cde2e5f3..24d83ec952f1 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -37,6 +37,8 @@ Optional properties: - operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt for details. +- resets : Phandle to the reset controls for the Mali Midgard device. + Example for a Mali-T760: -- 2.19.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] arm64: meson-gxm: Add support for the Mali T820 GPU
This patchset adds : - Optional reset properties in the midgard bindings - Mali T820 Node in Amlogic Meson GXM DTSI Christian Hewitt (1): arm64: dts: meson-gxm: Add Mali-T820 node Neil Armstrong (1): dt-bindings: gpu: mali-midgard: Add resets property .../bindings/gpu/arm,mali-midgard.txt | 2 ++ arch/arm64/boot/dts/amlogic/meson-gxm.dtsi| 27 +++ 2 files changed, 29 insertions(+) -- 2.19.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] arm64: dts: meson-gxm: Add Mali-T820 node
From: Christian Hewitt
The Amlogic Meson GXM SoC embeds an ARM Mali T820 GPU.
This patch adds the node with all the needed properties to power
on the GPU.
This has been tested with the work-in-progress PanFrost project
aiming support for ARM Mali Midgard and later GPUs.
Signed-off-by: Christian Hewitt
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 27 ++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index 247888d68a3a..35e59d390903 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -91,6 +91,33 @@
reset-names = "phy";
status = "okay";
};
+
+ mali: gpu@c {
+ compatible = "amlogic,meson-gxm-mali", "arm,mali-t820";
+ reg = <0x0 0xc 0x0 0x4>;
+ interrupt-parent = <>;
+ interrupts = ,
+,
+;
+ interrupt-names = "gpu", "mmu", "job";
+ clocks = < CLKID_MALI>;
+ resets = < RESET_MALI_CAPB3>, < RESET_MALI>;
+
+ /*
+* Mali clocking is provided by two identical clock paths
+* MALI_0 and MALI_1 muxed to a single clock by a glitch
+* free mux to safely change frequency while running.
+*/
+ assigned-clocks = < CLKID_MALI_0_SEL>,
+ < CLKID_MALI_0>,
+ < CLKID_MALI>; /* Glitch free mux */
+ assigned-clock-parents = < CLKID_FCLK_DIV3>,
+<0>, /* Do Nothing */
+< CLKID_MALI_0>;
+ assigned-clock-rates = <0>, /* Do Nothing */
+ <6>,
+ <0>; /* Do Nothing */
+ };
};
_AO {
--
2.19.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/qxl: Don't set the dpms hook
On Mon, Dec 10, 2018 at 11:03:57AM +0100, Daniel Vetter wrote:
> Doesn't do anything with atomic.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index ce0b9c40fc21..72a1784dae54 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -1010,7 +1010,6 @@ static void qxl_conn_destroy(struct drm_connector
> *connector)
> }
>
> static const struct drm_connector_funcs qxl_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
> .detect = qxl_conn_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy = qxl_conn_destroy,
Reviewed-by: Gerd Hoffmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: fix for 64bit seqno change
Am Freitag, den 07.12.2018, 20:11 +0100 schrieb Christian König:
> The fence seqno is now 64bit, fixes build warning.
>
> Signed-off-by: Christian König
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index 1fa74226db91..5c48915f492d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -449,7 +449,7 @@ static void etnaviv_gem_describe_fence(struct
> dma_fence *fence,
> const char *type, struct seq_file *m)
> {
> if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
> - seq_printf(m, "\t%9s: %s %s seq %u\n",
> + seq_printf(m, "\t%9s: %s %s seq %llu\n",
> type,
> fence->ops->get_driver_name(fence),
> fence->ops->get_timeline_name(fence),
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][drm-next] drm/selftest: fix spelling mistake "dimention" -> "dimenstion"
On Mon, 2018-12-10 at 09:26 +, Colin King wrote:
Reviewed-by: Thomas Hellstrom
I'll take this in the next pull request unless I'm told otherwise.
/Thomas
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err message, fix this.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/selftests/test-drm_damage_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> b/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> index a2f753205a3e..9d2bcdf8bc29 100644
> --- a/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> +++ b/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> @@ -53,7 +53,7 @@ static bool check_damage_clip(struct
> drm_plane_state *state, struct drm_rect *r,
> int src_y2 = (state->src.y2 >> 16) + !!(state->src.y2 &
> 0x);
>
> if (x1 >= x2 || y1 >= y2) {
> - pr_err("Cannot have damage clip with no dimention.\n");
> + pr_err("Cannot have damage clip with no dimension.\n");
> return false;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] arm64: dts: renesas: r8a77995: draak: Add backlight
Hi Geert, On Monday, 10 December 2018 14:30:22 EET Geert Uytterhoeven wrote: > On Tue, Dec 4, 2018 at 6:36 PM Geert Uytterhoeven wrote: > > On Sun, Nov 25, 2018 at 3:40 PM Laurent Pinchart wrote: > >> Add the backlight device for the LVDS1 output, in preparation for panel > >> support. > >> > >> Signed-off-by: Laurent Pinchart > >> > > > > Reviewed-by: Geert Uytterhoeven > > Oops, seems I missed the backlight node should be moved up, to preserve > sort order. I assumed that aliases and chosen should be kept at the top of the file. Maybe we don't want to keep the tradition :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] arm64: dts: renesas: r8a77995: draak: Add backlight
Hi Laurent,
On Tue, Dec 4, 2018 at 6:36 PM Geert Uytterhoeven wrote:
> On Sun, Nov 25, 2018 at 3:40 PM Laurent Pinchart
> wrote:
> > Add the backlight device for the LVDS1 output, in preparation for panel
> > support.
> >
> > Signed-off-by: Laurent Pinchart
>
> Reviewed-by: Geert Uytterhoeven
Oops, seems I missed the backlight node should be moved up, to preserve
sort order.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm: Split out drm_probe_helper.h
On 10/12/2018 11:11, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > drivers/gpu/drm/armada/armada_510.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > drivers/gpu/drm/armada/armada_drv.c | 2 +- > drivers/gpu/drm/armada/armada_fb.c| 2 +- > drivers/gpu/drm/ast/ast_drv.c | 1 + > drivers/gpu/drm/ast/ast_mode.c| 1 + > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > drivers/gpu/drm/bridge/panel.c| 2 +- > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > drivers/gpu/drm/bridge/tc358764.c | 2 +- > drivers/gpu/drm/bridge/tc358767.c | 2 +- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > drivers/gpu/drm/drm_probe_helper.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +- > drivers/gpu/drm/gma500/psb_intel_drv.h| 1 + > .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2
[PATCH 30/29] drm/omap: Merge omap_dss_device type and output_type fields
The omap_dss_device type and output_type fields differ mostly for historical reasons. The output_type field is required for all devices but the display at the end of the pipeline, and must be set to OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for all devices but the internal encoder, for which it is ignored. The only reason why the output_type field must be set to OMAP_DISPLAY_TYPE_NONE for the display at the end of the pipeline is to identify omap_dss_device instances corresponding to displays. This is not documented and confusing. Clean the code by adding a new display field to the omap_dss_device structure to identify displays, and merge the type and output_type fields. Signed-off-by: Laurent Pinchart --- .../gpu/drm/omapdrm/displays/connector-analog-tv.c | 1 + drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 1 + drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 1 + drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 1 - drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 1 - .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 1 - drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 1 + drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 1 + .../omapdrm/displays/panel-lgphilips-lb035q02.c| 1 + .../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 1 + .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 1 + .../drm/omapdrm/displays/panel-sony-acx565akm.c| 1 + .../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 1 + .../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 1 + drivers/gpu/drm/omapdrm/dss/base.c | 2 +- drivers/gpu/drm/omapdrm/dss/dpi.c | 2 +- drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +- drivers/gpu/drm/omapdrm/dss/hdmi4.c| 2 +- drivers/gpu/drm/omapdrm/dss/hdmi5.c| 2 +- drivers/gpu/drm/omapdrm/dss/omapdss.h | 14 +- drivers/gpu/drm/omapdrm/dss/output.c | 2 +- drivers/gpu/drm/omapdrm/dss/sdi.c | 2 +- drivers/gpu/drm/omapdrm/dss/venc.c | 2 +- drivers/gpu/drm/omapdrm/omap_crtc.c| 2 +- drivers/gpu/drm/omapdrm/omap_encoder.c | 4 ++-- 25 files changed, 31 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c index 1503563117f3..6c0561101874 100644 --- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c +++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c @@ -56,6 +56,7 @@ static int tvc_probe(struct platform_device *pdev) dssdev->ops = _ops; dssdev->dev = >dev; dssdev->type = OMAP_DISPLAY_TYPE_VENC; + dssdev->display = true; dssdev->owner = THIS_MODULE; dssdev->of_ports = BIT(0); diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c index bf5ee50ce5fe..fa3a69bf8a04 100644 --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c +++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c @@ -239,6 +239,7 @@ static int dvic_probe(struct platform_device *pdev) dssdev->ops = _ops; dssdev->dev = >dev; dssdev->type = OMAP_DISPLAY_TYPE_DVI; + dssdev->display = true; dssdev->owner = THIS_MODULE; dssdev->of_ports = BIT(0); diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c index 797da4a3f22e..68d6f6e44b03 100644 --- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c +++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c @@ -140,6 +140,7 @@ static int hdmic_probe(struct platform_device *pdev) dssdev->ops = _ops; dssdev->dev = >dev; dssdev->type = OMAP_DISPLAY_TYPE_HDMI; + dssdev->display = true; dssdev->owner = THIS_MODULE; dssdev->of_ports = BIT(0); dssdev->ops_flags = ddata->hpd_gpio diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c index fc5e0c47054d..29a5a130ebd1 100644 --- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c +++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c @@ -88,7 +88,6 @@ static int opa362_probe(struct platform_device *pdev) dssdev->ops = _ops; dssdev->dev = >dev; dssdev->type = OMAP_DISPLAY_TYPE_VENC; - dssdev->output_type = OMAP_DISPLAY_TYPE_VENC; dssdev->owner = THIS_MODULE; dssdev->of_ports = BIT(1) | BIT(0); diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c index 82035078377a..fb88537de1cc 100644 --- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c @@ -84,7 +84,6 @@ static int tfp410_probe(struct platform_device *pdev) dssdev->ops = _ops; dssdev->dev = >dev; dssdev->type =
[PATCH 2/2] drm/msm/a6xx: Fix NULL dereference during crashstate capture
The gpu crashstate's base objects registers pointer can be NULL if the
target implementation decides to capture the register dump on its own.
This patch simply checks for NULL before dereferencing.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 40bcf32..a39cebc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -415,6 +415,9 @@ void adreno_gpu_state_get(struct msm_gpu *gpu, struct
msm_gpu_state *state)
}
}
+ if (!adreno_gpu->registers)
+ return;
+
/* Count the number of registers */
for (i = 0; adreno_gpu->registers[i] != ~0; i += 2)
count += adreno_gpu->registers[i + 1] -
@@ -550,12 +553,14 @@ void adreno_show(struct msm_gpu *gpu, struct
msm_gpu_state *state,
}
}
- drm_puts(p, "registers:\n");
+ if (state->nr_registers > 0) {
+ drm_puts(p, "registers:\n");
- for (i = 0; i < state->nr_registers; i++) {
- drm_printf(p, " - { offset: 0x%04x, value: 0x%08x }\n",
- state->registers[i * 2] << 2,
- state->registers[(i * 2) + 1]);
+ for (i = 0; i < state->nr_registers; i++) {
+ drm_printf(p, " - { offset: 0x%04x, value: 0x%08x }\n",
+ state->registers[i * 2] << 2,
+ state->registers[(i * 2) + 1]);
+ }
}
}
#endif
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm/adreno: Make adreno_gpu_state_get() return void
We are not really checking the state of the adreno_gpu_state_get()
function at the callers and in addition the state capture is mostly a
best effort service, so make the function return void.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 +---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 1ca4bea..40bcf32 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -380,7 +380,7 @@ bool adreno_idle(struct msm_gpu *gpu, struct msm_ringbuffer
*ring)
return false;
}
-int adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state)
+void adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i, count = 0;
@@ -437,8 +437,6 @@ int adreno_gpu_state_get(struct msm_gpu *gpu, struct
msm_gpu_state *state)
state->nr_registers = count;
}
-
- return 0;
}
void adreno_gpu_state_destroy(struct msm_gpu_state *state)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 4973c8c..d4834b3 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -235,7 +235,7 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
void adreno_gpu_state_destroy(struct msm_gpu_state *state);
-int adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state);
+void adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state);
int adreno_gpu_state_put(struct msm_gpu_state *state);
/* ringbuffer helpers (the parts that are adreno specific) */
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 8/9] drm/doc: Add initial komeda driver documentation
On Wed, Dec 05, 2018 at 06:08:38PM -0800, Randy Dunlap wrote: > On 12/5/18 2:25 AM, james qian wang (Arm Technology China) wrote: > > Signed-off-by: James (Qian) Wang > > --- > > Documentation/gpu/drivers.rst| 1 + > > Documentation/gpu/komeda-kms.rst | 483 +++ > > 2 files changed, 484 insertions(+) > > create mode 100644 Documentation/gpu/komeda-kms.rst > > Hi, > > I have some editing changes for you to consider, although I did have a few > problems with reading the text. > Thank you Randy, I'll correct the doc according to your comments in the next version. > > > diff --git a/Documentation/gpu/komeda-kms.rst > > b/Documentation/gpu/komeda-kms.rst > > new file mode 100644 > > index ..8af925ca0869 > > --- /dev/null > > +++ b/Documentation/gpu/komeda-kms.rst > > @@ -0,0 +1,483 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +== > > + drm/komeda ARM display driver > > +== > > + > > +The drm/komeda driver supports for the ARM display processor D71 and later > > driver supports the ARM > > > +IPs, this document is for giving a brief overview of driver design: how it > >IPs. This document gives a brief overview of the driver design: > > (although I hate using "IPs" like that.) How about "Product" or "Chipset" > > > +works and why design it like that. > > + > > +Overview of D71 like display IPs > > + > > + > > +From D71, Arm display IP begins to adopt a flexible and modularized > > ARM Sorry my fault, I used "ARM" in the initial lines which misleads you, but after Arm reband last year, the "Arm" is the right version. And I'll unify all the usage to "Arm" in the next version. > > > +architecture. A display pipeline is made up of multiple individual and > > +functional pipeline stages called components, and every component has some > > +specific capabilities that can give the flowed pipeline pixel data a > > +particular processing. > > + > > +Typical D71 components: > > + > > +Layer > > +- > > +Layer is the first pipeline stage, which is for preparing the pixel data > > +for the next stage. It fetches the pixel from memory, decodes it if it's > > +AFBC, rotates the source image, unpacks or converts YUV pixels to the > > device > > +internal RGB pixels, then adjust the color_space of pixels if need. > > adjusts if needed. > > > > + > > +Scaler > > +-- > > +As its name, scaler is taking responsability for scaling, and D71 also > > As its name suggests, scaler takes (or has) responsibility for > > > +supports image enhancements by scaler. > > +The usage of scaler is very flexible and can be connected to layer output > > +for layer scaling, or connected to compositor and scale the whole display > > +frame and then feed the output data into wb_layer which will then write it > > +into memory. > > + > > +Compositor (compiz) > > +--- > > +Compositor is for blending multiple layers or pixel data flows into one > > +single display frame, and its output frame can be fed into post image > > +processor and then on the monitor or fed into wb_layer and written to > > memory > > +at the same time. And user also can insert a scaler between compositor and > > +wb_layer to down scale the display frame first and then writing to memory. > > and then write to memory. > > > + > > +Writeback Layer (wb_layer) > > +-- > > +Writeback layer do the opposite things of Layer, Which connect to compiz > > and try > >does which > > > +to write the composition result to memory. > > + > > +Post image processor (improc) > > +- > > +Post image processor is for adjusting frame data like gamma and color space > > +to fit the requirements of the monitor. > > + > > +Timing controller (timing_ctrlr) > > + > > +Final stage of display pipeline, Timing controller is not for the pixel > > +handling, but only for controlling the display timing. > > + > > +Merger > > +-- > > +D71 scaler mostly only has half the horizontal input/output capabilities > > compare > > > compared > > > +with Layer, Like if Layer supports 4K input size, the scaler only can > > supports > >like > support > > > +2K input/output in some time. To achieve the fully frame scaling, D71 > > introduce > > full > introduces > > > +Layer Split, which split the whole image to two half part and feed them to > > two > > splitsparts and feeds > > > +Layers A
[Bug 108981] Kernel 4.19 won't boot with amdgpu (black screen) for some video cards
https://bugs.freedesktop.org/show_bug.cgi?id=108981 Michel Dänzer changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Component|Driver/AMDgpu |DRM/AMDgpu Product|xorg|DRI QA Contact|xorg-t...@lists.x.org | --- Comment #1 from Michel Dänzer --- Sounds like it's probably failing to load some microcode files. The amdgpu driver in 4.19 started loading some of them from .../firmware/amdgpu/ instead of .../firmware/radeon/. If you don't have the former files yet, you can create symlinks for them pointing to the radeon directory for now. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/exynos/fimd: add dynamic zpos support
FIMD has fixed hardware window order. To implement dynamic zpos
normalized_zpos of active plane has to be connected to window number, and
remaining windows have to be disabled.
v2: fixed pixel format setting
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 46 ++--
1 file changed, 18 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a7993f5d8371..46588a14f0c3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -228,14 +228,6 @@ static const uint32_t fimd_formats[] = {
DRM_FORMAT_ARGB,
};
-static const unsigned int capabilities[WINDOWS_NR] = {
- 0,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
-};
-
static inline void fimd_set_bits(struct fimd_context *ctx, u32 reg, u32 mask,
u32 val)
{
@@ -636,12 +628,13 @@ static void fimd_win_set_bldmod(struct fimd_context *ctx,
unsigned int win,
BLENDCON_NEW_8BIT_ALPHA_VALUE);
}
-static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
- struct drm_framebuffer *fb, int width)
+static void fimd_win_set_pixfmt(struct fimd_context *ctx,
+ struct exynos_drm_plane *plane)
{
- struct exynos_drm_plane plane = ctx->planes[win];
struct exynos_drm_plane_state *state =
- to_exynos_plane_state(plane.base.state);
+ to_exynos_plane_state(plane->base.state);
+ unsigned int win = state->base.normalized_zpos;
+ struct drm_framebuffer *fb = state->base.fb;
uint32_t pixel_format = fb->format->format;
unsigned int alpha = state->base.alpha;
u32 val = WINCONx_ENWIN;
@@ -698,7 +691,7 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx,
unsigned int win,
* still better to change dma-burst than displaying garbage.
*/
- if (width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
+ if (state->src.w < MIN_FB_WIDTH_FOR_16WORD_BURST) {
val &= ~WINCONx_BURSTLEN_MASK;
val |= WINCONx_BURSTLEN_4WORD;
}
@@ -781,6 +774,12 @@ static void fimd_atomic_flush(struct exynos_drm_crtc *crtc)
if (ctx->suspended)
return;
+ for (i = hweight32(crtc->base.state->plane_mask); i < WINDOWS_NR; i++) {
+ if (!(readl(ctx->regs + WINCON(i)) & WINCONx_ENWIN))
+ break;
+ fimd_disable_win(ctx, i);
+ }
+
for (i = 0; i < WINDOWS_NR; i++)
fimd_shadow_protect_win(ctx, i, false);
@@ -797,7 +796,7 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
dma_addr_t dma_addr;
unsigned long val, size, offset;
unsigned int last_x, last_y, buf_offsize, line_size;
- unsigned int win = plane->index;
+ unsigned int win = state->base.normalized_zpos;
unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
@@ -864,7 +863,7 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
DRM_DEBUG_KMS("osd size = 0x%x\n", (unsigned int)val);
}
- fimd_win_set_pixfmt(ctx, win, fb, state->src.w);
+ fimd_win_set_pixfmt(ctx, plane);
/* hardware window 0 doesn't support color key. */
if (win != 0)
@@ -879,17 +878,6 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
atomic_set(>win_updated, 1);
}
-static void fimd_disable_plane(struct exynos_drm_crtc *crtc,
- struct exynos_drm_plane *plane)
-{
- struct fimd_context *ctx = crtc->ctx;
-
- if (ctx->suspended)
- return;
-
- fimd_disable_win(ctx, plane->index);
-}
-
static void fimd_enable(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc->ctx;
@@ -1008,7 +996,6 @@ static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
.disable_vblank = fimd_disable_vblank,
.atomic_begin = fimd_atomic_begin,
.update_plane = fimd_update_plane,
- .disable_plane = fimd_disable_plane,
.atomic_flush = fimd_atomic_flush,
.atomic_check = fimd_atomic_check,
.te_handler = fimd_te_handler,
@@ -1062,7 +1049,10 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[i].num_pixel_formats = ARRAY_SIZE(fimd_formats);
ctx->configs[i].zpos = i;
ctx->configs[i].type = fimd_win_types[i];
- ctx->configs[i].capabilities = capabilities[i];
+ ctx->configs[i].capabilities =
[PATCH v2 1/3] drm/exynos/decon5433: add dynamic zpos support
DECON has fixed hardware window order. To implement dynamic zpos
normalized_zpos of active plane has to be connected to window number, and
remaining windows have to be disabled.
v2: fixed pixel format setting
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 45 ---
1 file changed, 19 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5b4e0e8b23bc..bdfec5f977e9 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -83,14 +83,6 @@ static const enum drm_plane_type decon_win_types[WINDOWS_NR]
= {
[CURSON_WIN] = DRM_PLANE_TYPE_CURSOR,
};
-static const unsigned int capabilities[WINDOWS_NR] = {
- 0,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
-};
-
static inline void decon_set_bits(struct decon_context *ctx, u32 reg, u32 mask,
u32 val)
{
@@ -314,12 +306,13 @@ static void decon_win_set_bldmod(struct decon_context
*ctx, unsigned int win,
}
}
-static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
-struct drm_framebuffer *fb)
+static void decon_win_set_pixfmt(struct decon_context *ctx,
+struct exynos_drm_plane *plane)
{
- struct exynos_drm_plane plane = ctx->planes[win];
struct exynos_drm_plane_state *state =
- to_exynos_plane_state(plane.base.state);
+ to_exynos_plane_state(plane->base.state);
+ unsigned int win = state->base.normalized_zpos + ctx->first_win;
+ struct drm_framebuffer *fb = state->base.fb;
unsigned int alpha = state->base.alpha;
unsigned int pixel_alpha;
unsigned long val;
@@ -402,7 +395,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
to_exynos_plane_state(plane->base.state);
struct decon_context *ctx = crtc->ctx;
struct drm_framebuffer *fb = state->base.fb;
- unsigned int win = plane->index;
+ unsigned int win = state->base.normalized_zpos + ctx->first_win;
unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
@@ -446,25 +439,24 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
| BIT_VAL(state->crtc.w * cpp, 14, 0);
writel(val, ctx->addr + DECON_VIDW0xADD2(win));
- decon_win_set_pixfmt(ctx, win, fb);
+ decon_win_set_pixfmt(ctx, plane);
/* window enable */
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
}
-static void decon_disable_plane(struct exynos_drm_crtc *crtc,
- struct exynos_drm_plane *plane)
-{
- struct decon_context *ctx = crtc->ctx;
- unsigned int win = plane->index;
-
- decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
-}
-
static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
unsigned long flags;
+ int win = hweight32(crtc->base.state->plane_mask) + ctx->first_win;
+
+ /* disable windows corresponding to disabled planes */
+ for (; win < WINDOWS_NR; ++win) {
+ if (!readl(ctx->addr + DECON_WINCONx(win)) & WINCONx_ENWIN_F)
+ break;
+ decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
+ }
spin_lock_irqsave(>vblank_lock, flags);
@@ -538,7 +530,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
* a destroyed buffer later.
*/
for (i = ctx->first_win; i < WINDOWS_NR; i++)
- decon_disable_plane(crtc, >planes[i]);
+ decon_set_bits(ctx, DECON_WINCONx(i), WINCONx_ENWIN_F, 0);
decon_swreset(ctx);
@@ -607,7 +599,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.disable_vblank = decon_disable_vblank,
.atomic_begin = decon_atomic_begin,
.update_plane = decon_update_plane,
- .disable_plane = decon_disable_plane,
.mode_valid = decon_mode_valid,
.atomic_flush = decon_atomic_flush,
};
@@ -628,7 +619,9 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[win].num_pixel_formats = ARRAY_SIZE(decon_formats);
ctx->configs[win].zpos = win - ctx->first_win;
ctx->configs[win].type = decon_win_types[win];
- ctx->configs[win].capabilities = capabilities[win];
+
[PATCH v2 2/3] drm/exynos/fimd: create local helper for disabling hardware window
Hardware window disabling is performed in multiple places. Creating
helper for it simplifies the code and prepares it for further improvements.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 786a8ee6f10f..a7993f5d8371 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -345,6 +345,14 @@ static void fimd_enable_shadow_channel_path(struct
fimd_context *ctx,
writel(val, ctx->regs + SHADOWCON);
}
+static void fimd_disable_win(struct fimd_context *ctx, int win)
+{
+ fimd_enable_video_output(ctx, win, false);
+
+ if (ctx->driver_data->has_shadowcon)
+ fimd_enable_shadow_channel_path(ctx, win, false);
+}
+
static void fimd_clear_channels(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc->ctx;
@@ -363,12 +371,7 @@ static void fimd_clear_channels(struct exynos_drm_crtc
*crtc)
u32 val = readl(ctx->regs + WINCON(win));
if (val & WINCONx_ENWIN) {
- fimd_enable_video_output(ctx, win, false);
-
- if (ctx->driver_data->has_shadowcon)
- fimd_enable_shadow_channel_path(ctx, win,
- false);
-
+ fimd_disable_win(ctx, win);
ch_enabled = 1;
}
}
@@ -880,15 +883,11 @@ static void fimd_disable_plane(struct exynos_drm_crtc
*crtc,
struct exynos_drm_plane *plane)
{
struct fimd_context *ctx = crtc->ctx;
- unsigned int win = plane->index;
if (ctx->suspended)
return;
- fimd_enable_video_output(ctx, win, false);
-
- if (ctx->driver_data->has_shadowcon)
- fimd_enable_shadow_channel_path(ctx, win, false);
+ fimd_disable_win(ctx, plane->index);
}
static void fimd_enable(struct exynos_drm_crtc *crtc)
@@ -923,7 +922,7 @@ static void fimd_disable(struct exynos_drm_crtc *crtc)
* a destroyed buffer later.
*/
for (i = 0; i < WINDOWS_NR; i++)
- fimd_disable_plane(crtc, >planes[i]);
+ fimd_disable_win(ctx, i);
fimd_enable_vblank(crtc);
fimd_wait_for_vblank(crtc);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD
Hi Inki, This small patchset adds dynamic zpos support for DECON and FIMD. It was tested on tm2 and trats2. The patchset is rebased on current exynos-drm-next. v2: I have forgot to update *win_set_pixfmt to set pixel format on correct window, fixed. Regards Andrzej Andrzej Hajda (3): drm/exynos/decon5433: add dynamic zpos support drm/exynos/fimd: create local helper for disabling hardware window drm/exynos/fimd: add dynamic zpos support drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 45 ++--- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 67 --- 2 files changed, 47 insertions(+), 65 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108994] Cannot install version 18.40 due to dependency issues
https://bugs.freedesktop.org/show_bug.cgi?id=108994 --- Comment #1 from Michel Dänzer --- Please provide the actual command line you used, and its full output. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm: Split out drm_probe_helper.h
Le lun. 10 déc. 2018 à 11:24, Thierry Reding a écrit : > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > Having the probe helper stuff (which pretty much everyone needs) in > > the drm_crtc_helper.h file (which atomic drivers should never need) is > > confusing. Split them out. > > > > To make sure I actually achieved the goal here I went through all > > drivers. And indeed, all atomic drivers are now free of > > drm_crtc_helper.h includes. > > I have difficulties to apply this with git on top of drm-misc-next. It is because of that I got errors (encoder and connector types not found) while compiling adv7511_audio.c and exynos_dp.c ? Benjamin > > Signed-off-by: Daniel Vetter > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: virtualizat...@lists.linux-foundation.org > > Cc: etna...@lists.freedesktop.org > > Cc: linux-samsung-...@vger.kernel.org > > Cc: intel-...@lists.freedesktop.org > > Cc: linux-media...@lists.infradead.org > > Cc: linux-amlo...@lists.infradead.org > > Cc: linux-arm-...@vger.kernel.org > > Cc: freedr...@lists.freedesktop.org > > Cc: nouv...@lists.freedesktop.org > > Cc: spice-de...@lists.freedesktop.org > > Cc: amd-...@lists.freedesktop.org > > Cc: linux-renesas-...@vger.kernel.org > > Cc: linux-rockc...@lists.infradead.org > > Cc: linux-st...@st-md-mailman.stormreply.com > > Cc: linux-te...@vger.kernel.org > > Cc: xen-de...@lists.xen.org > > --- > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > > drivers/gpu/drm/armada/armada_510.c | 2 +- > > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > > drivers/gpu/drm/armada/armada_drv.c | 2 +- > > drivers/gpu/drm/armada/armada_fb.c| 2 +- > > drivers/gpu/drm/ast/ast_drv.c | 1 + > > drivers/gpu/drm/ast/ast_mode.c| 1 + > > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > > drivers/gpu/drm/bridge/panel.c| 2 +- > > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > > drivers/gpu/drm/bridge/tc358764.c | 2 +- > > drivers/gpu/drm/bridge/tc358767.c | 2 +- > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > > drivers/gpu/drm/drm_atomic_helper.c | 1 - > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > > drivers/gpu/drm/drm_probe_helper.c| 2 +- > > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c |
Re: TK1: DRM, Nouveau and VIC
On Mon, Dec 10, 2018 at 11:21:47AM +0100, Thierry Reding wrote:
> On Sat, Dec 08, 2018 at 02:54:45PM +, Marcel Ziswiler wrote:
> > Hi Thierry et al.
> >
> > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
> > Tegra124") graphics on Apalis TK1 is broken. During boot it fails
> > loading the vic firmware:
> >
> > [1.595824] tegra-vic 5434.vic: Direct firmware load for
> > nvidia/tegra124/vic03_ucode.bin failed with error -2
> > [1.606140] tegra-vic: probe of 5434.vic failed with error -2
> >
> > Subsequently Tegra HDMI seems to fail completely:
> >
> > [2.379860] tegra-hdmi 5428.hdmi: failed to get PLL regulator
> >
> > And finally, Nouveau even crashes:
> >
> > [8.241115] nouveau 5700.gpu: Linked as a consumer to
> > regulator.31
> > [8.247889] nouveau 5700.gpu: NVIDIA GK20A (0ea000a1)
> > [8.253396] nouveau 5700.gpu: imem: using IOMMU
> > [8.270210] Unable to handle kernel NULL pointer dereference at
> > virtual address 006c
> > [8.278340] pgd = (ptrval)
> > [8.281250] [006c] *pgd=
> > [8.284944] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> > [8.290260] Modules linked in: nouveau(+) ttm
> > [8.294625] CPU: 2 PID: 203 Comm: systemd-udevd Not tainted 4.20.0-
> > rc5-next-20181207-8-g85b0f8e25f86-dirty #110
> > [8.305055] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
> > [8.311331] PC is at drm_plane_register_all+0x18/0x50
> > [8.316373] LR is at drm_modeset_register_all+0xc/0x70
> > [8.321513] pc : []lr : []psr: a0060013
> > [8.327768] sp : ed527c70 ip : ecc43ec0 fp :
> > [8.332993] r10: 0016 r9 : ecc43e80 r8 :
> > [8.338209] r7 : bf182c80 r6 : r5 : ed61b24c r4 :
> > fffc
> > [8.344735] r3 : 0002f000 r2 : r1 : 2e124000 r0 :
> > ed61b000
> > [8.351260] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA
> > ARM Segment none
> > [8.358383] Control: 10c5387d Table: ad64c06a DAC: 0051
> > [8.364127] Process systemd-udevd (pid: 203, stack limit =
> > 0x(ptrval))
> > [8.370654] Stack: (0xed527c70 to 0xed528000)
> > [8.375004] 7c60: ed61b000
> > ed61b000 c0564cc8
> > [8.383177] 7c80: ed61b000 c054b5b8 0001
> > 0001
> > [8.391355] 7ca0: ed527cc0 c0f08c48 ed61b000
> > bf180c5c bf0dc900
> > [8.399531] 7cc0: eda29208 5dfe844b ee9f2a10
> > bf180c5c c05a9328
> > [8.407695] 7ce0: c1006828 ee9f2a10 c100682c
> > c05a744c ee9f2a10 bf180c5c
> > [8.415871] 7d00: ee9f2a44 c05a77a8 c0f08c48 bf182980
> > c05a769c eefd14d0 c05a77a8
> > [8.424048] 7d20: ee9f2a10 bf180c5c ee9f2a44 c05a77a8
> > c0f08c48 bf182980
> > [8.432226] 7d40: c05a7884 ee9ebfb4 c0f08c48 bf180c5c
> > c05a5790 ee88135c
> > [8.440405] 7d60: ee9ebfb4 5dfe844b c0f71168 bf180c5c ee379e80
> > c0f71168 c05a692c
> > [8.448570] 7d80: bf15dc00 bf180ac8 e000 bf180c5c bf180ac8
> > e000 bf1aa000 c05a84a0
> > [8.456746] 7da0: bf182b80 bf180ac8 e000 bf1aa170 c0fbd220
> > c0f08c48 e000 c0102ed0
> > [8.464924] 7dc0: ed53f4c0 006000c0 c01b3d98 000c 6113
> > bf182980 0040 c02592d0
> > [8.473102] 7de0: eda60200 2e124000 ee80 006000c0 006000c0
> > c01b3d98 000c c025a8cc
> > [8.481281] 7e00: c024ce54 a113 bf182980 5dfe844b bf182980
> > 0002 ed53f4c0 0002
> > [8.489459] 7e20: eceba000 c01b3dd4 c0f08c48 bf182980
> > ed527f40 0002 eceb9fc0
> > [8.497625] 7e40: 0002 c01b61a4 bf18298c 7fff bf182980
> > c01b2f88 c01b279c
> > [8.505800] 7e60: bf1829c8 bf182a80 bf182b6c bf182ab0 c0b03ab0
> > c0d58964 c0ca726c c0ca7278
> > [8.513978] 7e80: c0ca72d0 c0f08c48 c02654a0
> > e000 bf00
> > [8.522157] 7ea0:
> > 6e72656b 6c65
> > [8.530336] 7ec0:
> >
> > [8.538502] 7ee0:
> > 5dfe844b 7fff c0f08c48
> > [8.546677] 7f00: 000f b6f761cc c0101204 ed526000
> > 017b 004a3270 c01b66a4
> > [8.554855] 7f20: 7fff 0003 0001 004a3270
> > f0ced000 06e8994c
> > [8.563032] 7f40: f0e37f3a f0e50a40 f0ced000 06e8994c f7b75f9c
> > f7b75d34 f63e62dc 0016b000
> > [8.571209] 7f60: 0017f6f0 00050a48
> > 003b 003c 0023
> > [8.579388] 7f80: 0014 5dfe844b
> > 004c0ec0 0001
> > [8.587554] 7fa0: 017b c0101000 004c0ec0 000f
> > b6f761cc 0002
> > [8.595730] 7fc0: 004c0ec0 0001 017b 0048e114
> >
Re: [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
Patches #1 and #3 are Reviewed-by: Christian König
Patch #2 is Acked-by: Christian König because
I can't judge if adding the counter in the thread structure is actually
a good idea.
In patch #4 I honestly don't understand at all how this stuff works, so
no-comment from my side on this.
Christian.
Am 10.12.18 um 11:36 schrieb Daniel Vetter:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 mmu notifiers and
> whether we could use the newly-introduced return value to handle some
> corner cases. Until we realized that these are only for when a task
> has been killed by the oom reaper.
>
> An alternative approach would be to split the callback into two
> versions, one with the int return value, and the other with void
> return value like in older kernels. But that's a lot more churn for
> fairly little gain I think.
>
> Summary from the m-l discussion on why we want something at warning
> level: This allows automated tooling in CI to catch bugs without
> humans having to look at everything. If we just upgrade the existing
> pr_info to a pr_warn, then we'll have false positives. And as-is, no
> one will ever spot the problem since it's lost in the massive amounts
> of overall dmesg noise.
>
> v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> the problematic case (Michal Hocko).
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Christian König"
> Cc: David Rientjes
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: Paolo Bonzini
> Signed-off-by: Daniel Vetter
> ---
> mm/mmu_notifier.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 5119ff846769..ccc22f21b735 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -190,6 +190,9 @@ int __mmu_notifier_invalidate_range_start(struct
> mm_struct *mm,
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
>
> mn->ops->invalidate_range_start, _ret,
> !blockable ? "non-" : "");
> + if (blockable)
> + pr_warn("%pS callback failure not
> allowed\n",
> +
> mn->ops->invalidate_range_start);
> ret = _ret;
> }
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH i-g-t] igt: add timeline test cases
On 2018-12-07 11:01 a.m., Chunming Zhou wrote: > Signed-off-by: Chunming Zhou > --- > include/drm-uapi/drm.h | 33 ++ > lib/igt_syncobj.c| 204 +++ > lib/igt_syncobj.h| 19 + > tests/gem_ctx_bad_exec | Bin 0 -> 1284384 bytes Please run git rm tests/gem_ctx_bad_exec and re-send the patch. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC] MAINTAINERS: Daniel for drm co-maintainer
Am 10.12.18 um 11:30 schrieb Daniel Vetter: lkml and Linus gained a CoC, and it's serious this time. Which means my no 1 reason for declining to officially step up as drm maintainer is gone, and I didn't find any new good excuse. I chatted with a few people in private already, and the biggest concern is that I mislay my community hat and start running around with my intel hat only. Or some other convenient abuse of trust. That's why this patch doesn't just need a lot of acks that mean "yeah seems fine to me", but a lot of acks that mean "yeah we'll tell you when you're over the line and usurp you from that comfy chair if you don't get it". Which I think we've been done a fairly good job here at dri-devel in general, but better to be clear. Rough idea is that I'll do this for maybe 2-3 years, helping Dave figure out a group model for drm overall. And getting the tooling and infrastructure for that off the ground. Then step down again because some other shiny thing that needs chasing. Of course as plans tend to do, this one will probably pan out a bit different in reality. Cc: David Airlie Cc: Linus Torvalds Signed-off-by: Daniel Vetter Acked-by: Christian König --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7e05aa20b0ab..2c4cd038df2a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4849,6 +4849,7 @@ F:include/uapi/drm/vmwgfx_drm.h DRM DRIVERS M:David Airlie +M: Daniel Vetter L:dri-devel@lists.freedesktop.org T:git git://anongit.freedesktop.org/drm/drm B:https://bugs.freedesktop.org/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] mm, notifier: Add a lockdep map for invalidate_range_start
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But both at the
same time is really hard to reliable hit, especially when you want to
exercise paths like direct reclaim or compaction, where it's not
easy to control what exactly will be unmapped.
By introducing a lockdep map to tie them all together we allow lockdep
to see a lot more dependencies, without having to actually hit them
in a single challchain while testing.
Aside: Since I typed this to test i915 mmu notifiers I've only rolled
this out for the invaliate_range_start callback. If there's
interest, we should probably roll this out to all of them. But my
undestanding of core mm is seriously lacking, and I'm not clear on
whether we need a lockdep map for each callback, or whether some can
be shared.
v2: Use lock_map_acquire/release() like fs_reclaim, to avoid confusion
with this being a real mutex (Chris Wilson).
Cc: Chris Wilson
Cc: Andrew Morton
Cc: David Rientjes
Cc: "Jérôme Glisse"
Cc: Michal Hocko
Cc: "Christian König"
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Mike Rapoport
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter
---
include/linux/mmu_notifier.h | 6 ++
mm/mmu_notifier.c| 7 +++
2 files changed, 13 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 9893a6432adf..19be442606c6 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -12,6 +12,10 @@ struct mmu_notifier_ops;
#ifdef CONFIG_MMU_NOTIFIER
+#ifdef CONFIG_LOCKDEP
+extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
+#endif
+
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -267,8 +271,10 @@ static inline void mmu_notifier_change_pte(struct
mm_struct *mm,
static inline void mmu_notifier_invalidate_range_start(struct mm_struct *mm,
unsigned long start, unsigned long end)
{
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(mm))
__mmu_notifier_invalidate_range_start(mm, start, end, true);
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
}
static inline int mmu_notifier_invalidate_range_start_nonblock(struct
mm_struct *mm,
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index a50ed7d1ecef..c91d58fe388b 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -23,6 +23,13 @@
/* global SRCU for all MMs */
DEFINE_STATIC_SRCU(srcu);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map __mmu_notifier_invalidate_range_start_map = {
+ .name = "mmu_notifier_invalidate_range_start"
+};
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map);
+#endif
+
/*
* This function allows mmu_notifier::release callback to delay a call to
* a function that will free appropriate resources. The function must be
--
2.20.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return value to handle some
corner cases. Until we realized that these are only for when a task
has been killed by the oom reaper.
An alternative approach would be to split the callback into two
versions, one with the int return value, and the other with void
return value like in older kernels. But that's a lot more churn for
fairly little gain I think.
Summary from the m-l discussion on why we want something at warning
level: This allows automated tooling in CI to catch bugs without
humans having to look at everything. If we just upgrade the existing
pr_info to a pr_warn, then we'll have false positives. And as-is, no
one will ever spot the problem since it's lost in the massive amounts
of overall dmesg noise.
v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
the problematic case (Michal Hocko).
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Christian König"
Cc: David Rientjes
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Paolo Bonzini
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 5119ff846769..ccc22f21b735 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -190,6 +190,9 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct
*mm,
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
!blockable ? "non-" : "");
+ if (blockable)
+ pr_warn("%pS callback failure not
allowed\n",
+
mn->ops->invalidate_range_start);
ret = _ret;
}
}
--
2.20.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
