summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/sun4i/sun4i_backend.h
Commit message (Collapse)AuthorAgeFilesLines
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Thomas Gleixner2019-05-301-5/+1Star
| | | | | | | | | | | | | | | | | | | | | Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/sun4i: Pass modifier to backend and frontend format support helpersPaul Kocialkowski2018-11-271-1/+1
| | | | | | | | | | | | 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: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-33-paul.kocialkowski@bootlin.com
* drm/sun4i: backend: Add a helper and a list for supported formatsPaul Kocialkowski2018-11-271-0/+1
| | | | | | | | | | | | 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 <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-5-paul.kocialkowski@bootlin.com
* drm/sun4i: Cleanup video/YUV source before enabling a layerPaul Kocialkowski2018-11-271-0/+2
| | | | | | | | | | | | | | 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: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-2-paul.kocialkowski@bootlin.com
* drm/sun4i: sun4i: Introduce a quirk for lowest plane alpha supportPaul Kocialkowski2018-07-191-1/+0Star
| | | | | | | | | | | | | | | | | | Not all sunxi platforms with the first version of the Display Engine support an alpha component on the plane with the lowest z position (as in: lowest z-pos), that gets blended with the background color. In particular, the A13 is known to have this limitation. However, it was recently discovered that the A20 and A33 are capable of having alpha on their lowest plane. Thus, this introduces a specific quirk to indicate such support, per-platform. Since this was not tested on sun4i and sun6i platforms, a conservative approach is kept and this feature is not supported. 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/20180719080838.31598-2-paul.kocialkowski@bootlin.com
* drm/sun4i: sun4i: Register quirks with the backend structurePaul Kocialkowski2018-07-191-0/+2
| | | | | | | | | | In prevision for introducing a new quirk that will be used at atomic plane check time, register the quirks structure with the backend structure. This way, it can easily be grabbed where needed. 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/20180719080838.31598-1-paul.kocialkowski@bootlin.com
* drm/sun4i: Add support for plane alphaMaxime Ripard2018-04-161-0/+3
| | | | | | | | | | | | Our backend supports a per-plane alpha property. Support it through our new helper. Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/13e89f0d2f2b55752a22eb8c4f37f325246a3a9c.1523432341.git-series.maxime.ripard@bootlin.com
* drm/sun4i: backend: Support YUV planesMaxime Ripard2018-03-191-0/+17
| | | | | | | | | | | | | | | Now that we have the guarantee that we will have only a single YUV plane, actually support them. The way it works is not really straightforward, since we first need to enable the YUV mode in the plane that we want to setup, and then we have a few registers to setup the YUV buffer and parameters. We also need to setup the color correction to actually have something displayed. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/66088c1398bd3189123f28a89a7ccc669fe9f296.1519931807.git-series.maxime.ripard@bootlin.com
* drm/sun4i: backend: Check that we only have a single YUV planeMaxime Ripard2018-03-191-0/+1
| | | | | | | | | | | | Just like for the frontend, a single plane can use a YUV format. Make sure we have that constraint covered in our atomic_check. This is preliminary to the actual YUV support to make sure we don't end up in an impossible to support situation. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/2f8586493d9139b12efe7e94f65e9a149f818e0e.1519931807.git-series.maxime.ripard@bootlin.com
* drm/sun4i: backend: Check for the number of alpha planesMaxime Ripard2018-01-291-0/+2
| | | | | | | | | | | | | Due to the way the composition is done in hardware, we can only have a single alpha-enabled plane active at a time, placed in the second (highest priority) pipe. Make sure of that in our atomic_check to not end up in an impossible scenario. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/7371f62a1385f2cbe3ed75dfca2e746338eb2286.1516617243.git-series.maxime.ripard@free-electrons.com
* drm/sun4i: backend: Add support for zposMaxime Ripard2018-01-291-0/+2
| | | | | | | | | | | | | Our various planes have a configurable zpos, that combined with the pipes allow to configure the composition. Since the interaction between the pipes, zpos and alphas framebuffers is not trivial, let's just enable the zpos as an immutable property for now, and use that zpos in our atomic_update part. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/b006853e908bd06661c5bc1f2191121523bce0e4.1516617243.git-series.maxime.ripard@free-electrons.com
* drm/sun4i: backend: Fix define typoMaxime Ripard2018-01-291-1/+3
| | | | | | | | | There was a typo in the width spelling of the (unused) SUN4I_BACKEND_IYUVLINEWITDTH_REG macro. Fix it. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/6b2e872b611b733a98a38902a2197b70c725e0b9.1516617243.git-series.maxime.ripard@free-electrons.com
* drm/sun4i: backend: Add a custom atomic_check for the frontendMaxime Ripard2018-01-221-0/+2
| | | | | | | | | | | | | | | | | | Now that we have everything in place, we can start enabling the frontend. This is more difficult than one would assume since there can only be one plane using the frontend per-backend. We therefore need to make sure that the userspace will not try to setup multiple planes using it, since that would be impossible. In order to prevent that, we can create an atomic_check callback that will check that only one plane will effectively make use of the frontend in a given configuration, and will toggle the switch in that plane state so that the proper setup function can do their role. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/278e6c514a8311750fe627c7f28d58b3e2cbd825.1516613040.git-series.maxime.ripard@free-electrons.com
* drm/sun4i: backend: Wire in the frontendMaxime Ripard2018-01-221-0/+8
| | | | | | | | | | | | | | | | Now that we have a driver, we can make use of it. This is done by adding a flag to our custom plane state that will trigger whether we should use the frontend on that particular plane or not. The rest is just plumbing to set up the backend to not perform the DMA but receive its data from the frontend. Note that we're still not making any use of the frontend itself, as no one is setting the flag yet. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/cdffc25eab2d817820cc78cbd24f1f4b99902014.1516613040.git-series.maxime.ripard@free-electrons.com
* drm/sun4i: backend: Support output muxingChen-Yu Tsai2017-10-171-1/+2
| | | | | | | | | | | | | | | | | | | | The backend has a mux to select the destination of the data to output to. It can select the TCON or the frontends. On the A20, it includes an option to output to the second TCON. This is not documented in the user manual, but the vendor kernel uses it nevertheless, so the second backend outputs to the second TCON. Although the muxing can be changed on the fly, DRM needs to be able to group a bunch of layers such that they get switched to another crtc together. This is because the display backend does the layer compositing, while the TCON generates the display timings. This constraint is not supported by DRM. Here we simply pair up backends and TCONs with the same ID. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-2-wens@csie.org
* drm/sun4i: abstract a engine typeIcenowy Zheng2017-06-011-11/+8Star
| | | | | | | | | | | | | | | | | | | As we are going to add support for the Allwinner DE2 engine in sun4i-drm driver, we will finally have two types of display engines -- the DE1 backend and the DE2 mixer. They both do some display blending and feed graphics data to TCON, and is part of the "Display Engine" called by Allwinner, so I choose to call them both "engine" here. Abstract the engine type to a new struct with an ops struct, which contains functions that should be called outside the engine-specified code (in TCON, CRTC or TV Encoder code). In order to preserve bisectability, we also switch the backend and layer code in its own module. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: backend: Save pointer to device tree nodeChen-Yu Tsai2017-05-141-0/+2
| | | | | | | | | Save a pointer to the backend's underlying device tree node in its data structure. This will be used later for downstream tcons to find and match their respective upstream backends. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: backend: Fetch backend ID from device treeChen-Yu Tsai2017-05-141-0/+2
| | | | | | | | | | | | | | | | | Some Allwinner SoCs have 2 display pipelines, as in 2 of each components, including the frontend, backend, TCON, and any other extras. As the backend and TCON are always paired together and form the CRTC, we need to know which backend or TCON we are currently probing, so we can pair them when initializing the CRTC. This patch figures out the backend's ID from the device tree and stores it in the backend's data structure. It does this by looking at the "reg" property of any remote endpoints connected to the backend's input port. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: Use lists to track registered display backends and TCONsChen-Yu Tsai2017-05-141-0/+4
| | | | | | | | | | | | To support multiple display pipelines, we need to keep track of the multiple display backends and TCONs registered with the driver. Switch to lists to track registered components. Components are only appended to their respective lists if the bind process was successful. The TCON bind function now defers if a backend was not registered. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: Fix the high buffer address maskMaxime Ripard2016-09-221-2/+2
| | | | | | | | | | | The highest 3bits of the 4 layers buffers are all part of the same register. However, our mask computation was wrong, leading to all the lowest register bits being removed when we use regmap_update_bits, which will lead to the buffers being set to some random part of the RAM. Fix our mask. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: backend: Handle the SATMaxime Ripard2016-09-081-0/+3
| | | | | | | | | | | The A33 has an block called SAT that is part of the backend that needs to be clocked and out of reset to be able for the backend to operate properly. Extend the binding to have the SAT resources listed, and claim them when the backend probes. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org>
* drm: Add Allwinner A10 Display Engine supportMaxime Ripard2016-04-281-0/+165
The Allwinner A10 and subsequent SoCs share the same display pipeline, with variations in the number of controllers (1 or 2), or the presence or not of some output (HDMI, TV, VGA) or not. Add a driver with a limited set of features for now, and we will hopefully support all of them eventually Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>