- 05 1月, 2023 1 次提交
-
-
由 Dmitry Baryshkov 提交于
The functionality of drm_bridge_connector_enable_hpd() and drm_bridge_connector_disable_hpd() is provided automatically by the drm_kms_poll helpers. Stop calling these functions manually. Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-7-dmitry.baryshkov@linaro.org
-
- 17 12月, 2022 2 次提交
-
-
由 Tomi Valkeinen 提交于
dsi_dump_dsi_irqs(), a function used for debugfs prints, has a large struct in its frame, which can result in: drivers/gpu/drm/omapdrm/dss/dsi.c:1126:1: warning: the frame size of 1060 bytes is larger than 1024 bytes [-Wframe-larger-than=] As the performance of the function is of no concern, let's allocate the struct with kmalloc instead. Compile-tested only. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reported-by: Nkernel test robot <lkp@intel.com> Reviewed-by: NArnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220916082206.167427-1-tomi.valkeinen@ideasonboard.com
-
由 Yuan Can 提交于
After commit 64ff1891, struct csc_coef_rgb2yuv is not used any more and can be removed as well. Fixes: 64ff1891 ("drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes") Signed-off-by: NYuan Can <yuancan@huawei.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014024810.21675-1-yuancan@huawei.com
-
- 12 11月, 2022 1 次提交
-
-
由 Dmitry Osipenko 提交于
When userspace mmaps dma-buf's fd, the dma-buf reservation lock must be held. Add locking sanity checks to the dma-buf mmaping callbacks of DRM drivers to ensure that the locking assumptions won't regress in future. Suggested-by: NDaniel Vetter <daniel@ffwll.ch> Signed-off-by: NDmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by: NChristian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221110201349.351294-3-dmitry.osipenko@collabora.com
-
- 06 11月, 2022 3 次提交
-
-
由 Thomas Zimmermann 提交于
Rename drm_fb_helper_unregister_fbi() to drm_fb_helper_unregister_info() as part of unifying the naming within fbdev helpers. Adapt drivers. No functional changes. Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-15-tzimmermann@suse.de
-
由 Thomas Zimmermann 提交于
Rename drm_fb_helper_alloc_fbi() to drm_fb_helper_alloc_info() as part of unifying the naming within fbdev helpers. Adapt drivers. No functional changes. Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-14-tzimmermann@suse.de
-
由 Thomas Zimmermann 提交于
Rename struct drm_fb_helper.fbdev to info. The current name is misleading as it overlaps with generic fbdev naming conventions. Adapt to the usual naming in fbdev drivers by calling the field 'info'. No functional changes. Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-13-tzimmermann@suse.de
-
- 20 10月, 2022 1 次提交
-
-
由 Zack Rusin 提交于
The fb_base in struct drm_mode_config has been unused for a long time. Some drivers set it and some don't leading to a very confusing state where the variable can't be relied upon, because there's no indication as to which driver sets it and which doesn't. The only usage of fb_base is internal to two drivers so instead of trying to force it into all the drivers to get it into a coherent state completely remove it. Signed-off-by: NZack Rusin <zackr@vmware.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: NThomas Zimmermann <tzimemrmann@suse.de> Acked-by: NChristian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221019024401.394617-1-zack@kde.org
-
- 18 10月, 2022 1 次提交
-
-
由 Dmitry Osipenko 提交于
Prepare OMAP DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NDmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221017172229.42269-8-dmitry.osipenko@collabora.com
-
- 09 9月, 2022 3 次提交
-
-
由 ye xingchen 提交于
From the coccinelle check: ./drivers/gpu/drm/omapdrm/omap_dmm_tiler.c Error:line 817 is redundant because platform_get_irq() already prints an error So,remove the unnecessary print function dev_err() Reported-by: NZeal Robot <zealci@zte.com.cn> Signed-off-by: Nye xingchen <ye.xingchen@zte.com.cn> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220810062738.13554-1-ye.xingchen@zte.com.cn
-
由 Liang He 提交于
In dss_init_ports() and __dss_uninit_ports(), we should call of_node_put() for the reference returned by of_graph_get_port_by_id() in fail path or when it is not used anymore. Fixes: 09bffa6e ("drm: omap: use common OF graph helpers") Signed-off-by: NLiang He <windhl@126.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220722144348.1306569-1-windhl@126.com
-
由 Guo Zhengkui 提交于
Fix the following coccicheck warning: drivers/gpu/drm/omapdrm/dss/dispc.c:2454:21-22: WARNING opportunity for max() Signed-off-by: NGuo Zhengkui <guozhengkui@vivo.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220517050208.121488-1-guozhengkui@vivo.com
-
- 27 7月, 2022 1 次提交
-
-
由 Thomas Zimmermann 提交于
Remove the include statement for drm_plane_helper.h from all the files that don't need it. Althogh the header file is almost empty, many drivers include it somewhere. Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NSam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-5-tzimmermann@suse.de
-
- 06 7月, 2022 1 次提交
-
-
由 Ville Syrjälä 提交于
drm_crtc.h has no need for linux/fb.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/fb.h. Quite a few placs do currently depend on linux/fb.h or other headers pulled in by it without actually including any of it directly. All of those need to be fixed up. v2: Split the vmwgfx change out Acked-by: NSam Ravnborg <sam@ravnborg.org> Acked-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220630195114.17407-3-ville.syrjala@linux.intel.com
-
- 21 6月, 2022 3 次提交
-
-
由 Ville Syrjälä 提交于
drm_crtc.h has no need for drm_blend.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_blend.h. Quite a few placs do currently depend on drm_blend.h without actually including it directly. All of those need to be fixed up. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220613200317.11305-4-ville.syrjala@linux.intel.comAcked-by: NSam Ravnborg <sam@ravnborg.org> Acked-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
drm_crtc.h has no need for drm_frambuffer.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_framebuffer.h. Quite a few placs do currently depend on drm_framebuffer.h without actually including it directly. All of those need to be fixed up. v2: Fix up msm some more v2: Deal with ingenic and shmobile as well Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220614095449.29311-1-ville.syrjala@linux.intel.comAcked-by: NSam Ravnborg <sam@ravnborg.org> Acked-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
drm_crtc.h has no need for drm_edid.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_edid.h. Quite a few placs do currently depend on drm_edid.h without actually including it directly. All of those need to be fixed up. v2: Fix up i915 and msm some more v3: Fix alphabetical ordering (Sam) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220614090245.30283-1-ville.syrjala@linux.intel.comAcked-by: NSam Ravnborg <sam@ravnborg.org> Acked-by: NJani Nikula <jani.nikula@intel.com>
-
- 28 3月, 2022 3 次提交
-
-
由 Ivaylo Dimitrov 提交于
On devices with DMM, all allocations are done through either DMM or TILER. DMM/TILER being a limited resource means that such allocations will start to fail before actual free memory is exhausted. What is even worse is that with time DMM/TILER space gets fragmented to the point that even if we have enough free DMM/TILER space and free memory, allocation fails because there is no big enough free block in DMM/TILER space. Such failures can be easily observed with OMAP xorg DDX, for example - starting few GUI applications (so buffers for their windows are allocated) and then rotating landscape<->portrait while closing and opening new windows soon results in allocation failures. Fix that by mapping buffers through DMM/TILER only when really needed, like, for scanout buffers. Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1642587791-13222-4-git-send-email-ivo.g.dimitrov.75@gmail.com
-
由 Ivaylo Dimitrov 提交于
Currently code allocates non-scanout BOs from SHMEM and those objects are accessible to userspace by mmap(). However, on devices with no DMM (like OMAP3), the same objects are not accessible by kernel drivers that want to render to them as code refuses to export them. In turn this means that on devices with no DMM, all buffers must be allocated as scanout, otherwise only CPU can access them. On those devices, scanout buffers are allocated from CMA, making those allocations highly unreliable. Fix that by implementing functionality to export SHMEM backed buffers on devices with no DMM. This makes CMA memory only being used when needed, instead for every buffer that has to be off-CPU rendered. Tested on Motorola Droid4 and Nokia N900 Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1642587791-13222-3-git-send-email-ivo.g.dimitrov.75@gmail.com
-
由 Ivaylo Dimitrov 提交于
Move tiler related code to its own function. Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1642587791-13222-2-git-send-email-ivo.g.dimitrov.75@gmail.com
-
- 08 3月, 2022 1 次提交
-
-
由 Wan Jiabing 提交于
Fix the following coccicheck warning: ./drivers/gpu/drm/omapdrm/omap_overlay.c:89:22-25: ERROR: r_ovl is NULL but dereferenced. Here should be ovl->idx rather than r_ovl->idx. Fixes: e02b5cc9 ("drm/omap: Add a 'right overlay' to plane state") Signed-off-by: NWan Jiabing <wanjiabing@vivo.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220307095612.409090-1-wanjiabing@vivo.com
-
- 26 2月, 2022 3 次提交
-
-
由 Maxime Ripard 提交于
The omap KMS driver will call drm_plane_create_color_properties() with a default encoding and range values of BT601 and Full Range, respectively. Since the initial value wasn't carried over in the state, the driver had to set it again in omap_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Reviewed-by: NTomi Valkeinen <tomba@kernel.org> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-23-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The omap KMS driver will call drm_plane_create_zpos_property() with an init value of the plane index and the plane type. Since the initial value wasn't carried over in the state, the driver had to set it again in omap_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Reviewed-by: NTomi Valkeinen <tomba@kernel.org> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-15-maxime@cerno.tech
-
由 Maxime Ripard 提交于
While the omap_plane_init() function calls drm_plane_create_zpos_property() with an initial value of 0, omap_plane_reset() will force it to another value depending on the plane type. Fix the discrepancy by setting the initial zpos value to the same value in the drm_plane_create_zpos_property() call. Reviewed-by: NTomi Valkeinen <tomba@kernel.org> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-5-maxime@cerno.tech
-
- 25 2月, 2022 1 次提交
-
-
由 Yong Wu 提交于
Use the common compare helper from component. Cc: Tomi Valkeinen <tomba@kernel.org> Cc: Cai Huoqing <caihuoqing@baidu.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NYong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20220214060819.7334-17-yong.wu@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 28 1月, 2022 1 次提交
-
-
由 Javier Martinez Canillas 提交于
According to disable Documentation/admin-guide/kernel-parameters.txt, this parameter can be used to disable kernel modesetting. DRM drivers will not perform display-mode changes or accelerated rendering and only the system framebuffer will be available if it was set-up. But only a few DRM drivers currently check for nomodeset, make this driver to also support the command line parameter. Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211217003752.3946210-31-javierm@redhat.com
-
- 06 1月, 2022 1 次提交
-
-
由 Ivaylo Dimitrov 提交于
Currently omapdrm driver does not initialize dma_buf_export_info resv member, which leads to a new dma_resv being allocated and attached to the exported dma_buf. This leads to the issue that fences created on dma_buf objects imported by other drivers are ignored by omapdrm, as only fences in gem object resv are waited on. This leads to various issues like displaying incomplete frames. Fix that by initializing dma_buf resv to the resv of the gem object being exported. Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Tested-by: NMerlijn Wajer <merlijn@wizzup.org> Tested-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1641397018-29872-1-git-send-email-ivo.g.dimitrov.75@gmail.com
-
- 08 12月, 2021 11 次提交
-
-
由 Arnd Bergmann 提交于
Using the SET_RUNTIME_PM_OPS() macro causes a warning about the referenced functions when they are marked static but not __maybe_unused: drivers/gpu/drm/omapdrm/dss/dss.c:1572:12: error: unused function 'dss_runtime_suspend' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dss.c:1584:12: error: unused function 'dss_runtime_resume' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dispc.c:4845:12: error: unused function 'dispc_runtime_suspend' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dispc.c:4860:12: error: unused function 'dispc_runtime_resume' [-Werror,-Wunused-function] Fixes: b92f7ea5 ("drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211205131612.3192652-1-arnd@kernel.org
-
由 Benoit Parrot 提交于
If the drm_plane has a source width that's greater than the max width supported by a single hw overlay, then we assign a 'r_overlay' to it in omap_plane_atomic_check(). Both overlays should have the capabilities required to handle the source framebuffer. The only parameters that vary between the left and right hwoverlays are the src_w, crtc_w, src_x and crtc_x as we just even chop the fb into left and right halves. We also take care of not creating odd width size when dealing with YUV formats. Since both halves need to be 'appear' side by side the zpos is recalculated when dealing with dual overlay cases so that the other planes zpos is consistent. Depending on user space usage it is possible that on occasion the number of requested planes exceeds the numbers of overlays required to display them. In that case a failure would be returned for the plane that cannot be handled at that time. It is up to user space to make sure the H/W resource are not over-subscribed. Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-10-narmstrong@baylibre.com
-
由 Benoit Parrot 提交于
Now that we added specific item to our subclassed drm_plane_state we can add omap_plane_atomic_print_state() helper to dump out our own driver specific plane state. Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-9-narmstrong@baylibre.com
-
由 Benoit Parrot 提交于
(re)assign the hw overlays to planes based on required caps, and to handle situations where we could not modify an in-use plane. This means all planes advertise the superset of formats and properties. Userspace must (as always) use atomic TEST_ONLY step for atomic updates, as not all planes may be available for use on every frame. The mapping of hwoverlays to plane is stored in omap_global_state, so that state updates are atomically committed in the same way that plane/etc state updates are managed. This is needed because the omap_plane_state keeps a pointer to the hwoverlay, and we don't want global state to become out of sync with the plane state if an atomic update fails, we hit deadlock/ backoff scenario, etc. The use of global_state_lock keeps multiple parallel updates which both re-assign hwoverlays properly serialized. Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-8-narmstrong@baylibre.com
-
由 Benoit Parrot 提交于
Global shared resources (like hw overlays) for omapdrm are implemented as a part of atomic state using the drm_private_obj infrastructure available in the atomic core. omap_global_state is introduced as a drm atomic private object. The two funcs omap_get_global_state() and omap_get_existing_global_state() are the two variants that will be used to access omap_global_state. drm_mode_config_init() needs to be called earlier because it creates/initializes the private_obj link list maintained by the atomic framework. The private_obj link list has to exist prior to calling drm_atomic_private_obj_init(). Similarly the cleanup handler are reordered appropriately. Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-7-narmstrong@baylibre.com
-
由 Benoit Parrot 提交于
In preparation to add omap plane state specific extensions we need to subclass drm_plane_state and add the relevant helpers. The addition of specific extension will be done separately. Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-6-narmstrong@baylibre.com
-
由 Benoit Parrot 提交于
Split out the hardware overlay specifics from omap_plane. To start, the hw overlays are statically assigned to planes. The goal is to eventually assign hw overlays dynamically to planes during plane->atomic_check() based on requested caps (scaling, YUV, etc). And then perform hw overlay re-assignment if required. Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-5-narmstrong@baylibre.com
-
由 Benoit Parrot 提交于
In order to be able to dynamically assign overlays to planes we need to be able to asses the overlay capabilities. Add a helper function to be able to retrieve the supported capabilities of an overlay. And export the function to check if a fourcc is supported on a given overlay. Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-4-narmstrong@baylibre.com
-
由 Benoit Parrot 提交于
We currently assume that an overlay has the same maximum width and maximum height as the overlay manager. This assumption is incorrect. On some variants the overlay manager maximum width is twice the maximum width that the overlay can handle. We need to add the appropriate data per variant as well as export a helper function to retrieve the data so check can be made dynamically in omap_plane_atomic_check(). Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-3-narmstrong@baylibre.com
-
由 Neil Armstrong 提交于
Call drm_atomic_helper_check_plane_state() from the plane atomic_check() callback in order to add plane state sanity checking. It will permit filtering out totally bad scaling factors, even if the real check are done later in the atomic commit. Calling drm_atomic_helper_check_plane_state() also sets plane_state->visible which will be useful when dynamically assigning hw overlays to planes. Signed-off-by: NBenoit Parrot <bparrot@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-2-narmstrong@baylibre.com
-
由 Ivaylo Dimitrov 提交于
Memory of BOs backed by TILER is not contiguous, but omap_gem_map_dma_buf() exports it like it is. This leads to (possibly) invalid memory accesses if another device imports such a BO. Fix that by providing sg that correctly describes TILER memory layout. Align TILER allocations to page, so importer to be able to correctly set its MMU if have one. Set export size accounting for the alignment. Also, make sure to destroy sg on unpin, as it is no longer valid. Tested on Motorola Droid4 by using GPU (sgx540) to render. Suggested-by: NMatthijs van Duin <matthijsvanduin@gmail.com> Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1637309180-31032-1-git-send-email-ivo.g.dimitrov.75@gmail.com
-
- 10 11月, 2021 2 次提交
-
-
由 Tomi Valkeinen 提交于
DSS5's maximum tv pclk rate (i.e. HDMI) is set to 186MHz, which comes from the TRM (DPLL_HDMI_CLK1 frequency must be lower than 186 MHz). To support DRA76's wide screen HDMI feature, we need to increase this maximum rate. Testing shows that the PLL seems to work fine even with ~240MHz clocks, and even the HDMI output at that clock is stable enough for monitors to show a picture. This holds true for all DRA7 and AM5 SoCs (and probably also for OMAP5). However, the highest we can go without big refactoring to the clocking code is 192MHz, as that is the DSS func clock we get from the PRCM. So, increase the max HDMI pixel clock to 192MHz for now, to allow some more 2k+ modes to work. This patch never had a clear confirmation from HW people, but this change stayed on production trees for multiple years without any report on an eventual breakage. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211012133939.2145462-1-narmstrong@baylibre.com
-
由 Cai Huoqing 提交于
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: NCai Huoqing <caihuoqing@baidu.com> Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210831135707.4676-1-caihuoqing@baidu.com
-