- 05 Dec, 2018 4 commits
-
-
Christoph Manszewski authored
Color format and color range was set based on resolution. Change that, by splitting range and format. Leave color format setting as it is, set color range based on drm_display_mode using drm_default_quant_range helper function. Tested on Odroid-U3 with Exynos 4412 CPU, kernel next-20181128 using modetest. Signed-off-by:
Christoph Manszewski <c.manszewski@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Christoph Manszewski authored
Fix color format decision based on height(pixels). According to CEA-861-E: "High Definition (HD) - A CE video format that, inclusively, has between 720 to 1080 active vertical lines (Vactive) lines per video frame." Tested on Odroid-U3 with Exynos 4412 CPU, kernel next-20181128 using modetest. Signed-off-by:
-
Christoph Manszewski authored
The decon hardware supports different blend modes. Add pixel blend mode property and make it configurable, by modifying the blend equation. Tested on TM2 with Exynos 5433 CPU, on top of linux-next-20181019. Signed-off-by:
-
Christoph Manszewski authored
The decon hardware supports variable plane alpha. Currently planes are opaque, make this configurable. Tested on TM2 with Exynos 5433 CPU, on top of linux-next-20181019. Signed-off-by:
-
- 04 Dec, 2018 6 commits
-
-
Andrzej Hajda authored
As DMA code is the only user of IOMMU code both files can be merged. It allows to remove stub functions, after slight adjustment of exynos_drm_register_dma. Since IOMMU functions are used locally they can be marked static. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Andrzej Hajda authored
Using C conditionals is preferred solution - it provides better code coverage, makes code more clear. Signed-off-by:
-
Andrzej Hajda authored
Since __exynos_iommu* functions are used only in exynos_drm_iommu.c we can move them there. Signed-off-by:
-
Andrzej Hajda authored
Exynos DRM drivers should work with and without IOMMU. Providing common API generic to both scenarios should make code cleaner and allow further code improvements. The patch removes including of exynos_drm_iommu.h as the file contains mostly IOMMU specific stuff, instead it exposes exynos_drm_*_dma functions and puts them into exynos_drm_dma.c. Signed-off-by:
-
Andrzej Hajda authored
DRM_EXYNOS_IOMMU symbol is not configurable, it is always equal to EXYNOS_IOMMU. Signed-off-by:
-
Andrzej Hajda authored
Moving DMA mapping creation to drm_iommu_attach_device allows to avoid looping through all components and maintaining DMA device flags. v2: take care of configurations without IOMMU Signed-off-by:
-
- 29 Nov, 2018 4 commits
-
-
Sean Paul authored
Fixes htmldocs build error: Error: Cannot open file ../drivers/gpu/drm/drm_global.c Fixes: 2bb42410 ("drm: Remove drm_global.{c,h} v2") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Christian König <christian.koenig@amd.com> Cc: Junwei Zhang <Jerry.Zhang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Sean Paul <seanpaul@chromium.org> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181129155522.33749-1-sean@poorly.run
-
Dave Airlie authored
Requested by Boris Brezillon for some vc4 fixes that are needed for future vc4 work. Signed-off-by: -
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for v4.21: Core Changes: - Merge drm_info.c into drm_debugfs.c - Complete the fake drm_crtc_commit's hw_done/flip_done sooner. - Remove deprecated drm_obj_ref/unref functions. All drivers use get/put now. - Decrease stack use of drm_gem_prime_mmap. - Improve documentation for dumb callbacks. Driver Changes: - Add edid support to virtio. - Wait on implicit fence in meson and sun4i. - Add support for BGRX8888 to sun4i. - Preparation patches for sun4i driver to start supporting linear and tiled YUV formats. - Add support for HDMI 1.4 4k modes to meson, and support for VIC alternate timings. - Drop custom dumb_map in vkms. - Small fixes and cleanups to v3d. Signed-off-by:
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
R-Car DU changes for v4.21: - R8A7744 and R8A77470 support - R8A77965 LVDS support - Miscellaneous fixes Signed-off-by:
-
- 28 Nov, 2018 1 commit
-
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
Changes outside i915: - Connector property to limit max bpc (Radhakrishna) - Fix LPE audio runtime PM and deinit (Ville) - DP FEC prep work (Anusha) - Mark pinned shmemfs pages as unevictable (Kuo-Hsin) - Backmerge drm-next (Jani) Inside i915: - Revert OA UAPI change that lacks userspace (Joonas) - Register macro cleanup (Jani) - 32-bit build fixes on pin flags (Chris) - Fix MG DP mode and PHY gating for HDMI (Imre) - DP MST race, hpd and irq fixes (Lyude) - Combo PHY fixes and cleanup (Imre, Lucas) - Move display init and cleanup under modeset init and cleanup (José) - PSR fixes (José) - Subslice size fixes (Daniele) - Abstract and clean up fixed point helpers (Jani) - Plane input CSC for YUV to RGB conversion (Uma) - Break long iterations for get/put shmemfs pages (Chris) - Improve DDI encoder hw state readout sanity checks (Imre) - Fix power well leaks for MST (José) - Scaler fixes (Ville) - Watermark fixes (Ville) - Fix VLV/CHV DSI panel orientation readout (Ville) - ICL rawclock fixes (Paulo) - Workaround DMC power well request issues (Imre) - Plane allocation fix (Maarten) - Transcoder enum value/ordering robustness fixes (Imre) - UTS_RELEASE build dependency fix (Hans Holmberg) Signed-off-by:
-
- 27 Nov, 2018 25 commits
-
-
Eric Anholt authored
This is the same as the default drm_gem_dumb_map_offset() implementation, except that this one missed the ban on userspace mapping an imported dmabuf (which seems like intended common behavior for drivers). Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20181126215929.20546-1-eric@anholt.netAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Eric Anholt authored
The extra to_v3d_bo() calls came from copying this from the vc4 driver, which stored the cma gem object in the structs. v2: Fix an unused var warning Signed-off-by:
-
Eric Anholt authored
I merged bin and render's paths in a late refactoring. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com>
-
Eric Anholt authored
Signed-off-by:
-
Neil Armstrong authored
This change is an attempt to handle the alternate clock for the CEA mode. 60Hz vs. 59.94Hz, 30Hz vs 29.97Hz or 24Hz vs 23.97Hz on the Amlogic Meson SoC DRM Driver pixel clock generation. The actual clock generation will be moved to the Common Clock framework once all the video clock are handled by the Amlogic Meson SoC clock driver, then these alternate timings will be handled in the same time in a cleaner fashion. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Maxime Jourdan <mjourdan@baylibre.com> [narmstrong: fix maybe-uninitialized warnings after applying] Link: https://patchwork.freedesktop.org/patch/msgid/1541501675-3928-1-git-send-email-narmstrong@baylibre.com
-
Neil Armstrong authored
Add the timings for the HDMI 1.4 4K modes support : - 3840x2160@30 - 3840x2160@25 - 3840x2160@24 Since the 297000Hz pixel clock is already managed and the modes are compatible with the HDMI 1.4 current HDMI PHY+Controller support, only the missing timings values needs to be added. Signed-off-by:
-
Daniel Vetter authored
Noticed while reviewing a patch from Eric. Also add a todo for the dumb_map_offset callbacks (it should be simple to do, but piles of work). Plus fix up vbox, because vbox. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nicholas Mc Guire <der.herr@hofr.at> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Fabio Rafael da Rosa <fdr@pid42.net> Reviewed-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Paul Kocialkowski authored
To prepare the introduction of tiled mode support, pass the framebuffer format modifier to the helpers dealing with format support. Since only linear mode is supported for now, add corresponding checks in each helper. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Paul Kocialkowski authored
This introduces support for the BGRX8888 output format for the frontend, with its associated output format value definition. Signed-off-by:
-
Paul Kocialkowski authored
Our hardware requires the pitch to be an even number when using YUV formats with the frontend. Implement a driver-specific callback for GEM dumb allocation that sets the pitch accordingly. Since only the bpp is passed (and not the format), we cannot really distinguish if this alignment is really required. Since it doesn't hurt to align the pitch anyway, always do it. Signed-off-by:
-
Paul Kocialkowski authored
The frontend comes with two "channels", that can be configured independently. When used in YUV mode, the first channel (CH0) represents the luminance component while the second channel (CH1) represents the chrominance. In RGB mode, both have to be configured the same way. Use variables (with the YUV terminology) for each channel's dimensions, calculating the chroma dimensions from the luma dimensions and the sub-sampling factors from the format description. Since the configured size only has pixel precision, the fractional fixed-point part of the source size is dropped for both components to ensure that the scaling factors are accurate. Signed-off-by:
-
Paul Kocialkowski authored
The values in the BT601 YUV to RGB colorspace translation are not simply coded as multiples, but rather as fixed-point signed fractional values on a given number of bits. Add an explanation about that. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Signed-off-by:
-
Paul Kocialkowski authored
This introduces support for the BGRX8888 input format for the frontend, with its associated pixel sequence value definition. Other fields are already configured correctly as they no longer depend on the format's fourcc directly. Signed-off-by:
-
Paul Kocialkowski authored
Use the number of planes associated with the DRM format to determine the input mode configuration instead of the format iteself. This way, the helper can be used for all packed formats without future changes. Signed-off-by:
-
Paul Kocialkowski authored
This introduces proper definitions for the input and output format configuration registers instead of a macro and raw values in the code, with the intent to increase code readability and reduce indirections. Signed-off-by:
-
Paul Kocialkowski authored
This introduces new helpers for retrieving the input data mode and pixel sequence register field values based on the DRM format instead of hardcoding these. This makes it easier to add support for more formats. Signed-off-by:
-
Paul Kocialkowski authored
In order to support YUV to RGB conversion with the frontend (which is generally used for connecting with the backend), the CSC block must not be bypassed. As a result, the bit to enable CSC bypass is moved from the runtime resume routine to the format update routine, so that it can disabled when introducing support for YUV formats later. Signed-off-by:
-
Paul Kocialkowski authored
Since more formats can be supported by the frontend, rename the variable listing the layer formats to avoid suggesting that the backend itself supports all the listed formats. Signed-off-by:
-
Paul Kocialkowski authored
Our hardware has a limited number of YUV planes (usually 1) that can be supported using the backend only. However, YUV planes can also be supported by the frontend and must then not be counted when checking for that limitation. Only count the YUV plane when the frontend is not used. Signed-off-by:
-
Paul Kocialkowski authored
Before this patch, it is assumed that a plane is supported either through the frontend or through the backend alone. However, the DRM interface does not allow finely reporting our hardware capabilities and there are cases where neither are support. In particular, some plane formats are supported by the backend and not the frontend, so they can only be supported without scaling. Signed-off-by:
-
Paul Kocialkowski authored
Checking that scaling is in use is not sufficient as a condition to decide to use the frontend. Since not all layer formats are supported by the frontend, we need to check for that support first. Then, the frontend must only be enabled if the backend doesn't support the format or that scaling is required. Signed-off-by:
-
Paul Kocialkowski authored
In order to check whether the frontend supports a specific format, an explicit list and a related helper are introduced. Just like in the backend, the prototype of the helper is added to the frontend header so that it can be used later on. The helper is also exported because it will be used outside of the frontend module. Signed-off-by:
-
Paul Kocialkowski authored
In order to check whether the backend supports a specific format, an explicit list and a related helper are introduced. The prototype of this helper is added to the header so that it can be called from sun4i_layer later (when introducing tiled mode support). Signed-off-by:
-
Paul Kocialkowski authored
The backend allows integer-only scaling but can handle alpha components, unlike the frontend. It could be useful to add support for this eventually, so add a short TODO comment describing the situation. Signed-off-by:
-
Paul Kocialkowski authored
The frontend documentation (for the A33) mentions that ARGB is supported as output, but with the alpha component always set to 0xff. In practice, this means that the alpha component cannot be preserved when going through the frontend. Since the information is lost, ARGB is not properly supported. As a result, expose the matching format supported by the frontend (both for input and output) as XRGB instead of ARGB. Since ARGB was the selected format for connecting the frontend to the backend, change it to XRGB to reflect this as well. The A31 and A80 SoCs apparently have a bit to enable proper alpha, but this is not supported at this point (see the comment already in the code). Signed-off-by:
-
