Re: [PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[Christopher James Halse Rogers]

On 10 April 2017 6:51:21 pm AEST, "Michel Dänzer"  wrote:
>On 06/04/17 04:47 PM, Christopher James Halse Rogers wrote:
>> On Wed, 5 Apr 2017 at 20:14 Lucas Stach > > wrote:
>> 
>> Am Mittwoch, den 05.04.2017, 11:59 +0200 schrieb Daniel Vetter:
>> > On Wed, Apr 05, 2017 at 10:15:44AM +0200, Lucas Stach wrote:
>> > > Am Mittwoch, den 05.04.2017, 00:20 + schrieb Christopher
>> James Halse
>> > > Rogers:
>> > > >
>> > > >
>> > > > On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter
>> > wrote:
>> > > >
>> > > > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
>> > > > > > wrote:
>> > > > >> If I could guarantee that I'd only ever run on
>> > > > 4.13-or-later kernels
>> > > > >> (I think that's when the previous patches will
>> land?), then
>> > > > this would
>> > > > >> indeed be mostly unnecessary. It would save me a
>> bunch of
>> > > > addfb calls
>> > > > >> that would predictably fail, but they're cheap.
>> > > > >
>> > > > > I don't think we ever had caps for "things are
>> working now,
>> > > > as they are
>> > > > > supposed to". i915 wasn't properly synchronizing
>on
>> foreign
>> > > > fences for a
>> > > > > long time, yet we didn't gain a cap for "cross
>> device sync
>> > > > works now".
>> > > > >
>> > > > > If your distro use-case relies on those things
>> working it's
>> > > > probably
>> > > > > best to just backport the relevant fixes.
>> > > >
>> > > > The even better solution for this is to push the
>backports
>> > > > through
>> > > > upstream -stable kernels. This stuff here is simple
>enough
>> > > > that we can
>> > > > do it. Same could have been done for the fairly
>minimal
>> > > > fencing fixes
>> > > > for i915 (at least some of them, the ones in the
>> page-flip).
>> > > >
>> > > > Otherwise we'll end up with tons IM_NOT_BUGGY and
>> > > > IM_SLIGHTLY_LESS_BUGGY and
>> > > > IM_NOT_BUGGY_EXCEPT_THIS_BOTCHED_BACKPORT
>> > > > flags where no one at all knows what they mean,
>usage
>> between
>> > > > different drivers and different userspace is
>entirely
>> > > > inconsistent and
>> > > > they just all add to the confusion. They're just
>bugs,
>> lets
>> > > > treat them
>> > > > like that.
>> > > >
>> > > >
>> > > > It's not *quite* DRM_CAP_PRIME_SCANOUT_NOT_BUGGY - while
>the
>> relevant
>> > > > hardware allegedly supports it, nouveau/radeon/amdgpu don't
>do
>> scanout
>> > > > of GTT, so the lack of this cap indicates that there's no
>point in
>> > > > trying to call addfb2.
>> > > >
>> > > >
>> > > > But calling addfb2 and it failing is not expensive, so this
>is
>> rather
>> > > > niche.
>> > > >
>> > > >
>> > > > In practice I can just restrict attempting to scanout of
>imported
>> > > > buffers to i915, as that's the only driver that it'll work
>on.
>> By the
>> > > > time nouveau/radeon/amdgpu get patches to scanout of GTT
>the fixes
>> > > > should be old enough that I don't need to care about
>unfixed
>> kernels.
>> > > >
>> > > So given that most discreet hardware won't ever be able to
>> scanout from
>> > > GTT (latency and iso requirements will be hard to meet),
>can't
>> we just
>> > > fix the case of the broken prime sharing when migrating to
>VRAM?
>> > >
>> > > I'm thinking about attaching an exclusive fence to the
>dma-buf
>> when the
>> > > migration to VRAM happens, then when the GPU is done with the
>> buffer we
>> > > can either write back any changes to GTT, or just drop the
>fence
>> in case
>> > > the GPU didn't modify the buffer.
>> >
>> > We could, but someone needs to type the code for it. There's
>also the
>> > problem that you need to migrate back, and then doing all that
>behind
>> > userspaces back might not be the best idea.
>> 
>> Drivers with separate VRAM and GTT are already doing a lot of
>migration
>> behind the userspaces back. The only issue with dma-buf migration
>to
>> VRAM is that you probably don't want to migrate the pages, but
>duplicate
>> them in VRAM, doubling memory consumption with possible OOM. But
>then
>> you could alloc the memory on addfb where you are able to return
>proper
>> errors.
>> 
>> 
>> Hm. So, on a first inspection, this looks like something I could
>> actually 

[Bug 100687] KWin won't draw Aurorae themes under EGL

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100687

--- Comment #5 from MirceaKitsune  ---
(In reply to Michel Dänzer from comment #4)

I temporarily set KWin back to egl and added the following to my ~./profile
file:

export LIBGL_DRI3_DISABLE=1

This did not affect the problem: Window decorations are still completely
invisible, when using egl over glx for rendering.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 01/11] dt-bindings: add binding for the Allwinner DE2 CCU

[Icenowy Zheng]

Allwinner "Display Engine 2.0" contains some clock controls in it.

In order to add them as clock drivers, we need a device tree binding.
Add the binding here.

Signed-off-by: Icenowy Zheng 
---
Changes in v4:
- Dropped the leading 0 in clock@100 .
Changes in v3:
- Fill the address space length of DE2 CCU to 0x10, just reach the start of 
mixer0.

 .../devicetree/bindings/clock/sun8i-de2.txt| 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt

diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt 
b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
new file mode 100644
index ..15a60bd7dcf3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
@@ -0,0 +1,31 @@
+Allwinner Display Engine 2.0 Clock Control Binding
+--
+
+Required properties :
+- compatible: must contain one of the following compatibles:
+   - "allwinner,sun8i-a83t-de2-clk"
+   - "allwinner,sun50i-a64-de2-clk"
+   - "allwinner,sun50i-h5-de2-clk"
+
+- reg: Must contain the registers base address and length
+- clocks: phandle to the clocks feeding the display engine subsystem.
+ Three are needed:
+  - "mod": the display engine module clock
+  - "bus": the bus clock for the whole display engine subsystem
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset control for the display engine subsystem.
+- #clock-cells : must contain 1
+- #reset-cells : must contain 1
+
+Example:
+de2_clocks: clock@100 {
+   compatible = "allwinner,sun50i-a64-de2-clk";
+   reg = <0x0100 0x10>;
+   clocks = < CLK_DE>,
+< CLK_BUS_DE>;
+   clock-names = "mod",
+ "bus";
+   resets = < RST_BUS_DE>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+};
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 09/11] ARM: dts: sun8i: add DE2 nodes for V3s SoC

[Icenowy Zheng]

Allwinner V3s SoC features a "Display Engine 2.0" with only one TCON
which have RGB LCD output.

Add device nodes for it as well as the TCON.

Signed-off-by: Icenowy Zheng 
---
Changes in v4:
- Dropped leading 0's in unit name.
Changes in v3:
- Change the size of de2_clocks regs according to the binding example.

 arch/arm/boot/dts/sun8i-v3s.dtsi | 87 
 1 file changed, 87 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 71075969e5e6..ae23746731a8 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -41,6 +41,10 @@
  */
 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 / {
#address-cells = <1>;
@@ -59,6 +63,12 @@
};
};
 
+   de: display-engine {
+   compatible = "allwinner,sun8i-v3s-display-engine";
+   allwinner,pipelines = <_mixer0>;
+   status = "disabled";
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -93,6 +103,83 @@
#size-cells = <1>;
ranges;
 
+   de2_clocks: clock@100 {
+   compatible = "allwinner,sun50i-h5-de2-clk";
+   reg = <0x0100 0x10>;
+   clocks = < CLK_DE>,
+< CLK_BUS_DE>;
+   clock-names = "mod",
+ "bus";
+   resets = < RST_BUS_DE>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   de2_mixer0: mixer@110 {
+   compatible = "allwinner,sun8i-v3s-de2-mixer";
+   reg = <0x0110 0x10>;
+   clocks = <_clocks CLK_MIXER0>,
+<_clocks CLK_BUS_MIXER0>;
+   clock-names = "mod",
+ "bus";
+   resets = <_clocks RST_MIXER0>;
+   assigned-clocks = <_clocks CLK_MIXER0>;
+   assigned-clock-rates = <15000>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mixer0_out_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_in_mixer0>;
+   };
+   };
+   };
+   };
+
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun8i-v3s-tcon";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_TCON0>,
+< CLK_TCON0>;
+   clock-names = "ahb",
+ "tcon-ch0";
+   clock-output-names = "tcon-pixel-clock";
+   resets = < RST_BUS_TCON0>;
+   reset-names = "lcd";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon0_in_mixer0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

[Logan Gunthorpe]

Thanks for the information Milan.

On 15/04/17 06:10 AM, Milan Broz wrote:
> I think your patch is ok (if it is just plain conversion), if it is
> really needed, we can switch to ahash later in follow-up patch.

Sounds good to me.

> p.s.
> there is a lot of lists on cc, but for this patch is missing dm-devel, 
> dmcrypt changes
> need to go through Mike's tree (I added dm-devel to cc:)

Oh, sorry, I thought I had included all the lists. My hope however would
be to get the first patch merged and then re-send the remaining patches
to their respective maintainers. So that would have happened later. It's
hard to manage patches otherwise with such large distribution lists.

Logan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 10/11] ARM: dts: sun8i: add pinmux for LCD pins of V3s SoC

[Icenowy Zheng]

Allwinner V3s SoC features a set of pins that have functionality of RGB
LCD, the pins are at different pin ban than other SoCs.

Add pinctrl node for them.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index ae23746731a8..ac783a8a4fd3 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -297,6 +297,15 @@
function = "i2c0";
};
 
+   lcd_rgb666_pins: lcd_rgb666@0 {
+   pins = "PE0", "PE1", "PE2", "PE3", "PE4",
+  "PE5", "PE6", "PE7", "PE8", "PE9",
+  "PE10", "PE11", "PE12", "PE13", "PE14",
+  "PE15", "PE16", "PE17", "PE18", "PE19",
+  "PE23", "PE24";
+   function = "lcd";
+   };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 04/11] drm/sun4i: return only planes for layers created

[Icenowy Zheng]

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 these things makes the CRTC code independent to 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 will has different layers.

Signed-off-by: Icenowy Zheng 
---
Big refactor of "drm/sun4i: abstract the layer type" in v3.

The layer_ops and sunxi_layer.h are dropped, and the univeral type used
to represent layers(planes) is now directly drm_plane.

 drivers/gpu/drm/sun4i/sun4i_crtc.c  | 23 ---
 drivers/gpu/drm/sun4i/sun4i_crtc.h  |  1 -
 drivers/gpu/drm/sun4i/sun4i_layer.c | 18 ++
 drivers/gpu/drm/sun4i/sun4i_layer.h |  4 ++--
 4 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c 
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 3c876c3a356a..708b3543d4e9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -139,6 +139,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
   struct sun4i_tcon *tcon)
 {
struct sun4i_crtc *scrtc;
+   struct drm_plane **planes;
struct drm_plane *primary = NULL, *cursor = NULL;
int ret, i;
 
@@ -149,22 +150,22 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
scrtc->tcon = tcon;
 
/* Create our layers */
-   scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
-   if (IS_ERR(scrtc->layers)) {
+   planes = sun4i_layers_init(drm, scrtc);
+   if (IS_ERR(planes)) {
dev_err(drm->dev, "Couldn't create the planes\n");
return NULL;
}
 
/* find primary and cursor planes for drm_crtc_init_with_planes */
-   for (i = 0; scrtc->layers[i]; i++) {
-   struct sun4i_layer *layer = scrtc->layers[i];
+   for (i = 0; planes[i]; i++) {
+   struct drm_plane *plane = planes[i];
 
-   switch (layer->plane.type) {
+   switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
-   primary = >plane;
+   primary = plane;
break;
case DRM_PLANE_TYPE_CURSOR:
-   cursor = >plane;
+   cursor = plane;
break;
default:
break;
@@ -188,12 +189,12 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
   1);
 
/* Set possible_crtcs to this crtc for overlay planes */
-   for (i = 0; scrtc->layers[i]; i++) {
+   for (i = 0; planes[i]; i++) {
uint32_t possible_crtcs = BIT(drm_crtc_index(>crtc));
-   struct sun4i_layer *layer = scrtc->layers[i];
+   struct drm_plane *plane = planes[i];
 
-   if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
-   layer->plane.possible_crtcs = possible_crtcs;
+   if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+   plane->possible_crtcs = possible_crtcs;
}
 
return scrtc;
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h 
b/drivers/gpu/drm/sun4i/sun4i_crtc.h
index 230cb8f0d601..4dae3508424a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
@@ -19,7 +19,6 @@ struct sun4i_crtc {
 
struct sun4i_backend*backend;
struct sun4i_tcon   *tcon;
-   struct sun4i_layer  **layers;
 };
 
 static inline struct sun4i_crtc *drm_crtc_to_sun4i_crtc(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index f26bde5b9117..e1f03e1cc0ac 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -16,6 +16,7 @@
 #include 
 
 #include "sun4i_backend.h"
+#include "sun4i_crtc.h"
 #include "sun4i_layer.h"
 
 struct sun4i_plane_desc {
@@ -128,15 +129,16 @@ static struct sun4i_layer *sun4i_layer_init_one(struct 
drm_device *drm,
return layer;
 }
 
-struct sun4i_layer **sun4i_layers_init(struct drm_device *drm,
-  struct sun4i_backend *backend)
+struct drm_plane **sun4i_layers_init(struct drm_device *drm,
+struct 

[PATCH v4 07/11] drm/sun4i: Add compatible string for V3s display engine

[Icenowy Zheng]

Allwinner V3s features the new "Display Engine 2.0", which can now also
be driven with our subdrivers in sun4i-drm.

Add the compatible string for in sun4i_drv.c, in order to make the
display engine and its components probed.

Signed-off-by: Icenowy Zheng 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 8ddd72cd5873..68c0b754cdb5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -294,6 +294,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-display-engine" },
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
+   { .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 05/11] drm/sun4i: abstract a engine type

[Icenowy Zheng]

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, so I choose to call them both "engine" here.

Abstract the engine type to void * and a ops struct, which contains
functions that should be called outside the engine-specified code (in
TCON, CRTC or TV Encoder code).

A dedicated Kconfig option is also added to control whether
sun4i-backend-specified code (sun4i_backend.c and sun4i_layer.c) should
be built. As we removed the codes in CRTC code that directly call the
layer code, we can now extract the layer part and combine it with the
backend part into a new module, sun4i-backend.ko.

Signed-off-by: Icenowy Zheng 
---
Changes in v4:
- Comments to tag the color correction functions as optional.
- Check before calling the optional functions.
- Change layers_init to satisfy new PATCH v4 04/11.

 drivers/gpu/drm/sun4i/Kconfig | 10 ++
 drivers/gpu/drm/sun4i/Makefile|  6 --
 drivers/gpu/drm/sun4i/sun4i_backend.c | 26 +++---
 drivers/gpu/drm/sun4i/sun4i_backend.h |  5 -
 drivers/gpu/drm/sun4i/sun4i_crtc.c| 14 +++---
 drivers/gpu/drm/sun4i/sun4i_crtc.h|  7 ---
 drivers/gpu/drm/sun4i/sun4i_drv.h |  3 ++-
 drivers/gpu/drm/sun4i/sun4i_layer.c   |  2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.h   |  3 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.c|  2 +-
 drivers/gpu/drm/sun4i/sun4i_tv.c  | 11 ++-
 drivers/gpu/drm/sun4i/sunxi_engine.h  | 35 +++
 12 files changed, 91 insertions(+), 33 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index a4b357db8856..5a8227f37cc4 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -12,3 +12,13 @@ config DRM_SUN4I
  Choose this option if you have an Allwinner SoC with a
  Display Engine. If M is selected the module will be called
  sun4i-drm.
+
+config DRM_SUN4I_BACKEND
+   tristate "Support for Allwinner A10 Display Engine Backend"
+   depends on DRM_SUN4I
+   default DRM_SUN4I
+   help
+ Choose this option if you have an Allwinner SoC with the
+ original Allwinner Display Engine, which has a backend to
+ do some alpha blending and feed graphics to TCON. If M is
+ selected the module will be called sun4i-backend.
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 59b757350a1f..1db1068b9be1 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -5,9 +5,11 @@ sun4i-tcon-y += sun4i_tcon.o
 sun4i-tcon-y += sun4i_rgb.o
 sun4i-tcon-y += sun4i_dotclock.o
 sun4i-tcon-y += sun4i_crtc.o
-sun4i-tcon-y += sun4i_layer.o
+
+sun4i-backend-y += sun4i_layer.o
+sun4i-backend-y += sun4i_backend.o
 
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
-obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o
+obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index d660741ba475..a16c96a002a4 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -23,6 +23,8 @@
 
 #include "sun4i_backend.h"
 #include "sun4i_drv.h"
+#include "sun4i_layer.h"
+#include "sunxi_engine.h"
 
 static const u32 sunxi_rgb2yuv_coef[12] = {
0x0107, 0x0204, 0x0064, 0x0108,
@@ -30,9 +32,10 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
0x01c1, 0x3e88, 0x3fb8, 0x0808
 };
 
-void sun4i_backend_apply_color_correction(struct sun4i_backend *backend)
+static void sun4i_backend_apply_color_correction(void *engine)
 {
int i;
+   struct sun4i_backend *backend = engine;
 
DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n");
 
@@ -44,27 +47,28 @@ void sun4i_backend_apply_color_correction(struct 
sun4i_backend *backend)
regmap_write(backend->regs, SUN4I_BACKEND_OCRCOEF_REG(i),
 sunxi_rgb2yuv_coef[i]);
 }
-EXPORT_SYMBOL(sun4i_backend_apply_color_correction);
 
-void sun4i_backend_disable_color_correction(struct sun4i_backend *backend)
+static void sun4i_backend_disable_color_correction(void *engine)
 {
+   struct sun4i_backend *backend = engine;
+
DRM_DEBUG_DRIVER("Disabling color correction\n");
 
/* Disable color correction */
regmap_update_bits(backend->regs, SUN4I_BACKEND_OCCTL_REG,
   SUN4I_BACKEND_OCCTL_ENABLE, 0);
 }
-EXPORT_SYMBOL(sun4i_backend_disable_color_correction);
 
-void sun4i_backend_commit(struct sun4i_backend *backend)
+static void 

[PATCH v4 03/11] dt-bindings: add bindings for DE2 on V3s SoC

[Icenowy Zheng]

Allwinner V3s SoC have a display engine which have a different pipeline
with older SoCs.

Add document for it (new compatibles and the new "mixer" part).

Signed-off-by: Icenowy Zheng 
---
Changes in v4:
- Removed the refactor at TCON chapter.

Changes in v3:
- Remove the description of having a BE directly as allwinner,pipeline.

 .../bindings/display/sunxi/sun4i-drm.txt   | 29 --
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 57a8d0610062..7da80e26d61b 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -31,6 +31,7 @@ Required properties:
* allwinner,sun6i-a31-tcon
* allwinner,sun6i-a31s-tcon
* allwinner,sun8i-a33-tcon
+   * allwinner,sun8i-v3s-tcon
  - reg: base address and size of memory-mapped region
  - interrupts: interrupt associated to this IP
  - clocks: phandles to the clocks feeding the TCON. Three are needed:
@@ -52,7 +53,7 @@ Required properties:
   second the block connected to the TCON channel 1 (usually the TV
   encoder)
 
-On SoCs other than the A33, there is one more clock required:
+On SoCs other than the A33 and V3s, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
 
 DRC
@@ -138,6 +139,26 @@ Required properties:
   Documentation/devicetree/bindings/media/video-interfaces.txt. The
   first port should be the input endpoints, the second one the outputs
 
+Display Engine 2.0 Mixer
+
+
+The DE2 mixer have many functionalities, currently only layer blending is
+supported.
+
+Required properties:
+  - compatible: value must be one of:
+* allwinner,sun8i-v3s-de2-mixer
+  - reg: base address and size of the memory-mapped region.
+  - clocks: phandles to the clocks feeding the frontend and backend
+* bus: the backend interface clock
+* ram: the backend DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset controllers driving the backend
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. The
+  first port should be the input endpoints, the second one the output
+
 
 Display Engine Pipeline
 ---
@@ -152,9 +173,13 @@ Required properties:
 * allwinner,sun6i-a31-display-engine
 * allwinner,sun6i-a31s-display-engine
 * allwinner,sun8i-a33-display-engine
+* allwinner,sun8i-v3s-display-engine
 
   - allwinner,pipelines: list of phandle to the display engine
-frontends available.
+pipeline entry point. For SoCs with original DE (currently
+all SoCs supported by display engine except V3s), this
+phandle should be a display frontend; for SoCs with DE2,
+this phandle should be a mixer.
 
 Example:
 
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 02/11] clk: sunxi-ng: add support for DE2 CCU

[Icenowy Zheng]

The "Display Engine 2.0" in Allwinner newer SoCs contains a clock
management unit for its subunits, like the DE CCU in A80.

Add a sunxi-ng style driver for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v4:
- Fixed the inconsistence between mixer_div clocks' number and real clock.
Changes in v2:
- Rename sunxi-de2-ccu to sun8i-de2-ccu.

 drivers/clk/sunxi-ng/Kconfig  |   5 +
 drivers/clk/sunxi-ng/Makefile |   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-de2.c  | 218 ++
 drivers/clk/sunxi-ng/ccu-sun8i-de2.h  |  28 +
 include/dt-bindings/clock/sun8i-de2.h |  54 +
 include/dt-bindings/reset/sun8i-de2.h |  50 
 6 files changed, 356 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h
 create mode 100644 include/dt-bindings/clock/sun8i-de2.h
 create mode 100644 include/dt-bindings/reset/sun8i-de2.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index fbd3f8cd5c22..7c7f55dc7f65 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -140,6 +140,11 @@ config SUN8I_V3S_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
 
+config SUN8I_DE2_CCU
+   bool "Support for the Allwinner SoCs DE2 CCU"
+   select SUNXI_CCU_DIV
+   select SUNXI_CCU_GATE
+
 config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0ec02fe14c50..be616279450e 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_SUN8I_A23_CCU)   += ccu-sun8i-a23.o
 obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
 obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
 obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
+obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
 obj-$(CONFIG_SUN8I_R_CCU)  += ccu-sun8i-r.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-de.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
new file mode 100644
index ..30fe42635635
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_reset.h"
+
+#include "ccu-sun8i-de2.h"
+
+static SUNXI_CCU_GATE(bus_mixer0_clk,  "bus-mixer0",   "bus-de",
+ 0x04, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_mixer1_clk,  "bus-mixer1",   "bus-de",
+ 0x04, BIT(1), 0);
+static SUNXI_CCU_GATE(bus_wb_clk,  "bus-wb",   "bus-de",
+ 0x04, BIT(2), 0);
+
+static SUNXI_CCU_GATE(mixer0_clk,  "mixer0",   "mixer0-div",
+ 0x00, BIT(0), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(mixer1_clk,  "mixer1",   "mixer1-div",
+ 0x00, BIT(1), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(wb_clk,  "wb",   "wb-div",
+ 0x00, BIT(2), CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4,
+  CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de", 0x0c, 4, 4,
+  CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4,
+  CLK_SET_RATE_PARENT);
+
+static struct ccu_common *sunxi_de2_clks[] = {
+   _clk.common,
+   _clk.common,
+   _clk.common,
+
+   _mixer0_clk.common,
+   _mixer1_clk.common,
+   _wb_clk.common,
+
+   _div_clk.common,
+   _div_clk.common,
+   _div_clk.common,
+};
+
+static struct clk_hw_onecell_data sunxi_de2_hw_clks = {
+   .hws= {
+   [CLK_MIXER0]= _clk.common.hw,
+   [CLK_MIXER1]= _clk.common.hw,
+   [CLK_WB]= _clk.common.hw,
+
+   [CLK_BUS_MIXER0]= _mixer0_clk.common.hw,
+   [CLK_BUS_MIXER1]= _mixer1_clk.common.hw,
+   [CLK_BUS_WB]= _wb_clk.common.hw,
+
+   [CLK_MIXER0_DIV]= _div_clk.common.hw,
+   [CLK_MIXER1_DIV]= _div_clk.common.hw,
+   [CLK_WB_DIV]= _div_clk.common.hw,
+   },
+ 

[PATCH v4 08/11] drm/sun4i: tcon: add support for V3s TCON

[Icenowy Zheng]

Allwinner V3s SoC features a TCON without channel 1.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c  | 3 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 68c0b754cdb5..736b28e47281 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -176,7 +176,8 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
-   of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
+   of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") ||
+   of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon");
 }
 
 static int compare_of(struct device *dev, void *data)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index f50ecb75c177..e85a726a9c36 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -533,11 +533,16 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
/* nothing is supported */
 };
 
+static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
+   /* nothing is supported */
+};
+
 static const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-tcon", .data = _a13_quirks },
{ .compatible = "allwinner,sun6i-a31-tcon", .data = _a31_quirks },
{ .compatible = "allwinner,sun6i-a31s-tcon", .data = _a31s_quirks 
},
{ .compatible = "allwinner,sun8i-a33-tcon", .data = _a33_quirks },
+   { .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers

[Icenowy Zheng]

Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
with mixers to do graphic processing and feed data to TCON, like the old
backends and frontends.

Add support for the mixer on Allwinner V3s SoC; it's the simplest one.

Currently a lot of functions are still missing -- more investigations
are needed to gain enough information for them.

Signed-off-by: Icenowy Zheng 
---
Changes in v4:
- Killed some dead code according to Jernej.

 drivers/gpu/drm/sun4i/Kconfig   |  10 +
 drivers/gpu/drm/sun4i/Makefile  |   4 +
 drivers/gpu/drm/sun4i/sun8i_layer.c | 142 ++
 drivers/gpu/drm/sun4i/sun8i_layer.h |  36 
 drivers/gpu/drm/sun4i/sun8i_mixer.c | 381 
 drivers/gpu/drm/sun4i/sun8i_mixer.h | 131 +
 6 files changed, 704 insertions(+)
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
  original Allwinner Display Engine, which has a backend to
  do some alpha blending and feed graphics to TCON. If M is
  selected the module will be called sun4i-backend.
+
+config DRM_SUN4I_SUN8I_MIXER
+   tristate "Support for Allwinner Display Engine 2.0 Mixer"
+   depends on DRM_SUN4I
+   default MACH_SUN8I
+   help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 1db1068b9be1..7625c2dad1bb 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,7 +9,11 @@ sun4i-tcon-y += sun4i_crtc.o
 sun4i-backend-y += sun4i_layer.o
 sun4i-backend-y += sun4i_backend.o
 
+sun8i-mixer-y += sun8i_layer.o
+sun8i-mixer-y += sun8i_mixer.o
+
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
 obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER) += sun8i-mixer.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c 
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..d70a90d963b0
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) Icenowy Zheng 
+ *
+ * Based on sun4i_layer.h, which is:
+ *   Copyright (C) 2015 Free Electrons
+ *   Copyright (C) 2015 NextThing Co
+ *
+ *   Maxime Ripard 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "sun4i_crtc.h"
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+
+struct sun8i_plane_desc {
+  enum drm_plane_type type;
+  const uint32_t  *formats;
+  uint32_tnformats;
+};
+
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   return 0;
+}
+
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
+  struct drm_plane_state 
*old_state)
+{
+   struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+   struct sun8i_mixer *mixer = layer->mixer;
+
+   sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+   struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+   struct sun8i_mixer *mixer = layer->mixer;
+
+   sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+   sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+   sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+   sun8i_mixer_layer_enable(mixer, layer->id, true);
+}
+
+static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
+   .atomic_check   = sun8i_mixer_layer_atomic_check,
+   .atomic_disable = sun8i_mixer_layer_atomic_disable,
+   .atomic_update  = sun8i_mixer_layer_atomic_update,
+};
+
+static const struct drm_plane_funcs sun8i_mixer_layer_funcs = {
+   .atomic_destroy_state   = 

[PATCH v4 00/11] Initial Allwinner Display Engine 2.0 Support

[Icenowy Zheng]

This patchset is the initial patchset for Allwinner DE2 support.

It contains the support of clocks in DE2 and the mixers in DE2.

The SoC used to develop this patchset is V3s, as V3s is the simplest
one of the SoCs that have DE2.
(Allwinner V3s features only one mixer, although its clock control
unit contains support for second mixer's clock; and its only video
output is RGB LCD, which is already supported in our TCON driver)

The last patch is only a testing patch, it shouldn't be merged; and
for the patch to be really usable, the RFC fix of the TCON driver [1]
is needed.

No HDMI, TV encoder or other internal bridges' support is included
in this patchset, which makes it currently not usable on H3.

Thanks to Jean-Francois Moine and Jernej Skrabec for their efforts
to discover the internal of DE2!

[1] https://lists.freedesktop.org/archives/dri-devel/2016-December/126264.html

Icenowy Zheng (11):
  dt-bindings: add binding for the Allwinner DE2 CCU
  clk: sunxi-ng: add support for DE2 CCU
  dt-bindings: add bindings for DE2 on V3s SoC
  drm/sun4i: return only planes for layers created
  drm/sun4i: abstract a engine type
  drm/sun4i: add support for Allwinner DE2 mixers
  drm/sun4i: Add compatible string for V3s display engine
  drm/sun4i: tcon: add support for V3s TCON
  ARM: dts: sun8i: add DE2 nodes for V3s SoC
  ARM: dts: sun8i: add pinmux for LCD pins of V3s SoC
  [DO NOT MERGE] ARM: dts: sun8i: enable LCD panel of Lichee Pi Zero

 .../devicetree/bindings/clock/sun8i-de2.txt|  31 ++
 .../bindings/display/sunxi/sun4i-drm.txt   |  29 +-
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts  |  36 ++
 arch/arm/boot/dts/sun8i-v3s.dtsi   |  96 ++
 drivers/clk/sunxi-ng/Kconfig   |   5 +
 drivers/clk/sunxi-ng/Makefile  |   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-de2.c   | 218 
 drivers/clk/sunxi-ng/ccu-sun8i-de2.h   |  28 ++
 drivers/gpu/drm/sun4i/Kconfig  |  20 ++
 drivers/gpu/drm/sun4i/Makefile |  10 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c  |  26 +-
 drivers/gpu/drm/sun4i/sun4i_backend.h  |   5 -
 drivers/gpu/drm/sun4i/sun4i_crtc.c |  35 +-
 drivers/gpu/drm/sun4i/sun4i_crtc.h |   8 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c  |   4 +-
 drivers/gpu/drm/sun4i/sun4i_drv.h  |   3 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c|  18 +-
 drivers/gpu/drm/sun4i/sun4i_layer.h|   7 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c |   7 +-
 drivers/gpu/drm/sun4i/sun4i_tv.c   |  11 +-
 drivers/gpu/drm/sun4i/sun8i_layer.c| 142 
 drivers/gpu/drm/sun4i/sun8i_layer.h|  36 ++
 drivers/gpu/drm/sun4i/sun8i_mixer.c| 381 +
 drivers/gpu/drm/sun4i/sun8i_mixer.h| 131 +++
 drivers/gpu/drm/sun4i/sunxi_engine.h   |  35 ++
 include/dt-bindings/clock/sun8i-de2.h  |  54 +++
 include/dt-bindings/reset/sun8i-de2.h  |  50 +++
 27 files changed, 1371 insertions(+), 56 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
 create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h
 create mode 100644 include/dt-bindings/clock/sun8i-de2.h
 create mode 100644 include/dt-bindings/reset/sun8i-de2.h

-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 11/11] [DO NOT MERGE] ARM: dts: sun8i: enable LCD panel of Lichee Pi Zero

[Icenowy Zheng]

A 480x272 QiaoDian QD43003C0-40-7LED panel is available from Lichee Pi.

This commit connects this panel to Lichee Pi Zero.

Lichee Pi also provides a 800x480 panel without accurate model number,
so do not merge this patch. It will finally come as device tree overlay.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 36 +++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts 
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 387fc2aa546d..7ae72bf63cd0 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -75,6 +75,28 @@
gpios = < 6 2 GPIO_ACTIVE_LOW>; /* PG2 */
};
};
+
+   panel: panel {
+   compatible = "qiaodian,qd43003c0-40", "simple-panel";
+   enable-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* Should be 
backlight */
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel_input: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lcd>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
 };
 
  {
@@ -86,6 +108,20 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgb666_pins>;
+   status = "okay";
+
+};
+
+_out {
+   tcon0_out_lcd: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+};
+
  {
pinctrl-0 = <_pins_a>;
pinctrl-names = "default";
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] gpu: host1x: Fix wrong pointer passed to PTR_ERR()

[Wei Yongjun]

From: Wei Yongjun 

PTR_ERR should access the value just tested by IS_ERR, otherwise
the wrong error code will be returned.

Fixes: b386c6b73ac6 ("gpu: host1x: Support module reset")
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/host1x/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index f05ebb1..ac65f52 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -172,7 +172,7 @@ static int host1x_probe(struct platform_device *pdev)
 
host->rst = devm_reset_control_get(>dev, "host1x");
if (IS_ERR(host->rst)) {
-   err = PTR_ERR(host->clk);
+   err = PTR_ERR(host->rst);
dev_err(>dev, "failed to get reset: %d\n", err);
return err;
}

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

[Milan Broz]

On 04/14/2017 06:03 PM, Logan Gunthorpe wrote:
> 
> 
> On 14/04/17 02:39 AM, Christoph Hellwig wrote:
>> On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote:
>>> Very straightforward conversion to the new function in all four spots.
>>
>> I think the right fix here is to switch dm-crypt to the ahash API
>> that takes a scatterlist.
> 
> Hmm, well I'm not sure I understand the code enough to make that
> conversion. But I was looking at it. One tricky bit seems to be that
> crypt_iv_lmk_one adds a seed, skips the first 16 bytes in the page and
> then hashes another 16 bytes from other data. What would you do
> construct a new sgl for it and pass it to the ahash api?
> 
> The other thing is crypt_iv_lmk_post also seems to modify the page after
> the hash with a  crypto_xor so you'd still need at least one kmap in there.

yes, it is in fact modification of CBC mode implemented this hacky way.
These IVs are only for compatibility with loopaes and very old trueCrypt 
formats.

I think your patch is ok (if it is just plain conversion), if it is
really needed, we can switch to ahash later in follow-up patch.

All common code in dmcrypt uses async API already.

p.s.
there is a lot of lists on cc, but for this patch is missing dm-devel, dmcrypt 
changes
need to go through Mike's tree (I added dm-devel to cc:)

Milan


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99784] AMD 7470m When VGA plugged into laptop, only one monitor working at a time

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99784

--- Comment #11 from lazane...@gmail.com ---
Problem persists with 4.11rc7 kernel. Should I try updating some other package?

Also, I noticed that problem starts before X is active (at grub/systemd/ubuntu
splash logo). With fglrx only internal monitor would display image at that time
- until lightdm and X start (when all three monitors would turn on). Using
radeon drivers/drm however, external monitors would display mirrored systemd
log/splash screen and internal monitor is off right after grub menu.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100697] [radeonsi,WebGL] blinking random patches instead of blinking squares

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100697

--- Comment #2 from Kai  ---
(In reply to network723 from comment #1)
> While I'm not a dev, but this is very similar to what I see in Xonotic, due
> to llvm regression, see this bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=100681
> 
> If you can, try building mesa with earlier llvm revision, I myself use
> 299800 for now.

Thanks for the pointer but I've seen this issue for quite some time with
different versions of Mesa and LLVM. Therefore I do not believe this to be
related. I just never got around to report the bug since the main part of the
map is rendering fine and the menus are working as well. It's really just the
background here.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100697] [radeonsi,WebGL] blinking random patches instead of blinking squares

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100697

--- Comment #1 from network...@rkmail.ru ---
While I'm not a dev, but this is very similar to what I see in Xonotic, due to
llvm regression, see this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=100681

If you can, try building mesa with earlier llvm revision, I myself use 299800
for now.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100697] [radeonsi,WebGL] blinking random patches instead of blinking squares

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100697

Bug ID: 100697
   Summary: [radeonsi,WebGL] blinking random patches instead of
blinking squares
   Product: Mesa
   Version: git
  Hardware: Other
   URL: https://robertsspaceindustries.com/starmap
OS: All
Status: NEW
  Severity: minor
  Priority: low
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: k...@dev.carbon-project.org
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 130867
  --> https://bugs.freedesktop.org/attachment.cgi?id=130867=edit
Random blinking spots instead of squares

When viewing  you can see random
blinking patches (see attached screenshot) instead of full screen of blinking
squares in the background during the loading screens. The first few seconds of
 show how the background should
look.
Please note, that the actual star map works fine AFAICT (thus the reduced
severity and priority).
This is with the OpenGL stack detailed below and Firefox 52.0.2. Also this
doesn't seem to be a duplicate of bug 100036 as that star map seems to render
correctly for me with the same setup.

The full stack (Debian testing as a base) is:
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/566f2ed571
libdrm: Git:master/c9c77c3717 (tag libdrm-2.4.79)
LLVM: SVN:trunk/r299977 (5.0 devel)
X.Org: 2:1.19.2-1
Linux: 4.10.9
Firmware (firmware-amd-graphics): 20161130-2
libclc: 0.2.0+git20170330-1 (rebuilt for LLVM 5.0)
DDX (xserver-xorg-video-amdgpu): 1.2.0-1+b1

Let me know if you need anything else.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100695] Texture artifacts in Deus Ex: Mankind Divided

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100695

Bug ID: 100695
   Summary: Texture artifacts in Deus Ex: Mankind Divided
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: freedesk...@psydk.org
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 130861
  --> https://bugs.freedesktop.org/attachment.cgi?id=130861=edit
Main menu screen with an unreadable title

Hi,

I've got glitches in Deus Ex: Mankind Divided that appeared some days ago. See
the screenshot were the title is unreadable.

OS: Ubuntu 17.04
Linux kernel version: 4.10.0-19-generic
cpu: Intel i7-6700K
gpu: Amd RX 480
Mesa version: 1:17.1~git170417001000.9f0dd85~z~padoka0

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/8] drm/exynos: misc fixes and more

[Tobias Jakobi]

Hello Inki,


Inki Dae wrote:
> Hello Tobias,
> 
> 2017년 04월 11일 19:52에 Tobias Jakobi 이(가) 쓴 글:
>> Hello Inki,
>>
>> please don't forget to review this series.
> 
> Thanks for your contribution, and don't worry about that. Will review this 
> series.


Thank you for the confirmation!

In the meantime, i.e. until we have figured out the IOMMU pagefault, it
would make sense to reject the combination "interlaced mode + video
plane". Should I prepare a patch for that?


With best wishes,
Tobias



> Just sharing a plan for -next,
> 
> I plan to have pull-request after reviewing a patch set[1] posted by Andrzej.
> After that, I will start to review your patch set - we would need to enough 
> review this RFC patch set. 
> 
> It would be very helpful to me if other people could review this.
> 
> 
> Thanks,
> Inki Dae
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2017-April/138112.html
> 
> 
>>
>> Also some pointers concerning the video plane flickering and the
>> interlacing issue would be very welcome.
>>
>> Looking at the current register defines for MXR_INT_EN suggests that
>> there are at least three more type of interrupt available. Any chance
>> these could be documented? I hope to get some more insight into this
>> issue, which apparantly is caused by insufficient bandwidth.
>>
>> For the interlacing issue I have done partial progress. I now longer see
>> a IOMMU pagefault, but the video plane is heavily corrupted. Also the
>> dimensions look wrong.
>>
>> While I can somehow guess that VP_MODE_LINE_SKIP does, the
>> VP_MODE_FIELD_ID_AUTO_TOGGLING flag still remains a mystery to me. If
>> possible, I request some documentation for this as well.
>>
>>
>> With best wishes,
>> Tobias
>>
>>
>>
>> Tobias Jakobi wrote:
>>> Hello,
>>>
>>> some recent work I did on Exynos. Patches are based on [1] and [2].
>>>
>>> Summary:
>>> (a) Enables support for NV12MT in the mixer.
>>> (b) Sanitizes buffer pitch for HW with restrictions.
>>> (c) Misc fixes
>>>
>>> While testing the NV12MT part, I made these interesting observations.
>>>
>>> (1) I used 1920x1080 XRGB on the primary plane, and 1280x768 on the
>>> video plane. With this configuration, it does not matter if you're
>>> using NV12 or NV12MT, the video plane occasionally flickers or shows
>>> heavy artifacting. Reducing the size of the primary plane, e.g. to
>>> 32x32 solves this issue, so my guess is that this is memory bandwidth
>>> issue. Does someone know if one can check for buffer underflows of the
>>> mixer with respect to data passed from the VP?
>>>
>>> (2) Using 1920x1080i (so an interlaced mode) and NV12, the board
>>> immediately dies with an IOMMU pagefault at address zero. I'm
>>> currently investigating this, and it looks like that the VP setup
>>> is wrong here. In particular it should be the source (!) height
>>> and vertical position that should be halfed in interlaced mode, and
>>> not the destination. Need to look more into this.
>>>
>>> Anyway, both the issues are independant of the patches, so please
>>> review! :-)
>>>
>>> With best wishes,
>>> Tobias
>>>
>>>
>>> [1] http://www.spinics.net/lists/linux-samsung-soc/msg58640.html
>>> [2] http://www.spinics.net/lists/linux-samsung-soc/msg58644.html
>>>
>>> Tobias Jakobi (8):
>>>   drm/exynos: mixer: fix chroma comment in vp_video_buffer()
>>>   drm/exynos: mixer: enable NV12MT support for the video plane
>>>   drm/exynos: mixer: simplify {vp_video,mixer_graph}_buffer()
>>>   drm/exynos: mixer: remove src offset from mixer_graph_buffer()
>>>   drm/exynos: introduce BYTE_PITCH capability
>>>   drm/exynos: add BYTE_PITCH cap for all supported planes
>>>   drm/exynos: consistent use of cpp
>>>   drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers
>>>
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 17 +--
>>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 13 +++-
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 ++
>>>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 17 ---
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 ++
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 44 
>>> ---
>>>  7 files changed, 71 insertions(+), 61 deletions(-)
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Tobias Jakobi]

Hello Inki,



Inki Dae wrote:
> 2017년 04월 11일 17:17에 Tobias Jakobi 이(가) 쓴 글:
>> Another thing that I noticed. Why wasn't the v2 that ended up in your
>> git ever submitted to the mailing list? Because it should have, in
>> particular to spot these obvious errors.
> 
> Only comment about this.
> 
> This patch cleans up description of struct exynos_drm_clk - removed 
> unnecessary descriptions and adds one missed before.
> I think no problem to update the description without v2 because no code 
> change and description enough.
I think you miss the point here. I checked the mail thread again and you
responded with "More simple and looks better." when I suggested to put
the largest part of your description in front of 'struct
exynos_drm_clk'. I even went so far as to prepare the comment for you.
And then you proceed by ignoring everything and merging some completly
different patch. I find this disrespectful.

I'm quoting your words here (from [1]):
> I'd like to say *maintainer is really not a place for power*, and maintainer 
> would implicitly have a role to encourage in contribution activity of 
> contributer.

If you really mean this, you should also act accordingly. And that does
not mean saying "A" to someone and then doing "B".



> If you want to update the description more then you can post it.
> Ps. I am not a leisurely person to respond to every little thing.
I don't expect you to respond to every little thing. But I expect proper
and honest communication. Also a response delay of four weeks is simply
not acceptable. And I don't think I'm the only one on dri-devel that
thinks that way.

With best wishes,
Tobias


[1] http://www.spinics.net/lists/dri-devel/msg131304.html


> 
> Thanks,
> Inki Dae
> 
>>
>> - Tobias
>>
>>
>> Tobias Jakobi wrote:
>>> Inki Dae wrote:


 2017년 04월 10일 19:29에 Tobias Jakobi 이(가) 쓴 글:
> Inki Dae wrote:
>> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi :
>>> Hello Inki,
>>>
>>>
>>> Inki Dae wrote:
 Hello Tobias,


 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
> Hello Inki,
>
>
> Inki Dae wrote:
>> This patch removes unnecessary descriptions on
>> exynos_drm_crtc structure and adds one description
>> which specifies what pipe_clk member does.
>>
>> pipe_clk support had been added by below patch without any 
>> description,
>>  drm/exynos: add support for pipeline clock to the framework
> I would put the commit id here. That makes it easier to look up the
> commit your refer to.
>
>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 527bf1d..b0462cc 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>>   *
>>   * @base: crtc object.
>>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
>> - * @enabled: if the crtc is enabled or not
>> - * @event: vblank event that is currently queued for flip
>> - * @wait_update: wait all pending planes updates to finish
>> - * @pending_update: number of pending plane updates in this crtc
>>   * @ops: pointer to callbacks for exynos drm specific functionality
>>   * @ctx: A pointer to the crtc's implementation specific context
>> + * @pipe_clk: A pipe clock structure which includes a callback 
>> function
>> + for enabling DP clock of FIMD and HDMI PHY clock.
> This is wrong/inconsistent with the rest of the documentation. 
> pipe_clk
> is not a struct, but a pointer.
>
> I would suggest to follow. Just document that we have a pointer to 
>  escription> here (compare docu for 'ops' and 'ctx').
> And then put the later bits ("...callback function for enabling DP
> clock...") directly to the definition of 'struct exynos_drm_clk' 
> (which
> is currently lacking any kind of docu).

 Thanks for pointing it out. My mistake. :)

 How about this simply?
 "A pointer to exynos_drm_clk structure for enabling and disabling DP 
 clock of FIMD and HDMI PHY clocks"
>>> Not what I meant. You're describing 'struct exynos_drm_clk', and that
>>> does not belong here. If you describe 'struct exynos_drm_clk', then this
>>> should go in front of the struct's definition.
>>>
>>> How abouting something like this in front of the struct's definition::
 /*
  * Exynos DRM 

Re: [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

[Tobias Jakobi]

Hello Inki,

Inki Dae wrote:

> Tobias, why did you post the patch set 1/2 and 2/2 before?
> If these patches can be applied independently - you found out later - then 
> you need to clarify why you posted them separately.


after I posted v1 of the patchset, Andrzej responded with a Reviewed-By
for patch 1/2 and suggestions for patch 2/2. I then integrated the
suggestions and added the Reviewed-By tag, hence changing both patch 1/2
and 2/2. I then posted v2 of the patchset, because _both_ patches
changed. Andrzej then pointed out that the values used in patch 2/2
could be further simplied. I then posted a v3 of patch 2/2, because only
this one patch changed.
When I pinged you concerning the patches, I specifically did this with
v3 of 2/2, and v2 of 1/2. It was perfectly clear which patches I wanted
you to pick up.
I can understand when maintainers of high-volume subsystems sometimes
get patch versions mixed up. But drm-exynos only gets very few patches
each cycle. If you have problems dealing with your maintainer duties in
a timely manner, I would suggest to contact Daniel Vetter so that exynos
is added to drm-misc. I personally think exynos would benefit from such
a move.

With best wishes,
Tobias



> 
> Thanks,
> Inki Dae
> 
>>
>>
>>>
>>> I can merge the new one - really trivial - but I think it'd be better you 
>>> to resend this patch series for other people.
>>>
>>> This patch set has been removed from my tree. Please resend (not v4) this 
>>> patch set like below,
>>> [PATCH v3 0/2] drm/exynos: clean up mixer driver??
>>> [PATCH v3 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()
>>> [PATCH v3 2/2] drm/exynos: mixer: document YCbCr magic numbers
>> Not necessary, just pick up the two patches which for which I already
>> pinged you. For you convenience, here are the two on dri-devel patchwork:
>> https://patchwork.kernel.org/patch/9617085/
>> https://patchwork.kernel.org/patch/9617493/
>>
>> - Tobias
>>
>>
>>
>>>
>>> Thanks,
>>> Inki Dae
>>>

 - Tobias


> Thanks,
> Inki Dae
>
>> With best wishes,
>> Tobias
>>
>>
>> Tobias Jakobi wrote:
>>> The output stage of the mixer uses YCbCr for the internal
>>> computations, which is the reason that some registers take
>>> YCbCr related data as input. In particular this applies
>>> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>>>
>>> Document the formatting of the data which we write to
>>> these registers.
>>>
>>> While at it, unify wording of comments in the register header.
>>>
>>> Reviewed-by: Andrzej Hajda 
>>> Signed-off-by: Tobias Jakobi 
>>> ---
>>> Changes in v2:
>>> - use floating point values as input for the macros, as
>>>   suggested by Andrzej
>>> - the floating point values have been tuned to exactly match
>>>   the values that are currently used
>>>
>>> Changes in v3:
>>> - use only three digit values (pointed out by Andrzej)
>>>
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 
>>> +
>>>  drivers/gpu/drm/exynos/regs-mixer.h   |  7 +--
>>>  2 files changed, 30 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 41d0c36..9648dd5 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -45,6 +45,22 @@
>>>  #define MIXER_WIN_NR 3
>>>  #define VP_DEFAULT_WIN   2
>>>
>>> +/*
>>> + * Mixer color space conversion coefficient triplet.
>>> + * Used for CSC from RGB to YCbCr.
>>> + * Each coefficient is a 10-bit fixed point number with
>>> + * sign and no integer part, i.e.
>>> + * [0:8] = fractional part (representing a value y = x / 2^9)
>>> + * [9] = sign
>>> + * Negative values are encoded with two's complement.
>>> + */
>>> +#define MXR_CSC_C(x) ((int)((x) * 512.0) & 0x3ff)
>>> +#define MXR_CSC_CT(a0, a1, a2) \
>>> +  ((MXR_CSC_C(a0) << 20) | (MXR_CSC_C(a1) << 10) | (MXR_CSC_C(a2) << 
>>> 0))
>>> +
>>> +/* YCbCr value, used for mixer background color configuration. */
>>> +#define MXR_YCBCR_VAL(y, cb, cr) (((y) << 16) | ((cb) << 8) | ((cr) << 
>>> 0))
>>> +
>>>  /* The pixelformats that are natively supported by the mixer. */
>>>  #define MXR_FORMAT_RGB5654
>>>  #define MXR_FORMAT_ARGB1555  5
>>> @@ -391,13 +407,14 @@ static void mixer_cfg_rgb_fmt(struct 
>>> mixer_context *ctx, unsigned int height)
>>>   case 1080:
>>>   default:
>>>   val = MXR_CFG_RGB709_16_235;
>>> + /* Configure the BT.709 CSC matrix for full range RGB. */
>>>   mixer_reg_write(res, MXR_CM_COEFF_Y,
>>> - (1 << 30) | (94 << 20) | (314 << 10)