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: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478971198-3659-1-git-send-email-Julia.Lawall@lip6.fr

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: NMaxime 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: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NMaxime 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: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NChen-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: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NChen-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: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMaxime 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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>