summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* fbcon: fix null-ptr-deref in fbcon_switchQiujun Huang2020-03-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated. syzkaller report: https://lkml.org/lkml/2020/3/27/403 general protection fault, probably for non-canonical address 0xdffffc000000006c: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367] RIP: 0010:fbcon_switch+0x28f/0x1740 drivers/video/fbdev/core/fbcon.c:2260 Call Trace: redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008 vc_do_resize+0xfe7/0x1360 drivers/tty/vt/vt.c:1295 fbcon_init+0x1221/0x1ab0 drivers/video/fbdev/core/fbcon.c:1219 visual_init+0x305/0x5c0 drivers/tty/vt/vt.c:1062 do_bind_con_driver+0x536/0x890 drivers/tty/vt/vt.c:3542 do_take_over_console+0x453/0x5b0 drivers/tty/vt/vt.c:4122 do_fbcon_takeover+0x10b/0x210 drivers/video/fbdev/core/fbcon.c:588 fbcon_fb_registered+0x26b/0x340 drivers/video/fbdev/core/fbcon.c:3259 do_register_framebuffer drivers/video/fbdev/core/fbmem.c:1664 [inline] register_framebuffer+0x56e/0x980 drivers/video/fbdev/core/fbmem.c:1832 dlfb_usb_probe.cold+0x1743/0x1ba3 drivers/video/fbdev/udlfb.c:1735 usb_probe_interface+0x310/0x800 drivers/usb/core/driver.c:374 accessing vc_cons[logo_shown].d->vc_top causes the bug. Reported-by: syzbot+732528bae351682f1f27@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200329085647.25133-1-hqjagain@gmail.com
* drm/vc4: Fix HDMI mode validationNicolas Saenz Julienne2020-03-271-4/+16
| | | | | | | | | | | | | | | Current mode validation impedes setting up some video modes which should be supported otherwise. Namely 1920x1200@60Hz. Fix this by lowering the minimum HDMI state machine clock to pixel clock ratio allowed. Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Suggested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulienne@suse.de
* drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call, v2Hans de Goede2020-03-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The vboxvideo driver is missing a call to remove conflicting framebuffers. Surprisingly, when using legacy BIOS booting this does not really cause any issues. But when using UEFI to boot the VM then plymouth will draw on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered /dev/fb1 as fbdev emulation). VirtualBox will actual display the output of both devices (I guess it is showing whatever was drawn last), this causes weird artifacts because of pitch issues in the efifb when the VM window is not sized at 1024x768 (the window will resize to its last size once the vboxvideo driver loads, changing the pitch). Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers() call fixes this. Changes in v2: -Make the drm_fb_helper_remove_conflicting_pci_framebuffers() call one of the first things we do in our probe() method Cc: stable@vger.kernel.org Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200325144310.36779-1-hdegoede@redhat.com
* drm/panel-simple: drop use of data-mapping propertySam Ravnborg2020-03-251-11/+0
| | | | | | | | | | | | | | | | | | | The "data-mapping" property may not be the best way to describe the interface between panels and display interfaces. Drop use of in the panel-simple driver, so we have time to find the right way to describe this interface. Fixes: 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support") Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Cc: Rob Herring <robh@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200314153047.2486-3-sam@ravnborg.org
* dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help textGeert Uytterhoeven2020-03-251-5/+6
| | | | | | | | | | | | | | Improve the help text for the CONFIG_DMABUF_MOVE_NOTIFY symbol by: 1. Removing duplicated single quotes, 2. Adding a missing subject, 3. Fixing a misspelling of "yet", 4. Wrapping long lines. Fixes: bb42df4662a44765 ("dma-buf: add dynamic DMA-buf handling v15") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324125442.21983-1-geert+renesas@glider.be
* drm: Mark up racy check of drm_gem_object.handle_countChris Wilson2020-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ 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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200309120151.7675-1-chris@chris-wilson.co.uk
* drm/edid: Distribute switch variables for initializationKees Cook2020-03-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/202003060930.DDCCB6659@keescook
* drm: lock: Clean up documentationBenjamin Gaignard2020-03-161-6/+5
| | | | | | | | Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-2-benjamin.gaignard@st.com
* drm: bufs: Clean up documentationBenjamin Gaignard2020-03-161-10/+10
| | | | | | | | Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-3-benjamin.gaignard@st.com
* drm: vm: Clean up documentationBenjamin Gaignard2020-03-161-8/+8
| | | | | | | | Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-1-benjamin.gaignard@st.com
* drm: context: Clean up documentationBenjamin Gaignard2020-03-161-14/+14
| | | | | | | | Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-4-benjamin.gaignard@st.com
* drm/tiny: fix sparse warning: incorrect type in assignment (different base ↵Kamlesh Gurudasani2020-03-141-1/+1
| | | | | | | | | | | | | | | | | | types) 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: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1583684084-4694-1-git-send-email-kamlesh.gurudasani@gmail.com
* drm: Remove drm dp mst destroy_connector callbacksPankaj Bharadiya2020-03-113-33/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical amongst every driver and don't do anything other than cleaning up the connector((drm_connector_unregister()/drm_connector_put())) except for amdgpu_dm driver where some amdgpu_dm specific code in there. This connector cleaning up is now being handled in the drm core so driver destroy_connector callbacks are not needed (except for amdgpu_dm) hence remove them. Removal is done with below sementic patch: @r1@ identifier func, E; @@ struct drm_dp_mst_topology_cbs E = { ..., - .destroy_connector = func }; @delete depends on r1@ identifier r1.func; @@ - static void func(...){...} Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-6-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
* drm: Add drm_dp_destroy_connector helper and use itPankaj Bharadiya2020-03-111-2/+14
| | | | | | | | | | | | | | | | | | | | drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical amongst every driver and don't do anything other than cleaning up the connector (drm_connector_unregister()/drm_connector_put()) except for amdgpu_dm driver where some amdgpu_dm specific code in there which I an not sure if it should stay or not. Create and use a helper which calls driver's destroy_connector hook if available otherwise does cleanup internally. This is the step towards removing identical hooks from every driver. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-5-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
* drm: Remove dp mst register connector callbacksPankaj Bharadiya2020-03-114-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_dp_mst_port_add_connector() directly calls the drm_connector_register() now and drm_dp_mst_topology_mgr_cbs.register_connector callback is not getting called anymore. Hence remove all drm_dp_mst_topology_mgr_cbs.register_connector callbacks. This is the preparatory step for removing the drm_dp_mst_topology_mgr_cbs.register_connector callback hook. The removal is done with below sementic patch: @r1@ identifier func, E; @@ struct drm_dp_mst_topology_cbs E = { ..., - .register_connector = func }; @delete depends on r1@ identifier r1.func; @@ - static void func(...){...} Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-3-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
* drm: Register connector instead of calling register_connector callbackPankaj Bharadiya2020-03-111-1/+1
| | | | | | | | | | | | | | | | | drm_dp_mst_topology_mgr_cbs.register_connector callbacks are literally identical amongst every driver and don't do anything other than calling drm_connector_register(). Hence call drm_connector_register() directly instead of a callback. This is the preparatory step for removing the drm_dp_mst_topology_mgr_cbs.register_connector callback hook. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-2-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
* drm/edid: Add function to parse EDID descriptors for monitor rangeManasi Navare2020-03-111-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adaptive Sync is a VESA feature so add a DRM core helper to parse the EDID's detailed descritors to obtain the adaptive sync monitor range. Store this info as part fo drm_display_info so it can be used across all drivers. This part of the code is stripped out of amdgpu's function amdgpu_dm_update_freesync_caps() to make it generic and be used across all DRM drivers v6: * Call it monitor_range (Ville) v5: * Use the renamed flags v4: * Use is_display_descriptor() (Ville) * Name the monitor range flags (Ville) v3: * Remove the edid parsing restriction for just DP (Nicholas) * Use drm_for_each_detailed_block (Ville) * Make the drm_get_adaptive_sync_range function static (Harry, Jani) v2: * Change vmin and vmax to use u8 (Ville) * Dont store pixel clock since that is just a max dotclock and not related to VRR mode (Manasi) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-2-manasi.d.navare@intel.com
* drm/panel-simple: Fix dotclock for Logic PD Type 28Ville Syrjälä2020-03-111-1/+1
| | | | | | | | | | | | | | The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Adam Ford <aford173@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-22-ville.syrjala@linux.intel.com Reviewed-by: Adam Ford <aford173@gmail.com>
* drm/panel-sony-acx424akp: Fix dotclocksVille Syrjälä2020-03-111-2/+2
| | | | | | | | | | | | | | The currently listed dotclocks disagree with the currently listed vrefresh rates. Change the dotclocks to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-9-ville.syrjala@linux.intel.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
* drm/panel-lg-lg4573: Fix dotclockVille Syrjälä2020-03-111-1/+1
| | | | | | | | | | | | | | The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Heiko Schocher <hs@denx.de> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-7-ville.syrjala@linux.intel.com Reviewed-by: Heiko Schocher <hs@denx.de>
* drm/panel-ilitek-ili9322: Fix dotclocksVille Syrjälä2020-03-111-7/+7
| | | | | | | | | | | | | The listed dotclocks are two orders of mangnitude out. Fix them. v2: Just divide everything by 100 (Linus) Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200309133809.32585-1-ville.syrjala@linux.intel.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
* drm/panel-novatek-nt35510: Fix dotclockVille Syrjälä2020-03-111-1/+1
| | | | | | | | | | | | The dotclock is three orders of magnitude out. Fix it. v2: Just set it to 20MHz (Linus) Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200309133644.32385-1-ville.syrjala@linux.intel.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
* drm: sysfs: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai2020-03-111-1/+1
| | | | | | | | | | | Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200311073540.7108-1-tiwai@suse.de
* drm/ttm: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai2020-03-111-1/+1
| | | | | | | | | | | | Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/357174/ Signed-off-by: Christian König <christian.koenig@amd.com>
* drm/ttm: fix false positive assertChristian König2020-03-111-3/+2
| | | | | | | | | The assert sometimes incorrectly triggers when pinned BOs are destroyed. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Link: https://patchwork.freedesktop.org/patch/356737/
* drm/rockchip: rgb: don't count non-existent devices when determining subdriversHeiko Stuebner2020-03-111-1/+2
| | | | | | | | | | | | | | | | rockchip_drm_endpoint_is_subdriver() may also return error codes. For example if the target-node is in the disabled state, so no platform-device is getting created for it. In that case current code would count that as external rgb device, which in turn would make probing the rockchip-drm device fail. So only count the target as rgb device if the function actually returns 0. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121224828.4070067-1-heiko@sntech.de
* drm/dp_mst: Fix drm_dp_check_mstb_guid() return codeLyude Paul2020-03-101-2/+11
| | | | | | | | | | | | | | | | | | | | We actually expect this to return a 0 on success, or negative error code on failure. In order to do that, we check whether or not we managed to write the whole GUID and then return 0 if so, otherwise return a negative error code. Also, let's add an error message here so it's a little more obvious when this fails in the middle of a link address probe. This should fix issues with certain MST hubs seemingly stopping for no reason in the middle of the link address probe process. Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings") Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Sean Paul <sean@poorly.run> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-3-lyude@redhat.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* drm/dp_mst: Make drm_dp_mst_dpcd_write() consistent with drm_dp_dpcd_write()Lyude Paul2020-03-101-7/+4
| | | | | | | | | | | | | | | | | | | | | | | Noticed this while having some problems with hubs sometimes not being detected on the first plug. Every single dpcd read or write function returns the number of bytes transferred on success or a negative error code, except apparently for drm_dp_mst_dpcd_write() - which returns 0 on success. There's not really any good reason for this difference that I can tell, and having the two functions give differing behavior means that drm_dp_dpcd_write() will end up returning 0 on success for MST devices, but the number of bytes transferred for everything else. So, fix that and update the kernel doc. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 2f221a5efed4 ("drm/dp_mst: Add MST support to DP DPCD R/W functions") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-2-lyude@redhat.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* drm/panel-simple: Fix dotclock for Ortustech COM37H3MH. Nikolaus Schaller2020-03-101-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. There are two variants of the COM37H3M panel. The older one's COM37H3M05DTC data sheet specifies: MIN TYP MAX CLK frequency fCLK -- 22.4 26.3 MHz (in VGA mode) VSYNC Frequency fVSYNC 54 60 66 Hz VSYNC cycle time tv -- 650 -- H HSYNC frequency fHSYNC -- 39.3 -- kHz HSYNC cycle time th -- 570 -- CLK The newer one's COM37H3M99DTC data sheet says: MIN TYP MAX CLK frequency fCLK 18 19.8 27 MHz VSYNC Frequency fVSYNC 54 60 66 Hz VSYNC cycle time tv 646 650 700 H HSYNC frequency fHSYNC -- 39.0 50.0 kHz HSYNC cycle time th 504 508 630 CLK So we choose a parameter set that lies within the specs of both variants. We start at .vrefresh = 60, choose .htotal = 570 and .vtotal = 650 and end up in a clock of 22.230 MHz. Reported-by: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/e63a0533ad5b5142373437ef758aedbdb716152d.1583826198.git.hns@goldelico.com
* drm: panel: Set connector type for OrtusTech COM43H4M85ULC panelLaurent Pinchart2020-03-101-0/+1
| | | | | | | | | | The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200309184210.10042-1-laurent.pinchart@ideasonboard.com
* drm/mm: Remove redundant assignment in drm_mm_reserve_nodeAkeem G Abodunrin2020-03-101-1/+1
| | | | | | | | | | | | | In Pete Goodliffe words, "You can improve a system by adding new code. You can also improve a system by removing code" - In this case, commit "202b52b7fbf70" added new code to initialize end of the node. So, there is no need for duplicated initialization, and this patch simply removes it. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200309151156.25040-1-akeem.g.abodunrin@intel.com
* drm/meson: Add YUV420 output supportNeil Armstrong2020-03-101-21/+70
| | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. In addition if pixel stream down-sampling, the Y Cb Cr components must also be mapped differently to align with the HDMI2.0 specifications. This mode needs a different clock generation scheme since the TMDS PHY clock must match the 10x ratio with the YUV420 pixel clock, but the video encoder must run at 2x the pixel clock. This patch enables the bridge bus format negociation, and handles the YUV420 case if selected by the negociation. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-12-narmstrong@baylibre.com
* drm/meson: vclk: add support for YUV420 setupNeil Armstrong2020-03-104-35/+95
| | | | | | | | | | | | | | | | | | | | | | This patch adds clocking support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. This mode needs a different clock generation scheme since the TMDS PHY clock must match the 10x ratio with the YUV420 pixel clock, but the video encoder must run at 2x the pixel clock. This patch adds the TMDS PHY clock value in all the video clock setup in order to better support these specific uses cases and switch to the Common Clock framework for clocks handling in the future. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-11-narmstrong@baylibre.com
* drm/meson: venc: add support for YUV420 setupNeil Armstrong2020-03-103-4/+9
| | | | | | | | | | | | | | | | | This patch adds encoding support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. In addition if pixel stream down-sampling, the Y Cb Cr components must also be mapped differently to align with the HDMI2.0 specifications. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-10-narmstrong@baylibre.com
* drm/meson: dw-hdmi: stop enforcing input_bus_formatNeil Armstrong2020-03-101-1/+0
| | | | | | | | | | To allow using formats from negotiation, stop enforcing input_bus_format in the private dw-plat-data struct. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-9-narmstrong@baylibre.com
* drm/meson: meson_dw_hdmi: add bridge and switch to drm_bridge_funcsNeil Armstrong2020-03-101-20/+65
| | | | | | | | | | Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local bridge, connecting it to the dw-hdmi bridge, then implement the atomic_get_input_bus_fmts/atomic_get_output_bus_fmts. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-8-narmstrong@baylibre.com
* drm/meson: venc: make drm_display_mode constNeil Armstrong2020-03-102-2/+2
| | | | | | | | | | | Before switching to bridge funcs, make sure drm_display_mode is passed as const to the venc functions. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-7-narmstrong@baylibre.com
* drm/bridge: synopsys: dw-hdmi: allow ycbcr420 modes for >= 0x200aNeil Armstrong2020-03-101-0/+6
| | | | | | | | | | | | | Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support for these modes in the connector if the platform supports them. We limit these modes to DW-HDMI IP version >= 0x200a which are designed to support HDMI2.0 display modes. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-6-narmstrong@baylibre.com
* drm/bridge: synopsys: dw-hdmi: add bus format negociationNeil Armstrong2020-03-101-4/+277
| | | | | | | | | | | Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate the possible output and input formats for the current mode and monitor, and use the negotiated formats in a basic atomic_check callback. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-5-narmstrong@baylibre.com
* drm/bridge: dw-hdmi: Plug atomic state hooks to the default implementationNeil Armstrong2020-03-101-0/+3
| | | | | | | | | | | Add atomic_duplicate_state/atomic_destroy_state/atomic_reset bridge funcs to allow setup of atomic bridge state. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-4-narmstrong@baylibre.com
* drm/bridge: dw-hdmi: add max bpc connector propertyJonas Karlman2020-03-101-0/+8
| | | | | | | | | | | Add the max_bpc property to the dw-hdmi connector to prepare support for 10, 12 & 16bit output support. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-3-narmstrong@baylibre.com
* drm/bridge: dw-hdmi: set mtmdsclock for deep colorJonas Karlman2020-03-101-1/+20
| | | | | | | | | | Configure the correct mtmdsclock for deep colors to prepare support for 10, 12 & 16bit output. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-2-narmstrong@baylibre.com
* drm/virtio: add case for shmem objects in virtio_gpu_cleanup_object(..)Gurchetan Singh2020-03-092-15/+20
| | | | | | | | | | | This function can be reused for hostmem objects. v2: move virtio_gpu_is_shmem() check to virtio_gpu_cleanup_object() v3: use-after free fix Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* drm/virtio: factor out the sg_table from virtio_gpu_objectGurchetan Singh2020-03-093-20/+30
| | | | | | | | | | | | A resource will be a shmem based resource or a (planned) vram based resource, so it makes sense to factor out common fields (resource handle, dumb). v2: move mapped field to shmem object Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* drm: Make drm_pci_agp_init legacyChris Wilson2020-03-091-12/+12
| | | | | | | | | | | | | Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its only caller. The diff chooses it to so it by moving drm_pci_agp_destroy earlier, but the important bit is moving the #ifdef earlier before drm_pci_agp_init. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200307093702.2269-1-chris@chris-wilson.co.uk
* Revert "drm/panel: simple: Add support for Sharp LQ150X1LG11 panels"Peter Rosin2020-03-071-27/+0
| | | | | | | | | | | | | | | This reverts commit 0f9cdd743f7f8d470fff51b11250f02fc554cf1b. The interface of the panel is LVDS, not parallel. The color depth is RGB888, not RGB565. The panel has additional features, making it not so simple. The only user (upstream) of this panel is appropriately using panel-lvds. Suggested-by: Thierry Reding <thierry.reding@gmail.com> Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200305130536.26011-1-peda@axentia.se
* drm/vboxvideo/vboxvideo.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200305105558.GA19124@embeddedor
* drm/pci: Unexport drm_get_pci_devDaniel Vetter2020-03-061-21/+5
| | | | | | | | | | | | | | | Only user left is the shadow attach for legacy drivers. v2: Shift the #ifdef CONFIG_DRM_LEGACY to now also include drm_get_pci_dev() (Thomas) Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225165835.2394442-1-daniel.vetter@ffwll.ch
* drm: Remove drm_fb_helper add, add all and remove connector callsPankaj Bharadiya2020-03-0614-62/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_fb_helper_{add,remove}_one_connector() and drm_fb_helper_single_add_all_connectors() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h This removal is done using below sementic patch and unused variable compilation warnings are fixed manually. @@ @@ - drm_fb_helper_single_add_all_connectors(...); @@ expression e1; statement S; @@ - e1 = drm_fb_helper_single_add_all_connectors(...); - S @@ @@ - drm_fb_helper_add_one_connector(...); @@ @@ - drm_fb_helper_remove_one_connector(...); Changes since v1: * Squashed warning fixes into the patch that introduced the warnings (into 5/7) (Laurent, Emil, Lyude) Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-6-pankaj.laxminarayan.bharadiya@intel.com
* drm/i915/display: Remove drm_fb_helper_{add,remove}_one_connector callsPankaj Bharadiya2020-03-061-12/+0
| | | | | | | | | | | | | | | drm_fb_helper_{add,remove}_one_connector() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-5-pankaj.laxminarayan.bharadiya@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-31 10:23:27 +0100