| #
e9c897c8 |
| 13-Apr-2026 |
Damon Ding <damon.ding@rock-chips.com> |
drm/bridge: analogix_dp: Add new API analogix_dp_finish_probe()
Since the panel/bridge should logically be positioned behind the Analogix bridge in the display pipeline, it makes sense to handle the
drm/bridge: analogix_dp: Add new API analogix_dp_finish_probe()
Since the panel/bridge should logically be positioned behind the Analogix bridge in the display pipeline, it makes sense to handle the panel/bridge parsing on the Analogix side. Therefore, we add a new API analogix_dp_finish_probe(), which combines the panel/bridge parsing with component addition, to do it.
In order to process component binding right after the probe completes, the &analogix_dp_plat_data.ops is newly added to pass &component_ops, for which the &dp_aux_ep_device_with_data.done_probing() of DP AUX bus only supports passing &drm_dp_aux.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-4-damon.ding@rock-chips.com [Luca: propagate 'depends on OF' to DRM_ANALOGIX_DP and reverse dependencies] Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
show more ...
|
| #
99a49ff5 |
| 13-Apr-2026 |
Damon Ding <damon.ding@rock-chips.com> |
drm/bridge: analogix_dp: Apply drm_bridge_connector helper
Initialize bridge_connector for both Rockchip and Exynos encoder sides. Then, make DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory for Analogix br
drm/bridge: analogix_dp: Apply drm_bridge_connector helper
Initialize bridge_connector for both Rockchip and Exynos encoder sides. Then, make DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory for Analogix bridge side, as the private &drm_connector is no longer created.
The previous &drm_connector_funcs and &drm_connector_helper_funcs APIs are replaced by the corresponding &drm_bridge_funcs APIs:
analogix_dp_atomic_check() -> analogix_dp_bridge_atomic_check() analogix_dp_detect() -> analogix_dp_bridge_detect() analogix_dp_get_modes() -> analogix_dp_bridge_get_modes() analogix_dp_bridge_edid_read()
Additionally, the compatibilities of Analogix DP bridge based on whether the next bridge is a 'panel'. If it is, OP_MODES and OP_DETECT are supported; If not (the next bridge is a 'monitor' or a bridge chip), OP_EDID and OP_DETECT are supported.
The devm_drm_bridge_add() is placed in analogix_dp_bind() instead of analogix_dp_probe(), because the type of next bridge (the panel, monitor or bridge chip) can only be determined after the probe process has fully completed.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260413132551.1049307-3-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
show more ...
|
| #
1b7cee81 |
| 09-Apr-2026 |
Damon Ding <damon.ding@rock-chips.com> |
drm/exynos: exynos_dp: Apply of-display-mode-bridge to parse the display-timings node
If there is neither a panel nor a bridge, the display timing can be parsed from the display-timings node under t
drm/exynos: exynos_dp: Apply of-display-mode-bridge to parse the display-timings node
If there is neither a panel nor a bridge, the display timing can be parsed from the display-timings node under the dp node.
In order to get rid of &analogix_dp_plat_data.get_modes() and make the codes more consistent, apply DRM of-display-mode-bridge to parse display timings.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-6-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
show more ...
|
| #
d4016e31 |
| 24-Sep-2024 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/exynos-drm: Run DRM default client setup
Rework fbdev probing to support fbdev_probe in struct drm_driver and remove the old fb_probe callback. Provide an initializer macro for struct drm_driver
drm/exynos-drm: Run DRM default client setup
Rework fbdev probing to support fbdev_probe in struct drm_driver and remove the old fb_probe callback. Provide an initializer macro for struct drm_driver that sets the callback according to the kernel configuration.
Call drm_client_setup() to run the kernel's default client setup for DRM. Set fbdev_probe in struct drm_driver, so that the client setup can start the common fbdev client.
The exynos-drm driver specifies a preferred color mode of 32. As this is the default if no format has been given, leave it out entirely.
v5: - select DRM_CLIENT_SELECTION v4: - revert an unrelated cleanup (Javier)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Inki Dae <inki.dae@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-75-tzimmermann@suse.de
show more ...
|
| #
b21f187f |
| 29-Jul-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Use _DMAMEM_ infix for DMA-memory helpers
Change the infix for fbdev's DMA-memory helpers from _DMA_ to _DMAMEM_. The helpers perform operations within DMA-able memory, but they don't perform
fbdev: Use _DMAMEM_ infix for DMA-memory helpers
Change the infix for fbdev's DMA-memory helpers from _DMA_ to _DMAMEM_. The helpers perform operations within DMA-able memory, but they don't perform DMA operations. Naming should make this clear. Adapt all users. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230729193157.15446-4-tzimmermann@suse.de
show more ...
|
| #
b1d69bf1 |
| 07-Jul-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/exynos: Use fbdev DMA helpers
Use fbdev's DMA helpers for fbdev emulation. The driver previously used the I/O-memory helpers, while allocating DMA-able system memory. This could (in theory) resu
drm/exynos: Use fbdev DMA helpers
Use fbdev's DMA helpers for fbdev emulation. The driver previously used the I/O-memory helpers, while allocating DMA-able system memory. This could (in theory) result in bus errors from accessing the memory range.
This bug has been present since the exynos driver was first added.
v2: * drop the pointless Fixes tag (Javier) * fix typo in commit message
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Inki Dae <inki.dae@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Alim Akhtar <alim.akhtar@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230707083422.18691-7-tzimmermann@suse.de
show more ...
|
| #
ac9dc1b1 |
| 30-May-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/exynos: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's helpers. Exynos does not use damage handling, so DRM's fbdev helpers are mere wrappers ar
drm/exynos: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's helpers. Exynos does not use damage handling, so DRM's fbdev helpers are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation, we can eventually remove DRM's wrapper functions entirely.
v4: * use initializer macros for struct fb_ops v3: * don't reorder Makefile rules (Sam) v2: * use FB_IO_HELPERS option
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Inki Dae <inki.dae@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Alim Akhtar <alim.akhtar@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230530151228.22979-5-tzimmermann@suse.de
show more ...
|
| #
e7447128 |
| 08-Mar-2023 |
Jagan Teki <jagan@amarulasolutions.com> |
drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge
Samsung MIPI DSIM controller is common DSI IP that can be used in various SoCs like Exynos, i.MX8M Mini/Nano.
In order to access
drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge
Samsung MIPI DSIM controller is common DSI IP that can be used in various SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various platform SoCs, the ideal way to incorporate this in the drm stack is via the drm bridge driver.
We already have a consolidated code for supporting component and bridge based DRM drivers, so keep the exynos component based code in existing exynos_drm_dsi.c and move generic bridge code as part of samsung-dsim.c
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
9fcc00ea |
| 09-Dec-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
drm: Drop ARCH_MULTIPLATFORM from dependencies
Some of these dependencies used to be sensible when only a small part of the platforms supported by ARCH=arm could be compiled together in a single ker
drm: Drop ARCH_MULTIPLATFORM from dependencies
Some of these dependencies used to be sensible when only a small part of the platforms supported by ARCH=arm could be compiled together in a single kernel image. Nowadays ARCH_MULTIPLATFORM is only used as a guard for kernel options incompatible with a multiplatform image. See commit 84fc86360623 ("ARM: make ARCH_MULTIPLATFORM user-visible") for some more details.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221209220555.3631364-1-u.kleine-koenig@pengutronix.de
show more ...
|
| #
1e0f6642 |
| 21-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/display: Introduce a DRM display-helper module
Replace the DP-helper module with a display-helper module. The support for DisplayPort becomes an internal option that drivers have to select. Upda
drm/display: Introduce a DRM display-helper module
Replace the DP-helper module with a display-helper module. The support for DisplayPort becomes an internal option that drivers have to select. Update all related Kconfig and Makefile rules.
Besides the existing code for DisplayPort, the new module will contain helpers for other video-output standards, such as HDMI. Drivers will have to select their required video-output helpers.
Linking all display-related code into a single module avoids the proliferation of small kernel modules.
The module parameters drm_dp_cec_unregister_delay, dp_aux_i2c_speed_khz, and dp_aux_i2c_transfer_size are moving from the drm_dp_helper namespace to drm_display_helper.
v2: * mention module parameters in commit message (Javier) * distiguish between display module and DP support in Kconfig * update Makefile rules for DP helpers * move Kconfig rules into separate file under display/
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-4-tzimmermann@suse.de
show more ...
|
| #
53dbee49 |
| 31-Jan-2022 |
Dave Airlie <airlied@redhat.com> |
Merge tag 'drm-misc-next-2022-01-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
[airlied: add two missing Kconfig]
drm-misc-next for v5.18:
UAPI Changes: - Fix invalid IN_FORMATS
Merge tag 'drm-misc-next-2022-01-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
[airlied: add two missing Kconfig]
drm-misc-next for v5.18:
UAPI Changes: - Fix invalid IN_FORMATS blob when plane->format_mod_supported is NULL.
Cross-subsystem Changes: - Assorted dt bindings updates. - Fix vga16fb vga checking on x86. - Fix extra semicolon in rwsem.h's _down_write_nest_lock. - Assorted small fixes to agp and fbdev drivers. - Fix oops in creating a udmabuf with 0 pages. - Hot-unplug firmware fb devices on forced removal - Reqquest memory region in simplefb and simpledrm, and don't make the ioresource as busy.
Core Changes: - Mock a drm_plane in drm-plane-helper selftest. - Assorted bug fixes to device logging, dbi. - Use DP helper for sink count in mst. - Assorted documentation fixes. - Assorted small fixes. - Move DP headers to drm/dp, and add a drm dp helper module. - Move the buddy allocator from i915 to common drm. - Add simple pci and platform module init macros to remove a lot of boilerplate from some drivers. - Support microsoft extension for HMDs and specialized monitors. - Improve edid parser's deep color handling. - Add type 7 timing support to edid parser. - Add a weak backpointer to the ttm_bo from ttm_resource - Add 3 eDP panels.
Driver Changes: - Add support for HDMI and JZ4780 to ingenic. - Add support for higher DP/eDP bitrates to nouveau. - Assorted driver fixes to tilcdc, vmwgfx, sn65dsi83, meson, stm, panfrost, v3d, gma500, vc4, virtio, mgag200, ast, radeon, amdgpu, nouveau, various bridge drivers. - Convert and revert exynos dsi support to bridge driver. - Add vcc supply regulator support for sn65dsi83. - More conversion of bridge/chipone-icn6211 to atomic. - Remove conflicting fb's from stm, and add support for new hw version. - Add device link in parade-ps8640 to fix suspend/resume. - Update Boe-tv110c9m init sequence. - Add wide screen support to AST2600. - Fix omapdrm implicit dma_buf fencing. - Add support for multiple overlay planes to vkms. - Convert bridge/anx7625 to atomic, add HDCP support, add eld support for audio, and fix HPD. - Add driver for ChromeOS privacy screen. - Handover display from firmware to vc4 more gracefully, and support nomodeset. - Add flexible and ycbcr pixel formats to stm/ltdc. - Convert exynos mipi dsi to atomic. - Add initial dual core group GPUs support to panfrost. - No longer add exclusive fence in amdgpu as shared fence. - Add CSC and full range supoprt to vc4. - Shutdown the display on system shutdown and unbind. - Add Multi-Inno Technology MI0700S4T-6 simple panel.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/456a23c6-7324-7543-0c45-751f30ef83f7@linux.intel.com
show more ...
|
| #
2c8c08f3 |
| 27-Nov-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/exynos: Stop using frame_vector helpers
All we need are a pages array, pin_user_pages_fast can give us that directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin
drm/exynos: Stop using frame_vector helpers
All we need are a pages array, pin_user_pages_fast can give us that directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such ptes are marked with pte_mkspecial (which pup_fast rejects in the fastpath), and only architectures supporting that support the pin_user_pages_fast fastpath.
Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Jan Kara <jack@suse.cz> Cc: Dan Williams <dan.j.williams@intel.com> Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-media@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201127164131.2244124-2-daniel.vetter@ffwll.ch
show more ...
|
| #
e2d3d2e9 |
| 16-Nov-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
drm/exynos: depend on COMMON_CLK to fix compile tests
The Exynos DRM uses Common Clock Framework thus it cannot be built on platforms without it (e.g. compile test on MIPS with RALINK and SOC_RT305X
drm/exynos: depend on COMMON_CLK to fix compile tests
The Exynos DRM uses Common Clock Framework thus it cannot be built on platforms without it (e.g. compile test on MIPS with RALINK and SOC_RT305X):
/usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in function `mixer_bind': exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent'
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
c0bf499f |
| 04-Jan-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
drm/exynos: Rename Exynos to lowercase
Fix up inconsistent usage of upper and lowercase letters in "Exynos" name.
"EXYNOS" is not an abbreviation but a regular trademarked name. Therefore it should
drm/exynos: Rename Exynos to lowercase
Fix up inconsistent usage of upper and lowercase letters in "Exynos" name.
"EXYNOS" is not an abbreviation but a regular trademarked name. Therefore it should be written with lowercase letters starting with capital letter.
The lowercase "Exynos" name is promoted by its manufacturer Samsung Electronics Co., Ltd., in advertisement materials and on website.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
d6f25bd9 |
| 09-Jul-2019 |
Arnd Bergmann <arnd@arndb.de> |
drm/exynos: add CONFIG_MMU dependency
Compile-testing this driver on a NOMMU configuration shows a link failure:
drivers/gpu/drm/exynos/exynos_drm_gem.o: In function `exynos_drm_gem_fault': exynos_
drm/exynos: add CONFIG_MMU dependency
Compile-testing this driver on a NOMMU configuration shows a link failure:
drivers/gpu/drm/exynos/exynos_drm_gem.o: In function `exynos_drm_gem_fault': exynos_drm_gem.c:(.text+0x484): undefined reference to `vmf_insert_mixed'
Add a CONFIG_MMU dependency to ensure we only enable this in configurations that build correctly.
Many other drm drivers have the same dependency. It would be nice to make this work in MMU-less configurations, but evidently nobody has ever needed this so far.
Fixes: 156bdac99061 ("drm/exynos: trigger build of all modules") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Inki Dae <daeinki@gmail.com>
show more ...
|
| #
156bdac9 |
| 27-Jun-2019 |
Sam Ravnborg <sam@ravnborg.org> |
drm/exynos: trigger build of all modules
Add COMPILE_TEST dependency to force exynos driver to built for more than arm and to built modules that otherwise required other symbols to be de-selected.
drm/exynos: trigger build of all modules
Add COMPILE_TEST dependency to force exynos driver to built for more than arm and to built modules that otherwise required other symbols to be de-selected.
This will increase build coverage of the exynos driver thus allowing most trivial build errors to be detected/fixed early.
This introduces one warning when built using sh: exynos7_drm_decon.c: In function ‘decon_remove’: exynos7_drm_decon.c:769:24: warning: unused variable ‘ctx’ struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
This is due to the definition of iounmap() in sh, and nothing that exynos driver can fix.
Include fix of exynos build for alpha.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Jingoo Han <jingoohan1@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
ec8f24b7 |
| 19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier - Makefile/Kconfig
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project
treewide: Add SPDX license identifier - Makefile/Kconfig
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| #
69908ed2 |
| 12-Oct-2018 |
Andrzej Hajda <a.hajda@samsung.com> |
drm/exynos/iommu: remove DRM_EXYNOS_IOMMU Kconfig symbol
DRM_EXYNOS_IOMMU symbol is not configurable, it is always equal to EXYNOS_IOMMU.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-o
drm/exynos/iommu: remove DRM_EXYNOS_IOMMU Kconfig symbol
DRM_EXYNOS_IOMMU symbol is not configurable, it is always equal to EXYNOS_IOMMU.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
01fb9185 |
| 09-May-2018 |
Andrzej Pietrasiewicz <andrzej.p@samsung.com> |
drm/exynos: Add driver for Exynos Scaler module
Exynos Scaler is a hardware module, which processes graphic data fetched from memory and transfers the resultant dato another memory buffer. Graphics
drm/exynos: Add driver for Exynos Scaler module
Exynos Scaler is a hardware module, which processes graphic data fetched from memory and transfers the resultant dato another memory buffer. Graphics data can be up/down-scaled, rotated, flipped and converted color space. Scaler hardware modules are a part of Exynos5420 and newer Exynos SoCs.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
7a2d5c77 |
| 10-May-2018 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drm/exynos: fimc: Convert driver to IPP v2 core API
This patch adapts Exynos DRM FIMC driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to registe
drm/exynos: fimc: Convert driver to IPP v2 core API
This patch adapts Exynos DRM FIMC driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Merge conflict so merged manually. Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
8b7d3ec8 |
| 09-May-2018 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drm/exynos: gsc: Convert driver to IPP v2 core API
This patch adapts Exynos DRM GScaler driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to regis
drm/exynos: gsc: Convert driver to IPP v2 core API
This patch adapts Exynos DRM GScaler driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to register properly in the Exynos DRM core. During the conversion driver has been adapted to support more specific compatible strings to distinguish between Exynos5250 and Exynos5420 (different hardware limits). Support for Exynos5433 variant has been added too (different limits table, removed dependency on ARCH_EXYNOS5).
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
d8cb9eea |
| 09-May-2018 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drm/exynos: rotator: Convert driver to IPP v2 core API
This patch adapts Exynos DRM rotator driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to r
drm/exynos: rotator: Convert driver to IPP v2 core API
This patch adapts Exynos DRM rotator driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
9913f74f |
| 10-May-2018 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drm/exynos: ipp: Add IPP v2 framework
This patch adds Exynos IPP v2 subsystem and userspace API.
New userspace API is focused ONLY on memory-to-memory image processing. The two remainging operation
drm/exynos: ipp: Add IPP v2 framework
This patch adds Exynos IPP v2 subsystem and userspace API.
New userspace API is focused ONLY on memory-to-memory image processing. The two remainging operation modes of obsolete IPP v1 API (framebuffer writeback and local-path output with image processing) can be implemented using standard DRM features: writeback connectors and additional DRM planes with scaling features.
V2 IPP userspace API is based on stateless approach, which much better fits to memory-to-memory image processing model. It also provides support for all image formats, which are both already defined in DRM API and supported by the existing IPP hardware modules.
The API consists of the following ioctls: - DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image processing modules, - DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image formats of given IPP module, - DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for selected image format of given IPP module, - DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the provided structures (source and destination buffers, operation rectangle, transformation, etc).
The proposed userspace API is extensible. In the future more advanced image processing operations can be defined to support for example blending.
Userspace API is fully functional also on DRM render nodes, so it is not limited to the root/privileged client.
Internal driver API also has been completely rewritten. New IPP core performs all possible input validation, checks and object life-time control. The drivers can focus only on writing configuration to hardware registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies the driver API. Minimal driver needs to provide a single callback for starting processing and an array with supported image formats.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Merge conflict so merged manually. Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
5fae288d |
| 21-Apr-2018 |
Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> |
drm/exynos: Allow DRM_EXYNOS on s5pv210.
This patch brings back possibility to use drivers depending on DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.
Fixes: dbbc925bb83a ("drm/exynos
drm/exynos: Allow DRM_EXYNOS on s5pv210.
This patch brings back possibility to use drivers depending on DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.
Fixes: dbbc925bb83a ("drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS") Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|
| #
8ded5941 |
| 14-Dec-2017 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drm/exynos: ipp: Remove Exynos DRM IPP subsystem
Exynos DRM IPP subsystem is in fact non-functional and frankly speaking dead-code. This patch clearly marks that Exynos DRM IPP subsystem is broken a
drm/exynos: ipp: Remove Exynos DRM IPP subsystem
Exynos DRM IPP subsystem is in fact non-functional and frankly speaking dead-code. This patch clearly marks that Exynos DRM IPP subsystem is broken and never really functional. It will be replaced by a completely rewritten API.
Exynos DRM IPP user-space API can be obsoleted for the following reasons:
1. Exynos DRM IPP user-space API can be optional in Exynos DRM, so userspace should not rely that it is always available and should have a software fallback in case it is not there.
2. The only mode which was initially semi-working was memory-to-memory image processing. The remaining modes (LCD-"writeback" and "output") were never operational due to missing code (both in mainline and even vendor kernels).
3. Exynos DRM IPP mainline user-space API compatibility for memory-to-memory got broken very early by commit 083500baefd5 ("drm: remove DRM_FORMAT_NV12MT", which removed the support for tiled formats, the main feature which made this API somehow useful on Exynos platforms (video codec that time produced only tiled frames, to implement xvideo or any other video overlay, one has to de-tile them for proper display).
4. Broken drivers. Especially once support for IOMMU has been added, it revealed that drivers don't configure DMA operations properly and in many cases operate outside the provided buffers trashing memory around.
5. Need for external patches. Although IPP user-space API has been used in some vendor kernels, but in such cases there were additional patches applied (like reverting mentioned 083500baefd5 patch) what means that those userspace apps which might use it, still won't work with the mainline kernel version.
We don't have time machines, so we cannot change it, but Exynos DRM IPP extension should never have been merged to mainline in that form.
Exynos IPP subsystem and user-space API will be rewritten, so remove current IPP core code and mark existing drivers as BROKEN.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
show more ...
|