Re: [PATCH v2 1/3] drm/sun4i: dsi: Fix video start delay computation
On Tue, Oct 08, 2019 at 11:06:07AM +0800, Icenowy Zheng wrote: > 于 2019年10月7日 GMT+08:00 下午7:51:48, Maxime Ripard 写到: > >On Mon, Oct 07, 2019 at 12:03:00AM +0800, Icenowy Zheng wrote: > >> From: Jagan Teki > >> > >> The LCD timing definitions between Linux DRM vs Allwinner are > >different, > >> below diagram shows this clear differences. > >> > >>Active Front Sync Back > >>Region Porch > >Porch > >> > ><---><><--><--> > >> //| > >> // | > >> // |.. > > > >> > >> <- [hv]display -> > >> <- [hv]sync_start > > >> <- [hv]sync_end --> > >> < [hv]total > >--> > >> > >> <- lcd_[xy] ><- lcd_[hv]spw -> > >> <-- lcd_[hv]bp -> > >> < lcd_[hv]t > >--> > >> > >> The DSI driver misinterpreted the vbp term from the BSP code to refer > >> only to the backporch, when in fact it was backporch + sync. Thus the > >> driver incorrectly used the vertical front porch plus sync in its > >> calculation of the DRQ set bit value, when it should not have > >included > >> the sync timing. > >> > >> Including additional sync timings leads to flip_done timed out as: > >> > >> WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > >drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > >> [CRTC:46:crtc-0] vblank wait timed out > >> Modules linked in: > >> CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > >5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 > >> Hardware name: Allwinner sun8i Family > >> Workqueue: events deferred_probe_work_func > >> [] (unwind_backtrace) from [] > >(show_stack+0x10/0x14) > >> [] (show_stack) from [] (dump_stack+0x84/0x98) > >> [] (dump_stack) from [] (__warn+0xfc/0x114) > >> [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > >> [] (warn_slowpath_fmt) from [] > >(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > >> [] (drm_atomic_helper_wait_for_vblanks.part.1) from > >[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > >> [] (drm_atomic_helper_commit_tail_rpm) from [] > >(commit_tail+0x40/0x6c) > >> [] (commit_tail) from [] > >(drm_atomic_helper_commit+0xbc/0x128) > >> [] (drm_atomic_helper_commit) from [] > >(restore_fbdev_mode_atomic+0x1cc/0x1dc) > >> [] (restore_fbdev_mode_atomic) from [] > >(drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > >> [] (drm_fb_helper_restore_fbdev_mode_unlocked) from > >[] (drm_fb_helper_set_par+0x30/0x54) > >> [] (drm_fb_helper_set_par) from [] > >(fbcon_init+0x560/0x5ac) > >> [] (fbcon_init) from [] (visual_init+0xbc/0x104) > >> [] (visual_init) from [] > >(do_bind_con_driver+0x1b0/0x390) > >> [] (do_bind_con_driver) from [] > >(do_take_over_console+0x13c/0x1c4) > >> [] (do_take_over_console) from [] > >(do_fbcon_takeover+0x74/0xcc) > >> [] (do_fbcon_takeover) from [] > >(notifier_call_chain+0x44/0x84) > >> [] (notifier_call_chain) from [] > >(__blocking_notifier_call_chain+0x48/0x60) > >> [] (__blocking_notifier_call_chain) from [] > >(blocking_notifier_call_chain+0x18/0x20) > >> [] (blocking_notifier_call_chain) from [] > >(register_framebuffer+0x1e0/0x2f8) > >> [] (register_framebuffer) from [] > >(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > >> [] (__drm_fb_helper_initial_config_and_unlock) from > >[] (drm_fbdev_client_hotplug+0xe8/0x1b8) > >> [] (drm_fbdev_client_hotplug) from [] > >(drm_fbdev_generic_setup+0x88/0x118) > >> [] (drm_fbdev_generic_setup) from [] > >(sun4i_drv_bind+0x128/0x160) > >> [] (sun4i_drv_bind) from [] > >(try_to_bring_up_master+0x164/0x1a0) > >> [] (try_to_bring_up_master) from [] > >(__component_add+0x94/0x140) > >> [] (__component_add) from [] > >(sun6i_dsi_probe+0x144/0x234) > >> [] (sun6i_dsi_probe) from [] > >(platform_drv_probe+0x48/0x9c) > >> [] (platform_drv_probe) from [] > >(really_probe+0x1dc/0x2c8) > >> [] (really_probe) from [] > >(driver_probe_device+0x60/0x160) > >> [] (driver_probe_device) from [] > >(bus_for_each_drv+0x74/0xb8) > >> [] (bus_for_each_drv) from [] > >(__device_attach+0xd0/0x13c) > >> [] (__device_attach) from [] > >(bus_probe_device+0x84/0x8c) > >> [] (bus_probe_device) from [] > >(deferred_probe_work_func+0x64/0x90) > >> [] (deferred_probe_work_func) from [] > >(process_one_work+0x204/0x420) > >> [] (process_one_work) from [] > >(worker_thread+0x274/0x5a0) > >> [] (worker_thread) from [] (kthread+0x11c/0x14c) > >> [] (kthread) from [] (ret_from_fork+0x14/0x2c) > >> Exception stack(0xde539fb0 to 0xde539ff8) > >> 9fa0: > > > >> 9fc0:
Re: [PATCH 0/5] Fix SPI module alias for panels used by omapdrm
On 07/10/2019 20:22, Sam Ravnborg wrote: Hi Laurent. On Mon, Oct 07, 2019 at 08:07:56PM +0300, Laurent Pinchart wrote: Hello, This patch series fixes a module alias issue with the five recently added panel drivers used by omapdrm. Before those panel drivers, omapdrm had custom drivers for the panels, and prefixed the OF compatible strings with an "omapdss," prefix. The SPI device IDs are constructed by stripping the OF compatible string from the prefix, resulting in the "omapdss," prefix being removed, but the subsequence OF vendor prefix being kept. The SPI drivers thus had modules aliases that contained the vendor prefix. Now that the panels are supported by standard drivers and the "omapdss," prefix is removed, the SPI device IDs are stripped from the OF vendor prefix. As the new panel drivers copied the module aliases from the omapdrm-specific drivers, they contain the vendor prefix in their SPI module aliases, and are thus not loaded automatically. Fix this by removing the vendor prefix from the SPI modules aliases in the drivers. For consistency reason, the manual module aliases are also moved to use an SPI module table. Good explanation - thanks. These patches are based on the drm-misc-fixes branch as they fix v5.4 regressions. Laurent Pinchart (5): drm/panel: lg-lb035q02: Fix SPI alias drm/panel: nec-nl8048hl11: Fix SPI alias drm/panel: sony-acx565akm: Fix SPI alias drm/panel: tpo-td028ttec1: Fix SPI alias drm/panel: tpo-td043mtea1: Fix SPI alias Full series is: Acked-by: Sam Ravnborg I expect someone else to pick them up or that you apply them. Thanks! I've pushed these to drm-misc-fixes. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19
https://bugzilla.kernel.org/show_bug.cgi?id=201497 sebastian.lars...@protonmail.com changed: What|Removed |Added CC||sebastian.larsson@protonmai ||l.com --- Comment #11 from sebastian.lars...@protonmail.com --- Been struggling with this issue for quite some time Is there any progress made? ASUS ROG Swift PG278Q R9 380X 5.4.0-rc1linux-5.4-rc1 [2.776432] [drm:dc_link_detect [amdgpu]] *ERROR* No EDID read. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/sun4i: dsi: Fix video start delay computation
于 2019年10月7日 GMT+08:00 下午7:51:48, Maxime Ripard 写到: >On Mon, Oct 07, 2019 at 12:03:00AM +0800, Icenowy Zheng wrote: >> From: Jagan Teki >> >> The LCD timing definitions between Linux DRM vs Allwinner are >different, >> below diagram shows this clear differences. >> >>Active Front Sync Back >>Region Porch >Porch >> ><---><><--><--> >> //| >> // | >> // |.. > >> >> <- [hv]display -> >> <- [hv]sync_start > >> <- [hv]sync_end --> >> < [hv]total >--> >> >> <- lcd_[xy] > <- lcd_[hv]spw -> >><-- lcd_[hv]bp -> >> < lcd_[hv]t >--> >> >> The DSI driver misinterpreted the vbp term from the BSP code to refer >> only to the backporch, when in fact it was backporch + sync. Thus the >> driver incorrectly used the vertical front porch plus sync in its >> calculation of the DRQ set bit value, when it should not have >included >> the sync timing. >> >> Including additional sync timings leads to flip_done timed out as: >> >> WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 >drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 >> [CRTC:46:crtc-0] vblank wait timed out >> Modules linked in: >> CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted >5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 >> Hardware name: Allwinner sun8i Family >> Workqueue: events deferred_probe_work_func >> [] (unwind_backtrace) from [] >(show_stack+0x10/0x14) >> [] (show_stack) from [] (dump_stack+0x84/0x98) >> [] (dump_stack) from [] (__warn+0xfc/0x114) >> [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) >> [] (warn_slowpath_fmt) from [] >(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) >> [] (drm_atomic_helper_wait_for_vblanks.part.1) from >[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) >> [] (drm_atomic_helper_commit_tail_rpm) from [] >(commit_tail+0x40/0x6c) >> [] (commit_tail) from [] >(drm_atomic_helper_commit+0xbc/0x128) >> [] (drm_atomic_helper_commit) from [] >(restore_fbdev_mode_atomic+0x1cc/0x1dc) >> [] (restore_fbdev_mode_atomic) from [] >(drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) >> [] (drm_fb_helper_restore_fbdev_mode_unlocked) from >[] (drm_fb_helper_set_par+0x30/0x54) >> [] (drm_fb_helper_set_par) from [] >(fbcon_init+0x560/0x5ac) >> [] (fbcon_init) from [] (visual_init+0xbc/0x104) >> [] (visual_init) from [] >(do_bind_con_driver+0x1b0/0x390) >> [] (do_bind_con_driver) from [] >(do_take_over_console+0x13c/0x1c4) >> [] (do_take_over_console) from [] >(do_fbcon_takeover+0x74/0xcc) >> [] (do_fbcon_takeover) from [] >(notifier_call_chain+0x44/0x84) >> [] (notifier_call_chain) from [] >(__blocking_notifier_call_chain+0x48/0x60) >> [] (__blocking_notifier_call_chain) from [] >(blocking_notifier_call_chain+0x18/0x20) >> [] (blocking_notifier_call_chain) from [] >(register_framebuffer+0x1e0/0x2f8) >> [] (register_framebuffer) from [] >(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) >> [] (__drm_fb_helper_initial_config_and_unlock) from >[] (drm_fbdev_client_hotplug+0xe8/0x1b8) >> [] (drm_fbdev_client_hotplug) from [] >(drm_fbdev_generic_setup+0x88/0x118) >> [] (drm_fbdev_generic_setup) from [] >(sun4i_drv_bind+0x128/0x160) >> [] (sun4i_drv_bind) from [] >(try_to_bring_up_master+0x164/0x1a0) >> [] (try_to_bring_up_master) from [] >(__component_add+0x94/0x140) >> [] (__component_add) from [] >(sun6i_dsi_probe+0x144/0x234) >> [] (sun6i_dsi_probe) from [] >(platform_drv_probe+0x48/0x9c) >> [] (platform_drv_probe) from [] >(really_probe+0x1dc/0x2c8) >> [] (really_probe) from [] >(driver_probe_device+0x60/0x160) >> [] (driver_probe_device) from [] >(bus_for_each_drv+0x74/0xb8) >> [] (bus_for_each_drv) from [] >(__device_attach+0xd0/0x13c) >> [] (__device_attach) from [] >(bus_probe_device+0x84/0x8c) >> [] (bus_probe_device) from [] >(deferred_probe_work_func+0x64/0x90) >> [] (deferred_probe_work_func) from [] >(process_one_work+0x204/0x420) >> [] (process_one_work) from [] >(worker_thread+0x274/0x5a0) >> [] (worker_thread) from [] (kthread+0x11c/0x14c) >> [] (kthread) from [] (ret_from_fork+0x14/0x2c) >> Exception stack(0xde539fb0 to 0xde539ff8) >> 9fa0: > >> 9fc0: > >> 9fe0: 0013 >> ---[ end trace 495200a78b24980e ]--- >> random: fast init done >> [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* >[CRTC:46:crtc-0]
Re: linux-next: build failure after merge of the drm-misc tree
Hi all, On Tue, 8 Oct 2019 10:30:45 +1100 Stephen Rothwell wrote: > > Hi all, > > After merging the drm-misc tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > Sorry, forgot to include the error messages. But they shuld be clear from the fix ... -- Cheers, Stephen Rothwell pgpRlGtUZJ4yP.pgp Description: OpenPGP digital signature
[PATCH -next] drm/qxl: Fix randbuild error
If DEM_QXL is y and DRM_TTM_HELPER is m, building fails:
drivers/gpu/drm/qxl/qxl_object.o: undefined reference to
`drm_gem_ttm_print_info'
Select DRM_TTM_HELPER to fix this.
Fixes: 78d54f1f6a33 ("drm/qxl: use drm_gem_ttm_print_info")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/qxl/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig
index d0d691b..ca3f51c 100644
--- a/drivers/gpu/drm/qxl/Kconfig
+++ b/drivers/gpu/drm/qxl/Kconfig
@@ -4,6 +4,7 @@ config DRM_QXL
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
select DRM_TTM
+ select DRM_TTM_HELPER
select CRC32
help
QXL virtual GPU for Spice virtualization desktop integration.
--
2.7.4
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
Hi ville syrjala,
在 2019/9/30 下午6:48, Ville Syrjälä 写道:
On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
These new format is supported by some rockchip socs:
DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/drm_fourcc.c | 18 ++
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index c630064..ccd78a3 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -261,6 +261,24 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2,
.char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10, .depth = 0,
.num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV21_10, .depth = 0,
.num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV16_10, .depth = 0,
.num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
+ .hsub = 2, .vsub = 1, .is_yuv = true},
+ { .format = DRM_FORMAT_NV61_10, .depth = 0,
.num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
+ .hsub = 2, .vsub = 1, .is_yuv = true},
+ { .format = DRM_FORMAT_NV24_10, .depth = 0,
.num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
+ .hsub = 1, .vsub = 1, .is_yuv = true},
+ { .format = DRM_FORMAT_NV42_10, .depth = 0,
.num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
+ .hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_P210,.depth = 0,
.num_planes = 2, .char_per_block = { 2, 4, 0 },
.block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 }, .hsub = 2,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3..08e2221 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -238,6 +238,20 @@ extern "C" {
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr
+ * index 0 = Y plane, Y3:Y2:Y1:Y0 10:10:10:10
+ * index 1 = Cb:Cr plane, Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0
10:10:10:10:10:10:10:10
+ * or
+ * index 1 = Cr:Cb plane, Cr3:Cb3:Cr2:Cb2:Cr1:Cb1:Cr0:Cb0
10:10:10:10:10:10:10:10
So now you're defining it as some kind of byte aligned block.
With that specifying endianness would now make sense since
otherwise this tells us absolutely nothing about the memory
layout.
So I'd either do that, or go back to not specifying anything and
use some weasel words like "mamory layout is implementation defined"
which of course means no one can use it for anything that involves
any kind of cross vendor stuff.
/*
* 2 plane YCbCr
* index 0 = Y plane, [39: 0] Y3:Y2:Y1:Y0 10:10:10:10 little endian
* index 1 = Cb:Cr plane, [79: 0] Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0
10:10:10:10:10:10:10:10 little endian
* or
* index 1 = Cr:Cb plane, [79: 0] Cr3:Cb3:Cr2:Cb2:Cr1:Cb1:Cr0:Cb0
10:10:10:10:10:10:10:10 little endian
*/
Is this description ok?
+ */
+#define DRM_FORMAT_NV12_10 fourcc_code('N', 'A', '1', '2') /* 2x2
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV21_10 fourcc_code('N', 'A', '2', '1') /* 2x2
subsampled Cb:Cr plane */
+#define DRM_FORMAT_NV16_10 fourcc_code('N', 'A', '1', '6') /* 2x1
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV61_10 fourcc_code('N', 'A', '6', '1') /* 2x1
subsampled Cb:Cr plane */
+#define DRM_FORMAT_NV24_10 fourcc_code('N', 'A', '2', '4') /*
non-subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV42_10 fourcc_code('N', 'A', '4', '2') /*
non-subsampled Cb:Cr plane */
+
+/*
* 2 plane YCbCr MSB aligned
* index 0 = Y plane, [15:0] Y:x [10:6] little endian
* index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
--
2.7.4
___
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
[Bug 110865] Rx480 consumes 20w more power in idle than under Windows
https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #37 from Dieter Nützel --- (In reply to tempel.julian from comment #36) > (In reply to Dieter Nützel from comment #28) > > I've tried solving the flicker with both fixes (sent by magist3r) from this > > bug > > > > Bug 102646 - Screen flickering under amdgpu-experimental [buggy auto power > > profile] > > https://bugs.freedesktop.org/show_bug.cgi?id=102646 > > > > But no success. > > Have you also applied Ahzo's patch, just in case? Thanks for the hint. v2 is already in 'amd-staging-drm-next' f659bb6dae58c113805f92822e4c16ddd3156b79 drm/amd/powerplay/smu7: enforce minimal VBITimeout (v2) -- 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
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
10d8f308ba3e ("cec: add cec_adapter to cec_notifier_cec_adap_unregister()")
interacting with commit
7e86efa2ff03 ("media: cec-gpio: add notifier support")
form the v4l-dvb tree.
I have applied the following merge fix patch.
From: Stephen Rothwell
Date: Tue, 8 Oct 2019 10:26:05 +1100
Subject: [PATCH] cec: fix up for "cec: add cec_adapter to
cec_notifier_cec_adap_unregister()"
Signed-off-by: Stephen Rothwell
---
drivers/media/platform/cec-gpio/cec-gpio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c
b/drivers/media/platform/cec-gpio/cec-gpio.c
index 7be91e712c4a..42d2c2cd9a78 100644
--- a/drivers/media/platform/cec-gpio/cec-gpio.c
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -259,7 +259,7 @@ static int cec_gpio_probe(struct platform_device *pdev)
return 0;
unreg_notifier:
- cec_notifier_cec_adap_unregister(cec->notifier);
+ cec_notifier_cec_adap_unregister(cec->notifier, cec->adap);
del_adap:
cec_delete_adapter(cec->adap);
return ret;
@@ -269,7 +269,7 @@ static int cec_gpio_remove(struct platform_device *pdev)
{
struct cec_gpio *cec = platform_get_drvdata(pdev);
- cec_notifier_cec_adap_unregister(cec->notifier);
+ cec_notifier_cec_adap_unregister(cec->notifier, cec->adap);
cec_unregister_adapter(cec->adap);
return 0;
}
--
2.23.0.rc1
--
Cheers,
Stephen Rothwell
pgpjcYmXWdeKb.pgp
Description: OpenPGP digital signature
[Bug 111913] AMD Navi10 GPU powerplay issues when using two DisplayPort connectors
https://bugs.freedesktop.org/show_bug.cgi?id=111913 --- Comment #5 from Andrew Sheldon --- Are both monitors 60hz? I've seen this occur with 2x60hz setups, but not with other combinations of refresh rates. It seems to be similar to issues with 75hz in a single monitor configuration. Other combinations of dual monitor refresh rates don't exhibit the issue, for me (although there are other problems, as discussed in https://bugs.freedesktop.org/show_bug.cgi?id=111482). -- 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 v8 1/4] drm/panel: Add helper for reading DT rotation
On Mon, Oct 7, 2019 at 9:38 AM Sean Paul wrote:
>
> On Wed, Sep 25, 2019 at 03:58:30PM -0700, Derek Basehore wrote:
> > This adds a helper function for reading the rotation (panel
> > orientation) from the device tree.
> >
> > Signed-off-by: Derek Basehore
> > Reviewed-by: Sam Ravnborg
>
> The patch LGTM, but I don't see it used anywhere later in the patch? Is there
> a
> panel driver incoming?
Yeah, the boe-tv101wum-nl6 panel will use it. It's not in the patch
currently sent upstream since I don't want to step on their toes, but
I plan on sending a patch to add it as soon as that is merged.
I could hold back on this patch until that panel driver is merged too.
Another alternative is to throw this into the generic drm_panel code,
but there's no obvious place to put it since DRM seems to leave
reading the DTS up to the panel drivers themselves.
>
> Sean
>
> > ---
> > drivers/gpu/drm/drm_panel.c | 43 +
> > include/drm/drm_panel.h | 9
> > 2 files changed, 52 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > index 6b0bf42039cf..0909b53b74e6 100644
> > --- a/drivers/gpu/drm/drm_panel.c
> > +++ b/drivers/gpu/drm/drm_panel.c
> > @@ -264,6 +264,49 @@ struct drm_panel *of_drm_find_panel(const struct
> > device_node *np)
> > return ERR_PTR(-EPROBE_DEFER);
> > }
> > EXPORT_SYMBOL(of_drm_find_panel);
> > +
> > +/**
> > + * of_drm_get_panel_orientation - look up the orientation of the panel
> > through
> > + * the "rotation" binding from a device tree node
> > + * @np: device tree node of the panel
> > + * @orientation: orientation enum to be filled in
> > + *
> > + * Looks up the rotation of a panel in the device tree. The orientation of
> > the
> > + * panel is expressed as a property name "rotation" in the device tree. The
> > + * rotation in the device tree is counter clockwise.
> > + *
> > + * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or
> > the
> > + * rotation property doesn't exist. -EERROR otherwise.
> > + */
> > +int of_drm_get_panel_orientation(const struct device_node *np,
> > + enum drm_panel_orientation *orientation)
> > +{
> > + int rotation, ret;
> > +
> > + ret = of_property_read_u32(np, "rotation", );
> > + if (ret == -EINVAL) {
> > + /* Don't return an error if there's no rotation property. */
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > + return 0;
> > + }
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (rotation == 0)
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > + else if (rotation == 90)
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
> > + else if (rotation == 180)
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> > + else if (rotation == 270)
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
> > + else
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(of_drm_get_panel_orientation);
> > #endif
> >
> > MODULE_AUTHOR("Thierry Reding ");
> > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > index 624bd15ecfab..d16158deacdc 100644
> > --- a/include/drm/drm_panel.h
> > +++ b/include/drm/drm_panel.h
> > @@ -34,6 +34,8 @@ struct drm_device;
> > struct drm_panel;
> > struct display_timing;
> >
> > +enum drm_panel_orientation;
> > +
> > /**
> > * struct drm_panel_funcs - perform operations on a given panel
> > *
> > @@ -165,11 +167,18 @@ int drm_panel_get_modes(struct drm_panel *panel);
> >
> > #if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
> > struct drm_panel *of_drm_find_panel(const struct device_node *np);
> > +int of_drm_get_panel_orientation(const struct device_node *np,
> > + enum drm_panel_orientation *orientation);
> > #else
> > static inline struct drm_panel *of_drm_find_panel(const struct device_node
> > *np)
> > {
> > return ERR_PTR(-ENODEV);
> > }
> > +static inline int of_drm_get_panel_orientation(const struct device_node
> > *np,
> > + enum drm_panel_orientation *orientation)
> > +{
> > + return -ENODEV;
> > +}
> > #endif
> >
> > #endif
> > --
> > 2.23.0.351.gc4317032e6-goog
> >
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
Re: [v8,2/4] drm/panel: set display info in panel attach
On Mon, Oct 7, 2019 at 9:44 AM Sean Paul wrote:
>
> On Mon, Sep 30, 2019 at 04:14:54PM -0700, dbasehore . wrote:
> > On Sat, Sep 28, 2019 at 10:23 PM james qian wang (Arm Technology
> > China) wrote:
> > >
> > > On Wed, Sep 25, 2019 at 03:58:31PM -0700, Derek Basehore wrote:
> > > > Devicetree systems can set panel orientation via a panel binding, but
> > > > there's no way, as is, to propagate this setting to the connector,
> > > > where the property need to be added.
> > > > To address this, this patch sets orientation, as well as other fixed
> > > > values for the panel, in the drm_panel_attach function. These values
> > > > are stored from probe in the drm_panel struct.
> > > >
> > > > Signed-off-by: Derek Basehore
> > > > Reviewed-by: Sam Ravnborg
> > > > ---
> > > > drivers/gpu/drm/drm_panel.c | 28 +
> > > > include/drm/drm_panel.h | 50 +
> > > > 2 files changed, 78 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > > > index 0909b53b74e6..1cd2b56c9fe6 100644
> > > > --- a/drivers/gpu/drm/drm_panel.c
> > > > +++ b/drivers/gpu/drm/drm_panel.c
> > > > @@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
> > > > */
> > > > int drm_panel_attach(struct drm_panel *panel, struct drm_connector
> > > > *connector)
> > > > {
> > > > + struct drm_display_info *info;
> > > > +
> > > > if (panel->connector)
> > > > return -EBUSY;
> > > >
> > > > panel->connector = connector;
> > > > panel->drm = connector->dev;
> > > > + info = >display_info;
> > > > + info->width_mm = panel->width_mm;
> > > > + info->height_mm = panel->height_mm;
> > > > + info->bpc = panel->bpc;
> > > > + info->panel_orientation = panel->orientation;
> > > > + info->bus_flags = panel->bus_flags;
> > > > + if (panel->bus_formats)
> > > > + drm_display_info_set_bus_formats(>display_info,
> > > > + panel->bus_formats,
> > > > + panel->num_bus_formats);
> > > >
> > > > return 0;
> > > > }
> > > > @@ -126,6 +138,22 @@ EXPORT_SYMBOL(drm_panel_attach);
> > > > */
> > > > void drm_panel_detach(struct drm_panel *panel)
> > > > {
> > > > + struct drm_display_info *info;
> > > > +
> > > > + if (!panel->connector)
> > > > + goto out;
> > > > +
> > > > + info = >connector->display_info;
> > > > + info->width_mm = 0;
> > > > + info->height_mm = 0;
> > > > + info->bpc = 0;
> > > > + info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > > > + info->bus_flags = 0;
> > > > + kfree(info->bus_formats);
> > > > + info->bus_formats = NULL;
> > > > + info->num_bus_formats = 0;
> > > > +
> > > > +out:
> > > > panel->connector = NULL;
> > > > panel->drm = NULL;
> > > > }
> > > > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > > > index d16158deacdc..f3587a54b8ac 100644
> > > > --- a/include/drm/drm_panel.h
> > > > +++ b/include/drm/drm_panel.h
> > > > @@ -141,6 +141,56 @@ struct drm_panel {
> > > >*/
> > > > const struct drm_panel_funcs *funcs;
> > > >
> > >
> > > All these new added members seems dupliated with drm_display_info,
> > > So I think, can we add a new drm_plane_funcs func:
> > >
> > > int (*set_display_info)(struct drm_panel *panel,
> > > struct drm_display_info *info);
> >
> > I don't disagree personally, since I originally wrote it this way, but
> > 2 maintainers, Daniel Vetter and Thierry Reding, requested that it be
> > changed. Unless that decision is reversed, I won't be changing this.
> >
>
> Reading back the feedback on v1, I don't think anyone said they were against
> storing a drm_display_info struct in drm_panel (no one really weighed in on
> it one way or another). IMO duplicating a bunch of fields feels pretty icky.
Thanks for the review. Should we duplicate the entire struct, or just
create a sub-struct, say, physical_properties that will be part of
drm_display_info and drm_panel?
>
> I think most fields in drm_display_info have pretty reasonable defaults, so
> I'd
> recommend just storing a copy in drm_panel. As Thierry suggests, we can
> populate the dt parts in probe (orientation) and then copy over all or a
> subset
> of the struct to connector on attach.
>
> Sean
>
> > >
> > > Then in drm_panel_attach(), via this interface the specific panel
> > > driver can directly set connector->display_info. like
> > >
> > >...
> > >if (panel->funcs && panel->funcs->set_display_info)
> > > panel->funcs->unprepare(panel, connector->display_info);
> > >...
> > >
> > > Thanks
> > > James
> > >
> > > > + /**
> > > > + * @width_mm:
> > > > + *
> > > > + * Physical width in mm.
> > > > + */
> > > > + unsigned int width_mm;
> > > > +
> > > > + /**
> > > > +
[PATCH] drm/amdgpu/display: make various arrays static, makes object smaller
From: Colin Ian King
Don't populate the arrays on the stack but instead make them
static. Makes the object code smaller by 158 bytes.
Before:
textdata bss dec hex filename
324682072 0 3454086ec display/dc/bios/bios_parser.o
221981088 0 232865af6 display/dc/bios/bios_parser2.o
222781076 0 233545b3a display/dc/dce/dce_mem_input.o
81180
After:
textdata bss dec hex filename
323412136 0 3447786ad display/dc/bios/bios_parser.o
220701184 0 232545ad6 display/dc/bios/bios_parser2.o
221191172 0 232915afb display/dc/dce/dce_mem_input.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +-
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 +-
drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index 221e0f56389f..65ab225cf542 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -2745,7 +2745,7 @@ static enum bp_result bios_get_board_layout_info(
struct bios_parser *bp;
enum bp_result record_result;
- const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
+ static const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID1,
GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID2,
0, 0
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index dff65c0fe82f..809c4a89b899 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1832,7 +1832,7 @@ static enum bp_result bios_get_board_layout_info(
struct bios_parser *bp;
enum bp_result record_result;
- const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
+ static const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID1,
GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID2,
0, 0
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
index 8aa937f496c4..ed0031d5e021 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
@@ -395,7 +395,7 @@ static void program_size_and_rotation(
{
const struct rect *in_rect = _size->surface_size;
struct rect hw_rect = plane_size->surface_size;
- const uint32_t rotation_angles[ROTATION_ANGLE_COUNT] = {
+ static const uint32_t rotation_angles[ROTATION_ANGLE_COUNT] = {
[ROTATION_ANGLE_0] = 0,
[ROTATION_ANGLE_90] = 1,
[ROTATION_ANGLE_180] = 2,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] drm/amd/display: Recalculate VCPI slots for new DSC connectors
Ok, let's stop and slow down for a minute here since I've repeated myself a few times, and I'd like to figure out what's actually happening here and whether I'm not being clear enough with my explanations, or if there's just some misunderstanding here. I'll start of by trying my best to explain my hesistance in accepting these patches. To be clear, MST with DSC is a big thing in terms of impact. There's a lot of things to consider: * What should the default DSC policy for MST be? Should we keep it on by default so that we don't need to trigger a large number of PBN recalculations and enable DSC on a per-case basis, or are there legitimate reasons to keep DSC off by default (such as potential issues with lossiness down the line). * We have other drivers in the tree that are planning on implementing MST DSC quite soon. Chances are they'll be implementing helpers to do this so this can be supported across the DRM tree, and chances are we'll just have to rewrite and remove most of this code in that case once they do. * amdgpu already has a _lot_ of code that doesn't need to, and shouldn't be there. This ranges from various DC specific helpers that are essentially the same as the helpers that we already implement in the rest of DRM, to misuses of various kernel APIs, and a complete lack of any kind of code style (at least the last time that I checked) in or out of DC. This makes the driver more difficult for people who don't work at AMD but are well accustomed to working on the rest of the kernel, e.g. myself and others, and it's a problem that seriously needs to be solved. Adding more redundant DP helpers that will inevitably get removed is just making the problem worse. With all of this being said: I've been asking the same questions about this patch throughout the whole patch series so far (since it got passed off to you from David's internship ending): * Can we keep DSC enabled by default, so that these patches aren't needed? * If we can't, can we move this into common code so that other drivers can use it? The problem is I haven't received any responses to these questions, other then being told by David a month or two ago that it would be expedient to just accept the patches and move on. Honestly, if discussion had been had about the changes I requested, I would have given my r-b a long time ago. In fact-I really want to give it now! There's multiple patches in this series that would be very useful for other things that are being worked on at the moment, such as the changes to drm_dp_dpcd_read/drm_dp_dpcd_write(). But I really think this needs to be discussed first, and I'm worried that just going ahead and giving my R-B before they have been discussed will further encourage rushing changes like this in the future and continually building more tech debt for ourselves. Please note as well: if anything I've asked for is confusing, or you don't understand what I'm asking or looking for I am more then willing to help explain things and help out as best as I can. I understand that a lot of the developers working on DRM at AMD may have more experience in Windows and Mac land and as a result, trying to get used to the way that we do things in the Linux kernel can be a confusing endeavor. I'm more then happy to help out with this wherever I can, all you need to do is ask. Asking a few questions about something you aren't sure you understand can save both of us a lot of time, and avoid having to go through this many patch respins. In the mean time, I'd be willing to look at what patches from this series that have already been reviewed which could be pushed to drm-misc or friends in the mean time to speed things up a bit. On Tue, 2019-10-01 at 12:17 -0400, mikita.lip...@amd.com wrote: > From: Mikita Lipski > > Since for DSC MST connector's PBN is claculated differently > due to compression, we have to recalculate both PBN and > VCPI slots for that connector. > > This patch proposes to use similair logic as in > dm_encoder_helper_atomic_chek, but since we do not know which > connectors will have DSC enabled we have to recalculate PBN only > after that's determined, which is done in > compute_mst_dsc_configs_for_state. > > Cc: Jerry Zuo > Cc: Harry Wentland > Cc: Lyude Paul > Signed-off-by: Mikita Lipski > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 64 +-- > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 -- > 2 files changed, 59 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 81e30918f9ec..7501ce2233ed 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -4569,6 +4569,27 @@ static void dm_encoder_helper_disable(struct > drm_encoder *encoder) > > } > > +static int convert_dc_color_depth_into_bpc (enum dc_color_depth >
Re: [PATCH] drm/i915: make array hw_engine_mask static, makes object smaller
Quoting Chris Wilson (2019-10-07 17:22:52) > Quoting Colin King (2019-10-07 16:41:51) > > From: Colin Ian King > > > > Don't populate the array hw_engine_mask on the stack but instead make it > > static. Makes the object code smaller by 316 bytes. > > > > Before: > >textdata bss dec hex filename > > 340044388 320 387129738 gpu/drm/i915/gt/intel_reset.o > > > > After: > >textdata bss dec hex filename > > 335284548 320 3839695fc gpu/drm/i915/gt/intel_reset.o > > > > (gcc version 9.2.1, amd64) > > > > Signed-off-by: Colin Ian King > Reviewed-by: Chris Wilson And pushed, thanks for the patch. -Chris
Re: [PATCH v10 1/5] dma-buf: Add dma-buf heaps framework
On Mon, Oct 7, 2019 at 2:21 PM Randy Dunlap wrote: > On 10/7/19 2:18 PM, John Stultz wrote: > > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig > > index a23b6752d11a..6e9c7c4d7447 100644 > > --- a/drivers/dma-buf/Kconfig > > +++ b/drivers/dma-buf/Kconfig > > @@ -44,4 +44,13 @@ config DMABUF_SELFTESTS > > default n > > depends on DMA_SHARED_BUFFER > > > > +menuconfig DMABUF_HEAPS > > + bool "DMA-BUF Userland Memory Heaps" > > + select DMA_SHARED_BUFFER > > + help > > + Choose this option to enable the DMA-BUF userland memory heaps, > >heaps. > > > + this options creates per heap chardevs in /dev/dma_heap/ which > > This > > > + allows userspace to use to allocate dma-bufs that can be shared > > ?? to allocate & use I think the "to use" was just extraneous. I'll drop it. Thanks for catching these. I'll fix them up and respin v11 later this week. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 1/5] dma-buf: Add dma-buf heaps framework
From: "Andrew F. Davis" This framework allows a unified userspace interface for dma-buf exporters, allowing userland to allocate specific types of memory for use in dma-buf sharing. Each heap is given its own device node, which a user can allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. This code is an evoluiton of the Android ION implementation, and a big thanks is due to its authors/maintainers over time for their effort: Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, Laura Abbott, and many other contributors! Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-devel@lists.freedesktop.org Reviewed-by: Benjamin Gaignard Reviewed-by: Brian Starkey Acked-by: Laura Abbott Tested-by: Ayan Kumar Halder Signed-off-by: Andrew F. Davis Signed-off-by: John Stultz --- v2: * Folded down fixes I had previously shared in implementing heaps * Make flags a u64 (Suggested by Laura) * Add PAGE_ALIGN() fix to the core alloc funciton * IOCTL fixups suggested by Brian * Added fixes suggested by Benjamin * Removed core stats mgmt, as that should be implemented by per-heap code * Changed alloc to return a dma-buf fd, rather than a buffer (as it simplifies error handling) v3: * Removed scare-quotes in MAINTAINERS email address * Get rid of .release function as it didn't do anything (from Christoph) * Renamed filp to file (suggested by Christoph) * Split out ioctl handling to separate function (suggested by Christoph) * Add comment documenting PAGE_ALIGN usage (suggested by Brian) * Switch from idr to Xarray (suggested by Brian) * Fixup cdev creation (suggested by Brian) * Avoid EXPORT_SYMBOL until we finalize modules (suggested by Brian) * Make struct dma_heap internal only (folded in from Andrew) * Small cleanups suggested by GregKH * Provide class->devnode callback to get consistent /dev/ subdirectory naming (Suggested by Bjorn) v4: * Folded down dma-heap.h change that was in a following patch * Added fd_flags entry to allocation structure and pass it through to heap code for use on dma-buf fd creation (suggested by Benjamin) v5: * Minor cleanups v6: * Improved error path handling, minor whitespace fixes, both suggested by Brian v7: * Longer Kconfig description to quiet checkpatch warnings * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't working) v8: * Make struct dma_heap_ops consts (Suggested by Christoph) * Checkpatch whitespace fixups v9: * Minor cleanups suggested by Brian Starkey * Rename dma_heap_get_data->dma_heap_get_drvdata suggested by Hilf Danton --- MAINTAINERS | 18 +++ drivers/dma-buf/Kconfig | 9 ++ drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-heap.c| 250 ++ include/linux/dma-heap.h | 59 include/uapi/linux/dma-heap.h | 55 6 files changed, 392 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h diff --git a/MAINTAINERS b/MAINTAINERS index 55199ef7fa74..a49fbf39a9bf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4943,6 +4943,24 @@ F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst T: git git://anongit.freedesktop.org/drm/drm-misc +DMA-BUF HEAPS FRAMEWORK +M: Sumit Semwal +R: Andrew F. Davis +R: Benjamin Gaignard +R: Liam Mark +R: Laura Abbott +R: Brian Starkey +R: John Stultz +S: Maintained +L: linux-me...@vger.kernel.org +L: dri-devel@lists.freedesktop.org +L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) +F: include/uapi/linux/dma-heap.h +F: include/linux/dma-heap.h +F: drivers/dma-buf/dma-heap.c +F: drivers/dma-buf/heaps/* +T: git git://anongit.freedesktop.org/drm/drm-misc + DMA GENERIC OFFLOAD ENGINE SUBSYSTEM M: Vinod Koul L: dmaeng...@vger.kernel.org diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index a23b6752d11a..6e9c7c4d7447 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -44,4 +44,13 @@ config DMABUF_SELFTESTS default n depends on DMA_SHARED_BUFFER +menuconfig DMABUF_HEAPS + bool "DMA-BUF Userland Memory Heaps" + select DMA_SHARED_BUFFER + help + Choose this option to enable the DMA-BUF userland memory heaps, + this options creates per heap chardevs in /dev/dma_heap/ which + allows userspace to use to allocate dma-bufs that can be shared + between drivers. + endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 03479da06422..caee5eb3d351 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -1,6 +1,7 @@ #
[PATCH v10 0/5] DMA-BUF Heaps (destaging ION)
Here is yet another pass at the dma-buf heaps patchset Andrew and I have been working on which tries to destage a fair chunk of ION functionality. The patchset implements per-heap devices which can be opened directly and then an ioctl is used to allocate a dmabuf from the heap. The interface is similar, but much simpler then IONs, only providing an ALLOC ioctl. Also, I've provided relatively simple system and cma heaps. I've booted and tested these patches with AOSP on the HiKey960 using the kernel tree here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap And the userspace changes here: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 Compared to ION, this patchset is missing the system-contig, carveout and chunk heaps, as I don't have a device that uses those, so I'm unable to do much useful validation there. Additionally we have no upstream users of chunk or carveout, and the system-contig has been deprecated in the common/andoid-* kernels, so this should be ok. I've also removed the stats accounting, since any such accounting should be implemented by dma-buf core or the heaps themselves. New in v10: * Fixed missing vmalloc.h include that was causing trouble on mips and sh (Reported-by: kbuild test robot ) thanks -john Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-devel@lists.freedesktop.org Andrew F. Davis (1): dma-buf: Add dma-buf heaps framework John Stultz (4): dma-buf: heaps: Add heap helpers dma-buf: heaps: Add system heap to dmabuf heaps dma-buf: heaps: Add CMA heap to dmabuf heaps kselftests: Add dma-heap test MAINTAINERS | 18 ++ drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 2 + drivers/dma-buf/dma-heap.c| 250 drivers/dma-buf/heaps/Kconfig | 14 + drivers/dma-buf/heaps/Makefile| 4 + drivers/dma-buf/heaps/cma_heap.c | 169 +++ drivers/dma-buf/heaps/heap-helpers.c | 267 ++ drivers/dma-buf/heaps/heap-helpers.h | 55 drivers/dma-buf/heaps/system_heap.c | 122 include/linux/dma-heap.h | 59 include/uapi/linux/dma-heap.h | 55 tools/testing/selftests/dmabuf-heaps/Makefile | 9 + .../selftests/dmabuf-heaps/dmabuf-heap.c | 238 14 files changed, 1273 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 drivers/dma-buf/heaps/Kconfig create mode 100644 drivers/dma-buf/heaps/Makefile create mode 100644 drivers/dma-buf/heaps/cma_heap.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.h create mode 100644 drivers/dma-buf/heaps/system_heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Hillf Danton
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
v3:
* Switch to inline function for to_cma_heap()
* Minor cleanups suggested by Brian
* Fold in new registration style from Andrew
* Folded in changes from Andrew to use simplified page list
from the heap helpers
v4:
* Use the fd_flags when creating dmabuf fd (Suggested by
Benjamin)
* Use precalculated pagecount (Suggested by Andrew)
v6:
* Changed variable names to improve clarity, as suggested
by Brian
v7:
* Use newly lower-cased init_heap_helper_buffer helper
* Use new dmabuf export helper
v8:
* Make struct dma_heap_ops const (Suggested by Christoph)
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Checkpatch whitespace fixups
v9:
* Removing needless check noted by Brian Starkey
* Rename dma_heap_get_data->dma_heap_get_drvdata suggested
by Hilf Danton
* Check signals after clearing memory pages to avoid doing
needless work if the task is killed as suggested by Hilf
---
drivers/dma-buf/heaps/Kconfig| 8 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/cma_heap.c | 169 +++
3 files changed, 178 insertions(+)
create mode 100644 drivers/dma-buf/heaps/cma_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 205052744169..a5eef06c4226 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config DMABUF_HEAPS_CMA
+ bool "DMA-BUF CMA Heap"
+ depends on DMABUF_HEAPS && DMA_CMA
+ help
+ Choose this option to enable dma-buf CMA heap. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index d1808eca2581..6e54cdec3da0 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
new file mode 100644
index ..3fdb00e937c8
--- /dev/null
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF CMA heap exporter
+ *
+ * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Author: for ST-Ericsson.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+struct cma_heap {
+ struct dma_heap *heap;
+ struct cma *cma;
+};
+
+static void cma_heap_free(struct heap_helper_buffer *buffer)
+{
+ struct cma_heap *cma_heap = dma_heap_get_drvdata(buffer->heap);
+ unsigned long nr_pages = buffer->pagecount;
+ struct page *cma_pages = buffer->priv_virt;
+
+ /* free page list */
+ kfree(buffer->pages);
+ /* release memory */
+ cma_release(cma_heap->cma, cma_pages, nr_pages);
+ kfree(buffer);
+}
+
+/* dmabuf heap CMA operations functions */
+static int cma_heap_allocate(struct dma_heap *heap,
+unsigned long len,
+unsigned long fd_flags,
+unsigned long heap_flags)
+{
+ struct cma_heap *cma_heap = dma_heap_get_drvdata(heap);
+ struct heap_helper_buffer *helper_buffer;
+ struct page *cma_pages;
+ size_t size = PAGE_ALIGN(len);
+ unsigned long nr_pages = size >> PAGE_SHIFT;
+ unsigned long align = get_order(size);
+ struct dma_buf *dmabuf;
+ int ret = -ENOMEM;
+ pgoff_t pg;
+
+ if (align > CONFIG_CMA_ALIGNMENT)
+ align = CONFIG_CMA_ALIGNMENT;
+
+ helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
+ if (!helper_buffer)
+ return -ENOMEM;
+
+ init_heap_helper_buffer(helper_buffer,
[PATCH v10 2/5] dma-buf: heaps: Add heap helpers
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Hillf Danton
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Removed cache management performance hack that I had
accidentally folded in.
* Removed stats code that was in helpers
* Lots of checkpatch cleanups
v3:
* Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph)
* Switch to WARN on buffer destroy failure (suggested by Brian)
* buffer->kmap_cnt decrementing cleanup (suggested by Christoph)
* Extra buffer->vaddr checking in dma_heap_dma_buf_kmap
(suggested by Brian)
* Switch to_helper_buffer from macro to inline function
(suggested by Benjamin)
* Rename kmap->vmap (folded in from Andrew)
* Use vmap for vmapping - not begin_cpu_access (folded in from
Andrew)
* Drop kmap for now, as its optional (folded in from Andrew)
* Fold dma_heap_map_user into the single caller (foled in from
Andrew)
* Folded in patch from Andrew to track page list per heap not
sglist, which simplifies the tracking logic
v4:
* Moved dma-heap.h change out to previous patch
v6:
* Minor cleanups and typo fixes suggested by Brian
v7:
* Removed stray ;
* Make init_heap_helper_buffer lowercase, as suggested by Christoph
* Add dmabuf export helper to reduce boilerplate code
v8:
* Remove unused private_flags value
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Fix indentation by using shorter argument names (suggested by
Christoph)
* Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
(suggested by Christoph)
* Checkpatch whitespace fixups
v9:
* Minor cleanups suggested by Brian Starkey
v10:
* Fix missing vmalloc.h inclusion in heap helpers (found by
kbuild test robot )
---
drivers/dma-buf/Makefile | 1 +
drivers/dma-buf/heaps/Makefile | 2 +
drivers/dma-buf/heaps/heap-helpers.c | 267 +++
drivers/dma-buf/heaps/heap-helpers.h | 55 ++
4 files changed, 325 insertions(+)
create mode 100644 drivers/dma-buf/heaps/Makefile
create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index caee5eb3d351..9c190026bfab 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -2,6 +2,7 @@
obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
dma-resv.o seqno-fence.o
obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
+obj-$(CONFIG_DMABUF_HEAPS) += heaps/
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
new file mode 100644
index ..de49898112db
--- /dev/null
+++ b/drivers/dma-buf/heaps/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += heap-helpers.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
new file mode 100644
index ..d9cd39311a69
--- /dev/null
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -0,0 +1,267 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "heap-helpers.h"
+
+void init_heap_helper_buffer(struct heap_helper_buffer *buffer,
+void (*free)(struct heap_helper_buffer *))
+{
+ buffer->priv_virt = NULL;
+ mutex_init(>lock);
+ buffer->vmap_cnt = 0;
+ buffer->vaddr = NULL;
+ buffer->pagecount = 0;
+ buffer->pages = NULL;
+ INIT_LIST_HEAD(>attachments);
+ buffer->free = free;
+}
+
+struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
+ int fd_flags)
+{
+ DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+
+ exp_info.ops = _helper_ops;
+ exp_info.size = buffer->size;
+ exp_info.flags = fd_flags;
+ exp_info.priv = buffer;
+
+ return dma_buf_export(_info);
+}
+
+static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
+{
+ void *vaddr;
+
+ vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
+ if (!vaddr)
+ return ERR_PTR(-ENOMEM);
+
+ return vaddr;
+}
+
[PATCH v10 5/5] kselftests: Add dma-heap test
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Hillf Danton
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switched to use reworked dma-heap apis
v3:
* Add simple mmap
* Utilize dma-buf testdev to test importing
v4:
* Rework to use vgem
* Pass in fd_flags to match interface changes
* Skip . and .. dirs
v6:
* Number of style/cleanups suggested by Brian
v7:
* Whitespace fixup for checkpatch
v8:
* More checkpatch whitespace fixups
v9:
* Better handling error returns out to main, suggested
by Brian Starkey
* Switch to using snprintf, suggested by Brian
---
tools/testing/selftests/dmabuf-heaps/Makefile | 9 +
.../selftests/dmabuf-heaps/dmabuf-heap.c | 238 ++
2 files changed, 247 insertions(+)
create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
b/tools/testing/selftests/dmabuf-heaps/Makefile
new file mode 100644
index ..8c4c36e2972d
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
+#LDLIBS += -lrt -lpthread -lm
+
+# these are all "safe" tests that don't modify
+# system time or require escalated privileges
+TEST_GEN_PROGS = dmabuf-heap
+
+include ../lib.mk
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
new file mode 100644
index ..b36dd9f35c19
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "../../../../include/uapi/linux/dma-heap.h"
+
+#define DEVPATH "/dev/dma_heap"
+
+static int check_vgem(int fd)
+{
+ drm_version_t version = { 0 };
+ char name[5];
+ int ret;
+
+ version.name_len = 4;
+ version.name = name;
+
+ ret = ioctl(fd, DRM_IOCTL_VERSION, );
+ if (ret)
+ return 0;
+
+ return !strcmp(name, "vgem");
+}
+
+static int open_vgem(void)
+{
+ int i, fd;
+ const char *drmstr = "/dev/dri/card";
+
+ fd = -1;
+ for (i = 0; i < 16; i++) {
+ char name[80];
+
+ snprintf(name, 80, "%s%u", drmstr, i);
+
+ fd = open(name, O_RDWR);
+ if (fd < 0)
+ continue;
+
+ if (!check_vgem(fd)) {
+ close(fd);
+ fd = -1;
+ continue;
+ } else {
+ break;
+ }
+ }
+ return fd;
+}
+
+static int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+ struct drm_prime_handle import_handle = {
+ .fd = dma_buf_fd,
+ .flags = 0,
+ .handle = 0,
+};
+ int ret;
+
+ ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+ if (ret == 0)
+ *handle = import_handle.handle;
+ return ret;
+}
+
+static void close_handle(int vgem_fd, uint32_t handle)
+{
+ struct drm_gem_close close = {
+ .handle = handle,
+ };
+
+ ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+static int dmabuf_heap_open(char *name)
+{
+ int ret, fd;
+ char buf[256];
+
+ ret = snprintf(buf, 256, "%s/%s", DEVPATH, name);
+ if (ret < 0) {
+ printf("snprintf failed!\n");
+ return ret;
+ }
+
+ fd = open(buf, O_RDWR);
+ if (fd < 0)
+ printf("open %s failed!\n", buf);
+ return fd;
+}
+
+static int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags,
+int *dmabuf_fd)
+{
+ struct dma_heap_allocation_data data = {
+ .len = len,
+ .fd_flags = O_RDWR | O_CLOEXEC,
+ .heap_flags = flags,
+ };
+ int ret;
+
+ if (!dmabuf_fd)
+ return -EINVAL;
+
+ ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
+ if (ret < 0)
+ return ret;
+ *dmabuf_fd = (int)data.fd;
+ return ret;
+}
+
+static void dmabuf_sync(int fd, int start_stop)
+{
+ struct dma_buf_sync sync = {
+
[PATCH v10 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Hillf Danton
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
* Droped dead system-contig code
v3:
* Whitespace fixups from Benjamin
* Make sure we're zeroing the allocated pages (from Liam)
* Use PAGE_ALIGN() consistently (suggested by Brian)
* Fold in new registration style from Andrew
* Avoid needless dynamic allocation of sys_heap (suggested by
Christoph)
* Minor cleanups
* Folded in changes from Andrew to use simplified page list
from the heap helpers
v4:
* Optimization to allocate pages in chunks, similar to old
pagepool code
* Use fd_flags when creating dmabuf fd (Suggested by Benjamin)
v5:
* Back out large order page allocations (was leaking memory,
as the page array didn't properly track order size)
v6:
* Minor whitespace change suggested by Brian
* Remove unused variable
v7:
* Use newly lower-cased init_heap_helper_buffer helper
* Add system heap DOS avoidance suggested by Laura from ION code
* Use new dmabuf export helper
v8:
* Make struct dma_heap_ops consts (suggested by Christoph)
* Get rid of needless struct system_heap (suggested by Christoph)
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Add forgotten include file to fix build issue on x86
---
drivers/dma-buf/Kconfig | 2 +
drivers/dma-buf/heaps/Kconfig | 6 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/system_heap.c | 122
4 files changed, 131 insertions(+)
create mode 100644 drivers/dma-buf/heaps/Kconfig
create mode 100644 drivers/dma-buf/heaps/system_heap.c
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 6e9c7c4d7447..245b3b4ff69e 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -53,4 +53,6 @@ menuconfig DMABUF_HEAPS
allows userspace to use to allocate dma-bufs that can be shared
between drivers.
+source "drivers/dma-buf/heaps/Kconfig"
+
endmenu
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
new file mode 100644
index ..205052744169
--- /dev/null
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -0,0 +1,6 @@
+config DMABUF_HEAPS_SYSTEM
+ bool "DMA-BUF System Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable the system dmabuf heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index de49898112db..d1808eca2581 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
+obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
new file mode 100644
index ..5db4ef9b4afc
--- /dev/null
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF System heap exporter
+ *
+ * Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2019 Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+struct dma_heap *sys_heap;
+
+static void system_heap_free(struct heap_helper_buffer *buffer)
+{
+ pgoff_t pg;
+
+ for (pg = 0; pg < buffer->pagecount; pg++)
+ __free_page(buffer->pages[pg]);
+ kfree(buffer->pages);
+ kfree(buffer);
+}
+
+static int system_heap_allocate(struct dma_heap *heap,
+ unsigned long len,
+ unsigned long fd_flags,
+ unsigned long heap_flags)
+{
+ struct heap_helper_buffer *helper_buffer;
+ struct dma_buf *dmabuf;
+ int ret = -ENOMEM;
+ pgoff_t pg;
+
+ helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
+ if (!helper_buffer)
+ return -ENOMEM;
+
+ init_heap_helper_buffer(helper_buffer, system_heap_free);
+ helper_buffer->flags = heap_flags;
+ helper_buffer->heap = heap;
+
Re: [PATCH 01/14] drm/amd/display: Add MST atomic routines
Sorry this took me a little while to get to, I've been at XDC.
This is closer then, but still a couple more issues below (also-thank you for
including the changelog!)
On Tue, 2019-10-01 at 12:17 -0400, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> - Adding encoder atomic check to find vcpi slots for a connector
> - Using DRM helper functions to calculate PBN
> - Adding connector atomic check to release vcpi slots if connector
> loses CRTC
> - Calculate PBN and VCPI slots only once during atomic
> check and store them on amdgpu connector to eliminate
> redundant calculation
> - Call drm_dp_mst_atomic_check to verify validity of MST topology
> during state atomic check
>
> v2: squashed previous 3 separate patches, removed DSC PBN calculation,
> and added PBN and VCPI slots properties to amdgpu connector
>
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Nicholas Kazlauskas
> Cc: Lyude Paul
> Signed-off-by: Mikita Lipski
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 +++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 ++
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 42 ++-
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 32 ++
> 4 files changed, 81 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 239b1ae86007..3fc1afccbb33 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4573,6 +4573,41 @@ static int dm_encoder_helper_atomic_check(struct
> drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state
> *conn_state)
> {
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_connector *connector = conn_state->connector;
> + struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
> + struct dm_crtc_state *dm_new_crtc_state =
> to_dm_crtc_state(crtc_state);
> + const struct drm_display_mode *adjusted_mode = _state-
> >adjusted_mode;
> + struct drm_dp_mst_topology_mgr *mst_mgr;
> + struct drm_dp_mst_port *mst_port;
> + int clock, bpp = 0;
> +
> + if (!dm_new_crtc_state)
> + return 0;
You can remove this, crtc_state will never be NULL
> +
> + if (!aconnector->port || !aconnector->dc_sink)
> + return 0;
> +
This makes me think that this should probably just be moved into
amdgpu_dm_mst_types.c since we're not using this encoder check for anything
else, but I'll leave that decision up to you.
> + mst_port = aconnector->port;
> + mst_mgr = >mst_port->mst_mgr;
> +
> + if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
> + return 0;
> +
> + if(!state->duplicated) {
> + bpp = (uint8_t)connector->display_info.bpc * 3;
> + clock = adjusted_mode->clock;
> + aconnector->pbn = drm_dp_calc_pbn_mode(clock, bpp);
We can't do this...
> + }
> + aconnector->vcpi_slots = drm_dp_atomic_find_vcpi_slots(state,
> +mst_mgr,
> +mst_port,
> +aconnector-
> >pbn);
...and we can't do this: you're not allowed to modify anything during the
atomic check other than the atomic states that were passed in (e.g. crtc_state
along with anything in it's respective struct drm_atomic_state). Remember
we're trying to check if a configuration is valid here -before- we've
committed anything to hardware. So, the pbn and vcpi values need to be stored
in the connector's atomic state.
> +
> + if (aconnector->vcpi_slots < 0) {
> + DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n",
> aconnector->vcpi_slots);
> + return aconnector->vcpi_slots;
> + }
> return 0;
> }
>
> @@ -5197,6 +5232,8 @@ void amdgpu_dm_connector_init_helper(struct
> amdgpu_display_manager *dm,
> aconnector->base.dpms = DRM_MODE_DPMS_OFF;
> aconnector->hpd.hpd = AMDGPU_HPD_NONE; /* not used */
> aconnector->audio_inst = -1;
> + aconnector->vcpi_slots = 0;
> + aconnector->pbn = 0;
> mutex_init(>hpd_lock);
>
> /*
> @@ -7592,6 +7629,11 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> if (ret)
> goto fail;
>
> + /* Perform validation of MST topology in the state*/
> + ret = drm_dp_mst_atomic_check(state);
> + if (ret)
> + goto fail;
> +
> if (state->legacy_cursor_update) {
> /*
>* This is a fast cursor update coming from the plane update
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index
[PATCH 2/2] drm/msm: always dump buffer base/size
From: Rob Clark
Even if we are not dumping the buffer's contents, it is useful to log
their base address and size. This makes it easier to see when different
gpu pointers point to a single buffer, for example higher mipmap levels
of a single texture.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_rd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index f8f654301def..0896419ed95d 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -295,7 +295,7 @@ void msm_rd_debugfs_cleanup(struct msm_drm_private *priv)
static void snapshot_buf(struct msm_rd_state *rd,
struct msm_gem_submit *submit, int idx,
- uint64_t iova, uint32_t size)
+ uint64_t iova, uint32_t size, bool full)
{
struct msm_gem_object *obj = submit->bos[idx].obj;
unsigned offset = 0;
@@ -315,6 +315,9 @@ static void snapshot_buf(struct msm_rd_state *rd,
rd_write_section(rd, RD_GPUADDR,
(uint32_t[3]){ iova, size, iova >> 32 }, 12);
+ if (!full)
+ return;
+
/* But only dump the contents of buffers marked READ */
if (!(submit->bos[idx].flags & MSM_SUBMIT_BO_READ))
return;
@@ -378,8 +381,7 @@ void msm_rd_dump_submit(struct msm_rd_state *rd, struct
msm_gem_submit *submit,
rd_write_section(rd, RD_CMD, msg, ALIGN(n, 4));
for (i = 0; i < submit->nr_bos; i++)
- if (should_dump(submit, i))
- snapshot_buf(rd, submit, i, 0, 0);
+ snapshot_buf(rd, submit, i, 0, 0, should_dump(submit, i));
for (i = 0; i < submit->nr_cmds; i++) {
uint32_t szd = submit->cmd[i].size; /* in dwords */
@@ -387,7 +389,7 @@ void msm_rd_dump_submit(struct msm_rd_state *rd, struct
msm_gem_submit *submit,
/* snapshot cmdstream bo's (if we haven't already): */
if (!should_dump(submit, i)) {
snapshot_buf(rd, submit, submit->cmd[i].idx,
- submit->cmd[i].iova, szd * 4);
+ submit->cmd[i].iova, szd * 4, true);
}
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm: fix rd dumping for split-IB1
From: Rob Clark
When IB1 is split into multiple cmd buffers, we'd emit multiple
RD_CMDSTREAM_ADDR per submit. But after this packet is handled
by the cffdump parser, it resets it's known buffers on the next
GPUADDR packet, so subsequent RD_CMDSTREAM_ADDR packets from the
same submit would not find their buffers.
Re-work the loop to snapshot all buffers before RD_CMDSTREAM_ADDR
to avoid this problem.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_rd.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 76d3fdd17bf8..f8f654301def 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -382,7 +382,6 @@ void msm_rd_dump_submit(struct msm_rd_state *rd, struct
msm_gem_submit *submit,
snapshot_buf(rd, submit, i, 0, 0);
for (i = 0; i < submit->nr_cmds; i++) {
- uint64_t iova = submit->cmd[i].iova;
uint32_t szd = submit->cmd[i].size; /* in dwords */
/* snapshot cmdstream bo's (if we haven't already): */
@@ -390,6 +389,11 @@ void msm_rd_dump_submit(struct msm_rd_state *rd, struct
msm_gem_submit *submit,
snapshot_buf(rd, submit, submit->cmd[i].idx,
submit->cmd[i].iova, szd * 4);
}
+ }
+
+ for (i = 0; i < submit->nr_cmds; i++) {
+ uint64_t iova = submit->cmd[i].iova;
+ uint32_t szd = submit->cmd[i].size; /* in dwords */
switch (submit->cmd[i].type) {
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
--
2.21.0
Re: [pull] ttm drm-fixes-5.4
For some reason this didn't end up in patchwork which makes it hard for me to process. Usual suspects are using too old a git to send it or maybe it got ctrl-Ms in it. Dave. On Thu, 3 Oct 2019 at 01:44, Christian König wrote: > > Hi Dave, Daniel, > > we had some problems this cycle sending out TTM fixes because of lack of > time to rebase amd-staging-drm-next. > > Because of this Alex and I decided that I'm going to send out TTM pull > requests separately now. So this is the first small bunch of fixes for 5.4. > > The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c: > >Linux 5.4-rc1 (2019-09-30 10:35:40 -0700) > > are available in the Git repository at: > >https://gitlab.freedesktop.org/ckoenig/linux-drm.git drm-ttm-fixes > > for you to fetch changes up to 3eefcfe9a644be4409691b44c3b2d629d177fb9a: > >drm/ttm: Restore ttm prefaulting (2019-10-02 15:57:34 +0200) > > > Christian König (1): >drm/ttm: fix busy reference in ttm_mem_evict_first > > Thomas Hellstrom (1): >drm/ttm: Restore ttm prefaulting > > drivers/gpu/drm/ttm/ttm_bo.c| 4 ++-- > drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +++- > 2 files changed, 9 insertions(+), 11 deletions(-) > > Regards, > Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: New sysfs interface for privacy screens
On Mon, Oct 07, 2019 at 12:31:08PM -0700, Rajat Jain wrote:
> On Mon, Oct 7, 2019 at 9:19 AM Mat King wrote:
> >
> > On Mon, Oct 7, 2019 at 7:09 AM Sean Paul wrote:
> > >
> > > On Thu, Oct 3, 2019 at 3:57 PM Mat King wrote:
> > > >
> > > > On Thu, Oct 3, 2019 at 2:59 AM Jani Nikula
> > > > wrote:
> > > > >
> > > > > On Wed, 02 Oct 2019, Mat King wrote:
> > > > > > On Wed, Oct 2, 2019 at 4:46 AM Jani Nikula
> > > > > > wrote:
> > > > > >>
> > > > > >> On Wed, 02 Oct 2019, Daniel Thompson
> > > > > >> wrote:
> > > > > >> > On Wed, Oct 02, 2019 at 12:30:05PM +0300, Jani Nikula wrote:
> > > > > >> >> On Tue, 01 Oct 2019, Mat King wrote:
> > > > > >> >> > Resending in plain text mode
> > >
> > > /snip
> > >
> > > >
> > > > So my proposal would now be to add a new standard property to
> > > > drm_connector called "privacy_screen" this property would be an enum
> > > > which can take one of three values.
> > > >
> > > > PRIVACY_UNSUPPORTED - Privacy is not available for this connector
> > > > PRIVACY_DISABLED - Privacy is available but turned off
> > > > PRIVACY_ENABLED - Privacy is available and turned on
> > >
> > > Agree with Jani, use the property presence to determine if it's supported
> >
> > That makes sense; just to confirm can a property be added or removed
> > after the connector is registered?
> >
> > >
> > > >
> > > > When the connector is initized the privacy screen property is set to
> > > > PRIVACY_UNSUPPORTED and cannot be changed unless a drm_privacy_screen
> > > > is registered to the connector. drm_privacy_screen will look something
> > > > like
> > > >
> > > > struct drm_privacy_screen_ops {
> > > > int (*get_privacy_state)(struct drm_privacy_screen *);
> > > > int (*set_privacy_state)(struct drm_privacy_screen *, int);
> > > > }
> > > >
> > > > struct drm_privacy_screen {
> > > > /* The privacy screen device */
> > > > struct device *dev;
> > > >
> > > > /* The connector that the privacy screen is attached */
> > > > struct drm_connector *connector;
> > > >
> > > > /* Ops to get and set the privacy screen state */
> > > > struct drm_privacy_screen_ops *ops;
> > > >
> > > > /* The current state of the privacy screen */
> > > > int state;
> > > > }
> > > >
> > > > Privacy screen device drivers will call a function to register the
> > > > privacy screen with the connector.
> > >
> > > Do we actually need dedicated drivers for privacy screen? It seems
> > > like something that is panel-specific hardware, so I'd suggest just
> > > using the panel driver.
> >
> > The privacy screen is physically part of the display but the control
> > interface, at least in all current use cases, is ACPI. Is there a way
> > to control an ACPI device with the panel driver?
>
> I feel that doing it in a dedicated driver has the advantage that if
> we can standardise the control interface, it can be used across
> different panels. So a new panel can be supported using the existing
> driver by merely instantiating the right ACPI HID "privacy screen"
> device as a child device of the parent display / panel device. This
> parent-child relation would also give the kernel the connection needed
> about "which display does this privacy screen attach to". In future,if
> non-x86 platforms need the feature using a different control interface
> (say via a GPIO driver), the privacy screen driver can be updated to
> support that also.
I might be misunderstanding the scope of this, but if everything is controlled
via drm properties, you could just use a helper function to toggle it on/off? We
have helper libraries for a plethora of optional hardware features already.
Sean
>
> Thanks,
>
> Rajat
>
> >
> > >
> > > Sean
> > >
> > > >
> > > > int drm_privacy_screen_register(struct drm_privacy_screen_ops *ops,
> > > > struct device *dev, struct drm_connector *);
> > > >
> > > > Calling this will set a new field on the connector "struct
> > > > drm_privacy_screen *privacy_screen" and change the value of the
> > > > property to ops->get_privacy_state(). When
> > > > drm_mode_connector_set_obj_prop() is called with the
> > > > privacy_screen_proptery if a privacy_screen is registered to the
> > > > connector the ops->set_privacy_state() will be called with the new
> > > > value.
> > > >
> > > > Setting of this property (and all drm properties) is done in user
> > > > space using ioctrl.
> > > >
> > > > Registering the privacy screen with a connector may be tricky because
> > > > the driver for the privacy screen will need to be able to identify
> > > > which connector it belongs to and we will have to deal with connectors
> > > > being added both before and after the privacy screen device is added
> > > > by it's driver.
> > > >
> > > > How does that sound? I will work on a patch if that all sounds about
> > > > right.
> > > >
> > > > One question I still have is there a way to not accept a value that is
> > > > passed to drm_mode_connector_set_obj_prop()? In this case if a
Re: New sysfs interface for privacy screens
On Mon, Oct 7, 2019 at 9:19 AM Mat King wrote:
>
> On Mon, Oct 7, 2019 at 7:09 AM Sean Paul wrote:
> >
> > On Thu, Oct 3, 2019 at 3:57 PM Mat King wrote:
> > >
> > > On Thu, Oct 3, 2019 at 2:59 AM Jani Nikula
> > > wrote:
> > > >
> > > > On Wed, 02 Oct 2019, Mat King wrote:
> > > > > On Wed, Oct 2, 2019 at 4:46 AM Jani Nikula
> > > > > wrote:
> > > > >>
> > > > >> On Wed, 02 Oct 2019, Daniel Thompson
> > > > >> wrote:
> > > > >> > On Wed, Oct 02, 2019 at 12:30:05PM +0300, Jani Nikula wrote:
> > > > >> >> On Tue, 01 Oct 2019, Mat King wrote:
> > > > >> >> > Resending in plain text mode
> >
> > /snip
> >
> > >
> > > So my proposal would now be to add a new standard property to
> > > drm_connector called "privacy_screen" this property would be an enum
> > > which can take one of three values.
> > >
> > > PRIVACY_UNSUPPORTED - Privacy is not available for this connector
> > > PRIVACY_DISABLED - Privacy is available but turned off
> > > PRIVACY_ENABLED - Privacy is available and turned on
> >
> > Agree with Jani, use the property presence to determine if it's supported
>
> That makes sense; just to confirm can a property be added or removed
> after the connector is registered?
>
> >
> > >
> > > When the connector is initized the privacy screen property is set to
> > > PRIVACY_UNSUPPORTED and cannot be changed unless a drm_privacy_screen
> > > is registered to the connector. drm_privacy_screen will look something
> > > like
> > >
> > > struct drm_privacy_screen_ops {
> > > int (*get_privacy_state)(struct drm_privacy_screen *);
> > > int (*set_privacy_state)(struct drm_privacy_screen *, int);
> > > }
> > >
> > > struct drm_privacy_screen {
> > > /* The privacy screen device */
> > > struct device *dev;
> > >
> > > /* The connector that the privacy screen is attached */
> > > struct drm_connector *connector;
> > >
> > > /* Ops to get and set the privacy screen state */
> > > struct drm_privacy_screen_ops *ops;
> > >
> > > /* The current state of the privacy screen */
> > > int state;
> > > }
> > >
> > > Privacy screen device drivers will call a function to register the
> > > privacy screen with the connector.
> >
> > Do we actually need dedicated drivers for privacy screen? It seems
> > like something that is panel-specific hardware, so I'd suggest just
> > using the panel driver.
>
> The privacy screen is physically part of the display but the control
> interface, at least in all current use cases, is ACPI. Is there a way
> to control an ACPI device with the panel driver?
I feel that doing it in a dedicated driver has the advantage that if
we can standardise the control interface, it can be used across
different panels. So a new panel can be supported using the existing
driver by merely instantiating the right ACPI HID "privacy screen"
device as a child device of the parent display / panel device. This
parent-child relation would also give the kernel the connection needed
about "which display does this privacy screen attach to". In future,if
non-x86 platforms need the feature using a different control interface
(say via a GPIO driver), the privacy screen driver can be updated to
support that also.
Thanks,
Rajat
>
> >
> > Sean
> >
> > >
> > > int drm_privacy_screen_register(struct drm_privacy_screen_ops *ops,
> > > struct device *dev, struct drm_connector *);
> > >
> > > Calling this will set a new field on the connector "struct
> > > drm_privacy_screen *privacy_screen" and change the value of the
> > > property to ops->get_privacy_state(). When
> > > drm_mode_connector_set_obj_prop() is called with the
> > > privacy_screen_proptery if a privacy_screen is registered to the
> > > connector the ops->set_privacy_state() will be called with the new
> > > value.
> > >
> > > Setting of this property (and all drm properties) is done in user
> > > space using ioctrl.
> > >
> > > Registering the privacy screen with a connector may be tricky because
> > > the driver for the privacy screen will need to be able to identify
> > > which connector it belongs to and we will have to deal with connectors
> > > being added both before and after the privacy screen device is added
> > > by it's driver.
> > >
> > > How does that sound? I will work on a patch if that all sounds about
> > > right.
> > >
> > > One question I still have is there a way to not accept a value that is
> > > passed to drm_mode_connector_set_obj_prop()? In this case if a privacy
> > > screen is not registered the property must stay PRIVACY_UNSUPPORTED
> > > and if a privacy screen is registered then PRIVACY_UNSUPPORTED must
> > > never be set.
[Bug 111483] FreeSync LFC breaks under certain circumstances, causing either tearing or stutter
https://bugs.freedesktop.org/show_bug.cgi?id=111483 --- Comment #1 from tempel.jul...@gmail.com --- I think there is a realistic chance that this issue has been tackled by this commit: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.5-wip=109b3e3e13507ad0908ff00bc7eb759ed41b88be However, I don't own an LFC capable display anymore and can't test. Though I think it might be a candidate for backporting to 5.4? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A
This patch enables Dynamic Range and Mastering InfoFrame on GXL, GXM and G12A. Cc: Neil Armstrong Signed-off-by: Jonas Karlman Reviewed-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c index 022286dc6ab2..3bb7ffe5fc39 100644 --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c @@ -977,6 +977,11 @@ static int meson_dw_hdmi_bind(struct device *dev, struct device *master, dw_plat_data->input_bus_format = MEDIA_BUS_FMT_YUV8_1X24; dw_plat_data->input_bus_encoding = V4L2_YCBCR_ENC_709; + if (dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxl-dw-hdmi") || + dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxm-dw-hdmi") || + dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-g12a-dw-hdmi")) + dw_plat_data->use_drm_infoframe = true; + platform_set_drvdata(pdev, meson_dw_hdmi); meson_dw_hdmi->hdmi = dw_hdmi_bind(pdev, encoder, -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/sun4i: Enable DRM InfoFrame support on H6
This patch enables Dynamic Range and Mastering InfoFrame on H6.
Cc: Maxime Ripard
Cc: Jernej Skrabec
Signed-off-by: Jonas Karlman
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 ++
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index a44dca4b0219..e8a317d5ba19 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -226,6 +226,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
sun8i_hdmi_phy_init(hdmi->phy);
plat_data->mode_valid = hdmi->quirks->mode_valid;
+ plat_data->use_drm_infoframe = hdmi->quirks->use_drm_infoframe;
sun8i_hdmi_phy_set_ops(hdmi->phy, plat_data);
platform_set_drvdata(pdev, hdmi);
@@ -300,6 +301,7 @@ static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks
= {
static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
.mode_valid = sun8i_dw_hdmi_mode_valid_h6,
+ .use_drm_infoframe = true,
};
static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index d707c9171824..8e64945167e9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -179,6 +179,7 @@ struct sun8i_dw_hdmi_quirks {
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
const struct drm_display_mode *mode);
unsigned int set_rate : 1;
+ unsigned int use_drm_infoframe : 1;
};
struct sun8i_dw_hdmi {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399
This patch enables Dynamic Range and Mastering InfoFrame on RK3328 and RK3399.
Cc: Sandy Huang
Cc: Heiko Stuebner
Signed-off-by: Jonas Karlman
Reviewed-by: Heiko Stuebner
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 906891b03a38..7f56d8c3491d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -450,6 +450,7 @@ static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data
= {
.phy_ops = _hdmi_phy_ops,
.phy_name = "inno_dw_hdmi_phy2",
.phy_force_vendor = true,
+ .use_drm_infoframe = true,
};
static struct rockchip_hdmi_chip_data rk3399_chip_data = {
@@ -464,6 +465,7 @@ static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data
= {
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
.phy_data = _chip_data,
+ .use_drm_infoframe = true,
};
static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support
Add support for configuring Dynamic Range and Mastering InfoFrame from
the hdr_output_metadata connector property.
This patch adds a use_drm_infoframe flag to dw_hdmi_plat_data that platform
drivers use to signal when Dynamic Range and Mastering infoframes is supported.
This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version,
and only GXL support DRM InfoFrame.
These changes were based on work done by Zheng Yang
to support DRM InfoFrame on the Rockchip 4.4 BSP kernel at [1] and [2]
[1] https://github.com/rockchip-linux/kernel/tree/develop-4.4
[2]
https://github.com/rockchip-linux/kernel/commit/d1943fde81ff41d7cca87f4a42f03992e90bddd5
Cc: Zheng Yang
Signed-off-by: Jonas Karlman
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 81 +++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++
include/drm/bridge/dw_hdmi.h | 1 +
3 files changed, 119 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a15fbf71b9d7..fdc29869d75a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1743,6 +1744,41 @@ static void hdmi_config_vendor_specific_infoframe(struct
dw_hdmi *hdmi,
HDMI_FC_DATAUTO0_VSD_MASK);
}
+static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi)
+{
+ const struct drm_connector_state *conn_state = hdmi->connector.state;
+ struct hdmi_drm_infoframe frame;
+ u8 buffer[30];
+ ssize_t err;
+ int i;
+
+ if (!hdmi->plat_data->use_drm_infoframe)
+ return;
+
+ hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_DISABLE,
+ HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
+
+ err = drm_hdmi_infoframe_set_hdr_metadata(, conn_state);
+ if (err < 0)
+ return;
+
+ err = hdmi_drm_infoframe_pack(, buffer, sizeof(buffer));
+ if (err < 0) {
+ dev_err(hdmi->dev, "Failed to pack drm infoframe: %zd\n", err);
+ return;
+ }
+
+ hdmi_writeb(hdmi, frame.version, HDMI_FC_DRM_HB0);
+ hdmi_writeb(hdmi, frame.length, HDMI_FC_DRM_HB1);
+
+ for (i = 0; i < frame.length; i++)
+ hdmi_writeb(hdmi, buffer[4 + i], HDMI_FC_DRM_PB0 + i);
+
+ hdmi_writeb(hdmi, 1, HDMI_FC_DRM_UP);
+ hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_ENABLE,
+ HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
+}
+
static void hdmi_av_composer(struct dw_hdmi *hdmi,
const struct drm_display_mode *mode)
{
@@ -2064,6 +2100,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
/* HDMI Initialization Step F - Configure AVI InfoFrame */
hdmi_config_AVI(hdmi, mode);
hdmi_config_vendor_specific_infoframe(hdmi, mode);
+ hdmi_config_drm_infoframe(hdmi);
} else {
dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
}
@@ -2230,6 +2267,45 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
return ret;
}
+static bool hdr_metadata_equal(const struct drm_connector_state *old_state,
+ const struct drm_connector_state *new_state)
+{
+ struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
+ struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
+
+ if (!old_blob || !new_blob)
+ return old_blob == new_blob;
+
+ if (old_blob->length != new_blob->length)
+ return false;
+
+ return !memcmp(old_blob->data, new_blob->data, old_blob->length);
+}
+
+static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector_state *old_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_connector_state *new_state =
+ drm_atomic_get_new_connector_state(state, connector);
+ struct drm_crtc *crtc = new_state->crtc;
+ struct drm_crtc_state *crtc_state;
+
+ if (!crtc)
+ return 0;
+
+ if (!hdr_metadata_equal(old_state, new_state)) {
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ crtc_state->mode_changed = true;
+ }
+
+ return 0;
+}
+
static void dw_hdmi_connector_force(struct drm_connector *connector)
{
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
@@ -2254,6 +2330,7 @@ static const struct drm_connector_funcs
dw_hdmi_connector_funcs = {
static const struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs
[PATCH v2 0/4] drm/bridge: dw-hdmi: Add support for HDR metadata
Add support for HDR metadata using the hdr_output_metadata connector property, configure Dynamic Range and Mastering InfoFrame accordingly. A use_drm_infoframe flag is added to dw_hdmi_plat_data that platform drivers can use to signal when Dynamic Range and Mastering infoframes is supported. This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version, and only GXL support DRM InfoFrame. The first patch add functionality to configure DRM InfoFrame based on the hdr_output_metadata connector property. The remaining patches sets the use_drm_infoframe flag on some SoCs supporting Dynamic Range and Mastering InfoFrame. v2 has been runtime tested on a Rock64 (RK3328) and Rock Pi 4 (RK3399), only build tested for Amlogic and Allwinner. Changes in v2: * address comments from Andrzej Hajda - renamed blob_equal to hdr_metadata_equal - renamed drm_infoframe flag to use_drm_infoframe - use hdmi_drm_infoframe_pack and a loop to write regs - remove hdmi version check in hdmi_config_drm_infoframe Jonas Karlman (4): drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399 drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A drm/sun4i: Enable DRM InfoFrame support on H6 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 81 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 ++ drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 ++ drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 + include/drm/bridge/dw_hdmi.h| 1 + 7 files changed, 129 insertions(+) -- 2.17.1
[Bug 111913] AMD Navi10 GPU powerplay issues when using two DisplayPort connectors
https://bugs.freedesktop.org/show_bug.cgi?id=111913 --- Comment #4 from Stefan Rehm --- Just to clarify: this is not just a "cosmetic" issue. The computer is barely usable. Application take extremely long to start and/or run slowly. Also the files in sysfs (/sys/class/drm/card0/device/pp_*) dont return anything anymore and lm_senors reports N/A for all sensors except the fan speed. -- 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 v3 3/5] drm/rockchip: Add optional support for CRTC gamma LUT
On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> Add an optional CRTC gamma LUT support, and enable it on RK3288.
> This is currently enabled via a separate address resource,
> which needs to be specified in the devicetree.
>
> The address resource is required because on some SoCs, such as
> RK3288, the LUT address is after the MMU address, and the latter
> is supported by a different driver. This prevents the DRM driver
> from requesting an entire register space.
>
> The current implementation works for RGB 10-bit tables, as that
> is what seems to work on RK3288.
>
> Signed-off-by: Ezequiel Garcia
> Reviewed-by: Douglas Anderson
> Reviewed-by: Jacopo Mondi
> ---
> Changes from v2:
> * None.
>
> Changes from v1:
> * drop explicit linear LUT after finding a proper
> way to disable gamma correction.
> * avoid setting gamma is the CRTC is not active.
> * s/int/unsigned int as suggested by Jacopo.
> * only enable color management and set gamma size
> if gamma LUT is supported, suggested by Doug.
> * drop the reg-names usage, and instead just use indexed reg
> specifiers, suggested by Doug.
>
> Changes from RFC:
> * Request (an optional) address resource for the LUT.
> * Drop support for RK3399, which doesn't seem to work
> out of the box and needs more research.
> * Support pass-thru setting when GAMMA_LUT is NULL.
> * Add a check for the gamma size, as suggested by Ilia.
> * Move gamma setting to atomic_commit_tail, as pointed
> out by Jacopo/Laurent, is the correct way.
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 114
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 ++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
> 4 files changed, 126 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index dba352ec0ee3..fd1d987698ab 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -17,6 +17,7 @@
> #include "rockchip_drm_drv.h"
> #include "rockchip_drm_fb.h"
> #include "rockchip_drm_gem.h"
> +#include "rockchip_drm_vop.h"
>
> static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> .destroy = drm_gem_fb_destroy,
> @@ -112,6 +113,8 @@ rockchip_atomic_helper_commit_tail_rpm(struct
> drm_atomic_state *old_state)
>
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
>
> + rockchip_drm_vop_gamma_set(old_state);
> +
Instead of duplicating the commit_tail helper, could you just implement
.atomic_begin() and call this from there? I think the only hitch is if you
need this to be completed before crtc->atomic_enable(), at which point you
might need to call it from vop_crtc_atomic_enable() and then detect that in
atomic_begin()
That would prevent the revert in patch 1 and keep rockchip on the helper train.
Sean
> drm_atomic_helper_commit_modeset_enables(dev, old_state);
>
> drm_atomic_helper_commit_planes(dev, old_state,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 2f821c58007c..3a49794c6a43 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -141,6 +141,7 @@ struct vop {
>
> uint32_t *regsbak;
> void __iomem *regs;
> + void __iomem *lut_regs;
>
> /* physical map length of vop register */
> uint32_t len;
> @@ -1193,6 +1194,102 @@ static void vop_wait_for_irq_handler(struct vop *vop)
> synchronize_irq(vop->irq);
> }
>
> +static bool vop_dsp_lut_is_enable(struct vop *vop)
> +{
> + return vop_read_reg(vop, 0, >data->common->dsp_lut_en);
> +}
> +
> +static void vop_crtc_write_gamma_lut(struct vop *vop, struct drm_crtc *crtc)
> +{
> + struct drm_color_lut *lut = crtc->state->gamma_lut->data;
> + unsigned int i;
> +
> + for (i = 0; i < crtc->gamma_size; i++) {
> + u32 word;
> +
> + word = (drm_color_lut_extract(lut[i].red, 10) << 20) |
> +(drm_color_lut_extract(lut[i].green, 10) << 10) |
> + drm_color_lut_extract(lut[i].blue, 10);
> + writel(word, vop->lut_regs + i * 4);
> + }
> +}
> +
> +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> +struct drm_crtc_state *old_state)
> +{
> + unsigned int idle;
> + int ret;
> +
> + /*
> + * In order to write the LUT to the internal RAM memory,
> + * we need to first make sure the dsp_lut_en bit is cleared.
> + */
> + spin_lock(>reg_lock);
> + VOP_REG_SET(vop, common, dsp_lut_en, 0);
> + vop_cfg_done(vop);
> + spin_unlock(>reg_lock);
> +
> + /*
> + * If the CRTC is not active, dsp_lut_en will not get cleared.
> + * Apparently we still need to do the above step to for
> + * gamma
Re: [PATCH v3] drm/amd: Fix Kconfig indentation
On Mon, Oct 7, 2019 at 1:33 PM Krzysztof Kozlowski wrote: > > Adjust indentation from spaces to tab (+optional two spaces) as in > coding style with command like: > $ sed -e 's/^/\t/' -i */Kconfig > > Signed-off-by: Krzysztof Kozlowski Applied. Thanks! Alex > > --- > > Changes since v2: > 1. Split AMD and i915 to separate patches. > --- > drivers/gpu/drm/Kconfig | 4 ++-- > drivers/gpu/drm/amd/display/Kconfig | 32 ++--- > 2 files changed, 18 insertions(+), 18 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 108e1b7f4564..7cb6e4eb99e8 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -226,9 +226,9 @@ config DRM_AMDGPU > tristate "AMD GPU" > depends on DRM && PCI && MMU > select FW_LOADER > -select DRM_KMS_HELPER > + select DRM_KMS_HELPER > select DRM_SCHED > -select DRM_TTM > + select DRM_TTM > select POWER_SUPPLY > select HWMON > select BACKLIGHT_CLASS_DEVICE > diff --git a/drivers/gpu/drm/amd/display/Kconfig > b/drivers/gpu/drm/amd/display/Kconfig > index 1bbe762ee6ba..313183b80032 100644 > --- a/drivers/gpu/drm/amd/display/Kconfig > +++ b/drivers/gpu/drm/amd/display/Kconfig > @@ -23,16 +23,16 @@ config DRM_AMD_DC_DCN2_0 > depends on DRM_AMD_DC && X86 > depends on DRM_AMD_DC_DCN1_0 > help > - Choose this option if you want to have > - Navi support for display engine > + Choose this option if you want to have > + Navi support for display engine > > config DRM_AMD_DC_DCN2_1 > -bool "DCN 2.1 family" > -depends on DRM_AMD_DC && X86 > -depends on DRM_AMD_DC_DCN2_0 > -help > -Choose this option if you want to have > -Renoir support for display engine > + bool "DCN 2.1 family" > + depends on DRM_AMD_DC && X86 > + depends on DRM_AMD_DC_DCN2_0 > + help > + Choose this option if you want to have > + Renoir support for display engine > > config DRM_AMD_DC_DSC_SUPPORT > bool "DSC support" > @@ -41,16 +41,16 @@ config DRM_AMD_DC_DSC_SUPPORT > depends on DRM_AMD_DC_DCN1_0 > depends on DRM_AMD_DC_DCN2_0 > help > - Choose this option if you want to have > - Dynamic Stream Compression support > + Choose this option if you want to have > + Dynamic Stream Compression support > > config DRM_AMD_DC_HDCP > -bool "Enable HDCP support in DC" > -depends on DRM_AMD_DC > -help > - Choose this option > - if you want to support > - HDCP authentication > + bool "Enable HDCP support in DC" > + depends on DRM_AMD_DC > + help > +Choose this option > +if you want to support > +HDCP authentication > > config DEBUG_KERNEL_DC > bool "Enable kgdb break in DC" > -- > 2.17.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111913] AMD Navi10 GPU powerplay issues when using two DisplayPort connectors
https://bugs.freedesktop.org/show_bug.cgi?id=111913 --- Comment #3 from Stefan Rehm --- I can confirm this. My card is a PowerColor Radeon RX 5700 XT Red Dragon. As soon as I connect a second monitor, I get the same errors in dmesg as Timur Kristóf described. Unfortunately, the workaround with the HDMI connection does not seem to work in my case. It does not matter wether the monitors are connected via DP or HDMI. One important fact: the problem started with kernel 5.4-rc1 and persists in 5.4-rc2, but 5.3 works fine (except for the problem with the high idle power consumption, but that is a different story :))! -- 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 3/5] backlight: pwm_bl: drop use of int_pow()
On 07/10/2019 17.28, Daniel Thompson wrote: > On Thu, Sep 19, 2019 at 04:06:18PM +0200, Rasmus Villemoes wrote: > > It feels like there is some rationale missing in the description here. > > What is the benefit of replacing the explicit int_pow() with the > implicit multiplications? > > > Daniel. > > >> >> We could (and a following patch will) change to use a power-of-2 scale, >> but for a fixed small exponent of 3, there's no advantage in using >> repeated squaring. ^^ Apart from the function call overhead (and resulting register pressure etc.), using int_pow is less efficient (for an exponent of 3, it ends up doing four 64x64 multiplications instead of just two). But feel free to drop it, I'm not going to pursue it further - it just seemed like a sensible thing to do while I was optimizing the code anyway. [At the time I wrote the patch, this was also the only user of int_pow in the tree, so it also allowed removing int_pow altogether.] Rasmus
Re: [PATCH] drm/amdkfd: add missing void argument to function kgd2kfd_init
On 2019-10-07 12:08 p.m., Alex Deucher wrote:
> On Sat, Oct 5, 2019 at 1:58 PM Colin King wrote:
>> From: Colin Ian King
>>
>> Function kgd2kfd_init is missing a void argument, add it
>> to clean up the non-ANSI function declaration.
>>
>> Signed-off-by: Colin Ian King
> Applied. thanks!
Thank you!
>
> Alex
>
>> ---
>> drivers/gpu/drm/amd/amdkfd/kfd_module.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> index 986ff52d5750..f4b7f7e6c40e 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> @@ -82,7 +82,7 @@ static void kfd_exit(void)
>> kfd_chardev_exit();
>> }
>>
>> -int kgd2kfd_init()
>> +int kgd2kfd_init(void)
>> {
>> return kfd_init();
>> }
>> --
>> 2.20.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
Re: [PATCH v1 2/2] drm: delete drmP.h + drm_os_linux.h
Reviewed-by: Lyude Paul On Mon, 2019-10-07 at 19:12 +0200, Sam Ravnborg wrote: > There is finally no more users left in the kernel of drmP.h > and drm_os_linux.h (drmP.h was the only user left). > Delete the header files and delete the corresponding todo entry. > > When we started this quest there was more than 700 users of drmP.h. > And drmP.h was a huge cover-it-all header file. > > Daniel Vetter is the one that followed the work from start > to the end and in between many people have contributed to the > removal process - thanks to everyone! > > Signed-off-by: Sam Ravnborg > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > --- > Documentation/gpu/todo.rst | 12 - > include/drm/drmP.h | 103 - > include/drm/drm_os_linux.h | 55 > 3 files changed, 170 deletions(-) > delete mode 100644 include/drm/drmP.h > delete mode 100644 include/drm/drm_os_linux.h > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 8dc147c93c9c..79785559d711 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -299,18 +299,6 @@ connector register/unregister fixes > Core refactorings > = > > -Clean up the DRM header mess > - > - > -The DRM subsystem originally had only one huge global header, ``drmP.h``. > This > -is now split up, but many source files still include it. The remaining part > of > -the cleanup work here is to replace any ``#include `` by only > the > -headers needed (and fixing up any missing pre-declarations in the headers). > - > -In the end no .c file should need to include ``drmP.h`` anymore. > - > -Contact: Daniel Vetter > - > Make panic handling work > > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > deleted file mode 100644 > index 037b1f7a87a5.. > --- a/include/drm/drmP.h > +++ /dev/null > @@ -1,103 +0,0 @@ > -/* > - * Internal Header for the Direct Rendering Manager > - * > - * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > - * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > - * Copyright (c) 2009-2010, Code Aurora Forum. > - * All rights reserved. > - * > - * Author: Rickard E. (Rik) Faith > - * Author: Gareth Hughes > - * > - * Permission is hereby granted, free of charge, to any person obtaining a > - * copy of this software and associated documentation files (the > "Software"), > - * to deal in the Software without restriction, including without > limitation > - * the rights to use, copy, modify, merge, publish, distribute, sublicense, > - * and/or sell copies of the Software, and to permit persons to whom the > - * Software is furnished to do so, subject to the following conditions: > - * > - * The above copyright notice and this permission notice (including the > next > - * paragraph) shall be included in all copies or substantial portions of > the > - * Software. > - * > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES > OR > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > - * OTHER DEALINGS IN THE SOFTWARE. > - */ > - > -#ifndef _DRM_P_H_ > -#define _DRM_P_H_ > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#include > -#include > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -struct module; > - > -struct device_node; > -struct videomode; > -struct dma_resv; > -struct dma_buf_attachment; > - > -struct pci_dev; > -struct pci_controller; > - > -/* > - * NOTE: drmP.h is obsolete - do NOT add anything to this file > - * > - * Do not include drmP.h in new files. > - * Work is ongoing to remove drmP.h includes from existing files > - */ > - > -#endif > diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h > deleted file mode 100644 > index ee8d61b64f29.. > --- a/include/drm/drm_os_linux.h > +++ /dev/null > @@ -1,55 +0,0 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > -/** > - * \file drm_os_linux.h > - * OS abstraction macros. > - */ > - > -#include /* For task queue support */ >
Re: [PATCH v1 1/2] drm_dp_cec: drop use of drmP.h
Reviewed-by: Lyude Paul
On Mon, 2019-10-07 at 19:12 +0200, Sam Ravnborg wrote:
> drmP.h is deprecated and will be deleted.
> Replace use with proper header.
>
> Divide header includes in blocks while touching these.
>
> Build tested with various archtectures and configs.
>
> Signed-off-by: Sam Ravnborg
> Fixes: ae85b0df124f6928 ("drm_dp_cec: add connector info support.")
> Cc: Dariusz Marcinkiewicz
> Cc: Hans Verkuil
> Cc: Lyude Paul
> Cc: Ben Skeggs
> ---
> drivers/gpu/drm/drm_dp_cec.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index b457c16c3a8b..3ab2609f9ec7 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -8,10 +8,12 @@
> #include
> #include
> #include
> +
> +#include
> +
> #include
> +#include
> #include
> -#include
> -#include
>
> /*
> * Unfortunately it turns out that we have a chicken-and-egg situation
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: liboutput: thoughts about shared library on top of DRM/KMS
On Mon, 7 Oct 2019 at 19:16, Keith Packard wrote: > Daniel Stone writes: > > I think there would be a load of value in starting with simple helpers > > which can be used independently of any larger scheme, tackling that > > list above. > > Yeah, a helper library that didn't enforce at tonne of policy and just > let the user glue things together on their own is probably going to be > more generally usable by existing and new systems. > > I definitely like the idea of stealing the best parts of all existing > systems and trying to make them work together. > > How many libraries we end up with isn't nearly as important to me as > making sure they work well together; common data types, similar style, > etc. Yeah, totally AOL. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm: delete drmP.h + drm_os_linux.h
On Mon, Oct 07, 2019 at 07:12:24PM +0200, Sam Ravnborg wrote: > There is finally no more users left in the kernel of drmP.h > and drm_os_linux.h (drmP.h was the only user left). > Delete the header files and delete the corresponding todo entry. > > When we started this quest there was more than 700 users of drmP.h. > And drmP.h was a huge cover-it-all header file. > > Daniel Vetter is the one that followed the work from start > to the end and in between many people have contributed to the > removal process - thanks to everyone! > > Signed-off-by: Sam Ravnborg > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul \o/ Nice work! Reviewed-by: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > --- > Documentation/gpu/todo.rst | 12 - > include/drm/drmP.h | 103 - > include/drm/drm_os_linux.h | 55 > 3 files changed, 170 deletions(-) > delete mode 100644 include/drm/drmP.h > delete mode 100644 include/drm/drm_os_linux.h > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 8dc147c93c9c..79785559d711 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -299,18 +299,6 @@ connector register/unregister fixes > Core refactorings > = > > -Clean up the DRM header mess > - > - > -The DRM subsystem originally had only one huge global header, ``drmP.h``. > This > -is now split up, but many source files still include it. The remaining part > of > -the cleanup work here is to replace any ``#include `` by only the > -headers needed (and fixing up any missing pre-declarations in the headers). > - > -In the end no .c file should need to include ``drmP.h`` anymore. > - > -Contact: Daniel Vetter > - > Make panic handling work > > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > deleted file mode 100644 > index 037b1f7a87a5.. > --- a/include/drm/drmP.h > +++ /dev/null > @@ -1,103 +0,0 @@ > -/* > - * Internal Header for the Direct Rendering Manager > - * > - * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > - * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > - * Copyright (c) 2009-2010, Code Aurora Forum. > - * All rights reserved. > - * > - * Author: Rickard E. (Rik) Faith > - * Author: Gareth Hughes > - * > - * Permission is hereby granted, free of charge, to any person obtaining a > - * copy of this software and associated documentation files (the "Software"), > - * to deal in the Software without restriction, including without limitation > - * the rights to use, copy, modify, merge, publish, distribute, sublicense, > - * and/or sell copies of the Software, and to permit persons to whom the > - * Software is furnished to do so, subject to the following conditions: > - * > - * The above copyright notice and this permission notice (including the next > - * paragraph) shall be included in all copies or substantial portions of the > - * Software. > - * > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > - * OTHER DEALINGS IN THE SOFTWARE. > - */ > - > -#ifndef _DRM_P_H_ > -#define _DRM_P_H_ > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#include > -#include > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -struct module; > - > -struct device_node; > -struct videomode; > -struct dma_resv; > -struct dma_buf_attachment; > - > -struct pci_dev; > -struct pci_controller; > - > -/* > - * NOTE: drmP.h is obsolete - do NOT add anything to this file > - * > - * Do not include drmP.h in new files. > - * Work is ongoing to remove drmP.h includes from existing files > - */ > - > -#endif > diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h > deleted file mode 100644 > index ee8d61b64f29.. > --- a/include/drm/drm_os_linux.h > +++ /dev/null > @@ -1,55 +0,0 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > -/** > - * \file drm_os_linux.h > - * OS abstraction macros. > - */ > - > -#include /* For task queue support
Re: [PATCH v1 1/2] drm_dp_cec: drop use of drmP.h
On Mon, Oct 07, 2019 at 07:12:23PM +0200, Sam Ravnborg wrote:
> drmP.h is deprecated and will be deleted.
> Replace use with proper header.
>
> Divide header includes in blocks while touching these.
>
> Build tested with various archtectures and configs.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Fixes: ae85b0df124f6928 ("drm_dp_cec: add connector info support.")
> Cc: Dariusz Marcinkiewicz
> Cc: Hans Verkuil
> Cc: Lyude Paul
> Cc: Ben Skeggs
> ---
> drivers/gpu/drm/drm_dp_cec.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index b457c16c3a8b..3ab2609f9ec7 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -8,10 +8,12 @@
> #include
> #include
> #include
> +
> +#include
> +
> #include
> +#include
> #include
> -#include
> -#include
>
> /*
> * Unfortunately it turns out that we have a chicken-and-egg situation
> --
> 2.20.1
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: liboutput: thoughts about shared library on top of DRM/KMS
Daniel Stone writes: > I think there would be a load of value in starting with simple helpers > which can be used independently of any larger scheme, tackling that > list above. Yeah, a helper library that didn't enforce at tonne of policy and just let the user glue things together on their own is probably going to be more generally usable by existing and new systems. I definitely like the idea of stealing the best parts of all existing systems and trying to make them work together. How many libraries we end up with isn't nearly as important to me as making sure they work well together; common data types, similar style, etc. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #17 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Ahzo from comment #14) > Another way to prevent these frequent resume failures, while preserving the > intention of this commit, is to simply call amdgpu_ib_pool_init directly > after calling amdgpu_ucode_create_bo instead of directly before that. > Attached is a patch doing it that way. I'm not sure I understand why the patch helps. You are just changing the order of two memory allocations. The order shouldn't matter. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 1/5] drm/bridge: analogix-anx78xx: add support for avdd33 regulator
Hi Brian,
Thank you for the patch.
On Sun, Oct 06, 2019 at 09:45:05PM -0400, Brian Masney wrote:
> Add support for the avdd33 regulator to the analogix-anx78xx driver.
> Note that the regulator is currently enabled during driver probe and
> disabled when the driver is removed. This is currently how the
> downstream MSM kernel sources do this.
>
> Let's not merge this upstream for the mean time until I get the external
> display fully working on the Nexus 5 and then I can submit proper
> support then that powers down this regulator in the power off function.
Please then also update the corresponding DT bindings to describe the
avdd33 supply.
> Signed-off-by: Brian Masney
> ---
> Changes since v1:
> - None
>
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 33 +++
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index dec3f7e66aa0..e25fae36dbe1 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -56,6 +56,7 @@ static const u8 anx781x_i2c_addresses[] = {
>
> struct anx78xx_platform_data {
> struct regulator *dvdd10;
> + struct regulator *avdd33;
> struct gpio_desc *gpiod_hpd;
> struct gpio_desc *gpiod_pd;
> struct gpio_desc *gpiod_reset;
> @@ -715,10 +716,42 @@ static int anx78xx_start(struct anx78xx *anx78xx)
> return err;
> }
>
> +static void anx78xx_disable_regulator_action(void *_data)
> +{
> + struct anx78xx_platform_data *pdata = _data;
> +
> + regulator_disable(pdata->avdd33);
> +}
> +
> static int anx78xx_init_pdata(struct anx78xx *anx78xx)
> {
> struct anx78xx_platform_data *pdata = >pdata;
> struct device *dev = >client->dev;
> + int err;
> +
> + /* 3.3V digital core power regulator */
> + pdata->avdd33 = devm_regulator_get(dev, "avdd33");
> + if (IS_ERR(pdata->avdd33)) {
> + err = PTR_ERR(pdata->avdd33);
> + if (err != -EPROBE_DEFER)
> + DRM_ERROR("avdd33 regulator not found\n");
> +
> + return err;
> + }
> +
> + err = regulator_enable(pdata->avdd33);
> + if (err) {
> + DRM_ERROR("Failed to enable avdd33 regulator: %d\n", err);
> + return err;
> + }
> +
> + err = devm_add_action(dev, anx78xx_disable_regulator_action,
> + pdata);
> + if (err < 0) {
> + dev_err(dev, "Failed to setup regulator cleanup action %d\n",
> + err);
> + return err;
> + }
>
> /* 1.0V digital core power regulator */
> pdata->dvdd10 = devm_regulator_get(dev, "dvdd10");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Fix SPI module alias for panels used by omapdrm
Hi Sam, On Mon, Oct 07, 2019 at 07:22:56PM +0200, Sam Ravnborg wrote: > Hi Laurent. > On Mon, Oct 07, 2019 at 08:07:56PM +0300, Laurent Pinchart wrote: > > Hello, > > > > This patch series fixes a module alias issue with the five recently > > added panel drivers used by omapdrm. > > > > Before those panel drivers, omapdrm had custom drivers for the panels, > > and prefixed the OF compatible strings with an "omapdss," prefix. The > > SPI device IDs are constructed by stripping the OF compatible string > > from the prefix, resulting in the "omapdss," prefix being removed, but > > the subsequence OF vendor prefix being kept. The SPI drivers thus had > > modules aliases that contained the vendor prefix. > > > > Now that the panels are supported by standard drivers and the "omapdss," > > prefix is removed, the SPI device IDs are stripped from the OF vendor > > prefix. As the new panel drivers copied the module aliases from the > > omapdrm-specific drivers, they contain the vendor prefix in their SPI > > module aliases, and are thus not loaded automatically. > > > > Fix this by removing the vendor prefix from the SPI modules aliases in > > the drivers. For consistency reason, the manual module aliases are also > > moved to use an SPI module table. > > Good explanation - thanks. > > > These patches are based on the drm-misc-fixes branch as they fix v5.4 > > regressions. > > > > Laurent Pinchart (5): > > drm/panel: lg-lb035q02: Fix SPI alias > > drm/panel: nec-nl8048hl11: Fix SPI alias > > drm/panel: sony-acx565akm: Fix SPI alias > > drm/panel: tpo-td028ttec1: Fix SPI alias > > drm/panel: tpo-td043mtea1: Fix SPI alias > > Full series is: > Acked-by: Sam Ravnborg > > I expect someone else to pick them up or that you apply them. I'd like someone to test the patches first if possible :-) Tomi, could you then pick these up as v5.4 fixes ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: liboutput: thoughts about shared library on top of DRM/KMS
Hi, On Mon, 7 Oct 2019 at 18:35, Daniel Stone wrote: > There are definitely a few annoying problems which we should have > common resolution for. I'm thinking of: > - [...] Oh, and add backlight handling to that list. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: customize DPCD brightness control for specific panel
On Mon, 2019-10-07 at 12:08 +0300, Jani Nikula wrote: > The problem with the EDID quirks is that exposing the quirks sticks out > like a sore thumb. Thus far all of it has been contained in drm_edid.c > and they affect how the EDID gets parsed, for all drivers. Obviously > this could be changed, but is it the right thing to do? > > What I suggested was, check the OUI only, and if it matches, do > more. Perhaps there's something in the 0x300 range of DPCD offsets that > you can read? Or perhaps you need to write the source OUI first, and > then do that. My issue isn't really with identifying the panel from EDID rather than DPCD, whichever identifier is most specific is probably the best thing to use. It's more that this quirk is identified in common code but only applied in one driver. If this panel were ever to be attached to some other source, they might well want to apply the same kind of fix. My (admittedly naïve) reading of the OUI handshake process is that when the source device writes an OUI to DP_SOURCE_OUI it is telling the sink "I'm about to issue commands that conform to _this_ vendor's own conventions". If that convention communicates information that is entirely contained within AUXCH transactions (and doesn't, for example, require looking at some other strapping pin or external device) then in principle it doesn't matter if the source device "matches" that OUI; it would be legal for an AMD GPU to write the same sequence and expect the same reaction, should that panel be attached to an AMD GPU. So, it would be nice to know exactly what that protocol is meant to do, if it applies only to this specific panel or anything else with the same TCON, how one would identify such TCONs in the wild other than EDID, if it relies on an external PWM or something, etc. And it might make sense for now to make this a (shudder) driver-specific EDID quirk rather than match by DPCD, at least until we know if the panel is ever seen attached to other source devices and if the OUI convention is self-contained. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: liboutput: thoughts about shared library on top of DRM/KMS
Hi Keith, On Sat, 5 Oct 2019 at 17:16, Keith Packard wrote: > During XDC this year, we heard a few presentations and had a lot of > hallway talk about sharing code for driving DRM/KMS for display. Definitely. That would be great. > I think the general consensus is that there is enough shared > functionality between all of the various DRM/KMS clients that we can > start thinking about building a library that deals with the complexity > of DRM/KMS and can help take full advantage of the hardware. Y. Ish. There are definitely a few annoying problems which we should have common resolution for. I'm thinking of: - libliftoff's mandate of solving the views -> planes conundrum; it's a ton of work to do properly, is extremely easy to get wrong, and will ultimately require platform-specific tweaks as well - similarly, working backwards from 'I want to light these connectors up' to determine the plane -> CRTC -> connector routing, which also requires a mixture of brute force and platform-specific tweaks - currently this is mostly just to handle asymmetric CRTC capabilities (e.g. max clock), but is being complicated by the requirement for merged CRTCs - EDID/CEA/etc parsing, which is not only tedious and sucks, but requires a quirks database - sharing a mode-selection description language and semantics might also be nice - parsing DRM properties - particularly enums - is painful enough that Weston wrote its own internal wrapper around it - TTY handling :( Having those as helper libraries would solve a _lot_ of issues Weston has today. But pushing much more than that - thinking of rendering and transforms in particular - is going to be actively harmful to us. Given that we want to work on not just KMS, but nested-Wayland, nested-X11, remote protocols like RDP/Waltham, and even mixed local/remote setups where some outputs are KMS and others are at the end of an RTSP stream, I'm going to need to implement most of this stuff anyway. Delegating everything to a big does-everything-KMS library means that I'll just have to do it twice, and hope there isn't too much impedance mismatch between the results. I also worry about both colour management and timing: the users are going to have radically different wants and requirements for those, and a one-size-fits-all API seems like it would be tough to deal with. I think there would be a load of value in starting with simple helpers which can be used independently of any larger scheme, tackling that list above. Most of them have good prior art: libliftoff is working from Weston's plane-assignment code, Mutter has pretty good CRTC <-> connector routing IIRC, EDID parsing is best in the X server, DRM properties are probably best done in either Weston or kmscube (depending on the enum vs. string efficiency tradeoff), and TTY handling is probably most robust in the X server. If I was starting a compositor from scratch then I'd probably think pretty hard about a does-everything-for-you library, but with libweston already existing, it's a much harder sell tbh. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] gpu: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- Changes since v2: 1. Split AMD and i915 to separate patches. --- drivers/gpu/drm/Kconfig | 6 +++--- drivers/gpu/drm/bridge/Kconfig | 8 drivers/gpu/drm/lima/Kconfig | 2 +- drivers/gpu/drm/mgag200/Kconfig | 8 drivers/gpu/drm/nouveau/Kconfig | 2 +- drivers/gpu/drm/omapdrm/displays/Kconfig | 6 +++--- drivers/gpu/drm/omapdrm/dss/Kconfig | 12 ++-- drivers/gpu/drm/rockchip/Kconfig | 8 drivers/gpu/drm/udl/Kconfig | 2 +- drivers/gpu/vga/Kconfig | 2 +- 10 files changed, 28 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index e67c194c2aca..108e1b7f4564 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -207,8 +207,8 @@ config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI && MMU select FW_LOADER -select DRM_KMS_HELPER -select DRM_TTM + select DRM_KMS_HELPER + select DRM_TTM select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE @@ -266,7 +266,7 @@ config DRM_VKMS If M is selected the module will be called vkms. config DRM_ATI_PCIGART -bool + bool source "drivers/gpu/drm/exynos/Kconfig" diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 1cc9f502c1f2..a5aa7ec16000 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -60,10 +60,10 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW select DRM_KMS_HELPER select DRM_PANEL ---help--- - This is a driver for the display bridges of - GE B850v3 that convert dual channel LVDS - to DP++. This is used with the i.MX6 imx-ldb - driver. You are likely to say N here. + This is a driver for the display bridges of + GE B850v3 that convert dual channel LVDS + to DP++. This is used with the i.MX6 imx-ldb + driver. You are likely to say N here. config DRM_NXP_PTN3460 tristate "NXP PTN3460 DP/LVDS bridge" diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig index bb4ddc6bb0a6..652af7f50ea9 100644 --- a/drivers/gpu/drm/lima/Kconfig +++ b/drivers/gpu/drm/lima/Kconfig @@ -10,4 +10,4 @@ config DRM_LIMA depends on OF select DRM_SCHED help - DRM driver for ARM Mali 400/450 GPUs. +DRM driver for ARM Mali 400/450 GPUs. diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig index 76fee0fbdcae..4b31ef376abc 100644 --- a/drivers/gpu/drm/mgag200/Kconfig +++ b/drivers/gpu/drm/mgag200/Kconfig @@ -6,8 +6,8 @@ config DRM_MGAG200 select DRM_VRAM_HELPER help This is a KMS driver for the MGA G200 server chips, it - does not support the original MGA G200 or any of the desktop - chips. It requires 0.3.0 of the modesetting userspace driver, - and a version of mga driver that will fail on KMS enabled - devices. +does not support the original MGA G200 or any of the desktop +chips. It requires 0.3.0 of the modesetting userspace driver, +and a version of mga driver that will fail on KMS enabled +devices. diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 3558df043592..9c990266e876 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -2,7 +2,7 @@ config DRM_NOUVEAU tristate "Nouveau (NVIDIA) cards" depends on DRM && PCI && MMU -select FW_LOADER + select FW_LOADER select DRM_KMS_HELPER select DRM_TTM select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig b/drivers/gpu/drm/omapdrm/displays/Kconfig index 240dda102845..b562a8cd61bf 100644 --- a/drivers/gpu/drm/omapdrm/displays/Kconfig +++ b/drivers/gpu/drm/omapdrm/displays/Kconfig @@ -8,18 +8,18 @@ config DRM_OMAP_ENCODER_OPA362 through a GPIO. config DRM_OMAP_ENCODER_TPD12S015 -tristate "TPD12S015 HDMI ESD protection and level shifter" + tristate "TPD12S015 HDMI ESD protection and level shifter" help Driver for TPD12S015, which offers HDMI ESD protection and level shifting. config DRM_OMAP_CONNECTOR_HDMI -tristate "HDMI Connector" + tristate "HDMI Connector" help Driver for a generic HDMI connector. config DRM_OMAP_CONNECTOR_ANALOG_TV -tristate "Analog TV Connector" + tristate "Analog TV Connector" help Driver for a generic analog TV connector. diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig
[PATCH v3] drm/i915: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- Changes since v2: 1. Split AMD and i915 to separate patches. --- drivers/gpu/drm/i915/Kconfig | 12 +-- drivers/gpu/drm/i915/Kconfig.debug | 144 ++--- 2 files changed, 78 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 0d21402945ab..3c6d57df262d 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -76,7 +76,7 @@ config DRM_I915_CAPTURE_ERROR This option enables capturing the GPU state when a hang is detected. This information is vital for triaging hangs and assists in debugging. Please report any hang to -https://bugs.freedesktop.org/enter_bug.cgi?product=DRI + https://bugs.freedesktop.org/enter_bug.cgi?product=DRI for triaging. If in doubt, say "Y". @@ -105,11 +105,11 @@ config DRM_I915_USERPTR If in doubt, say "Y". config DRM_I915_GVT -bool "Enable Intel GVT-g graphics virtualization host support" -depends on DRM_I915 -depends on 64BIT -default n -help + bool "Enable Intel GVT-g graphics virtualization host support" + depends on DRM_I915 + depends on 64BIT + default n + help Choose this option if you want to enable Intel GVT-g graphics virtualization technology host support with integrated graphics. With GVT-g, it's possible to have one integrated graphics diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 00786a142ff0..eea79125b3ea 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -1,34 +1,34 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_I915_WERROR -bool "Force GCC to throw an error instead of a warning when compiling" -# As this may inadvertently break the build, only allow the user -# to shoot oneself in the foot iff they aim really hard -depends on EXPERT -# We use the dependency on !COMPILE_TEST to not be enabled in -# allmodconfig or allyesconfig configurations -depends on !COMPILE_TEST + bool "Force GCC to throw an error instead of a warning when compiling" + # As this may inadvertently break the build, only allow the user + # to shoot oneself in the foot iff they aim really hard + depends on EXPERT + # We use the dependency on !COMPILE_TEST to not be enabled in + # allmodconfig or allyesconfig configurations + depends on !COMPILE_TEST select HEADER_TEST -default n -help - Add -Werror to the build flags for (and only for) i915.ko. - Do not enable this unless you are writing code for the i915.ko module. + default n + help + Add -Werror to the build flags for (and only for) i915.ko. + Do not enable this unless you are writing code for the i915.ko module. - Recommended for driver developers only. + Recommended for driver developers only. - If in doubt, say "N". + If in doubt, say "N". config DRM_I915_DEBUG -bool "Enable additional driver debugging" -depends on DRM_I915 -select DEBUG_FS -select PREEMPT_COUNT -select REFCOUNT_FULL -select I2C_CHARDEV -select STACKDEPOT -select DRM_DP_AUX_CHARDEV -select X86_MSR # used by igt/pm_rpm -select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) -select DRM_DEBUG_MM if DRM=y + bool "Enable additional driver debugging" + depends on DRM_I915 + select DEBUG_FS + select PREEMPT_COUNT + select REFCOUNT_FULL + select I2C_CHARDEV + select STACKDEPOT + select DRM_DP_AUX_CHARDEV + select X86_MSR # used by igt/pm_rpm + select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) + select DRM_DEBUG_MM if DRM=y select DRM_DEBUG_SELFTEST select DMABUF_SELFTESTS select SW_SYNC # signaling validation framework (igt/syncobj*) @@ -36,14 +36,14 @@ config DRM_I915_DEBUG select DRM_I915_SELFTEST select DRM_I915_DEBUG_RUNTIME_PM select DRM_I915_DEBUG_MMIO -default n -help - Choose this option to turn on extra driver debugging that may affect - performance but will catch some internal issues. + default n + help + Choose this option to turn on extra driver debugging that may affect + performance but will catch some internal issues. - Recommended for driver developers only. + Recommended for driver developers only. - If in doubt, say "N". + If in doubt, say "N". config
[PATCH v3] drm/amd: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- Changes since v2: 1. Split AMD and i915 to separate patches. --- drivers/gpu/drm/Kconfig | 4 ++-- drivers/gpu/drm/amd/display/Kconfig | 32 ++--- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 108e1b7f4564..7cb6e4eb99e8 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -226,9 +226,9 @@ config DRM_AMDGPU tristate "AMD GPU" depends on DRM && PCI && MMU select FW_LOADER -select DRM_KMS_HELPER + select DRM_KMS_HELPER select DRM_SCHED -select DRM_TTM + select DRM_TTM select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 1bbe762ee6ba..313183b80032 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -23,16 +23,16 @@ config DRM_AMD_DC_DCN2_0 depends on DRM_AMD_DC && X86 depends on DRM_AMD_DC_DCN1_0 help - Choose this option if you want to have - Navi support for display engine + Choose this option if you want to have + Navi support for display engine config DRM_AMD_DC_DCN2_1 -bool "DCN 2.1 family" -depends on DRM_AMD_DC && X86 -depends on DRM_AMD_DC_DCN2_0 -help -Choose this option if you want to have -Renoir support for display engine + bool "DCN 2.1 family" + depends on DRM_AMD_DC && X86 + depends on DRM_AMD_DC_DCN2_0 + help + Choose this option if you want to have + Renoir support for display engine config DRM_AMD_DC_DSC_SUPPORT bool "DSC support" @@ -41,16 +41,16 @@ config DRM_AMD_DC_DSC_SUPPORT depends on DRM_AMD_DC_DCN1_0 depends on DRM_AMD_DC_DCN2_0 help - Choose this option if you want to have - Dynamic Stream Compression support + Choose this option if you want to have + Dynamic Stream Compression support config DRM_AMD_DC_HDCP -bool "Enable HDCP support in DC" -depends on DRM_AMD_DC -help - Choose this option - if you want to support - HDCP authentication + bool "Enable HDCP support in DC" + depends on DRM_AMD_DC + help +Choose this option +if you want to support +HDCP authentication config DEBUG_KERNEL_DC bool "Enable kgdb break in DC" -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH TRIVIAL v2] gpu: Fix Kconfig indentation
On Mon, 7 Oct 2019 at 18:09, Alex Deucher wrote: > > On Mon, Oct 7, 2019 at 7:39 AM Jani Nikula > wrote: > > > > On Fri, 04 Oct 2019, Krzysztof Kozlowski wrote: > > > drivers/gpu/drm/i915/Kconfig | 12 +- > > > drivers/gpu/drm/i915/Kconfig.debug | 144 +++ > > > > Please split these out to a separate patch. Can't speak for others, but > > the patch looks like it'll be conflicts galore and a problem to manage > > if merged in one big lump. > > Yes, it would be nice to have the amd patch separate as well. I'll split the AMD and i915 although I am not sure if it is sense to split such trivial patch per each driver. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Fix SPI module alias for panels used by omapdrm
Hi, On Mon, Oct 07, 2019 at 08:07:56PM +0300, Laurent Pinchart wrote: > This patch series fixes a module alias issue with the five recently > added panel drivers used by omapdrm. For the whole series: Reviewed-by: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Fix SPI module alias for panels used by omapdrm
Hi Laurent. On Mon, Oct 07, 2019 at 08:07:56PM +0300, Laurent Pinchart wrote: > Hello, > > This patch series fixes a module alias issue with the five recently > added panel drivers used by omapdrm. > > Before those panel drivers, omapdrm had custom drivers for the panels, > and prefixed the OF compatible strings with an "omapdss," prefix. The > SPI device IDs are constructed by stripping the OF compatible string > from the prefix, resulting in the "omapdss," prefix being removed, but > the subsequence OF vendor prefix being kept. The SPI drivers thus had > modules aliases that contained the vendor prefix. > > Now that the panels are supported by standard drivers and the "omapdss," > prefix is removed, the SPI device IDs are stripped from the OF vendor > prefix. As the new panel drivers copied the module aliases from the > omapdrm-specific drivers, they contain the vendor prefix in their SPI > module aliases, and are thus not loaded automatically. > > Fix this by removing the vendor prefix from the SPI modules aliases in > the drivers. For consistency reason, the manual module aliases are also > moved to use an SPI module table. Good explanation - thanks. > > These patches are based on the drm-misc-fixes branch as they fix v5.4 > regressions. > > Laurent Pinchart (5): > drm/panel: lg-lb035q02: Fix SPI alias > drm/panel: nec-nl8048hl11: Fix SPI alias > drm/panel: sony-acx565akm: Fix SPI alias > drm/panel: tpo-td028ttec1: Fix SPI alias > drm/panel: tpo-td043mtea1: Fix SPI alias Full series is: Acked-by: Sam Ravnborg I expect someone else to pick them up or that you apply them. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: panels: fix spi aliases of former omap panels
Hi Andreas,
On Mon, Oct 07, 2019 at 07:14:28PM +0200, Andreas Kemnade wrote:
> On Mon, 7 Oct 2019 19:04:46 +0200 Sebastian Reichel wrote:
> > On Mon, Oct 07, 2019 at 06:41:30PM +0200, Andreas Kemnade wrote:
> > > When the panels were moved from omap/displays/ to panel/
> > > omapdss prefix was stripped, which cause spi modalias
> > > to not contain the vendor-prefix anymore.
> > >
> > > so we had e.g. in former times:
> > > compatible=omapdss,tpo,td028ttec1 -> modalias=spi:tpo,td028ttec1
> > > now:
> > > compatible=tpo,td028ttec1 -> modalias=spi:td028ttec1
> > >
> > > This is consistent with other drivers. Tested the td028ttec.c
> > > only, but the pattern looks the same for the other ones.
> > >
> > > Fixes: 45f16c82db7e8 ("drm/omap: displays: Remove unused panel drivers")
> > > Signed-off-by: Andreas Kemnade
> > > ---
> >
> > Patch looks good to me, but you have one false positive.
> >
> > > [...]
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> > > b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> > > index 46cd9a2501298..838d39a263f53 100644
> > > --- a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> > > +++ b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> > > @@ -204,7 +204,7 @@ static int ls037v7dw01_remove(struct platform_device
> > > *pdev)
> > > }
> > >
> > > static const struct of_device_id ls037v7dw01_of_match[] = {
> > > - { .compatible = "sharp,ls037v7dw01", },
> > > + { .compatible = "ls037v7dw01", },
> > > { /* sentinel */ },
> > > };
> >
> > The DT compatible should have a vendor prefix.
>
> oops, sorry, but I it seems that Laurent already has submitted a fix.
Seems we've been racing each other :-S Feel free to submit a v2 of this
patch if you think it's better than my series. As long as the problem
gets fixed, I'll be happy :-)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm_dp_cec: drop use of drmP.h
drmP.h is deprecated and will be deleted.
Replace use with proper header.
Divide header includes in blocks while touching these.
Build tested with various archtectures and configs.
Signed-off-by: Sam Ravnborg
Fixes: ae85b0df124f6928 ("drm_dp_cec: add connector info support.")
Cc: Dariusz Marcinkiewicz
Cc: Hans Verkuil
Cc: Lyude Paul
Cc: Ben Skeggs
---
drivers/gpu/drm/drm_dp_cec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index b457c16c3a8b..3ab2609f9ec7 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -8,10 +8,12 @@
#include
#include
#include
+
+#include
+
#include
+#include
#include
-#include
-#include
/*
* Unfortunately it turns out that we have a chicken-and-egg situation
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/2] drm: delete drmP.h + drm_os_linux.h
There is finally no more users left in the kernel of drmP.h and drm_os_linux.h (drmP.h was the only user left). Delete the header files and delete the corresponding todo entry. When we started this quest there was more than 700 users of drmP.h. And drmP.h was a huge cover-it-all header file. Daniel Vetter is the one that followed the work from start to the end and in between many people have contributed to the removal process - thanks to everyone! Signed-off-by: Sam Ravnborg Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter --- Documentation/gpu/todo.rst | 12 - include/drm/drmP.h | 103 - include/drm/drm_os_linux.h | 55 3 files changed, 170 deletions(-) delete mode 100644 include/drm/drmP.h delete mode 100644 include/drm/drm_os_linux.h diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 8dc147c93c9c..79785559d711 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -299,18 +299,6 @@ connector register/unregister fixes Core refactorings = -Clean up the DRM header mess - - -The DRM subsystem originally had only one huge global header, ``drmP.h``. This -is now split up, but many source files still include it. The remaining part of -the cleanup work here is to replace any ``#include `` by only the -headers needed (and fixing up any missing pre-declarations in the headers). - -In the end no .c file should need to include ``drmP.h`` anymore. - -Contact: Daniel Vetter - Make panic handling work diff --git a/include/drm/drmP.h b/include/drm/drmP.h deleted file mode 100644 index 037b1f7a87a5.. --- a/include/drm/drmP.h +++ /dev/null @@ -1,103 +0,0 @@ -/* - * Internal Header for the Direct Rendering Manager - * - * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. - * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. - * Copyright (c) 2009-2010, Code Aurora Forum. - * All rights reserved. - * - * Author: Rickard E. (Rik) Faith - * Author: Gareth Hughes - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the next - * paragraph) shall be included in all copies or substantial portions of the - * Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. - */ - -#ifndef _DRM_P_H_ -#define _DRM_P_H_ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -struct module; - -struct device_node; -struct videomode; -struct dma_resv; -struct dma_buf_attachment; - -struct pci_dev; -struct pci_controller; - -/* - * NOTE: drmP.h is obsolete - do NOT add anything to this file - * - * Do not include drmP.h in new files. - * Work is ongoing to remove drmP.h includes from existing files - */ - -#endif diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h deleted file mode 100644 index ee8d61b64f29.. --- a/include/drm/drm_os_linux.h +++ /dev/null @@ -1,55 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/** - * \file drm_os_linux.h - * OS abstraction macros. - */ - -#include/* For task queue support */ -#include -#include -#include - -/** Current process ID */ -#define DRM_CURRENTPID task_pid_nr(current) -#define DRM_UDELAY(d) udelay(d) -/** Read a byte from a MMIO region */ -#define DRM_READ8(map, offset) readb(((void __iomem *)(map)->handle) + (offset)) -/** Read a word from a MMIO region */ -#define DRM_READ16(map, offset) readw(((void __iomem *)(map)->handle) + (offset)) -/** Read a
[PATCH v1 0/2]: Finally delete drmP.h
One user of drmP.h sneaked in after the merge window. Drop the use of drmP.h and delete the header file for good. Small band-aid on top of not going to xdc :-) Build tested with various architectures and configs. Sam Sam Ravnborg (2): drm_dp_cec: drop use of drmP.h drm: delete drmP.h + drm_os_linux.h Documentation/gpu/todo.rst | 12 - drivers/gpu/drm/drm_dp_cec.c | 6 ++- include/drm/drmP.h | 103 --- include/drm/drm_os_linux.h | 55 --- 4 files changed, 4 insertions(+), 172 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/panel: sony-acx565akm: Fix SPI alias
The panel-sony-acx565akm driver incorrectly includes the OF vendor
prefix in its SPI alias. Fix it, and move the manual alias to an SPI
module device table.
Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
Reported-by: H. Nikolaus Schaller
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
index 305259b58767..3d5b9c4f68d9 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -684,9 +684,17 @@ static const struct of_device_id acx565akm_of_match[] = {
MODULE_DEVICE_TABLE(of, acx565akm_of_match);
+static const struct spi_device_id acx565akm_ids[] = {
+ { "acx565akm", 0 },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(spi, acx565akm_ids);
+
static struct spi_driver acx565akm_driver = {
.probe = acx565akm_probe,
.remove = acx565akm_remove,
+ .id_table = acx565akm_ids,
.driver = {
.name = "panel-sony-acx565akm",
.of_match_table = acx565akm_of_match,
@@ -695,7 +703,6 @@ static struct spi_driver acx565akm_driver = {
module_spi_driver(acx565akm_driver);
-MODULE_ALIAS("spi:sony,acx565akm");
MODULE_AUTHOR("Nokia Corporation");
MODULE_DESCRIPTION("Sony ACX565AKM LCD Panel Driver");
MODULE_LICENSE("GPL");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/panel: nec-nl8048hl11: Fix SPI alias
The panel-nec-nl8048hl11 driver incorrectly includes the OF vendor
prefix in its SPI alias. Fix it, and move the manual alias to an SPI
module device table.
Fixes: df439abe6501 ("drm/panel: Add driver for the NEC NL8048HL11 panel")
Reported-by: H. Nikolaus Schaller
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
index 299b217c83e1..20f17e46e65d 100644
--- a/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
@@ -230,9 +230,17 @@ static const struct of_device_id nl8048_of_match[] = {
MODULE_DEVICE_TABLE(of, nl8048_of_match);
+static const struct spi_device_id nl8048_ids[] = {
+ { "nl8048hl11", 0 },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(spi, nl8048_ids);
+
static struct spi_driver nl8048_driver = {
.probe = nl8048_probe,
.remove = nl8048_remove,
+ .id_table = nl8048_ids,
.driver = {
.name = "panel-nec-nl8048hl11",
.pm = _pm_ops,
@@ -242,7 +250,6 @@ static struct spi_driver nl8048_driver = {
module_spi_driver(nl8048_driver);
-MODULE_ALIAS("spi:nec,nl8048hl11");
MODULE_AUTHOR("Erik Gilling ");
MODULE_DESCRIPTION("NEC-NL8048HL11 Driver");
MODULE_LICENSE("GPL");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/panel: lg-lb035q02: Fix SPI alias
The panel-lg-lb035q02 driver incorrectly includes the OF vendor prefix
in its SPI alias. Fix it, and move the manual alias to an SPI module
device table.
Fixes: f5b0c6542476 ("drm/panel: Add driver for the LG Philips LB035Q02 panel")
Reported-by: H. Nikolaus Schaller
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-lb035q02.c
b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
index fc82a525b071..ee4379729a5b 100644
--- a/drivers/gpu/drm/panel/panel-lg-lb035q02.c
+++ b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
@@ -220,9 +220,17 @@ static const struct of_device_id lb035q02_of_match[] = {
MODULE_DEVICE_TABLE(of, lb035q02_of_match);
+static const struct spi_device_id lb035q02_ids[] = {
+ { "lb035q02", 0 },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(spi, lb035q02_ids);
+
static struct spi_driver lb035q02_driver = {
.probe = lb035q02_probe,
.remove = lb035q02_remove,
+ .id_table = lb035q02_ids,
.driver = {
.name = "panel-lg-lb035q02",
.of_match_table = lb035q02_of_match,
@@ -231,7 +239,6 @@ static struct spi_driver lb035q02_driver = {
module_spi_driver(lb035q02_driver);
-MODULE_ALIAS("spi:lgphilips,lb035q02");
MODULE_AUTHOR("Tomi Valkeinen ");
MODULE_DESCRIPTION("LG.Philips LB035Q02 LCD Panel driver");
MODULE_LICENSE("GPL");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Fix SPI module alias for panels used by omapdrm
Hello, This patch series fixes a module alias issue with the five recently added panel drivers used by omapdrm. Before those panel drivers, omapdrm had custom drivers for the panels, and prefixed the OF compatible strings with an "omapdss," prefix. The SPI device IDs are constructed by stripping the OF compatible string from the prefix, resulting in the "omapdss," prefix being removed, but the subsequence OF vendor prefix being kept. The SPI drivers thus had modules aliases that contained the vendor prefix. Now that the panels are supported by standard drivers and the "omapdss," prefix is removed, the SPI device IDs are stripped from the OF vendor prefix. As the new panel drivers copied the module aliases from the omapdrm-specific drivers, they contain the vendor prefix in their SPI module aliases, and are thus not loaded automatically. Fix this by removing the vendor prefix from the SPI modules aliases in the drivers. For consistency reason, the manual module aliases are also moved to use an SPI module table. These patches are based on the drm-misc-fixes branch as they fix v5.4 regressions. Laurent Pinchart (5): drm/panel: lg-lb035q02: Fix SPI alias drm/panel: nec-nl8048hl11: Fix SPI alias drm/panel: sony-acx565akm: Fix SPI alias drm/panel: tpo-td028ttec1: Fix SPI alias drm/panel: tpo-td043mtea1: Fix SPI alias drivers/gpu/drm/panel/panel-lg-lb035q02.c| 9 - drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 9 - drivers/gpu/drm/panel/panel-sony-acx565akm.c | 9 - drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 3 +-- drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 9 - 5 files changed, 33 insertions(+), 6 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/panel: tpo-td028ttec1: Fix SPI alias
The panel-tpo-td028ttec1 driver incorrectly includes the OF vendor
prefix in its SPI alias. Fix it.
Fixes: 415b8dd08711 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel")
Reported-by: H. Nikolaus Schaller
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
index d7b2e34626ef..f2baff827f50 100644
--- a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
@@ -375,8 +375,7 @@ static const struct of_device_id td028ttec1_of_match[] = {
MODULE_DEVICE_TABLE(of, td028ttec1_of_match);
static const struct spi_device_id td028ttec1_ids[] = {
- { "tpo,td028ttec1", 0},
- { "toppoly,td028ttec1", 0 },
+ { "td028ttec1", 0 },
{ /* sentinel */ }
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/panel: tpo-td043mtea1: Fix SPI alias
The panel-tpo-td043mtea1 driver incorrectly includes the OF vendor
prefix in its SPI alias. Fix it, and move the manual alias to an SPI
module device table.
Fixes: dc2e1e5b2799 ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel")
Reported-by: H. Nikolaus Schaller
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
b/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
index 84370562910f..ba163c779084 100644
--- a/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
+++ b/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
@@ -491,9 +491,17 @@ static const struct of_device_id td043mtea1_of_match[] = {
MODULE_DEVICE_TABLE(of, td043mtea1_of_match);
+static const struct spi_device_id td043mtea1_ids[] = {
+ { "td043mtea1", 0 },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(spi, td043mtea1_ids);
+
static struct spi_driver td043mtea1_driver = {
.probe = td043mtea1_probe,
.remove = td043mtea1_remove,
+ .id_table = td043mtea1_ids,
.driver = {
.name = "panel-tpo-td043mtea1",
.pm = _pm_ops,
@@ -503,7 +511,6 @@ static struct spi_driver td043mtea1_driver = {
module_spi_driver(td043mtea1_driver);
-MODULE_ALIAS("spi:tpo,td043mtea1");
MODULE_AUTHOR("Gražvydas Ignotas ");
MODULE_DESCRIPTION("TPO TD043MTEA1 Panel Driver");
MODULE_LICENSE("GPL");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: panels: fix spi aliases of former omap panels
Hi,
On Mon, Oct 07, 2019 at 06:41:30PM +0200, Andreas Kemnade wrote:
> When the panels were moved from omap/displays/ to panel/
> omapdss prefix was stripped, which cause spi modalias
> to not contain the vendor-prefix anymore.
>
> so we had e.g. in former times:
> compatible=omapdss,tpo,td028ttec1 -> modalias=spi:tpo,td028ttec1
> now:
> compatible=tpo,td028ttec1 -> modalias=spi:td028ttec1
>
> This is consistent with other drivers. Tested the td028ttec.c
> only, but the pattern looks the same for the other ones.
>
> Fixes: 45f16c82db7e8 ("drm/omap: displays: Remove unused panel drivers")
> Signed-off-by: Andreas Kemnade
> ---
Patch looks good to me, but you have one false positive.
> [...]
>
> diff --git a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> index 46cd9a2501298..838d39a263f53 100644
> --- a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> +++ b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> @@ -204,7 +204,7 @@ static int ls037v7dw01_remove(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id ls037v7dw01_of_match[] = {
> - { .compatible = "sharp,ls037v7dw01", },
> + { .compatible = "ls037v7dw01", },
> { /* sentinel */ },
> };
>
The DT compatible should have a vendor prefix.
> [...]
-- Sebastian
signature.asc
Description: PGP signature
Re: [PATCH v8 4/4] drm/mtk: add panel orientation property
On Wed, Sep 25, 2019 at 03:58:33PM -0700, Derek Basehore wrote:
> This inits the panel orientation property for the mediatek dsi driver
> if the panel orientation (connector.display_info.panel_orientation) is
> not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
>
> Signed-off-by: Derek Basehore
> Acked-by: Sam Ravnborg
> Reviewed-by: CK Hu
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 224afb666881..2936932344eb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -792,10 +792,18 @@ static int mtk_dsi_create_connector(struct drm_device
> *drm, struct mtk_dsi *dsi)
> DRM_ERROR("Failed to attach panel to drm\n");
> goto err_connector_cleanup;
> }
> +
> + ret = drm_connector_init_panel_orientation_property(>conn);
> + if (ret) {
> + DRM_ERROR("Failed to init panel orientation\n");
> + goto err_panel_detach;
> + }
> }
>
> return 0;
>
> +err_panel_detach:
> + drm_panel_detach(dsi->panel);
> err_connector_cleanup:
> drm_connector_cleanup(>conn);
> return ret;
> --
> 2.23.0.351.gc4317032e6-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
Re: [PATCH v8 3/4] drm/connector: Split out orientation quirk detection
On Wed, Sep 25, 2019 at 03:58:32PM -0700, Derek Basehore wrote:
> Not every platform needs quirk detection for panel orientation, so
> split the drm_connector_init_panel_orientation_property into two
> functions. One for platforms without the need for quirks, and the
> other for platforms that need quirks.
>
> Signed-off-by: Derek Basehore
> Acked-by: Sam Ravnborg
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_connector.c | 45 ++---
> drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
> drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
> include/drm/drm_connector.h | 2 ++
> 5 files changed, 39 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 4c766624b20d..faef25683faf 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1989,31 +1989,23 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> * drm_connector_init_panel_orientation_property -
> * initialize the connecters panel_orientation property
> * @connector: connector for which to init the panel-orientation property.
> - * @width: width in pixels of the panel, used for panel quirk detection
> - * @height: height in pixels of the panel, used for panel quirk detection
> *
> * This function should only be called for built-in panels, after setting
> * connector->display_info.panel_orientation first (if known).
> *
> - * This function will check for platform specific (e.g. DMI based) quirks
> - * overriding display_info.panel_orientation first, then if panel_orientation
> - * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
> - * "panel orientation" property to the connector.
> + * This function will check if the panel_orientation is not
> + * DRM_MODE_PANEL_ORIENTATION_UNKNOWN. If not, it will attach the "panel
> + * orientation" property to the connector.
> *
> * Returns:
> * Zero on success, negative errno on failure.
> */
> int drm_connector_init_panel_orientation_property(
> - struct drm_connector *connector, int width, int height)
> + struct drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
> struct drm_display_info *info = >display_info;
> struct drm_property *prop;
> - int orientation_quirk;
> -
> - orientation_quirk = drm_get_panel_orientation_quirk(width, height);
> - if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> - info->panel_orientation = orientation_quirk;
>
> if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> return 0;
> @@ -2036,6 +2028,35 @@ int drm_connector_init_panel_orientation_property(
> }
> EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
>
> +/**
> + * drm_connector_init_panel_orientation_property_quirk -
> + * initialize the connecters panel_orientation property with a quirk
> + * override
> + * @connector: connector for which to init the panel-orientation property.
> + * @width: width in pixels of the panel, used for panel quirk detection
> + * @height: height in pixels of the panel, used for panel quirk detection
> + *
> + * This function will check for platform specific (e.g. DMI based) quirks
> + * overriding display_info.panel_orientation first, then if panel_orientation
> + * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
> + * "panel orientation" property to the connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_init_panel_orientation_property_quirk(
> + struct drm_connector *connector, int width, int height)
> +{
> + int orientation_quirk;
> +
> + orientation_quirk = drm_get_panel_orientation_quirk(width, height);
> + if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> + connector->display_info.panel_orientation = orientation_quirk;
> +
> + return drm_connector_init_panel_orientation_property(connector);
> +}
> +EXPORT_SYMBOL(drm_connector_init_panel_orientation_property_quirk);
> +
> int drm_connector_set_obj_prop(struct drm_mode_object *obj,
> struct drm_property *property,
> uint64_t value)
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 6e398c33a524..483287984090 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1538,7 +1538,7 @@ static void icl_dsi_add_properties(struct
> intel_connector *connector)
>
> connector->base.display_info.panel_orientation =
> intel_dsi_get_panel_orientation(connector);
> - drm_connector_init_panel_orientation_property(>base,
> + drm_connector_init_panel_orientation_property_quirk(>base,
> connector->panel.fixed_mode->hdisplay,
Re: [v8,2/4] drm/panel: set display info in panel attach
On Mon, Sep 30, 2019 at 04:14:54PM -0700, dbasehore . wrote:
> On Sat, Sep 28, 2019 at 10:23 PM james qian wang (Arm Technology
> China) wrote:
> >
> > On Wed, Sep 25, 2019 at 03:58:31PM -0700, Derek Basehore wrote:
> > > Devicetree systems can set panel orientation via a panel binding, but
> > > there's no way, as is, to propagate this setting to the connector,
> > > where the property need to be added.
> > > To address this, this patch sets orientation, as well as other fixed
> > > values for the panel, in the drm_panel_attach function. These values
> > > are stored from probe in the drm_panel struct.
> > >
> > > Signed-off-by: Derek Basehore
> > > Reviewed-by: Sam Ravnborg
> > > ---
> > > drivers/gpu/drm/drm_panel.c | 28 +
> > > include/drm/drm_panel.h | 50 +
> > > 2 files changed, 78 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > > index 0909b53b74e6..1cd2b56c9fe6 100644
> > > --- a/drivers/gpu/drm/drm_panel.c
> > > +++ b/drivers/gpu/drm/drm_panel.c
> > > @@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
> > > */
> > > int drm_panel_attach(struct drm_panel *panel, struct drm_connector
> > > *connector)
> > > {
> > > + struct drm_display_info *info;
> > > +
> > > if (panel->connector)
> > > return -EBUSY;
> > >
> > > panel->connector = connector;
> > > panel->drm = connector->dev;
> > > + info = >display_info;
> > > + info->width_mm = panel->width_mm;
> > > + info->height_mm = panel->height_mm;
> > > + info->bpc = panel->bpc;
> > > + info->panel_orientation = panel->orientation;
> > > + info->bus_flags = panel->bus_flags;
> > > + if (panel->bus_formats)
> > > + drm_display_info_set_bus_formats(>display_info,
> > > + panel->bus_formats,
> > > + panel->num_bus_formats);
> > >
> > > return 0;
> > > }
> > > @@ -126,6 +138,22 @@ EXPORT_SYMBOL(drm_panel_attach);
> > > */
> > > void drm_panel_detach(struct drm_panel *panel)
> > > {
> > > + struct drm_display_info *info;
> > > +
> > > + if (!panel->connector)
> > > + goto out;
> > > +
> > > + info = >connector->display_info;
> > > + info->width_mm = 0;
> > > + info->height_mm = 0;
> > > + info->bpc = 0;
> > > + info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > > + info->bus_flags = 0;
> > > + kfree(info->bus_formats);
> > > + info->bus_formats = NULL;
> > > + info->num_bus_formats = 0;
> > > +
> > > +out:
> > > panel->connector = NULL;
> > > panel->drm = NULL;
> > > }
> > > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > > index d16158deacdc..f3587a54b8ac 100644
> > > --- a/include/drm/drm_panel.h
> > > +++ b/include/drm/drm_panel.h
> > > @@ -141,6 +141,56 @@ struct drm_panel {
> > >*/
> > > const struct drm_panel_funcs *funcs;
> > >
> >
> > All these new added members seems dupliated with drm_display_info,
> > So I think, can we add a new drm_plane_funcs func:
> >
> > int (*set_display_info)(struct drm_panel *panel,
> > struct drm_display_info *info);
>
> I don't disagree personally, since I originally wrote it this way, but
> 2 maintainers, Daniel Vetter and Thierry Reding, requested that it be
> changed. Unless that decision is reversed, I won't be changing this.
>
Reading back the feedback on v1, I don't think anyone said they were against
storing a drm_display_info struct in drm_panel (no one really weighed in on
it one way or another). IMO duplicating a bunch of fields feels pretty icky.
I think most fields in drm_display_info have pretty reasonable defaults, so I'd
recommend just storing a copy in drm_panel. As Thierry suggests, we can
populate the dt parts in probe (orientation) and then copy over all or a subset
of the struct to connector on attach.
Sean
> >
> > Then in drm_panel_attach(), via this interface the specific panel
> > driver can directly set connector->display_info. like
> >
> >...
> >if (panel->funcs && panel->funcs->set_display_info)
> > panel->funcs->unprepare(panel, connector->display_info);
> >...
> >
> > Thanks
> > James
> >
> > > + /**
> > > + * @width_mm:
> > > + *
> > > + * Physical width in mm.
> > > + */
> > > + unsigned int width_mm;
> > > +
> > > + /**
> > > + * @height_mm:
> > > + *
> > > + * Physical height in mm.
> > > + */
> > > + unsigned int height_mm;
> > > +
> > > + /**
> > > + * @bpc:
> > > + *
> > > + * Maximum bits per color channel. Used by HDMI and DP outputs.
> > > + */
> > > + unsigned int bpc;
> > > +
> > > + /**
> > > + * @orientation
> > > + *
> > > + * Installation orientation of the panel with respect to the
> > > chassis.
> > > +
[PATCH] drm: panels: fix spi aliases of former omap panels
When the panels were moved from omap/displays/ to panel/
omapdss prefix was stripped, which cause spi modalias
to not contain the vendor-prefix anymore.
so we had e.g. in former times:
compatible=omapdss,tpo,td028ttec1 -> modalias=spi:tpo,td028ttec1
now:
compatible=tpo,td028ttec1 -> modalias=spi:td028ttec1
This is consistent with other drivers. Tested the td028ttec.c
only, but the pattern looks the same for the other ones.
Fixes: 45f16c82db7e8 ("drm/omap: displays: Remove unused panel drivers")
Signed-off-by: Andreas Kemnade
---
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 2 +-
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c| 2 +-
drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 2 +-
drivers/gpu/drm/panel/panel-sony-acx565akm.c| 2 +-
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c| 3 +--
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c| 2 +-
6 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-lb035q02.c
b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
index fc82a525b071b..8423684a0557e 100644
--- a/drivers/gpu/drm/panel/panel-lg-lb035q02.c
+++ b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
@@ -231,7 +231,7 @@ static struct spi_driver lb035q02_driver = {
module_spi_driver(lb035q02_driver);
-MODULE_ALIAS("spi:lgphilips,lb035q02");
+MODULE_ALIAS("spi:lb035q02");
MODULE_AUTHOR("Tomi Valkeinen ");
MODULE_DESCRIPTION("LG.Philips LB035Q02 LCD Panel driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
index 299b217c83e18..71b07ef2a62dd 100644
--- a/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
@@ -242,7 +242,7 @@ static struct spi_driver nl8048_driver = {
module_spi_driver(nl8048_driver);
-MODULE_ALIAS("spi:nec,nl8048hl11");
+MODULE_ALIAS("spi:nl8048hl11");
MODULE_AUTHOR("Erik Gilling ");
MODULE_DESCRIPTION("NEC-NL8048HL11 Driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
index 46cd9a2501298..838d39a263f53 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
@@ -204,7 +204,7 @@ static int ls037v7dw01_remove(struct platform_device *pdev)
}
static const struct of_device_id ls037v7dw01_of_match[] = {
- { .compatible = "sharp,ls037v7dw01", },
+ { .compatible = "ls037v7dw01", },
{ /* sentinel */ },
};
diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
index 305259b587670..a8af9340f89ee 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -695,7 +695,7 @@ static struct spi_driver acx565akm_driver = {
module_spi_driver(acx565akm_driver);
-MODULE_ALIAS("spi:sony,acx565akm");
+MODULE_ALIAS("spi:acx565akm");
MODULE_AUTHOR("Nokia Corporation");
MODULE_DESCRIPTION("Sony ACX565AKM LCD Panel Driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
index d7b2e34626efe..3ab66b4d3ea27 100644
--- a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
@@ -375,8 +375,7 @@ static const struct of_device_id td028ttec1_of_match[] = {
MODULE_DEVICE_TABLE(of, td028ttec1_of_match);
static const struct spi_device_id td028ttec1_ids[] = {
- { "tpo,td028ttec1", 0},
- { "toppoly,td028ttec1", 0 },
+ { "td028ttec1", 0},
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
b/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
index 84370562910ff..7e6cf0890600c 100644
--- a/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
+++ b/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
@@ -503,7 +503,7 @@ static struct spi_driver td043mtea1_driver = {
module_spi_driver(td043mtea1_driver);
-MODULE_ALIAS("spi:tpo,td043mtea1");
+MODULE_ALIAS("spi:td043mtea1");
MODULE_AUTHOR("Gražvydas Ignotas ");
MODULE_DESCRIPTION("TPO TD043MTEA1 Panel Driver");
MODULE_LICENSE("GPL");
--
2.20.1
Re: [PATCH v8 1/4] drm/panel: Add helper for reading DT rotation
On Wed, Sep 25, 2019 at 03:58:30PM -0700, Derek Basehore wrote:
> This adds a helper function for reading the rotation (panel
> orientation) from the device tree.
>
> Signed-off-by: Derek Basehore
> Reviewed-by: Sam Ravnborg
The patch LGTM, but I don't see it used anywhere later in the patch? Is there a
panel driver incoming?
Sean
> ---
> drivers/gpu/drm/drm_panel.c | 43 +
> include/drm/drm_panel.h | 9
> 2 files changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 6b0bf42039cf..0909b53b74e6 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -264,6 +264,49 @@ struct drm_panel *of_drm_find_panel(const struct
> device_node *np)
> return ERR_PTR(-EPROBE_DEFER);
> }
> EXPORT_SYMBOL(of_drm_find_panel);
> +
> +/**
> + * of_drm_get_panel_orientation - look up the orientation of the panel
> through
> + * the "rotation" binding from a device tree node
> + * @np: device tree node of the panel
> + * @orientation: orientation enum to be filled in
> + *
> + * Looks up the rotation of a panel in the device tree. The orientation of
> the
> + * panel is expressed as a property name "rotation" in the device tree. The
> + * rotation in the device tree is counter clockwise.
> + *
> + * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or the
> + * rotation property doesn't exist. -EERROR otherwise.
> + */
> +int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation)
> +{
> + int rotation, ret;
> +
> + ret = of_property_read_u32(np, "rotation", );
> + if (ret == -EINVAL) {
> + /* Don't return an error if there's no rotation property. */
> + *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> + return 0;
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + if (rotation == 0)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> + else if (rotation == 90)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
> + else if (rotation == 180)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> + else if (rotation == 270)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(of_drm_get_panel_orientation);
> #endif
>
> MODULE_AUTHOR("Thierry Reding ");
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 624bd15ecfab..d16158deacdc 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -34,6 +34,8 @@ struct drm_device;
> struct drm_panel;
> struct display_timing;
>
> +enum drm_panel_orientation;
> +
> /**
> * struct drm_panel_funcs - perform operations on a given panel
> *
> @@ -165,11 +167,18 @@ int drm_panel_get_modes(struct drm_panel *panel);
>
> #if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
> struct drm_panel *of_drm_find_panel(const struct device_node *np);
> +int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation);
> #else
> static inline struct drm_panel *of_drm_find_panel(const struct device_node
> *np)
> {
> return ERR_PTR(-ENODEV);
> }
> +static inline int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #endif
> --
> 2.23.0.351.gc4317032e6-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
Re: [PATCH] drm/amdkfd: Fix a && vs || typo
On Mon, Oct 7, 2019 at 4:52 AM Dan Carpenter wrote:
>
> In the current code if "device_info" is ever NULL then the kernel will
> Oops so probably || was intended instead of &&.
>
> Fixes: e392c887df97 ("drm/amdkfd: Use array to probe kfd2kgd_calls")
> Signed-off-by: Dan Carpenter
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 0db273587af4..070c9b5593c9 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -498,7 +498,7 @@ struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd,
> device_info = kfd_supported_devices[asic_type][vf];
> f2g = kfd2kgd_funcs[asic_type];
>
> - if (!device_info && !f2g) {
> + if (!device_info || !f2g) {
> dev_err(kfd_device, "%s %s not supported in kfd\n",
> amdgpu_asic_name[asic_type], vf ? "VF" : "");
> return NULL;
> --
> 2.20.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
Re: [PATCH] drm/amd/powerplay: Fix error handling in smu_init_fb_allocations()
Applied. Thanks!
Alex
On Mon, Oct 7, 2019 at 6:32 AM Wang, Kevin(Yang) wrote:
>
> thanks correct it.
>
> Reviewed-by: Kevin Wang
>
> Best Regards,
> Kevin
>
> From: Dan Carpenter
> Sent: Monday, October 7, 2019 5:02 PM
> To: Rex Zhu ; Wang, Kevin(Yang)
> Cc: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian ;
> Zhou, David(ChunMing) ; David Airlie ;
> Daniel Vetter ; amd-...@lists.freedesktop.org
> ; dri-devel@lists.freedesktop.org
> ; kernel-janit...@vger.kernel.org
>
> Subject: [PATCH] drm/amd/powerplay: Fix error handling in
> smu_init_fb_allocations()
>
> The error handling is off by one. We should not free the first
> "tables[i].bo" without decrementing "i" because that might result in a
> double free. The second problem is that when an error occurs, then the
> zeroth element "tables[0].bo" isn't freed.
>
> I had make "i" signed int for the error handling to work, so I just
> updated "ret" as well as a clean up.
>
> Fixes: f96357a991b9 ("drm/amd/powerplay: implement
> smu_init(fini)_fb_allocations function")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> index f1fbbc8b77ee..c9266ea70331 100644
> --- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> @@ -896,8 +896,7 @@ static int smu_init_fb_allocations(struct smu_context
> *smu)
> struct amdgpu_device *adev = smu->adev;
> struct smu_table_context *smu_table = >smu_table;
> struct smu_table *tables = smu_table->tables;
> - uint32_t i = 0;
> - int32_t ret = 0;
> + int ret, i;
>
> for (i = 0; i < SMU_TABLE_COUNT; i++) {
> if (tables[i].size == 0)
> @@ -915,7 +914,7 @@ static int smu_init_fb_allocations(struct smu_context
> *smu)
>
> return 0;
> failed:
> - for (; i > 0; i--) {
> + while (--i >= 0) {
> if (tables[i].size == 0)
> continue;
> amdgpu_bo_free_kernel([i].bo,
> --
> 2.20.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: unlock on error in smu_resume()
Applied. thanks!
Alex
On Mon, Oct 7, 2019 at 6:29 AM Wang, Kevin(Yang) wrote:
>
> Reviewed-by: Kevin Wang
>
> Best Regards,
> Kevin
>
> From: amd-gfx on behalf of Dan
> Carpenter
> Sent: Monday, October 7, 2019 5:04 PM
> To: Rex Zhu ; Quan, Evan
> Cc: Zhou, David(ChunMing) ; David Airlie
> ; kernel-janit...@vger.kernel.org
> ; amd-...@lists.freedesktop.org
> ; dri-devel@lists.freedesktop.org
> ; Daniel Vetter ; Deucher,
> Alexander ; Koenig, Christian
>
> Subject: [PATCH] drm/amd/powerplay: unlock on error in smu_resume()
>
> This function needs to drop the mutex before returning.
>
> Fixes: f7e3a5776fa6 ("drm/amd/powerplay: check SMU engine readiness before
> proceeding on S3 resume")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> index 6a64f765fcd4..f1fbbc8b77ee 100644
> --- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> @@ -1384,7 +1384,7 @@ static int smu_resume(void *handle)
> ret = smu_start_smc_engine(smu);
> if (ret) {
> pr_err("SMU is not ready yet!\n");
> - return ret;
> + goto failed;
> }
>
> ret = smu_smc_table_hw_init(smu, false);
> --
> 2.20.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> 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
Re: [PATCH] drm/i915: make array hw_engine_mask static, makes object smaller
Quoting Colin King (2019-10-07 16:41:51) > From: Colin Ian King > > Don't populate the array hw_engine_mask on the stack but instead make it > static. Makes the object code smaller by 316 bytes. > > Before: >textdata bss dec hex filename > 340044388 320 387129738 gpu/drm/i915/gt/intel_reset.o > > After: >textdata bss dec hex filename > 335284548 320 3839695fc gpu/drm/i915/gt/intel_reset.o > > (gcc version 9.2.1, amd64) > > Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson -Chris
Re: [PATCH 0/5] drm/amd/display: some fixes for gcc warning
Applied. Thanks! Alex On Mon, Oct 7, 2019 at 10:19 AM Harry Wentland wrote: > > Series is > Reviewed-by: Harry Wentland > > Harry > > On 2019-10-04 10:44 p.m., zhengbin wrote: > > zhengbin (5): > > drm/amd/display: Make function wait_for_alt_mode static > > drm/amd/display: Remove set but not used variable 'source_bpp' > > drm/amd/display: Remove set but not used variables > > 'h_ratio_chroma','v_ratio_chroma' > > drm/amd/display: Remove set but not used variable 'pixel_width' > > drm/amd/display: Remove set but not used variables 'pp_smu','old_pipe' > > > > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- > > drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 12 > > > > drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c| 7 --- > > drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dwb_scl.c| 4 > > drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c| 3 --- > > 5 files changed, 1 insertion(+), 27 deletions(-) > > > > -- > > 2.7.4 > > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: New sysfs interface for privacy screens
On Mon, Oct 7, 2019 at 7:09 AM Sean Paul wrote:
>
> On Thu, Oct 3, 2019 at 3:57 PM Mat King wrote:
> >
> > On Thu, Oct 3, 2019 at 2:59 AM Jani Nikula
> > wrote:
> > >
> > > On Wed, 02 Oct 2019, Mat King wrote:
> > > > On Wed, Oct 2, 2019 at 4:46 AM Jani Nikula
> > > > wrote:
> > > >>
> > > >> On Wed, 02 Oct 2019, Daniel Thompson
> > > >> wrote:
> > > >> > On Wed, Oct 02, 2019 at 12:30:05PM +0300, Jani Nikula wrote:
> > > >> >> On Tue, 01 Oct 2019, Mat King wrote:
> > > >> >> > Resending in plain text mode
>
> /snip
>
> >
> > So my proposal would now be to add a new standard property to
> > drm_connector called "privacy_screen" this property would be an enum
> > which can take one of three values.
> >
> > PRIVACY_UNSUPPORTED - Privacy is not available for this connector
> > PRIVACY_DISABLED - Privacy is available but turned off
> > PRIVACY_ENABLED - Privacy is available and turned on
>
> Agree with Jani, use the property presence to determine if it's supported
That makes sense; just to confirm can a property be added or removed
after the connector is registered?
>
> >
> > When the connector is initized the privacy screen property is set to
> > PRIVACY_UNSUPPORTED and cannot be changed unless a drm_privacy_screen
> > is registered to the connector. drm_privacy_screen will look something
> > like
> >
> > struct drm_privacy_screen_ops {
> > int (*get_privacy_state)(struct drm_privacy_screen *);
> > int (*set_privacy_state)(struct drm_privacy_screen *, int);
> > }
> >
> > struct drm_privacy_screen {
> > /* The privacy screen device */
> > struct device *dev;
> >
> > /* The connector that the privacy screen is attached */
> > struct drm_connector *connector;
> >
> > /* Ops to get and set the privacy screen state */
> > struct drm_privacy_screen_ops *ops;
> >
> > /* The current state of the privacy screen */
> > int state;
> > }
> >
> > Privacy screen device drivers will call a function to register the
> > privacy screen with the connector.
>
> Do we actually need dedicated drivers for privacy screen? It seems
> like something that is panel-specific hardware, so I'd suggest just
> using the panel driver.
The privacy screen is physically part of the display but the control
interface, at least in all current use cases, is ACPI. Is there a way
to control an ACPI device with the panel driver?
>
> Sean
>
> >
> > int drm_privacy_screen_register(struct drm_privacy_screen_ops *ops,
> > struct device *dev, struct drm_connector *);
> >
> > Calling this will set a new field on the connector "struct
> > drm_privacy_screen *privacy_screen" and change the value of the
> > property to ops->get_privacy_state(). When
> > drm_mode_connector_set_obj_prop() is called with the
> > privacy_screen_proptery if a privacy_screen is registered to the
> > connector the ops->set_privacy_state() will be called with the new
> > value.
> >
> > Setting of this property (and all drm properties) is done in user
> > space using ioctrl.
> >
> > Registering the privacy screen with a connector may be tricky because
> > the driver for the privacy screen will need to be able to identify
> > which connector it belongs to and we will have to deal with connectors
> > being added both before and after the privacy screen device is added
> > by it's driver.
> >
> > How does that sound? I will work on a patch if that all sounds about right.
> >
> > One question I still have is there a way to not accept a value that is
> > passed to drm_mode_connector_set_obj_prop()? In this case if a privacy
> > screen is not registered the property must stay PRIVACY_UNSUPPORTED
> > and if a privacy screen is registered then PRIVACY_UNSUPPORTED must
> > never be set.
Re: [PATCH v9 4/5] dt-bindings: backlight: Add led-backlight binding
Please send DT bindings to DT list or it's never in my queue. IOW, send patches to the lists that get_maintainers.pl tells you to. On Mon, Oct 7, 2019 at 7:45 AM Jean-Jacques Hiblot wrote: > > Add DT binding for led-backlight. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Daniel Thompson > Reviewed-by: Sebastian Reichel > --- > .../bindings/leds/backlight/led-backlight.txt | 28 +++ > 1 file changed, 28 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/led-backlight.txt Please make this a DT schema. > diff --git > a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > new file mode 100644 > index ..4c7dfbe7f67a > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > @@ -0,0 +1,28 @@ > +led-backlight bindings > + > +This binding is used to describe a basic backlight device made of LEDs. > +It can also be used to describe a backlight device controlled by the output > of > +a LED driver. > + > +Required properties: > + - compatible: "led-backlight" > + - leds: a list of LEDs 'leds' is already used as a node name and mixing is not ideal. We already have 'flash-leds' in use and with the same definition, so lets continue that and use 'backlight-leds'. > + > +Optional properties: > + - brightness-levels: Array of distinct brightness levels. The levels must > be > + in the range accepted by the underlying LED devices. > + This is used to translate a backlight brightness level > + into a LED brightness level. If it is not provided, > the > + identity mapping is used. > + > + - default-brightness-level: The default brightness level. You can just assume these 2 get a common schema at some point. So just need to define any additional constraints if possible. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Handle resetting on timeout better
On 10/7/19 6:09 AM, Neil Armstrong wrote:
Hi Steven,
On 07/10/2019 14:50, Steven Price wrote:
Panfrost uses multiple schedulers (one for each slot, so 2 in reality),
and on a timeout has to stop all the schedulers to safely perform a
reset. However more than one scheduler can trigger a timeout at the same
time. This race condition results in jobs being freed while they are
still in use.
When stopping other slots use cancel_delayed_work_sync() to ensure that
any timeout started for that slot has completed. Also use
mutex_trylock() to obtain reset_lock. This means that only one thread
attempts the reset, the other threads will simply complete without doing
anything (the first thread will wait for this in the call to
cancel_delayed_work_sync()).
While we're here and since the function is already dependent on
sched_job not being NULL, let's remove the unnecessary checks, along
with a commented out call to panfrost_core_dump() which has never
existed in mainline.
A Fixes: tags would be welcome here so it would be backported to v5.3
Signed-off-by: Steven Price
---
This is a tidied up version of the patch orginally posted here:
http://lkml.kernel.org/r/26ae2a4d-8df1-e8db-3060-41638ed63e2a%40arm.com
drivers/gpu/drm/panfrost/panfrost_job.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index a58551668d9a..dcc9a7603685 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -381,13 +381,19 @@ static void panfrost_job_timedout(struct drm_sched_job
*sched_job)
job_read(pfdev, JS_TAIL_LO(js)),
sched_job);
- mutex_lock(>reset_lock);
+ if (!mutex_trylock(>reset_lock))
+ return;
- for (i = 0; i < NUM_JOB_SLOTS; i++)
- drm_sched_stop(>js->queue[i].sched, sched_job);
+ for (i = 0; i < NUM_JOB_SLOTS; i++) {
+ struct drm_gpu_scheduler *sched = >js->queue[i].sched;
+
+ drm_sched_stop(sched, sched_job);
+ if (js != i)
+ /* Ensure any timeouts on other slots have finished */
+ cancel_delayed_work_sync(>work_tdr);
+ }
- if (sched_job)
- drm_sched_increase_karma(sched_job);
+ drm_sched_increase_karma(sched_job);
Indeed looks cleaner.
spin_lock_irqsave(>js->job_lock, flags);
for (i = 0; i < NUM_JOB_SLOTS; i++) {
@@ -398,7 +404,6 @@ static void panfrost_job_timedout(struct drm_sched_job
*sched_job)
}
spin_unlock_irqrestore(>js->job_lock, flags);
- /* panfrost_core_dump(pfdev); */
This should be cleaned in another patch !
Seems to me that this should be some kind of TODO, see
etnaviv_core_dump() for the kind of things we could be doing.
Maybe we can delete this line and mention this in the TODO file?
Cheers,
Tomeu
panfrost_devfreq_record_transition(pfdev, js);
panfrost_device_reset(pfdev);
Thanks,
Testing it right now with the last change removed (doesn't apply on v5.3 with
it),
results in a few hours... or minutes !
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 --- Comment #55 from Dmitri Seletski (drj...@gmail.com) --- (In reply to Alex Deucher from comment #54) > (In reply to Dmitri Seletski from comment #48) > > (In reply to Mike Lothian from comment #47) > > > It's selected automatically if you set DRM_FBDEV_EMULATION - which is > > > "Enable legacy fbdev support for your modesetting driver" and unset above > > > > > > That should get your console working > > > > Mike, just to clarify, console is working until AMDGPU driver is loaded. > > The console is running on efifb or vga mode until the driver loads. If you > don't have DRM_FBDEV_EMULATION enabled, there is nothing for the console to > bind to once the driver loads. Hello Alex. Does not appear to be the case: grep -R DRM_FBDEV_EMULATION ./*/.config ./git_clone/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux-4.14.83-gentoo/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux-5.1.14-gentoo/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux-5.2.10/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux-5.3.6.custom/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux-5.3-rc6/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux-5.3-rc8/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux-5.4-rc1/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux/.config:CONFIG_DRM_FBDEV_EMULATION=y ./linux-next-next-20190920/.config:CONFIG_DRM_FBDEV_EMULATION=y Any other ideas? Would be appreciated! Regards Dmitri -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH TRIVIAL v2] gpu: Fix Kconfig indentation
On Mon, Oct 7, 2019 at 7:39 AM Jani Nikula wrote: > > On Fri, 04 Oct 2019, Krzysztof Kozlowski wrote: > > drivers/gpu/drm/i915/Kconfig | 12 +- > > drivers/gpu/drm/i915/Kconfig.debug | 144 +++ > > Please split these out to a separate patch. Can't speak for others, but > the patch looks like it'll be conflicts galore and a problem to manage > if merged in one big lump. Yes, it would be nice to have the amd patch separate as well. Alex > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: add missing void argument to function kgd2kfd_init
On Sat, Oct 5, 2019 at 1:58 PM Colin King wrote:
>
> From: Colin Ian King
>
> Function kgd2kfd_init is missing a void argument, add it
> to clean up the non-ANSI function declaration.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_module.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> index 986ff52d5750..f4b7f7e6c40e 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
> @@ -82,7 +82,7 @@ static void kfd_exit(void)
> kfd_chardev_exit();
> }
>
> -int kgd2kfd_init()
> +int kgd2kfd_init(void)
> {
> return kfd_init();
> }
> --
> 2.20.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
Re: [PATCH -next] drm/amdgpu: remove duplicated include from mmhub_v1_0.c
Applied. thanks! Alex On Sun, Oct 6, 2019 at 11:05 PM YueHaibing wrote: > > Remove duplicated include. > > Signed-off-by: YueHaibing > --- > drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c > b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c > index 4c7e8c64a94e..6965e1e6fa9e 100644 > --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c > @@ -31,7 +31,6 @@ > #include "vega10_enum.h" > > #include "soc15_common.h" > -#include "amdgpu_ras.h" > > #define mmDAGB0_CNTL_MISC2_RV 0x008f > #define mmDAGB0_CNTL_MISC2_RV_BASE_IDX 0 > > > > > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/display: remove set but not used variable 'core_freesync'
On Mon, Oct 7, 2019 at 10:06 AM Harry Wentland wrote:
>
> On 2019-10-06 6:57 a.m., YueHaibing wrote:
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > rivers/gpu/drm/amd/amdgpu/../display/modules/freesync/freesync.c:
> > In function mod_freesync_get_settings:
> > drivers/gpu/drm/amd/amdgpu/../display/modules/freesync/freesync.c:984:24:
> > warning: variable core_freesync set but not used
> > [-Wunused-but-set-variable]
> >
> > It is not used since commit 98e6436d3af5 ("drm/amd/display: Refactor
> > FreeSync module")
> >
> > Reported-by: Hulk Robot
> > Signed-off-by: YueHaibing
>
> Reviewed-by: Harry Wentland
>
Applied. Thanks!
Alex
> Harry
>
> > ---
> > drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> > b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> > index 9ce56a8..237dda7 100644
> > --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> > +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> > @@ -981,13 +981,9 @@ void mod_freesync_get_settings(struct mod_freesync
> > *mod_freesync,
> > unsigned int *inserted_frames,
> > unsigned int *inserted_duration_in_us)
> > {
> > - struct core_freesync *core_freesync = NULL;
> > -
> > if (mod_freesync == NULL)
> > return;
> >
> > - core_freesync = MOD_FREESYNC_TO_CORE(mod_freesync);
> > -
> > if (vrr->supported) {
> > *v_total_min = vrr->adjust.v_total_min;
> > *v_total_max = vrr->adjust.v_total_max;
> >
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix typo in some comments
On Mon, Oct 7, 2019 at 10:13 AM Harry Wentland wrote: > > On 2019-10-05 7:32 a.m., Christophe JAILLET wrote: > > p and g are switched in 'amdpgu_dm' > > > > Signed-off-by: Christophe JAILLET > > Reviewed-by: Harry Wentland Applied. thanks! Alex > > Harry > > > --- > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > index 92932d521d7f..b9c2e1a930ab 100644 > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > @@ -1043,7 +1043,7 @@ static void s3_handle_mst(struct drm_device *dev, > > bool suspend) > > > > /** > > * dm_hw_init() - Initialize DC device > > - * @handle: The base driver device containing the amdpgu_dm device. > > + * @handle: The base driver device containing the amdgpu_dm device. > > * > > * Initialize the amdgpu_display_manager device. This involves > > calling > > * the initializers of each DM component, then populating the struct with > > them. > > @@ -1073,7 +1073,7 @@ static int dm_hw_init(void *handle) > > > > /** > > * dm_hw_fini() - Teardown DC device > > - * @handle: The base driver device containing the amdpgu_dm device. > > + * @handle: The base driver device containing the amdgpu_dm device. > > * > > * Teardown components within amdgpu_display_manager that require > > * cleanup. This involves cleaning up the DRM device, DC, and any modules > > that > > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: make array hw_engine_mask static, makes object smaller
From: Colin Ian King
Don't populate the array hw_engine_mask on the stack but instead make it
static. Makes the object code smaller by 316 bytes.
Before:
textdata bss dec hex filename
340044388 320 387129738 gpu/drm/i915/gt/intel_reset.o
After:
textdata bss dec hex filename
335284548 320 3839695fc gpu/drm/i915/gt/intel_reset.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gt/intel_reset.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index eeb3bd0c4d69..db58ca9bee3a 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -285,7 +285,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
unsigned int retry)
{
struct intel_engine_cs *engine;
- const u32 hw_engine_mask[] = {
+ static const u32 hw_engine_mask[] = {
[RCS0] = GEN6_GRDOM_RENDER,
[BCS0] = GEN6_GRDOM_BLT,
[VCS0] = GEN6_GRDOM_MEDIA,
@@ -408,7 +408,7 @@ static int gen11_reset_engines(struct intel_gt *gt,
intel_engine_mask_t engine_mask,
unsigned int retry)
{
- const u32 hw_engine_mask[] = {
+ static const u32 hw_engine_mask[] = {
[RCS0] = GEN11_GRDOM_RENDER,
[BCS0] = GEN11_GRDOM_BLT,
[VCS0] = GEN11_GRDOM_MEDIA,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/11] x86/mm, pat: convert pat tree to generic interval tree
* Davidlohr Bueso wrote:
> With some considerations, the custom pat_rbtree implementation can be
> simplified to use most of the generic interval_tree machinery.
>
> o The tree inorder traversal can slightly differ when there are key
> ('start') collisions in the tree due to one going left and another right.
> This, however, only affects the output of debugfs' pat_memtype_list file.
>
> o Generic interval trees are now semi open [a,b), which suits well with
> what pat wants.
>
> o Erasing logic must remain untouched as well.
>
> In order for the types to remain u64, the 'memtype_interval' calls are
> introduced, as opposed to simply using struct interval_tree.
>
> In addition, pat tree might potentially also benefit by the fast overlap
> detection for the insertion case when looking up the first overlapping node
> in the tree.
>
> Finally, I've tested this on various servers, via sanity warnings, running
> side by side with the current version and so far see no differences in the
> returned pointer node when doing memtype_rb_lowest_match() lookups.
>
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: x...@kernel.org
> Signed-off-by: Davidlohr Bueso
> ---
> arch/x86/mm/pat.c| 22 +++
> arch/x86/mm/pat_rbtree.c | 151
> ++-
> 2 files changed, 43 insertions(+), 130 deletions(-)
I suppose this will be carried in -mm?
If so and if this patch is regression free, then:
Acked-by: Ingo Molnar
Thanks,
Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] backlight: pwm_bl: switch to power-of-2 base for fixed-point math
On Thu, Sep 19, 2019 at 04:06:19PM +0200, Rasmus Villemoes wrote:
> Using a power-of-2 instead of power-of-10 base makes the computations
> much cheaper. 2^16 is safe; retval never becomes more than 2^48 +
> 2^16/2. On a 32 bit platform, the very expensive 64/32 division at the
> end of cie1931() instead becomes essentially free (a shift by 32 is
> just a register rename).
>
> Signed-off-by: Rasmus Villemoes
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/pwm_bl.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index aee6839e024a..102bc191310f 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -148,7 +148,8 @@ static const struct backlight_ops pwm_backlight_ops = {
> };
>
> #ifdef CONFIG_OF
> -#define PWM_LUMINANCE_SCALE 1 /* luminance scale */
> +#define PWM_LUMINANCE_SHIFT 16
> +#define PWM_LUMINANCE_SCALE (1 << PWM_LUMINANCE_SHIFT) /* luminance scale */
>
> /*
> * CIE lightness to PWM conversion.
> @@ -165,23 +166,25 @@ static const struct backlight_ops pwm_backlight_ops = {
> * The following function does the fixed point maths needed to implement the
> * above formula.
> */
> -static u64 cie1931(unsigned int lightness, unsigned int scale)
> +static u64 cie1931(unsigned int lightness)
> {
> u64 retval;
>
> /*
>* @lightness is given as a number between 0 and 1, expressed
> - * as a fixed-point number in scale @scale. Convert to a
> - * percentage, still expressed as a fixed-point number, so the
> - * above formulas can be applied.
> + * as a fixed-point number in scale
> + * PWM_LUMINANCE_SCALE. Convert to a percentage, still
> + * expressed as a fixed-point number, so the above formulas
> + * can be applied.
>*/
> lightness *= 100;
> - if (lightness <= (8 * scale)) {
> + if (lightness <= (8 * PWM_LUMINANCE_SCALE)) {
> retval = DIV_ROUND_CLOSEST(lightness * 10, 9033);
> } else {
> - retval = (lightness + (16 * scale)) / 116;
> + retval = (lightness + (16 * PWM_LUMINANCE_SCALE)) / 116;
> retval *= retval * retval;
> - retval = DIV_ROUND_CLOSEST_ULL(retval, (scale * scale));
> + retval += PWM_LUMINANCE_SCALE/2;
> + retval >>= 2*PWM_LUMINANCE_SHIFT;
> }
>
> return retval;
> @@ -215,8 +218,7 @@ int pwm_backlight_brightness_default(struct device *dev,
> /* Fill the table using the cie1931 algorithm */
> for (i = 0; i < data->max_brightness; i++) {
> retval = cie1931((i * PWM_LUMINANCE_SCALE) /
> - data->max_brightness, PWM_LUMINANCE_SCALE) *
> - period;
> + data->max_brightness) * period;
> retval = DIV_ROUND_CLOSEST_ULL(retval, PWM_LUMINANCE_SCALE);
> if (retval > UINT_MAX)
> return -EINVAL;
> --
> 2.20.1
Re: [PATCH 3/5] backlight: pwm_bl: drop use of int_pow()
On Thu, Sep 19, 2019 at 04:06:18PM +0200, Rasmus Villemoes wrote:
> The scheduler uses a (currently private) fixed_power_int() in its load
> average computation for computing powers of numbers 0 < x < 1
> expressed as fixed-point numbers, which is also what we want here. But
> that requires the scale to be a power-of-2.
It feels like there is some rationale missing in the description here.
What is the benefit of replacing the explicit int_pow() with the
implicit multiplications?
Daniel.
>
> We could (and a following patch will) change to use a power-of-2 scale,
> but for a fixed small exponent of 3, there's no advantage in using
> repeated squaring.
>
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/video/backlight/pwm_bl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 9252d51f31b9..aee6839e024a 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -179,7 +179,8 @@ static u64 cie1931(unsigned int lightness, unsigned int
> scale)
> if (lightness <= (8 * scale)) {
> retval = DIV_ROUND_CLOSEST(lightness * 10, 9033);
> } else {
> - retval = int_pow((lightness + (16 * scale)) / 116, 3);
> + retval = (lightness + (16 * scale)) / 116;
> + retval *= retval * retval;
> retval = DIV_ROUND_CLOSEST_ULL(retval, (scale * scale));
> }
>
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Documentation: Fix warning in drm-kmsc-helpers.rst
From: Sean Paul
Fixes the following warning:
../include/drm/drm_atomic_state_helper.h:1: warning: no structured comments
found
Fixes: 9ef8a9dc4b21 ("drm: Extract drm_atomic_state_helper.[hc]")
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul
---
Documentation/gpu/drm-kms-helpers.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 3868008db8a9..9668a7fe2408 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -77,9 +77,6 @@ Atomic State Reset and Initialization
Atomic State Helper Reference
-
-.. kernel-doc:: include/drm/drm_atomic_state_helper.h
- :internal:
-
.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:export:
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] backlight: pwm_bl: eliminate a 64/32 division
On Thu, Sep 19, 2019 at 04:06:17PM +0200, Rasmus Villemoes wrote:
> lightness*1000 is nowhere near overflowing 32 bits, so we can just use
> an ordinary 32/32 division, which is much cheaper than the 64/32 done
> via do_div().
>
> Signed-off-by: Rasmus Villemoes
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/pwm_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index be36be1cacb7..9252d51f31b9 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -177,7 +177,7 @@ static u64 cie1931(unsigned int lightness, unsigned int
> scale)
>*/
> lightness *= 100;
> if (lightness <= (8 * scale)) {
> - retval = DIV_ROUND_CLOSEST_ULL(lightness * 10, 9033);
> + retval = DIV_ROUND_CLOSEST(lightness * 10, 9033);
> } else {
> retval = int_pow((lightness + (16 * scale)) / 116, 3);
> retval = DIV_ROUND_CLOSEST_ULL(retval, (scale * scale));
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] backlight: pwm_bl: fix cie1913 comments and constant
On Thu, Sep 19, 2019 at 04:06:16PM +0200, Rasmus Villemoes wrote:
> The "break-even" point for the two formulas is L==8, which is also
> what the code actually implements. [Incidentally, at that point one
> has Y=0.008856, not 0.08856].
>
> Moreover, all the sources I can find say the linear factor is 903.3
> rather than 902.3, which makes sense since then the formulas agree at
> L==8, both yielding the 0.008856 figure to four significant digits.
Indeed. Interestingly the following doc (with a high search rank in
Google) has exactly this inconsistency and uses different values at
different times:
http://www.photonstophotos.net/GeneralTopics/Exposure/Psychometric_Lightness_and_Gamma.htm
>
> Signed-off-by: Rasmus Villemoes
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/pwm_bl.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 2201b8c78641..be36be1cacb7 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -155,8 +155,8 @@ static const struct backlight_ops pwm_backlight_ops = {
> *
> * The CIE 1931 lightness formula is what actually describes how we perceive
> * light:
> - * Y = (L* / 902.3) if L* ≤ 0.08856
> - * Y = ((L* + 16) / 116)^3if L* > 0.08856
> + * Y = (L* / 903.3) if L* ≤ 8
> + * Y = ((L* + 16) / 116)^3if L* > 8
> *
> * Where Y is the luminance, the amount of light coming out of the screen,
> and
> * is a number between 0.0 and 1.0; and L* is the lightness, how bright a
> human
> @@ -169,9 +169,15 @@ static u64 cie1931(unsigned int lightness, unsigned int
> scale)
> {
> u64 retval;
>
> + /*
> + * @lightness is given as a number between 0 and 1, expressed
> + * as a fixed-point number in scale @scale. Convert to a
> + * percentage, still expressed as a fixed-point number, so the
> + * above formulas can be applied.
> + */
> lightness *= 100;
> if (lightness <= (8 * scale)) {
> - retval = DIV_ROUND_CLOSEST_ULL(lightness * 10, 9023);
> + retval = DIV_ROUND_CLOSEST_ULL(lightness * 10, 9033);
> } else {
> retval = int_pow((lightness + (16 * scale)) / 116, 3);
> retval = DIV_ROUND_CLOSEST_ULL(retval, (scale * scale));
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework
On 10/7/19 8:40 AM, Steven Rostedt wrote: On Sun, 6 Oct 2019 10:18:11 -0700 Linus Torvalds wrote: On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote: Well, one thing we *can* do is if (a) if we can create a kselftest branch which we know is stable and won't change, and (b) we can get assurances that Linus *will* accept that branch during the next merge window, those subsystems which want to use kself test can simply pull it into their tree. Yes. At the same time, I don't think it needs to be even that fancy. Even if it's not a stable branch that gets shared between different developers, it would be good to just have people do a "let's try this" throw-away branch to use the kunit functionality and verify that "yeah, this is fairly convenient for ext4". It doesn't have to be merged in that form, but just confirmation that the infrastructure is helpful before it gets merged would be good. Can't you just create an ext4 branch that has the kselftest-next branch in it, that you build upon. And push that after the kunit test is merged? In the past I've had to rely on other branches in next, and would just hold two branches myself. One with everything not dependent on the other developer's branch, and one with the work that was. At the merge window, I would either merge the two or just send two pull requests with the two branches. I do something similar when I am working on top of a branch that isn't already in the mainline. In any case, repeating myself Let's work on top of - it is rebased to 5.4-rc1 and ready for use. https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/log/?h=test Let's use that for kunit work for 5.5. I won't add any kselftest patches to it and keep it dedicated for kunit work. When tests are ready for upstream, I can keep adding them to this branch. thanks, -- Shuah
Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework
On Sun, 6 Oct 2019 10:18:11 -0700 Linus Torvalds wrote: > On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote: > > > > Well, one thing we *can* do is if (a) if we can create a kselftest > > branch which we know is stable and won't change, and (b) we can get > > assurances that Linus *will* accept that branch during the next merge > > window, those subsystems which want to use kself test can simply pull > > it into their tree. > > Yes. > > At the same time, I don't think it needs to be even that fancy. Even > if it's not a stable branch that gets shared between different > developers, it would be good to just have people do a "let's try this" > throw-away branch to use the kunit functionality and verify that > "yeah, this is fairly convenient for ext4". > > It doesn't have to be merged in that form, but just confirmation that > the infrastructure is helpful before it gets merged would be good. Can't you just create an ext4 branch that has the kselftest-next branch in it, that you build upon. And push that after the kunit test is merged? In the past I've had to rely on other branches in next, and would just hold two branches myself. One with everything not dependent on the other developer's branch, and one with the work that was. At the merge window, I would either merge the two or just send two pull requests with the two branches. -- Steve
Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework
On 10/7/19 2:40 AM, Brendan Higgins wrote: On Sun, Oct 6, 2019 at 10:18 AM Linus Torvalds wrote: On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote: Well, one thing we *can* do is if (a) if we can create a kselftest branch which we know is stable and won't change, and (b) we can get assurances that Linus *will* accept that branch during the next merge window, those subsystems which want to use kself test can simply pull it into their tree. Yes. At the same time, I don't think it needs to be even that fancy. Even if it's not a stable branch that gets shared between different developers, it would be good to just have people do a "let's try this" throw-away branch to use the kunit functionality and verify that "yeah, this is fairly convenient for ext4". It doesn't have to be merged in that form, but just confirmation that the infrastructure is helpful before it gets merged would be good. I thought we already had done this satisfactorily. Adding a couple more tests will only help in the long run. The idea is to see can this help We have one proof-of-concept test in the branch in the kselftest repo (proc sysctl test) that went out in the pull request, and we also had some other tests that were not in the pull request (there is the ext4 timestamp stuff mentioned above, and we also had one against the list data structure), which we were planning on sending out for review once Shuah's pull request was accepted. I know the apparmor people also wrote some tests that they said were useful; however, I have not coordinated with them on upstreaming their tests. I know of some other people who are using it, but I don't think the tests are as far along for upstreaming. Maybe that is a good start. To get the tests that are already in use and get them in shape for upstream. The point is: I thought we had plenty of signal that KUnit would be useful to have merged into the mainline kernel. I thought the only reason it was rejected for 5.4 was due to the directory name issue combined with bad timing. That is probably the initial thought. However, it makes perfect sense to add a couple of tests in. We have a few weeks anyway and it gives us more confidence on kunit. I already have a branch that is in linux-next and it just has kunit in it and I will rebase it to 5.4-rc1. https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/log/?h=test Let's use that for kunit work for 5.5. I won't add any kselftest patches to it and keep it dedicated for kunit work. When tests are ready for upstream, I can keep adding them to this branch. thanks, -- Shuah
Re: [PULL] drm-misc-fixes
On Thu, Oct 3, 2019 at 9:26 AM Maxime Ripard wrote: > > Hi, > > On Wed, Oct 02, 2019 at 10:06:04PM +0200, Maxime Ripard wrote: > > Hi Dave, Daniel, > > > > I hope that you enjoy XDC if you could make it this year :) > > > > Here's the first round of fixes for drm-misc > > > > Maxime > > > > drm-misc-fixes-2019-10-02: > > - One include fix for tilcdc > > - A memory leak fix for Komeda > > - Some fixes for resources cleanups with writeback > > So it turns out that while that tag was pushed, I forgot to push the > branch first, and now we have a conflict. > > Let's drop this PR, I'll do another one. Hm, does dim not check for that? Can I volunteer you for a patch? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 --- Comment #54 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Dmitri Seletski from comment #48) > (In reply to Mike Lothian from comment #47) > > It's selected automatically if you set DRM_FBDEV_EMULATION - which is > > "Enable legacy fbdev support for your modesetting driver" and unset above > > > > That should get your console working > > Mike, just to clarify, console is working until AMDGPU driver is loaded. The console is running on efifb or vga mode until the driver loads. If you don't have DRM_FBDEV_EMULATION enabled, there is nothing for the console to bind to once the driver loads. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
