summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* drm/plane: Move drm_plane_enable_fb_damage_clips into coreDaniel Vetter2021-07-272-54/+54
| | | | | | | | | | | | | | | | | | | | | | We're trying to have a fairly strict split between core functionality that defines the uapi, including the docs, and the helper functions to implement it. Move drm_plane_enable_fb_damage_clips and associated kerneldoc into drm_plane from drm_damage_helper.c to fix this. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-3-daniel.vetter@ffwll.ch
* drm/plane: check that fb_damage is set up when usedDaniel Vetter2021-07-273-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's two stages of manual upload/invalidate displays: - just handling dirtyfb and uploading the entire fb all the time - looking at damage clips In the latter case we support it through fbdev emulation (with fb_defio), atomic property, and with the dirtfy clip rects. Make sure at least the atomic property is set up as the main official interface for this. Ideally we'd also check that drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up, but that's quite a bit harder to do. Ideas very much welcome. From a cursor audit drivers seem to be getting this right mostly, but better to make sure. At least no one is bypassing the accessor function. v2: - use drm_warn_once with a meaningful warning string (José) - don't splat in the atomic check code for everyone (intel-gfx-ci) Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-2-daniel.vetter@ffwll.ch
* drm/plane: remove drm_helper_get_plane_damage_clipsDaniel Vetter2021-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | It's not used. Drivers should instead use the helpers anyway. Currently both vbox and i915 hand-roll this and it's not the greatest. vbox looks buggy, and i915 does a bit much that helpers would take care of I think. Also improve the kerneldocs while we're at it. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-1-daniel.vetter@ffwll.ch
* drm/prime: fix comment on PRIME HelpersJose Maria Casanova Crespo2021-07-271-1/+1
| | | | | | | | | | s/Exporting/Importing Fixes: 805dc614d58a8 ("drm/prime: Update docs") Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210723123307.31064-1-jmcasanova@igalia.com
* drm/bridge: dw-mipi-dsi: Find the possible DSI devicesJagan Teki2021-07-271-15/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Finding panel_or_bridge might vary based on associated DSI devices like DSI panel, bridge, and I2C based DSI bridge. 1. DSI panels and bridges will invoke the host attach from probe in order to find the panel_or_bridge. chipone_probe() dw_mipi_dsi_host_attach().start dw_mipi_dsi_panel_or_bridge() ...found the panel_or_bridge... ltdc_encoder_init().start dw_mipi_dsi_bridge_attach().start dw_mipi_dsi_host_attach().start chipone_attach(). start chipone_attach(). done dw_mipi_dsi_host_attach().done dw_mipi_dsi_bridge_attach(). done ltdc_encoder_init().done 2. I2C based DSI bridge will invoke the drm_bridge_attach from bridge attach in order to find the panel_or_bridge. ltdc_encoder_init().start dw_mipi_dsi_bridge_attach().start dw_mipi_dsi_panel_or_bridge() ...found the panel_or_bridge... dw_mipi_dsi_host_attach().start sn65dsi83_attach(). start sn65dsi83_attach(). done dw_mipi_dsi_host_attach().done dw_mipi_dsi_bridge_attach(). done ltdc_encoder_init().done So, invoke the panel_or_bridge from host attach and bridge attach in order to find all possible DSI devices. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Yannick Fertre <yannick.fertre@foss.st.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210704140309.268469-1-jagan@amarulasolutions.com
* drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling featuresNicolas Boichat2021-07-2721-30/+30
| | | | | | | | | | | | | | | | | Many of the DSI flags have names opposite to their actual effects, e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually be disabled. Fix this by including _NO_ in the flag names, e.g. MIPI_DSI_MODE_NO_EOT_PACKET. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@samsung.com> Reviewed-by: Xin Ji <xji@analogixsemi.com> # anx7625.c Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> # msm/dsi Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210727094435.v3.1.I629b2366a6591410359c7fcf6d385b474b705ca2@changeid
* video: ep93xx: Prepare clock before using itAlexander Sverdlin2021-07-261-2/+2
| | | | | | | | | | Use clk_prepare_enable()/clk_disable_unprepare() in preparation for switch to Common Clock Framework. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210726140001.24820-5-nikita.shubin@maquefel.me
* drm/panel: simple: Add support for two more AUO panelsBjorn Andersson2021-07-261-0/+66
| | | | | | | | | Add definition of the AUO B133HAN05.4 13.3" FHD panel and the B140HAN06.4 14.0" FHD panel. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210726173300.432039-2-bjorn.andersson@linaro.org
* video: fbdev: riva: Error out if 'pixclock' equals zeroZheyu Ma2021-07-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 33.396850] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #222 [ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70 [ 33.396969] Call Trace: [ 33.396973] ? debug_smp_processor_id+0x1c/0x20 [ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90 [ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0 [ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0 [ 33.397014] ? vprintk_emit+0x110/0x4b0 [ 33.397024] ? vprintk_default+0x26/0x30 [ 33.397033] ? vprintk+0x9c/0x1f0 [ 33.397041] ? printk+0xba/0xed [ 33.397054] ? record_print_text.cold+0x16/0x16 [ 33.397063] ? __kasan_check_read+0x11/0x20 [ 33.397074] ? profile_tick+0xc0/0x100 [ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80 [ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397102] rivafb_set_par+0xbe/0x610 [ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397119] fb_set_var+0x5bf/0xeb0 [ 33.397127] ? fb_blank+0x1a0/0x1a0 [ 33.397134] ? lock_acquire+0x1ef/0x530 [ 33.397143] ? lock_release+0x810/0x810 [ 33.397151] ? lock_is_held_type+0x100/0x140 [ 33.397159] ? ___might_sleep+0x1ee/0x2d0 [ 33.397170] ? __mutex_lock+0x620/0x1190 [ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0 [ 33.397190] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-4-git-send-email-zheyuma97@gmail.com
* video: fbdev: kyro: Error out if 'pixclock' equals zeroZheyu Ma2021-07-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty #118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-3-git-send-email-zheyuma97@gmail.com
* video: fbdev: asiliantfb: Error out if 'pixclock' equals zeroZheyu Ma2021-07-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 43.861711] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #224 [ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730 [ 43.861843] Call Trace: [ 43.861848] ? asiliantfb_remove+0x190/0x190 [ 43.861858] fb_set_var+0x2e4/0xeb0 [ 43.861866] ? fb_blank+0x1a0/0x1a0 [ 43.861873] ? lock_acquire+0x1ef/0x530 [ 43.861884] ? lock_release+0x810/0x810 [ 43.861892] ? lock_is_held_type+0x100/0x140 [ 43.861903] ? ___might_sleep+0x1ee/0x2d0 [ 43.861914] ? __mutex_lock+0x620/0x1190 [ 43.861921] ? do_fb_ioctl+0x313/0x700 [ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0 [ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30 [ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861952] ? lockdep_hardirqs_on+0x59/0x100 [ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0 [ 43.861978] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-2-git-send-email-zheyuma97@gmail.com
* drm/rockchip: dsi: add ability to work as a phy instead of full dsiHeiko Stuebner2021-07-252-0/+343
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SoCs like the rk3288 and rk3399 have 3 mipi dphys on them. One is TX- only, one is RX-only and one can be configured to do either TX or RX. The RX phy is statically connected to the first Image Signal Processor, the TX phy is statically connected to the first DSI controller and the TXRX phy is connected to both the second DSI controller as well as the second ISP. The RX dphy is controlled externally through registers in the "General Register Files", while the other two are controlled through the "Configuration and Test Interface" inside their DSI controller's io-memory area. The Rockchip dw-dsi controller already controls these dphys for the TX case in the driver, but when we want to also allow configuration for RX to the ISP from the media subsystem we need to expose phy- functionality instead. So add a bit of infrastructure to allow the dsi driver to work as a phy and make sure it can be only one or the other at a time. Similarly as the dsi-controller will be part of the drm-graph when active, add an empty component to the drm-graph when in phy-mode to make the rest of the drm-graph not wait for it. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Tested-by: Sebastian Fricke <sebastian.fricke@posteo.net> Acked-by: Helen Koike <helen.koike@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210210111020.2476369-4-heiko@sntech.de
* drm/rockchip: dsi: add own additional pclk handlingHeiko Stuebner2021-07-251-0/+8
| | | | | | | | | | | | | In a followup patch, we'll need to access the pclk ourself to enable some functionality, so get and store it in the rockchip dw-dsi variant as well. Clocks are refcounted, so possible cascading enablements are no problem. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Tested-by: Sebastian Fricke <sebastian.fricke@posteo.net> Acked-by: Helen Koike <helen.koike@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210210111020.2476369-2-heiko@sntech.de
* drm/bridge: nwl-dsi: Avoid potential multiplication overflow on 32-bitGeert Uytterhoeven2021-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | As nwl_dsi.lanes is u32, and NSEC_PER_SEC is 1000000000L, the second multiplication in dsi->lanes * 8 * NSEC_PER_SEC will overflow on a 32-bit platform. Fix this by making the constant unsigned long long, forcing 64-bit arithmetic. As iMX8 is arm64, this driver is currently used on 64-bit platforms only, where long is 64-bit, so this cannot happen. But the issue will start to happen when the driver is reused for a 32-bit SoC (e.g. i.MX7ULP), or when code is copied for a new driver. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/ebb82941a86b4e35c4fcfb1ef5a5cfad7c1fceab.1626255956.git.geert+renesas@glider.be
* drm/shmobile: Convert to Linux IRQ interfacesThomas Zimmermann2021-07-252-5/+10
| | | | | | | | | | | | | | | | | Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. v3: * return error if (ret < 0) (Geert) * remove duplicate error message (Geert) v2: * handle errors in platform_get_irq() (Geert, Sergei) * store IRQ number in struct shmob_drm_device (Laurent) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210720080941.23646-1-tzimmermann@suse.de
* drm/st7586: Use framebuffer dma-buf helpersThomas Zimmermann2021-07-231-12/+6
| | | | | | | | | | | | Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access(); same for _end_cpu_access(). Remove some boiler-plate code. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210716140801.1215-8-tzimmermann@suse.de
* drm/repaper: Use framebuffer dma-buf helpersThomas Zimmermann2021-07-231-14/+4
| | | | | | | | | | | Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access(); same for _end_cpu_access(). Remove some boiler-plate code. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210716140801.1215-7-tzimmermann@suse.de
* drm/gm12u320: Use framebuffer dma-buf helpersThomas Zimmermann2021-07-231-14/+5
| | | | | | | | | | | Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access(); same for _end_cpu_access(). Remove some boiler-plate code. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210716140801.1215-6-tzimmermann@suse.de
* drm/gud: Use framebuffer dma-buf helpersThomas Zimmermann2021-07-231-8/+5
| | | | | | | | | | | Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access(); same for _end_cpu_access(). Remove some boiler-plate code. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210716140801.1215-5-tzimmermann@suse.de
* drm/mipi-dbi: Use framebuffer dma-buf helpersThomas Zimmermann2021-07-231-13/+7
| | | | | | | | | | | | | | | Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access(); same for _end_cpu_access(). Remove some boiler-plate code. No functional changes. There's one left-over reference to the imported attachment that we keep. GEM BOs with imported attachment are considered uncached and enables special handling within the drm_fb_swab(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210716140801.1215-4-tzimmermann@suse.de
* drm/udl: Use framebuffer dma-buf helpersThomas Zimmermann2021-07-231-21/+8
| | | | | | | | | | | Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access(); same for _end_cpu_access(). Remove some boiler-plate code. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210716140801.1215-3-tzimmermann@suse.de
* drm/gem: Provide drm_gem_fb_{begin,end}_cpu_access() helpersThomas Zimmermann2021-07-231-0/+89
| | | | | | | | | | | | | | | | | | | Implement helpers drm_gem_fb_begin_cpu_access() and _end_cpu_access(), which call the rsp dma-buf functions for all GEM BOs of the given framebuffer. Calls to dma_buf_end_cpu_access() can return an error code on failure, while drm_gem_fb_end_cpu_access() does not. The latter runs during DRM's atomic commit or during cleanup. Both cases don't allow for errors, so leave out the return value. v2: * fix typo in docs (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210716140801.1215-2-tzimmermann@suse.de
* drm/hisilicon/hibmc: Remove variable 'priv' from hibmc_unload()Thomas Zimmermann2021-07-231-1/+0
| | | | | | | | | | | | | | | | | | The variable 'priv' got introduced in commit 39a364a19e03 ("drm/hisilicon/hibmc: Convert to Linux IRQ interfaces") by accident. It's unused; remove it. Fixes a compiler warning. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 39a364a19e03 ("drm/hisilicon/hibmc: Convert to Linux IRQ interfaces") Reviewed-by: Tian Tao <tiantao6@hisilicon.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Dave Airlie <airlied@gmail.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Tian Tao <tiantao6@hisilicon.com> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210721131704.10306-1-tzimmermann@suse.de
* drm/panfrost: devfreq: Don't display error for EPROBE_DEFERChris Morgan2021-07-231-1/+2
| | | | | | | | | | | | Set a condition for the message of "Couldn't set OPP regulators" to not display if the error code is EPROBE_DEFER. Note that I used an if statement to capture the condition instead of the dev_err_probe function because I didn't want to change the DRM_DEV_ERROR usage. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721214830.25690-1-macroalpha82@gmail.com
* video: fbdev: neofb: add a check against divide errorZheyu Ma2021-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error because of the 'PICOS2KHZ' macro. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 53.093806] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 53.093838] CPU: 3 PID: 11763 Comm: hang Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0 #215 [ 53.093859] RIP: 0010:neofb_check_var+0x80/0xe50 [ 53.093951] Call Trace: [ 53.093956] ? neofb_setcolreg+0x2b0/0x2b0 [ 53.093968] fb_set_var+0x2e4/0xeb0 [ 53.093977] ? fb_blank+0x1a0/0x1a0 [ 53.093984] ? lock_acquire+0x1ef/0x530 [ 53.093996] ? lock_release+0x810/0x810 [ 53.094005] ? lock_is_held_type+0x100/0x140 [ 53.094016] ? ___might_sleep+0x1ee/0x2d0 [ 53.094028] ? __mutex_lock+0x620/0x1190 [ 53.094036] ? do_fb_ioctl+0x313/0x700 [ 53.094044] ? mutex_lock_io_nested+0xfa0/0xfa0 [ 53.094051] ? __this_cpu_preempt_check+0x1d/0x30 [ 53.094060] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 53.094069] ? lockdep_hardirqs_on+0x59/0x100 [ 53.094076] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 53.094085] ? trace_hardirqs_on+0x6a/0x1c0 [ 53.094096] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1626871424-27708-1-git-send-email-zheyuma97@gmail.com
* video: fbdev: arcfb: remove redundant initialization of variable errColin Ian King2021-07-211-1/+1
| | | | | | | | | | The variable err is being initialized with a value that is never read, the assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210721102608.42694-1-colin.king@canonical.com
* drivers/firmware: consolidate EFI framebuffer setup for all archesJavier Martinez Canillas2021-07-217-119/+127
| | | | | | | | | | | | | | | | | | | | | | | | | The register_gop_device() function registers an "efi-framebuffer" platform device to match against the efifb driver, to have an early framebuffer for EFI platforms. But there is already support to do exactly the same by the Generic System Framebuffers (sysfb) driver. This used to be only for X86 but it has been moved to drivers/firmware and could be reused by other architectures. Also, besides supporting registering an "efi-framebuffer", this driver can register a "simple-framebuffer" allowing to use the siple{fb,drm} drivers on non-X86 EFI platforms. For example, on aarch64 these drivers can only be used with DT and doesn't have code to register a "simple-frambuffer" platform device when booting with EFI. For these reasons, let's remove the register_gop_device() duplicated code and instead move the platform specific logic that's there to sysfb driver. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com
* drivers/firmware: move x86 Generic System Framebuffers supportJavier Martinez Canillas2021-07-216-0/+501
| | | | | | | | | | | | | | | | | | | The x86 architecture has generic support to register a system framebuffer platform device. It either registers a "simple-framebuffer" if the config option CONFIG_X86_SYSFB is enabled, or a legacy VGA/VBE/EFI FB device. But the code is generic enough to be reused by other architectures and can be moved out of the arch/x86 directory. This will allow to also support the simple{fb,drm} drivers on non-x86 EFI platforms, such as aarch64 where these drivers are only supported with DT. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210625130947.1803678-2-javierm@redhat.com
* vgaarb: don't pass a cookie to vga_client_registerChristoph Hellwig2021-07-216-33/+31
| | | | | | | | | | The VGA arbitration is entirely based on pci_dev structures, so just pass that back to the set_vga_decode callback. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-8-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* vgaarb: remove the unused irq_set_state argument to vga_client_registerChristoph Hellwig2021-07-216-27/+6
| | | | | | | | | | All callers pass NULL as the irq_set_state argument, so remove it and the ->irq_set_state member in struct vga_device. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-7-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* vgaarb: provide a vga_client_unregister wrapperChristoph Hellwig2021-07-217-9/+8
| | | | | | | | | | Add a trivial wrapper for the unregister case that sets all fields to NULL. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-6-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* vgaarb: move the kerneldoc for vga_set_legacy_decoding to vgaarb.cChristoph Hellwig2021-07-211-0/+11
| | | | | | | | | | Kerneldoc comments should be at the implementation side, not in the header just declaring the prototype. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-4-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* vgaarb: remove vga_conflictsChristoph Hellwig2021-07-211-6/+0
| | | | | | | | | | | vga_conflicts only has a single caller and none of the arch overrides mentioned in the comment. Just remove it and the thus dead check in the caller. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-3-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* drm/v3d: Expose performance counters to userspaceJuan A. Suarez Romero2021-07-217-0/+334
| | | | | | | | | | | | | | | | | | | | | | | | | | | The V3D engine has several hardware performance counters that can of interest for userspace performance analysis tools. This exposes new ioctls to create and destroy performance monitor objects, as well as to query the counter values. Each created performance monitor object has an ID that can be attached to CL/CSD submissions, so the driver enables the requested counters when the job is submitted, and updates the performance monitor values when the job is done. It is up to the user to ensure all the jobs have been finished before getting the performance monitor values. It is also up to the user to properly synchronize BCL jobs when submitting jobs with different performance monitors attached. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Emma Anholt <emma@anholt.net> To: dri-devel@lists.freedesktop.org Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com> Acked-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210608111541.461991-1-jasuarez@igalia.com
* drm: protect drm_master pointers in drm_lease.cDesmond Cheong Zhi Xi2021-07-202-20/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_file->master pointers should be protected by drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, in drm_lease.c, there are multiple instances where drm_file->master is accessed and dereferenced while neither lock is held. This makes drm_lease.c vulnerable to use-after-free bugs. We address this issue in 2 ways: 1. Add a new drm_file_get_master() function that calls drm_master_get on drm_file->master while holding on to drm_file.master_lookup_lock. Since drm_master_get increments the reference count of master, this prevents master from being freed until we unreference it with drm_master_put. 2. In each case where drm_file->master is directly accessed and eventually dereferenced in drm_lease.c, we wrap the access in a call to the new drm_file_get_master function, then unreference the master pointer once we are done using it. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-6-desmondcheongzx@gmail.com
* drm: serialize drm_file.master with a new spinlockDesmond Cheong Zhi Xi2021-07-202-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, drm_file.master pointers should be protected by drm_device.master_mutex when being dereferenced. This is because drm_file.master is not invariant for the lifetime of drm_file. If drm_file is not the creator of master, then drm_file.is_master is false, and a call to drm_setmaster_ioctl will invoke drm_new_set_master, which then allocates a new master for drm_file and puts the old master. Thus, without holding drm_device.master_mutex, the old value of drm_file.master could be freed while it is being used by another concurrent process. However, it is not always possible to lock drm_device.master_mutex to dereference drm_file.master. Through the fbdev emulation code, this might occur in a deep nest of other locks. But drm_device.master_mutex is also the outermost lock in the nesting hierarchy, so this leads to potential deadlocks. To address this, we introduce a new spin lock at the bottom of the lock hierarchy that only serializes drm_file.master. With this change, the value of drm_file.master changes only when both drm_device.master_mutex and drm_file.master_lookup_lock are held. Hence, any process holding either of those locks can ensure that the value of drm_file.master will not change concurrently. Since no lock depends on the new drm_file.master_lookup_lock, when drm_file.master is dereferenced, but drm_device.master_mutex cannot be held, we can safely protect the master pointer with drm_file.master_lookup_lock. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-5-desmondcheongzx@gmail.com
* drm: add a locked version of drm_is_current_masterDesmond Cheong Zhi Xi2021-07-201-19/+32
| | | | | | | | | | | | | | | | | | | | | While checking the master status of the DRM file in drm_is_current_master(), the device's master mutex should be held. Without the mutex, the pointer fpriv->master may be freed concurrently by another process calling drm_setmaster_ioctl(). This could lead to use-after-free errors when the pointer is subsequently dereferenced in drm_lease_owner(). The callers of drm_is_current_master() from drm_auth.c hold the device's master mutex, but external callers do not. Hence, we implement drm_is_current_master_locked() to be used within drm_auth.c, and modify drm_is_current_master() to grab the device's master mutex before checking the master status. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-4-desmondcheongzx@gmail.com
* drm: avoid blocking in drm_clients_info's rcu sectionDesmond Cheong Zhi Xi2021-07-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inside drm_clients_info, the rcu_read_lock is held to lock pid_task()->comm. However, within this protected section, a call to drm_is_current_master is made, which involves a mutex lock in a future patch. However, this is illegal because the mutex lock might block while in the RCU read-side critical section. Since drm_is_current_master isn't protected by rcu_read_lock, we avoid this by moving it out of the RCU critical section. The following report came from intel-gfx ci's igt@debugfs_test@read_all_entries testcase: ============================= [ BUG: Invalid wait context ] 5.13.0-CI-Patchwork_20515+ #1 Tainted: G W ----------------------------- debugfs_test/1101 is trying to lock: ffff888132d901a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1e/0x50 other info that might help us debug this: context-{4:4} 3 locks held by debugfs_test/1101: #0: ffff88810fdffc90 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0x53/0x3b0 #1: ffff888132d90240 (&dev->filelist_mutex){+.+.}-{3:3}, at: drm_clients_info+0x63/0x2a0 #2: ffffffff82734220 (rcu_read_lock){....}-{1:2}, at: drm_clients_info+0x1b1/0x2a0 stack backtrace: CPU: 8 PID: 1101 Comm: debugfs_test Tainted: G W 5.13.0-CI-Patchwork_20515+ #1 Hardware name: Intel Corporation CometLake Client Platform/CometLake S UDIMM (ERB/CRB), BIOS CMLSFWR1.R00.1263.D00.1906260926 06/26/2019 Call Trace: dump_stack+0x7f/0xad __lock_acquire.cold.78+0x2af/0x2ca lock_acquire+0xd3/0x300 ? drm_is_current_master+0x1e/0x50 ? __mutex_lock+0x76/0x970 ? lockdep_hardirqs_on+0xbf/0x130 __mutex_lock+0xab/0x970 ? drm_is_current_master+0x1e/0x50 ? drm_is_current_master+0x1e/0x50 ? drm_is_current_master+0x1e/0x50 drm_is_current_master+0x1e/0x50 drm_clients_info+0x107/0x2a0 seq_read_iter+0x178/0x3b0 seq_read+0x104/0x150 full_proxy_read+0x4e/0x80 vfs_read+0xa5/0x1b0 ksys_read+0x5a/0xd0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-3-desmondcheongzx@gmail.com
* drm: avoid circular locks in drm_mode_getconnectorDesmond Cheong Zhi Xi2021-07-201-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for a future patch to take a lock on drm_device.master_mutex inside drm_is_current_master(), we first move the call to drm_is_current_master() in drm_mode_getconnector out from the section locked by &dev->mode_config.mutex. This avoids creating a circular lock dependency. Failing to avoid this lock dependency produces the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted ------------------------------------------------------ kms_frontbuffer/1087 is trying to acquire lock: ffff88810dcd01a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1b/0x40 but task is already holding lock: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dev->mode_config.mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_probe+0x22e/0xca0 __drm_fb_helper_initial_config_and_unlock+0x42/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #1 (&client->modeset_mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_commit_locked+0x1c/0x180 drm_client_modeset_commit+0x1c/0x40 __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0 drm_fb_helper_set_par+0x34/0x40 intel_fbdev_set_par+0x11/0x40 [i915] fbcon_init+0x270/0x4f0 visual_init+0xc6/0x130 do_bind_con_driver+0x1e5/0x2d0 do_take_over_console+0x10e/0x180 do_fbcon_takeover+0x53/0xb0 register_framebuffer+0x22d/0x310 __drm_fb_helper_initial_config_and_unlock+0x36c/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #0 (&dev->master_mutex){+.+.}-{3:3}: __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &dev->master_mutex --> &client->modeset_mutex --> &dev->mode_config.mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->mode_config.mutex); lock(&client->modeset_mutex); lock(&dev->mode_config.mutex); lock(&dev->master_mutex); *** DEADLOCK *** 1 lock held by kms_frontbuffer/1087: #0: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 stack backtrace: CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 5.13.0-rc7-CI-CI_DRM_10254+ #1 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 Call Trace: dump_stack+0x7f/0xad check_noncircular+0x12e/0x150 __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-2-desmondcheongzx@gmail.com
* dma_buf: remove dmabuf sysfs teardown before releaseGuangming Cao2021-07-201-1/+1
| | | | | | | | | | | Dmabuf sysfs stat is used for dmabuf info track. But these file maybe still in use after buffer released, should clear it before buffer release. Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210720103158.83439-1-guangming.cao@mediatek.com Signed-off-by: Christian König <christian.koenig@amd.com>
* drm/bochs: Fix missing pci_disable_device() on error in bochs_pci_probe()Yang Yingliang2021-07-201-1/+1
| | | | | | | | | | | | | | | | | Replace pci_enable_device() with pcim_enable_device(), pci_disable_device() will be called in release automatically. v3: reformat commit message update for move to tiny/ v2: use pcim_enable_device() Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reported-by: Hulk Robot <hulkci@huawei.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210715132845.2415619-1-yangyingliang@huawei.com
* drm/ast: Disable fast reset after DRAM initialKuoHsiang Chou2021-07-203-26/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Bug][AST2500] V1: When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization have to be achieved by VGA driver with P2A (PCI to AHB) enabling. However, HW suggests disable Fast reset mode after DRAM initializaton, because fast reset mode is mainly designed for ARM ICE debugger. Once Fast reset is checked as enabling, WDT (Watch Dog Timer) should be first enabled to avoid system deadlock before disable fast reset mode. V2: Use to_pci_dev() to get revision of PCI configuration. V3: If SCU00 is not unlocked, just enter its password again. It is unnecessary to clear AHB lock condition and restore WDT default setting again, before Fast-reset clearing. V4: repatch after "error : could not build fake ancestor" resolved. V5: Since CVE_2019_6260 item3, Most of AST2500 have disabled P2A(PCIe to AMBA). However, for backward compatibility, some patches about P2A, such as items of v5.2 and v5.3, are considered to be upstreamed with comments. 1. Add define macro to improve source readability. ast_drv.h, ast_main.c, ast_post.c 2. Add comment about "Fast restet" is enabled for ARM-ICE debugger ast_post.c 3. Add comment about Reset USB port to patch USB unknown device issue ast_post.c Signed-off-by: KuoHsiang Chou <kuohsiang_chou@aspeedtech.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210709080900.4056-1-kuohsiang_chou@aspeedtech.com
* drm/ast: Zero is missing in detect functionAinux.Wang2021-07-201-1/+1
| | | | | | | | | The function ast_get_modes() will also return 0, when it try to get the edid, but it also do not get the edid. Signed-off-by: Ainux.Wang <ainux.wang@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716015615.9150-1-ainux.wang@gmail.com
* dma-buf: Delete the DMA-BUF attachment sysfs statisticsHridya Valsaraju2021-07-203-179/+4
| | | | | | | | | | | | | | | | | | The DMA-BUF attachment statistics form a subset of the DMA-BUF sysfs statistics that recently merged to the drm-misc tree. They are not UABI yet since they have not merged to the upstream Linux kernel. Since there has been a reported a performance regression due to the overhead of sysfs directory creation/teardown during dma_buf_attach()/dma_buf_detach(), this patch deletes the DMA-BUF attachment statistics from sysfs. Fixes: bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") Signed-off-by: Hridya Valsaraju <hridya@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210713040742.2680135-1-hridya@google.com Signed-off-by: Christian König <christian.koenig@amd.com>
* drm/ingenic: Convert to Linux IRQ interfacesThomas Zimmermann2021-07-191-4/+1
| | | | | | | | | | | | | | | | | | Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. This patch also fixes a bug where the driver didn't release the IRQ. v2: * automatically release IRQ via devm_request_irq() (Paul) * mention the bugfix (Sam) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210715100258.6638-1-tzimmermann@suse.de
* fbmem: Convert from atomic_t to refcount_t on fb_info->countXiyu Yang2021-07-191-3/+3
| | | | | | | | | | refcount_t type and corresponding API can protect refcounters from accidental underflow and overflow and further use-after-free situations. Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1626674392-55857-1-git-send-email-xiyuyang19@fudan.edu.cn
* video: fbdev: kyro: fix a DoS bug by restricting user inputZheyu Ma2021-07-191-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | The user can pass in any value to the driver through the 'ioctl' interface. The driver dost not check, which may cause DoS bugs. The following log reveals it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:SetOverlayViewPort+0x133/0x5f0 drivers/video/fbdev/kyro/STG4000OverlayDevice.c:476 Call Trace: kyro_dev_overlay_viewport_set drivers/video/fbdev/kyro/fbdev.c:378 [inline] kyrofb_ioctl+0x2eb/0x330 drivers/video/fbdev/kyro/fbdev.c:603 do_fb_ioctl+0x1f3/0x700 drivers/video/fbdev/core/fbmem.c:1171 fb_ioctl+0xeb/0x130 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19b/0x220 fs/ioctl.c:739 do_syscall_64+0x32/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1626235762-2590-1-git-send-email-zheyuma97@gmail.com
* drm/stm: dsi: compute the transition time from LP to HS and backAntonio Borneo2021-07-191-4/+13
| | | | | | | | | | | | | | | The driver uses a conservative set of hardcoded values for the maximum time delay of the transitions between LP and HS, either for data and clock lanes. By using the info in STM32MP157 datasheet, valid also for other ST devices, compute the actual delay from the lane's bps. Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Reviewed-by: Philippe Cornu <philippe.cornu@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713144941.3599-1-antonio.borneo@foss.st.com
* drm/stm: ltdc: Silence -EPROBE_DEFER till bridge attachedJagan Teki2021-07-191-3/+5
| | | | | | | | | | | | | | | | | | | | | | As dw-mipi-dsi supported all possible ways to find the DSI devices. It can take multiple iterations for ltdc to find all components attached to the DSI bridge. The current ltdc driver failed to find the endpoint as it returned -EINVAL for the first iteration itself. This leads to following error: [    3.099289] [drm:ltdc_load] *ERROR* init encoder endpoint 0 So, check the return value and cleanup the encoder only if it's not -EPROBE_DEFER. This make all components in the attached DSI bridge found properly. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Yannick Fertre <yannick.fertre@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210704135914.268308-1-jagan@amarulasolutions.com
* drm/panel: ws2401: Add driver for WideChips WS2401Linus Walleij2021-07-173-0/+452
| | | | | | | | | | | | | | | | | | | | | | | This adds a driver for panels based on the WideChips WS2401 display controller. This display controller is used in the Samsung LMS380KF01 display found in the Samsung GT-I8160 (Codina) mobile phone and possibly others. As is common with Samsung displays manufacturer commands are necessary to configure the display to a working state. The display optionally supports internal backlight control, but can also use an external backlight. This driver re-uses the DBI infrastructure to communicate with the display. Cc: phone-devel@vger.kernel.org Cc: Douglas Anderson <dianders@chromium.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210714225002.1065107-2-linus.walleij@linaro.org
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 08:38:52 +0100