Commit Graph

510 Commits

Author SHA1 Message Date
Maxime Ripard
bb43d40d7c drm/sun4i: rgb: Validate the clock rate
Our pixel clock cannot reach a high enough rate for some rather high while
common resolutions (like 1080p60).

Make sure we filter the resolutions we cannot reach in our mode_valid
function.

Fixes: 29e57fab97 ("drm: sun4i: Add RGB output")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30 08:28:33 +02:00
Maxime Ripard
4731a72df2 drm/sun4i: request exact rates to our parents
Our pixel clock currently only tries to deal with the current parent rate.

While that works when the resolution is the same than the one already
program, or when we can compute directly the rate from the current parent
rate, it cannot work in most situation when we want to change the
frequency, and we end up with an improper pixel clock rate, which obviously
doesn't work as expected.

Ask our parent for all the possible dividers if it can reach that
frequency, and return the best parent rate to the clock framework so that
we can use it.

Fixes: 9026e0d122 ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30 08:28:33 +02:00
Arnd Bergmann
9fa2568d9f drm: sun4i: fix probe error handling
gcc points out a possible uninitialized variable use in
sun4i_dclk_create():

drivers/gpu/drm/sun4i/sun4i_dotclock.c: In function 'sun4i_dclk_create':
drivers/gpu/drm/sun4i/sun4i_dotclock.c:139:12: error: 'clk_name' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  init.name = clk_name;

The warning only shows up when CONFIG_OF is disabled, and the
property is never filled, but the same bug can show up even
when CONFIG_OF is enabled but of_property_read_string_index
returns another error.

To fix it, this ensures that sun4i_dclk_create propagates
any error from of_property_read_string_index.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 9026e0d122 ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30 08:28:33 +02:00
Arnd Bergmann
f1b78f0e75 drm: sun4i: print DMA address correctly
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>
2016-05-30 08:28:33 +02:00
Arnd Bergmann
bebef39842 drm/sun4i: add COMMON_CLK dependency
The sun4i drm driver uses the clk-provider interfaces, which are not available
when CONFIG_COMMON_CLK is disabled:

drivers/gpu/drm/sun4i/sun4i_dotclock.c:19:16: error: field 'hw' has incomplete type
  struct clk_hw hw;
In file included from ../include/asm-generic/bug.h:13:0,
                 from ../arch/arm/include/asm/bug.h:59,
                 from ../include/linux/bug.h:4,
                 from ../include/linux/io.h:23,
                 from ../include/linux/clk-provider.h:14,
                 from ../drivers/gpu/drm/sun4i/sun4i_dotclock.c:13:
drivers/gpu/drm/sun4i/sun4i_dotclock.c: In function 'hw_to_dclk':
include/linux/kernel.h:831:48: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
...

This adds a Kconfig dependency to prevent the driver from being enabled
in this case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 9026e0d122 ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-05-30 08:28:33 +02:00
Maxime Ripard
2ff77b1659 drm: sun4i: tv: Add NTSC output standard
Add the settings to support the NTSC standard.

Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-04-28 10:30:05 +02:00
Maxime Ripard
154f695007 drm: sun4i: tv: Add PAL output standard
Now that we have support for the composite output, we can start adding new
supported standards. Start with PAL, and we will add other eventually.

Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-04-28 10:30:05 +02:00
Maxime Ripard
03c4c71d25 drm: sun4i: Add composite output
Some Allwinner SoCs have an IP called the TV encoder that is used to output
composite and VGA signals. In such a case, we need to use the second TCON
channel.

Add support for that TV encoder.

Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-04-28 10:30:05 +02:00
Maxime Ripard
29e57fab97 drm: sun4i: Add RGB output
One of the A10 display pipeline possible output is an RGB interface to
drive LCD panels directly. This is done through the first channel of the
TCON that will output our video signals directly.

Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2016-04-28 10:30:05 +02:00
Maxime Ripard
9026e0d122 drm: Add Allwinner A10 Display Engine support
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>
2016-04-28 10:30:05 +02:00