- 27 Feb, 2020 17 commits
-
-
Christian König authored
Implement the importer side of unpinned DMA-buf handling. v2: update page tables immediately Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/353998/?series=73646&rev=1
-
Christian König authored
This implements the exporter side of unpinned DMA-buf handling. v2: fix minor coding style issues Signed-off-by:
-
Christian König authored
Avoid that we ping/pong the buffers when we stop to pin DMA-buf exports by using the allowed domains for exported buffers. Signed-off-by:
-
Christian König authored
Pipeline removal of the BOs backing store when no placement is given during validation. Signed-off-by:
-
Christian König authored
On the exporter side we add optional explicit pinning callbacks. Which are called when the importer doesn't implement dynamic handling, move notification or need the DMA-buf locked in place for its use case. On the importer side we add an optional move_notify callback. This callback is used by the exporter to inform the importers that their mappings should be destroyed as soon as possible. This allows the exporter to provide the mappings without the need to pin the backing store. v2: don't try to invalidate mappings when the callback is NULL, lock the reservation obj while using the attachments, add helper to set the callback v3: move flag for invalidation support into the DMA-buf, use new attach_info structure to set the callback v4: use importer_priv field instead of mangling exporter priv. v5: drop invalidation_supported flag v6: squash together with pin/unpin changes v7: pin/unpin takes an attachment now v8: nuke dma_buf_attachment_(map|unmap)_locked, everything is now handled backward compatible v9: always cache when export/importer don't agree on dynamic handling v10: minimal style cleanup v11: drop automatically re-entry avoidance v12: rename callback to move_notify v13: add might_lock in appropriate places v14: rebase on separated locking change v15: add EXPERIMENTAL flag, some more code comments Signed-off-by: -
Vasily Khoruzhick authored
This commit adds support for the NewEast Optoelectronics CO., LTD WJFH116008A 11.6" 1920x1080 TFT LCD panel. Signed-off-by:
Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200226081011.1347245-6-anarsoul@gmail.com
-
Vasily Khoruzhick authored
This commit adds compatible for NewEast Optoelectronics WJFH116008A panel to panel-simple binding Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Vasily Khoruzhick authored
Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Vasily Khoruzhick authored
We don't want to print scary message if devm_regulator_get() returns -EPROBE_DEFER Reviewed-by:
-
Gurchetan Singh authored
The plan is use have both shmem and virtual "vram" running side-by-side in virtio-gpu. It looks like we'll eventually use struct drm_gem_object as a base class, and we'll need to convert to shmem and vram objects on the fly. As a first step, add a virtio_gpu_is_shmem helper. Thanks to kraxel for suggesting this approach on Gitlab. Suggested-by:
Gerd Hoffman <kraxel@redhat.com> Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20200227002601.745-3-gurchetansingh@chromium.orgSigned-off-by:
-
Gurchetan Singh authored
This is a very, very minor cleanup. Signed-off-by:
-
Tian Tao authored
use the drm_fb_helper_remove_conflicting_pci_framebuffer to remove the framebuffer initialized by fireware/bootloader to avoid resource conflict. Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Xinliang Liu <xinliang.liu@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1582524112-5628-1-git-send-email-tiantao6@hisilicon.com
-
Tian Tao authored
set the preferred mode resolution to 1024 * 768 and maximum resolution to 1920 * 1200. Signed-off-by:
Gong junjie <gongjunjie2@huawei.com> Signed-off-by:
-
Tian Tao authored
add mode_valid function, we can make sure the resolution is valid. Signed-off-by:
-
Tian Tao authored
The maximum resolution supported by hibmc is 1920 * 1200 instead of 1920 * 1440, this patch fixed this problem Signed-off-by:
-
Tian Tao authored
set the prefer_shadow as 1,so we use the shadowfb to acceleration. Signed-off-by:
-
Tian Tao authored
Add the three new pll config for corresponding resolution 1440x900 and 1600x900, 640x480 for hibmc Signed-off-by:
-
- 26 Feb, 2020 23 commits
-
-
Laurent Pinchart authored
The omap_dss_device .pre_enable(), .post_disable() and .set_timings() are not used anymore. Remove them. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by:
-
Laurent Pinchart authored
The omapdss_of_find_connected_device() function isn't used anymore, remove it. Signed-off-by:
-
Laurent Pinchart authored
Inline the omapdss_display_get() in its only caller to simplify the code. Signed-off-by:
-
Laurent Pinchart authored
The omap_connector implementation is now used for DSI only. Hardcode its type and drop unused code. Signed-off-by:
-
Laurent Pinchart authored
In order to integrate with a chain of drm_bridge, the internal SDI output has to expose its operations through the drm_bridge API. Register a bridge at initialisation time to do so and remove the omap_dss_device operations that are now unused. Signed-off-by:
-
Laurent Pinchart authored
This makes it easier to quickly locate duplicate includes. Signed-off-by:
-
Laurent Pinchart authored
In order to integrate with a chain of drm_bridge, the internal DPI output has to expose its operations through the drm_bridge API. Register a bridge at initialisation time to do so and remove the omap_dss_device operations that are now unused. Signed-off-by:
-
Laurent Pinchart authored
The dpi_set_pll_clk() and dpi_set_dispc_clk() return various information through pointer arguments that are never used by the callers. Remove them to simplify the clock setting API. Signed-off-by:
-
Laurent Pinchart authored
Group functions based on their purpose and split them in sections to make the source code easier to navigate. No functional change is included. Signed-off-by:
-
Laurent Pinchart authored
This makes it easier to quickly locate duplicate includes. Signed-off-by:
-
Laurent Pinchart authored
Now that the omap_dss_device EDID read operation has been removed, simplify the bridge-based EDID access by merging multiple functions together. Signed-off-by:
-
Laurent Pinchart authored
Now that the omap_dss_device EDID read operation has been removed, simplify the bridge-based EDID access by merging multiple functions together. Signed-off-by:
-
Laurent Pinchart authored
Now that the VENC output is driven fully through the drm_bridge API its omap_dss_device operations are not used anymore. Remove them. Signed-off-by:
-
Laurent Pinchart authored
Now that the HDMI outputs are driven fully through the drm_bridge API their omap_dss_device operations are not used anymore. Remove them. Signed-off-by:
-
Laurent Pinchart authored
Due to the removal of several omapdrm display drivers, the omapdss HPD, detected and EDID operations are not used anymore. Remove them and all related code. Signed-off-by:
-
Laurent Pinchart authored
The TPD12S015, OPA362 and analog and HDMI connectors are now supported by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be handled through the drm_bridge API. Switch the outputs to drm_bridge by making the next bridge mandatory and removing the related omapdrm-specific display drivers. Signed-off-by:
-
Laurent Pinchart authored
Use the drm_bridge_connector helper to create a connector for pipelines that use drm_bridge. This allows splitting connector operations across multiple bridges when necessary, instead of having the last bridge in the chain creating the connector and handling all connector operations internally. Signed-off-by:
-
Laurent Pinchart authored
In order to integrate with a chain of drm_bridge, the internal VENC encoder has to expose the mode valid, fixup and set, the enable and disable and the get modes operations through the drm_bridge API. Register a bridge at initialisation time to do so. Most of those operations are removed from the omap_dss_device as they are now called through the drm_bridge API by the DRM atomic helpers. The only exception is the .get_modes() operation that is still invoked through the omap_dss_device-based pipeline. For the time being make the next bridge in the chain optional as the VENC output is still based on omap_dss_device. The create_connector argument to the bridge attach function is also ignored for the same reason. This will be changed later when removing the related omapdrm-specific display drivers. Signed-off-by:
-
Laurent Pinchart authored
The omapdss_hdmi_ops .set_hdmi_mode() and .set_infoframe() operations operations are not used anymore, remove them. Signed-off-by:
-
Laurent Pinchart authored
The HDMI4 encoder is transitioning to the drm_bridge API, implement the last missing operation. Signed-off-by:
-
Laurent Pinchart authored
Move the omap_dss_device .set_timings(), .enable() and .disable() operations to the drm_bridge functions. As the drm_bridge for the HDMI encoder is unconditionally registered and attached, those operations will be called at the appropriate time. The omapdss device .set_infoframe() and .set_hdmi_mode() operations have no equivalent in drm_bridge. Thir content is thus moved to the bridge .enable() operation as the data they store is not needed before the HDMI encoder gets enabled. Signed-off-by:
-
Laurent Pinchart authored
Move the omap_dss_device .set_timings(), .enable() and .disable() operations to the drm_bridge functions. As the drm_bridge for the HDMI encoder is unconditionally registered and attached, those operations will be called at the appropriate time. The omapdss device .set_infoframe() and .set_hdmi_mode() operations have no equivalent in drm_bridge. Thir content is thus moved to the bridge .enable() operation as the data they store is not needed before the HDMI encoder gets enabled. Signed-off-by:
-
Laurent Pinchart authored
In order to integrate with a chain of drm_bridge, the internal HDMI5 encoder has to expose the EDID read operation through the drm_bridge API. Register a bridge at initialisation time to do so. For the time being make the next bridge in the chain optional as the HDMI output is still based on omap_dss_device. The create_connector argument to the bridge attach function is also ignored for the same reason. This will be changed later when removing the related omapdrm-specific display drivers. Signed-off-by:
-
