Re: [PATCH 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Geert Uytterhoeven]

Hi Niklas, Uli,

On Fri, Mar 9, 2018 at 11:24 PM, Geert Uytterhoeven
 wrote:
> On Fri, Mar 9, 2018 at 10:58 PM, Niklas Söderlund
>  wrote:
>> On 2018-03-09 13:33:03 +0100, Geert Uytterhoeven wrote:
>>> P.S. Apparently R-Car Gen2 and Gen3 also support 8-bit YCbCr input data
>>>  on the DATA8-15 pins, for which we don't have pin groups yet.
>>>  Niklas: is this mode supported by the VIN driver?
>>
>> * Gen2
>> I can't find DATA12-15 in the datasheet I have, where did you find them?
>> I'm looking at Tables 26.3, 26.4 and 26.5 on v1.0 of the Gen2 datasheet.
>> But yes on Gen2 the VIN driver supports capturing from these data pins.
>
> Sorry, on Gen2 (all but V2H, to make matters more complicated), the DATA pins
> are not numbered from 0 to 23, but split in 3 blocks of 8 pins, matching R, G,
> and B blocks. But apart from the numbering, the formats are mostly the same (4
> bit width is the exception, and supported on Gen2 only).
>
> What I meant is the third mode in e.g. Table 26.5, "ITU-R BT.601/BT.709/BT.656
> 8-bit YCbCr-422 (VnDMR2/YDS = 1)", which uses VI0_G[7:0] instead of VIO_B[7:0]
> for transfering 8-bit YCbCr data. Apparently the PFC driver doesn't have a pin
> group for that combo.

Apparently the BSP has support for using the upper 8 MSB of the 16-bit
interface, and calls the pin group "data8_sft8".

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 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Niklas Söderlund]

Hi Geert,

On 2018-03-09 23:24:37 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Fri, Mar 9, 2018 at 10:58 PM, Niklas Söderlund
>  wrote:
> > On 2018-03-09 13:33:03 +0100, Geert Uytterhoeven wrote:
> >> P.S. Apparently R-Car Gen2 and Gen3 also support 8-bit YCbCr input data
> >>  on the DATA8-15 pins, for which we don't have pin groups yet.
> >>  Niklas: is this mode supported by the VIN driver?
> >
> > * Gen2
> > I can't find DATA12-15 in the datasheet I have, where did you find them?
> > I'm looking at Tables 26.3, 26.4 and 26.5 on v1.0 of the Gen2 datasheet.
> > But yes on Gen2 the VIN driver supports capturing from these data pins.
> 
> Sorry, on Gen2 (all but V2H, to make matters more complicated), the DATA pins
> are not numbered from 0 to 23, but split in 3 blocks of 8 pins, matching R, G,
> and B blocks. But apart from the numbering, the formats are mostly the same (4
> bit width is the exception, and supported on Gen2 only).
> 
> What I meant is the third mode in e.g. Table 26.5, "ITU-R BT.601/BT.709/BT.656
> 8-bit YCbCr-422 (VnDMR2/YDS = 1)", which uses VI0_G[7:0] instead of VIO_B[7:0]
> for transfering 8-bit YCbCr data. Apparently the PFC driver doesn't have a pin
> group for that combo.
> 
> (I have v2.00 of the datasheet, but the table looks identical in v1.0).
> 
> > * Gen3
> > Currently CSI-2 are the only supported input method for the Gen3
> > patches. It would be possible with a small hack to run the Gen2 driver
> > on Gen3 and have it try and use the DATA pins, but this is not tested as
> > prior to V3M we had no device to test this on as the DATA pins where all
> > routed to EXIO connectors.
> >
> > There have been some talks about adding support for this to the driver,
> > I know Jacopo posted a patch-set a while ago for this but I have not
> > tested it. Looking at the Gen3 Table 26.8.1 it sure looks like all
> > DATA lines DATA0-23 could be used on some SoCs to capture 24 bit RGB and
> > YCbCr.
> 
> My question was about the second mode in the table, which is the same one
> as the third mode on Gen2.

Ahh I see my bad. The current VIN driver for Gen2 which is the only one 
where this is supported can use the following input formats:

ITU-R BT.656 8-Bit
ITU-R BT.656 10-Bit
ITU-R BT.601 8-Bit
ITU-R BT.601 10-Bit
ITU-R BT.601/BT.709/BT.1358 16-Bit
ITU-R BT.601/BT.709 (RGB888) 24-Bit

But I do not have the hardware to be able to verify that all modes 
actually work. All modes are carried over from the driver conversion 
from soc-camera.

Looking at the Koelsch the modes that are tested are 'ITU-R 
BT.601/BT.709 (RGB888) 24-Bit' from the ADV7612 and 'ITU-R BT.656 8-Bit' 
from the ADV7180.

> 
> 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

-- 
Regards,
Niklas Söderlund

Re: [PATCH 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Geert Uytterhoeven]

Hi Niklas,

On Fri, Mar 9, 2018 at 10:58 PM, Niklas Söderlund
 wrote:
> On 2018-03-09 13:33:03 +0100, Geert Uytterhoeven wrote:
>> P.S. Apparently R-Car Gen2 and Gen3 also support 8-bit YCbCr input data
>>  on the DATA8-15 pins, for which we don't have pin groups yet.
>>  Niklas: is this mode supported by the VIN driver?
>
> * Gen2
> I can't find DATA12-15 in the datasheet I have, where did you find them?
> I'm looking at Tables 26.3, 26.4 and 26.5 on v1.0 of the Gen2 datasheet.
> But yes on Gen2 the VIN driver supports capturing from these data pins.

Sorry, on Gen2 (all but V2H, to make matters more complicated), the DATA pins
are not numbered from 0 to 23, but split in 3 blocks of 8 pins, matching R, G,
and B blocks. But apart from the numbering, the formats are mostly the same (4
bit width is the exception, and supported on Gen2 only).

What I meant is the third mode in e.g. Table 26.5, "ITU-R BT.601/BT.709/BT.656
8-bit YCbCr-422 (VnDMR2/YDS = 1)", which uses VI0_G[7:0] instead of VIO_B[7:0]
for transfering 8-bit YCbCr data. Apparently the PFC driver doesn't have a pin
group for that combo.

(I have v2.00 of the datasheet, but the table looks identical in v1.0).

> * Gen3
> Currently CSI-2 are the only supported input method for the Gen3
> patches. It would be possible with a small hack to run the Gen2 driver
> on Gen3 and have it try and use the DATA pins, but this is not tested as
> prior to V3M we had no device to test this on as the DATA pins where all
> routed to EXIO connectors.
>
> There have been some talks about adding support for this to the driver,
> I know Jacopo posted a patch-set a while ago for this but I have not
> tested it. Looking at the Gen3 Table 26.8.1 it sure looks like all
> DATA lines DATA0-23 could be used on some SoCs to capture 24 bit RGB and
> YCbCr.

My question was about the second mode in the table, which is the same one
as the third mode on Gen2.

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 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Niklas Söderlund]

Hi Geert,

On 2018-03-09 13:33:03 +0100, Geert Uytterhoeven wrote:
> Hi Uli,
> 
> On Mon, Feb 26, 2018 at 11:18 AM, Geert Uytterhoeven
>  wrote:
> > On Mon, Feb 26, 2018 at 10:21 AM, Geert Uytterhoeven
> >  wrote:
> >> On Mon, Feb 26, 2018 at 10:02 AM, Ulrich Hecht
> >>  wrote:
> >>> On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
> >>>  wrote:
>  Would there be a use case for vin4_data4 and vin5_data4, or is that
>  mode only supported on R-Car H2?
> >>>
> >>> The docs don't mention it, so I would assume it's not supported.
> >>
> >> Thank you, queuing (also for r8a7795 and r8a77995) in sh-pfc-for-v4.17.
> >
> > Please send follow-up patches to reduce vin_data duplication.
> 
> Due to Sergei's submission for r8a77980, my attention was drawn to
> Tables 26.8.x, which describes which pins are used for each video input
> format.
> 
> The newly added tables for data18 are not correct, as they use the
> VI4_DATA0-17 pins, while data18/rgb666 uses the same pins as data24/rgb888
> mode, minus the 2 LSB pins for each channel. The BSP does it right, just
> like the R-Car Gen2 PFC drivers.
> 
> As in the mean time this is in pinctrl/for-next, can you please send
> follow-up patches fixing this bug for R-Car H3, M3-W, and D3?
> 
> Thanks!
> 
> P.S. Apparently R-Car Gen2 and Gen3 also support 8-bit YCbCr input data
>  on the DATA8-15 pins, for which we don't have pin groups yet.
>  Niklas: is this mode supported by the VIN driver?

* Gen2
I can't find DATA12-15 in the datasheet I have, where did you find them?  
I'm looking at Tables 26.3, 26.4 and 26.5 on v1.0 of the Gen2 datasheet.  
But yes on Gen2 the VIN driver supports capturing from these data pins.

* Gen3
Currently CSI-2 are the only supported input method for the Gen3 
patches. It would be possible with a small hack to run the Gen2 driver 
on Gen3 and have it try and use the DATA pins, but this is not tested as 
prior to V3M we had no device to test this on as the DATA pins where all 
routed to EXIO connectors.

There have been some talks about adding support for this to the driver, 
I know Jacopo posted a patch-set a while ago for this but I have not 
tested it. Looking at the Gen3 Table 26.8.1 it sure looks like all
DATA lines DATA0-23 could be used on some SoCs to capture 24 bit RGB and 
YCbCr.

> 
> 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

-- 
Regards,
Niklas Söderlund

Re: [PATCH 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Geert Uytterhoeven]

Hi Uli,

On Mon, Feb 26, 2018 at 11:18 AM, Geert Uytterhoeven
 wrote:
> On Mon, Feb 26, 2018 at 10:21 AM, Geert Uytterhoeven
>  wrote:
>> On Mon, Feb 26, 2018 at 10:02 AM, Ulrich Hecht
>>  wrote:
>>> On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
>>>  wrote:
 Would there be a use case for vin4_data4 and vin5_data4, or is that
 mode only supported on R-Car H2?
>>>
>>> The docs don't mention it, so I would assume it's not supported.
>>
>> Thank you, queuing (also for r8a7795 and r8a77995) in sh-pfc-for-v4.17.
>
> Please send follow-up patches to reduce vin_data duplication.

Due to Sergei's submission for r8a77980, my attention was drawn to
Tables 26.8.x, which describes which pins are used for each video input
format.

The newly added tables for data18 are not correct, as they use the
VI4_DATA0-17 pins, while data18/rgb666 uses the same pins as data24/rgb888
mode, minus the 2 LSB pins for each channel. The BSP does it right, just
like the R-Car Gen2 PFC drivers.

As in the mean time this is in pinctrl/for-next, can you please send
follow-up patches fixing this bug for R-Car H3, M3-W, and D3?

Thanks!

P.S. Apparently R-Car Gen2 and Gen3 also support 8-bit YCbCr input data
 on the DATA8-15 pins, for which we don't have pin groups yet.
 Niklas: is this mode supported by the VIN driver?

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 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Geert Uytterhoeven]

Hi Uli,

On Mon, Feb 26, 2018 at 10:21 AM, Geert Uytterhoeven
 wrote:
> On Mon, Feb 26, 2018 at 10:02 AM, Ulrich Hecht
>  wrote:
>> On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
>>  wrote:
>>> Would there be a use case for vin4_data4 and vin5_data4, or is that
>>> mode only supported on R-Car H2?
>>
>> The docs don't mention it, so I would assume it's not supported.
>
> Thank you, queuing (also for r8a7795 and r8a77995) in sh-pfc-for-v4.17.

Please send follow-up patches to reduce vin_data duplication.

Thanks!

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 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Geert Uytterhoeven]

Hi Ulrich,

On Mon, Feb 26, 2018 at 10:02 AM, Ulrich Hecht
 wrote:
> On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
>  wrote:
>> Would there be a use case for vin4_data4 and vin5_data4, or is that
>> mode only supported on R-Car H2?
>
> The docs don't mention it, so I would assume it's not supported.

Thank you, queuing (also for r8a7795 and r8a77995) in sh-pfc-for-v4.17.

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 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Ulrich Hecht]

On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
 wrote:
> Would there be a use case for vin4_data4 and vin5_data4, or is that
> mode only supported on R-Car H2?

The docs don't mention it, so I would assume it's not supported.

CU
Uli

Re: [PATCH 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Geert Uytterhoeven]

Hi Uli,

On Thu, Feb 15, 2018 at 1:01 PM, Ulrich Hecht
 wrote:
> This patch adds VIN4 and VIN5 pins, groups and functions for the
> R8A7796 SoC.
>
> Signed-off-by: Ulrich Hecht 

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven 

However, I guess you can use union vin_data and VIN_DATA_PIN_GROUP() to
reduce duplication, like on R-Car Gen2?

Would there be a use case for vin4_data4 and vin5_data4, or is that
mode only supported on R-Car H2?

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

[PATCH 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Ulrich Hecht]

This patch adds VIN4 and VIN5 pins, groups and functions for the
R8A7796 SoC.

Signed-off-by: Ulrich Hecht 
---
 drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 454 +++
 1 file changed, 454 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
index e5807d1..0ad8750 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
@@ -3853,6 +3853,400 @@ static const unsigned int usb30_mux[] = {
USB30_PWEN_MARK, USB30_OVC_MARK,
 };
 
+/* - VIN4 --- 
*/
+static const unsigned int vin4_data8_a_pins[] = {
+   RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9),
+   RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+   RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+   RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+};
+static const unsigned int vin4_data8_a_mux[] = {
+   VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+   VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+   VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+   VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+};
+static const unsigned int vin4_data8_b_pins[] = {
+   RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+   RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+   RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+   RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+};
+static const unsigned int vin4_data8_b_mux[] = {
+   VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+   VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+   VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+   VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+};
+static const unsigned int vin4_data10_a_pins[] = {
+   RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9),
+   RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+   RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+   RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+   RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+};
+static const unsigned int vin4_data10_a_mux[] = {
+   VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+   VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+   VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+   VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+   VI4_DATA8_MARK,  VI4_DATA9_MARK,
+};
+static const unsigned int vin4_data10_b_pins[] = {
+   RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+   RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+   RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+   RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+   RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+};
+static const unsigned int vin4_data10_b_mux[] = {
+   VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+   VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+   VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+   VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+   VI4_DATA8_MARK,  VI4_DATA9_MARK,
+};
+static const unsigned int vin4_data12_a_pins[] = {
+   RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9),
+   RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+   RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+   RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+   RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+   RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+};
+static const unsigned int vin4_data12_a_mux[] = {
+   VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+   VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+   VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+   VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+   VI4_DATA8_MARK,  VI4_DATA9_MARK,
+   VI4_DATA10_MARK, VI4_DATA11_MARK,
+};
+static const unsigned int vin4_data12_b_pins[] = {
+   RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+   RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+   RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+   RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+   RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+   RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+};
+static const unsigned int vin4_data12_b_mux[] = {
+   VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+   VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+   VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+   VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+   VI4_DATA8_MARK,  VI4_DATA9_MARK,
+   VI4_DATA10_MARK, VI4_DATA11_MARK,
+};
+static const unsigned int vin4_data16_a_pins[] = {
+   RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9),
+   RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+   RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+   RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+   RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+   RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+   RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+   RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+};
+static const unsigned int vin4_data16_a_mux[] = {
+   VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+   VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+   VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+   VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+   VI4_DATA8_MARK,  VI4_DATA9_MARK,
+   VI4_DATA10_MARK, VI4_DATA11_MARK,
+   VI4_DATA12_MARK, VI4_DATA13_MARK,
+   VI4_DATA14_MARK, VI4_DATA15_MARK,
+};
+static const unsigned int vin4_data16_b_pins[] = {
+   RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+   RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),