- 16 Mar, 2022 12 commits
-
-
Thomas Zimmermann authored
Move GEM functions from gtt.c to gem.c. Adapt some names. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
-
Thomas Zimmermann authored
Inline psb_gtt_restore() into its only caller in power.c. Perform the GTT restoration in psb_gem_mm_resume(). The restoration step is part of GEM anyway and will be moved over at some point. Signed-off-by:
-
Thomas Zimmermann authored
The GTT init, fini and resume functions contain both, GTT and GEM, code. Split each into a separate GTT and a GEM function. The GEM code is responsible for mmap_mutex and the stolen memory area. The rest of the functionality is left in GTT functions. Signed-off-by:
-
Thomas Zimmermann authored
Replace psb_gtt_takedown() with finalizer function that is only called for unloading the driver. Use roll-back pattern for error handling in psb_gtt_init() and _resume(). Also fixes a bug where vmap_addr was never unmapped. Signed-off-by:
-
Thomas Zimmermann authored
The current implementation of psb_gtt_init() also does resume handling. Move the resume code into its own helper. Signed-off-by:
-
Thomas Zimmermann authored
The GTT init and restore functions contain logic to populate the GTT entries. Move the code into helper functions. Signed-off-by:
-
Thomas Zimmermann authored
The semaphore at struct psb_mmu_driver.sem protects access to the MMU fields. Additional locking with struct psb_gtt.sem is unnecessary. Remove the field and related code. Signed-off-by:
-
Thomas Zimmermann authored
Acquire the GTT mutex in psb_gtt_{insert,remove}_pages(). Remove locking from callers. Also remove the GTT locking around the resume code. Resume does not run concurrently with other GTT operations. Signed-off-by: -
Thomas Zimmermann authored
Protect concurrent access to struct psb_gem_object by acquiring the GEM object's reservation lock; as it's supposed to be. The use of the GTT mutex can now be moved into GTT code. Signed-off-by:
-
Thomas Zimmermann authored
Calculate the number of pages in the BO's backing storage from the size. Remove the npage field. Signed-off-by:
-
YueHaibing authored
WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n] Selected by [m]: - DRM_SSD130X [=m] && HAS_IOMEM [=y] && DRM [=m] DRM_GEM_SHMEM_HELPER depends on MMU, DRM_SSD130X should also depends on MMU. Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Dmitry Baryshkov authored
The documentation for drm_rotation_simplify() uses DRM_MODE_ROTATE_X, while it's clear the comment should mention DRM_MODE_REFLECT_X instead. The example passes all flags except the DRM_MODE_REFLECT_X as supported and expects to eliminate this flag. Fixes: c2c446ad ("drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI") Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220316074648.7009-1-dmitry.baryshkov@linaro.org
-
- 14 Mar, 2022 4 commits
-
-
Ville Syrjälä authored
Replace the hand rolled drm_mode_duplicate() with the real thing. @is_dup@ @@ drm_mode_duplicate(...) { ... } @depends on !is_dup@ expression dev, oldmode; identifier newmode; @@ - newmode = drm_mode_create(dev); + newmode = drm_mode_duplicate(dev, oldmode); ... - drm_mode_copy(newmode, oldmode); Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-21-ville.syrjala@linux.intel.comAcked-by:
Sam Ravnborg <sam@ravnborg.org>
-
Ville Syrjälä authored
Replace the hand rolled drm_mode_duplicate() with the real thing. @is_dup@ @@ drm_mode_duplicate(...) { ... } @depends on !is_dup@ expression dev, oldmode; identifier newmode; @@ - newmode = drm_mode_create(dev); + newmode = drm_mode_duplicate(dev, oldmode); ... - drm_mode_copy(newmode, oldmode); Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:Philipp Zabel <p.zabel@pengutronix.de>
-
Ville Syrjälä authored
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Ville Syrjälä authored
Add a variant of drm_mode_copy() that explicitly clears out the list head of the destination mode. Helpful to guarantee we don't have stack garbage left in there for on-stack modes. Signed-off-by:
Harry Wentland <harry.wentland@amd.com>
-
- 11 Mar, 2022 8 commits
-
-
Zack Rusin authored
Initial version of guest backed objects in the host had some performance issues that made using surface-dma's instead of direct copies faster. Surface dma's force a migration to vram which at best is slow and at worst is impossible (e.g. on svga3 where there's not enough vram to migrate fb's to it). Slowly migrate away from surface dma's to direct copies by limiting their usage to systems with more than 32MB of vram. Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Maaz Mombasawala <mombasawalam@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-9-zack@kde.org
-
Zack Rusin authored
SVGAv3 deprecates legacy interrupts and adds support for MSI/MSI-X. With MSI the driver visible side remains largely unchanged but with MSI-X each interrupt gets delivered on its own vector. Add support for MSI/MSI-X while preserving the old functionality for SVGAv2. Code between the SVGAv2 and SVGAv3 is exactly the same, only the number of available vectors changes, in particular between legacy and MSI-X interrupts. Signed-off-by:
-
Zack Rusin authored
Transition to drm_mode_fb_cmd2 from drm_mode_fb_cmd left the structure unitialized. drm_mode_fb_cmd2 adds a few additional members, e.g. flags and modifiers which were never initialized. Garbage in those members can cause random failures during the bringup of the fbcon. Initializing the structure fixes random blank screens after bootup due to flags/modifiers mismatches during the fbcon bring up. Fixes: dabdcdc9 ("drm/vmwgfx: Switch to mode_cmd2") Signed-off-by:
-
Zack Rusin authored
Mesa3D loaders require knowledge of the devices PCI id. SVGAv2 and v3 have different PCI id's, but the same driver is used to handle them both. To allow Mesa3D svga driver to be loaded automatically for both SVGAv2 and SVGAv3 make the kernel return the PCI id of the currently running device. Signed-off-by:
-
Zack Rusin authored
Port of the vmwgfx to SVGAv3 lacked support for fencing. SVGAv3 removed FIFO's and replaced them with command buffers and extra registers. The initial version of SVGAv3 lacked support for most advanced features (e.g. 3D) which made fences unnecessary. That is no longer the case, especially as 3D support is being turned on. Switch from FIFO commands and capabilities to command buffers and extra registers to enable fences on SVGAv3. Fixes: 2cd80dbd ("drm/vmwgfx: Add basic support for SVGA3") Signed-off-by:
-
Zack Rusin authored
Capabilities were logged at the end of initialization so any early errors would make them not appear in the logs. Which is also when they're needed the most. Print the the capabilities right after fetching them, before the init code starts using them to make sure they always show up in the logs. Signed-off-by:
-
Zack Rusin authored
The results of the legacy display unit initialization were being silently ignored. Unifying the selection of number of display units based on whether the underlying device supports multimon makes it easier to add error checking to all paths. This makes the driver report the errors in ldu initialization paths and try to recover from them. Signed-off-by:
-
Martin Krastev authored
* Add support for CursorMob * Add support for CursorBypass 4 * Refactor vmw_du_cursor_plane_atomic_update to be kms-helper-atomic -- move BO mappings to vmw_du_cursor_plane_prepare_fb -- move BO unmappings to vmw_du_cursor_plane_cleanup_fb Cursor mobs are a new svga feature which enables support for large cursors, e.g. large accessibility cursor on platforms with vmwgfx. It also cleans up the cursor code and makes it more uniform with the rest of modern guest backed objects support. Signed-off-by:
-
- 09 Mar, 2022 16 commits
-
-
Brian Norris authored
DP AUX transactions can consist of many short operations. There's no need to power things up/down in short intervals. I pick an arbitrary 100ms; for the systems I'm testing (Rockchip RK3399), runtime-PM transitions only take a few microseconds. Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Brian Norris authored
If the display is not enable()d, then we aren't holding a runtime PM reference here. Thus, it's easy to accidentally cause a hang, if user space is poking around at /dev/drm_dp_aux0 at the "wrong" time. Let's get a runtime PM reference, and check that we "see" the panel. Don't force any panel power-up, etc., because that can be intrusive, and that's not what other drivers do (see drivers/gpu/drm/bridge/ti-sn65dsi86.c and drivers/gpu/drm/bridge/parade-ps8640.c.) Fixes: 0d97ad03 ("drm/bridge: analogix_dp: Remove duplicated code") Cc: <stable@vger.kernel.org> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
-
Douglas Anderson authored
Though the parade bridge chip is a little bit of a black box, I'm at least interested in hearing about changes to the driver since this bridge chip is used on some Chromebooks that I'm involved with. Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220308110615.3.I04f99fbcc14b8c09610b4b18f0696c992a44d2b7@changeid
-
Douglas Anderson authored
I've spent quite a bit of time poking at this driver and it's used on several Chromebooks I'm involved with. I'd like to get notified about patches. Add myself as a reviewer. It's expected that changes will still be landed through drm-misc as they always have been. Signed-off-by:
-
Douglas Anderson authored
The bindings for bridge chips should also get the same maintainers entry so the right people get notified about bindings changes. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Reviewed-by:
-
Chen-Yu Tsai authored
Currently the ssd130x driver only sets the segment remap setting when the device tree requests it; it however does not clear the setting if it is not requested. This leads to the setting incorrectly persisting if the hardware is always on and has no reset GPIO wired. This might happen when a developer is trying to find the correct settings for an unknown module, and cause the developer to get confused because the settings from the device tree are not consistently applied. Make the driver apply the segment remap setting consistently, setting the value correctly based on the device tree setting. This also makes this setting's behavior consistent with the other settings, which are always applied. Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
-
Chen-Yu Tsai authored
The SSD130x's command to toggle COM scan direction uses bit 3 and only bit 3 to set the direction of the scanout. The driver has an incorrect GENMASK(3, 2), causing the setting to be set on bit 2, rendering it ineffective. Fix the mask to only bit 3, so that the requested setting is applied correctly. Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Tom Rix authored
Clang static analysis reports this issue anx7625.c:876:13: warning: The left operand of '&' is a garbage value if (!(bcap & 0xOA01)) { ~~~~ ^ bcap is only set by a successful call to anx7625_aux_trans(). So check. Fixes: cd1637c7 ("drm/bridge: anx7625: add HDCP support") Signed-off-by:Tom Rix <trix@redhat.com> Fixes: adca62ec ("drm/bridge: anx7625: Support reading edid through aux channel") Signed-off-by:
-
Rex-BC Chen authored
This device requires the packets on lanes aligned at the end to fix screen shift or scroll. Signed-off-by:
Jitao Shi <jitao.shi@mediatek.com> Signed-off-by:
Rex-BC Chen <rex-bc.chen@mediatek.com> Acked-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Xin Ji <xji@analogixsemi.com> Reviewed-by:
-
Rex-BC Chen authored
Some DSI RX devices (for example, anx7625) require last alignment of packets on all lanes after each row of data is sent. Otherwise, there will be some issues of shift or scroll for screen. Take horizontal_sync_active_byte for a example, we roundup the HSA packet data to lane number, and the subtraction of 2 is the packet data value added by the roundup operation, making the long packets are integer multiples of lane number. This value (2) varies with the lane number, and that is the reason we do this operation when the lane number is 4. In the previous operation of function "mtk_dsi_config_vdo_timing", the length of HSA and HFP data packets has been adjusted to an integration multiple of lane number. Since the number of RGB data packets cannot be guaranteed to be an integer multiple of lane number, we modify the data packet length of HBP so that the number of HBP + RGB is equal to the lane number. So after sending a line of data (HSA + HBP + RGB + HFP), the data lanes are aligned. Signed-off-by:
Xinlei Lee <xinlei.lee@mediatek.com> Reviewed-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by:
-
Rex-BC Chen authored
Since a HS transmission is composed of an arbitrary number of bytes that may not be an integer multiple of lanes, some lanes may run out of data before others. (Defined in 6.1.3 of mipi_DSI_specification_v.01-02-00) However, for some DSI RX devices (for example, anx7625), there is a limitation that packet number should be the same on all DSI lanes. In other words, they need to end a HS at the same time. Because this limitation is for some specific DSI RX devices, it is more reasonable to put the enable control in these DSI RX drivers. If DSI TX driver knows the information, they can adjust the setting for this situation. Signed-off-by:
-
Noralf Trønnes authored
The datasheet lists the minimum Serial clock cycle (Write) as 66ns which is 15MHz. Mostly it can do much better than that and is in fact often run at 32MHz. With a clever driver that runs configuration commands at a low speed and only the pixel data at the maximum speed the configuration can't be messed up by transfer errors and the speed is only limited by the amount of pixel glitches that one is able to tolerate. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-4-noralf@tronnes.org
-
Noralf Trønnes authored
There are other ways than using a gpio to reset the controller so make this property optional. Signed-off-by:
-
Noralf Trønnes authored
The backlight property was lost during conversion to yaml in commit abdd9e37 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema"). Put it back. Fixes: abdd9e37 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
