- 18 Mar, 2020 29 commits
-
-
Ville Syrjälä authored
Currently the DispID tile block gets parsed in drm_get_edid(), which is an odd place for it considering we parse nothing else there. Also this doesn't work for override EDIDs since drm_connector_update_edid_property() refuses to do its job twice in such cases. Thus we never update the tile property with results of the DispID tile block parsing during drm_get_edid(). To fix this let's just move the tile block parsing to happen during drm_connector_update_edid_property(), which is where we parse a bunch of other stuff as well (and where we update both the EDID and tile properties). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-10-ville.syrjala@linux.intel.comReviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
Ville Syrjälä authored
Throw out the magic '5' from validate_displayid() and replace with the actual thing we mean sizeof(header)+checksum. Also rewrite the checksum loop to be less hard to parse for mere mortals. Signed-off-by:
-
Ville Syrjälä authored
The EDID extension block checksum byte is not part of the actual DispID data, so don't use it in validate_displayid(). Signed-off-by:
-
Ville Syrjälä authored
Currently the code assumes that the entire EDID extesion block can be taken up by the DispID blocks. That is not true. There is at least always the DispID checksum, and potentially fill bytes if the extension block uses the interior fill scheme to pad out to fill EDID block size. So let's not parse the checksum or the fill bytes as DispID blocks by having drm_find_displayid_extension() return the actual length of the DispID data to the caller. Signed-off-by:
-
Ville Syrjälä authored
Instead of everyone having to call validate_displayid() let's just have drm_find_displayid_extension() do it for them. Signed-off-by:
-
Ville Syrjälä authored
As with the byte offset (idx) drm_find_displayid_extension() is the only one who actually knows how much data the resulting DispID block can contain. So return the length from therein instead of assuming it's the EDID block length all over. Signed-off-by:
-
Ville Syrjälä authored
The fact that the DispID starts at byte offset 1 is due to the DispID coming from and EDID extension block (the first byte being the extesion block tag). Instead of hadrdocoding that idx==1 assumptions all over let's just have drm_find_displayid_extension() return it since it actually knows what it's talking about. If at some point someone comes across a DispID which is not embedded inside an EDID the function that returns the new type of DispID can return it's own byte offset without having to updated all the code. TODO: should probably just get rid of that idx thing altogether and just return the thing we want directly. Signed-off-by: -
Ville Syrjälä authored
A+B on the previous line, B+A on the next line. Brain hurts. Signed-off-by:
-
Ville Syrjälä authored
Make the topology id const since we don't want to change it. Signed-off-by:
-
Wambui Karuga authored
Since commit 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails and should return void. Therefore, remove its use as the return value of various debugfs_init() functions in drm, and have these functions return 0 directly. v2: convert debugfs_init() functions to return 0 instead of void to avoid build breakage. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200310133121.27913-16-wambui.karugax@gmail.com
-
Wambui Karuga authored
Since commit 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails and should return void. Therefore, remove its use as the return value of debugfs_init() functions and have the functions return void. v2: convert intel_display_debugfs_register() stub to return void too. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Wambui Karuga authored
Since 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), there is no need to ever check the return value for drm_debugfs_create_files(). Therefore remove the checks for the return value and subsequent error handling in omap_debugfs_init(). These changes also enables the changing of omap_debugfs_init() to return 0 directly. v2: convert omap_debugfs_init() to return 0 instead of void to avoid introduction of build issues and enable individual driver compilation. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
-
Wambui Karuga authored
Since 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail) drm_debugfs_create_files() should return void. Therefore, remove its use as the return value in pl111_debugfs_init(), and have the function return 0 directly. v2: have pl111_debugfs_init() return 0 instead of void to avoid build breakage for individual compilation. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
-
Wambui Karuga authored
Since 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), there is no need to ever check for the the return value of debugfs_create_file() and drm_debugfs_create_files(). Therefore, remove unnecessary checks and error handling in nouveau_drm_debugfs_init() and have the function return 0 directly. v2: have nouveau_drm_debugfs_init() return 0 instead of void so as not to introduce any build warnings to enable individual patch compilation. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
-
Wambui Karuga authored
Since 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails and should return void. Therefore, remove its use as the return value of drm_vram_mm_debugfs_init(), and have the function return 0 directly. v2: have drm_vram_mm_debugfs_init() return 0 instead of void to avoid introducing build issues and build breakage. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Wambui Karuga authored
Since commit 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails, and should return void. This change therefore removes it uses as a return value in various functions across drm/sti. With these changes, the affected functions have been changed to use a void return value. v2: convert sti_mixer_debugfs_init() and sti_compositor_debugfs_init() to return void too. Also have sti_drm_dbg_init() to return 0 to avoid build issues. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
-
Wambui Karuga authored
Since commit 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files never fails and only returns 0. Therefore, the unnecessary checks for its return value and error handling in various debugfs_init() functions in drm/msm and have the functions return 0 directly. v2: have debug functions return 0 instead of void to avoid build breakage and ensure standalone compilation. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
-
Wambui Karuga authored
Since commit 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails and only returns 0. Therefore, remove the unnecessary check of its return value and error handling in etnaviv_debugfs_init() and have the function return 0 directly. v2: have etnaviv_debugfs_init() return 0 instead of void to ensure individual compilation and avoid build breakage. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
-
Wambui Karuga authored
Since commit 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails and should return void. Therefore, remove its use as the return value of hdlcd_debugfs_init() and have the latter function return 0 directly. v2: make hdlcd_debugfs_init() return 0 instead of void to ensure that each patch compiles individually. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
Liviu Dudau <liviu.dudau@arm.com> Reviewed-by:
-
Wambui Karuga authored
Since commit 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails and should return void. Therefore, remove its use as the return value of arcpgu_debugfs_init() and have the latter function return 0 directly. v2: convert the function to return 0 instead of void to avoid breaking the build and ensure that this individual patch compiles properly. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Reviewed-by:
-
Wambui Karuga authored
Since 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails and should return void. Therefore, remove unnecessary check and error handling for the return value of drm_debugfs_create_files() in vc4_debugfs_init(). v2: remove conversion of vc4_debugfs_init() to void to enable individual compilation and avoid build issues and breakage. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
-
Wambui Karuga authored
Since commit 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails and should return void. Therefore, remove its use as the return value of v3d_debugfs_init() and have the function return 0 directly instead. v2: remove conversion of v3d_debugfs_init() to void to avoid build breakage and enable individual compilation. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
-
Wambui Karuga authored
Since 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail), drm_debugfs_create_files() never fails. Therefore, remove the check and error handling of the return value of drm_debugfs_create_files() as it is not needed in tilcdc_debugfs_init(). Also remove local variables that are not used after the changes. v2: remove conversion of tilcdc_debugfs_init() to void to avoid build breakage and enable individual compilation. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
Jyri Sarha <jsarha@ti.com> Reviewed-by:
-
Wambui Karuga authored
Since 987d65d0 (drm: debugfs: make drm_debugfs_create_files() never fail) there is no need to check the return value of drm_debugfs_create_files(). Therefore, remove the return checks and error handling of the drm_debugfs_create_files() function from various debugfs init functions in drm/tegra and have them return 0 directly. v2: remove conversion of tegra_debugfs_init() to void to avoid build breakage. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
Igor Matheus Andrade Torrente authored
Replace "pionter" with "pointer" in the drm_gem_handle_create description. Changes in v2: - Change subject text Signed-off-by:
Igor Matheus Andrade Torrente <igormtorrente@gmail.com> Signed-off-by:
-
Joe Perches authored
Convert /* fallthrough */ style comments to fallthrough; Convert the various uses of fallthrough comments to fallthrough; Done via script Link: https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe@perches.com/ And by hand: This file has a fallthrough comment outside of an #ifdef block that causes gcc to emit a warning if converted in-place. So move the new fallthrough; inside the containing #ifdef/#endif too. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Daniel Vetter authored
drm_encoder_slave is really not something anyone should be using, the last real user is only nouveau. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Andrzej Pietrasiewicz authored
The new struct contains afbc-specific data. The new function can be used by drivers which support afbc to complete the preparation of struct drm_afbc_framebuffer. It must be called after allocating the said struct and calling drm_gem_fb_init_with_funcs(). Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
James Qian Wang <james.qian.wang@arm.com> Acked-by:
-
Andrzej Pietrasiewicz authored
Allow allocating a specialized version of struct drm_framebuffer by moving the actual fb allocation out of drm_gem_fb_create_with_funcs(); the respective functions names are adjusted to reflect that fact. Please note, though, that standard size checks are performed on buffers, so the drm_gem_fb_init_with_funcs() is useful for cases where those standard size checks are appropriate or at least don't conflict the checks to be performed in the specialized case. Thanks to this change the drivers can call drm_gem_fb_init_with_funcs() having allocated their special version of struct drm_framebuffer, exactly the way the new version of drm_gem_fb_create_with_funcs() does. Signed-off-by:
-
- 17 Mar, 2020 1 commit
-
-
Maxime Ripard authored
Jernej needs some patches that got merged in -rc5. Signed-off-by:Maxime Ripard <maxime@cerno.tech>
-
- 16 Mar, 2020 7 commits
-
-
Chris Wilson authored
[ 1715.899800] BUG: KCSAN: data-race in drm_gem_handle_create_tail / drm_gem_object_handle_put_unlocked [ 1715.899838] [ 1715.899861] write to 0xffff8881830f3604 of 4 bytes by task 7834 on cpu 1: [ 1715.899896] drm_gem_handle_create_tail+0x62/0x250 [ 1715.899927] drm_gem_open_ioctl+0xc1/0x160 [ 1715.899956] drm_ioctl_kernel+0xe4/0x120 [ 1715.899981] drm_ioctl+0x297/0x4c7 [ 1715.900003] ksys_ioctl+0x89/0xb0 [ 1715.900027] __x64_sys_ioctl+0x42/0x60 [ 1715.900052] do_syscall_64+0x6e/0x2c0 [ 1715.900079] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1715.900100] [ 1715.900119] read to 0xffff8881830f3604 of 4 bytes by task 8137 on cpu 0: [ 1715.900149] drm_gem_object_handle_put_unlocked+0x31/0x130 [ 1715.900180] drm_gem_object_release_handle+0x93/0xe0 [ 1715.900208] drm_gem_handle_delete+0x7b/0xe0 [ 1715.900235] drm_gem_close_ioctl+0x61/0x80 [ 1715.900264] drm_ioctl_kernel+0xe4/0x120 [ 1715.900291] drm_ioctl+0x297/0x4c7 [ 1715.900316] ksys_ioctl+0x89/0xb0 [ 1715.900340] __x64_sys_ioctl+0x42/0x60 [ 1715.900363] do_syscall_64+0x6e/0x2c0 [ 1715.900388] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
Mark up the potential racy read in drm_mm_initialized(), as we want a cheap and cheerful check: [ 121.098731] BUG: KCSAN: data-race in _i915_gem_object_create_stolen [i915] / rm_hole [ 121.098766] [ 121.098789] write (marked) to 0xffff8881f01ed330 of 8 bytes by task 3568 on cpu 3: [ 121.098831] rm_hole+0x64/0x140 [ 121.098860] drm_mm_insert_node_in_range+0x3d3/0x6c0 [ 121.099254] i915_gem_stolen_insert_node_in_range+0x91/0xe0 [i915] [ 121.099646] _i915_gem_object_create_stolen+0x9d/0x100 [i915] [ 121.100047] i915_gem_object_create_region+0x7a/0xa0 [i915] [ 121.100451] i915_gem_object_create_stolen+0x33/0x50 [i915] [ 121.100849] intel_engine_create_ring+0x1af/0x280 [i915] [ 121.101242] __execlists_context_alloc+0xce/0x3d0 [i915] [ 121.101635] execlists_context_alloc+0x25/0x40 [i915] [ 121.102030] intel_context_alloc_state+0xb6/0xf0 [i915] [ 121.102420] __intel_context_do_pin+0x1ff/0x220 [i915] [ 121.102815] i915_gem_do_execbuffer+0x46b4/0x4c20 [i915] [ 121.103211] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 121.103244] drm_ioctl_kernel+0xe4/0x120 [ 121.103269] drm_ioctl+0x297/0x4c7 [ 121.103296] ksys_ioctl+0x89/0xb0 [ 121.103321] __x64_sys_ioctl+0x42/0x60 [ 121.103349] do_syscall_64+0x6e/0x2c0 [ 121.103377] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 121.103403] [ 121.103426] read to 0xffff8881f01ed330 of 8 bytes by task 3109 on cpu 1: [ 121.103819] _i915_gem_object_create_stolen+0x30/0x100 [i915] [ 121.104228] i915_gem_object_create_region+0x7a/0xa0 [i915] [ 121.104631] i915_gem_object_create_stolen+0x33/0x50 [i915] [ 121.105025] intel_engine_create_ring+0x1af/0x280 [i915] [ 121.105420] __execlists_context_alloc+0xce/0x3d0 [i915] [ 121.105818] execlists_context_alloc+0x25/0x40 [i915] [ 121.106202] intel_context_alloc_state+0xb6/0xf0 [i915] [ 121.106595] __intel_context_do_pin+0x1ff/0x220 [i915] [ 121.106985] i915_gem_do_execbuffer+0x46b4/0x4c20 [i915] [ 121.107375] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 121.107409] drm_ioctl_kernel+0xe4/0x120 [ 121.107437] drm_ioctl+0x297/0x4c7 [ 121.107464] ksys_ioctl+0x89/0xb0 [ 121.107489] __x64_sys_ioctl+0x42/0x60 [ 121.107511] do_syscall_64+0x6e/0x2c0 [ 121.107535] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
Kees Cook authored
Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, lift such variables up into the next code block. drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_eld’: drivers/gpu/drm/drm_edid.c:4395:9: warning: statement will never be executed [-Wswitch-unreachable] 4395 | int sad_count; | ^~~~~~~~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 v2: move into function block instead being switch-local (Ville Syrjälä) Signed-off-by:Kees Cook <keescook@chromium.org> [danvet: keep the changelog] Signed-off-by:
-
Benjamin Gaignard authored
Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by:
-
Benjamin Gaignard authored
Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by:
-
Benjamin Gaignard authored
Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by:
-
Benjamin Gaignard authored
Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by:
-
- 14 Mar, 2020 2 commits
-
-
Fabrizio Castro authored
Add binding for the idk-1110wr LVDS panel from Advantech. Some panel-specific documentation can be found here: https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htmSigned-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by:
-
Kamlesh Gurudasani authored
This fixes the following sparse warning: drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: sparse: incorrect type in assignment (different base types) drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: expected unsigned short [usertype] drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: got restricted __be16 [usertype] drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: sparse: incorrect type in assignment (different base types) drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: expected unsigned short [usertype] drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: got restricted __be16 [usertype] Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com> Signed-off-by:
-
- 13 Mar, 2020 1 commit
-
-
Sam Ravnborg authored
Fix following type af warnings in the panel bindings: Warning (unit_address_vs_reg): /example-0/dsi/panel: node has a reg or ranges property, but no unit name Warning (unit_address_vs_reg): /example-0/dsi@ff450000: node has a unit name, but no reg property Removing the "@xxx" from the node name fixed first warning. Adding a missing reg property fixed the second warning v2: - renamed mdss_dsi to dsi in panel-simple-dsi.yaml (Rob) Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
