[PATCH 3/3] ARM: dts: wheat: add QSPI support

2016-09-02 Thread Sergei Shtylyov
Define the Wheat board dependent part of the QSPI device node.
Add device nodes for Spansion S25FL512S SPI flash and MTD partitions on it.

Based  on the original (and large) patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7792-wheat.dts |   43 
 1 file changed, 43 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792-wheat.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7792-wheat.dts
+++ renesas/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -132,6 +132,11 @@
function = "sdhi0";
};
 
+   qspi_pins: qspi {
+   groups = "qspi_ctrl", "qspi_data4";
+   function = "qspi";
+   };
+
du0_pins: du0 {
groups = "du0_rgb888", "du0_sync", "du0_disp";
function = "du0";
@@ -173,6 +178,44 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   flash@0 {
+   compatible = "spansion,s25fl512s", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <3000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   spi-cpol;
+   spi-cpha;
+   m25p,fast-read;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "loader";
+   reg = <0x 0x0004>;
+   read-only;
+   };
+   partition@4 {
+   label = "user";
+   reg = <0x0004 0x0040>;
+   read-only;
+   };
+   partition@44 {
+   label = "flash";
+   reg = <0x0044 0x03bc>;
+   };
+   };
+   };
+};
+
  {
status = "okay";
clock-frequency = <40>;



[PATCH 2/3] ARM: dts: r8a7792: add QSPI support

2016-09-02 Thread Sergei Shtylyov
Define the generic R8A7792 part of the QSPI device node.

Based  on the original (and large) patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7792.dtsi |   16 
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -25,6 +25,7 @@
i2c3 = 
i2c4 = 
i2c5 = 
+   spi0 = 
vin0 = 
vin1 = 
vin2 = 
@@ -554,6 +555,21 @@
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
+   };
+
+   qspi: spi@e6b1 {
+   compatible = "renesas,qspi-r8a7792", "renesas,qspi";
+   reg = <0 0xe6b1 0 0x2c>;
+   interrupts = ;
+   clocks = <_clks R8A7792_CLK_QSPI_MOD>;
+   dmas = < 0x17>, < 0x18>,
+  < 0x17>, < 0x18>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7792_PD_ALWAYS_ON>;
+   num-cs = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
};
 
du: display@feb0 {



[PATCH 1/3] ARM: dts: r8a7792: add QSPI clock

2016-09-02 Thread Sergei Shtylyov
Describe the QSPI clock in the R8A7792 device tree.

Based  on the original (and large) patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7792.dtsi |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -860,6 +860,7 @@
clocks = <_clk>, <_clk>, <_clk>, <_clk>,
 <_clk>, <_clk>, <_clk>, <_clk>,
 <_clk>, <_clk>, <_clk>, <_clk>,
+<_clocks R8A7792_CLK_QSPI>,
 <_clk>, <_clk>, <_clk>, <_clk>,
 <_clk>, <_clk>, <_clk>, <_clk>;
#clock-cells = <1>;
@@ -870,6 +871,7 @@
R8A7792_CLK_GPIO1 R8A7792_CLK_GPIO0
R8A7792_CLK_GPIO11 R8A7792_CLK_GPIO10
R8A7792_CLK_CAN1 R8A7792_CLK_CAN0
+   R8A7792_CLK_QSPI_MOD
R8A7792_CLK_GPIO9 R8A7792_CLK_GPIO8
R8A7792_CLK_I2C5 R8A7792_CLK_I2C4
R8A7792_CLK_I2C3 R8A7792_CLK_I2C2
@@ -879,8 +881,9 @@
"gpio7", "gpio6", "gpio5", "gpio4",
"gpio3", "gpio2", "gpio1", "gpio0",
"gpio11", "gpio10", "can1", "can0",
-   "gpio9", "gpio8", "i2c5", "i2c4",
-   "i2c3", "i2c2", "i2c1", "i2c0";
+   "qspi_mod", "gpio9", "gpio8",
+   "i2c5", "i2c4", "i2c3", "i2c2",
+   "i2c1", "i2c0";
};
};
 



[PATCH 0/3] Add R8A7792/Wheat QSPI support

2016-09-02 Thread Sergei Shtylyov
Hello.

   Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160902-v4.8-rc4' tag plus the Wheat board patches posted this
week. We're adding the R8A7792/Wheat QSPI clocks and device nodes. The board
patch depends on the PFC driver QSPI patch in order for the QSPI pins to be
configured...

[1/3] ARM: dts: r8a7792: add QSPI clock
[2/3] ARM: dts: r8a7792: add QSPI support
[3/3] ARM: dts: wheat: add QSPI support

WBR, Sergei



[PATCH resend] pinctrl: sh-pfc: r8a7792: add QSPI pin groups

2016-09-02 Thread Sergei Shtylyov
Add QSPI pin groups to the R8A7792 PFC driver.

Based  on the original (and large) patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
repo...

Disregard the patch just posted with the stale subject please.

 drivers/pinctrl/sh-pfc/pfc-r8a7792.c |   33 +
 1 file changed, 33 insertions(+)

Index: linux-pinctrl/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
===
--- linux-pinctrl.orig/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
+++ linux-pinctrl/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
@@ -1034,6 +1034,29 @@ static const unsigned int lbsc_ex_cs5_pi
 static const unsigned int lbsc_ex_cs5_mux[] = {
EX_CS5_N_MARK,
 };
+/* - QSPI --- 
*/
+static const unsigned int qspi_ctrl_pins[] = {
+   /* SPCLK, SSL */
+   RCAR_GP_PIN(3, 25), RCAR_GP_PIN(3, 26),
+};
+static const unsigned int qspi_ctrl_mux[] = {
+   SPCLK_MARK, SSL_MARK,
+};
+static const unsigned int qspi_data2_pins[] = {
+   /* MOSI_IO0, MISO_IO1 */
+   RCAR_GP_PIN(3, 4), RCAR_GP_PIN(3, 5),
+};
+static const unsigned int qspi_data2_mux[] = {
+   MOSI_IO0_MARK, MISO_IO1_MARK,
+};
+static const unsigned int qspi_data4_pins[] = {
+   /* MOSI_IO0, MISO_IO1, IO2, IO3 */
+   RCAR_GP_PIN(3, 4), RCAR_GP_PIN(3, 5), RCAR_GP_PIN(3, 23),
+   RCAR_GP_PIN(3, 24),
+};
+static const unsigned int qspi_data4_mux[] = {
+   MOSI_IO0_MARK, MISO_IO1_MARK, IO2_MARK, IO3_MARK,
+};
 /* - SCIF0 -- 
*/
 static const unsigned int scif0_data_pins[] = {
/* RX, TX */
@@ -1585,6 +1608,9 @@ static const struct sh_pfc_pin_group pin
SH_PFC_PIN_GROUP(lbsc_ex_cs3),
SH_PFC_PIN_GROUP(lbsc_ex_cs4),
SH_PFC_PIN_GROUP(lbsc_ex_cs5),
+   SH_PFC_PIN_GROUP(qspi_ctrl),
+   SH_PFC_PIN_GROUP(qspi_data2),
+   SH_PFC_PIN_GROUP(qspi_data4),
SH_PFC_PIN_GROUP(scif0_data),
SH_PFC_PIN_GROUP(scif0_clk),
SH_PFC_PIN_GROUP(scif0_ctrl),
@@ -1708,6 +1734,12 @@ static const char * const lbsc_groups[]
"lbsc_ex_cs5",
 };
 
+static const char * const qspi_groups[] = {
+   "qspi_ctrl",
+   "qspi_data2",
+   "qspi_data4",
+};
+
 static const char * const scif0_groups[] = {
"scif0_data",
"scif0_clk",
@@ -1808,6 +1840,7 @@ static const struct sh_pfc_function pinm
SH_PFC_FUNCTION(du1),
SH_PFC_FUNCTION(intc),
SH_PFC_FUNCTION(lbsc),
+   SH_PFC_FUNCTION(qspi),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif3),
SH_PFC_FUNCTION(sdhi0),


[PATCH] pinctrl: sh-pfc: r8a7792: add DU pin groups

2016-09-02 Thread Sergei Shtylyov
Add QSPI pin groups to the R8A7792 PFC driver.

Based  on the original (and large) patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
repo...

 drivers/pinctrl/sh-pfc/pfc-r8a7792.c |   33 +
 1 file changed, 33 insertions(+)

Index: linux-pinctrl/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
===
--- linux-pinctrl.orig/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
+++ linux-pinctrl/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
@@ -1034,6 +1034,29 @@ static const unsigned int lbsc_ex_cs5_pi
 static const unsigned int lbsc_ex_cs5_mux[] = {
EX_CS5_N_MARK,
 };
+/* - QSPI --- 
*/
+static const unsigned int qspi_ctrl_pins[] = {
+   /* SPCLK, SSL */
+   RCAR_GP_PIN(3, 25), RCAR_GP_PIN(3, 26),
+};
+static const unsigned int qspi_ctrl_mux[] = {
+   SPCLK_MARK, SSL_MARK,
+};
+static const unsigned int qspi_data2_pins[] = {
+   /* MOSI_IO0, MISO_IO1 */
+   RCAR_GP_PIN(3, 4), RCAR_GP_PIN(3, 5),
+};
+static const unsigned int qspi_data2_mux[] = {
+   MOSI_IO0_MARK, MISO_IO1_MARK,
+};
+static const unsigned int qspi_data4_pins[] = {
+   /* MOSI_IO0, MISO_IO1, IO2, IO3 */
+   RCAR_GP_PIN(3, 4), RCAR_GP_PIN(3, 5), RCAR_GP_PIN(3, 23),
+   RCAR_GP_PIN(3, 24),
+};
+static const unsigned int qspi_data4_mux[] = {
+   MOSI_IO0_MARK, MISO_IO1_MARK, IO2_MARK, IO3_MARK,
+};
 /* - SCIF0 -- 
*/
 static const unsigned int scif0_data_pins[] = {
/* RX, TX */
@@ -1585,6 +1608,9 @@ static const struct sh_pfc_pin_group pin
SH_PFC_PIN_GROUP(lbsc_ex_cs3),
SH_PFC_PIN_GROUP(lbsc_ex_cs4),
SH_PFC_PIN_GROUP(lbsc_ex_cs5),
+   SH_PFC_PIN_GROUP(qspi_ctrl),
+   SH_PFC_PIN_GROUP(qspi_data2),
+   SH_PFC_PIN_GROUP(qspi_data4),
SH_PFC_PIN_GROUP(scif0_data),
SH_PFC_PIN_GROUP(scif0_clk),
SH_PFC_PIN_GROUP(scif0_ctrl),
@@ -1708,6 +1734,12 @@ static const char * const lbsc_groups[]
"lbsc_ex_cs5",
 };
 
+static const char * const qspi_groups[] = {
+   "qspi_ctrl",
+   "qspi_data2",
+   "qspi_data4",
+};
+
 static const char * const scif0_groups[] = {
"scif0_data",
"scif0_clk",
@@ -1808,6 +1840,7 @@ static const struct sh_pfc_function pinm
SH_PFC_FUNCTION(du1),
SH_PFC_FUNCTION(intc),
SH_PFC_FUNCTION(lbsc),
+   SH_PFC_FUNCTION(qspi),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif3),
SH_PFC_FUNCTION(sdhi0),



[PATCHv3 0/6] Fix rcar-vin field handling

2016-09-02 Thread Niklas Söderlund
Hi,

This series deals with how fields are handled in the rcar-vin driver.  
The current state is that the user is forced to use whatever field type 
is set by the subdevice. This series allows the user to freely choose 
the filed type.

It fixes the current handling of V4L2_FIELD_INTERLACED so that it 
depends on the current video standard to select between TB or BT mode 
(if the video standard can be determined that is). It also adds support 
for V4L2_FIELD_ALTERNATE.

All work is based on top of media-tree and is tested on Koelsch. Output 
of 'v4l2-compliance -fs' is attached bellow and I have tested all fields 
using qv4l2 and it looks OK to me. I need to disable 'Enable Video 
Scaling' in the 'Capture' Menu for ODD/EVEN/ALTERNATE or I get a 
horizontally stretched image. Also for ALTERNATE the 1 line difference 
between the fields are noticeable. The image jumps up/down 1 line for 
each other field, but I guess that is normal since the fields are 
different right?

# v4l2-compliance -d 2 -fs
v4l2-compliance SHA   : a737a6161485fffb70bf51e4fd7f6e2d910174c1

Driver Info:
Driver name   : rcar_vin
Card type : R_Car_VIN
Bus info  : platform:e6ef1000.video
Driver version: 4.8.0
Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/video2 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 1

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:

Streaming ioctls:
test read/write: OK
test MMAP: OKg
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device

Stream using all formats:
test MMAP for Format NV16, Frame Size 2x4:
Crop 720x576@0x0, Compose 6x4@0x0, Stride 32, Field None: OKg
Crop 720x288@0x0, Compose 6x4@0x0, Stride 32, Field Top: OKg
Crop 720x288@0x0, Compose 6x4@0x0, Stride 32, Field Bottom: OKg
Crop 720x288@0x0, Compose 6x4@0x0, Stride 32, Field Interlaced: 
OKg
Crop 720x288@0x0, Compose 6x4@0x0, Stride 32, Field 
Alternating: OKg
Crop 720x288@0x0, Compose 6x4@0x0, Stride 32, Field Interlaced 
Top-Bottom: OKg
Crop 720x288@0x0, Compose 6x4@0x0, Stride 32, Field Interlaced 
Bottom-Top: OKg
  

[PATCHv3 1/6] media: adv7180: fill in mbus format in set_fmt

2016-09-02 Thread Niklas Söderlund
If the V4L2_SUBDEV_FORMAT_TRY is used in set_fmt the width, height etc
would not be filled.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/i2c/adv7180.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 515ea6a..50efecc 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -711,6 +711,7 @@ static int adv7180_set_pad_format(struct v4l2_subdev *sd,
 {
struct adv7180_state *state = to_state(sd);
struct v4l2_mbus_framefmt *framefmt;
+   int ret;
 
switch (format->format.field) {
case V4L2_FIELD_NONE:
@@ -722,8 +723,9 @@ static int adv7180_set_pad_format(struct v4l2_subdev *sd,
break;
}
 
+   ret = adv7180_mbus_fmt(sd,  >format);
+
if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
-   framefmt = >format;
if (state->field != format->format.field) {
state->field = format->format.field;
adv7180_set_power(state, false);
@@ -735,7 +737,7 @@ static int adv7180_set_pad_format(struct v4l2_subdev *sd,
*framefmt = format->format;
}
 
-   return adv7180_mbus_fmt(sd, framefmt);
+   return ret;
 }
 
 static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
-- 
2.9.3



[PATCHv3 5/6] media: rcar-vin: fix height for TOP and BOTTOM fields

2016-09-02 Thread Niklas Söderlund
The height used for V4L2_FIELD_TOP and V4L2_FIELD_BOTTOM where wrong.
The frames only contain one field so the height should be half of the
frame.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 47d8d97..1392514 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -125,6 +125,8 @@ static int rvin_reset_format(struct rvin_dev *vin)
switch (vin->format.field) {
case V4L2_FIELD_TOP:
case V4L2_FIELD_BOTTOM:
+   vin->format.height /= 2;
+   break;
case V4L2_FIELD_NONE:
case V4L2_FIELD_INTERLACED_TB:
case V4L2_FIELD_INTERLACED_BT:
@@ -220,21 +222,13 @@ static int __rvin_try_format(struct rvin_dev *vin,
/* Limit to source capabilities */
__rvin_try_format_source(vin, which, pix, source);
 
-   /* If source can't match format try if VIN can scale */
-   if (source->width != rwidth || source->height != rheight)
-   rvin_scale_try(vin, pix, rwidth, rheight);
-
-   /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
-   walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
-
-   /* Limit to VIN capabilities */
-   v4l_bound_align_image(>width, 2, RVIN_MAX_WIDTH, walign,
- >height, 4, RVIN_MAX_HEIGHT, 2, 0);
-
switch (pix->field) {
-   case V4L2_FIELD_NONE:
case V4L2_FIELD_TOP:
case V4L2_FIELD_BOTTOM:
+   pix->height /= 2;
+   source->height /= 2;
+   break;
+   case V4L2_FIELD_NONE:
case V4L2_FIELD_INTERLACED_TB:
case V4L2_FIELD_INTERLACED_BT:
case V4L2_FIELD_INTERLACED:
@@ -244,6 +238,17 @@ static int __rvin_try_format(struct rvin_dev *vin,
break;
}
 
+   /* If source can't match format try if VIN can scale */
+   if (source->width != rwidth || source->height != rheight)
+   rvin_scale_try(vin, pix, rwidth, rheight);
+
+   /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
+   walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
+
+   /* Limit to VIN capabilities */
+   v4l_bound_align_image(>width, 2, RVIN_MAX_WIDTH, walign,
+ >height, 4, RVIN_MAX_HEIGHT, 2, 0);
+
pix->bytesperline = max_t(u32, pix->bytesperline,
  rvin_format_bytesperline(pix));
pix->sizeimage = max_t(u32, pix->sizeimage,
-- 
2.9.3



[PATCHv3 6/6] media: rcar-vin: add support for V4L2_FIELD_ALTERNATE

2016-09-02 Thread Niklas Söderlund
The HW can capture both ODD and EVEN fields in separate buffers so it's
possible to support V4L2_FIELD_ALTERNATE. This patch add support for
this mode.

At probe time and when S_STD is called the driver will default to use
V4L2_FIELD_INTERLACED if the subdevice reports V4L2_FIELD_ALTERNATE. The
driver will only change the field type if the subdevice implements
G_STD, if not it will keep the default at V4L2_FIELD_ALTERNATE.

The user can always explicitly ask for V4L2_FIELD_ALTERNATE in S_FMT and
the driver will use that field format.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  | 26 --
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 13 +
 2 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index d57801b..1da95ab 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -95,6 +95,7 @@
 /* Video n Module Status Register bits */
 #define VNMS_FBS_MASK  (3 << 3)
 #define VNMS_FBS_SHIFT 3
+#define VNMS_FS(1 << 2)
 #define VNMS_AV(1 << 1)
 #define VNMS_CA(1 << 0)
 
@@ -156,6 +157,7 @@ static int rvin_setup(struct rvin_dev *vin)
case V4L2_FIELD_INTERLACED_BT:
vnmc = VNMC_IM_FULL | VNMC_FOC;
break;
+   case V4L2_FIELD_ALTERNATE:
case V4L2_FIELD_NONE:
if (vin->continuous) {
vnmc = VNMC_IM_ODD_EVEN;
@@ -329,15 +331,26 @@ static bool rvin_capture_active(struct rvin_dev *vin)
return rvin_read(vin, VNMS_REG) & VNMS_CA;
 }
 
-static int rvin_get_active_slot(struct rvin_dev *vin)
+static int rvin_get_active_slot(struct rvin_dev *vin, u32 vnms)
 {
if (vin->continuous)
-   return (rvin_read(vin, VNMS_REG) & VNMS_FBS_MASK)
-   >> VNMS_FBS_SHIFT;
+   return (vnms & VNMS_FBS_MASK) >> VNMS_FBS_SHIFT;
 
return 0;
 }
 
+static enum v4l2_field rvin_get_active_field(struct rvin_dev *vin, u32 vnms)
+{
+   if (vin->format.field == V4L2_FIELD_ALTERNATE) {
+   /* If FS is set it's a Even field */
+   if (vnms & VNMS_FS)
+   return V4L2_FIELD_BOTTOM;
+   return V4L2_FIELD_TOP;
+   }
+
+   return vin->format.field;
+}
+
 static void rvin_set_slot_addr(struct rvin_dev *vin, int slot, dma_addr_t addr)
 {
const struct rvin_video_format *fmt;
@@ -878,7 +891,7 @@ static bool rvin_fill_hw(struct rvin_dev *vin)
 static irqreturn_t rvin_irq(int irq, void *data)
 {
struct rvin_dev *vin = data;
-   u32 int_status;
+   u32 int_status, vnms;
int slot;
unsigned int sequence, handled = 0;
unsigned long flags;
@@ -905,7 +918,8 @@ static irqreturn_t rvin_irq(int irq, void *data)
}
 
/* Prepare for capture and update state */
-   slot = rvin_get_active_slot(vin);
+   vnms = rvin_read(vin, VNMS_REG);
+   slot = rvin_get_active_slot(vin, vnms);
sequence = vin->sequence++;
 
vin_dbg(vin, "IRQ %02d: %d\tbuf0: %c buf1: %c buf2: %c\tmore: %d\n",
@@ -920,7 +934,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
goto done;
 
/* Capture frame */
-   vin->queue_buf[slot]->field = vin->format.field;
+   vin->queue_buf[slot]->field = rvin_get_active_field(vin, vnms);
vin->queue_buf[slot]->sequence = sequence;
vin->queue_buf[slot]->vb2_buf.timestamp = ktime_get_ns();
vb2_buffer_done(>queue_buf[slot]->vb2_buf, VB2_BUF_STATE_DONE);
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 1392514..61e9b59 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -122,9 +122,21 @@ static int rvin_reset_format(struct rvin_dev *vin)
vin->format.colorspace  = mf->colorspace;
vin->format.field   = mf->field;
 
+   /*
+* If the subdevice uses ALTERNATE field mode and G_STD is
+* implemented use the VIN HW to combine the two fields to
+* one INTERLACED frame. The ALTERNATE field mode can still
+* be requested in S_FMT and be respected, this is just the
+* default which is applied at probing or when S_STD is called.
+*/
+   if (vin->format.field == V4L2_FIELD_ALTERNATE &&
+   v4l2_subdev_has_op(vin_to_source(vin), video, g_std))
+   vin->format.field = V4L2_FIELD_INTERLACED;
+
switch (vin->format.field) {
case V4L2_FIELD_TOP:
case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_ALTERNATE:
vin->format.height /= 2;
break;
case V4L2_FIELD_NONE:
@@ -225,6 +237,7 @@ static int __rvin_try_format(struct rvin_dev 

[PATCHv3 2/6] media: rcar-vin: make V4L2_FIELD_INTERLACED standard dependent

2016-09-02 Thread Niklas Söderlund
The field V4L2_FIELD_INTERLACED is standard dependent and should not
unconditionally be equivalent to V4L2_FIELD_INTERLACED_TB.

This patch adds a check to see if the video standard can be obtained and
if it's a 60 Hz format. If the condition is met V4L2_FIELD_INTERLACED
is treated as V4L2_FIELD_INTERLACED_BT if not as
V4L2_FIELD_INTERLACED_TB.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 46abdb0..d57801b 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -131,6 +131,7 @@ static u32 rvin_read(struct rvin_dev *vin, u32 offset)
 static int rvin_setup(struct rvin_dev *vin)
 {
u32 vnmc, dmr, dmr2, interrupts;
+   v4l2_std_id std;
bool progressive = false, output_is_yuv = false, input_is_yuv = false;
 
switch (vin->format.field) {
@@ -141,6 +142,14 @@ static int rvin_setup(struct rvin_dev *vin)
vnmc = VNMC_IM_EVEN;
break;
case V4L2_FIELD_INTERLACED:
+   /* Default to TB */
+   vnmc = VNMC_IM_FULL;
+   /* Use BT if video standard can be read and is 60 Hz format */
+   if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
+   if (std & V4L2_STD_525_60)
+   vnmc = VNMC_IM_FULL | VNMC_FOC;
+   }
+   break;
case V4L2_FIELD_INTERLACED_TB:
vnmc = VNMC_IM_FULL;
break;
-- 
2.9.3



Re: [PATCH v4 1/4] arm64: dts: h3ulcb: enable GPIO leds

2016-09-02 Thread Sergei Shtylyov

Hello.

On 09/02/2016 03:05 PM, Vladimir Barinov wrote:


This supports GPIO leds on H3ULCB board

Signed-off-by: Vladimir Barinov 
Reviewed-by: Geert Uytterhoeven 
---
Changes in version 3:
- initially added
Changes in version 4:
- removed led4 in favor of gpio-keys
- added label

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index fb694b8..3329f78 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -31,6 +31,19 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
+
+   leds {
+   compatible = "gpio-leds";
+
+   led5 {
+   label = "LED5";


   Do we need the "label" prop? Based on the feedback to my former LED 
patches, no?



+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+   led6 {
+   label = "LED6";
+   gpios = < 13 GPIO_ACTIVE_HIGH>;
+   };
+   };
 };

 _clk {


MBR, Sergei



[PATCH v5 4/4] arm64: dts: h3ulcb: Sound SSI support

2016-09-02 Thread Vladimir Barinov
This supports SSI sound for H3ULCB board.
SSI DMA mode used. CS2000 used as AUDIO_CLK_B.

Signed-off-by: Vladimir Barinov 
Acked-by: Kuninori Morimoto 
---
Changes in version 3:
- initially added
Changes in version 4:
- added comment for audio_clkout
Changes in version 5:
- renamed x12_clk node to x12
- renamed clk_multiplier node to clk-multiplier
- renamed audio_clkout node to audio-clkout
- renamed sound_clk node to sound-clk

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 115 +
 1 file changed, 115 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index bbd7928..a254231 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -45,6 +45,12 @@
};
};
 
+   x12_clk: x12 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <24576000>;
+   };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
 
@@ -68,6 +74,32 @@
states = <330 1
  180 0>;
};
+
+   audio_clkout: audio-clkout {
+   /*
+* This is same as <_sound 0>
+* but needed to avoid cs2000/rcar_sound probe dead-lock
+*/
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <11289600>;
+   };
+
+   rsnd_ak4613: sound {
+   compatible = "simple-audio-card";
+
+   simple-audio-card,format = "left_j";
+   simple-audio-card,bitclock-master = <>;
+   simple-audio-card,frame-master = <>;
+
+   sndcpu: simple-audio-card,cpu {
+   sound-dai = <_sound>;
+   };
+
+   sndcodec: simple-audio-card,codec {
+   sound-dai = <>;
+   };
+   };
 };
 
 _clk {
@@ -113,6 +141,17 @@
power-source = <1800>;
};
 
+   sound_pins: sound {
+   groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
+   function = "ssi";
+   };
+
+   sound_clk_pins: sound-clk {
+   groups = "audio_clk_a_a", "audio_clk_b_a", "audio_clk_c_a",
+"audio_clkout_a", "audio_clkout3_a";
+   function = "audio_clk";
+   };
+
usb1_pins: usb1 {
groups = "usb1";
function = "usb1";
@@ -136,6 +176,73 @@
pinctrl-names = "default";
 
status = "okay";
+
+   clock-frequency = <10>;
+
+   ak4613: codec@10 {
+   compatible = "asahi-kasei,ak4613";
+   #sound-dai-cells = <0>;
+   reg = <0x10>;
+   clocks = <_sound 3>;
+
+   asahi-kasei,in1-single-end;
+   asahi-kasei,in2-single-end;
+   asahi-kasei,out1-single-end;
+   asahi-kasei,out2-single-end;
+   asahi-kasei,out3-single-end;
+   asahi-kasei,out4-single-end;
+   asahi-kasei,out5-single-end;
+   asahi-kasei,out6-single-end;
+   };
+
+   cs2000: clk-multiplier@4f {
+   #clock-cells = <0>;
+   compatible = "cirrus,cs2000-cp";
+   reg = <0x4f>;
+   clocks = <_clkout>, <_clk>;
+   clock-names = "clk_in", "ref_clk";
+
+   assigned-clocks = <>;
+   assigned-clock-rates = <24576000>; /* 1/1 divide */
+   };
+};
+
+_sound {
+   pinctrl-0 = <_pins _clk_pins>;
+   pinctrl-names = "default";
+
+   /* Single DAI */
+   #sound-dai-cells = <0>;
+
+   /* audio_clkout0/1/2/3 */
+   #clock-cells = <1>;
+   clock-frequency = <11289600>;
+
+   status = "okay";
+
+   /* update  to  */
+   clocks = < CPG_MOD 1005>,
+< CPG_MOD 1006>, < CPG_MOD 1007>,
+< CPG_MOD 1008>, < CPG_MOD 1009>,
+< CPG_MOD 1010>, < CPG_MOD 1011>,
+< CPG_MOD 1012>, < CPG_MOD 1013>,
+< CPG_MOD 1014>, < CPG_MOD 1015>,
+< CPG_MOD 1022>, < CPG_MOD 1023>,
+< CPG_MOD 1024>, < CPG_MOD 1025>,
+< CPG_MOD 1026>, < CPG_MOD 1027>,
+< CPG_MOD 1028>, < CPG_MOD 1029>,
+< CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1019>, < CPG_MOD 1018>,
+<_clk_a>, <>,
+<_clk_c>,
+< CPG_CORE R8A7795_CLK_S0D4>;
+
+   rcar_sound,dai {
+   dai0 {
+   playback = <  >;
+   capture  = <  >;
+   };
+   };
 };
 
  {
@@ -150,11 +257,19 @@
status = "okay";
 };
 
+ {
+   shared-pin;
+};
+
  {
timeout-sec = <60>;

[PATCH v5 3/4] arm64: dts: h3ulcb: enable SDHI0

2016-09-02 Thread Vladimir Barinov
This supports SDHI0 on H3ULCB board SD card slot

Signed-off-by: Vladimir Barinov 
Reviewed-by: Geert Uytterhoeven 
---
Changes in version 3:
- initially added
Changes in version 4:
- added sd-uhs-sdr50
Changes in version 5:
- nothing

---
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 6842597..babe41c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -44,6 +44,30 @@
gpios = < 13 GPIO_ACTIVE_HIGH>;
};
};
+
+   vcc_sdhi0: regulator-vcc-sdhi0 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI0 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 2 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vccq_sdhi0: regulator-vccq-sdhi0 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI0 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
 };
 
 _clk {
@@ -78,6 +102,18 @@
function = "avb";
};
 
+   sdhi0_pins_3v3: sd0_3v3 {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_1v8: sd0_1v8 {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
+   };
+
usb1_pins: usb1 {
groups = "usb1";
function = "usb1";
@@ -108,6 +144,19 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins_3v3>;
+   pinctrl-1 = <_pins_1v8>;
+   pinctrl-names = "default", "state_uhs";
+
+   vmmc-supply = <_sdhi0>;
+   vqmmc-supply = <_sdhi0>;
+   cd-gpios = < 12 GPIO_ACTIVE_LOW>;
+   bus-width = <4>;
+   sd-uhs-sdr50;
+   status = "okay";
+};
+
  {
timeout-sec = <60>;
status = "okay";
-- 
1.9.1



[PATCH v5 2/4] arm64: dts: h3ulcb: enable GPIO keys

2016-09-02 Thread Vladimir Barinov
This supports GPIO keys on H3ULCB board

Signed-off-by: Vladimir Barinov 
---
Changes in version 4:
- initially added
Changes in version 5:
- nothing

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 14 +
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index fb694b8..3329f78 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -12,6 +12,7 @@
 /dts-v1/;
 #include "r8a7795.dtsi"
 #include 
+#include 
 
 / {
model = "Renesas H3ULCB board based on r8a7795";
@@ -31,6 +31,18 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
+
+   keyboard {
+   compatible = "gpio-keys";
+
+   key-1 {
+   linux,code = ;
+   label = "SW3";
+   wakeup-source;
+   debounce-interval = <20>;
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
+   };
 
leds {
compatible = "gpio-leds";
-- 
1.9.1



[PATCH v5 1/4] arm64: dts: h3ulcb: enable GPIO leds

2016-09-02 Thread Vladimir Barinov
This supports GPIO leds on H3ULCB board

Signed-off-by: Vladimir Barinov 
Reviewed-by: Geert Uytterhoeven 
---
Changes in version 3:
- initially added
Changes in version 4:
- removed led4 in favor of gpio-keys
- added label
Changes in version 5:
- nothing

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index fb694b8..3329f78 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -31,6 +31,19 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
+
+   leds {
+   compatible = "gpio-leds";
+
+   led5 {
+   label = "LED5";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+   led6 {
+   label = "LED6";
+   gpios = < 13 GPIO_ACTIVE_HIGH>;
+   };
+   };
 };
 
 _clk {
-- 
1.9.1



Re: [PATCH] [media] rcar-vin: add legacy mode for wrong media bus formats

2016-09-02 Thread Niklas Söderlund
On 2016-08-22 11:12:59 +0200, Hans Verkuil wrote:
> On 07/20/2016 02:36 PM, Hans Verkuil wrote:
> > On 07/20/2016 02:29 PM, Niklas Söderlund wrote:
> >> Hi Hans,
> >>
> >> Thanks for your feedback.
> >>
> >> On 2016-07-20 11:48:40 +0200, Hans Verkuil wrote:
> >>> On 07/08/2016 12:43 PM, Niklas Söderlund wrote:
>  A recent bugfix to adv7180 brought to light that the rcar-vin driver are
>  looking for the wrong media bus format. It was looking for a YUVU format
>  but then expecting UYVY data. The bugfix for adv7180 will break the
>  usage of rcar-vin together with a adv7180 as found on Renesas R-Car2
>  Koelsch boards for example.
> 
>  This patch fix the rcar-vin driver to look for the correct UYVU formats
>  and adds a legacy mode. The legacy mode is needed since I don't know if
>  other devices provide a incorrect media bus format and I don't want to
>  break any working configurations. Hopefully the legacy mode can be
>  removed sometime in the future.
> >>>
> >>> I'd rather have a version without the legacy code. You have to assume that
> >>> subdevs return correct values otherwise what's the point of the mediabus
> >>> formats?
> >>>
> >>> So this is simply an adv7180 bug fix + this r-car fix to stay consistent
> >>> with the adv7180.
> >>
> >> On principal I agree with you. My goal with this patch is just to make
> >> sure there is no case where the rcar-vin driver won't work with the
> >> adv7180. The plan was to drop the legacy mode in a separate patch after
> >> both the adv7182 and rcar-vin patches where picked up.
> >>
> >> I'm happy to drop the 'legacy support' for the wrong formats from this
> >> patch as long as I can be sure that there is no breaking. Should I
> >> rewrite this patch to drop the wrong formats and submit it as a series
> >> together with the adv7180 patch so they can be picked up together? Or do
> >> you know of a better way?
> > 
> > Why not combine this patch and the adv7180 patch in a single patch? Just 
> > keep
> > Steve's Signed-off-by line together with yours. That way everything stays
> > in sync. The only other user of the adv7180 doesn't look at the mediabus
> > formats at all, so it isn't affected.
> 
> Niklas,
> 
> Were you planning to make a combined adv7180/rcar-vin patch for this?
> 
> I would prefer this solution rather than keeping legacy code around.

Sorry for the delay Hans. I just posted a combined patch for adv7180 and 
rcar-vin. Thanks for picking up the cleanup patches!

-- 
Regards,
Niklas Söderlund


[PATCH] [media] adv7180: rcar-vin: change mbus format to UYVY

2016-09-02 Thread Niklas Söderlund
The media bus format reported by the adv7180 is wrong. Steve Longerbeam
posted a patch which changed the format to UYVY8_2X8 with the commit
message:

  Change the media bus format from YUYV8_2X8 to UYVY8_2X8. Colors
  now look correct when capturing with the i.mx6 backend. The other
  option is to set the SWPC bit in register 0x27 to swap the Cr and Cb
  output samples.

The rcar-vin driver was developed and tested with the adv7180 and
therefor suffers from the same issue, looking for the wrong media bus
format. The two errors corrected each other.

This patch takes Steve's patch and merge it with a fix for rcar-vin
driver. The rcar-vin driver is used used in together with the adv7180
och Koelsch and this ensures it will not break while fixing the adv7180
issue. I checked wit Steve and he was fine with me merging the patches.

Signed-off-by: Niklas Söderlund 
Suggested-by: Steve Longerbeam 

ADV7180 parts:

Signed-off-by: Steve Longerbeam 
Acked-by: Lars-Peter Clausen 
Tested-by: Tim Harvey 
Acked-by: Tim Harvey 
---
 drivers/media/i2c/adv7180.c | 4 ++--
 drivers/media/platform/rcar-vin/rcar-core.c | 4 ++--
 drivers/media/platform/rcar-vin/rcar-dma.c  | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 515ea6a..a6ac78b 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -633,7 +633,7 @@ static int adv7180_enum_mbus_code(struct v4l2_subdev *sd,
if (code->index != 0)
return -EINVAL;
 
-   code->code = MEDIA_BUS_FMT_YUYV8_2X8;
+   code->code = MEDIA_BUS_FMT_UYVY8_2X8;
 
return 0;
 }
@@ -643,7 +643,7 @@ static int adv7180_mbus_fmt(struct v4l2_subdev *sd,
 {
struct adv7180_state *state = to_state(sd);
 
-   fmt->code = MEDIA_BUS_FMT_YUYV8_2X8;
+   fmt->code = MEDIA_BUS_FMT_UYVY8_2X8;
fmt->colorspace = V4L2_COLORSPACE_SMPTE170M;
fmt->width = 720;
fmt->height = state->curr_norm & V4L2_STD_525_60 ? 480 : 576;
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 64999a2..6219cba 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -43,8 +43,8 @@ static bool rvin_mbus_supported(struct rvin_graph_entity 
*entity)
code.index++;
switch (code.code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
-   case MEDIA_BUS_FMT_YUYV8_2X8:
-   case MEDIA_BUS_FMT_YUYV10_2X10:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
entity->code = code.code;
return true;
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 46abdb0..8c66a93 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -169,7 +169,7 @@ static int rvin_setup(struct rvin_dev *vin)
vnmc |= VNMC_INF_YUV16;
input_is_yuv = true;
break;
-   case MEDIA_BUS_FMT_YUYV8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
@@ -178,7 +178,7 @@ static int rvin_setup(struct rvin_dev *vin)
case MEDIA_BUS_FMT_RGB888_1X24:
vnmc |= VNMC_INF_RGB888;
break;
-   case MEDIA_BUS_FMT_YUYV10_2X10:
+   case MEDIA_BUS_FMT_UYVY10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
-- 
2.9.3



Re: [PATCH] arm64: renesas: r8a7796/salvator-x: Add board part number to DT bindings

2016-09-02 Thread Rob Herring
On Wed, Aug 31, 2016 at 11:17:34AM +0200, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
> b/Documentation/devicetree/bindings/arm/shmobile.txt
> index 90cf237ee5581978..42a046a97acba00f 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -65,7 +65,7 @@ Boards:
>  compatible = "renesas,porter", "renesas,r8a7791"
>- Salvator-X (RTP0RC7795SIPB0010S)
>  compatible = "renesas,salvator-x", "renesas,r8a7795";
> -  - Salvator-X
> +  - Salvator-X (RTP0RC7796SIPB0011S)
>  compatible = "renesas,salvator-x", "renesas,r8a7796";

Seems like these should be different compatibles rather than the 
combination here defining exactly which board. 

>- SILK (RTP0RC7794LCB00011S)
>  compatible = "renesas,silk", "renesas,r8a7794"
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 12/12] arm64: dts: h3ulcb: Sound SSI support

2016-09-02 Thread Vladimir Barinov

Hi Sergei,

Thank you for the review.
Lemme fix it in v5 patchset.

Regards,
Vladimir

On 02.09.2016 15:38, Sergei Shtylyov wrote:

Hello.

On 9/2/2016 3:05 PM, Vladimir Barinov wrote:


This supports SSI sound for H3ULCB board.
SSI DMA mode used. CS2000 used as AUDIO_CLK_B.

Signed-off-by: Vladimir Barinov 
Acked-by: Kuninori Morimoto 
---
Changes in version 3:
- initially added
Changes in version 4:
- added comment for audio_clkout

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 115 
+

 1 file changed, 115 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts

index bbd7928..a254231 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -45,6 +45,12 @@
 };
 };

+x12_clk: x12_clk {


   If the crystal name is X12, name the node "x12" too, this way the 
output clock will be named just "x12".



+compatible = "fixed-clock";
+#clock-cells = <0>;
+clock-frequency = <24576000>;
+};
+
 vcc_sdhi0: regulator-vcc-sdhi0 {
 compatible = "regulator-fixed";


[...]

@@ -136,6 +176,73 @@

[...]

+
+cs2000: clk_multiplier@4f {


   Don't use underscores in the node names, use hyphens instead.


+#clock-cells = <0>;
+compatible = "cirrus,cs2000-cp";
+reg = <0x4f>;
+clocks = <_clkout>, <_clk>;
+clock-names = "clk_in", "ref_clk";
+
+assigned-clocks = <>;
+assigned-clock-rates = <24576000>; /* 1/1 divide */
+};
+};

[...]

MBR, Sergei





[PATCH 1/2] v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine

2016-09-02 Thread Niklas Söderlund
The format is used on the R-Car VSP1 video queues that carry
2-D histogram statistics data.

Signed-off-by: Niklas Söderlund 
---
 Documentation/media/uapi/v4l/meta-formats.rst  |   1 +
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 150 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
 include/uapi/linux/videodev2.h |   3 +-
 4 files changed, 154 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst

diff --git a/Documentation/media/uapi/v4l/meta-formats.rst 
b/Documentation/media/uapi/v4l/meta-formats.rst
index 05ab91e..01e24e3 100644
--- a/Documentation/media/uapi/v4l/meta-formats.rst
+++ b/Documentation/media/uapi/v4l/meta-formats.rst
@@ -13,3 +13,4 @@ These formats are used for the :ref:`metadata` interface only.
 :maxdepth: 1
 
 pixfmt-meta-vsp1-hgo
+pixfmt-meta-vsp1-hgt
diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst 
b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
new file mode 100644
index 000..a093f0a
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
@@ -0,0 +1,150 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _v4l2-meta-fmt-vsp1-hgt:
+
+***
+V4L2_META_FMT_VSP1_HGT ('VSPT')
+***
+
+*man V4L2_META_FMT_VSP1_HGT(2)*
+
+Renesas R-Car VSP1 2-D Histogram Data
+
+
+Description
+===
+
+This format describes histogram data generated by the Renesas R-Car VSP1
+2-D Histogram (HGT) engine.
+
+The VSP1 HGT is a histogram computation engine that operates on HSV
+data. It operates on a possibly cropped and subsampled input image and
+computes the sum, maximum and minimum of the S component as well as a
+weighted frequency histogram based on the H and S components.
+
+The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in
+total. Each HSV value is added to one or more buckets with a wight
+between 1 and 16 depending on how the Hue areas are setup. Finding the
+correct buckets is done by inspecting the H and S value independently.
+
+The Saturation position **n** (0 - 31) in the matrix are found by the
+expression:
+
+8 * n <= S < 8 * (n + 1)
+
+The Hue positions **m** (0 - 5) in the matrix depends on how the HGT Hue
+areas are configured. There are 6 user configurable Hue Areas which can
+be configured to cover overlapping Hue values:
+
+::
+
+ Area 0   Area 1   Area 2   Area 3   Area 4   Area 
5
+     

+   \   /|  |\   /|  |\   /|  |\   /|  |\   /|  |\   /| 
 |\   /
+\ / |  | \ / |  | \ / |  | \ / |  | \ / |  | \ / | 
 | \ /
+ X  |  |  X  |  |  X  |  |  X  |  |  X  |  |  X  | 
 |  X
+/ \ |  | / \ |  | / \ |  | / \ |  | / \ |  | / \ | 
 | / \
+   /   \|  |/   \|  |/   \|  |/   \|  |/   \|  |/   \| 
 |/   \
+  5U   0L  0U   1L  1U   2L  2U   3L  3U   4L  4U   5L 
 5U   0L
+<0..Hue 
Value255>
+
+As shown in the diagram a single Hue vale can be attributed to more then
+one Hue area. In such case the Hue value is attributed to both Hue
+Areas, but with a weight. The maximum weight is 16 and is associated
+with all Hue values that are inside the center of a Hue area (between nL
+-- nU). Values outside this area are weighted with a rounded down value
+along the diagonal line. If there is no overlapped areas specified the
+value is included in the lower area.
+
+The Hue area setup must match one of the following constrains:
+
+::
+
+0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U
+
+::
+
+0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L
+
+**Byte Order.**
+All data is stored in memory in little endian format. Each cell in the tables
+contains one byte.
+
+.. flat-table:: VSP1 HGT Data - (800 bytes)
+:header-rows:  2
+:stub-columns: 0
+
+* - Offset
+  - :cspan:`4` Memory
+* -
+  - [31:24]
+  - [23:16]
+  - [15:8]
+  - [7:0]
+* - 0
+  - -
+  - S max [7:0]
+  - -
+  - S min [7:0]
+* - 4
+  - :cspan:`4` S sum [31:0]
+* - 8
+  - -
+  - Hue Area 0 Lower Boundary (0L) [0:7]
+  - -
+  - Hue Area 0 Upper Boundary (0U) [0:7]
+* - 12
+  - -
+  - Hue Area 1 Lower Boundary (1L) [0:7]
+  - -
+  - Hue Area 1 Upper Boundary (1U) [0:7]
+* - 16
+  - -
+  - Hue Area 2 Lower Boundary (2L) [0:7]
+  - -
+  - Hue Area 2 Upper Boundary (2U) [0:7]
+* - 20
+  - -
+  - Hue Area 3 Lower Boundary (3L) [0:7]
+  - -
+  - Hue Area 3 Upper Boundary (3U) [0:7]
+* - 24
+  - -
+  - Hue Area 4 Lower Boundary (4L) [0:7]
+  - -
+  - 

[PATCH 2/2] v4l: vsp1: Add HGT support

2016-09-02 Thread Niklas Söderlund
The HGT is a Histogram Generator Two-Dimensions. It computes a weighted
frequency histograms for hue and saturation areas over a configurable
region of the image with optional subsampling.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/vsp1/Makefile  |   2 +-
 drivers/media/platform/vsp1/vsp1.h|   3 +
 drivers/media/platform/vsp1/vsp1_drv.c|  32 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  33 +-
 drivers/media/platform/vsp1/vsp1_entity.h |   1 +
 drivers/media/platform/vsp1/vsp1_hgt.c| 495 ++
 drivers/media/platform/vsp1/vsp1_hgt.h|  51 +++
 drivers/media/platform/vsp1/vsp1_pipe.c   |  16 +
 drivers/media/platform/vsp1/vsp1_pipe.h   |   2 +
 drivers/media/platform/vsp1/vsp1_regs.h   |   9 +
 drivers/media/platform/vsp1/vsp1_video.c  |  10 +-
 11 files changed, 638 insertions(+), 16 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h

diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index 8ab6a06..a33afc3 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -3,7 +3,7 @@ vsp1-y  += vsp1_dl.o vsp1_drm.o 
vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
 vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
-vsp1-y += vsp1_hgo.o vsp1_histo.o
+vsp1-y += vsp1_hgo.o vsp1_hgt.o vsp1_histo.o
 vsp1-y += vsp1_lif.o
 
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1.o
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 9dce3ea..012ce40 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -33,6 +33,7 @@ struct vsp1_platform_data;
 struct vsp1_bru;
 struct vsp1_clu;
 struct vsp1_hgo;
+struct vsp1_hgt;
 struct vsp1_hsit;
 struct vsp1_lif;
 struct vsp1_lut;
@@ -52,6 +53,7 @@ struct vsp1_uds;
 #define VSP1_HAS_WPF_VFLIP (1 << 5)
 #define VSP1_HAS_WPF_HFLIP (1 << 6)
 #define VSP1_HAS_HGO   (1 << 7)
+#define VSP1_HAS_HGT   (1 << 8)
 
 struct vsp1_device_info {
u32 version;
@@ -74,6 +76,7 @@ struct vsp1_device {
struct vsp1_bru *bru;
struct vsp1_clu *clu;
struct vsp1_hgo *hgo;
+   struct vsp1_hgt *hgt;
struct vsp1_hsit *hsi;
struct vsp1_hsit *hst;
struct vsp1_lif *lif;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 9684abf..828584f 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -31,6 +31,7 @@
 #include "vsp1_dl.h"
 #include "vsp1_drm.h"
 #include "vsp1_hgo.h"
+#include "vsp1_hgt.h"
 #include "vsp1_hsit.h"
 #include "vsp1_lif.h"
 #include "vsp1_lut.h"
@@ -107,6 +108,7 @@ static int vsp1_create_sink_links(struct vsp1_device *vsp1,
continue;
 
if (source->type == VSP1_ENTITY_HGO ||
+   source->type == VSP1_ENTITY_HGT ||
source->type == VSP1_ENTITY_LIF ||
source->type == VSP1_ENTITY_WPF)
continue;
@@ -160,6 +162,16 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1)
return ret;
}
 
+   if (vsp1->hgt) {
+   ret = media_create_pad_link(>hgt->entity.subdev.entity,
+   HGT_PAD_SOURCE,
+   >hgt->histo.video.entity, 0,
+   MEDIA_LNK_FL_ENABLED |
+   MEDIA_LNK_FL_IMMUTABLE);
+   if (ret < 0)
+   return ret;
+   }
+
if (vsp1->lif) {
ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
RWPF_PAD_SOURCE,
@@ -300,6 +312,16 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(>hgo->entity.list_dev, >entities);
}
 
+   if (vsp1->info->features & VSP1_HAS_HGT && vsp1->info->uapi) {
+   vsp1->hgt = vsp1_hgt_create(vsp1);
+   if (IS_ERR(vsp1->hgt)) {
+   ret = PTR_ERR(vsp1->hgt);
+   goto done;
+   }
+
+   list_add_tail(>hgt->entity.list_dev, >entities);
+   }
+
/* The LIF is only supported when used in conjunction with the DU, in
 * which case the userspace API is disabled. If the userspace API is
 * enabled skip the LIF, even when present.
@@ -583,7 +605,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = 

[PATCH 0/2] v4l: vsp1: Add HGT support

2016-09-02 Thread Niklas Söderlund
Hi,

This series add support for the VSP1 2-D histogram engine HGT.

It's based on top of Laurent Pinchart tree at 
git://linuxtv.org/pinchartl/media.git hgo.

It is tested on Koelsch using a modified vsp-tests suite package, 
modifications can be found at https://git.ragnatech.se/vsp-tests hgt.

Niklas Söderlund (2):
  v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine
  v4l: vsp1: Add HGT support

 Documentation/media/uapi/v4l/meta-formats.rst  |   1 +
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 150 +++
 drivers/media/platform/vsp1/Makefile   |   2 +-
 drivers/media/platform/vsp1/vsp1.h |   3 +
 drivers/media/platform/vsp1/vsp1_drv.c |  32 +-
 drivers/media/platform/vsp1/vsp1_entity.c  |  33 +-
 drivers/media/platform/vsp1/vsp1_entity.h  |   1 +
 drivers/media/platform/vsp1/vsp1_hgt.c | 495 +
 drivers/media/platform/vsp1/vsp1_hgt.h |  51 +++
 drivers/media/platform/vsp1/vsp1_pipe.c|  16 +
 drivers/media/platform/vsp1/vsp1_pipe.h|   2 +
 drivers/media/platform/vsp1/vsp1_regs.h|   9 +
 drivers/media/platform/vsp1/vsp1_video.c   |  10 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
 include/uapi/linux/videodev2.h |   3 +-
 15 files changed, 792 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h

-- 
2.9.3



Re: [PATCH v6 5/9] mmc: tmio: Add tuning support

2016-09-02 Thread Simon Horman
On Fri, Sep 02, 2016 at 02:46:46PM +0200, Ulf Hansson wrote:
> On 2 September 2016 at 13:17, Simon Horman  wrote:
> > From: Ai Kyuse 
> >
> > Add tuning support for use with SDR104 mode
> >
> > Signed-off-by: Ai Kyuse 
> > Signed-off-by: Simon Horman 
> > ---
> > v6 [Simon Horman]
> > * As suggested by Ulf Hansson:
> >   - Restore saved tuning parameters on resume
> >
> > v5 [Simon Horman]
> > * As suggested by Ulf Hansson:
> >   - Move hw reset support into a separate patch
> >   - Use more descriptive name for callback to check for SSC error
> >   - Rely on core to retune in case of -EILSEQ
> >   - Document mandatory and optional callbacks
> >
> > v4 [Simon Horman]
> > * As suggested by Wolfram Sang:
> >   - Do not perform tuning if host->select_tuning is not set:
> > it seems to make little sense to do so and moreover there is currently
> > no such use-case
> >   - Do not add mrc->sbc handling from tmio_mmc_request,
> > this is a hang-over from earlier versions of this patchset which
> > did not use core infrastructure for retuning
> >   - Tidy up local variable usage
> > * Correct index passed to prepare_tuning(): this seems to have
> >   been the last piece of resolving the timeouts during tuning puzzle
> > * Further cleanups to tmio_mmc_execute_tuning():
> >   - Ensure tap is sized proportionally to its members
> >   - Remove stray '*' in comment
> >   - Use mmc rather than host->mmc, these are equivalent but
> > the former seems tidier
> >   - Correct inverted logic in setting tap values
> > * Re-introduce retuning support. This was removed in v3.
> >
> > v3 [Simon Horman]
> > * As suggested by Kuninori Morimoto:
> >   - Do not add unused retuning callback to struct tmio_mmc_host
> >   - Change return type of prepare_tuning callback to void
> >   - Add tap_size parameter to select_tuning callback
> >
> > v2 [Simon Horman]
> > * As suggested by Kuninori Morimoto:
> >   - Actually remove unnecessary TMIO_MMC_HAS_UHS_SCC define
> > * As suggested by Wolfram Sang:
> >   - Rely on core to call tuning. This simplifies things somewhat.
> >   - Use mmc_send_tuning()
> > - A side affect of this appears to be that we now see some recoverable
> >   errors logged during tuning. These are typically corrected by
> >   subsequent tuning. It is the logging that is the apparent side effect
> >   of this change.
> >   e.g.
> >   sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt 
> > (CMD19)
> >   sh_mobile_sdhi ee10.sd: Tuning procedure failed
> > * Use bool rather than unsigned long to pass test status
> >   to select_tuning() callback
> > * Do not retune if init_tuning callback is not present or
> >   indicates that there are no taps present
> > * Retune on hardware reset
> >
> > v1 [Simon Horman]
> > * Omit start_signal_voltage_switch and tmio_mmc_card_busy changes which are
> >   already present in mainline in a different form
> > * Return num from init_tuning rather than passing an extra parameter
> >   to hold the return value
> > * Only call host->init_tuning if it is non-NULL
> > * Place tmio_mmc_execute_tuning() such that no new forward declarations are
> >   required
> > * Remove unused TMIO_MMC_HAS_UHS_SCC define
> >
> > v0 [Ai Kyuse]
> > ---
> >  drivers/mmc/host/tmio_mmc.h | 12 +++
> >  drivers/mmc/host/tmio_mmc_pio.c | 69 
> > +
> >  2 files changed, 81 insertions(+)
> >
> > diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
> > index 4b71f31fba63..4b501f2d529f 100644
> > --- a/drivers/mmc/host/tmio_mmc.h
> > +++ b/drivers/mmc/host/tmio_mmc.h
> > @@ -150,6 +150,7 @@ struct tmio_mmc_host {
> > struct mutexios_lock;   /* protect set_ios() 
> > context */
> > boolnative_hotplug;
> > boolsdio_irq_enabled;
> > +   u32 scc_tappos;
> >
> > /* Mandatory callback */
> > int (*clk_enable)(struct tmio_mmc_host *host);
> > @@ -165,6 +166,17 @@ struct tmio_mmc_host {
> >struct mmc_ios *ios);
> > int (*write16_hook)(struct tmio_mmc_host *host, int addr);
> > void (*hw_reset)(struct tmio_mmc_host *host);
> > +   void (*prepare_tuning)(struct tmio_mmc_host *host, unsigned long 
> > tap);
> > +   bool (*check_scc_error)(struct tmio_mmc_host *host);
> > +
> > +   /* Mandatory callback for tuning to occur which is
> > +* optional for SDR50 and mandatory for SDR104 */
> > +   unsigned int (*init_tuning)(struct tmio_mmc_host *host);
> > +   int (*select_tuning)(struct tmio_mmc_host *host);
> > +
> > +   /* Tuning values: 1 for success, 0 for failure */
> > +   DECLARE_BITMAP(taps, BITS_PER_BYTE * sizeof(long));
> > +   unsigned int tap_num;
> >  };
> >
> >  struct 

Re: [PATCH 1/3] DT: arm: shmobile: document Wheat board

2016-09-02 Thread Rob Herring
On Fri, Aug 26, 2016 at 11:20:05PM +0300, Sergei Shtylyov wrote:
> Document the Wheat device tree bindings, listing it as a supported board.
> 
> This allows to use checkpatch.pl to validate .dts files referring to the
> Wheat board.
> 
> Signed-off-by: Sergei Shtylyov 

Acked-by: Rob Herring 


RE: [PATCH v2 1/3] ARM: dts: r7s72100: add ethernet clock to device tree

2016-09-02 Thread Chris Brandt
On 9/2/2016, Simon Horman wrote:
> For future submissions please consider:
> 1. Supplying a cover letter (git format-patch has a --cover-letter option)
>for patch-sets comprising more than one patch. This allows you to describe
>an overview of what the series as a whole achieves. And is also
>convenient for maintainers to reply to when accepting your patches.

OK. I can do that.


> 2. Starting a new thread for each new version of a patch/patch-set.

Does that mean to NOT use --in-reply-to= when submitting a v2,v3,etc... 



One more question:
Can I submit a patches series now that just adds all the MSTP clock nodes that 
I'll be working on for the next couple weeks? (USB, SDHI, MMC)
Or, do I have to wait till I have the drivers working?
Or, better yet, can I add all the MSTP clocks that will probably get used at 
some point (basically, everything that we're using today in our 3.14 BSP).

Chris



Re: [PATCH v6 5/9] mmc: tmio: Add tuning support

2016-09-02 Thread Ulf Hansson
On 2 September 2016 at 13:17, Simon Horman  wrote:
> From: Ai Kyuse 
>
> Add tuning support for use with SDR104 mode
>
> Signed-off-by: Ai Kyuse 
> Signed-off-by: Simon Horman 
> ---
> v6 [Simon Horman]
> * As suggested by Ulf Hansson:
>   - Restore saved tuning parameters on resume
>
> v5 [Simon Horman]
> * As suggested by Ulf Hansson:
>   - Move hw reset support into a separate patch
>   - Use more descriptive name for callback to check for SSC error
>   - Rely on core to retune in case of -EILSEQ
>   - Document mandatory and optional callbacks
>
> v4 [Simon Horman]
> * As suggested by Wolfram Sang:
>   - Do not perform tuning if host->select_tuning is not set:
> it seems to make little sense to do so and moreover there is currently
> no such use-case
>   - Do not add mrc->sbc handling from tmio_mmc_request,
> this is a hang-over from earlier versions of this patchset which
> did not use core infrastructure for retuning
>   - Tidy up local variable usage
> * Correct index passed to prepare_tuning(): this seems to have
>   been the last piece of resolving the timeouts during tuning puzzle
> * Further cleanups to tmio_mmc_execute_tuning():
>   - Ensure tap is sized proportionally to its members
>   - Remove stray '*' in comment
>   - Use mmc rather than host->mmc, these are equivalent but
> the former seems tidier
>   - Correct inverted logic in setting tap values
> * Re-introduce retuning support. This was removed in v3.
>
> v3 [Simon Horman]
> * As suggested by Kuninori Morimoto:
>   - Do not add unused retuning callback to struct tmio_mmc_host
>   - Change return type of prepare_tuning callback to void
>   - Add tap_size parameter to select_tuning callback
>
> v2 [Simon Horman]
> * As suggested by Kuninori Morimoto:
>   - Actually remove unnecessary TMIO_MMC_HAS_UHS_SCC define
> * As suggested by Wolfram Sang:
>   - Rely on core to call tuning. This simplifies things somewhat.
>   - Use mmc_send_tuning()
> - A side affect of this appears to be that we now see some recoverable
>   errors logged during tuning. These are typically corrected by
>   subsequent tuning. It is the logging that is the apparent side effect
>   of this change.
>   e.g.
>   sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt 
> (CMD19)
>   sh_mobile_sdhi ee10.sd: Tuning procedure failed
> * Use bool rather than unsigned long to pass test status
>   to select_tuning() callback
> * Do not retune if init_tuning callback is not present or
>   indicates that there are no taps present
> * Retune on hardware reset
>
> v1 [Simon Horman]
> * Omit start_signal_voltage_switch and tmio_mmc_card_busy changes which are
>   already present in mainline in a different form
> * Return num from init_tuning rather than passing an extra parameter
>   to hold the return value
> * Only call host->init_tuning if it is non-NULL
> * Place tmio_mmc_execute_tuning() such that no new forward declarations are
>   required
> * Remove unused TMIO_MMC_HAS_UHS_SCC define
>
> v0 [Ai Kyuse]
> ---
>  drivers/mmc/host/tmio_mmc.h | 12 +++
>  drivers/mmc/host/tmio_mmc_pio.c | 69 
> +
>  2 files changed, 81 insertions(+)
>
> diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
> index 4b71f31fba63..4b501f2d529f 100644
> --- a/drivers/mmc/host/tmio_mmc.h
> +++ b/drivers/mmc/host/tmio_mmc.h
> @@ -150,6 +150,7 @@ struct tmio_mmc_host {
> struct mutexios_lock;   /* protect set_ios() context 
> */
> boolnative_hotplug;
> boolsdio_irq_enabled;
> +   u32 scc_tappos;
>
> /* Mandatory callback */
> int (*clk_enable)(struct tmio_mmc_host *host);
> @@ -165,6 +166,17 @@ struct tmio_mmc_host {
>struct mmc_ios *ios);
> int (*write16_hook)(struct tmio_mmc_host *host, int addr);
> void (*hw_reset)(struct tmio_mmc_host *host);
> +   void (*prepare_tuning)(struct tmio_mmc_host *host, unsigned long tap);
> +   bool (*check_scc_error)(struct tmio_mmc_host *host);
> +
> +   /* Mandatory callback for tuning to occur which is
> +* optional for SDR50 and mandatory for SDR104 */
> +   unsigned int (*init_tuning)(struct tmio_mmc_host *host);
> +   int (*select_tuning)(struct tmio_mmc_host *host);
> +
> +   /* Tuning values: 1 for success, 0 for failure */
> +   DECLARE_BITMAP(taps, BITS_PER_BYTE * sizeof(long));
> +   unsigned int tap_num;
>  };
>
>  struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev);
> diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
> index f1d36f4533d2..54aa14bb2f75 100644
> --- a/drivers/mmc/host/tmio_mmc_pio.c
> +++ b/drivers/mmc/host/tmio_mmc_pio.c
> @@ -36,6 +36,7 @@
>  

Re: [PATCH] v4l: Add metadata buffer type and format

2016-09-02 Thread Sakari Ailus
Hi Laurent,

On Fri, Sep 02, 2016 at 03:07:03PM +0300, Laurent Pinchart wrote:
> The metadata buffer type is used to transfer metadata between userspace
> and kernelspace through a V4L2 buffers queue. It comes with a new
> metadata capture capability and format description.
> 
> Signed-off-by: Laurent Pinchart 
> Tested-by: Guennadi Liakhovetski 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk


Re: [PATCH v3 12/12] arm64: dts: h3ulcb: Sound SSI support

2016-09-02 Thread Vladimir Barinov

On 02.09.2016 15:05, Vladimir Barinov wrote:

This supports SSI sound for H3ULCB board.
SSI DMA mode used. CS2000 used as AUDIO_CLK_B.

Signed-off-by: Vladimir Barinov 
Acked-by: Kuninori Morimoto 
---
Changes in version 3:
- initially added
Changes in version 4:
- added comment for audio_clkout

  arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 115 +
  1 file changed, 115 insertions(+)


Sorry for the subject typo. The proper one is v4:
[PATCH v4 4/4] arm64: dts: h3ulcb: Sound SSI support



[PATCH] v4l: Add metadata buffer type and format

2016-09-02 Thread Laurent Pinchart
The metadata buffer type is used to transfer metadata between userspace
and kernelspace through a V4L2 buffers queue. It comes with a new
metadata capture capability and format description.

Signed-off-by: Laurent Pinchart 
Tested-by: Guennadi Liakhovetski 
---
Changes since v2:

- Dropped the reserved field from struct v4l2_meta_format
- Removed redundant documentation sentence
- Fixed typos

Changes since v1:

- Rebased on top of the DocBook to reST conversion

 Documentation/media/uapi/v4l/buffer.rst  |  8 +++
 Documentation/media/uapi/v4l/dev-meta.rst| 63 
 Documentation/media/uapi/v4l/devices.rst |  1 +
 Documentation/media/uapi/v4l/vidioc-querycap.rst | 14 --
 Documentation/media/videodev2.h.rst.exceptions   |  2 +
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 +++
 drivers/media/v4l2-core/v4l2-dev.c   | 16 +++---
 drivers/media/v4l2-core/v4l2-ioctl.c | 34 +
 drivers/media/v4l2-core/videobuf2-v4l2.c |  3 ++
 include/media/v4l2-ioctl.h   | 17 +++
 include/uapi/linux/videodev2.h   | 13 +
 11 files changed, 181 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index 5deb4a46f992..b5177cc63b86 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -499,6 +499,14 @@ enum v4l2_buf_type
-  Buffer for Software Defined Radio (SDR) output stream, see
  :ref:`sdr`.
 
+-  .. row 13
+
+   -  ``V4L2_BUF_TYPE_META_CAPTURE``
+
+   -  13
+
+   -  Buffer for metadata capture, see :ref:`metadata`.
+
 
 
 .. _buffer-flags:
diff --git a/Documentation/media/uapi/v4l/dev-meta.rst 
b/Documentation/media/uapi/v4l/dev-meta.rst
new file mode 100644
index ..d3a33fea9cc9
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-meta.rst
@@ -0,0 +1,63 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _metadata:
+
+**
+Metadata Interface
+**
+
+Metadata refers to any non-image data that supplements video frames with
+additional information. This may include statistics computed over the image
+or frame capture parameters supplied by the image source. This interface is
+intended for transfer of metadata to userspace and control of that operation.
+
+The metadata interface is implemented on video capture device nodes. The device
+can be dedicated to metadata or can implement both video and metadata capture
+as specified in its reported capabilities.
+
+.. note::
+
+This is an :ref:`experimental` interface and may
+change in the future.
+
+Querying Capabilities
+=
+
+Device nodes supporting the metadata interface set the 
``V4L2_CAP_META_CAPTURE``
+flag in the ``device_caps`` field of the
+:ref:`v4l2_capability ` structure returned by the
+:ref:`VIDIOC_QUERYCAP` ioctl. That flag means the device can capture
+metadata to memory.
+
+At least one of the read/write or streaming I/O methods must be supported.
+
+
+Data Format Negotiation
+===
+
+The metadata device uses the :ref:`format` ioctls to select the capture format.
+The metadata buffer content format is bound to that selected format. In 
addition
+to the basic :ref:`format` ioctls, the :ref:`VIDIOC_ENUM_FMT` ioctl must be
+supported as well.
+
+To use the :ref:`format` ioctls applications set the ``type`` field of the
+:ref:`v4l2_format ` structure to ``V4L2_BUF_TYPE_META_CAPTURE``
+and use the :ref:`v4l2_meta_format ` ``meta`` member of the
+``fmt`` union as needed per the desired operation. Both drivers and 
applications
+must set the remainder of the :ref:`v4l2_format ` structure to 0.
+
+.. _v4l2-meta-format:
+.. flat-table:: struct v4l2_meta_format
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u32
+  - ``dataformat``
+  - The data format, set by the application. This is a little endian
+:ref:`four character code `. V4L2 defines metadata formats
+in :ref:`meta-formats`.
+* - __u32
+  - ``buffersize``
+  - Maximum buffer size in bytes required for data. The value is set by the
+driver.
diff --git a/Documentation/media/uapi/v4l/devices.rst 
b/Documentation/media/uapi/v4l/devices.rst
index aed0ce11d1f8..961e7fb62063 100644
--- a/Documentation/media/uapi/v4l/devices.rst
+++ b/Documentation/media/uapi/v4l/devices.rst
@@ -24,3 +24,4 @@ Interfaces
 dev-sdr
 dev-event
 dev-subdev
+dev-meta
diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index b10fed313f99..734fae6fc5e4 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -387,6 +387,14 @@ 

[PATCH v3 12/12] arm64: dts: h3ulcb: Sound SSI support

2016-09-02 Thread Vladimir Barinov
This supports SSI sound for H3ULCB board.
SSI DMA mode used. CS2000 used as AUDIO_CLK_B.

Signed-off-by: Vladimir Barinov 
Acked-by: Kuninori Morimoto 
---
Changes in version 3:
- initially added
Changes in version 4:
- added comment for audio_clkout

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 115 +
 1 file changed, 115 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index bbd7928..a254231 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -45,6 +45,12 @@
};
};
 
+   x12_clk: x12_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <24576000>;
+   };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
 
@@ -68,6 +74,32 @@
states = <330 1
  180 0>;
};
+
+   audio_clkout: audio_clkout {
+   /*
+* This is same as <_sound 0>
+* but needed to avoid cs2000/rcar_sound probe dead-lock
+*/
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <11289600>;
+   };
+
+   rsnd_ak4613: sound {
+   compatible = "simple-audio-card";
+
+   simple-audio-card,format = "left_j";
+   simple-audio-card,bitclock-master = <>;
+   simple-audio-card,frame-master = <>;
+
+   sndcpu: simple-audio-card,cpu {
+   sound-dai = <_sound>;
+   };
+
+   sndcodec: simple-audio-card,codec {
+   sound-dai = <>;
+   };
+   };
 };
 
 _clk {
@@ -113,6 +141,17 @@
power-source = <1800>;
};
 
+   sound_pins: sound {
+   groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
+   function = "ssi";
+   };
+
+   sound_clk_pins: sound_clk {
+   groups = "audio_clk_a_a", "audio_clk_b_a", "audio_clk_c_a",
+"audio_clkout_a", "audio_clkout3_a";
+   function = "audio_clk";
+   };
+
usb1_pins: usb1 {
groups = "usb1";
function = "usb1";
@@ -136,6 +176,73 @@
pinctrl-names = "default";
 
status = "okay";
+
+   clock-frequency = <10>;
+
+   ak4613: codec@10 {
+   compatible = "asahi-kasei,ak4613";
+   #sound-dai-cells = <0>;
+   reg = <0x10>;
+   clocks = <_sound 3>;
+
+   asahi-kasei,in1-single-end;
+   asahi-kasei,in2-single-end;
+   asahi-kasei,out1-single-end;
+   asahi-kasei,out2-single-end;
+   asahi-kasei,out3-single-end;
+   asahi-kasei,out4-single-end;
+   asahi-kasei,out5-single-end;
+   asahi-kasei,out6-single-end;
+   };
+
+   cs2000: clk_multiplier@4f {
+   #clock-cells = <0>;
+   compatible = "cirrus,cs2000-cp";
+   reg = <0x4f>;
+   clocks = <_clkout>, <_clk>;
+   clock-names = "clk_in", "ref_clk";
+
+   assigned-clocks = <>;
+   assigned-clock-rates = <24576000>; /* 1/1 divide */
+   };
+};
+
+_sound {
+   pinctrl-0 = <_pins _clk_pins>;
+   pinctrl-names = "default";
+
+   /* Single DAI */
+   #sound-dai-cells = <0>;
+
+   /* audio_clkout0/1/2/3 */
+   #clock-cells = <1>;
+   clock-frequency = <11289600>;
+
+   status = "okay";
+
+   /* update  to  */
+   clocks = < CPG_MOD 1005>,
+< CPG_MOD 1006>, < CPG_MOD 1007>,
+< CPG_MOD 1008>, < CPG_MOD 1009>,
+< CPG_MOD 1010>, < CPG_MOD 1011>,
+< CPG_MOD 1012>, < CPG_MOD 1013>,
+< CPG_MOD 1014>, < CPG_MOD 1015>,
+< CPG_MOD 1022>, < CPG_MOD 1023>,
+< CPG_MOD 1024>, < CPG_MOD 1025>,
+< CPG_MOD 1026>, < CPG_MOD 1027>,
+< CPG_MOD 1028>, < CPG_MOD 1029>,
+< CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1019>, < CPG_MOD 1018>,
+<_clk_a>, <>,
+<_clk_c>,
+< CPG_CORE R8A7795_CLK_S0D4>;
+
+   rcar_sound,dai {
+   dai0 {
+   playback = <  >;
+   capture  = <  >;
+   };
+   };
 };
 
  {
@@ -150,11 +257,19 @@
status = "okay";
 };
 
+ {
+   shared-pin;
+};
+
  {
timeout-sec = <60>;
status = "okay";
 };
 
+_clk_a {
+   clock-frequency = <22579200>;
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
1.9.1



[PATCH v4 3/4] arm64: dts: h3ulcb: enable SDHI0

2016-09-02 Thread Vladimir Barinov
This supports SDHI0 on H3ULCB board SD card slot

Signed-off-by: Vladimir Barinov 
Reviewed-by: Geert Uytterhoeven 
---
Changes in version 3:
- initially added
Changes in version 4:
- added sd-uhs-sdr50

---
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 6842597..babe41c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -44,6 +44,30 @@
gpios = < 13 GPIO_ACTIVE_HIGH>;
};
};
+
+   vcc_sdhi0: regulator-vcc-sdhi0 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI0 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 2 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vccq_sdhi0: regulator-vccq-sdhi0 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI0 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
 };
 
 _clk {
@@ -78,6 +102,18 @@
function = "avb";
};
 
+   sdhi0_pins_3v3: sd0_3v3 {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_1v8: sd0_1v8 {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
+   };
+
usb1_pins: usb1 {
groups = "usb1";
function = "usb1";
@@ -108,6 +144,19 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins_3v3>;
+   pinctrl-1 = <_pins_1v8>;
+   pinctrl-names = "default", "state_uhs";
+
+   vmmc-supply = <_sdhi0>;
+   vqmmc-supply = <_sdhi0>;
+   cd-gpios = < 12 GPIO_ACTIVE_LOW>;
+   bus-width = <4>;
+   sd-uhs-sdr50;
+   status = "okay";
+};
+
  {
timeout-sec = <60>;
status = "okay";
-- 
1.9.1



[PATCH v4 2/4] arm64: dts: h3ulcb: enable GPIO keys

2016-09-02 Thread Vladimir Barinov
This supports GPIO keys on H3ULCB board

Signed-off-by: Vladimir Barinov 
---
Changes in version 4:
- initially added

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 14 +
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index fb694b8..3329f78 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -12,6 +12,7 @@
 /dts-v1/;
 #include "r8a7795.dtsi"
 #include 
+#include 
 
 / {
model = "Renesas H3ULCB board based on r8a7795";
@@ -31,6 +31,18 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
+
+   keyboard {
+   compatible = "gpio-keys";
+
+   key-1 {
+   linux,code = ;
+   label = "SW3";
+   wakeup-source;
+   debounce-interval = <20>;
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
+   };
 
leds {
compatible = "gpio-leds";
-- 
1.9.1



[PATCH v4 0/4] arm64: renesas: enable H3ULCB board peripherals

2016-09-02 Thread Vladimir Barinov
Hello,

This adds the folowing:
- R8A7795 SoC based H3ULCB board peripherals

Vladimir Barinov (4):
[1/4] arm64: dts: h3ulcb: enable GPIO leds
[2/4] arm64: dts: h3ulcb: enable GPIO keys
[3/4] arm64: dts: h3ulcb: enable SDHI0
[4/4] arm64: dts: h3ulcb: Sound SSI support

---
This patchset is against the 'kernel/git/horms/renesas.git' repo.

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 189 
+
 1 file changed, 189 insertions(+)


[PATCH v4 1/4] arm64: dts: h3ulcb: enable GPIO leds

2016-09-02 Thread Vladimir Barinov
This supports GPIO leds on H3ULCB board

Signed-off-by: Vladimir Barinov 
Reviewed-by: Geert Uytterhoeven 
---
Changes in version 3:
- initially added
Changes in version 4:
- removed led4 in favor of gpio-keys
- added label

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index fb694b8..3329f78 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -31,6 +31,19 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
+
+   leds {
+   compatible = "gpio-leds";
+
+   led5 {
+   label = "LED5";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+   led6 {
+   label = "LED6";
+   gpios = < 13 GPIO_ACTIVE_HIGH>;
+   };
+   };
 };
 
 _clk {
-- 
1.9.1



[PATCH v6 7/9] ARM: dts: lager: Enable UHS-I SDR-104

2016-09-02 Thread Simon Horman
Add the sd-uhs-sdr104 property to SDHI0.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 52b56fcaddf2..5e43763cec65 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -559,6 +559,7 @@
vqmmc-supply = <_sdhi0>;
cd-gpios = < 6 GPIO_ACTIVE_LOW>;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v6 3/9] mmc: tmio: document mandatory and optional callbacks

2016-09-02 Thread Simon Horman
Signed-off-by: Simon Horman 
---
v5
* New patch
---
 drivers/mmc/host/tmio_mmc.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 1f1cb2628f67..4b36cb5c2d9c 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -151,8 +151,10 @@ struct tmio_mmc_host {
boolnative_hotplug;
boolsdio_irq_enabled;
 
-   int (*write16_hook)(struct tmio_mmc_host *host, int addr);
+   /* Mandatory callback */
int (*clk_enable)(struct tmio_mmc_host *host);
+
+   /* Optional callbacks */
unsigned int (*clk_update)(struct tmio_mmc_host *host,
   unsigned int new_clock);
void (*clk_disable)(struct tmio_mmc_host *host);
@@ -161,6 +163,7 @@ struct tmio_mmc_host {
int (*card_busy)(struct mmc_host *mmc);
int (*start_signal_voltage_switch)(struct mmc_host *mmc,
   struct mmc_ios *ios);
+   int (*write16_hook)(struct tmio_mmc_host *host, int addr);
 };
 
 struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev);
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v6 4/9] mmc: tmio: Add hw reset support

2016-09-02 Thread Simon Horman
From: Ai Kyuse 

Add hw reset support.

Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
This is required by tuning support which will
be introduced by follow-up patches.

v6
* Rely on core to retune on reset

v5
* As suggested by Ulf Hansson
  - Broke out of a larger patch
---
 drivers/mmc/host/tmio_mmc.h | 1 +
 drivers/mmc/host/tmio_mmc_pio.c | 9 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 4b36cb5c2d9c..4b71f31fba63 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -164,6 +164,7 @@ struct tmio_mmc_host {
int (*start_signal_voltage_switch)(struct mmc_host *mmc,
   struct mmc_ios *ios);
int (*write16_hook)(struct tmio_mmc_host *host, int addr);
+   void (*hw_reset)(struct tmio_mmc_host *host);
 };
 
 struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 806308ac93e7..f1d36f4533d2 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -756,6 +756,14 @@ static int tmio_mmc_start_data(struct tmio_mmc_host *host,
return 0;
 }
 
+static void tmio_mmc_hw_reset(struct mmc_host *mmc)
+{
+   struct tmio_mmc_host *host = mmc_priv(mmc);
+
+   if (host->hw_reset)
+   host->hw_reset(host);
+}
+
 /* Process requests from the MMC layer */
 static void tmio_mmc_request(struct mmc_host *mmc, struct mmc_request *mrq)
 {
@@ -970,6 +978,7 @@ static struct mmc_host_ops tmio_mmc_ops = {
.get_cd = mmc_gpio_get_cd,
.enable_sdio_irq = tmio_mmc_enable_sdio_irq,
.multi_io_quirk = tmio_multi_io_quirk,
+   .hw_reset   = tmio_mmc_hw_reset,
 };
 
 static int tmio_mmc_init_ocr(struct tmio_mmc_host *host)
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v6 1/9] mmc: core: Add helper to see if a host can be retuned

2016-09-02 Thread Simon Horman
This is in preparation for restoring saved tuning parameters
when resuming the TMIO driver.

Signed-off-by: Simon Horman 
---
v6
* New patch
---
 include/linux/mmc/host.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index aa4bfbf129e4..4a9b4db8f22b 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -541,6 +541,11 @@ static inline void mmc_retune_recheck(struct mmc_host 
*host)
host->retune_now = 1;
 }
 
+static inline bool mmc_can_retune(struct mmc_host *host)
+{
+   return host->can_retune == 1;
+}
+
 void mmc_retune_pause(struct mmc_host *host);
 void mmc_retune_unpause(struct mmc_host *host);
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v6 5/9] mmc: tmio: Add tuning support

2016-09-02 Thread Simon Horman
From: Ai Kyuse 

Add tuning support for use with SDR104 mode

Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
v6 [Simon Horman]
* As suggested by Ulf Hansson:
  - Restore saved tuning parameters on resume

v5 [Simon Horman]
* As suggested by Ulf Hansson:
  - Move hw reset support into a separate patch
  - Use more descriptive name for callback to check for SSC error
  - Rely on core to retune in case of -EILSEQ
  - Document mandatory and optional callbacks

v4 [Simon Horman]
* As suggested by Wolfram Sang:
  - Do not perform tuning if host->select_tuning is not set:
it seems to make little sense to do so and moreover there is currently
no such use-case
  - Do not add mrc->sbc handling from tmio_mmc_request,
this is a hang-over from earlier versions of this patchset which
did not use core infrastructure for retuning
  - Tidy up local variable usage
* Correct index passed to prepare_tuning(): this seems to have
  been the last piece of resolving the timeouts during tuning puzzle
* Further cleanups to tmio_mmc_execute_tuning():
  - Ensure tap is sized proportionally to its members
  - Remove stray '*' in comment
  - Use mmc rather than host->mmc, these are equivalent but
the former seems tidier
  - Correct inverted logic in setting tap values
* Re-introduce retuning support. This was removed in v3.

v3 [Simon Horman]
* As suggested by Kuninori Morimoto:
  - Do not add unused retuning callback to struct tmio_mmc_host
  - Change return type of prepare_tuning callback to void
  - Add tap_size parameter to select_tuning callback

v2 [Simon Horman]
* As suggested by Kuninori Morimoto:
  - Actually remove unnecessary TMIO_MMC_HAS_UHS_SCC define
* As suggested by Wolfram Sang:
  - Rely on core to call tuning. This simplifies things somewhat.
  - Use mmc_send_tuning()
- A side affect of this appears to be that we now see some recoverable
  errors logged during tuning. These are typically corrected by
  subsequent tuning. It is the logging that is the apparent side effect
  of this change.
  e.g.
  sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
  sh_mobile_sdhi ee10.sd: Tuning procedure failed
* Use bool rather than unsigned long to pass test status
  to select_tuning() callback
* Do not retune if init_tuning callback is not present or
  indicates that there are no taps present
* Retune on hardware reset

v1 [Simon Horman]
* Omit start_signal_voltage_switch and tmio_mmc_card_busy changes which are
  already present in mainline in a different form
* Return num from init_tuning rather than passing an extra parameter
  to hold the return value
* Only call host->init_tuning if it is non-NULL
* Place tmio_mmc_execute_tuning() such that no new forward declarations are
  required
* Remove unused TMIO_MMC_HAS_UHS_SCC define

v0 [Ai Kyuse]
---
 drivers/mmc/host/tmio_mmc.h | 12 +++
 drivers/mmc/host/tmio_mmc_pio.c | 69 +
 2 files changed, 81 insertions(+)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 4b71f31fba63..4b501f2d529f 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -150,6 +150,7 @@ struct tmio_mmc_host {
struct mutexios_lock;   /* protect set_ios() context */
boolnative_hotplug;
boolsdio_irq_enabled;
+   u32 scc_tappos;
 
/* Mandatory callback */
int (*clk_enable)(struct tmio_mmc_host *host);
@@ -165,6 +166,17 @@ struct tmio_mmc_host {
   struct mmc_ios *ios);
int (*write16_hook)(struct tmio_mmc_host *host, int addr);
void (*hw_reset)(struct tmio_mmc_host *host);
+   void (*prepare_tuning)(struct tmio_mmc_host *host, unsigned long tap);
+   bool (*check_scc_error)(struct tmio_mmc_host *host);
+
+   /* Mandatory callback for tuning to occur which is
+* optional for SDR50 and mandatory for SDR104 */
+   unsigned int (*init_tuning)(struct tmio_mmc_host *host);
+   int (*select_tuning)(struct tmio_mmc_host *host);
+
+   /* Tuning values: 1 for success, 0 for failure */
+   DECLARE_BITMAP(taps, BITS_PER_BYTE * sizeof(long));
+   unsigned int tap_num;
 };
 
 struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index f1d36f4533d2..54aa14bb2f75 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -298,6 +299,11 @@ static void tmio_mmc_finish_request(struct tmio_mmc_host 
*host)
if (mrq->cmd->error || (mrq->data && mrq->data->error))
tmio_mmc_abort_dma(host);
 
+   if (host->check_scc_error 

[PATCH v6 6/9] mmc: sh_mobile_sdhi: Add tuning support

2016-09-02 Thread Simon Horman
Add tuning support for use with SDR104 mode
This includes adding support for the sampling clock controller (SCC).

Based on work by Ai Kyuse.

Cc: Ai Kyuse 
Signed-off-by: Simon Horman 
---
v6 [Simon Horman]
* Rebase to use host->taps

v5 [Simon Horman]
* As suggested by Ulf Hansson
  - Use more descriptive name for callback to check for SSC error
* Correct return statement in sh_mobile_sdhi_hw_reset
* Reinstate Gen3 tuning support

v4 [Simon Horman]
As suggested by Geert Uytterhoeven:
* guard SDR104 specific portion of probe with host->mmc->caps &
  MMC_CAP_UHS_SDR104
* As suggested by Wolfram Sang:
  - Pass priv to sd_scc_{read,write}32 to save host_to_priv access
for each call
  - Use 0x0 instead of other representations of 0 in hex
  - Use CLK_CTL_SCLKEN
  - Do not add unused SH_MOBILE_SDHI_MAX_TAP
  - Use ternary operator in sh_mobile_sdhi_select_tuning
  - Do include as yet unsupported HS200 in error string
* Reintroduce retuning support: This was removed in v3.
* Revert to algorithm in v1 patchset, on further reading of the documentation
  it appears to be correct.

v3 [Simon Horman]
* As suggested by Kuninori Morimoto:
  - Do not add unused retuning callback to struct tmio_mmc_host
  - Change return type of prepare_tuning callback to void
  - Add tap_size parameter to select_tuning callback

v2 [Simon Horman]
* As suggested by Kuninori Morimoto
  - Use host->mmc->caps & MMC_CAP_UHS_SDR104 instead of
pdata->flags & TMIO_MMC_HAS_UHS_SCC to avoid needing the
MMC_CAP_UHS_SDR104 flag at all.
N.B: Morimoto-san suggested using but this flag is not actually
set there in by current probe come.
  - Simplify logic in sh_mobile_sdhi_inquiry_tuning
* As suggested by Wolfram Sang
  - Use clk_rate instead of clk for field in struct sh_mobile_sdhi_scc
  - Remove inquiry_tuning callback which is now unnecessary as calling
of tuning is handled by the core
  - Removed unused sh_mobile_sdhi_set_clk_div callback
  - Save sci_base address rather than calculating it on each read and write
* Update selection logic in sh_mobile_sdhi_select_tuning to match spec
* Use bool instead of long for taps parameter of
  sh_mobile_sdhi_select_tuning()
* Return 0 from sh_mobile_sdhi_init_tuning() if the
  SDR104 capability is not set and thus tuning should not
  be performed because it is not supported by the hardware

v1 [Simon Horman]
* Rebase
* Always use value of 0x8 for TAPNUM field of DTCNTL register
  rather than reading value from DT property. There does not
  seem to be a need to expose this in DT at this point.
* Do not include tmio_mmc_start_signal_voltage_switch changes which
  are already in mainline in a different form
* Do not add renesas,clk-rate property as the max-frequency property, which
  is now present in mainline, seems to provide the needed rate
* Omit Gen3 specific changes
* Do not provide renesas,mmc-scc-tappos DT property.
  Instead, always use taps provided in driver.
* Do not parse sd-uhs-sdr50 and sd-uhs-sdr104 properties.
  This is handled by the core.

v0 [Ai Kyuse]

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/sh_mobile_sdhi.c | 265 +-
 1 file changed, 264 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c 
b/drivers/mmc/host/sh_mobile_sdhi.c
index d679c8a533b6..961f57f3362f 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -47,6 +47,11 @@
 
 #define host_to_priv(host) container_of((host)->pdata, struct sh_mobile_sdhi, 
mmc_data)
 
+struct sh_mobile_sdhi_scc {
+   unsigned long clk_rate; /* clock rate for SDR104 */
+   u32 tap;/* sampling clock position for SDR104 */
+};
+
 struct sh_mobile_sdhi_of_data {
unsigned long tmio_flags;
unsigned long capabilities;
@@ -54,6 +59,9 @@ struct sh_mobile_sdhi_of_data {
enum dma_slave_buswidth dma_buswidth;
dma_addr_t dma_rx_offset;
unsigned bus_shift;
+   int scc_offset;
+   struct sh_mobile_sdhi_scc *taps;
+   int taps_num;
 };
 
 static const struct sh_mobile_sdhi_of_data of_default_cfg = {
@@ -66,12 +74,35 @@ static const struct sh_mobile_sdhi_of_data 
of_rcar_gen1_compatible = {
.capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
 };
 
+/* Definitions for sampling clocks */
+static struct sh_mobile_sdhi_scc rcar_gen2_scc_taps[] = {
+   {
+   .clk_rate = 15600,
+   .tap = 0x0703,
+   },
+   {
+   .clk_rate = 0,
+   .tap = 0x0300,
+   },
+};
+
 static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_MIN_RCAR2,
.capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
.dma_buswidth   = DMA_SLAVE_BUSWIDTH_4_BYTES,

[PATCH v6 9/9] arm64: dts: r8a7795: salvator-x: Enable UHS-I SDR-104

2016-09-02 Thread Simon Horman
Add the sd-uhs-sdr104 property to SDHI0 and SDHI1.

Signed-off-by: Simon Horman 
---
v5
* New patch
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index b67b31bd568d..088787883a3c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -387,6 +387,7 @@
wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
@@ -401,6 +402,7 @@
wp-gpios = < 16 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v6 0/9] UHS-I SDR-104 support for sh_mobile_sdhi

2016-09-02 Thread Simon Horman
Hi,

this series is based on work by Ai Kyuse to add UHS-I SDR-104 support for
sh_mobile_sdhi. It builds on work by Shinobu Uehara, Rob Taylor, William
Towle and Ian Molton, Ben Hutchings, Wolfram Sang and others to add UHS-I
SDR-50 support to the same driver.

This series enables:
* UHS-I SDR-104 on the r8a7790/Lager where UHS-I SDR-50 is already enabled.
* Both UHS-1 SDR-50 and SDR-104 on the r8a7796/Salvator-X

It is based on a merge of the next branches of the mmc and renesas trees.

The "mmc:" patches are targeted at the next branch of the mmc
tree. The "ARM:" and "arm64:" patches are targeted at the next branch of
the renesas tree.

To aid review the following git branches are provided:
* https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdr104-v6
  This patch set
* https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdr104-v6+sdhi-dma-v3
  This patch set merged with a rebase of prototype DMA support for SDHI on
  R-Car Gen 3

Overview of changes since v5:
* Drop retune handling from tmio suspend handler: it hs handled by MMC core
* Allow restoration of saved tuning parameters on resume

Please see http://elinux.org/Tests:SD-SDHI-SDR104 for indicative tests
results.

Ai Kyuse (3):
  mmc: tmio: enhance illegal sequence handling
  mmc: tmio: Add hw reset support
  mmc: tmio: Add tuning support

Simon Horman (5):
  mmc: core: Add helper to see if a host can be retuned
  mmc: tmio: document mandatory and optional callbacks
  mmc: sh_mobile_sdhi: Add tuning support
  ARM: dts: lager: Enable UHS-I SDR-104
  arm64: dts: r8a7795: salvator-x: Enable UHS-I SDR-104

Wolfram Sang (1):
  arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3

 arch/arm/boot/dts/r8a7790-lager.dts|   1 +
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  24 +-
 drivers/mmc/host/sh_mobile_sdhi.c  | 265 -
 drivers/mmc/host/tmio_mmc.h|  18 +-
 drivers/mmc/host/tmio_mmc_pio.c|  93 +++-
 include/linux/mmc/host.h   |   5 +
 6 files changed, 396 insertions(+), 10 deletions(-)

-- 
2.7.0.rc3.207.g0ac5344



[PATCH v6 2/9] mmc: tmio: enhance illegal sequence handling

2016-09-02 Thread Simon Horman
From: Ai Kyuse 

An illegal sequence command error may occur if there is a stopbit or
cmd_index error as well as a CRC error. The correct course of action
is to re-enable IRQs

An illegal sequence data error may occur if there is a CRC or stopbit
error,  or underrun. In this case set data->error correctly.

This is in preparation for enabling tuning support which relies on
differentiating between illegal sequence and other errors.

Signed-off-by: Ai Kyuse 
[simon: broken out of a larger patch]
Signed-off-by: Simon Horman 
Reviewed-by: Wolfram Sang 
---
v4
* Added Ack from Wolfram Sang

v3
* No change

v2
* Broken out of a larger patch (but forgot to post)
---
 drivers/mmc/host/tmio_mmc_pio.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 192817850dff..806308ac93e7 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -520,7 +520,7 @@ void tmio_mmc_do_data_irq(struct tmio_mmc_host *host)
schedule_work(>done);
 }
 
-static void tmio_mmc_data_irq(struct tmio_mmc_host *host)
+static void tmio_mmc_data_irq(struct tmio_mmc_host *host, unsigned int stat)
 {
struct mmc_data *data;
spin_lock(>lock);
@@ -529,6 +529,9 @@ static void tmio_mmc_data_irq(struct tmio_mmc_host *host)
if (!data)
goto out;
 
+   if (stat & TMIO_STAT_CRCFAIL || stat & TMIO_STAT_STOPBIT_ERR ||
+   stat & TMIO_STAT_TXUNDERRUN)
+   data->error = -EILSEQ;
if (host->chan_tx && (data->flags & MMC_DATA_WRITE) && 
!host->force_pio) {
u32 status = sd_ctrl_read16_and_16_as_32(host, CTL_STATUS);
bool done = false;
@@ -577,8 +580,6 @@ static void tmio_mmc_cmd_irq(struct tmio_mmc_host *host,
goto out;
}
 
-   host->cmd = NULL;
-
/* This controller is sicker than the PXA one. Not only do we need to
 * drop the top 8 bits of the first response word, we also need to
 * modify the order of the response for short response command types.
@@ -598,14 +599,16 @@ static void tmio_mmc_cmd_irq(struct tmio_mmc_host *host,
 
if (stat & TMIO_STAT_CMDTIMEOUT)
cmd->error = -ETIMEDOUT;
-   else if (stat & TMIO_STAT_CRCFAIL && cmd->flags & MMC_RSP_CRC)
+   else if ((stat & TMIO_STAT_CRCFAIL && cmd->flags & MMC_RSP_CRC) ||
+stat & TMIO_STAT_STOPBIT_ERR ||
+stat & TMIO_STAT_CMD_IDX_ERR)
cmd->error = -EILSEQ;
 
/* If there is data to handle we enable data IRQs here, and
 * we will ultimatley finish the request in the data_end handler.
 * If theres no data or we encountered an error, finish now.
 */
-   if (host->data && !cmd->error) {
+   if (host->data && (!cmd->error || cmd->error == -EILSEQ)) {
if (host->data->flags & MMC_DATA_READ) {
if (host->force_pio || !host->chan_rx)
tmio_mmc_enable_mmc_irqs(host, 
TMIO_MASK_READOP);
@@ -666,7 +669,7 @@ static bool __tmio_mmc_sdcard_irq(struct tmio_mmc_host 
*host,
/* Data transfer completion */
if (ireg & TMIO_STAT_DATAEND) {
tmio_mmc_ack_mmc_irqs(host, TMIO_STAT_DATAEND);
-   tmio_mmc_data_irq(host);
+   tmio_mmc_data_irq(host, status);
return true;
}
 
-- 
2.7.0.rc3.207.g0ac5344



Re: [PATCH 2/2] mmc: host: sh_mobile_sdhi: don't populate unneeded functions

2016-09-02 Thread Ulf Hansson
On 2 September 2016 at 07:23, Wolfram Sang  wrote:
> Magnus,
>
>> To my eye it looks like this patch might be adding a fix for a bug
>> introduced by another patch. R-Car Gen2 and later are quite recent
>> SoCs but I believe support for other mobile chips and earlier R-Car
>> SoCs also also covered by the SDHI driver. Also there are theTMIO
>> chips that share some software and are related but a bit different. So
>> in my opinion we need to thread lightly to avoid breakage.
>
> I'm very much with you. This is the very much reason I introduced
> TMIO_MMC_MIN_RCAR2 in 3d376fb2ea907f ("mmc: tmio/sdhi: introduce flag
> for RCar 2+ specific features") in the first place to be able to
> "protect" old hardware from new features. It was not done before! This
> is also the reason why we have commits like a21553c9e0c236 ("mmc:
> tmio/sdhi: distinguish between SCLKDIVEN and ILL_FUNC") documenting a
> difference between some old TMIO variant and our current SDHI. I spent
> quite some time finding old TMIO information somewhere for that.
>
>> My concern is what happened before this patch was applied. It looks
>> like the callbacks were installed for all hardware types which makes
>> me wonder because UHS/SDR support is only available for quite recent
>> hardware.
>
> I didn't protect these callbacks before because I assumed they are only
> called when SDR support is enabled via devicetree or platform data.
> Which is not the case for all the old platforms. I sadly missed that
> card_busy() is used when polling an SDIO card in case "broken-cd" is
> used. That was a detail I overlooked, sorry. Given my work outlined
> above I don't think one can deduce that I don't care about regressing
> old hardware, though.
>
>> The ->card_busy() callback is not yet in mainline or -next. It was
>> introduced in:
>> 0157290 mmc: host: sh_mobile_sdhi: move card_busy from tmio to sdhi
>
> Not quite, it was introduced with 452e5eef6d311e ("mmc: tmio: Add UHS-I
> mode support"). The commit you mentioned moved it from tmio*.c to
> sdhi*.c
>
>> If this patch is fixing a recent commit then perhaps some patches
>> should be squashed together to prevent bisection breakage or if a
>> patch is already part of mainline then a "Fixes:" tag might be
>> suitable.
>
> It can be argued that this tag could be added:
>
> Fixes: 452e5eef6d311e ("mmc: tmio: Add UHS-I mode support")
>
> I don't know how well it applies, though, because the code has been
> modified a lot recently. But we can try.

Please tell me if you would like me to drop any of the changes I
queued up in this series.

Of course, I can also amend the change log, just tell me.

Kind regards
Uffe


Re: R-Car E2 Can interface receive issue

2016-09-02 Thread Roopesh K P

Dear Geert Uytterhoeven,

Thank you very much for your support.

I thought R-CAR M2 SoC have 2 CAN channels and doesn't require a 
hardware port in board to test it with can-utils.  So you means that I 
can only use virtual CAN interface (vcan) in Koelsch or ALT board.


Anyway thanks for the confirmation.


Regards
RKP

On 9/2/2016 1:30 PM, Geert Uytterhoeven wrote:

Hi RKP,

On Fri, Sep 2, 2016 at 9:19 AM, Roopesh K P  wrote:

I assume Koelsch and Porter boards have not much difference in their make
(both are using R-CAR M2 as SoC) and I can boot a Koelsch board with uImage
and dtb(r8a7791-porter.dtb) made for porter board . I did this for testing
CAN interface in my Koelsch board.

Using the DTB for Porter on Koelsch means you're lying about the hardware that's
present, and obviously won't work.

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 v4] clk: renesas: rz: Select EXTAL vs USB clock

2016-09-02 Thread Geert Uytterhoeven
On Fri, Sep 2, 2016 at 4:32 AM, Chris Brandt  wrote:
> Check the MD_CLK pin to determine the current clock mode in order to set
> the pll clock parent correctly.
>
> Signed-off-by: Chris Brandt 

Reviewed-by: Geert Uytterhoeven 

> ---
> V4:
> * added static and __init to rz_cpg_read_mode_pins
> * set cpg_mode during declaration
> v3:
> * move reading GPIO port into separate function
> v2:
> * Switched to reading MD_CLK pin to determine mode

Thanks for the update, will queue in clk-renesas-for-v4.X...

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 12/12] arm64: dts: h3ulcb: Sound SSI support

2016-09-02 Thread Simon Horman
On Fri, Sep 02, 2016 at 01:19:49AM +, Kuninori Morimoto wrote:
> 
> Hi Vladimir
> 
> > This supports SSI sound for H3ULCB board.
> > SSI DMA mode used. CS2000 used as AUDIO_CLK_B.
> > 
> > Signed-off-by: Vladimir Barinov 
> > ---
> 
> Acked-by: Kuninori Morimoto 
> 
> > +   audio_clkout: audio_clkout {
> > +   compatible = "fixed-clock";
> > +   #clock-cells = <0>;
> > +   clock-frequency = <11289600>;
> > +   };
> 
> I think having commont for AUDIO_CLKOUT is better for user, like Salvator-X.
> This "audio_clkout" is dummy. Actually, we don't need this dummy clock,
> and we should use "<_sound 0>" as AUDIO_CLKOUT,
> like AUDIO_CLKOUT3 as "<_sound 3>" which is used on ak4613. 
> But Salvator-X and this ULCB board has very complex connection,
> especially around CS2000.
> This means cs2000 requests rcar_sound, and rcar_sound requests cs2000.
> This audio_clkout exist to avoid probe dead-lock.
> This is the reason why audio_clkout and rcar_sound::clock-frequency
> has same value.

Vladimir,

please address the above and include it when you repost the patches
that I haven't queued up.


[ANNOUNCE] Renesas tree closing for v4.9

2016-09-02 Thread Simon Horman
Hi,

I would like to stop accepting non-fix patches for v4.9 next week. This is
in order for them to be sent before the release of v4.8-rc6, the deadline
set by the ARM SoC maintainers. As patches should ideally progress from
the renesas tree into linux-next before sending pull requests there is a
few days lead time involved.


Re: [PATCH v2 1/3] ARM: dts: r7s72100: add ethernet clock to device tree

2016-09-02 Thread Simon Horman
Thanks Chris,

I have queued up this and the following 2 patches for v4.9 (nothing more
for you to do unless something goes wrong in which case I'll let you know).

For future submissions please consider:
1. Supplying a cover letter (git format-patch has a --cover-letter option)
   for patch-sets comprising more than one patch. This allows you to describe
   an overview of what the series as a whole achieves. And is also
   convenient for maintainers to reply to when accepting your patches.
2. Starting a new thread for each new version of a patch/patch-set.

Different maintainers have different preferences. The above are mine.


Re: [PATCH v2 1/4] v4l: Add metadata buffer type and format

2016-09-02 Thread Sakari Ailus
Hi Laurent,

On Fri, Sep 02, 2016 at 12:40:18AM +0300, Laurent Pinchart wrote:
...
> > >> +Data Format Negotiation
> > >> +===
> > >> +
> > >> +The metadata device uses the :ref:`format` ioctls to select the capture
> > >> format. +The metadata buffer content format is bound to that selected
> > >> format. In addition +to the basic :ref:`format` ioctls, the
> > >> 
> > >> :ref:`VIDIOC_ENUM_FMT` ioctl must be +supported as well.
> > >> 
> > >> +
> > >> +To use the :ref:`format` ioctls applications set the ``type`` of the
> > >> +:ref:`v4l2_format ` structure to
> > >> ``V4L2_BUF_TYPE_META_CAPTURE`` +and use the :ref:`v4l2_meta_format
> > >> ` ``meta`` member of the +``fmt`` union as needed per
> > >> the desired operation. The :ref:`v4l2-meta-format` +structure contains
> > >> two fields, ``dataformat`` is set by applications to the V4L2
> > > 
> > > I might not specify the number of number of fields here. It has high
> > > chances of not getting updated when more fields are added. Up to you.
> > 
> > This has been copied from dev-sdr.rst. I can drop the last sentence
> > completely as the parameters are described in the table below. Hans, any
> > opinion ?
> 
> How about this ?
> 
> To use the :ref:`format` ioctls applications set the ``type`` of the

s/of/field of/

?

> :ref:`v4l2_format ` structure to ``V4L2_BUF_TYPE_META_CAPTURE``
> and use the :ref:`v4l2_meta_format ` ``meta`` member of the
> ``fmt`` union as needed per the desired operation. Both drivers and 
> applications must set the remainder of the :ref:`v4l2_format ` 
> structure to 0.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk


Re: [PATCH v3 01/13] ARM: dts: lager: rename and reindex i2cexio

2016-09-02 Thread Simon Horman
On Tue, Aug 30, 2016 at 05:29:08PM +0200, Wolfram Sang wrote:
> Hi Simon,
> 
> > serial0 = 
> > serial1 = 
> > -   i2c8 = "i2cexio";
> > +   i2c10 = "i2cexio0";
> 
> Those should be pointers, i.e. "", here and in the rest of
> your series. Sorry for the broken template!

Thanks, got it.

> Did you have a chance to
> test my fix for the demuxer?

Sorry, not yet.




Re: [PATCH] ARM: shmobile: fix regulator quirk for Gen2

2016-09-02 Thread Simon Horman
On Thu, Sep 01, 2016 at 09:00:07PM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 1, 2016 at 4:27 PM, Wolfram Sang  wrote:
> > On Thu, Sep 01, 2016 at 04:22:37PM +0200, Simon Horman wrote:
> >> On Tue, Aug 30, 2016 at 05:15:58PM +0200, Geert Uytterhoeven wrote:
> >> > On Tue, Aug 30, 2016 at 4:54 PM, Wolfram Sang
> >> >  wrote:
> >> > > The current implementation only works if the da9xxx devices are added
> >> > > before their drivers are registered. Only then it can apply the fixes 
> >> > > to
> >> > > both devices. Otherwise, the driver for the first device gets probed
> >> > > before the fix for the second device can be applied. This is what
> >> > > fails when using the IP core switcher or when having the i2c master
> >> > > driver as a module.
> >> >
> >> > > So, we need to disable both da9xxx once we detected one of them. We now
> >> > > use i2c_transfer with hardcoded i2c_messages and device addresses, so 
> >> > > we
> >> > > don't need the da9xxx client devices to be instantiated. Because the
> >> > > fixup is used on specific boards only, the addresses are not going to
> >> > > change.
> >> > >
> >> > > Signed-off-by: Wolfram Sang 
> >> >
> >> > Reviewed-by: Geert Uytterhoeven 
> >> > Tested-by: Geert Uytterhoeven  (r8a7791/koelsch)
> >>
> >> Can I get a Fixes tag or some indication of if it should apply
> >> to v4.9 or as a fix for v4.8.
> >
> > I'd say:
> >
> > Fixes: 663fbb52159cca ("ARM: shmobile: R-Car Gen2: Add da9063/da9210 
> > regulator quirk")
> >
> > and should go to 4.8. Geert?
> 
> That's right. CC stable, for v4.1+ and any LTS(I) it's been backported to.

Thanks, got it.


Re: renesas-drivers-2016-08-23-v4.8-rc3

2016-09-02 Thread Geert Uytterhoeven
Hi Morimoto-san,

On Fri, Sep 2, 2016 at 3:38 AM, Kuninori Morimoto
 wrote:
>> >> Even with my recent patch?
>> >
>> > I tried your patch, and it solved this issue.
>>
>> Interesting...
>>
>> Does "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU
>> cores in debug mode", without Wolfram's patch, also fix it?
>
> Interesting...
>
> Your patch (without Wolfram's patch) also solved this issue

I can offer some explanation, though...

The regulator quirk code masks all interrupts and events. Some of these events
are error states, but not all of them are. Hence they may be set (and cause
problems due to unhandled interrupts without the quirk) depending on power
consumption on the various power rails. The latter are influenced by secondary
CPU booting, and possibly by configuration of reset debug hardware.

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] drm/bridge: adv7511: add support for the 2nd chip

2016-09-02 Thread Archit Taneja

Hi,

On 9/2/2016 2:13 AM, Sergei Shtylyov wrote:

The Renesas Wheat board has 2 ADV7513 chips on the same I2C bus, however
the ADV751x driver only supports 1 chip as  it tries to assign the packet/
EDID/CEC  memory I2C devices  to the fixed I2C addresses. Assign these I2C
addresses at the fixed offsets (derived from the programming guide) from
the  main register map address  instead...

Signed-off-by: Sergei Shtylyov 

---
The patch is against David Airlie's 'linux.git' repo's 'drm-next' branch.

  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |   12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

Index: linux/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
===
--- linux.orig/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ linux/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -922,15 +922,13 @@ static int adv7511_parse_dt(struct devic
return 0;
  }

-static const int edid_i2c_addr = 0x7e;
-static const int packet_i2c_addr = 0x70;
-static const int cec_i2c_addr = 0x78;
-
  static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id 
*id)
  {
struct adv7511_link_config link_config;
struct adv7511 *adv7511;
struct device *dev = >dev;
+   unsigned int main_i2c_addr = i2c->addr << 1;
+   unsigned int edid_i2c_addr = main_i2c_addr + 4;
unsigned int val;
int ret;

@@ -991,8 +989,10 @@ static int adv7511_probe(struct i2c_clie

regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
-packet_i2c_addr);
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr);
+main_i2c_addr - 0xa);
+   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
+main_i2c_addr - 2);


The adv7533.c part of the driver uses cec_i2c_addr to create a another
dummy i2c device for CEC. Could you update this patch to derive the
cec address from the main i2c address for the ADV7533 part too?

Thanks,
Archit


+
adv7511_packet_disable(adv7511, 0x);

adv7511->i2c_main = i2c;

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



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: R-Car E2 Can interface receive issue

2016-09-02 Thread Geert Uytterhoeven
Hi RKP,

On Fri, Sep 2, 2016 at 9:19 AM, Roopesh K P  wrote:
> I assume Koelsch and Porter boards have not much difference in their make
> (both are using R-CAR M2 as SoC) and I can boot a Koelsch board with uImage
> and dtb(r8a7791-porter.dtb) made for porter board . I did this for testing
> CAN interface in my Koelsch board.

Using the DTB for Porter on Koelsch means you're lying about the hardware that's
present, and obviously won't work.

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 0/12] arm64: renesas: add H3ULCB board

2016-09-02 Thread Simon Horman
On Thu, Sep 01, 2016 at 09:25:08PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Thu, Sep 1, 2016 at 4:17 PM, Simon Horman  wrote:
> >> > [01/12] dt: arm: shmobile: add H3ULCB board DT bindings
> >
> > I have queued up the above patch after renaming it
> > arm64: dts: h3ulcb: enable USB2.0 Host channel 1
> >
> >> > [02/12] arm64: dts: h3ulcb: initial device tree
> >> > [03/12] arm64: dts: h3ulcb: enable SCIF clk and pins
> >> > [04/12] arm64: dts: h3ulcb: enable EthernetAVB
> >> > [05/12] arm64: dts: h3ulcb: enable GPIO leds
> >> > [06/12] arm64: dts: h3ulcb: enable SDHI0
> >> > [07/12] arm64: dts: h3ulcb: enable I2C2
> >> > [08/12] arm64: dts: h3ulcb: enable EXTALR clk
> >> > [09/12] arm64: dts: h3ulcb: enable WDT
> >> > [10/12] arm64: dts: h3ulcb: enable USB2 PHY of channel 1
> >> > [11/12] arm64: dts: h3ulcb: enable USB2.0 Host channel 1
> >>
> >> I went through all of the above...
> >
> > I have also queued up 02,03,04,07,08,09,11/12.
> 
> Any specific reason you skipped 10/12? I'm afraid it's a prerequisite for
> 11/12.

Thanks for pointing that out, it is an oversight.
I have queued up 10/12 and plan to push a bit later today.


Re: [PATCH v2 1/4] v4l: Add metadata buffer type and format

2016-09-02 Thread Sakari Ailus
Huomenta!

On Fri, Sep 02, 2016 at 12:22:42AM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Monday 29 Aug 2016 12:13:40 Sakari Ailus wrote:
> > On Wed, Aug 17, 2016 at 03:20:27PM +0300, Laurent Pinchart wrote:
> > > The metadata buffer type is used to transfer metadata between userspace
> > > and kernelspace through a V4L2 buffers queue. It comes with a new
> > > metadata capture capability and format description.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > > Tested-by: Guennadi Liakhovetski 
> > > ---
> > > Changes since v1:
> > > 
> > > - Rebased on top of the DocBook to reST conversion
> > > 
> > >  Documentation/media/uapi/v4l/buffer.rst  |  8 +++
> > >  Documentation/media/uapi/v4l/dev-meta.rst| 69 +++
> > >  Documentation/media/uapi/v4l/devices.rst |  1 +
> > >  Documentation/media/uapi/v4l/vidioc-querycap.rst | 14 +++--
> > >  Documentation/media/videodev2.h.rst.exceptions   |  2 +
> > >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 +++
> > >  drivers/media/v4l2-core/v4l2-dev.c   | 16 +++---
> > >  drivers/media/v4l2-core/v4l2-ioctl.c | 41 ++
> > >  drivers/media/v4l2-core/videobuf2-v4l2.c |  3 ++
> > >  include/media/v4l2-ioctl.h   | 17 ++
> > >  include/uapi/linux/videodev2.h   | 14 +
> > >  11 files changed, 195 insertions(+), 9 deletions(-)
> > >  create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst
> 
> [snip]
> 
> > > diff --git a/Documentation/media/uapi/v4l/dev-meta.rst
> > > b/Documentation/media/uapi/v4l/dev-meta.rst new file mode 100644
> > > index ..252ed05b4841
> > > --- /dev/null
> > > +++ b/Documentation/media/uapi/v4l/dev-meta.rst
> > > @@ -0,0 +1,69 @@
> > > +.. -*- coding: utf-8; mode: rst -*-
> > > +
> > > +.. _metadata:
> > > +
> > > +**
> > > +Metadata Interface
> > > +**
> > > +
> > > +Metadata refers to any non-image data that supplements video frames with
> > > +additional information. This may include statistics computed over the
> > > image +or frame capture parameters supplied by the image source. This
> > > interface is +intended for transfer of metadata to userspace and control
> > > of that operation. +
> > > +The metadata interface is implemented on video capture device nodes. The
> > > device +can be dedicated to metadata or can implement both video and
> > > metadata capture +as specified in its reported capabilities.
> > > +
> > > +.. note::
> > > +
> > > +This is an :ref:`experimental` interface and may
> > > +change in the future.
> > > +
> > > +Querying Capabilities
> > > +=
> > > +
> > > +Device nodes supporting the metadata interface set the
> > > ``V4L2_CAP_META_CAPTURE`` +flag in the ``device_caps`` field of the
> > > +:ref:`v4l2_capability ` structure returned by the
> > > +:ref:`VIDIOC_QUERYCAP` ioctl. That flag means the device can capture
> > > +metadata to memory.
> > > +
> > > +At least one of the read/write or streaming I/O methods must be
> > > supported.
> > > +
> > > +
> > > +Data Format Negotiation
> > > +===
> > > +
> > > +The metadata device uses the :ref:`format` ioctls to select the capture
> > > format. +The metadata buffer content format is bound to that selected
> > > format. In addition +to the basic :ref:`format` ioctls, the
> > > :ref:`VIDIOC_ENUM_FMT` ioctl must be +supported as well.
> > > +
> > > +To use the :ref:`format` ioctls applications set the ``type`` of the
> > > +:ref:`v4l2_format ` structure to
> > > ``V4L2_BUF_TYPE_META_CAPTURE`` +and use the :ref:`v4l2_meta_format
> > > ` ``meta`` member of the +``fmt`` union as needed per
> > > the desired operation. The :ref:`v4l2-meta-format` +structure contains
> > > two fields, ``dataformat`` is set by applications to the V4L2
> >
> > I might not specify the number of number of fields here. It has high chances
> > of not getting updated when more fields are added. Up to you.
> 
> This has been copied from dev-sdr.rst. I can drop the last sentence 
> completely 
> as the parameters are described in the table below. Hans, any opinion ?
> 
> > > +FourCC code of the desired format, and ``buffersize`` set by drivers to
> > > the +maximum buffer size (in bytes) required for data transfer.
> > > +
> > > +.. _v4l2-meta-format:
> > > +.. flat-table:: struct v4l2_meta_format
> > > +:header-rows:  0
> > > +:stub-columns: 0
> > > +:widths:   1 1 2
> > > +
> > > +* - __u32
> > > +  - ``dataformat``
> > > +  - The data format, set by the application. This is a little endian
> > > +:ref:`four character code `. V4L2 defines metadata
> > > formats +in :ref:`meta-formats`.
> > > +* - __u32
> > > +  - ``buffersize``
> > > +  - Maximum buffer size in bytes required for data. The value is set
> > > by the +driver.