[radeon-alex:drm-next-4.19 82/100] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:501:9: warning: missing braces around initializer
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.19
head: a21daa88d4f08c959a36ad9760df045407a080e5
commit: 6e0ef9d85b99baeeea4b9c4a9777809cb0c6040a [82/100] drm/amd/display:
Write TEST_EDID_CHECKSUM_WRITE for EDID tests
config: x86_64-randconfig-g0-06231137 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 6e0ef9d85b99baeeea4b9c4a9777809cb0c6040a
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c: In
function 'dm_helpers_read_local_edid':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:501:9:
>> warning: missing braces around initializer [-Wmissing-braces]
union test_request test_request = {0};
^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:501:9:
warning: (near initialization for 'test_request.bits') [-Wmissing-braces]
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:502:9:
warning: missing braces around initializer [-Wmissing-braces]
union test_response test_response = {0};
^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:502:9:
warning: (near initialization for 'test_response.bits') [-Wmissing-braces]
vim +501 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c
456
457 enum dc_edid_status dm_helpers_read_local_edid(
458 struct dc_context *ctx,
459 struct dc_link *link,
460 struct dc_sink *sink)
461 {
462 struct amdgpu_dm_connector *aconnector = link->priv;
463 struct i2c_adapter *ddc;
464 int retry = 3;
465 enum dc_edid_status edid_status;
466 struct edid *edid;
467
468 if (link->aux_mode)
469 ddc = >dm_dp_aux.aux.ddc;
470 else
471 ddc = >i2c->base;
472
473 /* some dongles read edid incorrectly the first time,
474 * do check sum and retry to make sure read correct edid.
475 */
476 do {
477
478 edid = drm_get_edid(>base, ddc);
479
480 if (!edid)
481 return EDID_NO_RESPONSE;
482
483 sink->dc_edid.length = EDID_LENGTH * (edid->extensions
+ 1);
484 memmove(sink->dc_edid.raw_edid, (uint8_t *)edid,
sink->dc_edid.length);
485
486 /* We don't need the original edid anymore */
487 kfree(edid);
488
489 edid_status = dm_helpers_parse_edid_caps(
490 ctx,
491 >dc_edid,
492 >edid_caps);
493
494 } while (edid_status == EDID_BAD_CHECKSUM && --retry > 0);
495
496 if (edid_status != EDID_OK)
497 DRM_ERROR("EDID err: %d, on connector: %s",
498 edid_status,
499 aconnector->base.name);
500 if (link->aux_mode) {
> 501 union test_request test_request = {0};
502 union test_response test_response = {0};
503
504 dm_helpers_dp_read_dpcd(ctx,
505 link,
506 DP_TEST_REQUEST,
507 _request.raw,
508 sizeof(union test_request));
509
510 if (!test_request.bits.EDID_READ)
511 return edid_status;
512
513 test_response.bits.EDID_CHECKSUM_WRITE = 1;
514
515 dm_helpers_dp_write_dpcd(ctx,
516 link,
517 DP_TEST_EDID_CHECKSUM,
518
>dc_edid.raw_edid[sink->dc_edid.length-1],
519 1);
520
521 dm_helpers_dp_write_dpcd(ctx,
522 link,
523 DP_TEST_RESPONSE,
524 _response.raw,
525 sizeof(test_response));
526
527 }
528
529 return edid_status;
530 }
531
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing
Re: [PATCH] drm/amdgpu: Count disabled CRTCs in commit tail earlier
On 06/22/2018 09:03 PM, Andrey Grodzovsky wrote: On 06/22/2018 02:56 PM, Lyude Paul wrote: On Fri, 2018-06-22 at 13:34 -0400, Andrey Grodzovsky wrote: On 06/21/2018 04:48 PM, Lyude Paul wrote: This fixes a regression I accidentally reduced that was picked up by kasan, where we were checking the CRTC atomic states after DRM's helpers had already freed them. Example: == BUG: KASAN: use-after-free in amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] Read of size 1 at addr 8803a697b071 by task kworker/u16:0/7 CPU: 7 PID: 7 Comm: kworker/u16:0 Tainted: G O 4.18.0- rc1Lyude-Upstream+ #1 Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.21 05/02/2018 Workqueue: events_unbound commit_work [drm_kms_helper] Call Trace: dump_stack+0xc1/0x169 ? dump_stack_print_info.cold.1+0x42/0x42 ? kmsg_dump_rewind_nolock+0xd9/0xd9 ? printk+0x9f/0xc5 ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] print_address_description+0x6c/0x23c ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] kasan_report.cold.6+0x241/0x2fd amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] ? commit_planes_to_stream.constprop.45+0x13b0/0x13b0 [amdgpu] ? cpu_load_update_active+0x290/0x290 ? finish_task_switch+0x2bd/0x840 ? __switch_to_asm+0x34/0x70 ? read_word_at_a_time+0xe/0x20 ? strscpy+0x14b/0x460 ? drm_atomic_helper_wait_for_dependencies+0x47d/0x7e0 [drm_kms_helper] commit_tail+0x96/0xe0 [drm_kms_helper] process_one_work+0x88a/0x1360 ? create_worker+0x540/0x540 ? __sched_text_start+0x8/0x8 ? move_queued_task+0x760/0x760 ? call_rcu_sched+0x20/0x20 ? vsnprintf+0xcda/0x1350 ? wait_woken+0x1c0/0x1c0 ? mutex_unlock+0x1d/0x40 ? init_timer_key+0x190/0x230 ? schedule+0xea/0x390 ? __schedule+0x1ea0/0x1ea0 ? need_to_create_worker+0xe4/0x210 ? init_worker_pool+0x700/0x700 ? try_to_del_timer_sync+0xbf/0x110 ? del_timer+0x120/0x120 ? __mutex_lock_slowpath+0x10/0x10 worker_thread+0x196/0x11f0 ? flush_rcu_work+0x50/0x50 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __schedule+0x7d6/0x1ea0 ? migrate_swap_stop+0x850/0x880 ? __sched_text_start+0x8/0x8 ? save_stack+0x8c/0xb0 ? kasan_kmalloc+0xbf/0xe0 ? kmem_cache_alloc_trace+0xe4/0x190 ? kthread+0x98/0x390 ? ret_from_fork+0x35/0x40 ? ret_from_fork+0x35/0x40 ? deactivate_slab.isra.67+0x3c4/0x5c0 ? kthread+0x98/0x390 ? kthread+0x98/0x390 ? set_track+0x76/0x120 ? schedule+0xea/0x390 ? __schedule+0x1ea0/0x1ea0 ? wait_woken+0x1c0/0x1c0 ? kasan_unpoison_shadow+0x30/0x40 ? parse_args.cold.15+0x17a/0x17a ? flush_rcu_work+0x50/0x50 kthread+0x2d4/0x390 ? kthread_create_worker_on_cpu+0xc0/0xc0 ret_from_fork+0x35/0x40 Allocated by task 1124: kasan_kmalloc+0xbf/0xe0 kmem_cache_alloc_trace+0xe4/0x190 dm_crtc_duplicate_state+0x78/0x130 [amdgpu] drm_atomic_get_crtc_state+0x147/0x410 [drm] page_flip_common+0x57/0x230 [drm_kms_helper] drm_atomic_helper_page_flip+0xa6/0x110 [drm_kms_helper] drm_mode_page_flip_ioctl+0xc4b/0x10a0 [drm] drm_ioctl_kernel+0x1d4/0x260 [drm] drm_ioctl+0x433/0x920 [drm] amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] do_vfs_ioctl+0x1a1/0x13d0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x147/0x440 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 1124: __kasan_slab_free+0x12e/0x180 kfree+0x92/0x1a0 drm_atomic_state_default_clear+0x315/0xc40 [drm] __drm_atomic_state_free+0x35/0xd0 [drm] drm_atomic_helper_update_plane+0xac/0x350 [drm_kms_helper] __setplane_internal+0x2d6/0x840 [drm] drm_mode_cursor_universal+0x41e/0xbe0 [drm] drm_mode_cursor_common+0x49f/0x880 [drm] drm_mode_cursor_ioctl+0xd8/0x130 [drm] drm_ioctl_kernel+0x1d4/0x260 [drm] drm_ioctl+0x433/0x920 [drm] amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] do_vfs_ioctl+0x1a1/0x13d0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x147/0x440 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at 8803a697b068 which belongs to the cache kmalloc-1024 of size 1024 The buggy address is located 9 bytes inside of 1024-byte region [8803a697b068, 8803a697b468) The buggy address belongs to the page: page:ea000e9a5e00 count:1 mapcount:0 mapping:88041e00efc0 index:0x0 compound_mapcount: 0 flags: 0x80008100(slab|head) raw: 80008100 ea000ecbc208 88041e000c70 88041e00efc0 raw: 00170017 0001 page dumped because: kasan: bad access detected Memory state around the buggy address: 8803a697af00: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[Bug 106490] VA-API video deconding broken for Chromium on Mesa 18.0.3
https://bugs.freedesktop.org/show_bug.cgi?id=106490 --- Comment #5 from MWATTT --- I have this problem too. A workaround is to set the driconf option "allow_rgb10_configs" to false for chromium-browser. This problem affects radeonsi and r600g, but not i965. -- 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/amdgpu: Count disabled CRTCs in commit tail earlier
On 06/22/2018 02:56 PM, Lyude Paul wrote: On Fri, 2018-06-22 at 13:34 -0400, Andrey Grodzovsky wrote: On 06/21/2018 04:48 PM, Lyude Paul wrote: This fixes a regression I accidentally reduced that was picked up by kasan, where we were checking the CRTC atomic states after DRM's helpers had already freed them. Example: == BUG: KASAN: use-after-free in amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] Read of size 1 at addr 8803a697b071 by task kworker/u16:0/7 CPU: 7 PID: 7 Comm: kworker/u16:0 Tainted: G O 4.18.0- rc1Lyude-Upstream+ #1 Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.21 05/02/2018 Workqueue: events_unbound commit_work [drm_kms_helper] Call Trace: dump_stack+0xc1/0x169 ? dump_stack_print_info.cold.1+0x42/0x42 ? kmsg_dump_rewind_nolock+0xd9/0xd9 ? printk+0x9f/0xc5 ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] print_address_description+0x6c/0x23c ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] kasan_report.cold.6+0x241/0x2fd amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] ? commit_planes_to_stream.constprop.45+0x13b0/0x13b0 [amdgpu] ? cpu_load_update_active+0x290/0x290 ? finish_task_switch+0x2bd/0x840 ? __switch_to_asm+0x34/0x70 ? read_word_at_a_time+0xe/0x20 ? strscpy+0x14b/0x460 ? drm_atomic_helper_wait_for_dependencies+0x47d/0x7e0 [drm_kms_helper] commit_tail+0x96/0xe0 [drm_kms_helper] process_one_work+0x88a/0x1360 ? create_worker+0x540/0x540 ? __sched_text_start+0x8/0x8 ? move_queued_task+0x760/0x760 ? call_rcu_sched+0x20/0x20 ? vsnprintf+0xcda/0x1350 ? wait_woken+0x1c0/0x1c0 ? mutex_unlock+0x1d/0x40 ? init_timer_key+0x190/0x230 ? schedule+0xea/0x390 ? __schedule+0x1ea0/0x1ea0 ? need_to_create_worker+0xe4/0x210 ? init_worker_pool+0x700/0x700 ? try_to_del_timer_sync+0xbf/0x110 ? del_timer+0x120/0x120 ? __mutex_lock_slowpath+0x10/0x10 worker_thread+0x196/0x11f0 ? flush_rcu_work+0x50/0x50 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __schedule+0x7d6/0x1ea0 ? migrate_swap_stop+0x850/0x880 ? __sched_text_start+0x8/0x8 ? save_stack+0x8c/0xb0 ? kasan_kmalloc+0xbf/0xe0 ? kmem_cache_alloc_trace+0xe4/0x190 ? kthread+0x98/0x390 ? ret_from_fork+0x35/0x40 ? ret_from_fork+0x35/0x40 ? deactivate_slab.isra.67+0x3c4/0x5c0 ? kthread+0x98/0x390 ? kthread+0x98/0x390 ? set_track+0x76/0x120 ? schedule+0xea/0x390 ? __schedule+0x1ea0/0x1ea0 ? wait_woken+0x1c0/0x1c0 ? kasan_unpoison_shadow+0x30/0x40 ? parse_args.cold.15+0x17a/0x17a ? flush_rcu_work+0x50/0x50 kthread+0x2d4/0x390 ? kthread_create_worker_on_cpu+0xc0/0xc0 ret_from_fork+0x35/0x40 Allocated by task 1124: kasan_kmalloc+0xbf/0xe0 kmem_cache_alloc_trace+0xe4/0x190 dm_crtc_duplicate_state+0x78/0x130 [amdgpu] drm_atomic_get_crtc_state+0x147/0x410 [drm] page_flip_common+0x57/0x230 [drm_kms_helper] drm_atomic_helper_page_flip+0xa6/0x110 [drm_kms_helper] drm_mode_page_flip_ioctl+0xc4b/0x10a0 [drm] drm_ioctl_kernel+0x1d4/0x260 [drm] drm_ioctl+0x433/0x920 [drm] amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] do_vfs_ioctl+0x1a1/0x13d0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x147/0x440 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 1124: __kasan_slab_free+0x12e/0x180 kfree+0x92/0x1a0 drm_atomic_state_default_clear+0x315/0xc40 [drm] __drm_atomic_state_free+0x35/0xd0 [drm] drm_atomic_helper_update_plane+0xac/0x350 [drm_kms_helper] __setplane_internal+0x2d6/0x840 [drm] drm_mode_cursor_universal+0x41e/0xbe0 [drm] drm_mode_cursor_common+0x49f/0x880 [drm] drm_mode_cursor_ioctl+0xd8/0x130 [drm] drm_ioctl_kernel+0x1d4/0x260 [drm] drm_ioctl+0x433/0x920 [drm] amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] do_vfs_ioctl+0x1a1/0x13d0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x147/0x440 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at 8803a697b068 which belongs to the cache kmalloc-1024 of size 1024 The buggy address is located 9 bytes inside of 1024-byte region [8803a697b068, 8803a697b468) The buggy address belongs to the page: page:ea000e9a5e00 count:1 mapcount:0 mapping:88041e00efc0 index:0x0 compound_mapcount: 0 flags: 0x80008100(slab|head) raw: 80008100 ea000ecbc208 88041e000c70 88041e00efc0 raw: 00170017 0001 page dumped because: kasan: bad access detected Memory state around the buggy address: 8803a697af00: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 8803a697af80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Re: [Nouveau] [PATCH] drm/nouveau/secboot/acr: Remove VLA usage
On Fri, Jun 22, 2018 at 11:34 PM, Kees Cook wrote:
> On Fri, Jun 22, 2018 at 10:50 AM, Karol Herbst wrote:
>> On Thu, May 24, 2018 at 7:24 PM, Kees Cook wrote:
>>> In the quest to remove all stack VLA usage from the kernel[1], this
>>> allocates the working buffers before starting the writing so it won't
>>> abort in the middle. This needs an initial walk of the lists to figure
>>> out how large the buffer should be.
>>>
>>> [1]
>>> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>>>
>>> Signed-off-by: Kees Cook
>>> ---
>>> .../nouveau/nvkm/subdev/secboot/acr_r352.c| 25 ---
>>> .../nouveau/nvkm/subdev/secboot/acr_r367.c| 16 +++-
>>> 2 files changed, 37 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>>> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>>> index a721354249ce..d02e183717dc 100644
>>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>>> @@ -414,6 +414,20 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
>>> list_head *imgs,
>>> {
>>> struct ls_ucode_img *_img;
>>> u32 pos = 0;
>>> + u32 max_desc_size = 0;
>>> + u8 *gdesc;
>>> +
>>> + /* Figure out how large we need gdesc to be. */
>>> + list_for_each_entry(_img, imgs, node) {
>>> + const struct acr_r352_ls_func *ls_func =
>>> +
>>> acr->func->ls_func[_img->falcon_id];
>>> +
>>> + max_desc_size = max(max_desc_size, ls_func->bl_desc_size);
>>> + }
>>> +
>>> + gdesc = kmalloc(max_desc_size, GFP_KERNEL);
>>> + if (!gdesc)
>>> + return -ENOMEM;
>>>
>>> nvkm_kmap(wpr_blob);
>>>
>>> @@ -421,7 +435,6 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
>>> list_head *imgs,
>>> struct ls_ucode_img_r352 *img = ls_ucode_img_r352(_img);
>>> const struct acr_r352_ls_func *ls_func =
>>>
>>> acr->func->ls_func[_img->falcon_id];
>>> - u8 gdesc[ls_func->bl_desc_size];
>>>
>>
>> if there are no guarantees that (ls_func->bl_desc_size & 0x4 == 0),
>> then we need to memset a bit more, because 4 bytes at the time are
>> actually copied inside nvkm_gpuobj_memcpy_to later in that code, but
>> the last 4 bytes are only partly memset to 0.
>
> I think this is unchanged from the original code, yes? The memset() is
> always against bl_desc_size; I haven't changed that.
>
right, but I think before we would upload undefined data (because we
run out of bounds for cerain bl_desc_size), now we get what ever was
left inside the buffer from the previous iteration. Both cases are not
good. It isn't an issue with your patch, the code before wasn't 100%
correct either. But maybe that's fine, because bl_desc_size is always
a multple of 0x4.
>> If ls_func->bl_desc_size is always a multiple of 0x4, then it isn't as
>> important, but still better to be fixed. Or maybe
>> nvkm_gpuobj_memcpy_to should do that handling and check if the size is
>> a multiple of 0x4 and otherwise handle that case?
>>
>> Same is valid for the changes in the r367 file.
>
> Should I resend with both the allocation and the memset getting
> rounded up to the next multiple of 4?
Yeah, I think copying 0 is better than random data.
Your patch is fine as it is though, because it doesn't add a new
issue, it just showed us there is a potential one. We should keep that
in mind and see how we want to fix that up. I can imagine that this
might cause some issues in some places, maybe it is totally fine.
Thanks
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-4.18
Hi Dave, A fix for a potential use after free introduced in a previous stable fix for runtime pm. The following changes since commit f3294568bbb19cbfc53451de192df6daae80f9b3: Merge tag 'drm-misc-fixes-2018-06-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-06-22 11:03:43 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.18 for you to fetch changes up to fe2a19652918a5247418aed48a247414a5e45fe2: drm/amdgpu: Count disabled CRTCs in commit tail earlier (2018-06-22 14:55:25 -0500) Lyude Paul (1): drm/amdgpu: Count disabled CRTCs in commit tail earlier drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On 2018-06-22 11:24 AM, Michal Hocko wrote:
> On Fri 22-06-18 17:13:02, Christian König wrote:
>> Hi Michal,
>>
>> [Adding Felix as well]
>>
>> Well first of all you have a misconception why at least the AMD graphics
>> driver need to be able to sleep in an MMU notifier: We need to sleep because
>> we need to wait for hardware operations to finish and *NOT* because we need
>> to wait for locks.
>>
>> I'm not sure if your flag now means that you generally can't sleep in MMU
>> notifiers any more, but if that's the case at least AMD hardware will break
>> badly. In our case the approach of waiting for a short time for the process
>> to be reaped and then select another victim actually sounds like the right
>> thing to do.
> Well, I do not need to make the notifier code non blocking all the time.
> All I need is to ensure that it won't sleep if the flag says so and
> return -EAGAIN instead.
>
> So here is what I do for amdgpu:
In the case of KFD we also need to take the DQM lock:
amdgpu_mn_invalidate_range_start_hsa -> amdgpu_amdkfd_evict_userptr ->
kgd2kfd_quiesce_mm -> kfd_process_evict_queues -> evict_process_queues_cpsch
So we'd need to pass the blockable parameter all the way through that
call chain.
Regards,
Felix
>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
>>> index 83e344fbb50a..d138a526feff 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
>>> @@ -136,12 +136,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
>>>*
>>>* Take the rmn read side lock.
>>>*/
>>> -static void amdgpu_mn_read_lock(struct amdgpu_mn *rmn)
>>> +static int amdgpu_mn_read_lock(struct amdgpu_mn *rmn, bool blockable)
>>> {
>>> - mutex_lock(>read_lock);
>>> + if (blockable)
>>> + mutex_lock(>read_lock);
>>> + else if (!mutex_trylock(>read_lock))
>>> + return -EAGAIN;
>>> +
>>> if (atomic_inc_return(>recursion) == 1)
>>> down_read_non_owner(>lock);
>>> mutex_unlock(>read_lock);
>>> +
>>> + return 0;
>>> }
>>> /**
>>> @@ -197,10 +203,11 @@ static void amdgpu_mn_invalidate_node(struct
>>> amdgpu_mn_node *node,
>>>* We block for all BOs between start and end to be idle and
>>>* unmap them by move them into system domain again.
>>>*/
>>> -static void amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
>>> +static int amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
>>> struct mm_struct *mm,
>>> unsigned long start,
>>> -unsigned long end)
>>> +unsigned long end,
>>> +bool blockable)
>>> {
>>> struct amdgpu_mn *rmn = container_of(mn, struct amdgpu_mn, mn);
>>> struct interval_tree_node *it;
>>> @@ -208,7 +215,11 @@ static void
>>> amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
>>> /* notification is exclusive, but interval is inclusive */
>>> end -= 1;
>>> - amdgpu_mn_read_lock(rmn);
>>> + /* TODO we should be able to split locking for interval tree and
>>> +* amdgpu_mn_invalidate_node
>>> +*/
>>> + if (amdgpu_mn_read_lock(rmn, blockable))
>>> + return -EAGAIN;
>>> it = interval_tree_iter_first(>objects, start, end);
>>> while (it) {
>>> @@ -219,6 +230,8 @@ static void amdgpu_mn_invalidate_range_start_gfx(struct
>>> mmu_notifier *mn,
>>> amdgpu_mn_invalidate_node(node, start, end);
>>> }
>>> +
>>> + return 0;
>>> }
>>> /**
>>> @@ -233,10 +246,11 @@ static void
>>> amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
>>>* necessitates evicting all user-mode queues of the process. The BOs
>>>* are restorted in amdgpu_mn_invalidate_range_end_hsa.
>>>*/
>>> -static void amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
>>> +static int amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
>>> struct mm_struct *mm,
>>> unsigned long start,
>>> -unsigned long end)
>>> +unsigned long end,
>>> +bool blockable)
>>> {
>>> struct amdgpu_mn *rmn = container_of(mn, struct amdgpu_mn, mn);
>>> struct interval_tree_node *it;
>>> @@ -244,7 +258,8 @@ static void amdgpu_mn_invalidate_range_start_hsa(struct
>>> mmu_notifier *mn,
>>> /* notification is exclusive, but interval is inclusive */
>>> end -= 1;
>>> - amdgpu_mn_read_lock(rmn);
>>> + if (amdgpu_mn_read_lock(rmn, blockable))
>>> + return -EAGAIN;
>>> it = interval_tree_iter_first(>objects, start, end);
>>> while (it) {
>>> @@ -262,6 +277,8 @@ static void
Re: [PATCH] drm/amdgpu: Count disabled CRTCs in commit tail earlier
On Fri, 2018-06-22 at 13:34 -0400, Andrey Grodzovsky wrote: > > On 06/21/2018 04:48 PM, Lyude Paul wrote: > > This fixes a regression I accidentally reduced that was picked up by > > kasan, where we were checking the CRTC atomic states after DRM's helpers > > had already freed them. Example: > > > > == > > BUG: KASAN: use-after-free in > > amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] > > Read of size 1 at addr 8803a697b071 by task kworker/u16:0/7 > > > > CPU: 7 PID: 7 Comm: kworker/u16:0 Tainted: G O 4.18.0- > > rc1Lyude-Upstream+ #1 > > Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.21 05/02/2018 > > Workqueue: events_unbound commit_work [drm_kms_helper] > > Call Trace: > > dump_stack+0xc1/0x169 > > ? dump_stack_print_info.cold.1+0x42/0x42 > > ? kmsg_dump_rewind_nolock+0xd9/0xd9 > > ? printk+0x9f/0xc5 > > ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] > > print_address_description+0x6c/0x23c > > ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] > > kasan_report.cold.6+0x241/0x2fd > > amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] > > ? commit_planes_to_stream.constprop.45+0x13b0/0x13b0 [amdgpu] > > ? cpu_load_update_active+0x290/0x290 > > ? finish_task_switch+0x2bd/0x840 > > ? __switch_to_asm+0x34/0x70 > > ? read_word_at_a_time+0xe/0x20 > > ? strscpy+0x14b/0x460 > > ? drm_atomic_helper_wait_for_dependencies+0x47d/0x7e0 [drm_kms_helper] > > commit_tail+0x96/0xe0 [drm_kms_helper] > > process_one_work+0x88a/0x1360 > > ? create_worker+0x540/0x540 > > ? __sched_text_start+0x8/0x8 > > ? move_queued_task+0x760/0x760 > > ? call_rcu_sched+0x20/0x20 > > ? vsnprintf+0xcda/0x1350 > > ? wait_woken+0x1c0/0x1c0 > > ? mutex_unlock+0x1d/0x40 > > ? init_timer_key+0x190/0x230 > > ? schedule+0xea/0x390 > > ? __schedule+0x1ea0/0x1ea0 > > ? need_to_create_worker+0xe4/0x210 > > ? init_worker_pool+0x700/0x700 > > ? try_to_del_timer_sync+0xbf/0x110 > > ? del_timer+0x120/0x120 > > ? __mutex_lock_slowpath+0x10/0x10 > > worker_thread+0x196/0x11f0 > > ? flush_rcu_work+0x50/0x50 > > ? __switch_to_asm+0x34/0x70 > > ? __switch_to_asm+0x34/0x70 > > ? __switch_to_asm+0x40/0x70 > > ? __switch_to_asm+0x34/0x70 > > ? __switch_to_asm+0x40/0x70 > > ? __switch_to_asm+0x34/0x70 > > ? __switch_to_asm+0x40/0x70 > > ? __schedule+0x7d6/0x1ea0 > > ? migrate_swap_stop+0x850/0x880 > > ? __sched_text_start+0x8/0x8 > > ? save_stack+0x8c/0xb0 > > ? kasan_kmalloc+0xbf/0xe0 > > ? kmem_cache_alloc_trace+0xe4/0x190 > > ? kthread+0x98/0x390 > > ? ret_from_fork+0x35/0x40 > > ? ret_from_fork+0x35/0x40 > > ? deactivate_slab.isra.67+0x3c4/0x5c0 > > ? kthread+0x98/0x390 > > ? kthread+0x98/0x390 > > ? set_track+0x76/0x120 > > ? schedule+0xea/0x390 > > ? __schedule+0x1ea0/0x1ea0 > > ? wait_woken+0x1c0/0x1c0 > > ? kasan_unpoison_shadow+0x30/0x40 > > ? parse_args.cold.15+0x17a/0x17a > > ? flush_rcu_work+0x50/0x50 > > kthread+0x2d4/0x390 > > ? kthread_create_worker_on_cpu+0xc0/0xc0 > > ret_from_fork+0x35/0x40 > > > > Allocated by task 1124: > > kasan_kmalloc+0xbf/0xe0 > > kmem_cache_alloc_trace+0xe4/0x190 > > dm_crtc_duplicate_state+0x78/0x130 [amdgpu] > > drm_atomic_get_crtc_state+0x147/0x410 [drm] > > page_flip_common+0x57/0x230 [drm_kms_helper] > > drm_atomic_helper_page_flip+0xa6/0x110 [drm_kms_helper] > > drm_mode_page_flip_ioctl+0xc4b/0x10a0 [drm] > > drm_ioctl_kernel+0x1d4/0x260 [drm] > > drm_ioctl+0x433/0x920 [drm] > > amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] > > do_vfs_ioctl+0x1a1/0x13d0 > > ksys_ioctl+0x60/0x90 > > __x64_sys_ioctl+0x6f/0xb0 > > do_syscall_64+0x147/0x440 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > Freed by task 1124: > > __kasan_slab_free+0x12e/0x180 > > kfree+0x92/0x1a0 > > drm_atomic_state_default_clear+0x315/0xc40 [drm] > > __drm_atomic_state_free+0x35/0xd0 [drm] > > drm_atomic_helper_update_plane+0xac/0x350 [drm_kms_helper] > > __setplane_internal+0x2d6/0x840 [drm] > > drm_mode_cursor_universal+0x41e/0xbe0 [drm] > > drm_mode_cursor_common+0x49f/0x880 [drm] > > drm_mode_cursor_ioctl+0xd8/0x130 [drm] > > drm_ioctl_kernel+0x1d4/0x260 [drm] > > drm_ioctl+0x433/0x920 [drm] > > amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] > > do_vfs_ioctl+0x1a1/0x13d0 > > ksys_ioctl+0x60/0x90 > > __x64_sys_ioctl+0x6f/0xb0 > > do_syscall_64+0x147/0x440 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > The buggy address belongs to the object at 8803a697b068 > > which belongs to the cache kmalloc-1024 of size 1024 > > The buggy address is located 9 bytes inside of > > 1024-byte region [8803a697b068, 8803a697b468) > > The buggy address belongs to the page: > > page:ea000e9a5e00 count:1 mapcount:0 mapping:88041e00efc0 index:0x0 > > compound_mapcount: 0 > > flags: 0x80008100(slab|head) > > raw:
Re: [PATCH] drm/amdgpu: Count disabled CRTCs in commit tail earlier
On 2018-06-21 04:48 PM, Lyude Paul wrote: > This fixes a regression I accidentally reduced that was picked up by > kasan, where we were checking the CRTC atomic states after DRM's helpers > had already freed them. Example: > > == > BUG: KASAN: use-after-free in > amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] > Read of size 1 at addr 8803a697b071 by task kworker/u16:0/7 > > CPU: 7 PID: 7 Comm: kworker/u16:0 Tainted: G O > 4.18.0-rc1Lyude-Upstream+ #1 > Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.21 05/02/2018 > Workqueue: events_unbound commit_work [drm_kms_helper] > Call Trace: > dump_stack+0xc1/0x169 > ? dump_stack_print_info.cold.1+0x42/0x42 > ? kmsg_dump_rewind_nolock+0xd9/0xd9 > ? printk+0x9f/0xc5 > ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] > print_address_description+0x6c/0x23c > ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] > kasan_report.cold.6+0x241/0x2fd > amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] > ? commit_planes_to_stream.constprop.45+0x13b0/0x13b0 [amdgpu] > ? cpu_load_update_active+0x290/0x290 > ? finish_task_switch+0x2bd/0x840 > ? __switch_to_asm+0x34/0x70 > ? read_word_at_a_time+0xe/0x20 > ? strscpy+0x14b/0x460 > ? drm_atomic_helper_wait_for_dependencies+0x47d/0x7e0 [drm_kms_helper] > commit_tail+0x96/0xe0 [drm_kms_helper] > process_one_work+0x88a/0x1360 > ? create_worker+0x540/0x540 > ? __sched_text_start+0x8/0x8 > ? move_queued_task+0x760/0x760 > ? call_rcu_sched+0x20/0x20 > ? vsnprintf+0xcda/0x1350 > ? wait_woken+0x1c0/0x1c0 > ? mutex_unlock+0x1d/0x40 > ? init_timer_key+0x190/0x230 > ? schedule+0xea/0x390 > ? __schedule+0x1ea0/0x1ea0 > ? need_to_create_worker+0xe4/0x210 > ? init_worker_pool+0x700/0x700 > ? try_to_del_timer_sync+0xbf/0x110 > ? del_timer+0x120/0x120 > ? __mutex_lock_slowpath+0x10/0x10 > worker_thread+0x196/0x11f0 > ? flush_rcu_work+0x50/0x50 > ? __switch_to_asm+0x34/0x70 > ? __switch_to_asm+0x34/0x70 > ? __switch_to_asm+0x40/0x70 > ? __switch_to_asm+0x34/0x70 > ? __switch_to_asm+0x40/0x70 > ? __switch_to_asm+0x34/0x70 > ? __switch_to_asm+0x40/0x70 > ? __schedule+0x7d6/0x1ea0 > ? migrate_swap_stop+0x850/0x880 > ? __sched_text_start+0x8/0x8 > ? save_stack+0x8c/0xb0 > ? kasan_kmalloc+0xbf/0xe0 > ? kmem_cache_alloc_trace+0xe4/0x190 > ? kthread+0x98/0x390 > ? ret_from_fork+0x35/0x40 > ? ret_from_fork+0x35/0x40 > ? deactivate_slab.isra.67+0x3c4/0x5c0 > ? kthread+0x98/0x390 > ? kthread+0x98/0x390 > ? set_track+0x76/0x120 > ? schedule+0xea/0x390 > ? __schedule+0x1ea0/0x1ea0 > ? wait_woken+0x1c0/0x1c0 > ? kasan_unpoison_shadow+0x30/0x40 > ? parse_args.cold.15+0x17a/0x17a > ? flush_rcu_work+0x50/0x50 > kthread+0x2d4/0x390 > ? kthread_create_worker_on_cpu+0xc0/0xc0 > ret_from_fork+0x35/0x40 > > Allocated by task 1124: > kasan_kmalloc+0xbf/0xe0 > kmem_cache_alloc_trace+0xe4/0x190 > dm_crtc_duplicate_state+0x78/0x130 [amdgpu] > drm_atomic_get_crtc_state+0x147/0x410 [drm] > page_flip_common+0x57/0x230 [drm_kms_helper] > drm_atomic_helper_page_flip+0xa6/0x110 [drm_kms_helper] > drm_mode_page_flip_ioctl+0xc4b/0x10a0 [drm] > drm_ioctl_kernel+0x1d4/0x260 [drm] > drm_ioctl+0x433/0x920 [drm] > amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] > do_vfs_ioctl+0x1a1/0x13d0 > ksys_ioctl+0x60/0x90 > __x64_sys_ioctl+0x6f/0xb0 > do_syscall_64+0x147/0x440 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Freed by task 1124: > __kasan_slab_free+0x12e/0x180 > kfree+0x92/0x1a0 > drm_atomic_state_default_clear+0x315/0xc40 [drm] > __drm_atomic_state_free+0x35/0xd0 [drm] > drm_atomic_helper_update_plane+0xac/0x350 [drm_kms_helper] > __setplane_internal+0x2d6/0x840 [drm] > drm_mode_cursor_universal+0x41e/0xbe0 [drm] > drm_mode_cursor_common+0x49f/0x880 [drm] > drm_mode_cursor_ioctl+0xd8/0x130 [drm] > drm_ioctl_kernel+0x1d4/0x260 [drm] > drm_ioctl+0x433/0x920 [drm] > amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] > do_vfs_ioctl+0x1a1/0x13d0 > ksys_ioctl+0x60/0x90 > __x64_sys_ioctl+0x6f/0xb0 > do_syscall_64+0x147/0x440 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > The buggy address belongs to the object at 8803a697b068 > which belongs to the cache kmalloc-1024 of size 1024 > The buggy address is located 9 bytes inside of > 1024-byte region [8803a697b068, 8803a697b468) > The buggy address belongs to the page: > page:ea000e9a5e00 count:1 mapcount:0 mapping:88041e00efc0 index:0x0 > compound_mapcount: 0 > flags: 0x80008100(slab|head) > raw: 80008100 ea000ecbc208 88041e000c70 88041e00efc0 > raw: 00170017 0001 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8803a697af00: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > 8803a697af80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> 8803a697b000: fc fc fc fc fc fc fc
Re: [Nouveau] [PATCH] drm/nouveau/secboot/acr: Remove VLA usage
On Thu, May 24, 2018 at 7:24 PM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the working buffers before starting the writing so it won't
> abort in the middle. This needs an initial walk of the lists to figure
> out how large the buffer should be.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Kees Cook
> ---
> .../nouveau/nvkm/subdev/secboot/acr_r352.c| 25 ---
> .../nouveau/nvkm/subdev/secboot/acr_r367.c| 16 +++-
> 2 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
> index a721354249ce..d02e183717dc 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
> @@ -414,6 +414,20 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
> list_head *imgs,
> {
> struct ls_ucode_img *_img;
> u32 pos = 0;
> + u32 max_desc_size = 0;
> + u8 *gdesc;
> +
> + /* Figure out how large we need gdesc to be. */
> + list_for_each_entry(_img, imgs, node) {
> + const struct acr_r352_ls_func *ls_func =
> +
> acr->func->ls_func[_img->falcon_id];
> +
> + max_desc_size = max(max_desc_size, ls_func->bl_desc_size);
> + }
> +
> + gdesc = kmalloc(max_desc_size, GFP_KERNEL);
> + if (!gdesc)
> + return -ENOMEM;
>
> nvkm_kmap(wpr_blob);
>
> @@ -421,7 +435,6 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
> list_head *imgs,
> struct ls_ucode_img_r352 *img = ls_ucode_img_r352(_img);
> const struct acr_r352_ls_func *ls_func =
>
> acr->func->ls_func[_img->falcon_id];
> - u8 gdesc[ls_func->bl_desc_size];
>
if there are no guarantees that (ls_func->bl_desc_size & 0x4 == 0),
then we need to memset a bit more, because 4 bytes at the time are
actually copied inside nvkm_gpuobj_memcpy_to later in that code, but
the last 4 bytes are only partly memset to 0.
If ls_func->bl_desc_size is always a multiple of 0x4, then it isn't as
important, but still better to be fixed. Or maybe
nvkm_gpuobj_memcpy_to should do that handling and check if the size is
a multiple of 0x4 and otherwise handle that case?
Same is valid for the changes in the r367 file.
> nvkm_gpuobj_memcpy_to(wpr_blob, pos, >wpr_header,
> sizeof(img->wpr_header));
> @@ -447,6 +460,8 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
> list_head *imgs,
>
> nvkm_done(wpr_blob);
>
> + kfree(gdesc);
> +
> return 0;
> }
>
> @@ -771,7 +786,11 @@ acr_r352_load(struct nvkm_acr *_acr, struct nvkm_falcon
> *falcon,
> struct fw_bl_desc *hsbl_desc;
> void *bl, *blob_data, *hsbl_code, *hsbl_data;
> u32 code_size;
> - u8 bl_desc[bl_desc_size];
> + u8 *bl_desc;
> +
> + bl_desc = kzalloc(bl_desc_size, GFP_KERNEL);
> + if (!bl_desc)
> + return -ENOMEM;
>
> /* Find the bootloader descriptor for our blob and copy it */
> if (blob == acr->load_blob) {
> @@ -802,7 +821,6 @@ acr_r352_load(struct nvkm_acr *_acr, struct nvkm_falcon
> *falcon,
> code_size, hsbl_desc->start_tag, 0, false);
>
> /* Generate the BL header */
> - memset(bl_desc, 0, bl_desc_size);
> acr->func->generate_hs_bl_desc(load_hdr, bl_desc, offset);
>
> /*
> @@ -811,6 +829,7 @@ acr_r352_load(struct nvkm_acr *_acr, struct nvkm_falcon
> *falcon,
> nvkm_falcon_load_dmem(falcon, bl_desc, hsbl_desc->dmem_load_off,
> bl_desc_size, 0);
>
> + kfree(bl_desc);
> return hsbl_desc->start_tag << 8;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c
> index 866877b88797..978ad0790367 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c
> @@ -265,6 +265,19 @@ acr_r367_ls_write_wpr(struct acr_r352 *acr, struct
> list_head *imgs,
> {
> struct ls_ucode_img *_img;
> u32 pos = 0;
> + u32 max_desc_size = 0;
> + u8 *gdesc;
> +
> + list_for_each_entry(_img, imgs, node) {
> + const struct acr_r352_ls_func *ls_func =
> +
> acr->func->ls_func[_img->falcon_id];
> +
> + max_desc_size = max(max_desc_size, ls_func->bl_desc_size);
> + }
> +
> + gdesc = kmalloc(max_desc_size, GFP_KERNEL);
> + if (!gdesc)
> + return -ENOMEM;
>
> nvkm_kmap(wpr_blob);
>
> @@ -272,7 +285,6 @@
Re: [DPU PATCH 09/11] drm/msm/dpu: Remove unused code and move the header
On 2018-06-22 21:03, Jordan Crouse wrote:
On Fri, Jun 22, 2018 at 09:51:28AM -0400, Sean Paul wrote:
On Wed, May 30, 2018 at 10:50 AM Rajesh Yadav
wrote:
>
> From: Jordan Crouse
>
> Remove unused code from dpu_io_util.c. The functions are only
> used inside of the msm driver so remove the EXPORT_SYMBOL
> tags and move the header dpu_io_util.h from include/linux.
>
> Signed-off-by: Jordan Crouse
> [rya...@codeaurora.org: rebased and removed some extra unused code]
> Signed-off-by: Rajesh Yadav
Hi Rajesh and Jordan,
I'm backporting this series for testing, and have found that the
mdss-pll driver uses both dpu_io_util and a bunch of functions/struct
members removed in this patchset. Do we anticipate having to add those
back for mdss-pll?
At some point in the distant past some of the downstream folks
discovered that
they were using relatively similar functions so they decided to share
the code.
The code originally lived in the display driver so it happened that the
exported
code continued to be hosted there.
I'm not sure what the upstream status of the mdss-pll code is but I
can't
imagine that sharing this code would be in the long term plan and even
if it
was basic module guidelines would dictate that it would live with
mdss-pll
which would be more likely to be either be built in or act as a
dependency for
DPU.
Jordan
Hi Sean,
drivers/clk/qcom/mdss was needed for dsi-staging driver and can be
safely dropped since we switched to upstream DSI driver.
Please drop the following change to address this issue (except for the
driver/gpu/drm/msm/Kconfig):
https://gitlab.freedesktop.org/seanpaul/dpu-staging/commit/2e433b56489b3e53b9d89ce7bfa15fb4698c8c58
I had tested it on my side.
Thanks,
Rajesh
> ---
> drivers/gpu/drm/msm/dpu_io_util.c | 380
+-
> drivers/gpu/drm/msm/dpu_io_util.h | 61 ++
> drivers/gpu/drm/msm/msm_drv.h | 1 -
> include/linux/dpu_io_util.h | 115
> 4 files changed, 66 insertions(+), 491 deletions(-)
> create mode 100644 drivers/gpu/drm/msm/dpu_io_util.h
> delete mode 100644 include/linux/dpu_io_util.h
>
> diff --git a/drivers/gpu/drm/msm/dpu_io_util.c
b/drivers/gpu/drm/msm/dpu_io_util.c
> index ecc297c..f7caec3 100644
> --- a/drivers/gpu/drm/msm/dpu_io_util.c
> +++ b/drivers/gpu/drm/msm/dpu_io_util.c
> @@ -13,318 +13,9 @@
>
> #include
> #include
> -#include
> -#include
> #include
> -#include
>
> -#define MAX_I2C_CMDS 16
> -void dss_reg_w(struct dss_io_data *io, u32 offset, u32 value, u32 debug)
> -{
> - u32 in_val;
> -
> - if (!io || !io->base) {
> - DEV_ERR("%pS->%s: invalid input\n",
> - __builtin_return_address(0), __func__);
> - return;
> - }
> -
> - if (offset > io->len) {
> - DEV_ERR("%pS->%s: offset out of range\n",
> - __builtin_return_address(0), __func__);
> - return;
> - }
> -
> - writel_relaxed(value, io->base + offset);
> - if (debug) {
> - in_val = readl_relaxed(io->base + offset);
> - DEV_DBG("[%08x] => %08x [%08x]\n",
> - (u32)(unsigned long)(io->base + offset),
> - value, in_val);
> - }
> -} /* dss_reg_w */
> -EXPORT_SYMBOL(dss_reg_w);
> -
> -u32 dss_reg_r(struct dss_io_data *io, u32 offset, u32 debug)
> -{
> - u32 value;
> -
> - if (!io || !io->base) {
> - DEV_ERR("%pS->%s: invalid input\n",
> - __builtin_return_address(0), __func__);
> - return -EINVAL;
> - }
> -
> - if (offset > io->len) {
> - DEV_ERR("%pS->%s: offset out of range\n",
> - __builtin_return_address(0), __func__);
> - return -EINVAL;
> - }
> -
> - value = readl_relaxed(io->base + offset);
> - if (debug)
> - DEV_DBG("[%08x] <= %08x\n",
> - (u32)(unsigned long)(io->base + offset), value);
> -
> - return value;
> -} /* dss_reg_r */
> -EXPORT_SYMBOL(dss_reg_r);
> -
> -void dss_reg_dump(void __iomem *base, u32 length, const char *prefix,
> - u32 debug)
> -{
> - if (debug)
> - print_hex_dump(KERN_INFO, prefix, DUMP_PREFIX_OFFSET, 32, 4,
> - (void *)base, length, false);
> -} /* dss_reg_dump */
> -EXPORT_SYMBOL(dss_reg_dump);
> -
> -static struct resource *msm_dss_get_res_byname(struct platform_device *pdev,
> - unsigned int type, const char *name)
> -{
> - struct resource *res = NULL;
> -
> - res = platform_get_resource_byname(pdev, type, name);
> - if (!res)
> - DEV_ERR("%s: '%s' resource not found\n", __func__, name);
> -
> - return res;
> -} /* msm_dss_get_res_byname */
> -EXPORT_SYMBOL(msm_dss_get_res_byname);
> -
> -int msm_dss_ioremap_byname(struct platform_device *pdev,
> - struct dss_io_data *io_data, const
Re: [PATCH] drm/amdgpu: Count disabled CRTCs in commit tail earlier
On 06/21/2018 04:48 PM, Lyude Paul wrote: This fixes a regression I accidentally reduced that was picked up by kasan, where we were checking the CRTC atomic states after DRM's helpers had already freed them. Example: == BUG: KASAN: use-after-free in amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] Read of size 1 at addr 8803a697b071 by task kworker/u16:0/7 CPU: 7 PID: 7 Comm: kworker/u16:0 Tainted: G O 4.18.0-rc1Lyude-Upstream+ #1 Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.21 05/02/2018 Workqueue: events_unbound commit_work [drm_kms_helper] Call Trace: dump_stack+0xc1/0x169 ? dump_stack_print_info.cold.1+0x42/0x42 ? kmsg_dump_rewind_nolock+0xd9/0xd9 ? printk+0x9f/0xc5 ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] print_address_description+0x6c/0x23c ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] kasan_report.cold.6+0x241/0x2fd amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] ? commit_planes_to_stream.constprop.45+0x13b0/0x13b0 [amdgpu] ? cpu_load_update_active+0x290/0x290 ? finish_task_switch+0x2bd/0x840 ? __switch_to_asm+0x34/0x70 ? read_word_at_a_time+0xe/0x20 ? strscpy+0x14b/0x460 ? drm_atomic_helper_wait_for_dependencies+0x47d/0x7e0 [drm_kms_helper] commit_tail+0x96/0xe0 [drm_kms_helper] process_one_work+0x88a/0x1360 ? create_worker+0x540/0x540 ? __sched_text_start+0x8/0x8 ? move_queued_task+0x760/0x760 ? call_rcu_sched+0x20/0x20 ? vsnprintf+0xcda/0x1350 ? wait_woken+0x1c0/0x1c0 ? mutex_unlock+0x1d/0x40 ? init_timer_key+0x190/0x230 ? schedule+0xea/0x390 ? __schedule+0x1ea0/0x1ea0 ? need_to_create_worker+0xe4/0x210 ? init_worker_pool+0x700/0x700 ? try_to_del_timer_sync+0xbf/0x110 ? del_timer+0x120/0x120 ? __mutex_lock_slowpath+0x10/0x10 worker_thread+0x196/0x11f0 ? flush_rcu_work+0x50/0x50 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __schedule+0x7d6/0x1ea0 ? migrate_swap_stop+0x850/0x880 ? __sched_text_start+0x8/0x8 ? save_stack+0x8c/0xb0 ? kasan_kmalloc+0xbf/0xe0 ? kmem_cache_alloc_trace+0xe4/0x190 ? kthread+0x98/0x390 ? ret_from_fork+0x35/0x40 ? ret_from_fork+0x35/0x40 ? deactivate_slab.isra.67+0x3c4/0x5c0 ? kthread+0x98/0x390 ? kthread+0x98/0x390 ? set_track+0x76/0x120 ? schedule+0xea/0x390 ? __schedule+0x1ea0/0x1ea0 ? wait_woken+0x1c0/0x1c0 ? kasan_unpoison_shadow+0x30/0x40 ? parse_args.cold.15+0x17a/0x17a ? flush_rcu_work+0x50/0x50 kthread+0x2d4/0x390 ? kthread_create_worker_on_cpu+0xc0/0xc0 ret_from_fork+0x35/0x40 Allocated by task 1124: kasan_kmalloc+0xbf/0xe0 kmem_cache_alloc_trace+0xe4/0x190 dm_crtc_duplicate_state+0x78/0x130 [amdgpu] drm_atomic_get_crtc_state+0x147/0x410 [drm] page_flip_common+0x57/0x230 [drm_kms_helper] drm_atomic_helper_page_flip+0xa6/0x110 [drm_kms_helper] drm_mode_page_flip_ioctl+0xc4b/0x10a0 [drm] drm_ioctl_kernel+0x1d4/0x260 [drm] drm_ioctl+0x433/0x920 [drm] amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] do_vfs_ioctl+0x1a1/0x13d0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x147/0x440 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 1124: __kasan_slab_free+0x12e/0x180 kfree+0x92/0x1a0 drm_atomic_state_default_clear+0x315/0xc40 [drm] __drm_atomic_state_free+0x35/0xd0 [drm] drm_atomic_helper_update_plane+0xac/0x350 [drm_kms_helper] __setplane_internal+0x2d6/0x840 [drm] drm_mode_cursor_universal+0x41e/0xbe0 [drm] drm_mode_cursor_common+0x49f/0x880 [drm] drm_mode_cursor_ioctl+0xd8/0x130 [drm] drm_ioctl_kernel+0x1d4/0x260 [drm] drm_ioctl+0x433/0x920 [drm] amdgpu_drm_ioctl+0x11d/0x290 [amdgpu] do_vfs_ioctl+0x1a1/0x13d0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x147/0x440 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at 8803a697b068 which belongs to the cache kmalloc-1024 of size 1024 The buggy address is located 9 bytes inside of 1024-byte region [8803a697b068, 8803a697b468) The buggy address belongs to the page: page:ea000e9a5e00 count:1 mapcount:0 mapping:88041e00efc0 index:0x0 compound_mapcount: 0 flags: 0x80008100(slab|head) raw: 80008100 ea000ecbc208 88041e000c70 88041e00efc0 raw: 00170017 0001 page dumped because: kasan: bad access detected Memory state around the buggy address: 8803a697af00: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 8803a697af80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 8803a697b000: fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb ^ 8803a697b080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri, Jun 22, 2018 at 06:42:43PM +0200, Michal Hocko wrote:
> [Resnding with the CC list fixed]
>
> On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> > On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > > > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > > > > Hi,
> > > > > > this is an RFC and not tested at all. I am not very familiar with
> > > > > > the
> > > > > > mmu notifiers semantics very much so this is a crude attempt to
> > > > > > achieve
> > > > > > what I need basically. It might be completely wrong but I would like
> > > > > > to discuss what would be a better way if that is the case.
> > > > > >
> > > > > > get_maintainers gave me quite large list of people to CC so I had
> > > > > > to trim
> > > > > > it down. If you think I have forgot somebody, please let me know
> > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > > index 854bd51b9478..5285df9331fa 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object
> > > > > > *mo)
> > > > > > mo->attached = false;
> > > > > > }
> > > > > >
> > > > > > -static void i915_gem_userptr_mn_invalidate_range_start(struct
> > > > > > mmu_notifier *_mn,
> > > > > > +static int i915_gem_userptr_mn_invalidate_range_start(struct
> > > > > > mmu_notifier *_mn,
> > > > > >struct
> > > > > > mm_struct *mm,
> > > > > >unsigned
> > > > > > long start,
> > > > > > - unsigned
> > > > > > long end)
> > > > > > + unsigned
> > > > > > long end,
> > > > > > + bool
> > > > > > blockable)
> > > > > > {
> > > > > > struct i915_mmu_notifier *mn =
> > > > > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > > > > @@ -124,7 +125,7 @@ static void
> > > > > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > > > > LIST_HEAD(cancelled);
> > > > > >
> > > > > > if (RB_EMPTY_ROOT(>objects.rb_root))
> > > > > > - return;
> > > > > > + return 0;
> > > > >
> > > > > The principle wait here is for the HW (even after fixing all the locks
> > > > > to be not so coarse, we still have to wait for the HW to finish its
> > > > > access).
> > > >
> > > > Is this wait bound or it can take basically arbitrary amount of time?
> > >
> > > Arbitrary amount of time but in desktop use case you can assume that
> > > it should never go above 16ms for a 60frame per second rendering of
> > > your desktop (in GPU compute case this kind of assumption does not
> > > hold). Is the process exit_state already updated by the time this mmu
> > > notifier callbacks happen ?
> >
> > What do you mean? The process is killed (by SIGKILL) at the time but we
> > do not know much more than that. The task might be stuck anywhere in the
> > kernel before handling that signal.
I was wondering if another thread might still be dereferencing any of
the structure concurrently with the OOM mmu notifier callback. Saddly
yes, it would be simpler if we could make such assumption.
> >
> > > > > The first pass would be then to not do anything here if
> > > > > !blockable.
> > > >
> > > > something like this? (incremental diff)
> > >
> > > What i wanted to do with HMM and mmu notifier is split the invalidation
> > > in 2 pass. First pass tell the drivers to stop/cancel pending jobs that
> > > depends on the range and invalidate internal driver states (like clear
> > > buffer object pages array in case of GPU but not GPU page table). While
> > > the second callback would do the actual wait on the GPU to be done and
> > > update the GPU page table.
> >
> > What can you do after the first phase? Can I unmap the range?
No you can't do anything but this force synchronization as any other
thread that concurrently trie to do something with those would queue
up. So it would serialize thing. Also main motivation on my side is
multi-GPU, right now multi-GPU are not that common but this is changing
quickly and what we see on high end (4, 8 or 16 GPUs per socket) is
spreading into more configurations. Here in mutli GPU case splitting
in two would avoid having to fully wait on first GPU before trying to
invaidate on second GPU, so on and so forth.
> >
> > > Now in this scheme in case the task is already in some exit state and
> > > that all CPU threads are frozen/kill then we can probably find a way to
> > > do the first path mostly lock less. AFAICR nor AMD nor Intel allow to
> > >
[Bug 102962] GPU crash running Overwatch in wine-staging
https://bugs.freedesktop.org/show_bug.cgi?id=102962 --- Comment #10 from amd_user --- Why does the system freeze when selecting Symmetra in the Hero Selection screen? Is it a mesa bug or wine bug? linux 4.17.2 amd ryzen 3 mesa 18.1.2 wine-staging 3.10 -- 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 106418] kernel BUG at drivers/dma-buf/reservation.c:234!
https://bugs.freedesktop.org/show_bug.cgi?id=106418 --- Comment #6 from Michel Dänzer --- (In reply to davep from comment #5) > My name's Dave Panariti (david.and I'm going to be taking a look at this. Thanks for looking into this, Dave. After hitting the BUG_ON again this week, I got fed up, took a closer look, and I think I found the problem here. This patch should fix it: https://patchwork.freedesktop.org/patch/231303/ -- 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] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
[Resnding with the CC list fixed]
On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > > > Hi,
> > > > > this is an RFC and not tested at all. I am not very familiar with the
> > > > > mmu notifiers semantics very much so this is a crude attempt to
> > > > > achieve
> > > > > what I need basically. It might be completely wrong but I would like
> > > > > to discuss what would be a better way if that is the case.
> > > > >
> > > > > get_maintainers gave me quite large list of people to CC so I had to
> > > > > trim
> > > > > it down. If you think I have forgot somebody, please let me know
> > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > index 854bd51b9478..5285df9331fa 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object
> > > > > *mo)
> > > > > mo->attached = false;
> > > > > }
> > > > >
> > > > > -static void i915_gem_userptr_mn_invalidate_range_start(struct
> > > > > mmu_notifier *_mn,
> > > > > +static int i915_gem_userptr_mn_invalidate_range_start(struct
> > > > > mmu_notifier *_mn,
> > > > >struct
> > > > > mm_struct *mm,
> > > > >unsigned long
> > > > > start,
> > > > > - unsigned long
> > > > > end)
> > > > > + unsigned long
> > > > > end,
> > > > > + bool blockable)
> > > > > {
> > > > > struct i915_mmu_notifier *mn =
> > > > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > > > @@ -124,7 +125,7 @@ static void
> > > > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > > > LIST_HEAD(cancelled);
> > > > >
> > > > > if (RB_EMPTY_ROOT(>objects.rb_root))
> > > > > - return;
> > > > > + return 0;
> > > >
> > > > The principle wait here is for the HW (even after fixing all the locks
> > > > to be not so coarse, we still have to wait for the HW to finish its
> > > > access).
> > >
> > > Is this wait bound or it can take basically arbitrary amount of time?
> >
> > Arbitrary amount of time but in desktop use case you can assume that
> > it should never go above 16ms for a 60frame per second rendering of
> > your desktop (in GPU compute case this kind of assumption does not
> > hold). Is the process exit_state already updated by the time this mmu
> > notifier callbacks happen ?
>
> What do you mean? The process is killed (by SIGKILL) at the time but we
> do not know much more than that. The task might be stuck anywhere in the
> kernel before handling that signal.
>
> > > > The first pass would be then to not do anything here if
> > > > !blockable.
> > >
> > > something like this? (incremental diff)
> >
> > What i wanted to do with HMM and mmu notifier is split the invalidation
> > in 2 pass. First pass tell the drivers to stop/cancel pending jobs that
> > depends on the range and invalidate internal driver states (like clear
> > buffer object pages array in case of GPU but not GPU page table). While
> > the second callback would do the actual wait on the GPU to be done and
> > update the GPU page table.
>
> What can you do after the first phase? Can I unmap the range?
>
> > Now in this scheme in case the task is already in some exit state and
> > that all CPU threads are frozen/kill then we can probably find a way to
> > do the first path mostly lock less. AFAICR nor AMD nor Intel allow to
> > share userptr bo hence a uptr bo should only ever be access through
> > ioctl submited by the process.
> >
> > The second call can then be delayed and ping from time to time to see
> > if GPU jobs are done.
> >
> >
> > Note that what you propose might still be useful as in case there is
> > no buffer object for a range then OOM can make progress in freeing a
> > range of memory. It is very likely that significant virtual address
> > range of a process and backing memory can be reclaim that way. This
> > assume OOM reclaim vma by vma or in some form of granularity like
> > reclaiming 1GB by 1GB. Or we could also update blocking callback to
> > return range that are blocking that way OOM can reclaim around.
>
> Exactly my point. What we have right now is all or nothing which is
> obviously too coarse to be useful.
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[Bug 106928] When starting a match Rocket League crashes on "Go"
https://bugs.freedesktop.org/show_bug.cgi?id=106928 --- Comment #2 from Roland Scheidegger --- Definitely looks like a r600 issue, in the sb code (I suppose it would work with R600_DEBUG=nosb). An apitrace might be helpful (it should be possible to capture one with nosb so it doesn't crash and then replaying it without that should crash). Unless someone has some ideas what could be wrong with the sb code 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
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
[Hmm, the cc list got mangled somehow - you have just made many people
to work for suse ;) and to kvack.org in the preious one - fixed up
hopefully]
On Fri 22-06-18 17:07:21, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:57:16)
> > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > > Hi,
> > > > this is an RFC and not tested at all. I am not very familiar with the
> > > > mmu notifiers semantics very much so this is a crude attempt to achieve
> > > > what I need basically. It might be completely wrong but I would like
> > > > to discuss what would be a better way if that is the case.
> > > >
> > > > get_maintainers gave me quite large list of people to CC so I had to
> > > > trim
> > > > it down. If you think I have forgot somebody, please let me know
> > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > index 854bd51b9478..5285df9331fa 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> > > > mo->attached = false;
> > > > }
> > > >
> > > > -static void i915_gem_userptr_mn_invalidate_range_start(struct
> > > > mmu_notifier *_mn,
> > > > +static int i915_gem_userptr_mn_invalidate_range_start(struct
> > > > mmu_notifier *_mn,
> > > >struct mm_struct
> > > > *mm,
> > > >unsigned long
> > > > start,
> > > > - unsigned long
> > > > end)
> > > > + unsigned long
> > > > end,
> > > > + bool blockable)
> > > > {
> > > > struct i915_mmu_notifier *mn =
> > > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > > @@ -124,7 +125,7 @@ static void
> > > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > > LIST_HEAD(cancelled);
> > > >
> > > > if (RB_EMPTY_ROOT(>objects.rb_root))
> > > > - return;
> > > > + return 0;
> > >
> > > The principle wait here is for the HW (even after fixing all the locks
> > > to be not so coarse, we still have to wait for the HW to finish its
> > > access).
> >
> > Is this wait bound or it can take basically arbitrary amount of time?
>
> Arbitrary. It waits for the last operation in the queue that needs that
> set of backing pages, and that queue is unbounded and not even confined
> to the local driver. (Though each operation should be bounded to be
> completed within an interval or be cancelled, that interval is on the
> order of 10s!)
OK, I see. We should rather not wait that long so backoff is just
better. The whole point of the oom_reaper is to tear down and free some
memory. We do not really need to reclaim all of it.
It would be great if we could do something like - kick the tear down of
the device memory but have it done in the background. We wouldn't tear
the vma down in that case but the whole process would start at least.
I am not sure something like that is possible.
> > > The first pass would be then to not do anything here if
> > > !blockable.
> >
> > something like this? (incremental diff)
>
> Yup.
Cool, I will start with that because even that is an improvement from
the oom_reaper POV.
Thanks!
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > Hi,
> > > this is an RFC and not tested at all. I am not very familiar with the
> > > mmu notifiers semantics very much so this is a crude attempt to achieve
> > > what I need basically. It might be completely wrong but I would like
> > > to discuss what would be a better way if that is the case.
> > >
> > > get_maintainers gave me quite large list of people to CC so I had to trim
> > > it down. If you think I have forgot somebody, please let me know
> >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > index 854bd51b9478..5285df9331fa 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> > > mo->attached = false;
> > > }
> > >
> > > -static void i915_gem_userptr_mn_invalidate_range_start(struct
> > > mmu_notifier *_mn,
> > > +static int i915_gem_userptr_mn_invalidate_range_start(struct
> > > mmu_notifier *_mn,
> > >struct mm_struct
> > > *mm,
> > >unsigned long
> > > start,
> > > - unsigned long end)
> > > + unsigned long end,
> > > + bool blockable)
> > > {
> > > struct i915_mmu_notifier *mn =
> > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > @@ -124,7 +125,7 @@ static void
> > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > LIST_HEAD(cancelled);
> > >
> > > if (RB_EMPTY_ROOT(>objects.rb_root))
> > > - return;
> > > + return 0;
> >
> > The principle wait here is for the HW (even after fixing all the locks
> > to be not so coarse, we still have to wait for the HW to finish its
> > access).
>
> Is this wait bound or it can take basically arbitrary amount of time?
Arbitrary amount of time but in desktop use case you can assume that
it should never go above 16ms for a 60frame per second rendering of
your desktop (in GPU compute case this kind of assumption does not
hold). Is the process exit_state already updated by the time this mmu
notifier callbacks happen ?
>
> > The first pass would be then to not do anything here if
> > !blockable.
>
> something like this? (incremental diff)
What i wanted to do with HMM and mmu notifier is split the invalidation
in 2 pass. First pass tell the drivers to stop/cancel pending jobs that
depends on the range and invalidate internal driver states (like clear
buffer object pages array in case of GPU but not GPU page table). While
the second callback would do the actual wait on the GPU to be done and
update the GPU page table.
Now in this scheme in case the task is already in some exit state and
that all CPU threads are frozen/kill then we can probably find a way to
do the first path mostly lock less. AFAICR nor AMD nor Intel allow to
share userptr bo hence a uptr bo should only ever be access through
ioctl submited by the process.
The second call can then be delayed and ping from time to time to see
if GPU jobs are done.
Note that what you propose might still be useful as in case there is
no buffer object for a range then OOM can make progress in freeing a
range of memory. It is very likely that significant virtual address
range of a process and backing memory can be reclaim that way. This
assume OOM reclaim vma by vma or in some form of granularity like
reclaiming 1GB by 1GB. Or we could also update blocking callback to
return range that are blocking that way OOM can reclaim around.
Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: remove now unused functions
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.18-rc1 next-20180622]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-omap-remove-now-unused-functions/20180622-212309
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> drivers/gpu//drm/omapdrm/omap_gem_dmabuf.c:134:16: error:
>> 'omap_gem_dmabuf_kmap_atomic' undeclared here (not in a function); did you
>> mean 'drm_gem_dmabuf_kmap_atomic'?
.map_atomic = omap_gem_dmabuf_kmap_atomic,
^~~
drm_gem_dmabuf_kmap_atomic
>> drivers/gpu//drm/omapdrm/omap_gem_dmabuf.c:135:18: error:
>> 'omap_gem_dmabuf_kunmap_atomic' undeclared here (not in a function); did you
>> mean 'omap_gem_dmabuf_kmap_atomic'?
.unmap_atomic = omap_gem_dmabuf_kunmap_atomic,
^
omap_gem_dmabuf_kmap_atomic
vim +134 drivers/gpu//drm/omapdrm/omap_gem_dmabuf.c
8b6b569e drivers/staging/omapdrm/omap_gem_dmabuf.c Rob Clark2012-05-17
127
815ed41b drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c Arvind Yadav 2017-07-02
128 static const struct dma_buf_ops omap_dmabuf_ops = {
6ad11bc3 drivers/staging/omapdrm/omap_gem_dmabuf.c Rob Clark2012-04-10
129 .map_dma_buf = omap_gem_map_dma_buf,
6ad11bc3 drivers/staging/omapdrm/omap_gem_dmabuf.c Rob Clark2012-04-10
130 .unmap_dma_buf = omap_gem_unmap_dma_buf,
c488dd20 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c Laurent Pinchart 2017-05-08
131 .release = drm_gem_dmabuf_release,
6ad11bc3 drivers/staging/omapdrm/omap_gem_dmabuf.c Rob Clark2012-04-10
132 .begin_cpu_access = omap_gem_dmabuf_begin_cpu_access,
6ad11bc3 drivers/staging/omapdrm/omap_gem_dmabuf.c Rob Clark2012-04-10
133 .end_cpu_access = omap_gem_dmabuf_end_cpu_access,
f9b67f00 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c Logan Gunthorpe 2017-04-19
@134 .map_atomic = omap_gem_dmabuf_kmap_atomic,
f9b67f00 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c Logan Gunthorpe 2017-04-19
@135 .unmap_atomic = omap_gem_dmabuf_kunmap_atomic,
f9b67f00 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c Logan Gunthorpe 2017-04-19
136 .map = omap_gem_dmabuf_kmap,
f9b67f00 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c Logan Gunthorpe 2017-04-19
137 .unmap = omap_gem_dmabuf_kunmap,
8b6b569e drivers/staging/omapdrm/omap_gem_dmabuf.c Rob Clark2012-05-17
138 .mmap = omap_gem_dmabuf_mmap,
6ad11bc3 drivers/staging/omapdrm/omap_gem_dmabuf.c Rob Clark2012-04-10
139 };
6ad11bc3 drivers/staging/omapdrm/omap_gem_dmabuf.c Rob Clark2012-04-10
140
:: The code at line 134 was first introduced by commit
:: f9b67f0014cba18f1aabb6fa9272335a043eb6fd dma-buf: Rename dma-ops to
prevent conflict with kunmap_atomic macro
:: TO: Logan Gunthorpe
:: CC: Sumit Semwal
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:02:42)
> > Hi,
> > this is an RFC and not tested at all. I am not very familiar with the
> > mmu notifiers semantics very much so this is a crude attempt to achieve
> > what I need basically. It might be completely wrong but I would like
> > to discuss what would be a better way if that is the case.
> >
> > get_maintainers gave me quite large list of people to CC so I had to trim
> > it down. If you think I have forgot somebody, please let me know
>
> > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > index 854bd51b9478..5285df9331fa 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> > mo->attached = false;
> > }
> >
> > -static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> > *_mn,
> > +static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> > *_mn,
> >struct mm_struct *mm,
> >unsigned long start,
> > - unsigned long end)
> > + unsigned long end,
> > + bool blockable)
> > {
> > struct i915_mmu_notifier *mn =
> > container_of(_mn, struct i915_mmu_notifier, mn);
> > @@ -124,7 +125,7 @@ static void
> > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > LIST_HEAD(cancelled);
> >
> > if (RB_EMPTY_ROOT(>objects.rb_root))
> > - return;
> > + return 0;
>
> The principle wait here is for the HW (even after fixing all the locks
> to be not so coarse, we still have to wait for the HW to finish its
> access).
Is this wait bound or it can take basically arbitrary amount of time?
> The first pass would be then to not do anything here if
> !blockable.
something like this? (incremental diff)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 5285df9331fa..e9ed0d2cfabc 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -122,6 +122,7 @@ static int
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
container_of(_mn, struct i915_mmu_notifier, mn);
struct i915_mmu_object *mo;
struct interval_tree_node *it;
+ int ret = 0;
LIST_HEAD(cancelled);
if (RB_EMPTY_ROOT(>objects.rb_root))
@@ -133,6 +134,10 @@ static int
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
spin_lock(>lock);
it = interval_tree_iter_first(>objects, start, end);
while (it) {
+ if (!blockable) {
+ ret = -EAGAIN;
+ goto out_unlock;
+ }
/* The mmu_object is released late when destroying the
* GEM object so it is entirely possible to gain a
* reference on an object in the process of being freed
@@ -154,8 +159,10 @@ static int
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
spin_unlock(>lock);
/* TODO: can we skip waiting here? */
- if (!list_empty() && blockable)
+ if (!list_empty())
flush_workqueue(mn->wq);
+
+ return ret;
}
static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #14 from Ilia Mirkin --- (In reply to Mike Lothian from comment #13) > I know my SkyQ box outputs at 2160@60Hz in 10bit colour https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_HDR10_video 4k@60@10bpc needs YUV 4:2:2 for HDMI 2.0, so it can't handle RGB (or YUV 4:4:4). That's probably the discrepancy - there's currently no great way for userspace to select which encoding variant is to be used (or what bpc to send it at). -- 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] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Quoting Michal Hocko (2018-06-22 16:02:42)
> Hi,
> this is an RFC and not tested at all. I am not very familiar with the
> mmu notifiers semantics very much so this is a crude attempt to achieve
> what I need basically. It might be completely wrong but I would like
> to discuss what would be a better way if that is the case.
>
> get_maintainers gave me quite large list of people to CC so I had to trim
> it down. If you think I have forgot somebody, please let me know
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 854bd51b9478..5285df9331fa 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> mo->attached = false;
> }
>
> -static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> *_mn,
> +static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> *_mn,
>struct mm_struct *mm,
>unsigned long start,
> - unsigned long end)
> + unsigned long end,
> + bool blockable)
> {
> struct i915_mmu_notifier *mn =
> container_of(_mn, struct i915_mmu_notifier, mn);
> @@ -124,7 +125,7 @@ static void
> i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> LIST_HEAD(cancelled);
>
> if (RB_EMPTY_ROOT(>objects.rb_root))
> - return;
> + return 0;
The principle wait here is for the HW (even after fixing all the locks
to be not so coarse, we still have to wait for the HW to finish its
access). The first pass would be then to not do anything here if
!blockable.
Jerome keeps on shaking his head and telling us we're doing it all
wrong, so maybe it'll all fall out of HMM before we have to figure out
how to differentiate between objects that can be invalidated immediately
and those that need to acquire locks and/or wait.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 09/11] drm/msm/dpu: Remove unused code and move the header
On Fri, Jun 22, 2018 at 09:51:28AM -0400, Sean Paul wrote:
> On Wed, May 30, 2018 at 10:50 AM Rajesh Yadav wrote:
> >
> > From: Jordan Crouse
> >
> > Remove unused code from dpu_io_util.c. The functions are only
> > used inside of the msm driver so remove the EXPORT_SYMBOL
> > tags and move the header dpu_io_util.h from include/linux.
> >
> > Signed-off-by: Jordan Crouse
> > [rya...@codeaurora.org: rebased and removed some extra unused code]
> > Signed-off-by: Rajesh Yadav
>
> Hi Rajesh and Jordan,
> I'm backporting this series for testing, and have found that the
> mdss-pll driver uses both dpu_io_util and a bunch of functions/struct
> members removed in this patchset. Do we anticipate having to add those
> back for mdss-pll?
At some point in the distant past some of the downstream folks discovered that
they were using relatively similar functions so they decided to share the code.
The code originally lived in the display driver so it happened that the exported
code continued to be hosted there.
I'm not sure what the upstream status of the mdss-pll code is but I can't
imagine that sharing this code would be in the long term plan and even if it
was basic module guidelines would dictate that it would live with mdss-pll
which would be more likely to be either be built in or act as a dependency for
DPU.
Jordan
> > ---
> > drivers/gpu/drm/msm/dpu_io_util.c | 380
> > +-
> > drivers/gpu/drm/msm/dpu_io_util.h | 61 ++
> > drivers/gpu/drm/msm/msm_drv.h | 1 -
> > include/linux/dpu_io_util.h | 115
> > 4 files changed, 66 insertions(+), 491 deletions(-)
> > create mode 100644 drivers/gpu/drm/msm/dpu_io_util.h
> > delete mode 100644 include/linux/dpu_io_util.h
> >
> > diff --git a/drivers/gpu/drm/msm/dpu_io_util.c
> > b/drivers/gpu/drm/msm/dpu_io_util.c
> > index ecc297c..f7caec3 100644
> > --- a/drivers/gpu/drm/msm/dpu_io_util.c
> > +++ b/drivers/gpu/drm/msm/dpu_io_util.c
> > @@ -13,318 +13,9 @@
> >
> > #include
> > #include
> > -#include
> > -#include
> > #include
> > -#include
> >
> > -#define MAX_I2C_CMDS 16
> > -void dss_reg_w(struct dss_io_data *io, u32 offset, u32 value, u32 debug)
> > -{
> > - u32 in_val;
> > -
> > - if (!io || !io->base) {
> > - DEV_ERR("%pS->%s: invalid input\n",
> > - __builtin_return_address(0), __func__);
> > - return;
> > - }
> > -
> > - if (offset > io->len) {
> > - DEV_ERR("%pS->%s: offset out of range\n",
> > - __builtin_return_address(0), __func__);
> > - return;
> > - }
> > -
> > - writel_relaxed(value, io->base + offset);
> > - if (debug) {
> > - in_val = readl_relaxed(io->base + offset);
> > - DEV_DBG("[%08x] => %08x [%08x]\n",
> > - (u32)(unsigned long)(io->base + offset),
> > - value, in_val);
> > - }
> > -} /* dss_reg_w */
> > -EXPORT_SYMBOL(dss_reg_w);
> > -
> > -u32 dss_reg_r(struct dss_io_data *io, u32 offset, u32 debug)
> > -{
> > - u32 value;
> > -
> > - if (!io || !io->base) {
> > - DEV_ERR("%pS->%s: invalid input\n",
> > - __builtin_return_address(0), __func__);
> > - return -EINVAL;
> > - }
> > -
> > - if (offset > io->len) {
> > - DEV_ERR("%pS->%s: offset out of range\n",
> > - __builtin_return_address(0), __func__);
> > - return -EINVAL;
> > - }
> > -
> > - value = readl_relaxed(io->base + offset);
> > - if (debug)
> > - DEV_DBG("[%08x] <= %08x\n",
> > - (u32)(unsigned long)(io->base + offset), value);
> > -
> > - return value;
> > -} /* dss_reg_r */
> > -EXPORT_SYMBOL(dss_reg_r);
> > -
> > -void dss_reg_dump(void __iomem *base, u32 length, const char *prefix,
> > - u32 debug)
> > -{
> > - if (debug)
> > - print_hex_dump(KERN_INFO, prefix, DUMP_PREFIX_OFFSET, 32, 4,
> > - (void *)base, length, false);
> > -} /* dss_reg_dump */
> > -EXPORT_SYMBOL(dss_reg_dump);
> > -
> > -static struct resource *msm_dss_get_res_byname(struct platform_device
> > *pdev,
> > - unsigned int type, const char *name)
> > -{
> > - struct resource *res = NULL;
> > -
> > - res = platform_get_resource_byname(pdev, type, name);
> > - if (!res)
> > - DEV_ERR("%s: '%s' resource not found\n", __func__, name);
> > -
> > - return res;
> > -} /* msm_dss_get_res_byname */
> > -EXPORT_SYMBOL(msm_dss_get_res_byname);
> > -
> > -int msm_dss_ioremap_byname(struct platform_device *pdev,
> > - struct dss_io_data *io_data, const char *name)
> > -{
> > - struct resource *res = NULL;
> > -
> > - if (!pdev || !io_data) {
> > - DEV_ERR("%pS->%s: invalid input\n",
> > -
[Bug 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #13 from Mike Lothian --- What is Raven capable of? I know my SkyQ box outputs at 2160@60Hz in 10bit colour -- 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: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri 22-06-18 17:13:02, Christian König wrote:
> Hi Michal,
>
> [Adding Felix as well]
>
> Well first of all you have a misconception why at least the AMD graphics
> driver need to be able to sleep in an MMU notifier: We need to sleep because
> we need to wait for hardware operations to finish and *NOT* because we need
> to wait for locks.
>
> I'm not sure if your flag now means that you generally can't sleep in MMU
> notifiers any more, but if that's the case at least AMD hardware will break
> badly. In our case the approach of waiting for a short time for the process
> to be reaped and then select another victim actually sounds like the right
> thing to do.
Well, I do not need to make the notifier code non blocking all the time.
All I need is to ensure that it won't sleep if the flag says so and
return -EAGAIN instead.
So here is what I do for amdgpu:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > index 83e344fbb50a..d138a526feff 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > @@ -136,12 +136,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> >*
> >* Take the rmn read side lock.
> >*/
> > -static void amdgpu_mn_read_lock(struct amdgpu_mn *rmn)
> > +static int amdgpu_mn_read_lock(struct amdgpu_mn *rmn, bool blockable)
> > {
> > - mutex_lock(>read_lock);
> > + if (blockable)
> > + mutex_lock(>read_lock);
> > + else if (!mutex_trylock(>read_lock))
> > + return -EAGAIN;
> > +
> > if (atomic_inc_return(>recursion) == 1)
> > down_read_non_owner(>lock);
> > mutex_unlock(>read_lock);
> > +
> > + return 0;
> > }
> > /**
> > @@ -197,10 +203,11 @@ static void amdgpu_mn_invalidate_node(struct
> > amdgpu_mn_node *node,
> >* We block for all BOs between start and end to be idle and
> >* unmap them by move them into system domain again.
> >*/
> > -static void amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
> > +static int amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
> > struct mm_struct *mm,
> > unsigned long start,
> > -unsigned long end)
> > +unsigned long end,
> > +bool blockable)
> > {
> > struct amdgpu_mn *rmn = container_of(mn, struct amdgpu_mn, mn);
> > struct interval_tree_node *it;
> > @@ -208,7 +215,11 @@ static void
> > amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
> > /* notification is exclusive, but interval is inclusive */
> > end -= 1;
> > - amdgpu_mn_read_lock(rmn);
> > + /* TODO we should be able to split locking for interval tree and
> > +* amdgpu_mn_invalidate_node
> > +*/
> > + if (amdgpu_mn_read_lock(rmn, blockable))
> > + return -EAGAIN;
> > it = interval_tree_iter_first(>objects, start, end);
> > while (it) {
> > @@ -219,6 +230,8 @@ static void amdgpu_mn_invalidate_range_start_gfx(struct
> > mmu_notifier *mn,
> > amdgpu_mn_invalidate_node(node, start, end);
> > }
> > +
> > + return 0;
> > }
> > /**
> > @@ -233,10 +246,11 @@ static void
> > amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
> >* necessitates evicting all user-mode queues of the process. The BOs
> >* are restorted in amdgpu_mn_invalidate_range_end_hsa.
> >*/
> > -static void amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
> > +static int amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
> > struct mm_struct *mm,
> > unsigned long start,
> > -unsigned long end)
> > +unsigned long end,
> > +bool blockable)
> > {
> > struct amdgpu_mn *rmn = container_of(mn, struct amdgpu_mn, mn);
> > struct interval_tree_node *it;
> > @@ -244,7 +258,8 @@ static void amdgpu_mn_invalidate_range_start_hsa(struct
> > mmu_notifier *mn,
> > /* notification is exclusive, but interval is inclusive */
> > end -= 1;
> > - amdgpu_mn_read_lock(rmn);
> > + if (amdgpu_mn_read_lock(rmn, blockable))
> > + return -EAGAIN;
> > it = interval_tree_iter_first(>objects, start, end);
> > while (it) {
> > @@ -262,6 +277,8 @@ static void amdgpu_mn_invalidate_range_start_hsa(struct
> > mmu_notifier *mn,
> > amdgpu_amdkfd_evict_userptr(mem, mm);
> > }
> > }
> > +
> > + return 0;
> > }
> > /**
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #12 from Alex Deucher --- >From what I can see the HDMI 2.0 spec only supports 4k@60 at 8 bpc. I think you need HDMI 2.1 for 4k@60 with 10 bpc or greater. -- 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: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Hi Michal, [Adding Felix as well] Well first of all you have a misconception why at least the AMD graphics driver need to be able to sleep in an MMU notifier: We need to sleep because we need to wait for hardware operations to finish and *NOT* because we need to wait for locks. I'm not sure if your flag now means that you generally can't sleep in MMU notifiers any more, but if that's the case at least AMD hardware will break badly. In our case the approach of waiting for a short time for the process to be reaped and then select another victim actually sounds like the right thing to do. What we also already try to do is to abort hardware operations with the address space when we detect that the process is dying, but that can certainly be improved. Regards, Christian. Am 22.06.2018 um 17:02 schrieb Michal Hocko: From: Michal Hocko There are several blockable mmu notifiers which might sleep in mmu_notifier_invalidate_range_start and that is a problem for the oom_reaper because it needs to guarantee a forward progress so it cannot depend on any sleepable locks. Currently we simply back off and mark an oom victim with blockable mmu notifiers as done after a short sleep. That can result in selecting a new oom victim prematurely because the previous one still hasn't torn its memory down yet. We can do much better though. Even if mmu notifiers use sleepable locks there is no reason to automatically assume those locks are held. Moreover most notifiers only care about a portion of the address space. This patch handles the first part of the problem. __mmu_notifier_invalidate_range_start gets a blockable flag and callbacks are not allowed to sleep if the flag is set to false. This is achieved by using trylock instead of the sleepable lock for most callbacks. I think we can improve that even further because there is a common pattern to do a range lookup first and then do something about that. The first part can be done without a sleeping lock I presume. Anyway, what does the oom_reaper do with all that? We do not have to fail right away. We simply retry if there is at least one notifier which couldn't make any progress. A retry loop is already implemented to wait for the mmap_sem and this is basically the same thing. Cc: "David (ChunMing) Zhou" Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Doug Ledford Cc: Jason Gunthorpe Cc: Mike Marciniszyn Cc: Dennis Dalessandro Cc: Sudeep Dutt Cc: Ashutosh Dixit Cc: Dimitri Sivanich Cc: Boris Ostrovsky Cc: Juergen Gross Cc: "Jérôme Glisse" Cc: Andrea Arcangeli Cc: k...@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)) Cc: linux-ker...@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)) Cc: amd-...@lists.freedesktop.org (open list:RADEON and AMDGPU DRM DRIVERS) Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS) Cc: intel-...@lists.freedesktop.org (open list:INTEL DRM DRIVERS (excluding Poulsbo, Moorestow...) Cc: linux-r...@vger.kernel.org (open list:INFINIBAND SUBSYSTEM) Cc: xen-de...@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE) Cc: linux...@kvack.org (open list:HMM - Heterogeneous Memory Management) Reported-by: David Rientjes Signed-off-by: Michal Hocko --- Hi, this is an RFC and not tested at all. I am not very familiar with the mmu notifiers semantics very much so this is a crude attempt to achieve what I need basically. It might be completely wrong but I would like to discuss what would be a better way if that is the case. get_maintainers gave me quite large list of people to CC so I had to trim it down. If you think I have forgot somebody, please let me know Any feedback is highly appreciated. arch/x86/kvm/x86.c | 7 -- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 33 +++-- drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +--- drivers/gpu/drm/radeon/radeon_mn.c | 15 --- drivers/infiniband/core/umem_odp.c | 15 --- drivers/infiniband/hw/hfi1/mmu_rb.c | 7 -- drivers/misc/mic/scif/scif_dma.c| 7 -- drivers/misc/sgi-gru/grutlbpurge.c | 7 -- drivers/xen/gntdev.c| 14 --- include/linux/kvm_host.h| 2 +- include/linux/mmu_notifier.h| 15 +-- mm/hmm.c| 7 -- mm/mmu_notifier.c | 15 --- mm/oom_kill.c | 29 +++--- virt/kvm/kvm_main.c | 12 ++--- 15 files changed, 137 insertions(+), 58 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6bcecc325e7e..ac08f5d711be 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7203,8 +7203,9 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu) kvm_x86_ops->load_eoi_exitmap(vcpu,
Re: [PATCH 10/10] Revert "drm: crc: Wait for a frame before returning from open()"
On 06/22/2018 02:30 PM, Maarten Lankhorst wrote: Op 22-06-18 om 12:41 schreef Mahesh Kumar: This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680. Don't wait for first CRC during crtc_crc_open. It avoids one frame wait during open. If application want to wait after read call, it can use poll/read blocking read() call. Hi, unfortunately I don't remember why that was deemed undesirable, and I failed to explain so in the commit message. My only comment is that it would be good to make the motivation for this revert explicit, in case someone else in the future wonders. I would also test it in a machine with eDP, IGT should be able to test there. Thanks, Tomeu Suggested-by: Ville Syrjälä Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/drm_debugfs_crc.c | 16 1 file changed, 16 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index 834bc7ee5550..69ec2728727e 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -211,24 +211,8 @@ static int crtc_crc_open(struct inode *inode, struct file *filep) if (ret) goto err; - spin_lock_irq(>lock); - /* -* Only return once we got a first frame, so userspace doesn't have to -* guess when this particular piece of HW will be ready to start -* generating CRCs. -*/ - ret = wait_event_interruptible_lock_irq(crc->wq, - crtc_crc_data_count(crc), - crc->lock); - spin_unlock_irq(>lock); - - if (ret) - goto err_disable; - return 0; -err_disable: - crtc->funcs->set_crc_source(crtc, NULL); err: spin_lock_irq(>lock); crtc_crc_cleanup(crc); Adding Tomeu Vizoso to the cc. Can you resend the series, and add dri-devel@lists.freedesktop.org and the driver maintainers to the cc? You'll need to get acks from the maintainers to merge this through drm-misc. :) ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
From: Michal Hocko
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks. Currently we simply back off and mark an
oom victim with blockable mmu notifiers as done after a short sleep.
That can result in selecting a new oom victim prematurely because the
previous one still hasn't torn its memory down yet.
We can do much better though. Even if mmu notifiers use sleepable locks
there is no reason to automatically assume those locks are held.
Moreover most notifiers only care about a portion of the address
space. This patch handles the first part of the problem.
__mmu_notifier_invalidate_range_start gets a blockable flag and
callbacks are not allowed to sleep if the flag is set to false. This is
achieved by using trylock instead of the sleepable lock for most
callbacks. I think we can improve that even further because there is
a common pattern to do a range lookup first and then do something about
that. The first part can be done without a sleeping lock I presume.
Anyway, what does the oom_reaper do with all that? We do not have to
fail right away. We simply retry if there is at least one notifier which
couldn't make any progress. A retry loop is already implemented to wait
for the mmap_sem and this is basically the same thing.
Cc: "David (ChunMing) Zhou"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Sudeep Dutt
Cc: Ashutosh Dixit
Cc: Dimitri Sivanich
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: "Jérôme Glisse"
Cc: Andrea Arcangeli
Cc: k...@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86))
Cc: linux-ker...@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT AND
64-BIT))
Cc: amd-...@lists.freedesktop.org (open list:RADEON and AMDGPU DRM DRIVERS)
Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS)
Cc: intel-...@lists.freedesktop.org (open list:INTEL DRM DRIVERS (excluding
Poulsbo, Moorestow...)
Cc: linux-r...@vger.kernel.org (open list:INFINIBAND SUBSYSTEM)
Cc: xen-de...@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE)
Cc: linux...@kvack.org (open list:HMM - Heterogeneous Memory Management)
Reported-by: David Rientjes
Signed-off-by: Michal Hocko
---
Hi,
this is an RFC and not tested at all. I am not very familiar with the
mmu notifiers semantics very much so this is a crude attempt to achieve
what I need basically. It might be completely wrong but I would like
to discuss what would be a better way if that is the case.
get_maintainers gave me quite large list of people to CC so I had to trim
it down. If you think I have forgot somebody, please let me know
Any feedback is highly appreciated.
arch/x86/kvm/x86.c | 7 --
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 33 +++--
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +---
drivers/gpu/drm/radeon/radeon_mn.c | 15 ---
drivers/infiniband/core/umem_odp.c | 15 ---
drivers/infiniband/hw/hfi1/mmu_rb.c | 7 --
drivers/misc/mic/scif/scif_dma.c| 7 --
drivers/misc/sgi-gru/grutlbpurge.c | 7 --
drivers/xen/gntdev.c| 14 ---
include/linux/kvm_host.h| 2 +-
include/linux/mmu_notifier.h| 15 +--
mm/hmm.c| 7 --
mm/mmu_notifier.c | 15 ---
mm/oom_kill.c | 29 +++---
virt/kvm/kvm_main.c | 12 ++---
15 files changed, 137 insertions(+), 58 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6bcecc325e7e..ac08f5d711be 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7203,8 +7203,9 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu)
kvm_x86_ops->load_eoi_exitmap(vcpu, eoi_exit_bitmap);
}
-void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
- unsigned long start, unsigned long end)
+int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
+ unsigned long start, unsigned long end,
+ bool blockable)
{
unsigned long apic_address;
@@ -7215,6 +7216,8 @@ void kvm_arch_mmu_notifier_invalidate_range(struct kvm
*kvm,
apic_address = gfn_to_hva(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
if (start <= apic_address && apic_address < end)
kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
+
+ return 0;
}
void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index 83e344fbb50a..d138a526feff 100644
---
Re: [PATCH] drm: Make sure that encoder_type for drm_encoder_init() is in the list
On Fri, Jun 22, 2018 at 10:31:42AM +0200, Daniel Vetter wrote:
> On Thu, Jun 21, 2018 at 05:04:02PM -0600, Jordan Crouse wrote:
> > If a encoder name isn't specified for drm_encoder_init() it will try
> > to construct one based on the incoming encoder_type identifier. If the
> > caller passes an invalid encoder_type value the lookup could walk right
> > past the end of the table.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> > drivers/gpu/drm/drm_encoder.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > index 273e1c59c54a..4cf6c3bb8503 100644
> > --- a/drivers/gpu/drm/drm_encoder.c
> > +++ b/drivers/gpu/drm/drm_encoder.c
> > @@ -128,6 +128,12 @@ int drm_encoder_init(struct drm_device *dev,
> > encoder->name = kvasprintf(GFP_KERNEL, name, ap);
> > va_end(ap);
> > } else {
> > + /* Make sure that the requested encoder type is in the list */
> > + if (encoder_type >= ARRAY_SIZE(drm_encoder_enum_list)) {
>
> I think moving that to the top and wrapping it in a WARN_ON would be even
> better - specifying and invalid encoder type is clearly a driver bug.
> -Daniel
It wasn't immediately clear to me if it was legal to pass a "custom" encoder
type assuming you provided a name for it so I erred on the side of caution.
I would have no problem moving it up to the top and being loud about it.
Jordan
> > + ret = -EINVAL;
> > + goto out_put;
> > + }
> > +
> > encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
> >
> > drm_encoder_enum_list[encoder_type].name,
> > encoder->base.id);
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
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
[PULL] mali-dp: fixes for v4.18-rc3
Hi Dave, A small set of fixes for mali-dp that I should have sent earlier. Many thanks! Liviu The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/malidp-fixes for you to fetch changes up to c6cf387ec56c19028333274747bbb4ae145a2d13: drm/mali-dp: Rectify the width and height passed to rotmem_required() (2018-06-18 18:08:43 +0100) Alison Wang (1): drm: mali-dp: Enable Global SE interrupts mask for DP500 Ayan Kumar Halder (3): drm/arm/malidp: Ensure that the crtcs are shutdown before removing any encoder/connector drm/arm/malidp: Preserve LAYER_FORMAT contents when setting format drm/mali-dp: Rectify the width and height passed to rotmem_required() drivers/gpu/drm/arm/malidp_drv.c| 3 ++- drivers/gpu/drm/arm/malidp_hw.c | 3 ++- drivers/gpu/drm/arm/malidp_planes.c | 9 ++--- 3 files changed, 10 insertions(+), 5 deletions(-) -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107001] hard system freeze with mesa 18.1.1 and 18.1.2 on AMD RX 580
https://bugs.freedesktop.org/show_bug.cgi?id=107001 Michel Dänzer changed: What|Removed |Added Component|Other |Drivers/Gallium/radeonsi QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.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/omap: remove now unused functions
On Fri, Jun 22, 2018 at 6:37 AM, Christian König
wrote:
> Some functions are unused after removal of the kmap_atomic
> DMA-buf interface.
>
> Signed-off-by: Christian König
> Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> index 1a073f9b2834..ec04a69ade46 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> @@ -93,23 +93,6 @@ static int omap_gem_dmabuf_end_cpu_access(struct dma_buf
> *buffer,
> return 0;
> }
>
> -
> -static void *omap_gem_dmabuf_kmap_atomic(struct dma_buf *buffer,
> - unsigned long page_num)
> -{
> - struct drm_gem_object *obj = buffer->priv;
> - struct page **pages;
> - omap_gem_get_pages(obj, , false);
> - omap_gem_cpu_sync_page(obj, page_num);
> - return kmap_atomic(pages[page_num]);
> -}
> -
> -static void omap_gem_dmabuf_kunmap_atomic(struct dma_buf *buffer,
> - unsigned long page_num, void *addr)
> -{
> - kunmap_atomic(addr);
> -}
> -
> static void *omap_gem_dmabuf_kmap(struct dma_buf *buffer,
> unsigned long page_num)
> {
> --
> 2.14.1
>
> ___
> 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 106879] Ugly bug present in kernels 4.14, 4.15, 4.16, 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106879 --- Comment #5 from Alex Deucher --- Is this a regression? If so, can you bisect? Does setting amdgpu.runpm=0 on the kernel commandline in grub help? -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #11 from Mike Lothian --- It might be the same, the EDID says the TV is capable of both 10bit and 12bit colour, I was under the impression that HDMI 2 was able to do 2160p@60Hz at those colour depths -- 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 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
v2: reordered
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 9 ++---
include/linux/dma-buf.h | 4
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index dc94e76e2e2a..49f23b791eb8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -665,7 +665,9 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
- sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ sg_table = dma_buf_map_attachment_locked(attach, direction);
+ reservation_object_unlock(attach->dmabuf->resv);
if (!sg_table)
sg_table = ERR_PTR(-ENOMEM);
@@ -715,8 +717,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
- attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
- direction);
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ dma_buf_unmap_attachment_locked(attach, sg_table, direction);
+ reservation_object_unlock(attach->dmabuf->resv);
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a25e754ae2f7..024658d1f22e 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -118,6 +118,8 @@ struct dma_buf_ops {
* any other kind of sharing that the exporter might wish to make
* available to buffer-users.
*
+* This is called with the dmabuf->resv object locked.
+*
* Returns:
*
* A _table scatter list of or the backing storage of the DMA buffer,
@@ -138,6 +140,8 @@ struct dma_buf_ops {
* It should also unpin the backing storage if this is the last mapping
* of the DMA buffer, it the exporter supports backing storage
* migration.
+*
+* This is called with the dmabuf->resv object locked.
*/
void (*unmap_dma_buf)(struct dma_buf_attachment *,
struct sg_table *,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amdgpu: add independent DMA-buf import v4
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface
v4: split out from unpinned DMA-buf work
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 38 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 34 +++
4 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 5e71af8dd3a7..391c171f814e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -373,10 +373,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg);
struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gobj,
int flags);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index cdf0be85d361..ad0a8b3f90b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -919,7 +919,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
- .gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 038a8c8488b7..5cc4c09d720e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -122,31 +122,28 @@ int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma
}
/**
- * amdgpu_gem_prime_import_sg_table - _driver.gem_prime_import_sg_table
- * implementation
+ * amdgpu_gem_prime_create_obj - create BO for DMA-buf import
+ *
* @dev: DRM device
- * @attach: DMA-buf attachment
- * @sg: Scatter/gather table
+ * @dma_buf: DMA-buf
*
- * Import shared DMA buffer memory exported by another device.
+ * Creates an empty SG BO for DMA-buf import.
*
* Returns:
* A new GEM buffer object of the given DRM device, representing the memory
* described by the given DMA-buf attachment and scatter/gather table.
*/
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg)
+static struct drm_gem_object *
+amdgpu_gem_prime_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
{
- struct reservation_object *resv = attach->dmabuf->resv;
+ struct reservation_object *resv = dma_buf->resv;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_bo *bo;
struct amdgpu_bo_param bp;
int ret;
memset(, 0, sizeof(bp));
- bp.size = attach->dmabuf->size;
+ bp.size = dma_buf->size;
bp.byte_align = PAGE_SIZE;
bp.domain = AMDGPU_GEM_DOMAIN_CPU;
bp.flags = 0;
@@ -157,11 +154,9 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
if (ret)
goto error;
- bo->tbo.sg = sg;
- bo->tbo.ttm->sg = sg;
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
- if (attach->dmabuf->ops != _dmabuf_ops)
+ if (dma_buf->ops != _dmabuf_ops)
bo->prime_shared_count = 1;
ww_mutex_unlock(>lock);
@@ -376,6 +371,7 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device
*dev,
struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
{
+ struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
if (dma_buf->ops == _dmabuf_ops) {
@@ -390,5 +386,17 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
}
}
- return drm_gem_prime_import(dev, dma_buf);
+ obj = amdgpu_gem_prime_create_obj(dev, dma_buf);
+ if (IS_ERR(obj))
+ return
[PATCH 3/4] drm/amdgpu: add independent DMA-buf export v3
The caching of SGT's done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 94 +--
3 files changed, 39 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d8e0cc08f9db..5e71af8dd3a7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -373,7 +373,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *
amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a549483032b0..cdf0be85d361 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -919,7 +919,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
- .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index b2286bc41aec..038a8c8488b7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -40,22 +40,6 @@
static const struct dma_buf_ops amdgpu_dmabuf_ops;
-/**
- * amdgpu_gem_prime_get_sg_table - _driver.gem_prime_get_sg_table
- * implementation
- * @obj: GEM buffer object
- *
- * Returns:
- * A scatter/gather table for the pinned pages of the buffer object's memory.
- */
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int npages = bo->tbo.num_pages;
-
- return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
/**
* amdgpu_gem_prime_vmap - _buf_ops.vmap implementation
* @obj: GEM buffer object
@@ -189,35 +173,29 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
}
/**
- * amdgpu_gem_map_attach - _buf_ops.attach implementation
- * @dma_buf: shared DMA buffer
- * @target_dev: target device
+ * amdgpu_gem_map_dma_buf - _buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
+ * @dir: DMA direction
*
* Makes sure that the shared DMA buffer can be accessed by the target device.
* For now, simply pins it to the GTT domain, where it should be accessible by
* all DMA devices.
*
* Returns:
- * 0 on success or negative error code.
+ * sg_table filled with the DMA addresses to use or ERR_PRT with negative error
+ * code.
*/
-static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
-struct dma_buf_attachment *attach)
+static struct sg_table *
+amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
{
+ struct dma_buf *dma_buf = attach->dmabuf;
struct drm_gem_object *obj = dma_buf->priv;
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct sg_table *sgt;
long r;
- r = drm_gem_map_attach(dma_buf, attach);
- if (r)
- return r;
-
- r = amdgpu_bo_reserve(bo, false);
- if (unlikely(r != 0))
- goto error_detach;
-
-
if (attach->dev->driver != adev->dev->driver) {
/*
* Wait for all shared fences to complete before we switch to
future
@@ -228,54 +206,62 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
MAX_SCHEDULE_TIMEOUT);
if (unlikely(r < 0)) {
DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
- goto error_unreserve;
+ return ERR_PTR(r);
}
}
/* pin buffer into GTT */
r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
if (r)
- goto error_unreserve;
+
[PATCH 1/4] dma-buf: add dma_buf_(un)map_attachment_locked variants v2
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 57 +++
include/linux/dma-buf.h | 5 +
2 files changed, 62 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 852a3928ee71..dc94e76e2e2a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -606,6 +606,40 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
}
EXPORT_SYMBOL_GPL(dma_buf_detach);
+/**
+ * dma_buf_map_attachment_locked - Maps the buffer into _device_ address space
+ * with the reservation lock held. Is a wrapper for map_dma_buf() of the
+ *
+ * Returns the scatterlist table of the attachment;
+ * dma_buf_ops.
+ * @attach:[in]attachment whose scatterlist is to be returned
+ * @direction: [in]direction of DMA transfer
+ *
+ * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
+ * on error. May return -EINTR if it is interrupted by a signal.
+ *
+ * A mapping must be unmapped by using dma_buf_unmap_attachment_locked(). Note
+ * that the underlying backing storage is pinned for as long as a mapping
+ * exists, therefore users/importers should not hold onto a mapping for undue
+ * amounts of time.
+ */
+struct sg_table *
+dma_buf_map_attachment_locked(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction)
+{
+ struct sg_table *sg_table;
+
+ might_sleep();
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
+
+ return sg_table;
+}
+EXPORT_SYMBOL_GPL(dma_buf_map_attachment_locked);
+
/**
* dma_buf_map_attachment - Returns the scatterlist table of the attachment;
* mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
@@ -639,6 +673,29 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
+/**
+ * dma_buf_unmap_attachment_locked - unmaps the buffer with reservation lock
+ * held, should deallocate the associated scatterlist. Is a wrapper for
+ * unmap_dma_buf() of dma_buf_ops.
+ * @attach:[in]attachment to unmap buffer from
+ * @sg_table: [in]scatterlist info of the buffer to unmap
+ * @direction: [in]direction of DMA transfer
+ *
+ * This unmaps a DMA mapping for @attached obtained by
+ * dma_buf_map_attachment_locked().
+ */
+void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *attach,
+struct sg_table *sg_table,
+enum dma_data_direction direction)
+{
+ might_sleep();
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
+ direction);
+}
+EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
+
/**
* dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might
* deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 991787a03199..a25e754ae2f7 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -384,8 +384,13 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
struct dma_buf *dma_buf_get(int fd);
void dma_buf_put(struct dma_buf *dmabuf);
+struct sg_table *dma_buf_map_attachment_locked(struct dma_buf_attachment *,
+ enum dma_data_direction);
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
enum dma_data_direction);
+void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *,
+struct sg_table *,
+enum dma_data_direction);
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
enum dma_data_direction);
int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
First step towards unpinned DMA-buf operation.
[As requested by Daniel cross posting to intel-gfx as well]. This set is the first step towards allowing to use a DMA-buf without actually pinning the underlying resources. This in turn the the ground work for PCIe P2P operations as well as quite a bunch of other use cases. The idea is that we build the support for unpinned operation around the already present reservation lock in the DMA-buf object. For this we now grab the reservation object lock while mapping and unmapping DMA-bufs. The down side is that all implementations as well as users of DMA-buf needs to be audited to make sure that we don't run into double locking or lock inversions. So please test and/or comment and report back how badly lockdep complains :) Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] dma-buf/fence: Take refcount on the module that owns the fence
Each fence object holds function pointers of the module that initialized
it. Allowing the module to unload before this fence's release is
catastrophic. So, keep a refcount on the module until the fence is
released.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- added description for the new function parameter.
drivers/dma-buf/dma-fence.c | 16 +---
include/linux/dma-fence.h | 10 --
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 4edb9fd..2aaa44e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -18,6 +18,7 @@
* more details.
*/
+#include
#include
#include
#include
@@ -168,6 +169,7 @@ void dma_fence_release(struct kref *kref)
{
struct dma_fence *fence =
container_of(kref, struct dma_fence, refcount);
+ struct module *module = fence->owner;
trace_dma_fence_destroy(fence);
@@ -178,6 +180,8 @@ void dma_fence_release(struct kref *kref)
fence->ops->release(fence);
else
dma_fence_free(fence);
+
+ module_put(module);
}
EXPORT_SYMBOL(dma_fence_release);
@@ -541,6 +545,7 @@ struct default_wait_cb {
/**
* dma_fence_init - Initialize a custom fence.
+ * @module:[in]the module that calls this API
* @fence: [in]the fence to initialize
* @ops: [in]the dma_fence_ops for operations on this fence
* @lock: [in]the irqsafe spinlock to use for locking this fence
@@ -556,8 +561,9 @@ struct default_wait_cb {
* to check which fence is later by simply using dma_fence_later.
*/
void
-dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
- spinlock_t *lock, u64 context, unsigned seqno)
+_dma_fence_init(struct module *module, struct dma_fence *fence,
+ const struct dma_fence_ops *ops, spinlock_t *lock,
+ u64 context, unsigned seqno)
{
BUG_ON(!lock);
BUG_ON(!ops || !ops->wait || !ops->enable_signaling ||
@@ -571,7 +577,11 @@ struct default_wait_cb {
fence->seqno = seqno;
fence->flags = 0UL;
fence->error = 0;
+ fence->owner = module;
+
+ if (!try_module_get(module))
+ fence->owner = NULL;
trace_dma_fence_init(fence);
}
-EXPORT_SYMBOL(dma_fence_init);
+EXPORT_SYMBOL(_dma_fence_init);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index eb9b05a..8159125 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -36,6 +36,8 @@
/**
* struct dma_fence - software synchronization primitive
+ * @owner: the module that contains fence_ops functions.
+ *Usually THIS_MODULE.
* @refcount: refcount for this fence
* @ops: dma_fence_ops associated with this fence
* @rcu: used for releasing fence with kfree_rcu
@@ -71,6 +73,7 @@
* been completed, or never called at all.
*/
struct dma_fence {
+ struct module *owner;
struct kref refcount;
const struct dma_fence_ops *ops;
struct rcu_head rcu;
@@ -249,8 +252,11 @@ struct dma_fence_ops {
char *str, int size);
};
-void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
- spinlock_t *lock, u64 context, unsigned seqno);
+#define dma_fence_init(fence, ops, lock, context, seqno) _dma_fence_init( \
+ THIS_MODULE, fence, ops, lock, context, seqno)
+void _dma_fence_init(struct module *module, struct dma_fence *fence,
+ const struct dma_fence_ops *ops, spinlock_t *lock, u64 context,
+ unsigned seqno);
void dma_fence_release(struct kref *kref);
void dma_fence_free(struct dma_fence *fence);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Hi Ard, On 6/22/2018 7:21 AM, Ard Biesheuvel wrote: > Apologies for only bringing this up now, but I think this patch is > wrong after all. > > screen_info.lfb_base is supposed to be a CPU address, and so > translating it like this is wrong. If you end up with a PCI address > here, you have made a mistake in hacking support for PCI outbound > translations into UEFI. Other users such as UEFI itself or GRUB will > treat this as a CPU physical address as well, so the kernel should not > treat it any differently. The behavior I'm seeing is from a UEFI BIOS vendor. I did not write the code for it... I was asked to debug it. I'd like to dive into your statement about UEFI and GRUB using this address as physical addresses. AFAIK, all PCI outbound requests go through PCI IO protocol in UEFI and the translation information is hidden inside the UEFI PCI Host Bridge driver. Drivers are not allowed to access PCI resources directly especially as a memory mapped address. This particular vendor is programming the BAR address into the GOP protocol. Since the host bridge driver is doing a translation, we are hitting this issue. Is there a UEFI spec reference about the definition of this field? Sinan -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the 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 V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 13 June 2018 at 18:08, Bartlomiej Zolnierkiewicz wrote: > On Wednesday, June 13, 2018 05:45:48 PM Ard Biesheuvel wrote: >> On 18 May 2018 at 16:17, Sinan Kaya wrote: >> > A host bridge is allowed to remap BAR addresses using _TRA attribute in >> > _CRS windows. >> > >> > pci_bus :00: root bus resource [mem 0x8010010-0x8011fff >> > window] (bus address [0x0010-0x1fff]) >> > pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] >> > >> > When a VGA device is behind such a host bridge and the resource is >> > translated efifb driver is trying to do ioremap against bus address >> > rather than the resource address and is failing to probe. >> > >> > efifb: probing for efifb >> > efifb: cannot reserve video memory at 0x1e00 >> > efifb: framebuffer at 0x1e00, using 1920k, total 1875k >> > efifb: mode is 800x600x32, linelength=3200, pages=1 >> > efifb: scrolling: redraw >> > efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 >> > >> > Use the host bridge offset information to convert bus address to >> > resource address in the fixup. >> > >> > Signed-off-by: Sinan Kaya >> >> Reviewed-by: Ard Biesheuvel >> >> Bartlomiej, could you please take these via the fbdev tree for v4.19? > > Sure, I will queue it after the current merge window. > >> Peter already gave his ack but Sinan dropped it (presumably because of >> the split in v2) > > Peter, can I (re)add your ACK to V2 patches? > Actually, it would be better if we could take this through the EFI tree instead, with your ack. Would you mind? There are some other efifb changes coming up, some of which depend on core EFI changes, and taking these through different trees is going to be more trouble than it's worth. https://marc.info/?l=linux-efi=152929425329015=2 from Hans, and the series [PATCH v2 0/2] efi: add support for cacheable efifb mappings that I just cc'ed you on a minute ago. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 20 June 2018 at 00:29, Bjorn Helgaas wrote:
> Minor subject nit: From the caller's point of view, we must convert a bus
> address to a resource *always* (the caller has no knowledge of "whether it
> is translated by the host bridge").
>
> On Fri, May 18, 2018 at 10:17:51AM -0400, Sinan Kaya wrote:
>> A host bridge is allowed to remap BAR addresses using _TRA attribute in
>> _CRS windows.
>
> Also, _TRA/_CRS are ACPI-specific terms and non-ACPI host bridges can
> also do the same sort of translation. Another trivial nit.
>
>> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
>> (bus address [0x0010-0x1fff])
>> pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
>>
>> When a VGA device is behind such a host bridge and the resource is
>> translated efifb driver is trying to do ioremap against bus address
>> rather than the resource address and is failing to probe.
>>
>> efifb: probing for efifb
>> efifb: cannot reserve video memory at 0x1e00
>> efifb: framebuffer at 0x1e00, using 1920k, total 1875k
>> efifb: mode is 800x600x32, linelength=3200, pages=1
>> efifb: scrolling: redraw
>> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
>>
>> Use the host bridge offset information to convert bus address to
>> resource address in the fixup.
>>
>> Signed-off-by: Sinan Kaya
>
> Reviewed-by: Bjorn Helgaas
>
> Thanks a lot for fixing this!
>
Apologies for only bringing this up now, but I think this patch is
wrong after all.
screen_info.lfb_base is supposed to be a CPU address, and so
translating it like this is wrong. If you end up with a PCI address
here, you have made a mistake in hacking support for PCI outbound
translations into UEFI. Other users such as UEFI itself or GRUB will
treat this as a CPU physical address as well, so the kernel should not
treat it any differently.
>> ---
>> drivers/video/fbdev/efifb.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
>> index 6daac8d..429cc85 100644
>> --- a/drivers/video/fbdev/efifb.c
>> +++ b/drivers/video/fbdev/efifb.c
>> @@ -431,6 +431,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
>> .end = screen_info.lfb_base + screen_info.lfb_size - 1,
>> .flags = IORESOURCE_MEM,
>> };
>> + struct pci_bus_region region;
>> int i;
>>
>> if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
>> @@ -442,6 +443,10 @@ static void efifb_fixup_resources(struct pci_dev *dev)
>> if (!screen_res.start)
>> return;
>>
>> + region.start = screen_res.start;
>> + region.end = screen_res.end;
>> + pcibios_bus_to_resource(dev->bus, _res, );
>> +
>> for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
>> struct resource *res = >resource[i];
>>
>> --
>> 2.7.4
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dma-buf/fence: Take refcount on the module that owns the fence
On 6/22/2018 3:38 PM, Chris Wilson wrote:
Quoting Gustavo Padovan (2018-06-22 11:04:16)
Hi Akhil,
On Fri, 2018-06-22 at 15:10 +0530, Akhil P Oommen wrote:
Each fence object holds function pointers of the module that
initialized
it. Allowing the module to unload before this fence's release is
catastrophic. So, keep a refcount on the module until the fence is
released.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- added description for the new function parameter.
drivers/dma-buf/dma-fence.c | 16 +---
include/linux/dma-fence.h | 10 --
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-
fence.c
index 4edb9fd..2aaa44e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -18,6 +18,7 @@
* more details.
*/
+#include
#include
#include
#include
@@ -168,6 +169,7 @@ void dma_fence_release(struct kref *kref)
{
struct dma_fence *fence =
container_of(kref, struct dma_fence, refcount);
+ struct module *module = fence->owner;
trace_dma_fence_destroy(fence);
@@ -178,6 +180,8 @@ void dma_fence_release(struct kref *kref)
fence->ops->release(fence);
else
dma_fence_free(fence);
+
+ module_put(module);
}
EXPORT_SYMBOL(dma_fence_release);
@@ -541,6 +545,7 @@ struct default_wait_cb {
/**
* dma_fence_init - Initialize a custom fence.
+ * @module: [in]the module that calls this API
* @fence: [in]the fence to initialize
* @ops: [in]the dma_fence_ops for operations on this
fence
* @lock:[in]the irqsafe spinlock to use for locking
this fence
@@ -556,8 +561,9 @@ struct default_wait_cb {
* to check which fence is later by simply using dma_fence_later.
*/
void
-dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops
*ops,
-spinlock_t *lock, u64 context, unsigned seqno)
+_dma_fence_init(struct module *module, struct dma_fence *fence,
+ const struct dma_fence_ops *ops, spinlock_t *lock,
+ u64 context, unsigned seqno)
{
BUG_ON(!lock);
BUG_ON(!ops || !ops->wait || !ops->enable_signaling ||
@@ -571,7 +577,11 @@ struct default_wait_cb {
fence->seqno = seqno;
fence->flags = 0UL;
fence->error = 0;
+ fence->owner = module;
+
+ if (!try_module_get(module))
+ fence->owner = NULL;
trace_dma_fence_init(fence);
}
-EXPORT_SYMBOL(dma_fence_init);
+EXPORT_SYMBOL(_dma_fence_init);
Do we still need to export the symbol, it won't be called from outside
anymore? Other than that looks good to me:
Yes. Because dma_fence_init() is now a macro that resolves to
_dma_fence_init().
There's a big drawback in that a module reference is often insufficient,
and that a reference on the driver (or whatever is required for the
lifetime of the fence) will already hold the module reference.
I didn't quite understand what you meant here. Could you please elaborate?
Considering that we want a few 100k fences in flight per second, is
there no other way to only export a fence with a module reference?
-Chris
Thanks,
Akhil.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
Hi Thierry,
> This commit adds support for KOE's 5.7" display.
>
> Signed-off-by: Lukasz Majewski
> Reviewed-by: Rob Herring
> ---
> Changes for v2:
> - Add Reviewed-by tag
Could you apply this patch to your tree?
Thanks in advance,
Łukasz
>
> ---
> .../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42
> ++
> drivers/gpu/drm/panel/panel-simple.c | 26
> ++ 2 files changed, 68 insertions(+) create mode 100644
> Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> new file mode 100644 index ..be7ac666807b --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> @@ -0,0 +1,42 @@ +Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x
> 240) TFT LCD panel +
> +Required properties:
> +- compatible: should be "koe,tx14d24vm1bpa"
> +- backlight: phandle of the backlight device attached to the panel
> +- power-supply: single regulator to provide the supply voltage
> +
> +Required nodes:
> +- port: Parallel port mapping to connect this display
> +
> +This panel needs single power supply voltage. Its backlight is
> conntrolled +via PWM signal.
> +
> +Example:
> +
> +
> +Example device-tree definition when connected to iMX53 based board
> +
> + lcd_panel: lcd-panel {
> + compatible = "koe,tx14d24vm1bpa";
> + backlight = <_lcd>;
> + power-supply = <_3v3>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <_display_out>;
> + };
> + };
> + };
> +
> +Then one needs to extend the dispX node:
> +
> + lcd_display: disp1 {
> +
> + port@1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <_panel_in>;
> + };
> + };
> + };
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c index
> d9984bdb5bb5..103b43ce7dee 100644 ---
> a/drivers/gpu/drm/panel/panel-simple.c +++
> b/drivers/gpu/drm/panel/panel-simple.c @@ -1268,6 +1268,29 @@ static
> const struct panel_desc innolux_zj070na_01p = { },
> };
>
> +static const struct display_timing koe_tx14d24vm1bpa_timing = {
> + .pixelclock = { 558, 585, 620 },
> + .hactive = { 320, 320, 320 },
> + .hfront_porch = { 30, 30, 30 },
> + .hback_porch = { 30, 30, 30 },
> + .hsync_len = { 1, 5, 17 },
> + .vactive = { 240, 240, 240 },
> + .vfront_porch = { 6, 6, 6 },
> + .vback_porch = { 5, 5, 5 },
> + .vsync_len = { 1, 2, 11 },
> + .flags = DISPLAY_FLAGS_DE_HIGH,
> +};
> +
> +static const struct panel_desc koe_tx14d24vm1bpa = {
> + .timings = _tx14d24vm1bpa_timing,
> + .num_timings = 1,
> + .bpc = 6,
> + .size = {
> + .width = 115,
> + .height = 86,
> + },
> +};
> +
> static const struct display_timing koe_tx31d200vm0baa_timing = {
> .pixelclock = { 3960, 4320, 4800 },
> .hactive = { 1280, 1280, 1280 },
> @@ -2204,6 +2227,9 @@ static const struct of_device_id
> platform_of_match[] = { .compatible = "innolux,zj070na-01p",
> .data = _zj070na_01p,
> }, {
> + .compatible = "koe,tx14d24vm1bpa",
> + .data = _tx14d24vm1bpa,
> + }, {
> .compatible = "koe,tx31d200vm0baa",
> .data = _tx31d200vm0baa,
> }, {
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
pgp1ldU9Q9qBq.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 22 June 2018 at 15:52, Sinan Kaya wrote: > Hi Ard, > > On 6/22/2018 7:21 AM, Ard Biesheuvel wrote: >> Apologies for only bringing this up now, but I think this patch is >> wrong after all. >> >> screen_info.lfb_base is supposed to be a CPU address, and so >> translating it like this is wrong. If you end up with a PCI address >> here, you have made a mistake in hacking support for PCI outbound >> translations into UEFI. Other users such as UEFI itself or GRUB will >> treat this as a CPU physical address as well, so the kernel should not >> treat it any differently. > > The behavior I'm seeing is from a UEFI BIOS vendor. I did not write the > code for it... > > I was asked to debug it. > > I'd like to dive into your statement about UEFI and GRUB using this address > as physical addresses. > > AFAIK, all PCI outbound requests go through PCI IO protocol in UEFI and the > translation information is hidden inside the UEFI PCI Host Bridge driver. > Drivers are not allowed to access PCI resources directly especially as a > memory mapped address. > > This particular vendor is programming the BAR address into the GOP protocol. > Since the host bridge driver is doing a translation, we are hitting this > issue. > > Is there a UEFI spec reference about the definition of this field? > Yes, it is part of the PCI I/O protocol definition. FrameBufferBase is described as """ Base address of graphics linear frame buffer. Info contains information required to allow software to draw directly to the frame buffer without using Blt().Offset zero in FrameBufferBase represents the upper left pixel of the display. """ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 Michel Dänzer changed: What|Removed |Added CC||harry.wentl...@amd.com, ||mikita.lip...@amd.com --- Comment #10 from Michel Dänzer --- Is this different from bug 106959? -- 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: [DPU PATCH 09/11] drm/msm/dpu: Remove unused code and move the header
On Wed, May 30, 2018 at 10:50 AM Rajesh Yadav wrote:
>
> From: Jordan Crouse
>
> Remove unused code from dpu_io_util.c. The functions are only
> used inside of the msm driver so remove the EXPORT_SYMBOL
> tags and move the header dpu_io_util.h from include/linux.
>
> Signed-off-by: Jordan Crouse
> [rya...@codeaurora.org: rebased and removed some extra unused code]
> Signed-off-by: Rajesh Yadav
Hi Rajesh and Jordan,
I'm backporting this series for testing, and have found that the
mdss-pll driver uses both dpu_io_util and a bunch of functions/struct
members removed in this patchset. Do we anticipate having to add those
back for mdss-pll?
Sean
> ---
> drivers/gpu/drm/msm/dpu_io_util.c | 380
> +-
> drivers/gpu/drm/msm/dpu_io_util.h | 61 ++
> drivers/gpu/drm/msm/msm_drv.h | 1 -
> include/linux/dpu_io_util.h | 115
> 4 files changed, 66 insertions(+), 491 deletions(-)
> create mode 100644 drivers/gpu/drm/msm/dpu_io_util.h
> delete mode 100644 include/linux/dpu_io_util.h
>
> diff --git a/drivers/gpu/drm/msm/dpu_io_util.c
> b/drivers/gpu/drm/msm/dpu_io_util.c
> index ecc297c..f7caec3 100644
> --- a/drivers/gpu/drm/msm/dpu_io_util.c
> +++ b/drivers/gpu/drm/msm/dpu_io_util.c
> @@ -13,318 +13,9 @@
>
> #include
> #include
> -#include
> -#include
> #include
> -#include
>
> -#define MAX_I2C_CMDS 16
> -void dss_reg_w(struct dss_io_data *io, u32 offset, u32 value, u32 debug)
> -{
> - u32 in_val;
> -
> - if (!io || !io->base) {
> - DEV_ERR("%pS->%s: invalid input\n",
> - __builtin_return_address(0), __func__);
> - return;
> - }
> -
> - if (offset > io->len) {
> - DEV_ERR("%pS->%s: offset out of range\n",
> - __builtin_return_address(0), __func__);
> - return;
> - }
> -
> - writel_relaxed(value, io->base + offset);
> - if (debug) {
> - in_val = readl_relaxed(io->base + offset);
> - DEV_DBG("[%08x] => %08x [%08x]\n",
> - (u32)(unsigned long)(io->base + offset),
> - value, in_val);
> - }
> -} /* dss_reg_w */
> -EXPORT_SYMBOL(dss_reg_w);
> -
> -u32 dss_reg_r(struct dss_io_data *io, u32 offset, u32 debug)
> -{
> - u32 value;
> -
> - if (!io || !io->base) {
> - DEV_ERR("%pS->%s: invalid input\n",
> - __builtin_return_address(0), __func__);
> - return -EINVAL;
> - }
> -
> - if (offset > io->len) {
> - DEV_ERR("%pS->%s: offset out of range\n",
> - __builtin_return_address(0), __func__);
> - return -EINVAL;
> - }
> -
> - value = readl_relaxed(io->base + offset);
> - if (debug)
> - DEV_DBG("[%08x] <= %08x\n",
> - (u32)(unsigned long)(io->base + offset), value);
> -
> - return value;
> -} /* dss_reg_r */
> -EXPORT_SYMBOL(dss_reg_r);
> -
> -void dss_reg_dump(void __iomem *base, u32 length, const char *prefix,
> - u32 debug)
> -{
> - if (debug)
> - print_hex_dump(KERN_INFO, prefix, DUMP_PREFIX_OFFSET, 32, 4,
> - (void *)base, length, false);
> -} /* dss_reg_dump */
> -EXPORT_SYMBOL(dss_reg_dump);
> -
> -static struct resource *msm_dss_get_res_byname(struct platform_device *pdev,
> - unsigned int type, const char *name)
> -{
> - struct resource *res = NULL;
> -
> - res = platform_get_resource_byname(pdev, type, name);
> - if (!res)
> - DEV_ERR("%s: '%s' resource not found\n", __func__, name);
> -
> - return res;
> -} /* msm_dss_get_res_byname */
> -EXPORT_SYMBOL(msm_dss_get_res_byname);
> -
> -int msm_dss_ioremap_byname(struct platform_device *pdev,
> - struct dss_io_data *io_data, const char *name)
> -{
> - struct resource *res = NULL;
> -
> - if (!pdev || !io_data) {
> - DEV_ERR("%pS->%s: invalid input\n",
> - __builtin_return_address(0), __func__);
> - return -EINVAL;
> - }
> -
> - res = msm_dss_get_res_byname(pdev, IORESOURCE_MEM, name);
> - if (!res) {
> - DEV_ERR("%pS->%s: '%s' msm_dss_get_res_byname failed\n",
> - __builtin_return_address(0), __func__, name);
> - return -ENODEV;
> - }
> -
> - io_data->len = (u32)resource_size(res);
> - io_data->base = ioremap(res->start, io_data->len);
> - if (!io_data->base) {
> - DEV_ERR("%pS->%s: '%s' ioremap failed\n",
> - __builtin_return_address(0), __func__, name);
> - return -EIO;
> - }
> -
> - return 0;
> -} /* msm_dss_ioremap_byname */
> -EXPORT_SYMBOL(msm_dss_ioremap_byname);
> -
> -void msm_dss_iounmap(struct dss_io_data *io_data)
> -{
> - if (!io_data) {
> -
Re: [PATCH 5/5] drm/amdgpu: add independent DMA-buf export v3
Am 18.06.2018 um 10:28 schrieb Daniel Vetter:
On Fri, Jun 01, 2018 at 02:00:20PM +0200, Christian König wrote:
The caching of SGT's done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
Hm, why is it harmful? We've done it because it's expensive, and people
started screaming about the overhead ... hence the caching.
It's a bad idea because it artificially extends the lifetime of the
mapping, which is exactly what we want to avoid when we create the
mappings dynamically and only as long as necessary.
And actually checking the mail history I could only find indicators that
people thought it would help. I haven't found any evidence that anybody
actually checked if that helps or not.
Doing an amdgpu copypasta seems like working around issues in shared code.
Completely agree, but I don't want to push that policy to everybody just
yet.
When we find that this is really the right direction I can convert
Radeon as well, move more component functionality logic into common code
and when that's done rip out this middle layer because it just becomes
superfluous.
Christian.
-Daniel
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 73 ++-
3 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 2d7500921c0b..93dc57d74fc2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -373,7 +373,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *
amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index b0bf2f24da48..270b8ad927ea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -907,7 +907,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
- .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index a156b3891a3f..0c5a75b06648 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -32,14 +32,6 @@
static const struct dma_buf_ops amdgpu_dmabuf_ops;
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int npages = bo->tbo.num_pages;
-
- return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
{
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
@@ -132,23 +124,17 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
}
-static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
-struct dma_buf_attachment *attach)
+static struct sg_table *
+amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
{
+ struct dma_buf *dma_buf = attach->dmabuf;
struct drm_gem_object *obj = dma_buf->priv;
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct sg_table *sgt;
long r;
- r = drm_gem_map_attach(dma_buf, attach);
- if (r)
- return r;
-
- r = amdgpu_bo_reserve(bo, false);
- if (unlikely(r != 0))
- goto error_detach;
-
-
if (attach->dev->driver != adev->dev->driver) {
/*
* Wait for all shared fences to complete before we switch to
future
@@ -159,46 +145,53 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
MAX_SCHEDULE_TIMEOUT);
if (unlikely(r < 0)) {
DRM_DEBUG_PRIME("Fence wait failed:
Re: [PATCH 10/10] Revert "drm: crc: Wait for a frame before returning from open()"
Op 22-06-18 om 12:41 schreef Mahesh Kumar: > This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680. > > Don't wait for first CRC during crtc_crc_open. It avoids one frame wait > during open. If application want to wait after read call, it can use > poll/read blocking read() call. > > Suggested-by: Ville Syrjälä > Signed-off-by: Mahesh Kumar > --- > drivers/gpu/drm/drm_debugfs_crc.c | 16 > 1 file changed, 16 deletions(-) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c > index 834bc7ee5550..69ec2728727e 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -211,24 +211,8 @@ static int crtc_crc_open(struct inode *inode, struct > file *filep) > if (ret) > goto err; > > - spin_lock_irq(>lock); > - /* > - * Only return once we got a first frame, so userspace doesn't have to > - * guess when this particular piece of HW will be ready to start > - * generating CRCs. > - */ > - ret = wait_event_interruptible_lock_irq(crc->wq, > - crtc_crc_data_count(crc), > - crc->lock); > - spin_unlock_irq(>lock); > - > - if (ret) > - goto err_disable; > - > return 0; > > -err_disable: > - crtc->funcs->set_crc_source(crtc, NULL); > err: > spin_lock_irq(>lock); > crtc_crc_cleanup(crc); Adding Tomeu Vizoso to the cc. Can you resend the series, and add dri-devel@lists.freedesktop.org and the driver maintainers to the cc? You'll need to get acks from the maintainers to merge this through drm-misc. :) ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #9 from Mike Lothian --- I have a feeling that Kwin was trying to modeset back to 60Hz which was causing Xorg to crash and the error to appear in the dmesg I'll post the Xorg.0.logs if I manage to reproduce the issue -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #8 from Mike Lothian --- Created attachment 140278 --> https://bugs.freedesktop.org/attachment.cgi?id=140278=edit Xorg.0.log with modesetting -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #7 from Mike Lothian --- Xrandr now with modesetting xrandr Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384 HDMI-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 1872mm x 1053mm 4096x2160 30.0025.0024.0024.0029.9723.98 3840x2160 59.9730.00* 30.0025.0025.0024.0024.00 29.9723.98 3200x1800 59.9659.94 2880x1620 59.9659.97 2560x1600 59.9959.97 2560x1440 59.9959.9659.95 2048x1536 75.0060.00 1920x1440 75.0060.00 1856x1392 75.0060.01 1792x1344 75.0060.01 2048x1152 59.9959.9859.9059.91 1920x1200 59.8859.95 1920x1080 60.0159.9759.9660.0060.0050.0059.94 59.9330.0025.0024.0029.9723.98 1600x1200 75.0070.0065.0060.00 1680x1050 59.9559.88 1400x1050 74.7659.98 1600x900 59.9959.9459.9560.0059.82 1280x1024 75.0260.02 1440x900 59.90 1400x900 59.9659.88 1280x960 60.00 1440x810 60.0059.97 1368x768 59.8859.85 1366x768 59.79 1280x800 59.9959.9759.8159.91 1152x864 75.00 1280x720 60.0059.9959.8660.0060.0050.0059.94 59.74 1024x768 75.0560.0475.0370.0760.00 960x720 75.0060.00 928x696 75.0060.05 896x672 75.0560.01 1024x576 59.9559.9659.9059.82 960x600 59.9360.00 832x624 74.55 960x540 59.9659.9959.6359.82 800x600 75.0070.0065.0060.0072.1975.0060.32 56.25 840x525 60.0159.88 864x486 59.9259.57 720x576 50.00 700x525 74.7659.98 800x450 59.9559.82 720x480 60.0059.94 640x512 75.0260.02 700x450 59.9659.88 640x480 60.0075.0072.8175.0066.6760.0059.94 720x405 59.5158.99 720x400 70.08 684x384 59.8859.85 640x400 59.8859.98 576x432 75.00 640x360 59.8659.8359.8459.32 512x384 75.0370.0760.00 512x288 60.0059.92 416x312 74.66 480x270 59.6359.82 400x300 72.1975.1260.3256.34 432x243 59.9259.57 320x240 72.8175.0060.05 360x202 59.5159.13 320x180 59.8459.32 HDMI-2 disconnected (normal left inverted right x axis y axis) HDMI-3 disconnected (normal left inverted right x axis y axis) HDMI-4 disconnected (normal left inverted right x axis y axis) -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #6 from Mike Lothian --- Strange I've just tried to do this again with modesetting and X starts but the higher than 30Hz options aren't selectable, and 60Hz exactly is still missing -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #5 from Mike Lothian --- Created attachment 140277 --> https://bugs.freedesktop.org/attachment.cgi?id=140277=edit Dmesg with error -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #4 from Mike Lothian --- If I use the modesetting DDX (with Xorg from git - to include the PCIIDs for Raven) X no longer starts and I get an error in the dmesg -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #3 from Mike Lothian --- Created attachment 140276 --> https://bugs.freedesktop.org/attachment.cgi?id=140276=edit EDID -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 --- Comment #2 from Mike Lothian --- Created attachment 140275 --> https://bugs.freedesktop.org/attachment.cgi?id=140275=edit Dmesg no 60Hz -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #1 from Mike Lothian --- Created attachment 140274 --> https://bugs.freedesktop.org/attachment.cgi?id=140274=edit Xorg.0.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
[Bug 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 Bug ID: 106999 Summary: [raven] 2160p@60Hz no longer available Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: m...@fireburn.co.uk I'm not sure what's changed, if this is an X, DDX or Kernel issue but the number of modes has decreased on my 2400G and 60Hz is no longer available xrandr Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384 HDMI-A-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 1872mm x 1053mm 4096x2160 30.0025.0024.0029.9723.98 3840x2160 30.00* 25.0024.0029.9723.98 1920x1080 60.0050.0059.9430.0025.0024.0029.97 23.98 1680x1050 59.88 1600x900 60.00 1280x1024 75.0260.02 1440x900 59.90 1366x768 59.79 1280x800 59.91 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0370.0760.00 832x624 74.55 800x600 72.1975.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0072.8166.6760.0059.94 720x400 70.08 HDMI-A-1 disconnected (normal left inverted right x axis y axis) HDMI-A-2 disconnected (normal left inverted right x axis y axis) HDMI-A-3 disconnected (normal left inverted right x axis y axis) -- 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 v4] fbdev: Remove depends on HAS_DMA in case of platform dependency
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by: Geert Uytterhoeven Reviewed-by: Mark Brown Acked-by: Robin Murphy Acked-by: Bartlomiej Zolnierkiewicz --- v4: - Rebase to v4.18-rc1 (applies to next-20180622, too), v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/video/fbdev/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 591a13a597874ec0..c6f9023aede4adbc 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2074,7 +2074,8 @@ config FB_XILINX config FB_GOLDFISH tristate "Goldfish Framebuffer" - depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST) + depends on FB + depends on GOLDFISH || COMPILE_TEST select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: remove now unused functions
Some functions are unused after removal of the kmap_atomic
DMA-buf interface.
Signed-off-by: Christian König
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 1a073f9b2834..ec04a69ade46 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -93,23 +93,6 @@ static int omap_gem_dmabuf_end_cpu_access(struct dma_buf
*buffer,
return 0;
}
-
-static void *omap_gem_dmabuf_kmap_atomic(struct dma_buf *buffer,
- unsigned long page_num)
-{
- struct drm_gem_object *obj = buffer->priv;
- struct page **pages;
- omap_gem_get_pages(obj, , false);
- omap_gem_cpu_sync_page(obj, page_num);
- return kmap_atomic(pages[page_num]);
-}
-
-static void omap_gem_dmabuf_kunmap_atomic(struct dma_buf *buffer,
- unsigned long page_num, void *addr)
-{
- kunmap_atomic(addr);
-}
-
static void *omap_gem_dmabuf_kmap(struct dma_buf *buffer,
unsigned long page_num)
{
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106470] [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081
https://bugs.freedesktop.org/show_bug.cgi?id=106470 --- Comment #1 from Dominik 'Rathann' Mierzejewski --- Ping? Is there anything I can do here to help debug this? -- 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 V2 1/2] efi/fb: Simplify fixup code to prefer struct resource
On Wednesday, June 13, 2018 05:42:11 PM Ard Biesheuvel wrote: > On 18 May 2018 at 16:17, Sinan Kaya wrote: > > Get rid of base and size variables in favor of a struct resource. > > The conditional for checking window can be replaced with > > resource_contains(). > > > > Signed-off-by: Sinan Kaya > > Reviewed-by: Ard Biesheuvel Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On Friday, June 22, 2018 12:07:48 PM Bartlomiej Zolnierkiewicz wrote: > On Friday, June 22, 2018 09:54:22 AM Ard Biesheuvel wrote: > > On 13 June 2018 at 18:08, Bartlomiej Zolnierkiewicz > > wrote: > > > On Wednesday, June 13, 2018 05:45:48 PM Ard Biesheuvel wrote: > > >> On 18 May 2018 at 16:17, Sinan Kaya wrote: > > >> > A host bridge is allowed to remap BAR addresses using _TRA attribute in > > >> > _CRS windows. > > >> > > > >> > pci_bus :00: root bus resource [mem 0x8010010-0x8011fff > > >> > window] (bus address [0x0010-0x1fff]) > > >> > pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] > > >> > > > >> > When a VGA device is behind such a host bridge and the resource is > > >> > translated efifb driver is trying to do ioremap against bus address > > >> > rather than the resource address and is failing to probe. > > >> > > > >> > efifb: probing for efifb > > >> > efifb: cannot reserve video memory at 0x1e00 > > >> > efifb: framebuffer at 0x1e00, using 1920k, total 1875k > > >> > efifb: mode is 800x600x32, linelength=3200, pages=1 > > >> > efifb: scrolling: redraw > > >> > efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > > >> > > > >> > Use the host bridge offset information to convert bus address to > > >> > resource address in the fixup. > > >> > > > >> > Signed-off-by: Sinan Kaya > > >> > > >> Reviewed-by: Ard Biesheuvel > > >> > > >> Bartlomiej, could you please take these via the fbdev tree for v4.19? > > > > > > Sure, I will queue it after the current merge window. > > > > > >> Peter already gave his ack but Sinan dropped it (presumably because of > > >> the split in v2) > > > > > > Peter, can I (re)add your ACK to V2 patches? > > > > > > > Actually, it would be better if we could take this through the EFI > > tree instead, with your ack. Would you mind? > > Fine with me. Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dma-buf/fence: Take refcount on the module that owns the fence
Quoting Gustavo Padovan (2018-06-22 11:04:16)
> Hi Akhil,
>
> On Fri, 2018-06-22 at 15:10 +0530, Akhil P Oommen wrote:
> > Each fence object holds function pointers of the module that
> > initialized
> > it. Allowing the module to unload before this fence's release is
> > catastrophic. So, keep a refcount on the module until the fence is
> > released.
> >
> > Signed-off-by: Akhil P Oommen
> > ---
> > Changes in v2:
> > - added description for the new function parameter.
> >
> > drivers/dma-buf/dma-fence.c | 16 +---
> > include/linux/dma-fence.h | 10 --
> > 2 files changed, 21 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-
> > fence.c
> > index 4edb9fd..2aaa44e 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -18,6 +18,7 @@
> > * more details.
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -168,6 +169,7 @@ void dma_fence_release(struct kref *kref)
> > {
> > struct dma_fence *fence =
> > container_of(kref, struct dma_fence, refcount);
> > + struct module *module = fence->owner;
> >
> > trace_dma_fence_destroy(fence);
> >
> > @@ -178,6 +180,8 @@ void dma_fence_release(struct kref *kref)
> > fence->ops->release(fence);
> > else
> > dma_fence_free(fence);
> > +
> > + module_put(module);
> > }
> > EXPORT_SYMBOL(dma_fence_release);
> >
> > @@ -541,6 +545,7 @@ struct default_wait_cb {
> >
> > /**
> > * dma_fence_init - Initialize a custom fence.
> > + * @module: [in]the module that calls this API
> > * @fence: [in]the fence to initialize
> > * @ops: [in]the dma_fence_ops for operations on this
> > fence
> > * @lock:[in]the irqsafe spinlock to use for locking
> > this fence
> > @@ -556,8 +561,9 @@ struct default_wait_cb {
> > * to check which fence is later by simply using dma_fence_later.
> > */
> > void
> > -dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops
> > *ops,
> > -spinlock_t *lock, u64 context, unsigned seqno)
> > +_dma_fence_init(struct module *module, struct dma_fence *fence,
> > + const struct dma_fence_ops *ops, spinlock_t *lock,
> > + u64 context, unsigned seqno)
> > {
> > BUG_ON(!lock);
> > BUG_ON(!ops || !ops->wait || !ops->enable_signaling ||
> > @@ -571,7 +577,11 @@ struct default_wait_cb {
> > fence->seqno = seqno;
> > fence->flags = 0UL;
> > fence->error = 0;
> > + fence->owner = module;
> > +
> > + if (!try_module_get(module))
> > + fence->owner = NULL;
> >
> > trace_dma_fence_init(fence);
> > }
> > -EXPORT_SYMBOL(dma_fence_init);
> > +EXPORT_SYMBOL(_dma_fence_init);
>
> Do we still need to export the symbol, it won't be called from outside
> anymore? Other than that looks good to me:
There's a big drawback in that a module reference is often insufficient,
and that a reference on the driver (or whatever is required for the
lifetime of the fence) will already hold the module reference.
Considering that we want a few 100k fences in flight per second, is
there no other way to only export a fence with a module reference?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On Friday, June 22, 2018 09:54:22 AM Ard Biesheuvel wrote: > On 13 June 2018 at 18:08, Bartlomiej Zolnierkiewicz > wrote: > > On Wednesday, June 13, 2018 05:45:48 PM Ard Biesheuvel wrote: > >> On 18 May 2018 at 16:17, Sinan Kaya wrote: > >> > A host bridge is allowed to remap BAR addresses using _TRA attribute in > >> > _CRS windows. > >> > > >> > pci_bus :00: root bus resource [mem 0x8010010-0x8011fff > >> > window] (bus address [0x0010-0x1fff]) > >> > pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] > >> > > >> > When a VGA device is behind such a host bridge and the resource is > >> > translated efifb driver is trying to do ioremap against bus address > >> > rather than the resource address and is failing to probe. > >> > > >> > efifb: probing for efifb > >> > efifb: cannot reserve video memory at 0x1e00 > >> > efifb: framebuffer at 0x1e00, using 1920k, total 1875k > >> > efifb: mode is 800x600x32, linelength=3200, pages=1 > >> > efifb: scrolling: redraw > >> > efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > >> > > >> > Use the host bridge offset information to convert bus address to > >> > resource address in the fixup. > >> > > >> > Signed-off-by: Sinan Kaya > >> > >> Reviewed-by: Ard Biesheuvel > >> > >> Bartlomiej, could you please take these via the fbdev tree for v4.19? > > > > Sure, I will queue it after the current merge window. > > > >> Peter already gave his ack but Sinan dropped it (presumably because of > >> the split in v2) > > > > Peter, can I (re)add your ACK to V2 patches? > > > > Actually, it would be better if we could take this through the EFI > tree instead, with your ack. Would you mind? Fine with me. > There are some other efifb changes coming up, some of which depend on > core EFI changes, and taking these through different trees is going to > be more trouble than it's worth. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dma-buf/fence: Take refcount on the module that owns the fence
Hi Akhil,
On Fri, 2018-06-22 at 15:10 +0530, Akhil P Oommen wrote:
> Each fence object holds function pointers of the module that
> initialized
> it. Allowing the module to unload before this fence's release is
> catastrophic. So, keep a refcount on the module until the fence is
> released.
>
> Signed-off-by: Akhil P Oommen
> ---
> Changes in v2:
> - added description for the new function parameter.
>
> drivers/dma-buf/dma-fence.c | 16 +---
> include/linux/dma-fence.h | 10 --
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-
> fence.c
> index 4edb9fd..2aaa44e 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -18,6 +18,7 @@
> * more details.
> */
>
> +#include
> #include
> #include
> #include
> @@ -168,6 +169,7 @@ void dma_fence_release(struct kref *kref)
> {
> struct dma_fence *fence =
> container_of(kref, struct dma_fence, refcount);
> + struct module *module = fence->owner;
>
> trace_dma_fence_destroy(fence);
>
> @@ -178,6 +180,8 @@ void dma_fence_release(struct kref *kref)
> fence->ops->release(fence);
> else
> dma_fence_free(fence);
> +
> + module_put(module);
> }
> EXPORT_SYMBOL(dma_fence_release);
>
> @@ -541,6 +545,7 @@ struct default_wait_cb {
>
> /**
> * dma_fence_init - Initialize a custom fence.
> + * @module: [in]the module that calls this API
> * @fence: [in]the fence to initialize
> * @ops: [in]the dma_fence_ops for operations on this
> fence
> * @lock:[in]the irqsafe spinlock to use for locking
> this fence
> @@ -556,8 +561,9 @@ struct default_wait_cb {
> * to check which fence is later by simply using dma_fence_later.
> */
> void
> -dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops
> *ops,
> -spinlock_t *lock, u64 context, unsigned seqno)
> +_dma_fence_init(struct module *module, struct dma_fence *fence,
> + const struct dma_fence_ops *ops, spinlock_t *lock,
> + u64 context, unsigned seqno)
> {
> BUG_ON(!lock);
> BUG_ON(!ops || !ops->wait || !ops->enable_signaling ||
> @@ -571,7 +577,11 @@ struct default_wait_cb {
> fence->seqno = seqno;
> fence->flags = 0UL;
> fence->error = 0;
> + fence->owner = module;
> +
> + if (!try_module_get(module))
> + fence->owner = NULL;
>
> trace_dma_fence_init(fence);
> }
> -EXPORT_SYMBOL(dma_fence_init);
> +EXPORT_SYMBOL(_dma_fence_init);
Do we still need to export the symbol, it won't be called from outside
anymore? Other than that looks good to me:
Reviewed-by: Gustavo Padovan
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-next
Am 22.06.2018 um 05:11 schrieb Dave Airlie: On 21 June 2018 at 20:54, Gustavo Padovan wrote: drm-misc-next-2018-06-21: drm-misc-next for 4.19: Cross-subsystem Changes: - fix compile breakage on ION due to the dma-buf cleanups (Christian König) The following changes since commit daf0678c2036c918f01e4aa6035629d2debc2f30: Merge branch 'drm-next-4.18' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-06-15 11:32:29 +1000) I've pulled this, but it produces: /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c:107:13: warning: ‘omap_gem_dmabuf_kunmap_atomic’ defined but not used [-Wunused-function] static void omap_gem_dmabuf_kunmap_atomic(struct dma_buf *buffer, ^ /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c:97:14: warning: ‘omap_gem_dmabuf_kmap_atomic’ defined but not used [-Wunused-function] static void *omap_gem_dmabuf_kmap_atomic(struct dma_buf *buffer, ^~~ Can I get a follow up in misc-next to fix that? You can consider it done. Sorry for the noise (again), Christian. Thanks, Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] drm: kirin: Remove useless "Scale not support" error message
On Thu, Jun 21, 2018 at 04:01:16PM -0700, John Stultz wrote:
> The driver doesn't support scaling, but when an atomic test is done
> it repeatedly spits out this warning which isn't particularly useful.
>
> So just remove the error message.
>
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei Kong
> Cc: Chen Feng
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Peter Griffin
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
Makes sense, applied to drm-misc-next. This code should probably use
drm_atomic_helper_check_plane_state() anyway, which also comes with a
useful set of opt-in debug output to replace this.
-Daniel
> ---
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index 2269be9..bb77420 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -859,7 +859,6 @@ static int ade_plane_atomic_check(struct drm_plane *plane,
> return PTR_ERR(crtc_state);
>
> if (src_w != crtc_w || src_h != crtc_h) {
> - DRM_ERROR("Scale not support!!!\n");
> return -EINVAL;
> }
>
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Make sure that encoder_type for drm_encoder_init() is in the list
On Thu, Jun 21, 2018 at 05:04:02PM -0600, Jordan Crouse wrote:
> If a encoder name isn't specified for drm_encoder_init() it will try
> to construct one based on the incoming encoder_type identifier. If the
> caller passes an invalid encoder_type value the lookup could walk right
> past the end of the table.
>
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/drm_encoder.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 273e1c59c54a..4cf6c3bb8503 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -128,6 +128,12 @@ int drm_encoder_init(struct drm_device *dev,
> encoder->name = kvasprintf(GFP_KERNEL, name, ap);
> va_end(ap);
> } else {
> + /* Make sure that the requested encoder type is in the list */
> + if (encoder_type >= ARRAY_SIZE(drm_encoder_enum_list)) {
I think moving that to the top and wrapping it in a WARN_ON would be even
better - specifying and invalid encoder type is clearly a driver bug.
-Daniel
> + ret = -EINVAL;
> + goto out_put;
> + }
> +
> encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
>
> drm_encoder_enum_list[encoder_type].name,
> encoder->base.id);
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Consider drivers setting DRIVER_ATOMIC as atomic.
On Thu, Jun 21, 2018 at 12:54:28PM -0700, Eric Anholt wrote:
> Drivers such as vc4 don't initialize mode_config.funcs until later in
> initialization, but we know they're atomic since they've got the flag
> set. This avoids oopsing on dereferencing funcs in the new atomic
> methods sanity checks.
>
> I moved the atomic check function down below the core flag check, to
> avoid needing a prototype.
>
> Signed-off-by: Eric Anholt
> Fixes: ba1f665f161c ("drm: Add checks for atomic_[duplicate/destroy]_state
> with atomic drivers")
Reviewed-by: Daniel Vetter
btw, dim fixes also generates Cc: tags for you (author/reviewer/maintainer
of the commit your fixing), besides just the Fixes: line.
-Daniel
> ---
> include/drm/drmP.h | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index f5099c12c6a6..c5dfbdb7271d 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -97,6 +97,16 @@ struct pci_controller;
>
> #define DRM_IF_VERSION(maj, min) (maj << 16 | min)
>
> +#define DRM_SWITCH_POWER_ON 0
> +#define DRM_SWITCH_POWER_OFF 1
> +#define DRM_SWITCH_POWER_CHANGING 2
> +#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
> +
> +static inline bool drm_core_check_feature(struct drm_device *dev, int
> feature)
> +{
> + return dev->driver->driver_features & feature;
> +}
> +
> /**
> * drm_drv_uses_atomic_modeset - check if the driver implements
> * atomic_commit()
> @@ -107,17 +117,8 @@ struct pci_controller;
> */
> static inline bool drm_drv_uses_atomic_modeset(struct drm_device *dev)
> {
> - return dev->mode_config.funcs->atomic_commit != NULL;
> -}
> -
> -#define DRM_SWITCH_POWER_ON 0
> -#define DRM_SWITCH_POWER_OFF 1
> -#define DRM_SWITCH_POWER_CHANGING 2
> -#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
> -
> -static inline bool drm_core_check_feature(struct drm_device *dev, int
> feature)
> -{
> - return dev->driver->driver_features & feature;
> + return drm_core_check_feature(dev, DRIVER_ATOMIC) ||
> + dev->mode_config.funcs->atomic_commit != NULL;
> }
>
> /* returns true if currently okay to sleep */
> --
> 2.18.0.rc2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Count disabled CRTCs in commit tail earlier
On 2018-06-21 10:48 PM, Lyude Paul wrote:
> This fixes a regression I accidentally reduced that was picked up by
> kasan, where we were checking the CRTC atomic states after DRM's helpers
> had already freed them. Example:
>
> [...]
>
> So, we fix this by counting the number of CRTCs this atomic commit disabled
> early on in the function before their atomic states have been freed, then use
> that count later to do the appropriate number of RPM puts at the end of the
> function.
>
> Fixes: 97028037a38ae ("drm/amdgpu: Grab/put runtime PM references in
> atomic_commit_tail()")
> Signed-off-by: Lyude Paul
> Cc: Michel Dänzer
> Reported-by: Michel Dänzer
Actually, it was reported by Tom St Denis . With
that fixed,
Acked-by: Michel Dänzer
(needs review by DC folks)
--
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
[PATCH v3 2/2] drm/rockchip: Support 10 bits yuv format in vop
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..6a54b20501ac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV12_10LE40:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,6 +250,17 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV12_10LE40:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool is_yuv_10bit(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV12_10LE40:
return true;
default:
return false;
@@ -711,6 +723,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
@@ -728,6 +741,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ is_10_bits = is_yuv_10bit(fb->format->format);
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -742,7 +757,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (fb->format->cpp[0] * 5 / 4);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -753,6 +772,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -761,7 +781,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (bpp * 5 / 4) / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084acdd0019a..d9ec993f420a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -131,6 +131,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08023d3ecb76..5393886ddd95 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,7 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV12_10LE40,
};
static const uint32_t formats_win_lite[] = {
@@ -215,6 +216,7 @@ static const struct vop_win_phy rk3288_win01_data = {
.nformats = ARRAY_SIZE(formats_win_full),
.enable = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 0),
.format = VOP_REG(RK3288_WIN0_CTRL0, 0x7, 1),
+ .fmt_10 = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 4),
.rb_swap =
[PATCH v12 4/5] drm/panel: add Innolux TV123WAM panel driver support
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
Reviewed-by: Sean Paul
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 234af81fb3d0..8c72270deb08 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1190,6 +1190,30 @@ static const struct panel_desc innolux_n156bge_l21 = {
},
};
+static const struct drm_display_mode innolux_tv123wam_mode = {
+ .clock = 206016,
+ .hdisplay = 2160,
+ .hsync_start = 2160 + 48,
+ .hsync_end = 2160 + 48 + 32,
+ .htotal = 2160 + 48 + 32 + 80,
+ .vdisplay = 1440,
+ .vsync_start = 1440 + 3,
+ .vsync_end = 1440 + 3 + 10,
+ .vtotal = 1440 + 3 + 10 + 27,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc innolux_tv123wam = {
+ .modes = _tv123wam_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 259,
+ .height = 173,
+ },
+};
+
static const struct drm_display_mode innolux_zj070na_01p_mode = {
.clock = 51501,
.hdisplay = 1024,
@@ -2037,6 +2061,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,n156bge-l21",
.data = _n156bge_l21,
}, {
+ .compatible = "innolux,tv123wam",
+ .data = _tv123wam,
+ }, {
.compatible = "innolux,zj070na-01p",
.data = _zj070na_01p,
}, {
--
The Qualcomm Innovation Center, Inc. is a member of the 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
[PATCH v12 1/5] dt-bindings: media: extend interface documentation for DSI and DP
Properties like data-lanes, clock-noncontinuous and lane-polarities are applicable to DSI and DisplayPort interface also. So update the documentation to mention the same. Signed-off-by: Sandeep Panda Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/media/video-interfaces.txt | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 852041a7480c..f53d8e49f489 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -99,15 +99,16 @@ Optional endpoint properties determines the logical lane number, while the value of an entry indicates physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0. - This property is valid for serial busses only (e.g. MIPI CSI-2). + This property is valid for serial busses only (e.g. MIPI CSI-2, MIPI DSI, + DisplayPort). - clock-lanes: an array of physical clock lane indexes. Position of an entry determines the logical lane number, while the value of an entry indicates physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;", which places the clock lane on hardware lane 0. This property is valid for serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this array contains only one entry. -- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous - clock mode. +- clock-noncontinuous: a boolean property to allow non-continuous clock mode. + This property is valid for serial busses (e.g. MIPI CSI-2, MIPI DSI and DisplayPort). - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. @@ -116,7 +117,8 @@ Optional endpoint properties Valid values are 0 (normal) and 1 (inverted). The length of the array should be the combined length of data-lanes and clock-lanes properties. If the lane-polarities property is omitted, the value must be interpreted - as 0 (normal). This property is valid for serial busses only. + as 0 (normal). This property is valid for serial busses only (e.g. MIPI CSI-2, + MIPI DSI, DisplayPort). - strobe: Whether the clock signal is used as clock (0) or strobe (1). Used with CCP2, for instance. -- The Qualcomm Innovation Center, Inc. is a member of the 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 v12 3/5] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Quoting Sandeep Panda (2018-06-21 05:32:07) > diff --git > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > new file mode 100644 > index ..c8b8f018356f > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > @@ -0,0 +1,86 @@ > +SN65DSI86 DSI to eDP bridge chip > + > + > +This is the binding for Texas Instruments SN65DSI86 bridge. > +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf > + > +Required properties: > +- compatible: Must be "ti,sn65dsi86" > +- reg: i2c address of the chip, 0x2d as per datasheet > +- enable-gpios: OF device-tree gpio specification for bridge_en pin (active > high) > + > +- vccio-supply: A 1.8V supply that powers up the digital IOs. > +- vpll-supply: A 1.8V supply that powers up the displayport PLL. > +- vcca-supply: A 1.2V supply that powers up the analog circuits. > +- vcc-supply: A 1.2V supply that powers up the digital core. > + > +Optional properties: > +- interrupts-extended: Specifier for the SN65DSI86 interrupt line. > + > +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing > + > +- gpio-controller: Marks the device has a GPIO controller. > +- #gpio-cells: Should be two. The first cell is the pin number and > + the second cell is used to specify flags. > + See ../../gpio/gpio.txt for more information. > +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of > + the cell formats. > + > +- clock-names: should be "refclk" > +- clocks: Specification for input reference clock. The reference > + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. > + > +- data-lanes: See ../../media/video-interface.txt > +- lane-polarities: See ../../media/video-interface.txt We need another property for suspend-gpios function of GPIO1. I suppose for the other GPIOs we don't need anything like this because they're output functions only? GPIO4 can do PWM and I guess if pwm is used in DT from here then the driver can mux that out of gpio4 properly. I have no idea how the hsync and vsync GPIOs would work though. I see that GPIO3 can do DSIA hsync or vsync and GPIO2 can do DSIA vsync and I would guess those are in output mode only. Maybe that's just another property on this node to indicate if we should mux out the function or not. Usually that's done from pinctrl though. I don't have a use case for those functions but I do care about suspend gpios so at least add that one please. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 5/5] dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as done by other existing panel support changes.
Changes in v2:
- Separate driver change from dt-binding documentation (Rob Herring).
- Add the properties from simple-panel binding that are applicable to
this panel (Rob Herring).
Signed-off-by: Sandeep Panda
Reviewed-by: Rob Herring
---
.../bindings/display/panel/innolux,tv123wam.txt | 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
b/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
new file mode 100644
index ..a9b35265fa13
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
@@ -0,0 +1,20 @@
+Innolux TV123WAM 12.3 inch eDP 2K display panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "innolux,tv123wam"
+- power-supply: regulator to provide the supply voltage
+
+Optional properties:
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+ panel_edp: panel-edp {
+ compatible = "innolux,tv123wam";
+ enable-gpios = < 31 GPIO_ACTIVE_LOW>;
+ power-supply = <_l2>;
+ backlight = <>;
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the 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 4.17] reloading etnaviv module causes kernel warning
When removing and reloading the etnaviv module, the following splat occurs: sysfs: cannot create duplicate filename '/devices/platform/etnaviv' CPU: 0 PID: 1471 Comm: modprobe Not tainted 4.17.0+ #1608 Hardware name: Marvell Dove (Cubox) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r6:ef033e38 r5:ee07b340 r4:edb9d000 r3: [] (show_stack) from [] (dump_stack+0x20/0x28) [] (dump_stack) from [] (sysfs_warn_dup+0x5c/0x70) [] (sysfs_warn_dup) from [] (sysfs_create_dir_ns+0x90/0x98) r6:ffef r5:ef033e38 r4:ed984818 r3:ed984818 [] (sysfs_create_dir_ns) from [] (kobject_add_internal+0xb4/0x2d0) r6:ed98481c r5:ef03fd00 r4:ed984818 [] (kobject_add_internal) from [] (kobject_add+0x50/0x98) r8:0001 r7:c08f6f08 r6:c08f6f10 r5: r4:ed984818 [] (kobject_add) from [] (device_add+0xc8/0x538) r3:0003 r2: r6:ed984818 r5: r4:ed984810 [] (device_add) from [] (platform_device_add+0xb4/0x220) r10:ed197e60 r9:bf107748 r8:0001 r7:ed984810 r6:ed984800 r5: r4:ed197d80 [] (platform_device_add) from [] (platform_device_register_full+0xe8/0x110) r8:0001 r7: r6:c0921620 r5:ed984800 r4:ed197d80 r3: [] (platform_device_register_full) from [] (etnaviv_init+0xa4/0xd0 [etnaviv]) r5: r4:ef7b71ec [] (etnaviv_init [etnaviv]) from [] (do_one_initcall+0x90/0x294) r5:bf10e040 r4:bf107700 [] (do_one_initcall) from [] (do_init_module+0x68/0x1d4) r8:0001 r7:bf107700 r6:eea50300 r5:c0921b48 r4:bf107700 [] (do_init_module) from [] (load_module+0x189c/0x2018) r7:bf107700 r6:eeb78400 r5:c0921b48 r4:ed197f38 [] (load_module) from [] (sys_finit_module+0x94/0xa0) r10:0002 r9:ed196000 r8:004d784c r7:0003 r6: r5: r4:7fff [] (sys_finit_module) from [] (ret_fast_syscall+0x0/0x54) Exception stack(0xed197fa8 to 0xed197ff0) 7fa0: 004eb178 0003 004d784c 004eccc0 7fc0: 004eb178 57daf400 017b 0004 004ebea0 7fe0: be84e1f8 be84e1e8 004cf4bb b6ef76b2 r8:c0009228 r7:017b r6:57daf400 r5: r4:004eb178 kobject_add_internal failed for etnaviv with -EEXIST, don't try to register things with the same name in the same directory. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride. The color gamut
follows the BT.2020 standard.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 0/5] Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel
Changes in current patchset: - Explain in comment as in why dsi dev registration is done in bridge_attach. - Make panel/DDC exclusive until HPD support is added. - Update interrupts and data-lane dt property bindings. Sandeep Panda (5): dt-bindings: media: extend interface documentation for DSI and DP drm/bridge: add support for sn65dsi86 bridge driver dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings drm/panel: add Innolux TV123WAM panel driver support dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings .../bindings/display/bridge/ti,sn65dsi86.txt | 86 +++ .../bindings/display/panel/innolux,tv123wam.txt| 20 + .../devicetree/bindings/media/video-interfaces.txt | 10 +- drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 708 + drivers/gpu/drm/panel/panel-simple.c | 27 + 7 files changed, 857 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c -- The Qualcomm Innovation Center, Inc. is a member of the 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
[PATCH 17/26] drm/vmwgfx: Convert to new IDA API
Reorder allocation to avoid an awkward lock/unlock/lock sequence.
Simpler code due to being able to use ida_alloc_max(), even if we can't
eliminate the driver's spinlock.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 41 ++-
1 file changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index f2f9d88131f2..2d6291373efb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -51,51 +51,34 @@ static int vmw_gmrid_man_get_node(struct
ttm_mem_type_manager *man,
{
struct vmwgfx_gmrid_man *gman =
(struct vmwgfx_gmrid_man *)man->priv;
- int ret = 0;
int id;
mem->mm_node = NULL;
+ id = ida_alloc_max(>gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL);
+ if (id < 0)
+ return id;
+
spin_lock(>lock);
if (gman->max_gmr_pages > 0) {
gman->used_gmr_pages += bo->num_pages;
if (unlikely(gman->used_gmr_pages > gman->max_gmr_pages))
- goto out_err_locked;
+ goto nospace;
}
- do {
- spin_unlock(>lock);
- if (unlikely(ida_pre_get(>gmr_ida, GFP_KERNEL) == 0)) {
- ret = -ENOMEM;
- goto out_err;
- }
- spin_lock(>lock);
-
- ret = ida_get_new(>gmr_ida, );
- if (unlikely(ret == 0 && id >= gman->max_gmr_ids)) {
- ida_remove(>gmr_ida, id);
- ret = 0;
- goto out_err_locked;
- }
- } while (ret == -EAGAIN);
-
- if (likely(ret == 0)) {
- mem->mm_node = gman;
- mem->start = id;
- mem->num_pages = bo->num_pages;
- } else
- goto out_err_locked;
+ mem->mm_node = gman;
+ mem->start = id;
+ mem->num_pages = bo->num_pages;
spin_unlock(>lock);
return 0;
-out_err:
- spin_lock(>lock);
-out_err_locked:
+nospace:
gman->used_gmr_pages -= bo->num_pages;
spin_unlock(>lock);
- return ret;
+ ida_free(>gmr_ida, id);
+ return 0;
}
static void vmw_gmrid_man_put_node(struct ttm_mem_type_manager *man,
@@ -105,8 +88,8 @@ static void vmw_gmrid_man_put_node(struct
ttm_mem_type_manager *man,
(struct vmwgfx_gmrid_man *)man->priv;
if (mem->mm_node) {
+ ida_free(>gmr_ida, mem->start);
spin_lock(>lock);
- ida_remove(>gmr_ida, mem->start);
gman->used_gmr_pages -= mem->num_pages;
spin_unlock(>lock);
mem->mm_node = NULL;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 2/5] drm/bridge: add support for sn65dsi86 bridge driver
Add support for TI's sn65dsi86 dsi2edp bridge chip. The chip converts DSI transmitted signal to eDP signal, which is fed to the connected eDP panel. This chip can be controlled via either i2c interface or dsi interface. Currently in driver all the control registers are being accessed through i2c interface only. Also as of now HPD support has not been added to bridge chip driver. Changes in v1: - Split the dt-bindings and the driver support into separate patches (Andrzej Hajda). - Use of gpiod APIs to parse and configure gpios instead of obsolete ones (Andrzej Hajda). - Use macros to define the register offsets (Andrzej Hajda). Changes in v2: - Separate out edp panel specific HW resource handling from bridge driver and create a separate edp panel drivers to handle panel specific mode information and HW resources (Sean Paul). - Replace pr_* APIs to DRM_* APIs to log error or debug information (Sean Paul). - Remove some of the unnecessary structure/variable from driver (Sean Paul). - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge" (Sean Paul / Rob Herring). - Remove most of the hard-coding and modified the bridge init sequence based on current mode (Sean Paul). - Remove the existing function to retrieve the EDID data and implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul). - Remove the dummy irq handler implementation, will add back the proper irq handling later (Sean Paul). - Capture the required enable gpios in a single array based on dt entry instead of having individual descriptor for each gpio (Sean Paul). Changes in v3: - Remove usage of irq_gpio and replace it as "interrupts" property (Rob Herring). - Remove the unnecessary header file inclusions (Sean Paul). - Rearrange the header files in alphabetical order (Sean Paul). - Use regmap interface to perform i2c transactions. - Update Copyright/License field and address other review comments (Jordan Crouse). Changes in v4: - Update License/Copyright (Sean Paul). - Add Kconfig and Makefile changes (Sean Paul). - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios will be handled by i2c master. - Update required supplies names. - Remove unnecessary goto statements (Sean Paul). - Add mutex lock to power_ctrl API to avoid race conditions (Sean Paul). - Add support to parse reference clk frequency from dt(optional). - Update the bridge chip enable/disable sequence. Changes in v5: - Fixed Kbuild test service reported warnings. Changes in v6: - Use PM runtime based ref-counting instead of local ref_count mechanism (Stephen Boyd). - Clean up some debug logs and indentations (Sean Paul). - Simplify dp rate calculation (Sean Paul). - Add support to configure refclk based on input REFCLK pin or DACP/N pin (Stephen Boyd). Changes in v7: - Use static supply entries instead of dynamic allocation (Andrzej Hajda). - Defer bridge driver probe if panel is not probed (Andrzej Hajda). - Update of_graph APIs for correct node reference management. (Andrzej Hajda). - Remove local display_mode object (Andrzej Hajda). - Remove version id check function from driver. Changes in v8: - Move dsi register/attach function to bridge driver probe (Andrzej Hajda). - Introduce a new helper function to write 16bit words into consecutive registers (Andrzej Hajda). - Remove unnecessary macros (Andrzej Hajda). Changes in v9: - Remove dsi register/attach from bridge probe, since dsi dev register completion also waits for any panel or bridge to get added. This creates deadlock situation when bridge driver calls dsi dev register and attach before bridge add, in its probe function. - Fix issues faced during testing of bridge driver on actual HW. - Remove unnecessary initializations (Stephen Boyd). - Use local refclk lut size instead of global macro (Sean Paul). Changes in v10: - Use refclk to determine if continuous dsi clock is needed or not. Changes in v11: - Read DPPLL_SRC register to determine continuous clock instead of using refclk handle (Stephen Boyd). Changes in v12: - Explain in comment as in why dsi dev registration is done in bridge_attach (Andrzej Hajda). - Move HPD disable to bridge_pre_enable (Andrzej Hajda). - Make panel/DDC exclusive until HPD support is added (Andrzej Hajda). Signed-off-by: Sandeep Panda --- drivers/gpu/drm/bridge/Kconfig| 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 708 ++ 3 files changed, 718 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 3b99d5a06c16..8153150acd36 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -108,6 +108,15 @@ config DRM_TI_TFP410 ---help--- Texas Instruments TFP410 DVI/HDMI Transmitter driver
[PATCH v3 0/2] Add support for a YUV 10bits pixel format
In the last time, I got some feedback and not a clear guide on what I should do. So just give more comment on describing this 10bits format. Whether I should add bpp instead cpp in drm_format_info and update a numbers of functions is up to you guys. And I don't any other driver would request 10bits yuv format support, so I can't add the pixel format they don't use as I did a year ago. You would ignore those patches. v3: I put a code comment in a wrong commit in the previous commit, move it back. v2: add more comment to describe this pixel format Randy Li (2): drm/fourcc: add a 10bits fully packed variant of NV12 drm/rockchip: Support 10 bits yuv format in vop drivers/gpu/drm/drm_fourcc.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++ include/uapi/drm/drm_fourcc.h | 8 5 files changed, 37 insertions(+), 2 deletions(-) -- 2.14.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..14bee94a12d9 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,14 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * A fully packed 2 plane YCbCr
+ * Y1 0-9, Y2 10-19, Y3 20-29, Y4 20-39
+ *
+ * U1V1: 0-19, U2V2: 20-39
+ */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 3/5] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp panel specific dt-binding entries. Only keep bridge
specific entries (Sean Paul).
- Remove custom-modes dt entry since its usage is removed from driver also
(Sean Paul).
- Remove is-pluggable dt entry since this will not be needed anymore (Sean
Paul).
Changes in v3:
- Remove irq-gpio dt entry and instead populate is an interrupt
property (Rob Herring).
Changes in v4:
- Add link to bridge chip datasheet (Stephen Boyd)
- Add vpll and vcc regulator supply bindings (Stephen Boyd)
- Add ref clk optional dt binding (Stephen Boyd)
- Add gpio-controller optional dt binding (Stephen Boyd)
Changes in v5:
- Use clock property to specify the input refclk (Stephen Boyd).
- Update gpio cell and pwm cell numbers (Stephen Boyd).
Changes in v6:
- Add property to mention the lane mapping scheme and polarity inversion
(Stephen Boyd).
Changes in v7:
- Detail description of lane mapping scheme dt property (Andrzej
Hajda/ Rob Herring).
- Removed HDP gpio binding, since the bridge uses IRQ signal to
determine HPD, and IRQ property is already documented in binding.
Changes in v8:
- Removed unnecessary explanation of lane mapping and polarity dt
property, since these are already explained in media/video-interface
dt binidng (Rob Herring).
Changes in v9:
- Avoid putting re-definition of lane mapping and polarity dt binding
(Rob Herring).
Changes in v10:
- Use interrupts-extended property instead of interrupts to specify
interrupt line (Andrzej Hajda).
- Move data-lanes and lane-polarity property example to proper place (Andrzej
Hajda).
Signed-off-by: Sandeep Panda
---
.../bindings/display/bridge/ti,sn65dsi86.txt | 86 ++
1 file changed, 86 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index ..c8b8f018356f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,86 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specification for bridge_en pin (active
high)
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vpll-supply: A 1.8V supply that powers up the displayport PLL.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+- vcc-supply: A 1.2V supply that powers up the digital core.
+
+Optional properties:
+- interrupts-extended: Specifier for the SN65DSI86 interrupt line.
+
+- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing
+
+- gpio-controller: Marks the device has a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See ../../gpio/gpio.txt for more information.
+- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
+ the cell formats.
+
+- clock-names: should be "refclk"
+- clocks: Specification for input reference clock. The reference
+ clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
+
+- data-lanes: See ../../media/video-interface.txt
+- lane-polarities: See ../../media/video-interface.txt
+
+Required nodes:
+This device has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+edp-bridge@2d {
+ compatible = "ti,sn65dsi86";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2d>;
+
+ enable-gpios = < 33 GPIO_ACTIVE_HIGH>;
+
+ interrupts-extended = < 4 IRQ_TYPE_EDGE_FALLING>;
+
+ vccio-supply = <_l17>;
+ vcca-supply = <_l6>;
+ vpll-supply = <_l17>;
+ vcc-supply = <_l6>;
+
+ clock-names = "refclk";
+ clocks = <_refclk>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ edp_bridge_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+
[PATCH v2 2/2] drm/rockchip: Support 10 bits yuv format in vop
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
include/uapi/drm/drm_fourcc.h | 6 +-
4 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..6a54b20501ac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV12_10LE40:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,6 +250,17 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV12_10LE40:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool is_yuv_10bit(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV12_10LE40:
return true;
default:
return false;
@@ -711,6 +723,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
@@ -728,6 +741,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ is_10_bits = is_yuv_10bit(fb->format->format);
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -742,7 +757,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (fb->format->cpp[0] * 5 / 4);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -753,6 +772,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -761,7 +781,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (bpp * 5 / 4) / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084acdd0019a..d9ec993f420a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -131,6 +131,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08023d3ecb76..5393886ddd95 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,7 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV12_10LE40,
};
static const uint32_t formats_win_lite[] = {
@@ -215,6 +216,7 @@ static const struct vop_win_phy rk3288_win01_data = {
.nformats = ARRAY_SIZE(formats_win_full),
.enable = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 0),
.format = VOP_REG(RK3288_WIN0_CTRL0, 0x7, 1),
+ .fmt_10
Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec
wrote:
> > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> >
> > wrote:
> >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >> >>
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
napisal(a):
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
> >> >> >> > order
> >> >> >> > to work.
> >> >> >> >
> >> >> >> > Add support for such TCONs.
> >> >> >> >
> >> >> >> > Signed-off-by: Jernej Skrabec
> >> >> >> > ---
> >> >> >> >
> >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++
> >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4
> >> >> >> > 2 files changed, 15 insertions(+)
> >> >> >> >
> >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> >> > 100644
> >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
> >> >> >> > device
> >> >> >> > *dev,
> >> >> >> >
> >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> >> >> > return PTR_ERR(tcon->clk);
> >> >> >> >
> >> >> >> > }
> >> >> >> >
> >> >> >> > +
> >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> >> >> > clock\n");
> >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> >> > + }
> >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> >> > + }
> >> >> >> > +
> >> >> >>
> >> >> >> Is it required for the TCON itself to operate, or does the TCON
> >> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> >> >> functional?
> >> >> >>
> >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> >> >> particular
> >> >> >> device to actually be wired to another device. I'm not saying this
> >> >> >> isn't the case, but it would be a first.
> >> >> >
> >> >> > Documentation doesn't say much about that gate. I did few tests and
> >> >> > TCON
> >> >> > registers can be read and written even if TCON TOP TV TCON gate is
> >> >> > disabled. However, there is no image, as expected.
> >> >>
> >> >> The R40 manual does include it in the diagram, on page 504. There's
> >> >> also
> >> >> a
> >> >> mux to select whether the clock comes directly from the CCU or the TV
> >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> >> referring
> >> >> to
> >> >> here, in which case it is not a bus clock, but rather the TCON module
> >> >> or
> >> >> channel clock, strangely routed.
> >> >>
> >> >> > More interestingly, I enabled test pattern directly in TCON to
> >> >> > eliminate
> >> >> > influence of the mixer. As soon as I disabled that gate, test
> >> >> > pattern
> >> >> > on
> >> >> > HDMI screen was gone, which suggest that this gate influences
> >> >> > something
> >> >> > inside TCON.
> >> >> >
> >> >> > Another test I did was that I moved enable/disable gate code to
> >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >> >
> >> >> > I'll ask AW engineer what that gate actually does, but from what I
> >> >> > saw,
> >> >> > I
> >> >> > would say that most appropriate location to enable/disable TCON TOP
> >> >> > TV
> >> >> > TCON
> >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
> >> >> > any
> >> >> > TV
> >> >> > TCON is in use and enable appropriate gate. However, that doesn't
> >> >> > sound
> >> >> > right to me for some reason.
> >> >>
> >> >> If what I said above it true, then yes, the appropriate location to
> >> >> enable
> >> >> it is the TCON driver, but moreover, the representation of the clock
> >> >> tree
> >> >> should be fixed such that the TCON takes the clock from the TCON TOP
> >> >> as
> >> >> its
> >> >> channel/ module clock instead. That way you don't need this patch, but
> >> >> you'd add another for all the clock routing.
> >> >
> >> > Can you be more specific? I not sure what you mean here.
> >>
> >> For clock related properties in the device tree:
> >>
> >> _top {
> >>
> >> clocks = < CLK_BUS_TCON_TOP>,
> >>
> >> < CLK_TCON_TV0>,
> >> <>,
> >> < CLK_TCON_TV1>,
> >> <>;
> >>
> >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1",
[PATCH v2 0/2] Add support for a YUV 10bits pixel format
In the last time, I got some feedback and not a clear guide on what I should do. So just give more comment on describing this 10bits format. Whether I should add bpp instead cpp in drm_format_info and update a numbers of functions is up to you guys. And I don't any other driver would request 10bits yuv format support, so I can't add the pixel format they don't use as I did a year ago. You would ignore those patches. Randy Li (2): drm/fourcc: add a 10bits fully packed variant of NV12 drm/rockchip: Support 10 bits yuv format in vop drivers/gpu/drm/drm_fourcc.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++ include/uapi/drm/drm_fourcc.h | 7 +++ 5 files changed, 36 insertions(+), 2 deletions(-) -- 2.14.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106879] Ugly bug present in kernels 4.14, 4.15, 4.16, 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106879 --- Comment #4 from javcasalc --- Hi any ideas with this bug? -- 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
[DPU PATCH v2] drm/msm/dpu: remove msm_prop entry from Makefile
msm_prop[.ch] files were removed in prop cleanup series but its reference were left in Makefile. Remove it. Changes in v2: - removed Change-id Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index 9872928..2451d50 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -76,7 +76,6 @@ msm-y := \ disp/dpu1/dpu_power_handle.o \ dpu_dbg.o \ dpu_dbg_evtlog.o \ - msm_prop.o \ msm_atomic.o \ msm_debugfs.o \ msm_drv.o \ -- The Qualcomm Innovation Center, Inc. is a member of the 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
[DPU PATCH] drm/msm/dpu: remove msm_prop entry from Makefile
msm_prop[.ch] files were removed in prop cleanup series but its refrence were left in Makefile. Remove it. Change-Id: I185d82423c00a2df15a1b3daa7026c3a3e10c8e6 Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index 9872928..2451d50 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -76,7 +76,6 @@ msm-y := \ disp/dpu1/dpu_power_handle.o \ dpu_dbg.o \ dpu_dbg_evtlog.o \ - msm_prop.o \ msm_atomic.o \ msm_debugfs.o \ msm_drv.o \ -- The Qualcomm Innovation Center, Inc. is a member of the 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
