- Mar 14, 2022
-
-
Gurchetan Singh authored
Tell userspace about the guest dedicated heap. Signed-off-by:Gurchetan Singh <gurchetansingh@chromium.org>
-
Add support of GUEST_VRAM type of blob. These are dedicated heap memory allocations required for vk support on hypervisors that don't support runtime injections of host memory into guest physical address space. The flow of usage: 1) Host VM reserves dedicated heap memory in it's dts 2) Device get info about memory reservations and report it to guest using new mmio registers 3) Guest virtio-gpu driver on starts checks new mmio registers for physical address and length of reserved region. Then it reserves it in guest. 4) On create_blob drm ioctl guest driver gets chunk of required memory and send it to host using sg list. It uses one sg entry for 1 blob call. Heap is managed on guest using drm memory manager (drm_mm). Signed-off-by:Andrii Pauk <Andrii.Pauk@opensynergy.com>
-
Gurchetan Singh authored
Let's check for the presence of the guest vram feature. Signed-off-by: -
Gurchetan Singh authored
Allocate via guest dedicated heap. Signed-off-by: -
Gurchetan Singh authored
Dedicated heap of guest memory. Signed-off-by: -
Gurchetan Singh authored
Tell userspace about the ability to create handles from guest memory. Signed-off-by: -
Gurchetan Singh authored
Necessary modifications to verify blob. Signed-off-by: -
Gurchetan Singh authored
Let's check for the presence of create guest handle feature. Signed-off-by: -
Gurchetan Singh authored
Allows the creation of OS specific handles from guest memory when the VIRTGPU_BLOB_FLAG_CREATE_GUEST_HANDLE is specified. Signed-off-by: -
Gurchetan Singh authored
This feature allows the creation of OS-specific handles from guest memory. A handle is typically an dmabuf, Zircon handle, or Win32 descriptor. Right now, only udmabuf on Linux has this capability, but VIRTIO_GPU_BLOB_FLAG_CREATE_GUEST_UDMABUF seemed OS-specific given the goals of the virtio initiative. It only works with BLOB_MEM_GUEST, of course. We can also name it some like VIRTIO_GPU_BLOB_FLAG_HANDLE_FROM_GUEST *shrugs*. Signed-off-by:
-
- Mar 11, 2022
-
-
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:
-
- Mar 09, 2022
-
-
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:
-
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
-
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:
Maxime Ripard <maxime@cerno.tech> Signed-off-by:
-
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:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
-
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:
-
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:
-
- Mar 08, 2022
-
-
Make sure we pull in the kernel-doc for this. Reported-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220208151228.344997-1-matthew.auld@intel.com Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
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:
-
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:
-
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:
-
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:
-
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:
-
