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
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
The function converting the DRM format to its equivalent in the backend
registers was assuming that we were having a plane.
However, we might want to use that function when setting up a plane using
the frontend, in which case we will not have a plane associated to the
backend's layer. Yet, we still need to setup the format to the one output
by the frontend.
Test for NULL plane pointers before referencing them, so that we can work
around it.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bfbe4c2e8525a7542526b648d59a8f3546e905f1.1516613040.git-series.maxime.ripard@free-electrons.com
The A20 display pipeline has 2 frontends, 2 backends, and 2 TCONs.
This patch adds support (or a compatible string in the frontend's
case) for these components.
The TCONs support directly outputting to CPU/RGB/LVDS LCD panels,
or it can output to HDMI via an on-chip HDMI controller, or
CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional
encoders are not covered in this patch.
Signed-off-by: Jonathan Liu <net147@gmail.com>
[wens@csie.org: Expand commit message]
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-6-wens@csie.org
The A10 display pipeline has 2 frontends, 2 backends, and 2 TCONs.
This patch adds support (or a compatible string in the frontend's
case) for these components.
The TCONs support directly outputting to CPU/RGB/LVDS LCD panels,
or it can output to HDMI via an on-chip HDMI controller, or
CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional
encoders are not covered in this patch.
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-5-wens@csie.org
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
The display backend, as well as other peripherals that have a DRAM
clock gate and access DRAM directly, bypassing the system bus,
address the DRAM starting from 0x0, while physical addresses the
system uses starts from 0x40000000 (or 0x20000000 in A80's case).
This issue was witnessed on the Cubietruck, which has 2GB of RAM.
Devices with less RAM function normally due to the DRAM address
wrapping around. CMA seems to always allocate its buffer at a
very high address, close to the end of DRAM.
On a 1GB RAM device, the physical address would be something like
0x78000000. The DRAM address 0x78000000 would access the same DRAM
region as 0x38000000 on a system, as the DRAM address would only
span 0x0 ~ 0x3fffffff. The bit 0x40000000 is non-functional in this
case.
However on the Cubietruck, the DRAM is 2GB. The physical address
is 0x40000000 ~ 0xbfffffff. The buffer would be something like
0xb8000000. But the DRAM address span 0x0 ~ 0x7fffffff, meaning
the buffer address wraps around to 0x38000000, which is wrong.
The correct DRAM address for it should be 0x78000000.
Correct the address configured into the backend layer registers
by PHYS_OFFSET to account for this.
Fixes: 9026e0d122 ("drm: Add Allwinner A10 Display Engine support")
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/20171017042349.31743-6-wens@csie.org
Many of the backend's layer configuration registers have undefined
default values. This poses a risk as we use regmap_update_bits in
some places, and don't overwrite the whole register.
At probe/bind time we explicitly clear all the control registers
by writing 0 to them. This patch adds a more detailed explanation
on why we're doing this.
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/20171014040252.9621-5-wens@csie.org
Commit 4636ce93d5 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
adds a new helper, which covers fetching a drm_framebuffer's GEM object
and calculating the buffer address for a given plane.
This patch uses this helper to replace our own open coded version of the
same function.
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/20171014040252.9621-4-wens@csie.org
The backend has various clocks and reset controls that need to be
enabled and deasserted before register access is possible.
Move the creation of the regmap to after the clocks and reset controls
have been configured where it makes more sense.
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/20171014040252.9621-3-wens@csie.org
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.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>
sun4i_backend_layer_enable can be called to enable or disable a layer.
However the debug message always says "Enable", which is confusing.
This patch makes the debug message vary according to the enable state.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
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>
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>
Now that we support multiple instances of backends, the trailing 0
implying only one backend no longer makes sense.
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 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>
sunxi_rgb2yuv_coef is a table of RGB-to-YUV conversion coefficients.
They are programmed into the hardware, and can be declared constant.
Reported-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Just one minor fix.
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJYkFQBAAoJEBx+YmzsjxAgcP4QAKbh9vgqcucnnX5kG6K6oH98
ZXrooKYHOcVghUqoMS1tgOCCWKsRrId41rX4kxhSMEEyMQgwt0MMAr1gexNE+n5R
UNQDZ0cAjaIo9Mf2Ivwz3KO2k1k2kU5Q2vJlcUdHYHOgRPt35NRgznWayFXMiksN
SbGYNdaoTeCOoUTL9gNATipUIIsLWBYKW8M7eCn2/0LzAr24KLh3l5hfQVdPEvBs
H80IxRlDN0olPOuy3MRqVlVG92kHhBgTOomJRgGyecsUP8vxOWriha5yfMVb2EwM
jjUz//WJkKoAnQb2CcgEPPTV2DOHvajkaoUI+abB/dpPAepi/W3pVVsD9uSMiBgY
IFY1PmD/lAg6CbJfy13qB9vzzt1Huho1XdwFJLnKq8s3PuRIr9oIlPEzDKXkBZml
wbDAgnThU8lW2nhOvHNp0qtIwD0yparBOOyCcn5wjCqUOPLlgvAYloiNcadGxDuv
PTmJcZVJwdW4Fu0lB53S3BpkfK0hUg7+Om4oclTM5MkfyheINFTKRzcUDUw4Hmx5
ekGiL52tlxeBY+DIXVLxCbfjMGIR9+On0obuwSTRKj2KzhI1Ias/WIzjJYGgzjWF
tB4D3SqkecoC+uetSx7ClypZPKSUvVCGEDt775e6Q2eLEBoVajymiHGtTrh5Jg6Y
eQDvde29f76IJu+0a5MC
=SSQZ
-----END PGP SIGNATURE-----
Merge tag 'sunxi-drm-for-4.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-next
Allwinner DRM changes for 4.11
Just one minor fix.
* tag 'sunxi-drm-for-4.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
drm/sun4i: Fix a return value in case of error
If 'sun4i_backend_drm_format_to_layer()' does not return 0, then 'val' is
left unmodified.
As it is not initialized either, the return value can be anything.
It is likely that returning the error code was expected here.
As the only caller of 'sun4i_backend_update_layer_formats()' does not check
the return value, this fix is purely theorical.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Another pile of misc:
- Explicit fencing for atomic! Big thanks to Gustavo, Sean, Rob 3x, Brian
and anyone else I've forgotten to make this happen.
- roll out fbdev helper ops to drivers (Stefan Christ)
- last bits of drm_crtc split-up&kerneldoc
- some drm_irq.c crtc functions cleanup
- prepare_fb helper for cma, works correctly with explicit fencing (Marek
Vasut)
- misc small patches all over
* tag 'drm-misc-next-2016-11-16' of git://anongit.freedesktop.org/git/drm-misc: (51 commits)
drm/fence: add out-fences support
drm/fence: add fence timeline to drm_crtc
drm/fence: add in-fences support
drm/bridge: analogix_dp: return error if transfer none byte
drm: drm_irq.h header cleanup
drm/irq: Unexport drm_vblank_on/off
drm/irq: Unexport drm_vblank_count
drm/irq: Make drm_vblank_pre/post_modeset internal
drm/nouveau: Use drm_crtc_vblank_off/on
drm/amdgpu: Use drm_crtc_vblank_on/off for dce6
drm/color: document NULL values and default settings better
drm: Drop externs from drm_crtc.h
drm: Move tile group code into drm_connector.c
drm: Extract drm_mode_config.[hc]
Revert "drm: Add aspect ratio parsing in DRM layer"
Revert "drm: Add and handle new aspect ratios in DRM layer"
drm/print: Move kerneldoc next to definition
drm: Consolidate dumb buffer docs
drm: Clean up kerneldoc for struct drm_driver
drm: Extract drm_drv.h
...
These component_ops structures are only used as the second argument to
component_add and component_del, which are declared as const, so the
structures can be declared as const as well.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct component_ops i@p = { ... };
@ok1@
identifier r.i;
expression e1;
position p;
@@
component_add(e1,&i@p)
@ok2@
identifier r.i;
expression e1;
position p;
@@
component_del(e1, &i@p)
@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct component_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct component_ops i = { ... };
// </smpl>
The result of the size command before the change is (arm):
text data bss dec hex filename
5266 236 8 5510 1586 sun4i_backend.o
6393 236 8 6637 19ed sun4i_tcon.o
3700 368 8 4076 fec sun4i_tv.o
1668 108 0 1776 6f0 sun6i_drc.o
and after the change:
text data bss dec hex filename
5274 228 8 5510 1586 sun4i_backend.o
6401 228 8 6637 19ed sun4i_tcon.o
3708 360 8 4076 fec sun4i_tv.o
1676 100 0 1776 6f0 sun6i_drc.o
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478971198-3659-1-git-send-email-Julia.Lawall@lip6.fr
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>
The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It
also has new display enhancement blocks, such as the DRC (Dynamic Range
Controller), the DEU (Display Enhancement Unit), and the CMU (Color
Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels.
The A31s display pipeline is almost the same, just without MIPI DSI.
Only the TCON seems to be different, due to the missing mux for MIPI
DSI.
Add compatible strings for both of them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
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>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
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>
The A33 has a significantly different pipeline, with components that differ
too.
Make sure we had compatible for them.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
The newly added sun4i drm driver prints a dma address using the %x
format string, which cannot work when dma_addr_t is 64 bit,
and gcc warns about this configuration:
drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_update_layer_buffer':
drm/sun4i/sun4i_backend.c:193:84: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr);
drm/sun4i/sun4i_backend.c:201:84: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr);
This changes the code to use the explicit %pad format string, which
always prints the right length.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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>
Maxime Ripard