summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-07-30Merge tag 'drm-misc-next-2021-07-29' of ↵Dave Airlie84-680/+1797
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.15: UAPI Changes: - Add modifiers for arm fixed rate compression. Cross-subsystem Changes: - Assorted dt binding fixes. - Convert ssd1307fb to json-schema. - Update a lot of irc channels to point to OFTC, as everyone moved there. - Fix the same divide by zero for asilantfb, kyro, rivafb. Core Changes: - Document requirements for new atomic properties. - Add drm_gem_fb_(begin/end)_cpu_access helpers, and use them in some drivers. - Document drm_property_enum.value for bitfields. - Add explicit _NO_ for MIPI_DSI flags that disable features. - Assorted documentation fixes. - Update fb_damage handling, and move drm_plane_enable_fb_damage_clips to core. - Add logging and docs to RMFB ioctl. - Assorted small fixes to dp_mst, master handling. - Clarify drm lease usage. Driver Changes: - Assorted small fixes to panfrost, hibmc, bridge/nwl-dsi, rockchip, vc4. - More drm -> linux irq conversions. - Add support for some Logic Technologies and Multi-Inno panels. - Expose phy-functionality for drm/rockchip, to allow controlling from the media subsystem. - Add support for 2 AUO panels. - Add damage handling to ssd1307fb. - Improve FIFO handling on mxsfb. - Assorted small fixes to vmwgfx, and bump version to 2.19 for the new ioctls. - Improve sony acx424akp backlight handling. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a753221a-e23e-0dc4-7ca6-8c1b179738d0@linux.intel.com
2021-07-30Merge tag 'du-next-20210728' of git://linuxtv.org/pinchartl/media into drm-nextDave Airlie32-224/+134
- R-Car DU shutdown fixes - R-Car DU conversion to bridge connector helper - Misc small fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/YQGHjOSOw2G4+A3x@pendragon.ideasonboard.com
2021-07-29drm/vc4: hdmi: Remove unused structMaxime Ripard1-12/+0
Commit 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") removed the references to the vc4_hdmi_audio_component_drv structure, but not the structure itself resulting in a warning. Remove it. Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707093632.1468127-2-maxime@cerno.tech
2021-07-29drm/vc4: hdmi: Remove redundant variablesMaxime Ripard2-16/+12
The vc4_hdmi_audio_prepare function and the functions it's calling have in several occurences multiple dereferences of either the sample rate or the number of channels. It turns out that these variables are also passed through the hdmi codec parameters structure. Convert all the users to use this structure, and if it's used multiple times use a variable to store it instead of dereferencing it every time. Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210707093632.1468127-1-maxime@cerno.tech
2021-07-29drm: clarify usage of drm leasesDesmond Cheong Zhi Xi3-11/+116
We make the following changes to the documentation of drm leases to make it easier to reason about their usage. In particular, we clarify the lifetime and locking rules of lease fields in drm_master: 1. Make it clear that &drm_device.mode_config.idr_mutex protects the lease idr and list structures for drm_master. The lessor field itself doesn't need to be protected as it doesn't change after it's set in drm_lease_create. 2. Add descriptions for the lifetime of lessors and leases. 3. Add an overview DOC: section in drm-uapi.rst that defines the terminology for drm leasing, and explains how leases work and why they're used. Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210728102739.441543-1-desmondcheongzx@gmail.com
2021-07-29drm/panel-sony-acx424akp: Modernize backlight handlingLinus Walleij1-56/+26
This converts the internal backlight in the Sony ACX424AKP driver to do it the canonical way: - Assign the panel->backlight during probe. - Let the panel framework handle the backlight. - Make the backlight .set_brightness() turn the backlight off completely if blank. - Fix some dev_err_probe() use cases along the way. Tested on the U8500 HREF520 reference design. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210715092808.1100106-1-linus.walleij@linaro.org
2021-07-29drm: use the lookup lock in drm_is_current_masterDesmond Cheong Zhi Xi1-4/+5
Inside drm_is_current_master, using the outer drm_device.master_mutex to protect reads of drm_file.master makes the function prone to creating lock hierarchy inversions. Instead, we can use the drm_file.master_lookup_lock that sits at the bottom of the lock hierarchy. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210724111824.59266-2-desmondcheongzx@gmail.com
2021-07-28drm/vmwgfx: Use 2.19 version number to recognize mks-stats ioctlsZack Rusin1-3/+3
To let the userspace recognize that it's running on top of a vmwgfx that supports mks-stat ioctls we need to bump the version number. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Neha Bhende <bhenden@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723165153.113198-4-zackr@vmware.com
2021-07-28drm/vmwgfx: Be a lot more flexible with MOB limitsZack Rusin2-2/+43
The code was trying to keep a strict limit on the amount of mob memory that was used in the guest by making it match the host settings. There's technically no reason to do that (guests can certainly use more than the host can have resident in renderers at the same time). In particular this is problematic because our userspace is not great at handling OOM conditions and running out of MOB space results in GL apps crashing, e.g. gnome-shell likes to allocate huge surfaces (~61MB for the desktop on 2560x1600 with two workspaces) and running out of memory there means that the gnome-shell crashes on startup taking us back to the login and resulting in a system where one can not login in graphically anymore. Instead of letting the userspace crash we can extend available MOB space, we just don't want to use all of the RAM for graphics, so we're going to limit it to half of RAM. With the addition of some extra logging this should make the "guest has been configured with not enough graphics memory" errors a lot easier to diagnose in cases where the automatic expansion of MOB space fails. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723165153.113198-3-zackr@vmware.com
2021-07-28drm/vmwgfx: Cleanup loggingZack Rusin8-106/+151
The code was using the old DRM logging functions, which made it hard to figure out what was coming from vmwgfx. The newer logging helpers include the driver name in the logs and make it explicit which driver they're coming from. This allows us to standardize our logging a bit and clean it up in the process. vmwgfx is a little special because technically the hardware it's running on can be anything from the last 12 years or so which is why we need to include capabilities in the logs in the first place or otherwise we'd have no way of knowing what were the capabilities of the platform the guest was running in. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723165153.113198-2-zackr@vmware.com
2021-07-28drm/vmwgfx: Switch to using DRM_IOCTL_DEF_DRVZack Rusin1-92/+84
The macro has been accounting for DRM_COMMAND_BASE for a long time now so there's no reason to still be duplicating it. Plus we were leaving the name undefined which meant that all the DRM ioctl warnings/errors were always listing "null" ioctl at the culprit. This fixes the undefined ioctl name and removes duplicated code. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723165153.113198-1-zackr@vmware.com
2021-07-28drm: rcar-du: lvds: Use dev_err_probe()Laurent Pinchart1-3/+2
Simplify error handling by using the dev_err_probe() function. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm: rcar-du: lvds: Don't set bridge driver_private fieldLaurent Pinchart1-1/+0
The drm_bridge.driver_private field is set but never used. Don't set it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm: rcar-du: Use drm_bridge_connector_init() helperLaurent Pinchart1-5/+21
Use the drm_bridge_connector_init() helper to create a drm_connector for each output, instead of relying on the bridge drivers doing so. Attach the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct them not to create a connector. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # On V3U Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm: rcar-du: dw-hdmi: Set output port numberLaurent Pinchart1-0/+1
Report the DT output port number in dw_hdmi_plat_data to connect to the next bridge in the dw-hdmi driver. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # On V3U Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm: rcar-du: lvds: Convert to DRM panel bridge helperLaurent Pinchart1-108/+12
Replace the manual panel handling with usage of the DRM panel bridge helper. This simplifies the driver, and brings support for DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # On V3U Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm: bridge: dw-hdmi: Attach to next bridge if availableLaurent Pinchart2-1/+55
On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings require a video output port connected to an HDMI sink (most likely an HDMI connector, in rare cases another bridges converting HDMI to another protocol). For those platforms, retrieve the next bridge and attach it from the dw-hdmi bridge attach handler. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # On V3U Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm/bridge: Centralize error message when bridge attach failsLaurent Pinchart26-103/+33
Being informed of a failure to attach a bridge is useful, and many drivers prints an error message in that case. Move the message to drm_bridge_attach() to avoid code duplication. Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi>
2021-07-28drm: rcar-du: Shutdown the display on removeLaurent Pinchart1-0/+1
When the device is unbound from the driver (the DU being a platform device, this occurs either when removing the DU module, or when unbinding the device manually through sysfs), the display may be active. Make sure it gets shut down. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm: rcar-du: Don't put reference to drm_device in rcar_du_remove()Laurent Pinchart1-2/+0
The reference to the drm_device that was acquired by devm_drm_dev_alloc() is released automatically by the devres infrastructure. It must not be released manually, as that causes a reference underflow.. Fixes: ea6aae151887 ("drm: rcar-du: Embed drm_device in rcar_du_device") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm: rcar-du: Shutdown the display on system shutdownLaurent Pinchart1-0/+8
When the system shuts down or warm reboots, the display may be active, with the hardware accessing system memory. Upon reboot, the DDR will not be accessible, which may cause issues. Implement the platform_driver .shutdown() operation and shut down the display to fix this. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2021-07-28drm/bridge: make a const array static, makes object smallerColin Ian King1-1/+1
Don't populate the const array frs_limits on the stack but instead make it static. Makes the object code smaller by 128 bytes: Before: text data bss dec hex filename 24845 7440 64 32349 7e5d ./drivers/gpu/drm/bridge/tc358768.o After: text data bss dec hex filename 24749 7408 64 32221 7ddd ./drivers/gpu/drm/bridge/tc358768.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2021-07-28drm/dp_mst: Fix return code on sideband message failureRajkumar Subbiah1-4/+6
Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") added some debug code for sideband message tracing. But it seems to have unintentionally changed the behavior on sideband message failure. It catches and returns failure only if DRM_UT_DP is enabled. Otherwise it ignores the error code and returns success. So on an MST unplug, the caller is unaware that the clear payload message failed and ends up waiting for 4 seconds for the response. Fixes the issue by returning the proper error code. Changes in V2: -- Revise commit text as review comment -- add Fixes text Changes in V3: -- remove "unlikely" optimization Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: Rajkumar Subbiah <rsubbia@codeaurora.org> Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/1625585434-9562-1-git-send-email-khsieh@codeaurora.org
2021-07-27drm: mxsfb: Clear FIFO_CLEAR bitMarek Vasut1-0/+3
Make sure the FIFO_CLEAR bit is latched in when configuring the controller, so that the FIFO is really cleared. And then clear the FIFO_CLEAR bit, since it is not self-clearing. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Daniel Abrecht <public@danielabrecht.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Stefan Agner <stefan@agner.ch> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com> # i.Core MX8MM Acked-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210620224946.189524-1-marex@denx.de
2021-07-27drm: mxsfb: Use bus_format from the nearest bridge if presentMarek Vasut1-8/+24
In case there is a bridge connected to the LCDIF, use bus_format from the bridge, otherwise behave as before and use bus_format from the connector. This way, even if there are multiple bridges in the display pipeline, the LCDIF will use the correct format. Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Daniel Abrecht <public@danielabrecht.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Stefan Agner <stefan@agner.ch> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210726194457.341696-1-marex@denx.de
2021-07-27drm: mxsfb: Increase number of outstanding requests on V4 and newer HWMarek Vasut4-0/+20
In case the DRAM is under high load, the MXSFB FIFO might underflow and that causes visible artifacts. This could be triggered on i.MX8MM using e.g. "$ memtester 128M" on a device with 1920x1080 panel. The first "Stuck Address" test of the memtester will completely corrupt the image on the panel and leave the MXSFB FIFO in odd state. To avoid this underflow, increase number of outstanding requests to DRAM from 2 to 16, which is the maximum. This mitigates the issue and it can no longer be triggered. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Daniel Abrecht <public@danielabrecht.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Stefan Agner <stefan@agner.ch> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210620224759.189351-1-marex@denx.de
2021-07-27drm: mxsfb: Enable recovery on underflowMarek Vasut2-0/+30
There is some sort of corner case behavior of the controller, which could rarely be triggered at least on i.MX6SX connected to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS bridged 1920x1080 panel (and likely on other setups too), where the image on the panel shifts to the right and wraps around. This happens either when the controller is enabled on boot or even later during run time. The condition does not correct itself automatically, i.e. the display image remains shifted. It seems this problem is known and is due to sporadic underflows of the LCDIF FIFO. While the LCDIF IP does have underflow/overflow IRQs, neither of the IRQs trigger and neither IRQ status bit is asserted when this condition occurs. All known revisions of the LCDIF IP have CTRL1 RECOVER_ON_UNDERFLOW bit, which is described in the reference manual since i.MX23 as " Set this bit to enable the LCDIF block to recover in the next field/frame if there was an underflow in the current field/frame. " Enable this bit to mitigate the sporadic underflows. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Daniel Abrecht <public@danielabrecht.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Stefan Agner <stefan@agner.ch> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210620224701.189289-1-marex@denx.de
2021-07-27video: fbdev: ssd1307fb: Cache address rangesGeert Uytterhoeven1-2/+25
Cache the column and page ranges, to avoid doing unneeded I2C transfers when the values haven't changed. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210727134730.3765898-6-geert@linux-m68k.org
2021-07-27video: fbdev: ssd1307fb: Optimize screen updatesGeert Uytterhoeven1-21/+29
Currently, each screen update triggers an I2C transfer of all screen data, up to 1 KiB of data for a 128x64 display, which takes at least 20 ms in Fast mode. Reduce the amount of transferred data by only updating the rectangle that changed. Remove the calls to ssd1307fb_set_col_range() and ssd1307fb_set_page_range() during initialization, as ssd1307fb_update_rect() now takes care of that. Note that for now the optimized operation is only used for fillrect, copyarea, and imageblit, which are used by fbcon. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210727134730.3765898-5-geert@linux-m68k.org
2021-07-27video: fbdev: ssd1307fb: Extract ssd1307fb_set_{col,page}_range()Geert Uytterhoeven1-20/+37
Extract the code to set the column and page ranges into two helper functions. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210727134730.3765898-4-geert@linux-m68k.org
2021-07-27video: fbdev: ssd1307fb: Simplify ssd1307fb_update_display()Geert Uytterhoeven1-7/+10
Simplify the nested loops to handle conversion from linear frame buffer to ssd1307 page layout: 1. Move last page handling one level up, as the value of "m" is the same inside a page, 2. array->data[] is filled linearly, so there is no need to recalculate array_idx over and over again; a simple increment is sufficient. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210727134730.3765898-3-geert@linux-m68k.org
2021-07-27video: fbdev: ssd1307fb: Propagate errors via ssd1307fb_update_display()Geert Uytterhoeven1-6/+12
Make ssd1307fb_update_display() return an error code, so callers that can handle failures can propagate it. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210727134730.3765898-2-geert@linux-m68k.org
2021-07-27drm: document DRM_IOCTL_MODE_RMFBSimon Ser1-0/+10
Since there's no struct to attach the docs to, document the IOCTL definition. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Leandro Ribeiro <leandro.ribeiro@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/ephVkof3uGu2RpOdBbrHE3qF98zBfIBRzXe4Vyoboh0@cp4-web-034.plabs.ch
2021-07-27drm: add logging for RMFB ioctlSimon Ser1-1/+21
We already have logging for ADDFB2. Add some logging for RMFB as well. This can be handy when trying to find out why a CRTC gets magically disabled. v2: make log message more explicit, add log messages to drm_framebuffer_remove (Daniel) Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/EghsoRDcn1SJV0nxVqRCisPd7v0627yLZbBjn4A8Yg@cp3-web-048.plabs.ch
2021-07-27Backmerge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst11807-281985/+538325
Required bump from v5.13-rc3 to v5.14-rc3, and to pick up sysfb compilation fixes. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-07-27drm/plane: Move drm_plane_enable_fb_damage_clips into coreDaniel Vetter5-58/+58
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
2021-07-27drm/plane: check that fb_damage is set up when usedDaniel Vetter4-33/+57
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
2021-07-27drm/plane: remove drm_helper_get_plane_damage_clipsDaniel Vetter4-21/+11
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
2021-07-27drm/prime: fix comment on PRIME HelpersJose Maria Casanova Crespo1-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
2021-07-27drm/bridge: dw-mipi-dsi: Find the possible DSI devicesJagan Teki1-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
2021-07-27efi: sysfb_efi: fix build when EFI is not setRandy Dunlap1-0/+2
When # CONFIG_EFI is not set, there are 2 definitions of sysfb_apply_efi_quirks(). The stub from sysfb.h should be used and the __init function from sysfb_efi.c should not be used. ../drivers/firmware/efi/sysfb_efi.c:337:13: error: redefinition of ‘sysfb_apply_efi_quirks’ __init void sysfb_apply_efi_quirks(struct platform_device *pd) ^~~~~~~~~~~~~~~~~~~~~~ In file included from ../drivers/firmware/efi/sysfb_efi.c:26:0: ../include/linux/sysfb.h:65:20: note: previous definition of ‘sysfb_apply_efi_quirks’ was here static inline void sysfb_apply_efi_quirks(struct platform_device *pd) ^~~~~~~~~~~~~~~~~~~~~~ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: linux-efi@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Mark Brown <broonie@kernel.org> Cc: linux-next@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210727050447.7339-1-rdunlap@infradead.org
2021-07-27drivers/firmware: fix SYSFB depends to prevent build failuresJavier Martinez Canillas1-1/+1
The Generic System Framebuffers support is built when the COMPILE_TEST option is enabled. But this wrongly assumes that all the architectures declare a struct screen_info. This is true for most architectures, but at least the following do not: arc, m68k, microblaze, openrisc, parisc and s390. By attempting to make this compile testeable on all architectures, it leads to linking errors as reported by the kernel test robot for parisc: All errors (new ones prefixed by >>): hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init': (.init.text+0x24): undefined reference to `screen_info' >> hppa-linux-ld: (.init.text+0x28): undefined reference to `screen_info' To prevent these errors only allow sysfb to be built on systems that are going to need it, which are x86 BIOS and EFI. The EFI Kconfig symbol is used instead of (ARM || ARM64 || RISC) because some of these architectures only declare a struct screen_info if EFI is enabled. And also, because the SYSFB code is only used for EFI on these architectures. For !EFI the "simple-framebuffer" device is registered by OF when parsing the Device Tree Blob (if a DT node for this was defined). Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210727093015.1225107-1-javierm@redhat.com
2021-07-27drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling featuresNicolas Boichat22-34/+34
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
2021-07-26video: ep93xx: Prepare clock before using itAlexander Sverdlin1-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
2021-07-26dt-bindings: Add QiShenglong vendor prefixArtjom Vejsel1-0/+2
Add vendor prefix for Shenzhen QiShenglong Industrialist Co., Ltd. QiShenglong is a Chinese manufacturer of handheld gaming consoles, most of which run (very old) versions of Linux. QiShenglong is known as Hamy. Signed-off-by: Artjom Vejsel <akawolf0@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210725221527.1771892-2-akawolf0@gmail.com
2021-07-26drm/panel: simple: Add support for two more AUO panelsBjorn Andersson1-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
2021-07-26dt-bindings: display: simple: Add AUO B133HAN05 & B140HAN06Bjorn Andersson1-0/+4
Add bindings for the two AUO panels B133HAN05 and B140HAN06, both 1920x1080 panels with 16.7M colors, first being 13.3" and the latter 14.0". 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-1-bjorn.andersson@linaro.org
2021-07-26video: fbdev: riva: Error out if 'pixclock' equals zeroZheyu Ma1-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
2021-07-26video: fbdev: kyro: Error out if 'pixclock' equals zeroZheyu Ma1-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
2021-07-26video: fbdev: asiliantfb: Error out if 'pixclock' equals zeroZheyu Ma1-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