- 30 Jul, 2021 2 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
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
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
- R-Car DU shutdown fixes - R-Car DU conversion to bridge connector helper - Misc small fixes Signed-off-by:
-
- 29 Jul, 2021 3 commits
-
-
Maxime Ripard authored
Commit 91e99e11 ("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: 91e99e11 ("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
-
Maxime Ripard authored
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:
-
Desmond Cheong Zhi Xi authored
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:
-
- 28 Jul, 2021 17 commits
-
-
Linus Walleij authored
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
-
Desmond Cheong Zhi Xi authored
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:
-
Zack Rusin authored
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
-
Zack Rusin authored
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 authored
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 authored
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:
-
Laurent Pinchart authored
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>
-
Laurent Pinchart authored
The drm_bridge.driver_private field is set but never used. Don't set it. Signed-off-by:
-
Laurent Pinchart authored
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:
Jacopo Mondi <jacopo+renesas@jmondi.org> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # On V3U Reviewed-by:
-
Laurent Pinchart authored
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 authored
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 authored
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:
Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # On V3U Reviewed-by:
-
Laurent Pinchart authored
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:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Jyri Sarha <jyri.sarha@iki.fi>
-
Laurent Pinchart authored
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 authored
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: ea6aae15 ("drm: rcar-du: Embed drm_device in rcar_du_device") Signed-off-by:
-
Laurent Pinchart authored
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:
-
Colin Ian King authored
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:
-
- 27 Jul, 2021 18 commits
-
-
Rajkumar Subbiah authored
Commit 2f015ec6 ("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: 2f015ec6 ("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:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Marek Vasut authored
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: 45d59d70 ("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:
-
Marek Vasut authored
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:
-
Marek Vasut authored
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: 45d59d70 ("drm: Add new driver for MXSFB controller") Signed-off-by:
-
Marek Vasut authored
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: 45d59d70 ("drm: Add new driver for MXSFB controller") Signed-off-by:
-
Geert Uytterhoeven authored
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:
-
Geert Uytterhoeven authored
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 authored
Extract the code to set the column and page ranges into two helper functions. Signed-off-by:
-
Geert Uytterhoeven authored
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 authored
Make ssd1307fb_update_display() return an error code, so callers that can handle failures can propagate it. Signed-off-by:
-
Simon Ser authored
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:
-
Simon Ser authored
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:
-
Maarten Lankhorst authored
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>
-
Daniel Vetter authored
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
-
Daniel Vetter authored
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 authored
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:
-
Jose Maria Casanova Crespo authored
s/Exporting/Importing Fixes: 805dc614 ("drm/prime: Update docs") Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Jose Maria Casanova Crespo <jmcasanova@igalia.com> Signed-off-by:
-
Jagan Teki authored
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: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:
-
