- 27 Nov, 2018 18 commits
-
-
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 <paul.kocialkowski@bootlin.com> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-23-paul.kocialkowski@bootlin.com
-
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:
Boris Brezillon <boris.brezillon@bootlin.com> Acked-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:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181121180215.13881-1-noralf@tronnes.org
-
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 7 commits
-
-
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:
Neil Armstrong <narmstrong@baylibre.com> [narmstrong: added Suggested-by tag] Signed-off-by:
-
Gerd Hoffmann authored
linux guest driver implementation of the VIRTIO_GPU_F_EDID feature. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Daniel Vetter <daniel@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20181030063206.19528-3-kraxel@redhat.com
-
Gerd Hoffmann authored
The feature allows the guest request an EDID blob (describing monitor capabilities) for a given scanout (aka virtual monitor connector). It brings a new command message, which has just a scanout field (beside the standard virtio-gpu header) and a response message which carries the EDID data. Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181030063206.19528-2-kraxel@redhat.com
-
Christophe Fergeau authored
QEMU keeps a vram reference to the last QXLCursorCmd it received. This QXLCursorCmd command points to a QXLCursor instance (stored in vram too). However, while the QXLCursorCmd memory is pinned, the QXLCursor memory is not. When booting a recent Fedora to its login screen while monitoring the QXLCursorCmd QEMU holds, it's possible to see the QXLCursor memory becoming invalid shortly after boot. Pinning that memory ensures that that QXLCursor memory is not going to be moved by the guest kernel. Moving the pin/unpin to qxl_release_list_add()/qxl_release_free_list() would be a more generic fix. However, doing this quickly exhausts QXL video memory, so more fixing would be needed before this is workable. Signed-off-by:
Christophe Fergeau <cfergeau@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181120162004.22807-3-cfergeau@redhat.comSigned-off-by:
-
Christophe Fergeau authored
The 'domain' argument to qxl_bo_pin is redundant with 'bo', and 'gpu_addr' is unused, so we can remove both. Signed-off-by:
-
Christophe Fergeau authored
qxl_bo_unref() is already performing a NULL check. Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/cirrus/cirrus_fbdev.c: In function 'cirrusfb_create': drivers/gpu/drm/cirrus/cirrus_fbdev.c:172:20: warning: variable 'bo' set but not used [-Wunused-but-set-variable] It never used since introduction in commit f9aa76a8 ("drm/kms: driver for virtual cirrus under qemu") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Link: http://patchwork.freedesktop.org/patch/msgid/1542283836-152176-1-git-send-email-yuehaibing@huawei.comSigned-off-by:
-
- 20 Nov, 2018 2 commits
-
-
Stanislav Lisovskiy authored
v5: This is YUV444 packed format same as AYUV, but without alpha, as supported by i915. v6: Removed unneeded initializer for new XYUV format. v7: Added is_yuv field initialization according to latest drm_fourcc format structure initialization changes. v8: Edited commit message to be more clear about skl+, renamed PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format doesn't support per-pixel alpha. Fixed minor code issues. v9: Moved DRM format check to proper place in intel_framebuffer_init. v10: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV8888 v11: Fixed rebase conflict, caused by added new formats to drm-tip meanwhile. Reviewed-by:Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> [vsyrjala: Removed stray tab and sorted the formats differently] Signed-off-by:
-
Noralf Trønnes authored
The CMA helper now has the functionality to ensure a virtual address on imported buffer so use that. While touching all tinydrm drivers, remove the unnecessary inclusion of drm_fb_helper.h in some drivers. Cc: David Lechner <david@lechnology.com> Cc: Eric Anholt <eric@anholt.net> Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-6-noralf@tronnes.org
-
