[PATCH] media: soc_camera: rcar_vin: Add R-Car Gen3 support

[PATCH] media: soc_camera: rcar_vin: Add R-Car Gen3 support

[Yoshihiro Kaneko]

From: Yoshihiko Mori <yoshihiko.mori.nx@renesas.com>

Add chip identification for R-Car Gen3.

Signed-off-by: Yoshihiko Mori <yoshihiko.mori.nx@renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
---

This patch is against master branch of linuxtv.org/media_tree.git.

 Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
 drivers/media/platform/soc_camera/rcar_vin.c         | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 9dafe6b..619193c 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -6,6 +6,7 @@ family of devices. The current blocks are always slaves and suppot one input
 channel which can be either RGB, YUYV or BT656.
 
  - compatible: Must be one of the following
+   - "renesas,vin-r8a7795" for the R8A7795 device
    - "renesas,vin-r8a7794" for the R8A7794 device
    - "renesas,vin-r8a7793" for the R8A7793 device
    - "renesas,vin-r8a7791" for the R8A7791 device
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c
index 5d90f39..29e7ca4 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -143,6 +143,7 @@
 #define RCAR_VIN_BT656			(1 << 3)
 
 enum chip_id {
+	RCAR_GEN3,
 	RCAR_GEN2,
 	RCAR_H1,
 	RCAR_M1,
@@ -1846,6 +1847,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
 
 #ifdef CONFIG_OF
 static const struct of_device_id rcar_vin_of_table[] = {
+	{ .compatible = "renesas,vin-r8a7795", .data = (void *)RCAR_GEN3 },
 	{ .compatible = "renesas,vin-r8a7794", .data = (void *)RCAR_GEN2 },
 	{ .compatible = "renesas,vin-r8a7793", .data = (void *)RCAR_GEN2 },
 	{ .compatible = "renesas,vin-r8a7791", .data = (void *)RCAR_GEN2 },
-- 
1.9.1

Re: [PATCH] media: soc_camera: rcar_vin: Add R-Car Gen3 support

[Sergei Shtylyov]

On 12/13/2015 06:27 PM, Yoshihiro Kaneko wrote:

> From: Yoshihiko Mori <yoshihiko.mori.nx@renesas.com>
>
> Add chip identification for R-Car Gen3.
>
> Signed-off-by: Yoshihiko Mori <yoshihiko.mori.nx@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
[...]
> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c
> index 5d90f39..29e7ca4 100644
> --- a/drivers/media/platform/soc_camera/rcar_vin.c
> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> @@ -143,6 +143,7 @@
>   #define RCAR_VIN_BT656			(1 << 3)
>
>   enum chip_id {
> +	RCAR_GEN3,
>   	RCAR_GEN2,
>   	RCAR_H1,
>   	RCAR_M1,
> @@ -1846,6 +1847,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
>
>   #ifdef CONFIG_OF
>   static const struct of_device_id rcar_vin_of_table[] = {
> +	{ .compatible = "renesas,vin-r8a7795", .data = (void *)RCAR_GEN3 },

    I don't see where this is checked in the driver. Shouldn't we just use gen2?

MBR, Sergei

Re: [PATCH] media: soc_camera: rcar_vin: Add R-Car Gen3 support

[Yoshihiro Kaneko]

Hi,

2015-12-14 2:43 GMT+09:00 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>:
> On 12/13/2015 06:27 PM, Yoshihiro Kaneko wrote:
>
>> From: Yoshihiko Mori <yoshihiko.mori.nx@renesas.com>
>>
>> Add chip identification for R-Car Gen3.
>>
>> Signed-off-by: Yoshihiko Mori <yoshihiko.mori.nx@renesas.com>
>> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>
> [...]
>>
>> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
>> b/drivers/media/platform/soc_camera/rcar_vin.c
>> index 5d90f39..29e7ca4 100644
>> --- a/drivers/media/platform/soc_camera/rcar_vin.c
>> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
>> @@ -143,6 +143,7 @@
>>   #define RCAR_VIN_BT656                        (1 << 3)
>>
>>   enum chip_id {
>> +       RCAR_GEN3,
>>         RCAR_GEN2,
>>         RCAR_H1,
>>         RCAR_M1,
>> @@ -1846,6 +1847,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops
>> = {
>>
>>   #ifdef CONFIG_OF
>>   static const struct of_device_id rcar_vin_of_table[] = {
>> +       { .compatible = "renesas,vin-r8a7795", .data = (void *)RCAR_GEN3
>> },
>
>
>    I don't see where this is checked in the driver. Shouldn't we just use
> gen2?

I'd like to withdraw this patch now.
I intend to post the series patch including this patch at another day.

>
> MBR, Sergei
>

Thanks,
kaneko

Re: [PATCH] media: soc_camera: rcar_vin: Add R-Car Gen3 support

[Guennadi Liakhovetski]

Hi Sergei,

On Sun, 13 Dec 2015, Sergei Shtylyov wrote:

> On 12/13/2015 06:27 PM, Yoshihiro Kaneko wrote:
> 
> > From: Yoshihiko Mori <yoshihiko.mori.nx@renesas.com>
> > 
> > Add chip identification for R-Car Gen3.
> > 
> > Signed-off-by: Yoshihiko Mori <yoshihiko.mori.nx@renesas.com>
> > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> [...]
> > diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
> > b/drivers/media/platform/soc_camera/rcar_vin.c
> > index 5d90f39..29e7ca4 100644
> > --- a/drivers/media/platform/soc_camera/rcar_vin.c
> > +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> > @@ -143,6 +143,7 @@
> >   #define RCAR_VIN_BT656			(1 << 3)
> > 
> >   enum chip_id {
> > +	RCAR_GEN3,
> >   	RCAR_GEN2,
> >   	RCAR_H1,
> >   	RCAR_M1,
> > @@ -1846,6 +1847,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops =
> > {
> > 
> >   #ifdef CONFIG_OF
> >   static const struct of_device_id rcar_vin_of_table[] = {
> > +	{ .compatible = "renesas,vin-r8a7795", .data = (void *)RCAR_GEN3 },
> 
>    I don't see where this is checked in the driver. Shouldn't we just use
> gen2?

That would be different. What this patch does is not the same, as using 
GEN2. GEN2 is used in the driver when setting up the hardware for RGB32, 
so, if you would use GEN2 for r8a7795 as well, that code path would be 
used for it too. This patch adds GEN3 without modifying that check, so, if 
you now attempt to use RGB32 with GEN3 / r8a7795 it would issue an 
"invalid" warning and fail. Of course, I have no idea, whether this is the 
intended behaviour, especially since many other chips do seem to support 
RGB32 via that code...

Thanks
Guennadi

> 
> MBR, Sergei
>