[PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property

2018-04-19 Thread Jacopo Mondi
The THC63LVD1024 LVDS to RGB bridge supports two different input mapping
modes, selectable by means of an external pin.

Describe the LVDS mode map through a newly defined mandatory property in
device tree bindings.

Signed-off-by: Jacopo Mondi 
---
 .../devicetree/bindings/display/bridge/thine,thc63lvd1024.txt  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
index 37f0c04..0937595 100644
--- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -12,6 +12,8 @@ Required properties:
 - compatible: Shall be "thine,thc63lvd1024"
 - vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
   PPL and digital circuitry
+- thine,map: LVDS mapping mode selection signal, pin name "MAP". Shall be <1>
+  for mapping mode 1, <0> for mapping mode 2
 
 Optional properties:
 - powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
@@ -36,6 +38,7 @@ Example:
 
vcc-supply = <®_lvds_vcc>;
powerdown-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
+   thine,map = <1>;
 
ports {
#address-cells = <1>;
-- 
2.7.4



[PATCH 3/8] drm: bridge: thc63lvd1024: Add support for LVDS mode map

2018-04-19 Thread Jacopo Mondi
The THC63LVD1024 LVDS to RGB bridge supports two different LVDS mapping
modes, selectable by means of an external pin.

Add support for configurable LVDS input mapping modes, using the newly
introduced support for bridge input image formats.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/bridge/thc63lvd1024.c | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index 48527f8..a3071a1 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -10,9 +10,15 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
+enum thc63_lvds_mapping_mode {
+   THC63_LVDS_MAP_MODE2,
+   THC63_LVDS_MAP_MODE1,
+};
+
 enum thc63_ports {
THC63_LVDS_IN0,
THC63_LVDS_IN1,
@@ -116,6 +122,37 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
return 0;
 }
 
+static int thc63_set_bus_fmt(struct thc63_dev *thc63)
+{
+   u32 bus_fmt;
+   u32 map;
+   int ret;
+
+   ret = of_property_read_u32(thc63->dev->of_node, "thine,map", &map);
+   if (ret) {
+   dev_err(thc63->dev,
+   "Unable to parse property \"thine,map\": %d\n", ret);
+   return ret;
+   }
+
+   switch (map) {
+   case THC63_LVDS_MAP_MODE1:
+   bus_fmt = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+   break;
+   case THC63_LVDS_MAP_MODE2:
+   bus_fmt = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+   break;
+   default:
+   dev_err(thc63->dev,
+   "Invalid value for property \"thine,map\": %u\n", map);
+   return -EINVAL;
+   }
+
+   drm_bridge_set_bus_formats(&thc63->bridge, &bus_fmt, 1);
+
+   return 0;
+}
+
 static int thc63_gpio_init(struct thc63_dev *thc63)
 {
thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
@@ -166,6 +203,10 @@ static int thc63_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = thc63_set_bus_fmt(thc63);
+   if (ret)
+   return ret;
+
thc63->bridge.driver_private = thc63;
thc63->bridge.of_node = pdev->dev.of_node;
thc63->bridge.funcs = &thc63_bridge_func;
-- 
2.7.4



[PATCH 6/8] drm: rcar-du: rcar-lvds: Add bridge format support

2018-04-19 Thread Jacopo Mondi
With the introduction of static input image format enumeration in DRM
bridges, add support to retrieve the format in rcar-lvds LVDS encoder
from both panel or bridge, to set the desired LVDS mode.

Do not rely on 'DRM_BUS_FLAG_DATA_LSB_TO_MSB' flag to mirror the LVDS
format, as it is only defined for drm connectors, but use the newly
introduced _LE version of LVDS mbus image formats.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/rcar-du/rcar_lvds.c | 64 +
 1 file changed, 44 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3d2d3bb..2fa875f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -280,41 +280,65 @@ static bool rcar_lvds_mode_fixup(struct drm_bridge 
*bridge,
return true;
 }
 
-static void rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds)
+static int rcar_lvds_get_lvds_mode_from_connector(struct rcar_lvds *lvds,
+ unsigned int *bus_fmt)
 {
struct drm_display_info *info = &lvds->connector.display_info;
-   enum rcar_lvds_mode mode;
-
-   /*
-* There is no API yet to retrieve LVDS mode from a bridge, only panels
-* are supported.
-*/
-   if (!lvds->panel)
-   return;
 
if (!info->num_bus_formats || !info->bus_formats) {
dev_err(lvds->dev, "no LVDS bus format reported\n");
-   return;
+   return -EINVAL;
+   }
+
+   *bus_fmt = info->bus_formats[0];
+
+   return 0;
+}
+
+static int rcar_lvds_get_lvds_mode_from_bridge(struct rcar_lvds *lvds,
+  unsigned int *bus_fmt)
+{
+   if (!lvds->next_bridge->num_bus_formats ||
+   !lvds->next_bridge->bus_formats) {
+   dev_err(lvds->dev, "no LVDS bus format reported\n");
+   return -EINVAL;
}
 
-   switch (info->bus_formats[0]) {
+   *bus_fmt = lvds->next_bridge->bus_formats[0];
+
+   return 0;
+}
+
+static void rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds)
+{
+   unsigned int bus_fmt;
+   int ret;
+
+   if (lvds->panel)
+   ret = rcar_lvds_get_lvds_mode_from_connector(lvds, &bus_fmt);
+   else
+   ret = rcar_lvds_get_lvds_mode_from_bridge(lvds, &bus_fmt);
+   if (ret)
+   return;
+
+   switch (bus_fmt) {
+   case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE:
+   case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE:
+   lvds->mode |= RCAR_LVDS_MODE_MIRROR;
case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
-   mode = RCAR_LVDS_MODE_JEIDA;
+   lvds->mode = RCAR_LVDS_MODE_JEIDA;
break;
+
+   case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE:
+   lvds->mode |= RCAR_LVDS_MODE_MIRROR;
case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
-   mode = RCAR_LVDS_MODE_VESA;
+   lvds->mode = RCAR_LVDS_MODE_VESA;
break;
default:
dev_err(lvds->dev, "unsupported LVDS bus format 0x%04x\n",
-   info->bus_formats[0]);
-   return;
+   bus_fmt);
}
-
-   if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
-   mode |= RCAR_LVDS_MODE_MIRROR;
-
-   lvds->mode = mode;
 }
 
 static void rcar_lvds_mode_set(struct drm_bridge *bridge,
-- 
2.7.4



[PATCH 7/8] drm: panel: Use _LE LVDS formats for data mirroring

2018-04-19 Thread Jacopo Mondi
As now both bridges and panels report supported image formats,
use the newly introduced _LE version of LVDS media bus formats in place
of the DRM_BUS_FLAG_DATA_ flags defined in drm_connector.h

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/panel/panel-lvds.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index 5185819..ac03eab 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -37,7 +37,6 @@ struct panel_lvds {
unsigned int height;
struct videomode video_mode;
unsigned int bus_format;
-   bool data_mirror;
 
struct backlight_device *backlight;
struct regulator *supply;
@@ -129,9 +128,6 @@ static int panel_lvds_get_modes(struct drm_panel *panel)
connector->display_info.height_mm = lvds->height;
drm_display_info_set_bus_formats(&connector->display_info,
 &lvds->bus_format, 1);
-   connector->display_info.bus_flags = lvds->data_mirror
- ? DRM_BUS_FLAG_DATA_LSB_TO_MSB
- : DRM_BUS_FLAG_DATA_MSB_TO_LSB;
 
return 1;
 }
@@ -149,6 +145,7 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
struct device_node *np = lvds->dev->of_node;
struct display_timing timing;
const char *mapping;
+   bool data_mirror;
int ret;
 
ret = of_get_display_timing(np, "panel-timing", &timing);
@@ -179,20 +176,26 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
return -ENODEV;
}
 
+   data_mirror = of_property_read_bool(np, "data-mirror");
+
if (!strcmp(mapping, "jeida-18")) {
-   lvds->bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
+   lvds->bus_format = data_mirror ?
+  MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE :
+  MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
} else if (!strcmp(mapping, "jeida-24")) {
-   lvds->bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+   lvds->bus_format = data_mirror ?
+  MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE :
+  MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
} else if (!strcmp(mapping, "vesa-24")) {
-   lvds->bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+   lvds->bus_format = data_mirror ?
+  MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE :
+  MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
} else {
dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
np, "data-mapping");
return -EINVAL;
}
 
-   lvds->data_mirror = of_property_read_bool(np, "data-mirror");
-
return 0;
 }
 
-- 
2.7.4



[PATCH 5/8] media: Add LE version of RGB LVDS formats

2018-04-19 Thread Jacopo Mondi
Some LVDS controller can output swapped versions of LVDS RGB formats.
Define and document them in the list of supported media bus formats

Signed-off-by: Jacopo Mondi 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 174 
 include/uapi/linux/media-bus-format.h   |   5 +-
 2 files changed, 178 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index 9fcabe7..9a5263c 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -1669,6 +1669,64 @@ JEIDA defined bit mapping will be named
   - b\ :sub:`2`
   - g\ :sub:`1`
   - r\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB666-1X7X3-SPWG_LE:
+
+  - MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE
+  - 0x101b
+  - 0
+  -
+  -
+  - b\ :sub:`2`
+  - g\ :sub:`1`
+  - r\ :sub:`0`
+* -
+  -
+  - 1
+  -
+  -
+  - b\ :sub:`3`
+  - g\ :sub:`2`
+  - r\ :sub:`1`
+* -
+  -
+  - 2
+  -
+  -
+  - b\ :sub:`4`
+  - g\ :sub:`3`
+  - r\ :sub:`2`
+* -
+  -
+  - 3
+  -
+  -
+  - b\ :sub:`5`
+  - g\ :sub:`4`
+  - r\ :sub:`3`
+* -
+  -
+  - 4
+  -
+  -
+  - d
+  - g\ :sub:`5`
+  - r\ :sub:`4`
+* -
+  -
+  - 5
+  -
+  -
+  - d
+  - b\ :sub:`0`
+  - r\ :sub:`5`
+* -
+  -
+  - 6
+  -
+  -
+  - d
+  - b\ :sub:`1`
+  - g\ :sub:`0`
 * .. _MEDIA-BUS-FMT-RGB888-1X7X4-SPWG:
 
   - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG
@@ -1727,6 +1785,64 @@ JEIDA defined bit mapping will be named
   - b\ :sub:`2`
   - g\ :sub:`1`
   - r\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB888-1X7X4-SPWG_LE:
+
+  - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE
+  - 0x101c
+  - 0
+  -
+  - r\ :sub:`6`
+  - b\ :sub:`2`
+  - g\ :sub:`1`
+  - r\ :sub:`0`
+* -
+  -
+  - 1
+  -
+  - r\ :sub:`7`
+  - b\ :sub:`3`
+  - g\ :sub:`2`
+  - r\ :sub:`1`
+* -
+  -
+  - 2
+  -
+  - g\ :sub:`6`
+  - b\ :sub:`4`
+  - g\ :sub:`3`
+  - r\ :sub:`2`
+* -
+  -
+  - 3
+  -
+  - g\ :sub:`7`
+  - b\ :sub:`5`
+  - g\ :sub:`4`
+  - r\ :sub:`3`
+* -
+  -
+  - 4
+  -
+  - b\ :sub:`6`
+  - d
+  - g\ :sub:`5`
+  - r\ :sub:`4`
+* -
+  -
+  - 5
+  -
+  - b\ :sub:`7`
+  - d
+  - b\ :sub:`0`
+  - r\ :sub:`5`
+* -
+  -
+  - 6
+  -
+  - d
+  - d
+  - b\ :sub:`1`
+  - g\ :sub:`0`
 * .. _MEDIA-BUS-FMT-RGB888-1X7X4-JEIDA:
 
   - MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA
@@ -1785,6 +1901,64 @@ JEIDA defined bit mapping will be named
   - b\ :sub:`4`
   - g\ :sub:`3`
   - r\ :sub:`2`
+* .. _MEDIA-BUS-FMT-RGB888-1X7X4-JEIDA_LE:
+
+  - MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE
+  - 0x101d
+  - 0
+  -
+  - r\ :sub:`0`
+  - b\ :sub:`4`
+  - g\ :sub:`3`
+  - r\ :sub:`2`
+* -
+  -
+  - 1
+  -
+  - r\ :sub:`1`
+  - b\ :sub:`5`
+  - g\ :sub:`4`
+  - r\ :sub:`3`
+* -
+  -
+  - 2
+  -
+  - g\ :sub:`0`
+  - b\ :sub:`6`
+  - g\ :sub:`5`
+  - r\ :sub:`4`
+* -
+  -
+  - 3
+  -
+  - g\ :sub:`1`
+  - b\ :sub:`7`
+  - g\ :sub:`6`
+  - r\ :sub:`5`
+* -
+  -
+  - 4
+  -
+  - b\ :sub:`0`
+  - d
+  - g\ :sub:`7`
+  - r\ :sub:`6`
+* -
+  -
+  - 5
+  -
+  - b\ :sub:`1`
+  - d
+  - b\ :sub:`2`
+  - r\ :sub:`7`
+* -
+  -
+  - 6
+  -
+  - d
+  - d
+  - b\ :sub:`3`
+  - g\ :sub:`2`
 
 .. raw:: latex
 
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 9e35117..5bea7c0 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -34,7 +34,7 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x101b */
+/* RGB - next is   0x101f */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -49,13 +49,16 @@
 #define MEDIA_BUS_FMT_RBG888_1X24  0x100e
 #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI   0x1015
 #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG0x1010
+#define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE 0x101b
 #define MEDIA_BUS_FMT_BGR888_1X24  0x1013
 #define MEDIA_BUS_FMT_GBR888_1X24  0x1014
 #define MEDIA_BUS_FMT_RGB888_1X24  0x100a
 #define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
 #define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
 #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011
+#define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE 0x101c
 #define 

[PATCH 8/8] drm: connector: Remove DRM_BUS_FLAG_DATA_* flags

2018-04-19 Thread Jacopo Mondi
DRM_BUS_FLAG_DATA_* flags, defined in drm_connector.h header file are
used to swap ordering of LVDS RGB format to accommodate DRM objects
that need to handle LVDS components ordering.

Now that the only 2 users of DRM_BUS_FLAG_DATA_* flags have been ported
to use the newly introduced MEDIA_BUS_FMT_RGB888_1X7X*_LE media bus
formats, remove them.

Signed-off-by: Jacopo Mondi 
---
 include/drm/drm_connector.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 675cc3f..9e0d6d5 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -286,10 +286,6 @@ struct drm_display_info {
 #define DRM_BUS_FLAG_PIXDATA_POSEDGE   (1<<2)
 /* drive data on neg. edge */
 #define DRM_BUS_FLAG_PIXDATA_NEGEDGE   (1<<3)
-/* data is transmitted MSB to LSB on the bus */
-#define DRM_BUS_FLAG_DATA_MSB_TO_LSB   (1<<4)
-/* data is transmitted LSB to MSB on the bus */
-#define DRM_BUS_FLAG_DATA_LSB_TO_MSB   (1<<5)
 
/**
 * @bus_flags: Additional information (like pixel signal polarity) for
-- 
2.7.4



Re: [PATCH v5 2/6] dt-bindings: reset: renesas,rzn1-reboot: document RZ/N1 reboot driver

2018-04-19 Thread Geert Uytterhoeven
Hi Michel,

On Tue, Apr 17, 2018 at 1:04 PM, Michel Pollet
 wrote:
> The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
> as part of the sysctrl MFD to handle rebooting the CA7 cores.
> This documents the driver bindings.
>
> Signed-off-by: Michel Pollet 
> ---
>  .../devicetree/bindings/power/renesas,rzn1-reboot.txt   | 17 
> +
>  1 file changed, 17 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
>
> diff --git a/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt 
> b/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
> new file mode 100644
> index 000..a553864
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
> @@ -0,0 +1,17 @@
> +DT bindings for the Renesas RZ/N1 Reboot Driver
> +
> +== Reboot Driver Node ==
> +
> +The reboot driver allows restarting the RZ/N1.
> +
> +Bindings:
> ++ Required:
> +   compatible = "renesas,r9a06g032-reboot", "renesas,rzn1-reboot";
> +
> +Example:
> +   reboot@4000c120 {
> +   compatible = "renesas,r9a06g032-reboot",
> +   "renesas,rzn1-reboot";
> +   reg = <0x4000c120 4>,
> +   <0x4000c198 4>;
> +   };

I'm afraid this will become a messy DT structure, once device nodes for the
registers just before, between, and after these 2 registers will be added...

There's really only a single multi-function sysctrl device here, using a 4 KiB
block at 0x4000c000, containing a mix of:
  1. Clock Control Registers (Table 6.1 [*]),
  2. Reset Control (Table 6.2 [*]),
  3. System Configuration (Table 6.3 [*]).

Looks a lot like the mix used in the Amiga's custom chip block at 0xdff000,
which also cannot be separated into logical blocks without listing individual
registers ;-)

So I suggest to have a DT binding for the whole block, and a clock driver
matching against the whole block, registering all clocks and a small reset
controller driver.

[*] RZ/N1D Group, RZ/N1S Group, RZ/N1L Group User’s Manual: System
Introduction, Multiplexing, Electrical and Mechanical Information.

https://www.renesas.com/en-eu/doc/products/mpumcu/doc/rz/r01uh0750ej0090-rzn1-introduction.pdf

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v3 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

2018-04-19 Thread Simon Horman
On Wed, Apr 18, 2018 at 08:20:57PM +0200, Wolfram Sang wrote:
> Early revisions of certain SoCs cannot do multiple DMA RX streams in
> parallel. To avoid data corruption, only allow one DMA RX channel and
> fall back to PIO, if needed.
> 
> Signed-off-by: Wolfram Sang 
> Reviewed-by: Yoshihiro Shimoda 
> Tested-by: Nguyen Viet Dung 

Reviewed-by: Simon Horman 



<    1   2