| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Now that we have everything in place, we can make zpos configurable now.
Change the zpos property from an immutable one to a regular.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0ab187956855db86972d936e6751181649e0d035.1518802627.git-series.maxime.ripard@bootlin.com
|
|
The plane description structure was mostly needed to differentiate the
formats usable on the primary plane (because of its lowest position), and
assign the pipes. Now that both are dynamically checked and assigned, we
can remove the static definition.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6b09e3698e692c3338f70a5ae1e5a580f9dd08ee.1518802627.git-series.maxime.ripard@bootlin.com
|
|
Since we now have a way to enforce the zpos, check for the number of alpha
planes, the only missing part is to assign our pipe automatically instead
of hardcoding it.
The algorithm is quite simple, but requires two iterations over the list of
planes.
In the first one (which is the same one that we've had to check for alpha,
the frontend usage, and so on), we order the planes by their zpos.
We can then do a second iteration over that array by ascending zpos
starting with the pipe 0. When and if we encounter our alpha plane, we put
it and all the other subsequent planes in the second pipe.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e9caf21d831438d36a3ccc7cef229c9a7ea7f69f.1518802627.git-series.maxime.ripard@bootlin.com
|
|
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
|
|
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
|
|
The plane state zpos value will be set only if there's an existing state
attached to the plane when creating the property.
However, this is not the case during the probe, and we therefore need to
put our default value in our reset hook.
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/b6a183234f0ad5a9a58c780c9cabbe29cbf40888.1516617243.git-series.maxime.ripard@free-electrons.com
|
|
The function supposed to update a plane's coordinates is called in both
branches of our function. Let's move it out the if statement.
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/2cd57bcf13652109da7bd5bbe12fa1d29429f02f.1516617243.git-series.maxime.ripard@free-electrons.com
|
|
The sun4i_plane_desc structure was somehow indented to two tabulations
instead of one as we shoud do. Fix that.
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/8a6714bddb865adfcfe2b792e406a2f10bb819bc.1516617243.git-series.maxime.ripard@free-electrons.com
|
|
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
|
|
We will need to store some additional data in the future to the state.
Create a custom plane state that will embed those data, in order to store
the pipe or whether or not that plane should use the frontend.
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/88dd9c2b0caa550595e7b2ff37dc9d0af2c78609.1516613040.git-series.maxime.ripard@free-electrons.com
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-next
Allwinner DRM changes for 4.14
A few changes, but most notably improving the HDMI support merged in 4.13,
by reporting the DDC adapter as an i2c bus, and by adding CEC support
through the CEC framework.
* tag 'sunxi-drm-for-4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
sun4i_hdmi: add CEC support
dt-bindings: display: sunxi: Improve endpoint ID scheme readability
drm/sun4i: tcon: remove unused function
drm/sun4i: Remove useless atomic_check
drm/sun4i: Add if statement instead of depends on
drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus
drm/sun4i: constify drm_plane_helper_funcs
|
|
This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.
This patch simply allows the DRM drivers to initialize their list of
supported modifiers upon initializing the plane.
v2: A minor addition from Daniel
v3:
* Updated commit message
* s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
* Remove some excess newlines (Liviu)
* Update comment for > 64 modifiers (Liviu)
v4: Minor comment adjustments (Liviu)
v5: Some new platforms added due to rebase
v6: Add some missed plane inits (or maybe they're new - who knows at
this point) (Daniel)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Daniel Stone <daniels@collabora.com> (v2)
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
|
|
The atomic_check callback is optional, and we don't implement anything in
some parts of our drivers. Let's remove it.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
drm_plane_helper_funcs are not supposed to change at runtime.
All functions working with drm_plane_helper_funcs provided by
<drm/drm_plane_helper.h> work with const drm_plane_helper_funcs.
So mark the non-const structs as const.
File size before:
text data bss dec hex filename
981 40 0 1021 3fd drivers/gpu/drm/sun4i/sun4i_layer.o
File size After adding 'const':
text data bss dec hex filename
1021 0 0 1021 3fd drivers/gpu/drm/sun4i/sun4i_layer.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
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>
|
|
As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
driver, we will finally have two types of layers.
Each layer is bound to a drm_plane that is CRTC-specific, so we create
them when initializing CRTC (calling sun4i_layers_init, which will be
generalized in next patch). The drm_plane's will be used when creating
CRTC, but the CRTC initialization code do not care other properties of
the layer, so we let the sun4i_layers_init function return drm_plane's
only.
As we have no need to trace the layers after the CRTC is properly
created, we drop the layers pointer in sun4i_crtc struct.
Doing this uncouples the CRTC code from the type of layer (the
sun4i_layers_init function name is still hardcoded and will be changed
in the next patch), so that we can finally gain support for the
mixer in DE2, which has different layers.
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>
|
|
sun4i_layer only controls the backend hardware block of the display
pipeline.
Pass pointers to the underlying backend in the layer init function,
instead of trying to fetch it from the drm_device structure. This
avoids the headache of trying to figure out which device the layers
actually belong to.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
sun4i_layer only controls the backend hardware block of the display
pipeline. Instead of getting a pointer to the underlying backend
through the drm_device structure, leave one in itself.
Also drop the drm_device pointer, since it is no longer needed.
The next step forward would be to pass the pointer in through
sun4i_layers_init as a parameter. This would make it easier to support
multiple display pipelines layer on.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
To support multiple display pipelines, we would have multiple crtcs,
with one or more planes bound to them. Obviously having hardcoded
values for the drm_plane .possible_crtcs field is not going to work.
For primary and cursor planes, the value is set by
drm_crtc_init_with_planes. We just need to set it for overlay planes.
We also fix the value set for the RGB encoder, by referencing the
crtc set in sun4i_drv.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
The current layer init code keeps a pointer to the primary plane layer
in sun4i_drv. When we eventually support multiple display pipelines,
this would force us to keep track of primary planes for all crtcs. And
these pointers only get used at bind time.
Instead, have the crtc init code iterate through the returned layers
to find the primary and cursor layers. And drop the pointer from the
sun4i_drv structure.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
The number of defined planes in sun4i_layer is unknown to other parts
of the sun4i drm driver. Since the return value of sun4i_layers_init
is a list of layers, make it return 1 more empty layer as an end of
list guard value.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
sun4i_layers_init allocates an array to store pointers to newly created
layers returned by sun4i_layer_init_one(), but fails to actually store
them. But it actually returns the empty array to unsuspecting users.
Save the pointers in the array, so that they may be used later.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
The assignment found in the main loop in sun4i_layers_init:
struct sun4i_layer *layer = layers[i];
is useless as it gets overwritten by the next line:
layer = sun4i_layer_init_one(drm, plane);
Drop the assignment.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
In sun4i_layers_init we are allocating an array of pointers to struct
sun4i_layer:
layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes),
sizeof(**layers), GFP_KERNEL);
The element size should be the size of an individual element of the
array. Change it to sizeof(*layers) to avoid wasting a lot of memory.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
The planes can do more than what was previously exposed. Add support for
them.
Since we still have the issue that the primary plane cannot have any alpha
component, we will expose only the non-alpha formats in the primary
formats, and the alpha formats will be exposed in the overlays.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
|
|
Even though all our planes can support the ARGB formats, the lowest plane
(ie the primary plane) cannot use the alpha component, otherwise it will
just result in the transparent area being entirely black.
Since some applications will still require the ARGB format, let's force the
format to XRGB to drop the alpha component entirely.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
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>
|
