- 18 Jan, 2019 19 commits
-
-
Paul Kocialkowski authored
This introduces a helper to check whether a frontend input format supports tiling mode. This helper is used when tiling is requested in the frontend format support helper. Only semiplanar and planar YUV formats are supported by the hardware. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Paul Kocialkowski authored
This introduces stride and offset configuration for the VPU tiling mode. Stride is calculated differently than it is for linear formats and an offset is calculated, for which new register definitions are introduced. Signed-off-by:
-
Paul Kocialkowski authored
This introduces the data input mode definitions for the tiled YUV mode, that are used in the input mode helper if tiling is requested. The modifier is passed to the helper from the framebuffer to determine if tiling is requested. Only semiplanar and planar YUV formats are supported for tiling mode. Signed-off-by:
-
Paul Kocialkowski authored
This introduces specific definitions for vendor Allwinner and its associated tiled format modifier. This modifier is used for the output format of the VPU, that can be imported directly with the display engine hardware supported by the sun4i-drm driver. Signed-off-by:
-
Paul Kocialkowski authored
Planar YUV formats come with 3 distinct planes, which requires configuring the frontend line stride and address registers for the third plane. Our hardware only supports the YUV planes order and in order to support formats with a YVU plane order, a helper is introduced to indicate whether to invert the address of the two chroma planes. Missing definitions for YUV411 and YUV444 input format configuration are also introduced as support is added for these formats. For the input sequence part, no configuration is required for planar YUV formats so zero is returned in that case. Signed-off-by:
-
Paul Kocialkowski authored
Semi-planar YUV formats use two distinct planes, one for luminance and one for chrominance. To add support for them, we need to configure the second line stride and buffer address registers to setup the second YUV plane. New definitions are introduced to configure the input format register for the YUV420 and YUV422 semi-planar formats. Signed-off-by:
-
Paul Kocialkowski authored
This introduces support for packed YUV formats with 4:2:2 sampling using the frontend. Definitions are introduced for the data format and pixel sequence input format register values. Signed-off-by:
-
Paul Kocialkowski authored
In prevision of adding support for YUV formats, set the YUV to RGB colorspace conversion coefficients if required and don't bypass the CSC engine when converting. The BT601 coefficients from the A33 BSP are copied over from the backend code. Because of module inter-dependency, we can't have the frontend use these coefficients from the backend directly. Signed-off-by:
-
Paul Kocialkowski authored
Both the backend and the frontend need the BT.601 CSC coefficients for YUV to RGB conversion. Since the backend has a dependency on the frontend (and not the other way round), move the coefficients there so that both can access them without having to duplicate them. Signed-off-by:
-
Paul Kocialkowski authored
Since all the RGB input formats have the same value for the DATA_FMT field of the INPUT_FMT register, we can group them when the format is known to be RGB. Here, we assume that a non-YUV format is RGB, because the hardware does not support any other colorspace than RGB and YUV. Use the DRM format info structure to check whether the format uses a YUV colorspace. Signed-off-by:
-
Paul Kocialkowski authored
The helper returning the input mode needs to know the number of planes for the provided format. Passing the fourcc requires iterating through the format info list in order to return the number of planes. Pass the DRM format info structure directly instead to all helpers related to configuring the input format, since it's available to the caller. Also rename the input format in the caller function to keep things consistent. Signed-off-by:
-
Paul Kocialkowski authored
Checking for the number of planes is not sufficient to en ensure that the format is a packed YUV422. Use explicit fourcc helpers for the check instead. Signed-off-by:
-
Paul Kocialkowski authored
Display engine drivers often need to distinguish between different types of YUV sub-sampling. This introduces helpers to check for common sub-sampling ratios in their commonly-used denomination from the DRM format info. Signed-off-by:
-
Paul Kocialkowski authored
It is often useful to check whether the DRM format info retrieved from the DRM framebuffer matches a specific YUV planes disposition. This introduces helpers to quickly check that a provided format info matches a YUV format with a specific disposition, in commonly-used terminology. The intent of providing helpers taking the format info instead of the fourcc alone is to avoid the overhead of iterating through all formats when the whole format info structure is available. As a result, these helpers are very simple so they are made inline. Signed-off-by:
-
Peter Rosin authored
Optionally power down the LVDS-encoder when it is not in use. Signed-off-by:
Peter Rosin <peda@axentia.se> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Peter Rosin authored
Make the code easier to read and modify. Signed-off-by:
-
Peter Rosin authored
The name powerdown-gpios is the standard property name for the functionality covered by the previous pwdn-gpios name. This rename should be safe to do since the linux driver supporting the binding (lvds-encoder.c) never implemented the property, and no dts file names it. At least not upstream. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peter Rosin authored
Drop #address-cells and #size-cells from the root node in the example, they are unused. Reviewed-by:
-
Peter Rosin authored
DS90C185 has a shutdown pin which does not fit in the lvds-transmitter binding, which is meant to be generic. The sister chip DS90C187 is similar to DS90C185, describe it here as well. Signed-off-by:
-
- 17 Jan, 2019 7 commits
-
-
Noralf Trønnes authored
- Better manual-upload support for atomic The new damage helper has the necessary pieces to make this work. - tinydrm_gem_cma_prime_import_sg_table This is now moved to the CMA helper and can be set using the DRM_GEM_CMA_VMAP_DRIVER_OPS macro. - tinydrm_fb_create This is now covered by drm_gem_fb_create_with_dirty() Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190115043643.2364-6-noralf@tronnes.org
-
Noralf Trønnes authored
This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty handler. All flushing will now happen in the pipe functions. Also enable the damage plane property for all except repaper which can only do full updates. ili9225: This change made ili9225_init() equal to mipi_dbi_init() so use it. v3: Include vblank header (Sam) ili9225 and st7586 can't use mipi_dbi_enable_flush() (David) v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL (kbuild test robot) Cc: David Lechner <david@lechnology.com> Cc: Eric Anholt <eric@anholt.net> Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
David Lechner <david@lechnology.com> Reviewed-by:
-
Noralf Trønnes authored
This prepares for the switch to drm_atomic_helper_dirtyfb() in the next patch. The damage helper returns a drm_rect so switch to that everywhere including using a pointer in the dirty functions. This is a non-functional change except for the debug print which looks a bit different. Signed-off-by:
-
Noralf Trønnes authored
Useful for drivers that only care about the combined damage. v2: Remove unnecessary clearing of damage clips Cc: Deepak Rawat <drawat@vmware.com> Signed-off-by:
-
Noralf Trønnes authored
This adds a .fb_create helper that sets the .dirty callback to drm_atomic_helper_dirtyfb(). v2: Improve docs (Daniel) Signed-off-by:
-
Noralf Trønnes authored
CMA helper drivers have been converted to drm_fbdev_generic_setup() so the fbdev code can be removed. v3: Remove CMA specific conditional in the generic fbdev client v2: Clean up the includes some more (Laurent) Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114121059.20704-1-noralf@tronnes.org
-
Jonathan Corbet authored
The kerneldoc comment for struct dma_fence_array lacks a description of the "work" member, leading to this docs-build warning: ./include/linux/dma-fence-array.h:54: warning: Function parameter or member 'work' not described in 'dma_fence_array' Add a description and make the warning go away. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
- 16 Jan, 2019 2 commits
-
-
Sam Ravnborg authored
0-DAY reported the following bug: tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next head: 21376e2c commit: e9eafcb5 [1/2] drm: move drm_can_sleep() to drm_util.h config: alpha-allmodconfig (attached as .config) ... In file included from include/linux/irqflags.h:16:0, from include/drm/drm_util.h:35, from drivers/gpu/drm/qxl/qxl_cmd.c:28: >> arch/alpha/include/asm/irqflags.h:58:15: error: unknown type name 'bool' static inline bool arch_irqs_disabled_flags(unsigned long flags) ^~~~ And later following bug: tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next head: 21376e2c commit: e9eafcb5 [1/2] drm: move drm_can_sleep() to drm_util.h config: ia64-allyesconfig (attached as .config) ... In file included from arch/ia64/include/asm/irqflags.h:14, from include/linux/irqflags.h:16, from include/drm/drm_util.h:35, from drivers/gpu/drm/qxl/qxl_cmd.c:28: arch/ia64/include/asm/pal.h: In function 'ia64_pal_tr_read': arch/ia64/include/asm/pal.h:1703:64: error: implicit declaration of function 'ia64_tpa'; did you mean 'ia64_pal'? [-Werror=implicit-function-declaration] PAL_CALL_PHYS_STK(iprv, PAL_VM_TR_READ, reg_num, tr_type,(u64)ia64_tpa(tr_buffer)); ^~~~~~~~ ... So we have a situation where we do not pull in <linux/types.h> when building for alpha and for ia64 we need even more definitions are required. Two invasive fixes where considered: - Change all declarations of arch_irqs_disabled_flags() to use bool - Add include of <linux/types.h> to all files that uses bool for arch_irqs_disabled_flags To invasive with a too high pain/benefit ratio, so dropped. They would not cover ia64 either. Some less invasive fixes was also considered: - Add include of <linux/types.h> to drm_util.h - Add include of <linux/interrupt.h> to drm_util.h The first was dropped as this did not cover the ia64 case. The latter was considered the best option as there could be other similar cases and we would like the header files below include/drm/ to be selfcontained. So we end up pulling in a lot of stuff not needed, but this is the price we pay in drm/ because the kernel headers are not all selfcontained. While at it, ordred the includefiles in drm_util in alphabetical order. Build tested with alpha,ia64,arm,x86 with allmodconfig and allyesconfig. v2: - fix ia64 build, changed to include interrupt.h - sort include files alphabetically Fixes: 733748ac37b45 ("drm: move drm_can_sleep() to drm_util.h") Signed-off-by:
-
Thierry Reding authored
All other files in that directory have a .txt suffix, so add one for consistency. Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
- 15 Jan, 2019 8 commits
-
-
Lyude Paul authored
Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae147 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com
-
Daniel Vetter authored
It's a debug hack flag useful to work around driver bugs. That's not a good idea for a new driver. Especially for a new drm driver. Aside: the fbdev support should probably be converted over to the new generic fbdev support. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190115102755.16183-1-daniel.vetter@ffwll.ch
-
Rodrigo Siqueira authored
Add maintainers and reviewers for VKMS driver Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by:
-
Shayenne Moura authored
This patch finalizes the KMS cleanup task dependency from drm_display_mode. It removes the use of drm_mode_object from drm_display_mode struct and it removes the use of base.id and base.type from drm_display_mode struct print string. Signed-off-by:
Shayenne Moura <shayenneluzmoura@gmail.com> Reviewed-by:
-
Shayenne Moura authored
This patch removes the drm_mode_object prints, evaluation and use from drm_display_mode objects used in drm files. It removes dependency from drm_mode_object. Signed-off-by:
-
Shayenne Moura authored
This patch adjust the print string of drm_display_mode object to remove drm_mode_object dependency in armada files. Signed-off-by:
-
Mathieu Malaterre authored
There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warnings: include/linux/compiler.h:77:22: warning: this statement may fall through [-Wimplicit-fallthrough=] include/asm-generic/bug.h:134:2: note: in expansion of macro 'unlikely' drivers/gpu/drm/drm_dp_helper.c:155:3: note: in expansion of macro 'WARN' include/linux/compiler.h:77:22: warning: this statement may fall through [-Wimplicit-fallthrough=] include/asm-generic/bug.h:134:2: note: in expansion of macro 'unlikely' drivers/gpu/drm/drm_dp_helper.c:173:3: note: in expansion of macro 'WARN' drivers/gpu/drm/drm_dp_helper.c:547:3: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by:
Mathieu Malaterre <malat@debian.org> Acked-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Matteo Franchin authored
This commit adds definitions of format modifiers for version 1.3 of the Arm Framebuffer Compression (AFBC). Signed-off-by:
Matteo Franchin <matteo.franchin@arm.com> Signed-off-by:
Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by:
Brian Starkey <brian.starkey@arm.com> Link: https://patchwork.freedesktop.org/patch/277333/
-
- 14 Jan, 2019 4 commits
-
-
Ville Syrjälä authored
On i965gm we need to adjust max_vblank_count dynamically depending on whether the TV encoder is used or not. To that end add a per-crtc max_vblank_count that takes precedence over its device wide counterpart. The driver can now call drm_crtc_set_max_vblank_count() to configure the per-crtc value before calling drm_vblank_on(). Also looks like there was some discussion about exynos needing similar treatment. v2: Drop the extra max_vblank_count!=0 check for the WARN(last!=current), will take care of it in i915 code (Daniel) WARN_ON(!inmodeset) (Daniel) WARN_ON(dev->max_vblank_count) Pimp up the docs (Daniel) Cc: stable@vger.kernel.org Cc: Inki Dae <inki.dae@samsung.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: -
Maxime Jourdan authored
In case we are using simplefb or another conflicting framebuffer, make the call to drm_fb_helper_remove_conflicting_framebuffers() Signed-off-by:
Maxime Jourdan <mjourdan@baylibre.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Noralf Trønnes authored
The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. Cc: Marek Vasut <marex@denx.de> Signed-off-by:
-
Noralf Trønnes authored
The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. struct kirin_drm_private can be removed now that driver doesn't have to store the fbdev pointer. Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Signed-off-by:
-
