- 27 Nov, 2018 26 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:
-
Paul Kocialkowski authored
This adds a dedicated function for cleaning the video and YUV source channel layer enable bits. This function is called first on layer atomic update to make sure that there are no leftover bits from previous plane configuration that were not cleaned until now. It fixes issues when alternating between video and YUV planes, where both bits would be set eventually, leading to broken plane display. Signed-off-by:
-
- 24 Nov, 2018 8 commits
-
-
Fernando Ramos authored
This entry asked to rename all drm core "*_reference/_unrefence" functions to "*_get/_put". Now that this task is complete, we can remove this entry from the TODO list. Signed-off-by:
Fernando Ramos <greenfoo@gluegarage.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Fernando Ramos authored
The coccinelle script was used to rename some (deprecated) functions which no longer exist now. Signed-off-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
Fernando Ramos authored
There are no more places where this (deprecated) function is being used from, thus it can now be removed. Signed-off-by:
-
Fernando Ramos authored
There are no more places where this (deprecated) function is being used from, thus it can now be removed. Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Fernando Ramos authored
This patch unifies the naming of DRM functions for reference counting as requested on Documentation/gpu/todo.rst Signed-off-by:
-
Fernando Ramos authored
There are no more places where this (deprecated) function is being used from, thus it can now be removed. Signed-off-by:
-
Fernando Ramos authored
This patch unifies the naming of DRM functions for reference counting as requested on Documentation/gpu/todo.rst Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Acked-by:
Stefan Agner <stefan@agner.ch> Reviewed-by:
-
Fernando Ramos authored
There are no more places where these (deprecated) functions are being used from, thus they can now be removed. Signed-off-by:
-
- 23 Nov, 2018 2 commits
-
-
Ville Syrjälä authored
For real commits we WARN if ->hw_done hasn't been completed by the time drm_atomic_helper_commit_cleanup_done() is called. Let's do the same for the fake commit. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181122143412.11655-2-ville.syrjala@linux.intel.comReviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
Consider the following scenario: 1. nonblocking enable crtc 2. wait for the event 3. nonblocking disable crtc On i915 this can lead to a spurious -EBUSY from step 3 on account of non-enabled planes getting the fake_commit in step 1 and we don't complete the fake_commit-> flip_done until drm_atomic_helper_commit_hw_done() which can happen a long time after the flip event was sent out. This will become somewhat easy to hit on SKL+ once we start to add all the planes for the crtc to every modeset commit for the purposes of forcing a watermark register programming [1]. To make the race a little less pronounced let's complete fake_commit->flip_done after drm_atomic_helper_wait_for_flip_done(). For the single crtc case this should make the race quite theoretical, assuming drm_atomic_helper_wait_for_flip_done() actually has to wait for the real commit flip_done. In case the real commit flip_done gets completed singificantly before drm_atomic_helper_wait_for_flip_done(), or we are dealing with multiple crtcs whose vblanks don't line up nicely the race still exists. [1] https://patchwork.freedesktop.org/patch/262670/ Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 080de2e5 ("drm/atomic: Check for busy planes/connectors before setting the commit") Testcase: igt/kms_cursor_legacy/*nonblocking-modeset-vs-cursor-atomic Signed-off-by:
-
- 22 Nov, 2018 3 commits
-
-
Noralf Trønnes authored
drivers/gpu/drm/drm_prime.c: In function 'drm_gem_prime_mmap': >> drivers/gpu/drm/drm_prime.c:688:1: warning: the frame size of 1592 bytes is larger than 1024 bytes [-Wframe-larger-than=] Fix by allocating on the heap. Fixes: 7698799f ("drm/prime: Add drm_gem_prime_mmap()") Reported-by:
kbuild test robot <lkp@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
-
Qiang Yu authored
Render like lima will attach a fence to the framebuffer dma_buf, display like sun4i should wait it finish before show the framebuffer. Otherwise tearing will be observed. Signed-off-by:
Qiang Yu <yuq825@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Ever since commit cb6458f9 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 15:41:34 2013 +0200 drm: remove procfs code, take 2 Having the code shared between procfs and debugfs in the separate drm_info.c file stopped making sense. Merge them. Noticed because Lyude asked some questions on irc about why we even have drm_info_node and I remember this old story. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121213510.31260-1-daniel.vetter@ffwll.ch
-
- 21 Nov, 2018 1 commit
-
-
Koen Kooi authored
Suggested by Qiang Yu <yuq825@gmail.com> to fix tearing artefacts in the Kodi GUI. Suggested-by:
Koen Kooi <koen@dominion.thruhere.net> Acked-by:
-
