Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

2017-11-15 Thread Rob Herring
On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
> Document the devicetree bindings for the CSI-2 inputs available on Gen3.
> 
> There is a need to add a custom property 'renesas,id' and to define
> which CSI-2 input is described in which endpoint under the port@1 node.
> This information is needed since there are a set of predefined routes
> between each VIN and CSI-2 block. This routing table will be kept
> inside the driver but in order for it to act on it it must know which
> VIN and CSI-2 is which.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../devicetree/bindings/media/rcar_vin.txt | 116 
> ++---
>  1 file changed, 104 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>  ---
>  
>  The rcar_vin device provides video input capabilities for the Renesas R-Car
> -family of devices. The current blocks are always slaves and suppot one input
> -channel which can be either RGB, YUYV or BT656.
> +family of devices.
> +
> +Each VIN instance has a single parallel input that supports RGB and YUV 
> video,
> +with both external synchronization and BT.656 synchronization for the latter.
> +Depending on the instance the VIN input is connected to external SoC pins, or
> +on Gen3 to a CSI-2 receiver.
>  
>   - compatible: Must be one or more of the following
> - "renesas,vin-r8a7795" for the R8A7795 device
> @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
>  Additionally, an alias named vinX will need to be created to specify
>  which video input device this is.
>  
> -The per-board settings:
> +The per-board settings Gen2:
>   - port sub-node describing a single endpoint connected to the vin
> as described in video-interfaces.txt[1]. Only the first one will
> be considered as each vin interface has one input port.
>  
> -   These settings are used to work out video input format and widths
> -   into the system.
> +The per-board settings Gen3:
> +
> +Gen3 can support both a single connected parallel input source from
> +external SoC pins (port0) and/or multiple parallel input sources from
> +local SoC CSI-2 receivers (port1) depending on SoC.
>  
> +- renesas,id - ID number of the VIN, VINx in the documentation.

Why is this needed? We try to avoid indexes unless that's the only way a 
device is addressed (and then we use reg).


Re: [PATCH v11 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

2017-11-15 Thread Rob Herring
On Sat, Nov 11, 2017 at 01:25:25AM +0100, Niklas Söderlund wrote:
> Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> are located between the video sources (CSI-2 transmitters) and the video
> grabbers (VIN) on Gen3 of Renesas R-Car SoC.
> 
> Each CSI-2 device is connected to more then one VIN device which
> simultaneously can receive video from the same CSI-2 device. Each VIN
> device can also be connected to more then one CSI-2 device. The routing
> of which link are used are controlled by the VIN devices. There are only
> a few possible routes which are set by hardware limitations, which are
> different for each SoC in the Gen3 family.
> 
> To work with the limitations of routing possibilities it is necessary
> for the DT bindings to describe which VIN device is connected to which
> CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> VIN device that be connected to it. To setup and to know which links are
> valid for each SoC is the responsibility of the VIN driver since the
> register to configure it belongs to the VIN hardware.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../bindings/media/renesas,rcar-csi2.txt   | 104 
> +
>  MAINTAINERS|   1 +
>  2 files changed, 105 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt 
> b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> new file mode 100644
> index ..24705d8997b14a10
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> @@ -0,0 +1,104 @@
> +Renesas R-Car MIPI CSI-2
> +
> +
> +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
> +family of devices. It is to be used in conjunction with the R-Car VIN module,
> +which provides the video capture capabilities.
> +
> +Mandatory properties
> +
> + - compatible: Must be one or more of the following
> +   - "renesas,r8a7795-csi2" for the R8A7795 device.
> +   - "renesas,r8a7796-csi2" for the R8A7796 device.
> +
> + - reg: the register base and size for the device registers
> + - interrupts: the interrupt for the device
> + - clocks: Reference to the parent clock
> +
> +The device node shall contain two 'port' child nodes according to the
> +bindings defined in Documentation/devicetree/bindings/media/
> +video-interfaces.txt. Port 0 shall connect the node that is the video
> +source for to the CSI-2. Port 1 shall connect all the R-Car VIN
> +modules, which can make use of the CSI-2 module.
> +
> +- Port 0 - Video source (Mandatory)
> + - Endpoint 0 - sub-node describing the endpoint that is the video source
> +
> +- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
> + - Endpoint 0 - sub-node describing the endpoint that is VIN0
> + - Endpoint 1 - sub-node describing the endpoint that is VIN1
> + - Endpoint 2 - sub-node describing the endpoint that is VIN2
> + - Endpoint 3 - sub-node describing the endpoint that is VIN3
> + - Endpoint 4 - sub-node describing the endpoint that is VIN4
> + - Endpoint 5 - sub-node describing the endpoint that is VIN5
> + - Endpoint 6 - sub-node describing the endpoint that is VIN6
> + - Endpoint 7 - sub-node describing the endpoint that is VIN7
> +
> +Example:
> +
> + csi20: csi2@fea8 {
> + compatible = "renesas,r8a7796-csi2", "renesas,rcar-gen3-csi2";
> + reg = <0 0xfea8 0 0x1>;
> + interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < CPG_MOD 714>;
> + power-domains = < R8A7796_PD_ALWAYS_ON>;
> + resets = < 714>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0>;
> +
> + csi20_in: endpoint@0 {

unit-address without reg property is not valid.

Otherwise,

Acked-by: Rob Herring 


> + clock-lanes = <0>;
> + data-lanes = <1>;
> + remote-endpoint = <_txb>;
> + };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <1>;
> +
> + csi20vin0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <>;
> + };
> +  

Re: [PATCH 3/3] arm64: dts: renesas: eagle: add EtherAVB pins

2017-11-15 Thread Sergei Shtylyov

Hello!

On 11/15/2017 07:21 PM, Geert Uytterhoeven wrote:


Add the (previously omitted) EtherAVB pin data to the Eagle board's
device tree.



--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -34,6 +34,9 @@


[...]


@@ -53,6 +56,11 @@
   };

{
+   avb_pins: avb {
+   groups = "avb0_mdio", "avb0_mii";



Oh no, its'called "avb0_mdio" here, but "avb(0)_mdc" on all other
R-Car Gen3 SoCs?



Can you remember the reason? I don;t want to follow the bad example. :-)


Sorry, I don't know.


   Hm, you seem to have participated in the related discussions for H2/M3-W...
The reason was that omlu AVB_MDC signal was multiplexed, AVB_MDIO signal (and 
AVB MII signals) was mapped to a dedicated pin without any multiplexing, so 
the "avb_mdc" group initially contained only AVB_MDC.



Gr{oetje,eeting}s,


MBR, Sergei


[PATCH] v4l: sh_mobile_ceu: Return buffers on streamoff()

2017-11-15 Thread Jacopo Mondi
videobuf2 core reports an error when not all buffers have been returned
to the framework:

drivers/media/v4l2-core/videobuf2-core.c:1651
WARN_ON(atomic_read(>owned_by_drv_count))

Fix this returning all buffers currently in capture queue.

Signed-off-by: Jacopo Mondi 

---

I know I'm working to get rid of this driver, but while I was trying to have
it working again on mainline, I found this had to be fixed.

Thanks
  j

---
 drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c 
b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index 36762ec..9180a1d 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -451,13 +451,18 @@ static void sh_mobile_ceu_stop_streaming(struct vb2_queue 
*q)
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct sh_mobile_ceu_dev *pcdev = ici->priv;
struct list_head *buf_head, *tmp;
+   struct vb2_v4l2_buffer *vbuf;

spin_lock_irq(>lock);

pcdev->active = NULL;

-   list_for_each_safe(buf_head, tmp, >capture)
+   list_for_each_safe(buf_head, tmp, >capture) {
+   vbuf = _entry(buf_head, struct sh_mobile_ceu_buffer,
+  queue)->vb;
+   vb2_buffer_done(>vb2_buf, VB2_BUF_STATE_DONE);
list_del_init(buf_head);
+   }

spin_unlock_irq(>lock);

--
2.7.4



Re: [PATCH 2/2] pinctrl: sh-pfc: add R8A77970 PFC support

2017-11-15 Thread Rob Herring
On Fri, Nov 10, 2017 at 08:59:01PM +0300, Sergei Shtylyov wrote:
> Add the PFC support for the R8A77970 SoC including pin groups for some
> on-chip devices such as CAN-FD, EtherAVB, [H]SCIF, I2C, INTC-EX, MMC,
> MSIOF, PWM, VIN...
> 
> Based on the original (and large) patch by Daisuke Matsushita
> .
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt |1 

Acked-by: Rob Herring 

>  drivers/pinctrl/sh-pfc/Kconfig|5 
>  drivers/pinctrl/sh-pfc/Makefile   |1 
>  drivers/pinctrl/sh-pfc/core.c |6 
>  drivers/pinctrl/sh-pfc/pfc-r8a77970.c | 2421 
> ++
>  drivers/pinctrl/sh-pfc/sh_pfc.h   |1 
>  6 files changed, 2435 insertions(+)


Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

2017-11-15 Thread Geert Uytterhoeven
Hi Jacopo,

On Wed, Nov 15, 2017 at 7:15 PM, jacopo mondi  wrote:
> On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
>>  wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
>> > @@ -0,0 +1,87 @@
>> > +Renesas Capture Engine Unit (CEU)
>> > +--
>> > +
>> > +The Capture Engine Unit is the image capture interface found on Renesas
>> > +RZ chip series and on SH Mobile ones.
>> > +
>> > +The interface supports a single parallel input with up 8/16bits data bus 
>> > width.
>>
>> ... with data bus widths up to 8/16 bits?
>>
>> > +
>> > +Required properties:
>> > +- compatible
>> > +   Must be "renesas,renesas-ceu".
>>
>> The double "renesas" part looks odd to me. What about "renesas,ceu"?
>
> I'm totally open for better "compatible" strings here, so yeah, let's
> got for the shorter one you proposed...
>
>> Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu",
>> too?
>
> Well, I actually have no SoC-specific data in the driver, so I don't
> need SoC specific "compatible" values. But if it's a good practice
> to have them anyway, I will add those in next spin..

You don't necessarily need them in the driver, but in the bindings and DTS,
just in case a difference is discovered later.

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 v1 01/10] dt-bindings: media: Add Renesas CEU bindings

2017-11-15 Thread jacopo mondi
Hi Geert,

On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> CC devicetree folks

Yeah, sorry I forgot them. Sorry about this and thanks for adding the
address back!

>
> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
>  wrote:
> > Add bindings documentation for Renesas Capture Engine Unit (CEU).
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> > ++
> >  1 file changed, 87 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> > b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > new file mode 100644
> > index 000..a88e9cb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > @@ -0,0 +1,87 @@
> > +Renesas Capture Engine Unit (CEU)
> > +--
> > +
> > +The Capture Engine Unit is the image capture interface found on Renesas
> > +RZ chip series and on SH Mobile ones.
> > +
> > +The interface supports a single parallel input with up 8/16bits data bus 
> > width.
>
> ... with data bus widths up to 8/16 bits?
>
> > +
> > +Required properties:
> > +- compatible
> > +   Must be "renesas,renesas-ceu".
>
> The double "renesas" part looks odd to me. What about "renesas,ceu"?

I'm totally open for better "compatible" strings here, so yeah, let's
got for the shorter one you proposed...

> Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu",
> too?

Well, I actually have no SoC-specific data in the driver, so I don't
need SoC specific "compatible" values. But if it's a good practice
to have them anyway, I will add those in next spin..
>
> > +- reg
> > +   Physical address base and size.
> > +- interrupts
> > +   The interrupt line number.
>
> interrupt specifier

Yeah, it's not just the line number...

>

[snip]

> > +i2c1: i2c@fcfee400 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins>;
> > +
> > +   status = "okay";
> > +   clock-frequency = <10>;
> > +
> > +   ov7670: camera@21 {
> > +   compatible = "ovti,ov7670";
> > +   reg = <0x21>;
> > +
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins>;
> > +
> > +   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> > +   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> > +
> > +   clocks = <>;
> > +   clock-names = "xclk";
> > +
> > +   xclk: fixed_clk {
> > +   compatible = "fixed-clock";
> > +   #clock-cells = <0>;
> > +   clock-frequency = <2400>;
> > +   };

As Sakari pointed out in his review, this fixed clock is a detail
specific to the sensor used in the example (ov7670). For sake of
simplicity I can remove it.

Thanks
  j


Re: [PATCH v11 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

2017-11-15 Thread Niklas Söderlund
Hi Rob,

Thanks for your feedback.

On 2017-11-15 13:59:36 -0600, Rob Herring wrote:
> On Sat, Nov 11, 2017 at 01:25:25AM +0100, Niklas Söderlund wrote:
> > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> > are located between the video sources (CSI-2 transmitters) and the video
> > grabbers (VIN) on Gen3 of Renesas R-Car SoC.
> > 
> > Each CSI-2 device is connected to more then one VIN device which
> > simultaneously can receive video from the same CSI-2 device. Each VIN
> > device can also be connected to more then one CSI-2 device. The routing
> > of which link are used are controlled by the VIN devices. There are only
> > a few possible routes which are set by hardware limitations, which are
> > different for each SoC in the Gen3 family.
> > 
> > To work with the limitations of routing possibilities it is necessary
> > for the DT bindings to describe which VIN device is connected to which
> > CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> > VIN device that be connected to it. To setup and to know which links are
> > valid for each SoC is the responsibility of the VIN driver since the
> > register to configure it belongs to the VIN hardware.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  .../bindings/media/renesas,rcar-csi2.txt   | 104 
> > +
> >  MAINTAINERS|   1 +
> >  2 files changed, 105 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt 
> > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > new file mode 100644
> > index ..24705d8997b14a10
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > @@ -0,0 +1,104 @@
> > +Renesas R-Car MIPI CSI-2
> > +
> > +
> > +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
> > +family of devices. It is to be used in conjunction with the R-Car VIN 
> > module,
> > +which provides the video capture capabilities.
> > +
> > +Mandatory properties
> > +
> > + - compatible: Must be one or more of the following
> > +   - "renesas,r8a7795-csi2" for the R8A7795 device.
> > +   - "renesas,r8a7796-csi2" for the R8A7796 device.
> > +
> > + - reg: the register base and size for the device registers
> > + - interrupts: the interrupt for the device
> > + - clocks: Reference to the parent clock
> > +
> > +The device node shall contain two 'port' child nodes according to the
> > +bindings defined in Documentation/devicetree/bindings/media/
> > +video-interfaces.txt. Port 0 shall connect the node that is the video
> > +source for to the CSI-2. Port 1 shall connect all the R-Car VIN
> > +modules, which can make use of the CSI-2 module.
> > +
> > +- Port 0 - Video source (Mandatory)
> > +   - Endpoint 0 - sub-node describing the endpoint that is the video source
> > +
> > +- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
> > +   - Endpoint 0 - sub-node describing the endpoint that is VIN0
> > +   - Endpoint 1 - sub-node describing the endpoint that is VIN1
> > +   - Endpoint 2 - sub-node describing the endpoint that is VIN2
> > +   - Endpoint 3 - sub-node describing the endpoint that is VIN3
> > +   - Endpoint 4 - sub-node describing the endpoint that is VIN4
> > +   - Endpoint 5 - sub-node describing the endpoint that is VIN5
> > +   - Endpoint 6 - sub-node describing the endpoint that is VIN6
> > +   - Endpoint 7 - sub-node describing the endpoint that is VIN7
> > +
> > +Example:
> > +
> > +   csi20: csi2@fea8 {
> > +   compatible = "renesas,r8a7796-csi2", "renesas,rcar-gen3-csi2";
> > +   reg = <0 0xfea8 0 0x1>;
> > +   interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> > +   clocks = < CPG_MOD 714>;
> > +   power-domains = < R8A7796_PD_ALWAYS_ON>;
> > +   resets = < 714>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   reg = <0>;
> > +
> > +   csi20_in: endpoint@0 {
> 
> unit-address without reg property is not valid.

Ops, my bad thanks for noticing.

> 
> Otherwise,
> 
> Acked-by: Rob Herring 

Thanks, will fix the above and re-send.

> 
> 
> > +   clock-lanes = <0>;
> > +   data-lanes = <1>;
> > +   remote-endpoint = <_txb>;
> > +   };
> > +   };
> > +
> > +   port@1 {
> > +   #address-cells = <1>;
> > + 

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

2017-11-15 Thread Niklas Söderlund
Hi Rob,

Thanks for your feedback, much appreciated!

On 2017-11-15 14:02:26 -0600, Rob Herring wrote:
> On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
> > Document the devicetree bindings for the CSI-2 inputs available on Gen3.
> > 
> > There is a need to add a custom property 'renesas,id' and to define
> > which CSI-2 input is described in which endpoint under the port@1 node.
> > This information is needed since there are a set of predefined routes
> > between each VIN and CSI-2 block. This routing table will be kept
> > inside the driver but in order for it to act on it it must know which
> > VIN and CSI-2 is which.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  .../devicetree/bindings/media/rcar_vin.txt | 116 
> > ++---
> >  1 file changed, 104 insertions(+), 12 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> > b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
> >  ---
> >  
> >  The rcar_vin device provides video input capabilities for the Renesas R-Car
> > -family of devices. The current blocks are always slaves and suppot one 
> > input
> > -channel which can be either RGB, YUYV or BT656.
> > +family of devices.
> > +
> > +Each VIN instance has a single parallel input that supports RGB and YUV 
> > video,
> > +with both external synchronization and BT.656 synchronization for the 
> > latter.
> > +Depending on the instance the VIN input is connected to external SoC pins, 
> > or
> > +on Gen3 to a CSI-2 receiver.
> >  
> >   - compatible: Must be one or more of the following
> > - "renesas,vin-r8a7795" for the R8A7795 device
> > @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
> >  Additionally, an alias named vinX will need to be created to specify
> >  which video input device this is.
> >  
> > -The per-board settings:
> > +The per-board settings Gen2:
> >   - port sub-node describing a single endpoint connected to the vin
> > as described in video-interfaces.txt[1]. Only the first one will
> > be considered as each vin interface has one input port.
> >  
> > -   These settings are used to work out video input format and widths
> > -   into the system.
> > +The per-board settings Gen3:
> > +
> > +Gen3 can support both a single connected parallel input source from
> > +external SoC pins (port0) and/or multiple parallel input sources from
> > +local SoC CSI-2 receivers (port1) depending on SoC.
> >  
> > +- renesas,id - ID number of the VIN, VINx in the documentation.
> 
> Why is this needed? We try to avoid indexes unless that's the only way a 
> device is addressed (and then we use reg).

This is unfortunately needed (or something similar) as there is a 
register in one VIN instance which controls the routing of the incoming 
CSI-2 video streams, not only to itself, but also to other VIN instances 
inside the same SoC.

To be more specific I will try to clarify this using the R-Car H3 as an 
example. On the H3 there are 8 instances of the capture hardware (VIN0 - 
VIN7) and 3 instances off CSI-2 receivers (CSI20, CSI40 and CSI41) which 
receives CSI-2 streams, split the possible multiple virtual channels 
(VC) encoded in CSI-2 streams and forwards it to the VIN's.

The problem is that VIN0 and VIN4 are different from the other VIN's, 
they have one register (CHSEL) which controls the limited number of 
possible routes of video streams between a CSI-2 + VC to a specific VIN.  
The CHSEL register in VIN0 controls the routing for VIN0-3 and the one 
in VIN4 controls VIN4-7 (the two subgroups are similar so lets only 
consider VIN0-3).

There are only a handful of routes possible and the kicker is that 
changing the CHSEL value in VIN0, directly reflects all routes for 
VIN0-VIN3 per this table:

CHSEL reg in VIN0:  0 1 2 3 4
Video sent to VIN0: CSI40/VC0 CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI20/VC0
Video sent to VIN1: CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI40/VC1 CSI20/VC1
Video sent to VIN2: CSI20/VC1 CSI40/VC0 CSI20/VC0 CSI40/VC2 CSI20/VC2
Video sent to VIN3: CSI40/VC1 CSI20/VC1 CSI20/VC1 CSI40/VC3 CSI20/VC3

So if CHSEL in VIN0 is set to 2 the following routes are active: VIN0: 
CSI40/VC1, VIN1: CSI40/VC0, VIN2: CSI20/VC0, CSI20/VC1. These routing 
tables are different for most SoCs in the R-Car Gen3 family, and are 
kept inside the driver code.

So the renesas,id properly is used so that the rcar-vin driver knows 
which of the driver instances corresponds to a specific VINx number from 
the documentation so that using the media device API the correct links 
can be added and that the routing table is enforced so a user can't try 
to 

[PATCH] v4l: rcar-vin: Implement V4L2 video node release handler

2017-11-15 Thread Laurent Pinchart
The rvin_dev data structure contains driver private data for an instance
of the VIN. It is allocated dynamically at probe time, and must be freed
once all users are gone.

The structure is currently allocated with devm_kzalloc(), which results
in memory being freed when the device is unbound. If a userspace
application is currently performing an ioctl call, or just keeps the
device node open and closes it later, this will lead to accessing freed
memory.

Fix the problem by implementing a V4L2 release handler for the video
node associated with the VIN instance (called when the last user of the
video node releases it), and freeing memory explicitly from the release
handler.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 29 +++--
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  9 -
 2 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 495610949457..bd7976efa1fb 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1208,7 +1208,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
struct resource *mem;
int irq, ret;
 
-   vin = devm_kzalloc(>dev, sizeof(*vin), GFP_KERNEL);
+   vin = kzalloc(sizeof(*vin), GFP_KERNEL);
if (!vin)
return -ENOMEM;
 
@@ -1224,20 +1224,26 @@ static int rcar_vin_probe(struct platform_device *pdev)
vin->info = attr->data;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (mem == NULL)
-   return -EINVAL;
+   if (mem == NULL) {
+   ret = -EINVAL;
+   goto error_free;
+   }
 
vin->base = devm_ioremap_resource(vin->dev, mem);
-   if (IS_ERR(vin->base))
-   return PTR_ERR(vin->base);
+   if (IS_ERR(vin->base)) {
+   ret = PTR_ERR(vin->base);
+   goto error_free;
+   }
 
irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
-   return irq;
+   if (irq < 0) {
+   ret = irq;
+   goto error_free;
+   }
 
ret = rvin_dma_probe(vin, irq);
if (ret)
-   return ret;
+   goto error_free;
 
platform_set_drvdata(pdev, vin);
if (vin->info->use_mc)
@@ -1245,15 +1251,18 @@ static int rcar_vin_probe(struct platform_device *pdev)
else
ret = rvin_digital_graph_init(vin);
if (ret < 0)
-   goto error;
+   goto error_dma;
 
pm_suspend_ignore_children(>dev, true);
pm_runtime_enable(>dev);
 
return 0;
-error:
+
+error_dma:
rvin_dma_remove(vin);
v4l2_async_notifier_cleanup(>notifier);
+error_free:
+   kfree(vin);
 
return ret;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 2c14d44950b2..25f1d24c1d2d 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -1026,6 +1026,13 @@ static void rvin_notify(struct v4l2_subdev *sd,
}
 }
 
+static void rvin_v4l2_release(struct video_device *vdev)
+{
+   struct rvin_dev *vin = container_of(vdev, struct rvin_dev, vdev);
+
+   kfree(vin);
+}
+
 int rvin_v4l2_register(struct rvin_dev *vin)
 {
struct video_device *vdev = >vdev;
@@ -1038,7 +1045,7 @@ int rvin_v4l2_register(struct rvin_dev *vin)
vdev->queue = >queue;
snprintf(vdev->name, sizeof(vdev->name), "%s %s", KBUILD_MODNAME,
 dev_name(vin->dev));
-   vdev->release = video_device_release_empty;
+   vdev->release = rvin_v4l2_release;
vdev->lock = >lock;
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
-- 
Regards,

Laurent Pinchart



[PATCH] v4l2-drm-example: Make the exporter selectable

2017-11-15 Thread Laurent Pinchart
The new -e command line option allows selecting the exporter between the
V4L2 and DRM side. DRM is used as the exporter by default.

Signed-off-by: Laurent Pinchart 
---
 v4l2-drm-example/dmabuf-sharing.c | 99 +++
 1 file changed, 89 insertions(+), 10 deletions(-)

This patch is against the master branch of
git://git.infradead.org/users/kmpark/public-apps and is available in my clone
tree at git://git.ideasonboard.org/samsung-public-apps.git.

Andrzej, if the patch is acceptable, could you merge it upstream ?

diff --git a/v4l2-drm-example/dmabuf-sharing.c 
b/v4l2-drm-example/dmabuf-sharing.c
index 5e1fb6a8f0c3..e2f1a4228af8 100644
--- a/v4l2-drm-example/dmabuf-sharing.c
+++ b/v4l2-drm-example/dmabuf-sharing.c
@@ -69,6 +69,11 @@ static inline int warn(const char *file, int line, const 
char *fmt, ...)
 #define WARN_ON(cond, ...) \
((cond) ? warn(__FILE__, __LINE__, __VA_ARGS__) : 0)
 
+enum dmabuf_exporter {
+   DMABUF_EXPORTER_DRM = 0,
+   DMABUF_EXPORTER_V4L2,
+};
+
 struct setup {
char module[32];
int conId;
@@ -85,6 +90,7 @@ struct setup {
unsigned int use_compose : 1;
struct v4l2_rect crop;
struct v4l2_rect compose;
+   enum dmabuf_exporter exporter;
 };
 
 struct drm_device {
@@ -105,10 +111,12 @@ struct drm_device {
unsigned int height;
 
struct v4l2_rect compose;
+   int export;
 };
 
 struct v4l2_device {
const char *devname;
+   enum v4l2_memory memory;
int fd;
 
struct v4l2_pix_format format;
@@ -149,6 +157,7 @@ static void usage(char *name)
 
fprintf(stderr, "\nGeneric options:\n\n");
fprintf(stderr, "\t-b buffer_count\tset number of buffers\n");
+   fprintf(stderr, "\t-e \tset the exporter ('v4l2' or 
'drm')\n");
fprintf(stderr, "\t-h\tshow this help\n");
 }
 
@@ -170,13 +179,21 @@ static int parse_args(int argc, char *argv[], struct 
setup *s)
 
strcpy(s->video, "/dev/video0");
 
-   while ((c = getopt(argc, argv, "b:F:f:hi:M:o:p:S:s:t:")) != -1) {
+   while ((c = getopt(argc, argv, "b:e:F:f:hi:M:o:p:S:s:t:")) != -1) {
switch (c) {
case 'b':
ret = sscanf(optarg, "%u", >buffer_count);
if (WARN_ON(ret != 1, "incorrect buffer count\n"))
return -1;
break;
+   case 'e':
+   if (strcmp(optarg, "v4l2") == 0)
+   s->exporter = DMABUF_EXPORTER_V4L2;
+   else if (strcmp(optarg, "drm") == 0)
+   s->exporter = DMABUF_EXPORTER_DRM;
+   else if (WARN_ON(1, ""))
+   return -1;
+   break;
case 'F':
if (WARN_ON(strlen(optarg) != 4, "invalid fourcc\n"))
return -1;
@@ -284,13 +301,49 @@ fail_prime:
 
 fail_gem:
memset(_destroy, 0, sizeof gem_destroy);
-   gem_destroy.handle = b->bo_handle,
+   gem_destroy.handle = b->bo_handle;
ret = ioctl(dev->fd, DRM_IOCTL_MODE_DESTROY_DUMB, _destroy);
WARN_ON(ret, "DESTROY_DUMB failed: %s\n", ERRSTR);
 
return -1;
 }
 
+static int drm_buffer_import(struct drm_device *dev, struct buffer *b,
+const struct v4l2_pix_format *fmt)
+{
+   struct drm_prime_handle prime;
+   struct drm_gem_close gem_close;
+   int ret;
+
+   memset(, 0, sizeof prime);
+   prime.fd = b->dbuf_fd;
+   ret = ioctl(dev->fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, );
+   if (WARN_ON(ret, "PRIME_FD_TO_HANDLE failed: %s\n", ERRSTR))
+   return -1;
+   b->bo_handle = prime.handle;
+
+   uint32_t offsets[4] = { 0 };
+   uint32_t pitches[4] = { fmt->bytesperline };
+   uint32_t bo_handles[4] = { b->bo_handle };
+   unsigned int fourcc = dev->format;
+   if (!fourcc)
+   fourcc = fmt->pixelformat;
+   ret = drmModeAddFB2(dev->fd, fmt->width, fmt->height, fourcc, 
bo_handles,
+   pitches, offsets, >fb_handle, 0);
+   if (WARN_ON(ret, "drmModeAddFB2 failed: %s\n", ERRSTR))
+   goto fail_gem;
+
+   return 0;
+
+fail_gem:
+   memset(_close, 0, sizeof gem_close);
+   gem_close.handle = b->bo_handle;
+   ret = ioctl(dev->fd, DRM_IOCTL_GEM_CLOSE, _close);
+   WARN_ON(ret, "GEM_CLOSE failed: %s\n", ERRSTR);
+
+   return -1;
+}
+
 static int drm_find_crtc(struct drm_device *dev)
 {
int ret = -1;
@@ -406,8 +459,13 @@ static void drm_init(struct drm_device *dev, const struct 
v4l2_pix_format *fmt,
 
/* TODO: add support for multiplanar formats */
for (unsigned int i = 0; i < num_buffers; ++i) {
-   ret = drm_buffer_create(dev, [i], fmt);
-   BYE_ON(ret, "failed to create buffer%d\n", i);
+ 

[PATCH/RFC 0/2] V4L2: Handle the race condition between device access and unbind

2017-11-15 Thread Laurent Pinchart
Hello,

This small RFC is an attempt to handle the race condition that exists between
device access and device unbind.

Devices can be unbound from drivers in three different ways:

- When the driver module is unloaded, the driver is unregistered and unbound
  from all devices it was bound to. As module unloading can't happen as long
  as the module reference count is not zero, no concurrent access to the
  device from userspace access can be ongoing. This patch series isn't needed
  to address this case.

- When the device is removed either physically (for instance with USB or
  hotpluggable PCI) or logically (for instance by unloading a DT overlay), the
  device is unbound from its driver.

- When userspace initiates a manual unbind through the driver sysfs unbind
  file the device is also unbound from its driver.

The last two cases can occur at any time and are not synchronized with device
access from userspace through video device nodes. This is the race that the
patch series tries to address.

Drivers need to ensure that no access to internal resources can occur before
freeing those resources in the unbind handler. To do so, we need to both block
all new accesses to device resources, and wait for all ongoing accesses to
complete before freeing resources.

This series achieves this by marking code sections that access device
resources with the new video_device_enter() and video_device_exit() functions.
The function internally keep a count of the number of such sections currently
being executed in order to delay device unbind. Driver must call the
video_device_unplug() function in their unbind handler before cleaning up any
resource that can be accessed through the function marked with enter/exit. The
video_device_unplug() function marks the device is being unbound, preventing
subsequent calls to video_device_enter() from succeeding, and then waits for
all device access code sections to be exited before returning.

Several issues haven't been addressed yet, hence the RFC status of the series:

- Only the video_device ioctl handler is currently protected by
  video_device_enter() and video_device_exit(). This needs to be extended to
  other file operations.

- Blocking operations (such a VIDIOC_DQBUF for instance) need to be unblocked
  at unbind time. Whether this can be handled entirely inside
  video_device_unplug() needs to be researched.

- While the above mechanism should be usable for subdevs too as the
  v4l2_subdev structure contains a video_device structure, the subdev
  .release() file operation handler subdev_close() accesses the v4l2_subdev
  structure, which is currently freed by drivers at unbind time due to the
  lack of a structure release operation in the v4l2_subdev structure. Fixing
  this will likely require major refactoring of the subdev registration API,
  which might not be considered worth it as the long term goal is to replace
  subdev device nodes with the request API anyway.

I would like to receive feedback on this initial version, and will then work
on a second version that addresses at least the first two problems listed
above.

Laurent Pinchart (2):
  v4l: v4l2-dev: Add infrastructure to protect device unplug race
  v4l: rcar-vin: Wait for device access to complete before unplugging

 drivers/media/platform/rcar-vin/rcar-core.c |  1 +
 drivers/media/v4l2-core/v4l2-dev.c  | 57 +
 include/media/v4l2-dev.h| 47 
 3 files changed, 105 insertions(+)

-- 
Regards,

Laurent Pinchart



[PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

2017-11-15 Thread Laurent Pinchart
Device unplug being asynchronous, it naturally races with operations
performed by userspace through ioctls or other file operations on video
device nodes.

This leads to potential access to freed memory or to other resources
during device access if unplug occurs during device access. To solve
this, we need to wait until all device access completes when unplugging
the device, and block all further access when the device is being
unplugged.

Three new functions are introduced. The video_device_enter() and
video_device_exit() functions must be used to mark entry and exit from
all code sections where the device can be accessed. The
video_device_unplug() function is then used in the unplug handler to
mark the device as being unplugged and wait for all access to complete.

As an example mark the ioctl handler as a device access section. Other
file operations need to be protected too, and blocking ioctls (such as
VIDIOC_DQBUF) need to be handled as well.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/v4l2-core/v4l2-dev.c | 57 ++
 include/media/v4l2-dev.h   | 47 +++
 2 files changed, 104 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index c647ba648805..c73c6d49e7cf 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device *vdev)
 }
 EXPORT_SYMBOL(video_device_release_empty);
 
+int video_device_enter(struct video_device *vdev)
+{
+   bool unplugged;
+
+   spin_lock(>unplug_lock);
+   unplugged = vdev->unplugged;
+   if (!unplugged)
+   vdev->access_refcount++;
+   spin_unlock(>unplug_lock);
+
+   return unplugged ? -ENODEV : 0;
+}
+EXPORT_SYMBOL_GPL(video_device_enter);
+
+void video_device_exit(struct video_device *vdev)
+{
+   bool wake_up;
+
+   spin_lock(>unplug_lock);
+   WARN_ON(--vdev->access_refcount < 0);
+   wake_up = vdev->access_refcount == 0;
+   spin_unlock(>unplug_lock);
+
+   if (wake_up)
+   wake_up(>unplug_wait);
+}
+EXPORT_SYMBOL_GPL(video_device_exit);
+
+void video_device_unplug(struct video_device *vdev)
+{
+   bool unplug_blocked;
+
+   spin_lock(>unplug_lock);
+   unplug_blocked = vdev->access_refcount > 0;
+   vdev->unplugged = true;
+   spin_unlock(>unplug_lock);
+
+   if (!unplug_blocked)
+   return;
+
+   if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
+   msecs_to_jiffies(15)))
+   WARN(1, "Timeout waiting for device access to complete\n");
+}
+EXPORT_SYMBOL_GPL(video_device_unplug);
+
 static inline void video_get(struct video_device *vdev)
 {
get_device(>dev);
@@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
struct video_device *vdev = video_devdata(filp);
int ret = -ENODEV;
 
+   ret = video_device_enter(vdev);
+   if (ret < 0)
+   return ret;
+
if (vdev->fops->unlocked_ioctl) {
struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
 
@@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
return -ERESTARTSYS;
if (video_is_registered(vdev))
ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
+   else
+   ret = -ENODEV;
if (lock)
mutex_unlock(lock);
} else
ret = -ENOTTY;
 
+   video_device_exit(vdev);
return ret;
 }
 
@@ -841,6 +894,10 @@ int __video_register_device(struct video_device *vdev, int 
type, int nr,
if (WARN_ON(!vdev->v4l2_dev))
return -EINVAL;
 
+   /* unplug support */
+   spin_lock_init(>unplug_lock);
+   init_waitqueue_head(>unplug_wait);
+
/* v4l2_fh support */
spin_lock_init(>fh_lock);
INIT_LIST_HEAD(>fh_list);
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index e657614521e3..365a94f91dc9 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -178,6 +179,12 @@ struct v4l2_file_operations {
  * @pipe:  media_pipeline
  * @fops: pointer to  v4l2_file_operations for the video device
  * @device_caps: device capabilities as used in v4l2_capabilities
+ * @unplugged: when set the device has been unplugged and no device access
+ * section can be entered
+ * @access_refcount: number of device access section currently running for the
+ * device
+ * @unplug_lock: protects unplugged and access_refcount
+ * @unplug_wait: wait queue to wait for device access sections to complete
  * @dev:  device for the video device
  * 

[PATCH/RFC 2/2] v4l: rcar-vin: Wait for device access to complete before unplugging

2017-11-15 Thread Laurent Pinchart
To avoid races between device access and unplug, call the
video_device_unplug() function in the platform driver remove handler.
This will unsure that all device access completes before the remove
handler proceeds to free resources.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index bd7976efa1fb..c5210f1d09ed 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1273,6 +1273,7 @@ static int rcar_vin_remove(struct platform_device *pdev)
 
pm_runtime_disable(>dev);
 
+   video_device_unplug(>vdev);
 
if (!vin->info->use_mc) {
v4l2_async_notifier_unregister(>notifier);
-- 
Regards,

Laurent Pinchart



[PATCH] pinctrl: sh-pfc: r8a7796: Fix to delete A20..A25 pins function definitions

2017-11-15 Thread Yoshihiro Kaneko
From: Takeshi Kihara 

This patch fixes the macro definitions of A20..A25 pins function deleted.

This is a correction because IPSR register specification for R8A7796 SoC
was changed in R-Car Gen3 Hardware User's Manual Rev.0.53E.

Fixes: f9aece7344bd ("pinctrl: sh-pfc: Initial R8A7796 PFC support")
Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Kaneko 
---

This patch is based on the for-next branch of linux-pinctrl tree.

 drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
index 73ed9c7..954daae 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
@@ -224,12 +224,12 @@
 #define IP0_27_24  FM(IRQ0)FM(QPOLB)   F_(0, 0)
FM(DU_CDE)  FM(VI4_DATA0_B) FM(CAN0_TX_B)   
FM(CANFD0_TX_B) FM(MSIOF3_SS2_E) F_(0, 0)   F_(0, 0)
F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
 #define IP0_31_28  FM(IRQ1)FM(QPOLA)   F_(0, 0)
FM(DU_DISP) FM(VI4_DATA1_B) FM(CAN0_RX_B)   
FM(CANFD0_RX_B) FM(MSIOF3_SS1_E) F_(0, 0)   F_(0, 0)
F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
 #define IP1_3_0FM(IRQ2)FM(QCPV_QDE)F_(0, 
0)FM(DU_EXODDF_DU_ODDF_DISP_CDE)  FM(VI4_DATA2_B) F_(0, 0)  
  F_(0, 0)FM(MSIOF3_SYNC_E) F_(0, 0)  FM(PWM3_B)
  F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_7_4FM(IRQ3)FM(QSTVB_QVE)   FM(A25) 
FM(DU_DOTCLKOUT1)   FM(VI4_DATA3_B) F_(0, 0)
F_(0, 0)FM(MSIOF3_SCK_E) F_(0, 0)   FM(PWM4_B)  
F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_11_8   FM(IRQ4)FM(QSTH_QHS)FM(A24) 
FM(DU_EXHSYNC_DU_HSYNC) FM(VI4_DATA4_B) F_(0, 0)F_(0, 
0)FM(MSIOF3_RXD_E) F_(0, 0)   FM(PWM5_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_15_12  FM(IRQ5)FM(QSTB_QHE)FM(A23) 
FM(DU_EXVSYNC_DU_VSYNC) FM(VI4_DATA5_B) F_(0, 0)F_(0, 
0)FM(MSIOF3_TXD_E) F_(0, 0)   FM(PWM6_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_19_16  FM(PWM0)FM(AVB_AVTP_PPS)FM(A22) 
F_(0, 0)FM(VI4_DATA6_B) F_(0, 0)F_(0, 
0)F_(0, 0)F_(0, 0)FM(IECLK_B) F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_23_20  FM(PWM1_A)  F_(0, 0)FM(A21) 
FM(HRX3_D)  FM(VI4_DATA7_B) F_(0, 0)F_(0, 
0)F_(0, 0)F_(0, 0)FM(IERX_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_27_24  FM(PWM2_A)  F_(0, 0)FM(A20) 
FM(HTX3_D)  F_(0, 0)F_(0, 0)F_(0, 
0)F_(0, 0)F_(0, 0)FM(IETX_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_7_4FM(IRQ3)FM(QSTVB_QVE)   F_(0, 
0)FM(DU_DOTCLKOUT1)   FM(VI4_DATA3_B) F_(0, 0)  
  F_(0, 0)FM(MSIOF3_SCK_E) F_(0, 0)   FM(PWM4_B)
  F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_11_8   FM(IRQ4)FM(QSTH_QHS)F_(0, 0)
FM(DU_EXHSYNC_DU_HSYNC) FM(VI4_DATA4_B) F_(0, 0)F_(0, 
0)FM(MSIOF3_RXD_E) F_(0, 0)   FM(PWM5_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_15_12  FM(IRQ5)FM(QSTB_QHE)F_(0, 0)
FM(DU_EXVSYNC_DU_VSYNC) FM(VI4_DATA5_B) F_(0, 0)F_(0, 
0)FM(MSIOF3_TXD_E) F_(0, 0)   FM(PWM6_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_19_16  FM(PWM0)FM(AVB_AVTP_PPS)F_(0, 0)
F_(0, 0)FM(VI4_DATA6_B) F_(0, 0)F_(0, 
0)F_(0, 0)F_(0, 0)FM(IECLK_B) F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_23_20  FM(PWM1_A)  F_(0, 0)F_(0, 0)
FM(HRX3_D)  FM(VI4_DATA7_B) F_(0, 0)F_(0, 
0)   

Re: [PATCH] v4l: rcar-vin: Implement V4L2 video node release handler

2017-11-15 Thread Niklas Söderlund
Hi Laurent,

Thanks for your patch.

On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote:
> The rvin_dev data structure contains driver private data for an instance
> of the VIN. It is allocated dynamically at probe time, and must be freed
> once all users are gone.
> 
> The structure is currently allocated with devm_kzalloc(), which results
> in memory being freed when the device is unbound. If a userspace
> application is currently performing an ioctl call, or just keeps the
> device node open and closes it later, this will lead to accessing freed
> memory.
> 
> Fix the problem by implementing a V4L2 release handler for the video
> node associated with the VIN instance (called when the last user of the
> video node releases it), and freeing memory explicitly from the release
> handler.
> 
> Signed-off-by: Laurent Pinchart 

Acked-by: Niklas Söderlund 

This patch is based on-top of the VIN Gen3 enablement series not yet 
upstream. This is OK for me, just wanted to check that this was the 
intention as to minimize conflicts between the two.

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 29 
> +++--
>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  9 -
>  2 files changed, 27 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 495610949457..bd7976efa1fb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1208,7 +1208,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
>   struct resource *mem;
>   int irq, ret;
>  
> - vin = devm_kzalloc(>dev, sizeof(*vin), GFP_KERNEL);
> + vin = kzalloc(sizeof(*vin), GFP_KERNEL);
>   if (!vin)
>   return -ENOMEM;
>  
> @@ -1224,20 +1224,26 @@ static int rcar_vin_probe(struct platform_device 
> *pdev)
>   vin->info = attr->data;
>  
>   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (mem == NULL)
> - return -EINVAL;
> + if (mem == NULL) {
> + ret = -EINVAL;
> + goto error_free;
> + }
>  
>   vin->base = devm_ioremap_resource(vin->dev, mem);
> - if (IS_ERR(vin->base))
> - return PTR_ERR(vin->base);
> + if (IS_ERR(vin->base)) {
> + ret = PTR_ERR(vin->base);
> + goto error_free;
> + }
>  
>   irq = platform_get_irq(pdev, 0);
> - if (irq < 0)
> - return irq;
> + if (irq < 0) {
> + ret = irq;
> + goto error_free;
> + }
>  
>   ret = rvin_dma_probe(vin, irq);
>   if (ret)
> - return ret;
> + goto error_free;
>  
>   platform_set_drvdata(pdev, vin);
>   if (vin->info->use_mc)
> @@ -1245,15 +1251,18 @@ static int rcar_vin_probe(struct platform_device 
> *pdev)
>   else
>   ret = rvin_digital_graph_init(vin);
>   if (ret < 0)
> - goto error;
> + goto error_dma;
>  
>   pm_suspend_ignore_children(>dev, true);
>   pm_runtime_enable(>dev);
>  
>   return 0;
> -error:
> +
> +error_dma:
>   rvin_dma_remove(vin);
>   v4l2_async_notifier_cleanup(>notifier);
> +error_free:
> + kfree(vin);
>  
>   return ret;
>  }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 2c14d44950b2..25f1d24c1d2d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -1026,6 +1026,13 @@ static void rvin_notify(struct v4l2_subdev *sd,
>   }
>  }
>  
> +static void rvin_v4l2_release(struct video_device *vdev)
> +{
> + struct rvin_dev *vin = container_of(vdev, struct rvin_dev, vdev);
> +
> + kfree(vin);
> +}
> +
>  int rvin_v4l2_register(struct rvin_dev *vin)
>  {
>   struct video_device *vdev = >vdev;
> @@ -1038,7 +1045,7 @@ int rvin_v4l2_register(struct rvin_dev *vin)
>   vdev->queue = >queue;
>   snprintf(vdev->name, sizeof(vdev->name), "%s %s", KBUILD_MODNAME,
>dev_name(vin->dev));
> - vdev->release = video_device_release_empty;
> + vdev->release = rvin_v4l2_release;
>   vdev->lock = >lock;
>   vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
>   V4L2_CAP_READWRITE;
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund


[PATCH] pinctrl: sh-pfc: r8a7795: Fix to delete A20..A25 pins function definitions

2017-11-15 Thread Yoshihiro Kaneko
From: Takeshi Kihara 

This patch fixes the macro definitions of A20..A25 pins function deleted.

This is a correction because IPSR register specification for R8A7795 ES2.0
SoC was changed in R-Car Gen3 Hardware User's Manual Rev.0.53E.

Fixes: b205914c8f82 ("pinctrl: sh-pfc: r8a7795: Add support for R-Car H3 ES2.0")
Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Kaneko 
---

This patch is based on the for-next branch of linux-pinctrl tree.

 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 85699fb..b513010 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -219,12 +219,12 @@
 #define IP0_27_24  FM(IRQ0)FM(QPOLB)   F_(0, 0)
FM(DU_CDE)  FM(VI4_DATA0_B) FM(CAN0_TX_B)   
FM(CANFD0_TX_B) FM(MSIOF3_SS2_E) F_(0, 0)   F_(0, 0)
F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
 #define IP0_31_28  FM(IRQ1)FM(QPOLA)   F_(0, 0)
FM(DU_DISP) FM(VI4_DATA1_B) FM(CAN0_RX_B)   
FM(CANFD0_RX_B) FM(MSIOF3_SS1_E) F_(0, 0)   F_(0, 0)
F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
 #define IP1_3_0FM(IRQ2)FM(QCPV_QDE)F_(0, 
0)FM(DU_EXODDF_DU_ODDF_DISP_CDE)  FM(VI4_DATA2_B) F_(0, 0)  
  F_(0, 0)FM(MSIOF3_SYNC_E) F_(0, 0)  FM(PWM3_B)
  F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_7_4FM(IRQ3)FM(QSTVB_QVE)   FM(A25) 
FM(DU_DOTCLKOUT1)   FM(VI4_DATA3_B) F_(0, 0)
F_(0, 0)FM(MSIOF3_SCK_E) F_(0, 0)   FM(PWM4_B)  
F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_11_8   FM(IRQ4)FM(QSTH_QHS)FM(A24) 
FM(DU_EXHSYNC_DU_HSYNC) FM(VI4_DATA4_B) F_(0, 0)F_(0, 
0)FM(MSIOF3_RXD_E) F_(0, 0)   FM(PWM5_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_15_12  FM(IRQ5)FM(QSTB_QHE)FM(A23) 
FM(DU_EXVSYNC_DU_VSYNC) FM(VI4_DATA5_B) FM(FSCLKST2_N_B) F_(0, 
0)   FM(MSIOF3_TXD_E) F_(0, 0)   FM(PWM6_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_19_16  FM(PWM0)FM(AVB_AVTP_PPS)FM(A22) 
F_(0, 0)FM(VI4_DATA6_B) F_(0, 0)F_(0, 
0)F_(0, 0)F_(0, 0)FM(IECLK_B) F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_23_20  FM(PWM1_A)  F_(0, 0)FM(A21) 
FM(HRX3_D)  FM(VI4_DATA7_B) F_(0, 0)F_(0, 
0)F_(0, 0)F_(0, 0)FM(IERX_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP1_27_24  FM(PWM2_A)  F_(0, 0)FM(A20) 
FM(HTX3_D)  F_(0, 0)F_(0, 0)F_(0, 
0)F_(0, 0)F_(0, 0)FM(IETX_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_7_4FM(IRQ3)FM(QSTVB_QVE)   F_(0, 
0)FM(DU_DOTCLKOUT1)   FM(VI4_DATA3_B) F_(0, 0)  
  F_(0, 0)FM(MSIOF3_SCK_E) F_(0, 0)   FM(PWM4_B)
  F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_11_8   FM(IRQ4)FM(QSTH_QHS)F_(0, 0)
FM(DU_EXHSYNC_DU_HSYNC) FM(VI4_DATA4_B) F_(0, 0)F_(0, 
0)FM(MSIOF3_RXD_E) F_(0, 0)   FM(PWM5_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_15_12  FM(IRQ5)FM(QSTB_QHE)F_(0, 0)
FM(DU_EXVSYNC_DU_VSYNC) FM(VI4_DATA5_B) FM(FSCLKST2_N_B) F_(0, 
0)   FM(MSIOF3_TXD_E) F_(0, 0)   FM(PWM6_B)  F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_19_16  FM(PWM0)FM(AVB_AVTP_PPS)F_(0, 0)
F_(0, 0)FM(VI4_DATA6_B) F_(0, 0)F_(0, 
0)F_(0, 0)F_(0, 0)FM(IECLK_B) F_(0, 
0)F_(0, 0)F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP1_23_20  FM(PWM1_A)  F_(0, 0)F_(0, 0)
FM(HRX3_D)  FM(VI4_DATA7_B) F_(0, 0)

[PATCH] pinctrl: sh-pfc: r8a7795: Add GP-1-28 port pin support

2017-11-15 Thread Yoshihiro Kaneko
From: Takeshi Kihara 

This patch supports GP-1-28 port pin of R8A7795 ES2.0 SoC added in
Rev.0.54E of the R-Car Gen3 Hardware User's Manual or later version.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Kaneko 
---

This patch is based on the for-next branch of linux-pinctrl tree.

 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index d1cec6d..85699fb 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -20,7 +20,7 @@
 
 #define CPU_ALL_PORT(fn, sfx)  \
PORT_GP_CFG_16(0, fn, sfx, CFG_FLAGS),  \
-   PORT_GP_CFG_28(1, fn, sfx, CFG_FLAGS),  \
+   PORT_GP_CFG_29(1, fn, sfx, CFG_FLAGS),  \
PORT_GP_CFG_15(2, fn, sfx, CFG_FLAGS),  \
PORT_GP_CFG_12(3, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE),  
\
PORT_GP_CFG_1(3, 12, fn, sfx, CFG_FLAGS),   \
@@ -55,6 +55,7 @@
 #define GPSR0_0F_(D0,  IP5_15_12)
 
 /* GPSR1 */
+#define GPSR1_28   FM(CLKOUT)
 #define GPSR1_27   F_(EX_WAIT0_A,  IP5_11_8)
 #define GPSR1_26   F_(WE1_N,   IP5_7_4)
 #define GPSR1_25   F_(WE0_N,   IP5_3_0)
@@ -368,7 +369,7 @@

GPSR6_31 \

GPSR6_30 \

GPSR6_29 \
-   
GPSR6_28 \
+   GPSR1_28
GPSR6_28 \
GPSR1_27
GPSR6_27 \
GPSR1_26
GPSR6_26 \
GPSR1_25
GPSR5_25GPSR6_25 \
@@ -548,7 +549,7 @@
FM(AVB_TX_CTL) FM(AVB_TXC) FM(AVB_TD0) FM(AVB_TD1) FM(AVB_TD2) 
FM(AVB_TD3) \
FM(AVB_RX_CTL) FM(AVB_RXC) FM(AVB_RD0) FM(AVB_RD1) FM(AVB_RD2) 
FM(AVB_RD3) \
FM(AVB_TXCREFCLK) FM(AVB_MDIO) \
-   FM(CLKOUT) FM(PRESETOUT) \
+   FM(PRESETOUT) \
FM(DU_DOTCLKIN0) FM(DU_DOTCLKIN1) FM(DU_DOTCLKIN2) FM(DU_DOTCLKIN3) \
FM(TMS) FM(TDO) FM(ASEBRK) FM(MLB_REF) FM(TDI) FM(TCK) FM(TRST) 
FM(EXTALR)
 
@@ -587,6 +588,7 @@ enum {
 
PINMUX_SINGLE(AVS1),
PINMUX_SINGLE(AVS2),
+   PINMUX_SINGLE(CLKOUT),
PINMUX_SINGLE(HDMI0_CEC),
PINMUX_SINGLE(HDMI1_CEC),
PINMUX_SINGLE(I2C_SEL_0_1),
@@ -4644,7 +4646,7 @@ enum {
0, 0,
0, 0,
0, 0,
-   0, 0,
+   GP_1_28_FN, GPSR1_28,
GP_1_27_FN, GPSR1_27,
GP_1_26_FN, GPSR1_26,
GP_1_25_FN, GPSR1_25,
@@ -5246,7 +5248,7 @@ enum {
{ RCAR_GP_PIN(1, 19),  0, 3 },  /* A19 */
} },
{ PINMUX_DRIVE_REG("DRVCTRL8", 0xe6060320) {
-   { PIN_NUMBER('F', 1), 28, 3 },  /* CLKOUT */
+   { RCAR_GP_PIN(1, 28), 28, 3 },  /* CLKOUT */
{ RCAR_GP_PIN(1, 20), 24, 3 },  /* CS0 */
{ RCAR_GP_PIN(1, 21), 20, 3 },  /* CS1_A26 */
{ RCAR_GP_PIN(1, 22), 16, 3 },  /* BS */
-- 
1.9.1



[PATCH] pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using STP_ISEN_1_D

2017-11-15 Thread Yoshihiro Kaneko
From: Takeshi Kihara 

This patch fixes the implementation incorrect of MOD_SEL1 bit[25:24]
value when STP_ISEN_1_D pin function is selected for IPSR16 bit[27:24].

This is a correction to the incorrect implementation of MOD_SEL register
pin assignment for R8A7795 SoC specification of R-Car Gen3 Hardware
User's Manual Rev.0.51E or later.

Fixes: 0b0ffc96dbe3 ("pinctrl: sh-pfc: Initial R8A7795 PFC support)
Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Kaneko 
---

This patch is based on the for-next branch of linux-pinctrl tree.

 drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c
index 1d4d84f..292e35d 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c
@@ -1397,7 +1397,7 @@ enum {
PINMUX_IPSR_MSEL(IP16_27_24,AUDIO_CLKOUT_B, SEL_ADG_1),
PINMUX_IPSR_MSEL(IP16_27_24,SSI_SCK2_B, SEL_SSI_1),
PINMUX_IPSR_MSEL(IP16_27_24,TS_SDEN1_D, SEL_TSIF1_3),
-   PINMUX_IPSR_MSEL(IP16_27_24,STP_ISEN_1_D,   SEL_SSP1_1_2),
+   PINMUX_IPSR_MSEL(IP16_27_24,STP_ISEN_1_D,   SEL_SSP1_1_3),
PINMUX_IPSR_MSEL(IP16_27_24,STP_OPWM_0_E,   SEL_SSP1_0_4),
PINMUX_IPSR_MSEL(IP16_27_24,RIF3_D0_B,  SEL_DRIF3_1),
PINMUX_IPSR_MSEL(IP16_27_24,TCLK2_B,
SEL_TIMER_TMU_1),
-- 
1.9.1



Re: [PATCH RFT] mmc: core: use usleep_range rather than HZ magic in mmc_delay()

2017-11-15 Thread Ulf Hansson
On 14 November 2017 at 23:55, Wolfram Sang
 wrote:
> Documentation/timers/timers-howto.txt recommends to use usleep_range for
> delays 1-20ms. Let's adhere to it. No need for messing with HZ and still
> do busy looping these days.
>
> Signed-off-by: Wolfram Sang 
> ---
>
> Here is a more detailed test page for this describing my tests:
>
> https://elinux.org/Tests:mmc-delay-refactor
>
> I did mainly test the insert/eject cycle because powering up the cards
> seemed to trigger most delays. Transferring data did not cause any calls
> to mmc_delay() for me. Please let me know if someone knows a test pattern
> which should be included before applying this change.
>
> Works fine for me on Lager (R-Car H2) and Salvator-X (R-Car M3-W). Testing on
> other platforms very welcome. This should be independent of the IP core.
>
>  drivers/mmc/core/core.h | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
> index 71e6c6d7ceb70d..b2877e2d740fa5 100644
> --- a/drivers/mmc/core/core.h
> +++ b/drivers/mmc/core/core.h
> @@ -62,12 +62,10 @@ void mmc_set_initial_state(struct mmc_host *host);
>
>  static inline void mmc_delay(unsigned int ms)
>  {
> -   if (ms < 1000 / HZ) {
> -   cond_resched();
> -   mdelay(ms);
> -   } else {
> +   if (ms <= 20)
> +   usleep_range(ms * 1000, ms * 1250);

This means we get usleep_range(2, 25000) for the worst case.

Perhaps we want "ms <= 16" instead, thus getting usleep
usleep_range(16000, 2) for the worst case? No?

> +   else
> msleep(ms);
> -   }
>  }

Kind regards
Uffe


Re: [PATCH] v4l2-drm-example: Make the exporter selectable

2017-11-15 Thread Andrzej Hajda
Hi Laurent,

On 15.11.2017 10:00, Laurent Pinchart wrote:
> The new -e command line option allows selecting the exporter between the
> V4L2 and DRM side. DRM is used as the exporter by default.
>
> Signed-off-by: Laurent Pinchart 
> ---
>  v4l2-drm-example/dmabuf-sharing.c | 99 
> +++
>  1 file changed, 89 insertions(+), 10 deletions(-)
>
> This patch is against the master branch of
> git://git.infradead.org/users/kmpark/public-apps and is available in my clone
> tree at git://git.ideasonboard.org/samsung-public-apps.git.
>
> Andrzej, if the patch is acceptable, could you merge it upstream ?

Sylwester merged it to devel branch of
https://git.linuxtv.org/snawrocki/samsung-utils.git

The branch git://git.infradead.org/users/kmpark/public-apps is obsolete
and beyond our control.


Regards
Andrzej

>
> diff --git a/v4l2-drm-example/dmabuf-sharing.c 
> b/v4l2-drm-example/dmabuf-sharing.c
> index 5e1fb6a8f0c3..e2f1a4228af8 100644
> --- a/v4l2-drm-example/dmabuf-sharing.c
> +++ b/v4l2-drm-example/dmabuf-sharing.c
> @@ -69,6 +69,11 @@ static inline int warn(const char *file, int line, const 
> char *fmt, ...)
>  #define WARN_ON(cond, ...) \
>   ((cond) ? warn(__FILE__, __LINE__, __VA_ARGS__) : 0)
>  
> +enum dmabuf_exporter {
> + DMABUF_EXPORTER_DRM = 0,
> + DMABUF_EXPORTER_V4L2,
> +};
> +
>  struct setup {
>   char module[32];
>   int conId;
> @@ -85,6 +90,7 @@ struct setup {
>   unsigned int use_compose : 1;
>   struct v4l2_rect crop;
>   struct v4l2_rect compose;
> + enum dmabuf_exporter exporter;
>  };
>  
>  struct drm_device {
> @@ -105,10 +111,12 @@ struct drm_device {
>   unsigned int height;
>  
>   struct v4l2_rect compose;
> + int export;
>  };
>  
>  struct v4l2_device {
>   const char *devname;
> + enum v4l2_memory memory;
>   int fd;
>  
>   struct v4l2_pix_format format;
> @@ -149,6 +157,7 @@ static void usage(char *name)
>  
>   fprintf(stderr, "\nGeneric options:\n\n");
>   fprintf(stderr, "\t-b buffer_count\tset number of buffers\n");
> + fprintf(stderr, "\t-e \tset the exporter ('v4l2' or 
> 'drm')\n");
>   fprintf(stderr, "\t-h\tshow this help\n");
>  }
>  
> @@ -170,13 +179,21 @@ static int parse_args(int argc, char *argv[], struct 
> setup *s)
>  
>   strcpy(s->video, "/dev/video0");
>  
> - while ((c = getopt(argc, argv, "b:F:f:hi:M:o:p:S:s:t:")) != -1) {
> + while ((c = getopt(argc, argv, "b:e:F:f:hi:M:o:p:S:s:t:")) != -1) {
>   switch (c) {
>   case 'b':
>   ret = sscanf(optarg, "%u", >buffer_count);
>   if (WARN_ON(ret != 1, "incorrect buffer count\n"))
>   return -1;
>   break;
> + case 'e':
> + if (strcmp(optarg, "v4l2") == 0)
> + s->exporter = DMABUF_EXPORTER_V4L2;
> + else if (strcmp(optarg, "drm") == 0)
> + s->exporter = DMABUF_EXPORTER_DRM;
> + else if (WARN_ON(1, ""))
> + return -1;
> + break;
>   case 'F':
>   if (WARN_ON(strlen(optarg) != 4, "invalid fourcc\n"))
>   return -1;
> @@ -284,13 +301,49 @@ fail_prime:
>  
>  fail_gem:
>   memset(_destroy, 0, sizeof gem_destroy);
> - gem_destroy.handle = b->bo_handle,
> + gem_destroy.handle = b->bo_handle;
>   ret = ioctl(dev->fd, DRM_IOCTL_MODE_DESTROY_DUMB, _destroy);
>   WARN_ON(ret, "DESTROY_DUMB failed: %s\n", ERRSTR);
>  
>   return -1;
>  }
>  
> +static int drm_buffer_import(struct drm_device *dev, struct buffer *b,
> +  const struct v4l2_pix_format *fmt)
> +{
> + struct drm_prime_handle prime;
> + struct drm_gem_close gem_close;
> + int ret;
> +
> + memset(, 0, sizeof prime);
> + prime.fd = b->dbuf_fd;
> + ret = ioctl(dev->fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, );
> + if (WARN_ON(ret, "PRIME_FD_TO_HANDLE failed: %s\n", ERRSTR))
> + return -1;
> + b->bo_handle = prime.handle;
> +
> + uint32_t offsets[4] = { 0 };
> + uint32_t pitches[4] = { fmt->bytesperline };
> + uint32_t bo_handles[4] = { b->bo_handle };
> + unsigned int fourcc = dev->format;
> + if (!fourcc)
> + fourcc = fmt->pixelformat;
> + ret = drmModeAddFB2(dev->fd, fmt->width, fmt->height, fourcc, 
> bo_handles,
> + pitches, offsets, >fb_handle, 0);
> + if (WARN_ON(ret, "drmModeAddFB2 failed: %s\n", ERRSTR))
> + goto fail_gem;
> +
> + return 0;
> +
> +fail_gem:
> + memset(_close, 0, sizeof gem_close);
> + gem_close.handle = b->bo_handle;
> + ret = ioctl(dev->fd, DRM_IOCTL_GEM_CLOSE, _close);
> + WARN_ON(ret, "GEM_CLOSE failed: %s\n", ERRSTR);
> +
> + return -1;
> +}
> +
>  static int 

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

2017-11-15 Thread Kieran Bingham
Hi Jacopo,

A couple of minor language fixups inline.

On 15/11/17 10:55, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..a88e9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,87 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with up 8/16bits data bus 
> width.

s/with up 8/16bits/with either 8 or 16 bits/ ?

> +
> +Required properties:
> +- compatible
> + Must be "renesas,renesas-ceu".
> +- reg
> + Physical address base and size.
> +- interrupts
> + The interrupt line number.
> +- pinctrl-names, pinctrl-0
> + phandle of pin controller sub-node configuring pins for CEU operations.
> +
> +CEU supports a single parallel input and should contain a single 'port' 
> subnode
> +with a single 'endpoint'. Optional endpoint properties applicable to parallel
> +input bus are described in "video-interfaces.txt".
> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and a

s/and a/and an/

> +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,renesas-ceu";
> + interrupts = ;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <_out>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> + clocks = <>;
> + clock-names = "xclk";
> +
> + xclk: fixed_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2400>;
> + };
> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <_in>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> + };
> 


[PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

2017-11-15 Thread Jacopo Mondi
Add driver for Renesas Capture Engine Unit (CEU).

The CEU interface supports capturing 'data' (YUV422) and 'images'
(NV[12|21|16|61]).

This driver aims to replace the soc_camera based sh_mobile_ceu one.

Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
platform GR-Peach.

Tested with ov7725 camera sensor on SH4 platform Migo-R.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/Kconfig   |9 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/renesas-ceu.c | 1768 ++
 3 files changed, 1779 insertions(+)
 create mode 100644 drivers/media/platform/renesas-ceu.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 3c4f7fa..401caea 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
  To compile this driver as a module, choose M here: the module
  will be called stm32-dcmi.

+config VIDEO_RENESAS_CEU
+   tristate "Renesas Capture Engine Unit (CEU) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
+   ---help---
+ This is a v4l2 driver for the Renesas CEU Interface
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 327f80a..0d1f02b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA)  += coda/

 obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o

+obj-$(CONFIG_VIDEO_RENESAS_CEU)+= renesas-ceu.o
+
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o

 obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
new file mode 100644
index 000..aaba3cd
--- /dev/null
+++ b/drivers/media/platform/renesas-ceu.c
@@ -0,0 +1,1768 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
+ *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
+ * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
+ * Copyright (C) 2008 Magnus Damm
+ *
+ * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"renesas-ceu"
+
+/* 
+ * CEU registers offsets and masks
+ */
+#define CEU_CAPSR  0x00 /* Capture start register  */
+#define CEU_CAPCR  0x04 /* Capture control register*/
+#define CEU_CAMCR  0x08 /* Capture interface control register  */
+#define CEU_CAMOR  0x10 /* Capture interface offset register   */
+#define CEU_CAPWR  0x14 /* Capture interface width register*/
+#define CEU_CAIFR  0x18 /* Capture interface input format register */
+#define CEU_CRCNTR 0x28 /* CEU register control register   */
+#define CEU_CRCMPR 0x2c /* CEU register forcible control register  */
+#define CEU_CFLCR  0x30 /* Capture filter control register */
+#define CEU_CFSZR  0x34 /* Capture filter size clip register   */
+#define CEU_CDWDR  0x38 /* Capture destination width register  */
+#define CEU_CDAYR  0x3c /* Capture data address Y register */
+#define CEU_CDACR  0x40 /* Capture data address C register */
+#define CEU_CFWCR  0x5c /* Firewall operation control register */
+#define CEU_CDOCR  0x64 /* Capture data output control register*/
+#define CEU_CEIER  0x70 /* Capture event interrupt enable register */
+#define CEU_CETCR  0x74 /* Capture event flag clear register   */
+#define CEU_CSTSR  0x7c /* Capture status register */
+#define CEU_CSRTR  0x80 /* Capture software reset register */
+
+/* Data synchronous fetch mode */
+#define CEU_CAMCR_JPEG BIT(4)
+
+/* Input components 

[PATCH v1 02/10] include: media: Add Renesas CEU driver interface

2017-11-15 Thread Jacopo Mondi
Add renesas-ceu header file.

Do not remove the existing sh_mobile_ceu.h one as long as the original
driver does not go away.

Signed-off-by: Jacopo Mondi 
---
 include/media/drv-intf/renesas-ceu.h | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 include/media/drv-intf/renesas-ceu.h

diff --git a/include/media/drv-intf/renesas-ceu.h 
b/include/media/drv-intf/renesas-ceu.h
new file mode 100644
index 000..f2da78c
--- /dev/null
+++ b/include/media/drv-intf/renesas-ceu.h
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+#ifndef __ASM_RENESAS_CEU_H__
+#define __ASM_RENESAS_CEU_H__
+
+#include 
+
+#define CEU_FLAG_PRIMARY_SENS  BIT(0)
+#define CEU_MAX_SENS   2
+
+struct ceu_async_subdev {
+   unsigned long flags;
+   unsigned char bus_width;
+   unsigned char bus_shift;
+   unsigned int i2c_adapter_id;
+   unsigned int i2c_address;
+};
+
+struct ceu_info {
+   unsigned int num_subdevs;
+   struct ceu_async_subdev subdevs[CEU_MAX_SENS];
+};
+
+#endif /* __ASM_RENESAS_CEU_H__ */
--
2.7.4



[PATCH v1 07/10] v4l: i2c: Copy ov772x soc_camera sensor driver

2017-11-15 Thread Jacopo Mondi
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/ov772x.c | 1124 
 1 file changed, 1124 insertions(+)
 create mode 100644 drivers/media/i2c/ov772x.c

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
new file mode 100644
index 000..8063835
--- /dev/null
+++ b/drivers/media/i2c/ov772x.c
@@ -0,0 +1,1124 @@
+/*
+ * ov772x Camera Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov7670 and soc_camera_platform driver,
+ *
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * register offset
+ */
+#define GAIN0x00 /* AGC - Gain control gain setting */
+#define BLUE0x01 /* AWB - Blue channel gain setting */
+#define RED 0x02 /* AWB - Red   channel gain setting */
+#define GREEN   0x03 /* AWB - Green channel gain setting */
+#define COM10x04 /* Common control 1 */
+#define BAVG0x05 /* U/B Average Level */
+#define GAVG0x06 /* Y/Gb Average Level */
+#define RAVG0x07 /* V/R Average Level */
+#define AECH0x08 /* Exposure Value - AEC MSBs */
+#define COM20x09 /* Common control 2 */
+#define PID 0x0A /* Product ID Number MSB */
+#define VER 0x0B /* Product ID Number LSB */
+#define COM30x0C /* Common control 3 */
+#define COM40x0D /* Common control 4 */
+#define COM50x0E /* Common control 5 */
+#define COM60x0F /* Common control 6 */
+#define AEC 0x10 /* Exposure Value */
+#define CLKRC   0x11 /* Internal clock */
+#define COM70x12 /* Common control 7 */
+#define COM80x13 /* Common control 8 */
+#define COM90x14 /* Common control 9 */
+#define COM10   0x15 /* Common control 10 */
+#define REG16   0x16 /* Register 16 */
+#define HSTART  0x17 /* Horizontal sensor size */
+#define HSIZE   0x18 /* Horizontal frame (HREF column) end high 8-bit */
+#define VSTART  0x19 /* Vertical frame (row) start high 8-bit */
+#define VSIZE   0x1A /* Vertical sensor size */
+#define PSHFT   0x1B /* Data format - pixel delay select */
+#define MIDH0x1C /* Manufacturer ID byte - high */
+#define MIDL0x1D /* Manufacturer ID byte - low  */
+#define LAEC0x1F /* Fine AEC value */
+#define COM11   0x20 /* Common control 11 */
+#define BDBASE  0x22 /* Banding filter Minimum AEC value */
+#define DBSTEP  0x23 /* Banding filter Maximum Setp */
+#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) */
+#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) */
+#define VPT 0x26 /* AGC/AEC Fast mode operating region */
+#define REG28   0x28 /* Register 28 */
+#define HOUTSIZE0x29 /* Horizontal data output size MSBs */
+#define EXHCH   0x2A /* Dummy pixel insert MSB */
+#define EXHCL   0x2B /* Dummy pixel insert LSB */
+#define VOUTSIZE0x2C /* Vertical data output size MSBs */
+#define ADVFL   0x2D /* LSB of insert dummy lines in Vertical direction */
+#define ADVFH   0x2E /* MSG of insert dummy lines in Vertical direction */
+#define YAVE0x2F /* Y/G Channel Average value */
+#define LUMHTH  0x30 /* Histogram AEC/AGC Luminance high level threshold */
+#define LUMLTH  0x31 /* Histogram AEC/AGC Luminance low  level threshold */
+#define HREF0x32 /* Image start and size control */
+#define DM_LNL  0x33 /* Dummy line low  8 bits */
+#define DM_LNH  0x34 /* Dummy line high 8 bits */
+#define ADOFF_B 0x35 /* AD offset compensation value for B  channel */
+#define ADOFF_R 0x36 /* AD offset compensation value for R  channel */
+#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */
+#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */
+#define OFF_B   0x39 /* Analog process B  channel offset value */
+#define OFF_R   0x3A /* Analog process R  channel offset value */
+#define OFF_GB  0x3B /* Analog process Gb channel offset value */
+#define OFF_GR  0x3C /* Analog process Gr channel offset value */
+#define COM12   0x3D /* Common control 12 */
+#define COM13   0x3E /* Common control 13 */
+#define COM14   0x3F /* Common control 14 */
+#define COM15   0x40 /* Common control 15*/
+#define 

[PATCH v1 08/10] media: i2c: ov772x: Remove soc_camera dependencies

2017-11-15 Thread Jacopo Mondi
Remove soc_camera framework dependencies from ov772x sensor driver.
- Handle clock directly
- Register async subdevice
- Add platform specific enable/disable functions
- Adjust build system

This commit does not remove the original soc_camera based driver.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig  | 12 +++
 drivers/media/i2c/Makefile |  1 +
 drivers/media/i2c/ov772x.c | 88 +++---
 include/media/i2c/ov772x.h |  3 ++
 4 files changed, 76 insertions(+), 28 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9415389..ff251ce 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -629,6 +629,18 @@ config VIDEO_OV5670
  To compile this driver as a module, choose M here: the
  module will be called ov5670.

+config VIDEO_OV772X
+   tristate "OmniVision OV772x sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV772x camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov772x.
+
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f104650..b2459a1 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
+obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 8063835..9be7e4e 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -15,6 +15,7 @@
  * published by the Free Software Foundation.
  */

+#include 
 #include 
 #include 
 #include 
@@ -25,8 +26,8 @@
 #include 

 #include 
-#include 
-#include 
+
+#include 
 #include 
 #include 
 #include 
@@ -393,7 +394,7 @@ struct ov772x_win_size {
 struct ov772x_priv {
struct v4l2_subdevsubdev;
struct v4l2_ctrl_handler  hdl;
-   struct v4l2_clk  *clk;
+   struct clk   *clk;
struct ov772x_camera_info*info;
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
@@ -550,7 +551,7 @@ static int ov772x_reset(struct i2c_client *client)
 }

 /*
- * soc_camera_ops function
+ * subdev ops
  */

 static int ov772x_s_stream(struct v4l2_subdev *sd, int enable)
@@ -650,13 +651,36 @@ static int ov772x_s_register(struct v4l2_subdev *sd,
 }
 #endif

+static int ov772x_power_on(struct ov772x_priv *priv)
+{
+   int ret;
+
+   if (priv->info->platform_enable) {
+   ret = priv->info->platform_enable();
+   if (ret)
+   return ret;
+   }
+
+   /*  drivers/sh/clk/core.c returns -EINVAL if clk is NULL */
+   return clk_enable(priv->clk) <= 0 ? 0 : 1;
+}
+
+static int ov772x_power_off(struct ov772x_priv *priv)
+{
+   if (priv->info->platform_enable)
+   priv->info->platform_disable();
+
+   clk_disable(priv->clk);
+
+   return 0;
+}
+
 static int ov772x_s_power(struct v4l2_subdev *sd, int on)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov772x_priv *priv = to_ov772x(sd);

-   return soc_camera_set_power(>dev, ssdd, priv->clk, on);
+   return on ? ov772x_power_on(priv) :
+   ov772x_power_off(priv);
 }

 static const struct ov772x_win_size *ov772x_select_win(u32 width, u32 height)
@@ -1000,14 +1024,10 @@ static int ov772x_enum_mbus_code(struct v4l2_subdev *sd,
 static int ov772x_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-
cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
V4L2_MBUS_DATA_ACTIVE_HIGH;
cfg->type = V4L2_MBUS_PARALLEL;
-   cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);

return 0;
 }
@@ -1038,12 +1058,11 @@ static int ov772x_probe(struct i2c_client *client,
const struct i2c_device_id *did)
 {
struct ov772x_priv  *priv;
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-   struct i2c_adapter  *adapter = to_i2c_adapter(client->dev.parent);
+   struct 

[PATCH v1 09/10] v4l: i2c: Copy tw9910 soc_camera sensor driver

2017-11-15 Thread Jacopo Mondi
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/tw9910.c | 999 +
 1 file changed, 999 insertions(+)
 create mode 100644 drivers/media/i2c/tw9910.c

diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
new file mode 100644
index 000..bdb5e0a
--- /dev/null
+++ b/drivers/media/i2c/tw9910.c
@@ -0,0 +1,999 @@
+/*
+ * tw9910 Video Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov772x driver,
+ *
+ * Copyright (C) 2008 Kuninori Morimoto 
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define GET_ID(val)  ((val & 0xF8) >> 3)
+#define GET_REV(val) (val & 0x07)
+
+/*
+ * register offset
+ */
+#define ID 0x00 /* Product ID Code Register */
+#define STATUS10x01 /* Chip Status Register I */
+#define INFORM 0x02 /* Input Format */
+#define OPFORM 0x03 /* Output Format Control Register */
+#define DLYCTR 0x04 /* Hysteresis and HSYNC Delay Control */
+#define OUTCTR10x05 /* Output Control I */
+#define ACNTL1 0x06 /* Analog Control Register 1 */
+#define CROP_HI0x07 /* Cropping Register, High */
+#define VDELAY_LO  0x08 /* Vertical Delay Register, Low */
+#define VACTIVE_LO 0x09 /* Vertical Active Register, Low */
+#define HDELAY_LO  0x0A /* Horizontal Delay Register, Low */
+#define HACTIVE_LO 0x0B /* Horizontal Active Register, Low */
+#define CNTRL1 0x0C /* Control Register I */
+#define VSCALE_LO  0x0D /* Vertical Scaling Register, Low */
+#define SCALE_HI   0x0E /* Scaling Register, High */
+#define HSCALE_LO  0x0F /* Horizontal Scaling Register, Low */
+#define BRIGHT 0x10 /* BRIGHTNESS Control Register */
+#define CONTRAST   0x11 /* CONTRAST Control Register */
+#define SHARPNESS  0x12 /* SHARPNESS Control Register I */
+#define SAT_U  0x13 /* Chroma (U) Gain Register */
+#define SAT_V  0x14 /* Chroma (V) Gain Register */
+#define HUE0x15 /* Hue Control Register */
+#define CORING10x17
+#define CORING20x18 /* Coring and IF compensation */
+#define VBICNTL0x19 /* VBI Control Register */
+#define ACNTL2 0x1A /* Analog Control 2 */
+#define OUTCTR20x1B /* Output Control 2 */
+#define SDT0x1C /* Standard Selection */
+#define SDTR   0x1D /* Standard Recognition */
+#define TEST   0x1F /* Test Control Register */
+#define CLMPG  0x20 /* Clamping Gain */
+#define IAGC   0x21 /* Individual AGC Gain */
+#define AGCGAIN0x22 /* AGC Gain */
+#define PEAKWT 0x23 /* White Peak Threshold */
+#define CLMPL  0x24 /* Clamp level */
+#define SYNCT  0x25 /* Sync Amplitude */
+#define MISSCNT0x26 /* Sync Miss Count Register */
+#define PCLAMP 0x27 /* Clamp Position Register */
+#define VCNTL1 0x28 /* Vertical Control I */
+#define VCNTL2 0x29 /* Vertical Control II */
+#define CKILL  0x2A /* Color Killer Level Control */
+#define COMB   0x2B /* Comb Filter Control */
+#define LDLY   0x2C /* Luma Delay and H Filter Control */
+#define MISC1  0x2D /* Miscellaneous Control I */
+#define LOOP   0x2E /* LOOP Control Register */
+#define MISC2  0x2F /* Miscellaneous Control II */
+#define MVSN   0x30 /* Macrovision Detection */
+#define STATUS20x31 /* Chip STATUS II */
+#define HFREF  0x32 /* H monitor */
+#define CLMD   0x33 /* CLAMP MODE */
+#define IDCNTL 0x34 /* ID Detection Control */
+#define CLCNTL10x35 /* Clamp Control I */
+#define ANAPLLCTL  0x4C
+#define VBIMIN 0x4D
+#define HSLOWCTL   0x4E
+#define WSS3   0x4F
+#define FILLDATA   0x50
+#define SDID   0x51
+#define DID0x52
+#define WSS1   0x53
+#define WSS2   0x54
+#define VVBI   0x55
+#define LCTL6  0x56
+#define LCTL7  0x57
+#define LCTL8  0x58
+#define LCTL9  0x59
+#define LCTL10 0x5A
+#define LCTL11 0x5B
+#define LCTL12 0x5C
+#define LCTL13 0x5D
+#define LCTL14 0x5E
+#define LCTL15 

[PATCH v1 10/10] media: i2c: tw9910: Remove soc_camera dependencies

2017-11-15 Thread Jacopo Mondi
Remove soc_camera framework dependencies from tw9910 sensor driver.
- Handle clock directly
- Register async subdevice
- Add platform specific enable/disable functions
- Adjust build system

This commit does not remove the original soc_camera based driver.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig  |  9 ++
 drivers/media/i2c/Makefile |  1 +
 drivers/media/i2c/tw9910.c | 80 ++
 include/media/i2c/tw9910.h |  6 
 4 files changed, 75 insertions(+), 21 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ff251ce..bbd77ee 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -415,6 +415,15 @@ config VIDEO_TW9906
  To compile this driver as a module, choose M here: the
  module will be called tw9906.

+config VIDEO_TW9910
+   tristate "Techwell TW9910 video decoder"
+   depends on VIDEO_V4L2 && I2C
+   ---help---
+ Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9910.
+
 config VIDEO_VPX3220
tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b2459a1..835784a 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
 obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
 obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
 obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
+obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
 obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
 obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
 obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
index bdb5e0a..f422da2 100644
--- a/drivers/media/i2c/tw9910.c
+++ b/drivers/media/i2c/tw9910.c
@@ -16,6 +16,7 @@
  * published by the Free Software Foundation.
  */

+#include 
 #include 
 #include 
 #include 
@@ -25,9 +26,7 @@
 #include 
 #include 

-#include 
 #include 
-#include 
 #include 

 #define GET_ID(val)  ((val & 0xF8) >> 3)
@@ -228,7 +227,7 @@ struct tw9910_scale_ctrl {

 struct tw9910_priv {
struct v4l2_subdev  subdev;
-   struct v4l2_clk *clk;
+   struct clk  *clk;
struct tw9910_video_info*info;
const struct tw9910_scale_ctrl  *scale;
v4l2_std_id norm;
@@ -582,13 +581,40 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
 }
 #endif

+static int tw9910_power_on(struct tw9910_priv *priv)
+{
+   int ret;
+
+   if (priv->info->platform_enable) {
+   ret = priv->info->platform_enable();
+   if (ret)
+   return ret;
+   }
+
+   if (priv->clk)
+   return clk_enable(priv->clk);
+
+   return 0;
+}
+
+static int tw9910_power_off(struct tw9910_priv *priv)
+{
+   if (priv->info->platform_enable)
+   priv->info->platform_disable();
+
+   if (priv->clk)
+   clk_disable(priv->clk);
+
+   return 0;
+}
+
 static int tw9910_s_power(struct v4l2_subdev *sd, int on)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct tw9910_priv *priv = to_tw9910(client);

-   return soc_camera_set_power(>dev, ssdd, priv->clk, on);
+   return on ? tw9910_power_on(priv) :
+   tw9910_power_off(priv);
 }

 static int tw9910_set_frame(struct v4l2_subdev *sd, u32 *width, u32 *height)
@@ -614,7 +640,7 @@ static int tw9910_set_frame(struct v4l2_subdev *sd, u32 
*width, u32 *height)
 * set bus width
 */
val = 0x00;
-   if (SOCAM_DATAWIDTH_16 == priv->info->buswidth)
+   if (priv->info->buswidth == TW9910_DATAWIDTH_16)
val = LEN;

ret = tw9910_mask_set(client, OPFORM, LEN, val);
@@ -799,8 +825,8 @@ static int tw9910_video_probe(struct i2c_client *client)
/*
 * tw9910 only use 8 or 16 bit bus width
 */
-   if (SOCAM_DATAWIDTH_16 != priv->info->buswidth &&
-   SOCAM_DATAWIDTH_8  != priv->info->buswidth) {
+   if (priv->info->buswidth != TW9910_DATAWIDTH_16 &&
+   priv->info->buswidth != TW9910_DATAWIDTH_8) {
dev_err(>dev, "bus width error\n");
return -ENODEV;
}
@@ -859,15 +885,11 @@ static int tw9910_enum_mbus_code(struct v4l2_subdev *sd,
 static int tw9910_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-
cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |

[PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

2017-11-15 Thread Jacopo Mondi
Add bindings documentation for Renesas Capture Engine Unit (CEU).

Signed-off-by: Jacopo Mondi 
---
 .../devicetree/bindings/media/renesas,ceu.txt  | 87 ++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
b/Documentation/devicetree/bindings/media/renesas,ceu.txt
new file mode 100644
index 000..a88e9cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
@@ -0,0 +1,87 @@
+Renesas Capture Engine Unit (CEU)
+--
+
+The Capture Engine Unit is the image capture interface found on Renesas
+RZ chip series and on SH Mobile ones.
+
+The interface supports a single parallel input with up 8/16bits data bus width.
+
+Required properties:
+- compatible
+   Must be "renesas,renesas-ceu".
+- reg
+   Physical address base and size.
+- interrupts
+   The interrupt line number.
+- pinctrl-names, pinctrl-0
+   phandle of pin controller sub-node configuring pins for CEU operations.
+
+CEU supports a single parallel input and should contain a single 'port' subnode
+with a single 'endpoint'. Optional endpoint properties applicable to parallel
+input bus are described in "video-interfaces.txt".
+
+Example:
+
+The example describes the connection between the Capture Engine Unit and a
+OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
+
+ceu: ceu@e821 {
+   reg = <0xe821 0x209c>;
+   compatible = "renesas,renesas-ceu";
+   interrupts = ;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   port {
+   ceu_in: endpoint {
+   remote-endpoint = <_out>;
+
+   bus-width = <8>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
+
+i2c1: i2c@fcfee400 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+   clock-frequency = <10>;
+
+   ov7670: camera@21 {
+   compatible = "ovti,ov7670";
+   reg = <0x21>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
+
+   clocks = <>;
+   clock-names = "xclk";
+
+   xclk: fixed_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+   };
+
+   port {
+   ov7670_out: endpoint {
+   remote-endpoint = <_in>;
+
+   bus-width = <8>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+   };
-- 
2.7.4



[PATCH v1 00/10] Renesas Capture Engine Unit (CEU) V4L2 driver

2017-11-15 Thread Jacopo Mondi
Hello,
   this series implementes a modern V4L2 driver for Renesas Capture Engine
Unit (CEU). CEU is currently supported by the soc_camera based driver
drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c

The driver supports capturing images in planar formats (NV12/21 and NV16/61)
and non-planar YUYV422 format.

It had been tested with OV7670/OV7725 images sensor capturing images at
different resolutions (VGA and QVGA)

The series:
- Adds a new driver under drivers/media/platform/renesas-ceu.c and a new driver
  interface under include/media/drv-intf/renesas-ceu.h
- Adds device tree bindings for renesas-ceu
- Adds CEU to Renesas RZ/A1 dtsi
- Ports Migo-R SH4 based platform to make use of the new driver
- Ports image sensor drivers used by Migo-R (ov772x and tw9910) away from
  soc_camera

While this driver aims to replace the existing one, which is the last platform
driver making use of soc_camera framework, this series does not delete any of
the existing code, just because there are other SH4 users of the existing
soc_camera based driver: (mach-ap325rxa, mach-ecovec24, mach-kfr2r09 and
mach-se/7724)

As I only have access to Migo-R board, I have ported that one first, while all
other boards can be compile-ported later, once this new driver will eventually
be accepted mainline.

This series is based on v4.14-rc8 with a few patches applied on top:
https://www.spinics.net/lists/linux-sh/msg51739.html

These patches are required for mainline Migo-R board and sh_mobile_ceu_camera
driver to work properly with SH4 architecture on modern kernels, and I have
based my series on top of them.

A tag with those patches already applied on top of v4.14-rc8 is available at
git://jmondi.org/linux v4.14-rc8-migor-ceu-base

A note on testing:
The CEU IP block is found on both Renesas RZ series devices (single core ARM
platforms) and on older SH4 devices (such as Migo-R).
I have developed and tested the driver on RZ platforms, specifically on
GR-Peach with an OV7670 based camera module. More details on:
https://elinux.org/RZ-A/Boards/GR-PEACH-audiocamerashield

As we aim to replace the soc_camera based driver, I have also tested the
new one on Migo-R, capturing images from the OV7725 sensor installed on
that board (I've not been able to test TW9910 video decoder as the sensor does
not probe on the platform I have access to).
Hans, as you told me, you have a Migo-R and if you eventually would like to
give this series a spin on that platform feel free to ping me, as to run a
modern mainline kernel on SH4 you may need the above mentioned patches and some
attention to configuration option for SH4.

A note on sensor drivers:
As I need ov772x and tw9910 driver to be ported away from soc_camera for testing
on Migo-R, for each of them I have copied the driver first in
drivers/media/i2c/ from drivers/media/i2c/soc_camera without any modification
and then removed soc_camera dependencies in a separate commit to ease review.
As per the soc_camera based CEU platform driver, I have not removed the original
soc_camera based sensor drivers in this series.

Output of v4l2-compliance is available at:
https://paste.debian.net/995838/
I'm slightly confused about what the test application complains for
TRY_FMT/S_FMT but I judged this good enough for a first submission.

Thanks
  j

Jacopo Mondi (10):
  dt-bindings: media: Add Renesas CEU bindings
  include: media: Add Renesas CEU driver interface
  v4l: platform: Add Renesas CEU driver
  ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
  arch: sh: migor: Use new renesas-ceu camera driver
  sh: sh7722: Rename CEU clock
  v4l: i2c: Copy ov772x soc_camera sensor driver
  media: i2c: ov772x: Remove soc_camera dependencies
  v4l: i2c: Copy tw9910 soc_camera sensor driver
  media: i2c: tw9910: Remove soc_camera dependencies

 .../devicetree/bindings/media/renesas,ceu.txt  |   87 +
 arch/arm/boot/dts/r7s72100.dtsi|   12 +-
 arch/sh/boards/mach-migor/setup.c  |  164 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |2 +-
 drivers/media/i2c/Kconfig  |   21 +
 drivers/media/i2c/Makefile |2 +
 drivers/media/i2c/ov772x.c | 1156 +
 drivers/media/i2c/tw9910.c | 1037 
 drivers/media/platform/Kconfig |9 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/renesas-ceu.c   | 1766 
 include/media/drv-intf/renesas-ceu.h   |   23 +
 include/media/i2c/ov772x.h |3 +
 include/media/i2c/tw9910.h |6 +
 14 files changed, 4199 insertions(+), 91 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
 create mode 100644 drivers/media/i2c/ov772x.c
 create mode 100644 drivers/media/i2c/tw9910.c
 create mode 100644 drivers/media/platform/renesas-ceu.c
 create 

[PATCH v1 06/10] sh: sh7722: Rename CEU clock

2017-11-15 Thread Jacopo Mondi
Rename CEU clock to match the new platform driver name used in Migo-R.

There are no other sh7722 based devices Migo-R apart, so we can safely
rename this.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c 
b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
index 8f07a1a..d85091e 100644
--- a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
+++ b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
@@ -223,7 +223,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh-vou.0", _clks[HWBLK_VOU]),
CLKDEV_CON_ID("jpu0", _clks[HWBLK_JPU]),
CLKDEV_CON_ID("beu0", _clks[HWBLK_BEU]),
-   CLKDEV_DEV_ID("sh_mobile_ceu.0", _clks[HWBLK_CEU]),
+   CLKDEV_DEV_ID("renesas-ceu.0", _clks[HWBLK_CEU]),
CLKDEV_CON_ID("veu0", _clks[HWBLK_VEU]),
CLKDEV_CON_ID("vpu0", _clks[HWBLK_VPU]),
CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", _clks[HWBLK_LCDC]),
-- 
2.7.4



[PATCH v1 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

2017-11-15 Thread Jacopo Mondi
Add Capture Engine Unit (CEU) node to device tree.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r7s72100.dtsi | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 4ed12a4..683d459 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -136,8 +136,8 @@
compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
reg = <0xfcfe042c 4>;
clocks = <_clk>;
-   clock-indices = ;
-   clock-output-names = "rtc";
+   clock-indices = ;
+   clock-output-names = "rtc", "ceu";
};
 
mstp7_clks: mstp7_clks@fcfe0430 {
@@ -666,4 +666,12 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+   ceu: ceu@e821 {
+   reg = <0xe821 0x209c>;
+   compatible = "renesas,renesas-ceu";
+   interrupts = ;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
 };
-- 
2.7.4



[PATCH v1 05/10] arch: sh: migor: Use new renesas-ceu camera driver

2017-11-15 Thread Jacopo Mondi
Migo-R platform uses sh_mobile_ceu camera driver, which is now being
replaced by a proper V4L2 camera driver named 'renesas-ceu'.

Move Migo-R platform to use the v4l2 renesas-ceu camera driver
interface and get rid of soc_camera defined components used to register
sensor drivers.

Also, memory for CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/boards/mach-migor/setup.c | 164 ++
 1 file changed, 76 insertions(+), 88 deletions(-)

diff --git a/arch/sh/boards/mach-migor/setup.c 
b/arch/sh/boards/mach-migor/setup.c
index 98aa094..10a9b3c 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -308,62 +308,80 @@ static struct platform_device migor_lcdc_device = {
 static struct clk *camera_clk;
 static DEFINE_MUTEX(camera_lock);

-static void camera_power_on(int is_tw)
+static void camera_vio_clk_on(void)
 {
-   mutex_lock(_lock);
-
/* Use 10 MHz VIO_CKO instead of 24 MHz to work
 * around signal quality issues on Panel Board V2.1.
 */
camera_clk = clk_get(NULL, "video_clk");
clk_set_rate(camera_clk, 1000);
clk_enable(camera_clk); /* start VIO_CKO */
-
-   /* use VIO_RST to take camera out of reset */
-   mdelay(10);
-   if (is_tw) {
-   gpio_set_value(GPIO_PTT2, 0);
-   gpio_set_value(GPIO_PTT0, 0);
-   } else {
-   gpio_set_value(GPIO_PTT0, 1);
-   }
-   gpio_set_value(GPIO_PTT3, 0);
-   mdelay(10);
-   gpio_set_value(GPIO_PTT3, 1);
-   mdelay(10); /* wait to let chip come out of reset */
 }

-static void camera_power_off(void)
+static void camera_disable(void)
 {
-   clk_disable(camera_clk); /* stop VIO_CKO */
+   /* stop VIO_CKO */
+   clk_disable(camera_clk);
clk_put(camera_clk);

+   gpio_set_value(GPIO_PTT0, 0);
+   gpio_set_value(GPIO_PTT2, 1);
gpio_set_value(GPIO_PTT3, 0);
+
mutex_unlock(_lock);
 }

-static int ov7725_power(struct device *dev, int mode)
+static void camera_reset(void)
 {
-   if (mode)
-   camera_power_on(0);
-   else
-   camera_power_off();
+   /* use VIO_RST to take camera out of reset */
+   gpio_set_value(GPIO_PTT3, 0);
+   mdelay(10);
+   gpio_set_value(GPIO_PTT3, 1);
+   mdelay(10);
+}
+
+static int ov7725_enable(void)
+{
+   mutex_lock(_lock);
+   camera_vio_clk_on();
+   mdelay(10);
+   gpio_set_value(GPIO_PTT0, 1);
+
+   camera_reset();

return 0;
 }

-static int tw9910_power(struct device *dev, int mode)
+static int tw9910_enable(void)
 {
-   if (mode)
-   camera_power_on(1);
-   else
-   camera_power_off();
+   mutex_lock(_lock);
+   camera_vio_clk_on();
+   mdelay(10);
+   gpio_set_value(GPIO_PTT2, 0);
+
+   camera_reset();

return 0;
 }

-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_info ceu_info = {
+   .num_subdevs= 2,
+   .subdevs = {
+   { /* [0] = ov772x */
+   .flags  = CEU_FLAG_PRIMARY_SENS,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x21,
+   },
+   { /* [1] = tw9910 */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x45,
+   },
+   },
 };

 static struct resource migor_ceu_resources[] = {
@@ -377,18 +395,15 @@ static struct resource migor_ceu_resources[] = {
.start  = evt2irq(0x880),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };

 static struct platform_device migor_ceu_device = {
-   .name   = "sh_mobile_ceu",
+   .name   = "renesas-ceu",
.id = 0, /* "ceu0" clock */
.num_resources  = ARRAY_SIZE(migor_ceu_resources),
.resource   = migor_ceu_resources,
.dev= {
-   .platform_data  = _mobile_ceu_info,
+   .platform_data  = _info,
},
 };

@@ -427,6 +442,19 @@ static struct platform_device sdhi_cn9_device = {
},
 };

+static struct ov772x_camera_info ov7725_info = {
+   .platform_enable = ov7725_enable,
+   .platform_disable = camera_disable,
+};
+
+static struct tw9910_video_info 

Re: [PATCH v11 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

2017-11-15 Thread Niklas Söderlund
Hi,

I just noticed I made a small mistake in this patch, see bellow. I will 
send out a new version in a few days with this fix included but I don't 
want to spam the list too much so I give it a few more days if there is 
any other feedback.

On 2017-11-11 01:25:26 +0100, Niklas Söderlund wrote:
> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> hardware blocks are connected between the video sources and the video
> grabbers (VIN).
> 
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/Kconfig |  12 +
>  drivers/media/platform/rcar-vin/Makefile|   1 +
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 896 
> 
>  3 files changed, 909 insertions(+)
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> 
> diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> b/drivers/media/platform/rcar-vin/Kconfig
> index af4c98b44d2e22cb..6875f30c1ae42631 100644
> --- a/drivers/media/platform/rcar-vin/Kconfig
> +++ b/drivers/media/platform/rcar-vin/Kconfig
> @@ -1,3 +1,15 @@
> +config VIDEO_RCAR_CSI2
> + tristate "R-Car MIPI CSI-2 Receiver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> + depends on ARCH_RENESAS || COMPILE_TEST
> + select V4L2_FWNODE
> + ---help---
> +   Support for Renesas R-Car MIPI CSI-2 receiver.
> +   Supports R-Car Gen3 SoCs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called rcar-csi2.
> +
>  config VIDEO_RCAR_VIN
>   tristate "R-Car Video Input (VIN) Driver"
>   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> MEDIA_CONTROLLER
> diff --git a/drivers/media/platform/rcar-vin/Makefile 
> b/drivers/media/platform/rcar-vin/Makefile
> index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> --- a/drivers/media/platform/rcar-vin/Makefile
> +++ b/drivers/media/platform/rcar-vin/Makefile
> @@ -1,3 +1,4 @@
>  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
>  
> +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
>  obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> new file mode 100644
> index ..4202c60b4d0aa7f7
> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -0,0 +1,896 @@
> +/*
> + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> + *
> + * Copyright (C) 2017 Renesas Electronics Corp.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets and bits */
> +
> +/* Control Timing Select */
> +#define TREF_REG 0x00
> +#define TREF_TREFBIT(0)
> +
> +/* Software Reset */
> +#define SRST_REG 0x04
> +#define SRST_SRSTBIT(0)
> +
> +/* PHY Operation Control */
> +#define PHYCNT_REG   0x08
> +#define PHYCNT_SHUTDOWNZ BIT(17)
> +#define PHYCNT_RSTZ  BIT(16)
> +#define PHYCNT_ENABLECLK BIT(4)
> +#define PHYCNT_ENABLE_3  BIT(3)
> +#define PHYCNT_ENABLE_2  BIT(2)
> +#define PHYCNT_ENABLE_1  BIT(1)
> +#define PHYCNT_ENABLE_0  BIT(0)
> +
> +/* Checksum Control */
> +#define CHKSUM_REG   0x0c
> +#define CHKSUM_ECC_ENBIT(1)
> +#define CHKSUM_CRC_ENBIT(0)
> +
> +/*
> + * Channel Data Type Select
> + * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
> + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
> + */
> +#define VCDT_REG 0x10
> +#define VCDT2_REG0x14
> +#define VCDT_VCDTN_ENBIT(15)
> +#define VCDT_SEL_VC(n)   (((n) & 0x3) << 8)
> +#define VCDT_SEL_DTN_ON  BIT(6)
> +#define VCDT_SEL_DT(n)   (((n) & 0x3f) << 0)
> +
> +/* Frame Data Type Select */
> +#define FRDT_REG 0x18
> +
> +/* Field Detection Control */
> +#define FLD_REG  0x1c
> +#define FLD_FLD_NUM(n)   (((n) & 0xff) << 16)
> +#define FLD_FLD_EN4  BIT(3)
> +#define FLD_FLD_EN3  BIT(2)
> +#define FLD_FLD_EN2  BIT(1)
> +#define FLD_FLD_EN   BIT(0)
> +
> +/* Automatic Standby 

Re: [PATCH/RFT v5 3/3] iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code

2017-11-15 Thread Geert Uytterhoeven
Hi Simon,

On Tue, Nov 14, 2017 at 9:34 AM, Simon Horman
 wrote:
> Support the r8a77970 (R-Car V3M) and r8a77995 (R-Car D3) IPMMUs by sharing
> feature flags with r8a7795 (R-Car H3) and r8a7796 (R-Car M3-W). Also update
> IOMMU_OF_DECLARE to hook up the compat strings.
>
> Based on work for the r8a7796 by Magnus Damm
>
> Signed-off-by: Simon Horman 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v2
> * Add reviewed-by tag from Geert Uytterhoeven
> ---
>  drivers/iommu/ipmmu-vmsa.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index f936f834984a..49c6fc0c1ae6 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -763,6 +763,8 @@ static bool ipmmu_slave_whitelist(struct device *dev)
>  static const struct soc_device_attribute soc_rcar_gen3[] = {
> { .soc_id = "r8a7795", },
> { .soc_id = "r8a7796", },
> +   { .soc_id = "r8a77970", },
> +   { .soc_id = "r8a77995", },

This array starts becoming a mirror of most entries in ipmmu_of_ids[].
As long as you don't need to match against a specific SoC revision, you could
store the whitelist check flag in struct ipmmu_features, as pointed to by
ipmmu_of_ids.data.

> { /* sentinel */ }
>  };
>
> @@ -943,6 +945,12 @@ static const struct of_device_id ipmmu_of_ids[] = {
> .compatible = "renesas,ipmmu-r8a7796",
> .data = _features_rcar_gen3,
> }, {
> +   .compatible = "renesas,ipmmu-r8a77970",
> +   .data = _features_rcar_gen3,
> +   }, {
> +   .compatible = "renesas,ipmmu-r8a77995",
> +   .data = _features_rcar_gen3,
> +   }, {
> /* Terminator */
> },


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 v1 03/10] v4l: platform: Add Renesas CEU driver

2017-11-15 Thread jacopo mondi
Hi Sakari,
   thanks for review!

On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> Could you remove the original driver and send the patch using git
> send-email -C ? That way a single patch would address converting it to a
> proper V4L2 driver as well as move it to the correct location. The changes
> would be easier to review that way since then, well, it'd be easier to see
> the changes. :-)

Actually I prefer not to remove the existing driver at the moment. See
the cover letter for reasons why not to do so right now...

Also, there's not that much code from the old driver in here, surely
less than the default 50% -C and -M options of 'git format-patch' use
as a threshold for detecting copies iirc..

I would prefer this to be reviewed as new driver, I know it's a bit
more painful, but irq handler and a couple of other routines apart,
there's not that much code shared between the two...

>
> The same goes for the two V4L2 SoC camera sensor / video decoder drivers at
> the end of the set.
>

Also in this case I prefer not to remove existing code, as long as
there are platforms using it..

> On Wed, Nov 15, 2017 at 11:55:56AM +0100, Jacopo Mondi wrote:
> > Add driver for Renesas Capture Engine Unit (CEU).
> >
> > The CEU interface supports capturing 'data' (YUV422) and 'images'
> > (NV[12|21|16|61]).
> >
> > This driver aims to replace the soc_camera based sh_mobile_ceu one.
> >
> > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> > platform GR-Peach.
> >
> > Tested with ov7725 camera sensor on SH4 platform Migo-R.
>
> Nice!
>
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> > +#include 
>
> Do you need this header? There would seem some that I wouldn't expect to be
> needed below, such as linux/init.h.

It's probably a leftover, I'll remove it...

[snip]
>
> > +#if IS_ENABLED(CONFIG_OF)
> > +static const struct of_device_id ceu_of_match[] = {
> > +   { .compatible = "renesas,renesas-ceu" },
>
> Even if you add support for new hardware, shouldn't you maintain support
> for renesas,sh-mobile-ceu?
>

As you noticed already, the old driver did not support OF, so there
are no compatibility issues here

Thanks
   j


Re: [PATCH v5 01/15] arm64: dts: renesas: r8a7795: Add IPMMU device nodes

2017-11-15 Thread Geert Uytterhoeven
Hi Simon,

On Fri, Nov 10, 2017 at 2:25 PM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Add r8a7795 IPMMU nodes and keep all disabled by default.
>
> This includes all IPMMU devices for r8a7795 ES2.0. Those
> not present in r8a7795 ES1.x are removed from the DT for those
> SoCs using delete-node. A follow-up patch will add IPMMU devices
> to ES1.x which are not also present in ES2.0.
>
> Signed-off-by: Magnus Damm 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Simon Horman 
> ---
> v5 [Simon Horman]
> * Correct ES1.x override for ipmmu_vc0
> * Add ES1.x override for ipmmu_vc1
> * Drop mostly redundant comments from nodes
> * Add power domains
> * Consistently mark all nodes as disabled

Thanks for the update!

Looks like "power-domains" do work for IOMMU nodes.
However, adding them seems to postpone initialization of the IOMMUs.

With the two typos below fixed:
Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi

> +   ipmmu_vc0: mmu@fe6b {
> +   compatible = "renesas,ipmmu-r8a7795";
> +   reg = <0 0xfe6b 0 0x1000>;
> +   renesas,ipmmu-main = <_mm 12>;
> +   power-domains = < R8A7795_PD_A3VP>;

R8A7795_PD_A3VC

> +   #iommu-cells = <1>;
> +   status = "disabled";
> +   };
> +
> +   ipmmu_vc1: mmu@fe6f {
> +   compatible = "renesas,ipmmu-r8a7795";
> +   reg = <0 0xfe6f 0 0x1000>;
> +   renesas,ipmmu-main = <_mm 13>;
> +   power-domains = < R8A7795_PD_A3VP>;

R8A7795_PD_A3VC

> +   #iommu-cells = <1>;
> +   status = "disabled";
> +   };

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 v5 02/15] arm64: dts: renesas: r8a7795-es1: Add IPMMU device nodes

2017-11-15 Thread Geert Uytterhoeven
On Fri, Nov 10, 2017 at 2:25 PM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Add r8a7795 ES1.x IPMMU nodes and keep all disabled by default.
>
> This is a follow-up to a patch that adds IPMMU device nodes that
> are common to r8a7795 ES1.x and ES2.0
>
> Power domains are omitted as they appear to be undocumented.
>
> Signed-off-by: Magnus Damm 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Simon Horman 
> ---
> v5 [Simon Horman]
> * Added reviewed-by tag from Geert Uytterhoeven

Nope, you didn't ;-)

Reviewed-by: Geert Uytterhoeven 

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 0/3] [VIN-Tests] minor updates

2017-11-15 Thread Kieran Bingham
From: Kieran Bingham 

Hi Niklas,

Some minor updates to the 8camera-status tool, and a speed up fix for the
vin-tests core function 'mc_get_dev()'.

Kieran Bingham (3):
  tools: 8camera-status: Fix write failure mis-allocations
  tools: 8camera-status: Expand to 9 cameras
  vin-tests: Refactor mc_get_dev

 scripts/vin-tests.sh | 14 +++---
 tools/8camera-status | 12 ++--
 2 files changed, 9 insertions(+), 17 deletions(-)

-- 
2.7.4



[PATCH 1/3] tools: 8camera-status: Fix write failure mis-allocations

2017-11-15 Thread Kieran Bingham
From: Kieran Bingham 

Debug prints of the max9271_write call are appearing in the failure counts.

Fix the 'catcher' so that it is more specific to the failure

Signed-off-by: Kieran Bingham 
---
 tools/8camera-status | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/8camera-status b/tools/8camera-status
index 234b8a0cab2b..cdfe76ef286f 100755
--- a/tools/8camera-status
+++ b/tools/8camera-status
@@ -21,7 +21,7 @@ BEGIN {
print
 }
 
-/max9271_write/ {
+/max9271_write.*write failed/ {
max9271_write_fail++
print
 }
-- 
2.7.4



[PATCH 3/3] vin-tests: Refactor mc_get_dev

2017-11-15 Thread Kieran Bingham
From: Kieran Bingham 

Rather that using shell parsing of each file when looking for a device
node, use a combination of grep and sed to identify the device.

This is a remarkable speed optimisation for this code segment.

Signed-off-by: Kieran Bingham 
---
 scripts/vin-tests.sh | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/scripts/vin-tests.sh b/scripts/vin-tests.sh
index 7c81aa51c1c5..2e6214bc95e6 100644
--- a/scripts/vin-tests.sh
+++ b/scripts/vin-tests.sh
@@ -99,17 +99,9 @@ mc_get_mdev() {
 }
 
 mc_get_dev() {
-name=$1
-mdev=$(mc_get_mdev)
-
-for dev in  /sys/class/video4linux/*; do
-if [[ "$(cat $dev/name)" == "$name" ]]; then
-basename $dev
-return 0
-fi
-done
-
-error "Can't find device"
+name="$1"
+grep -l "$name" /sys/class/video4linux/video*/name | \
+   sed 's#.*video4linux\(.*\)/name#/dev\1#g'
 }
 
 mc_log() {
-- 
2.7.4



Re: [PATCH v2 1/7] arm64: dts: renesas: r8a7796: Add IPMMU device nodes

2017-11-15 Thread Geert Uytterhoeven
Hi Simon,

On Fri, Nov 10, 2017 at 2:26 PM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Add r8a7796 IPMMU nodes and keep all disabled by default.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 
> ---
> v2 [Simon Horman]
> * Drop mostly redundant comments from nodes
> * Add power domains

Thanks for the update!

With the below fixed:
Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi

[...]

> +   ipmmu_vc0: mmu@fe6b {
> +   compatible = "renesas,ipmmu-r8a7796";
> +   reg = <0 0xfe6b 0 0x1000>;
> +   renesas,ipmmu-main = <_mm 8>;
> +   power-domains = < R8A7796_PD_ALWAYS_ON>;

R8A7796_PD_A3VC

> +   #iommu-cells = <1>;
> +   status = "disabled";
> +   };

[...]

> +   ipmmu_ds0: mmu@e674 {
> +   compatible = "renesas,ipmmu-r8a7796";
> +   reg = <0 0xe674 0 0x1000>;
> +   renesas,ipmmu-main = <_mm 0>;

power-domains = < R8A7796_PD_ALWAYS_ON>;

> +   #iommu-cells = <1>;
> +   status = "disabled";
> +   };

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 RFT] i2c: sh_mobile: make sure to not accidently trigger STOP

2017-11-15 Thread Wolfram Sang
The datasheet was a bit vague, but after consultation with HW designers,
we came to the conclusion that we should set the SCP bit always when
dealing only with the ICE bit. A set SCP bit is ignored, and thus fine,
a cleared one may trigger STOP on the bus.

Signed-off-by: Wolfram Sang 
---

Jacopo: another to test, please. On top of all the other patches. Thank you!

 drivers/i2c/busses/i2c-sh_mobile.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-sh_mobile.c 
b/drivers/i2c/busses/i2c-sh_mobile.c
index 9012d5f8fb38b8..c2841a4f5807c0 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -604,10 +604,10 @@ static int start_ch(struct sh_mobile_i2c_data *pd, struct 
i2c_msg *usr_msg,
 
if (do_init) {
/* Initialize channel registers */
-   iic_wr(pd, ICCR, 0);
+   iic_wr(pd, ICCR, ICCR_SCP);
 
/* Enable channel and configure rx ack */
-   iic_wr(pd, ICCR, ICCR_ICE);
+   iic_wr(pd, ICCR, ICCR_ICE | ICCR_SCP);
 
/* Set the clock */
iic_wr(pd, ICCL, pd->iccl & 0xff);
@@ -723,7 +723,7 @@ static int sh_mobile_i2c_xfer(struct i2c_adapter *adapter,
}
 
/* Disable channel */
-   iic_wr(pd, ICCR, 0);
+   iic_wr(pd, ICCR, ICCR_SCP);
 
/* Disable clock and mark device as idle */
pm_runtime_put_sync(pd->dev);
-- 
2.11.0



Re: [PATCH RFT] mmc: core: use usleep_range rather than HZ magic in mmc_delay()

2017-11-15 Thread Wolfram Sang

> > I did mainly test the insert/eject cycle because powering up the cards
> > seemed to trigger most delays. Transferring data did not cause any calls
> > to mmc_delay() for me. Please let me know if someone knows a test pattern
> > which should be included before applying this change.
> 
> JFTR, with CONFIG_DEBUG_ATOMIC_SLEEP=y, I assume ?
> (also for the other patch)

Actually, no :( Did this now and retested, nothing showed up luckily
(would have been really a surprise, too). Also, added those config
options to the configs in the test branch. Thanks for the pointer,
Geert!



signature.asc
Description: PGP signature


Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

2017-11-15 Thread Sakari Ailus
Hi Jacopo,

Thanks for the patchset. Please see my comments below.

On Wed, Nov 15, 2017 at 11:55:54AM +0100, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..a88e9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,87 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with up 8/16bits data bus 
> width.
> +
> +Required properties:
> +- compatible
> + Must be "renesas,renesas-ceu".
> +- reg
> + Physical address base and size.
> +- interrupts
> + The interrupt line number.
> +- pinctrl-names, pinctrl-0
> + phandle of pin controller sub-node configuring pins for CEU operations.
> +
> +CEU supports a single parallel input and should contain a single 'port' 
> subnode
> +with a single 'endpoint'. Optional endpoint properties applicable to parallel
> +input bus are described in "video-interfaces.txt".

Could you list which ones they are? For someone not familiar with the
parallel bus this might not be obvious; also not all hardware can make use
of every one of these properties.

> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and a
> +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,renesas-ceu";
> + interrupts = ;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <_out>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> + clocks = <>;
> + clock-names = "xclk";
> +
> + xclk: fixed_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2400>;
> + };

What's the purpose of the fixed_clk node here?

> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <_in>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> + };

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi


Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

2017-11-15 Thread Geert Uytterhoeven
Hi Jacopo,

CC devicetree folks

On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
 wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
>
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..a88e9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,87 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with up 8/16bits data bus 
> width.

... with data bus widths up to 8/16 bits?

> +
> +Required properties:
> +- compatible
> +   Must be "renesas,renesas-ceu".

The double "renesas" part looks odd to me. What about "renesas,ceu"?
Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu",
too?

> +- reg
> +   Physical address base and size.
> +- interrupts
> +   The interrupt line number.

interrupt specifier

> +- pinctrl-names, pinctrl-0
> +   phandle of pin controller sub-node configuring pins for CEU 
> operations.
> +
> +CEU supports a single parallel input and should contain a single 'port' 
> subnode
> +with a single 'endpoint'. Optional endpoint properties applicable to parallel
> +input bus are described in "video-interfaces.txt".
> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and a

... an

> +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> +
> +ceu: ceu@e821 {
> +   reg = <0xe821 0x209c>;
> +   compatible = "renesas,renesas-ceu";
> +   interrupts = ;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   status = "okay";
> +
> +   port {
> +   ceu_in: endpoint {
> +   remote-endpoint = <_out>;
> +
> +   bus-width = <8>;
> +   hsync-active = <1>;
> +   vsync-active = <1>;
> +   pclk-sample = <1>;
> +   data-active = <1>;
> +   };
> +   };
> +};
> +
> +i2c1: i2c@fcfee400 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   status = "okay";
> +   clock-frequency = <10>;
> +
> +   ov7670: camera@21 {
> +   compatible = "ovti,ov7670";
> +   reg = <0x21>;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> +   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> +   clocks = <>;
> +   clock-names = "xclk";
> +
> +   xclk: fixed_clk {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <2400>;
> +   };
> +
> +   port {
> +   ov7670_out: endpoint {
> +   remote-endpoint = <_in>;
> +
> +   bus-width = <8>;
> +   hsync-active = <1>;
> +   vsync-active = <1>;
> +   pclk-sample = <1>;
> +   data-active = <1>;
> +   };
> +   };
> +   };
> --
> 2.7.4

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 v1 06/10] sh: sh7722: Rename CEU clock

2017-11-15 Thread Geert Uytterhoeven
Hi Jacopo,

On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
 wrote:
> Rename CEU clock to match the new platform driver name used in Migo-R.
>
> There are no other sh7722 based devices Migo-R apart, so we can safely
> rename this.
>
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c 
> b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> index 8f07a1a..d85091e 100644
> --- a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> +++ b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> @@ -223,7 +223,7 @@ static struct clk_lookup lookups[] = {
> CLKDEV_DEV_ID("sh-vou.0", _clks[HWBLK_VOU]),
> CLKDEV_CON_ID("jpu0", _clks[HWBLK_JPU]),
> CLKDEV_CON_ID("beu0", _clks[HWBLK_BEU]),
> -   CLKDEV_DEV_ID("sh_mobile_ceu.0", _clks[HWBLK_CEU]),
> +   CLKDEV_DEV_ID("renesas-ceu.0", _clks[HWBLK_CEU]),
> CLKDEV_CON_ID("veu0", _clks[HWBLK_VEU]),
> CLKDEV_CON_ID("vpu0", _clks[HWBLK_VPU]),
> CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", _clks[HWBLK_LCDC]),

Shouldn't this be merged with "[PATCH v1 05/10] arch: sh: migor: Use new
renesas-ceu camera driver", to avoid breaking bisection?

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 v1 02/10] include: media: Add Renesas CEU driver interface

2017-11-15 Thread Sakari Ailus
Hi Jacopo,

On Wed, Nov 15, 2017 at 11:55:55AM +0100, Jacopo Mondi wrote:
> Add renesas-ceu header file.
> 
> Do not remove the existing sh_mobile_ceu.h one as long as the original
> driver does not go away.

Hmm. This isn't really not about not removing a file but adding a new one.
Do you really need it outside the driver's own directory?

> 
> Signed-off-by: Jacopo Mondi 
> ---
>  include/media/drv-intf/renesas-ceu.h | 23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 include/media/drv-intf/renesas-ceu.h
> 
> diff --git a/include/media/drv-intf/renesas-ceu.h 
> b/include/media/drv-intf/renesas-ceu.h
> new file mode 100644
> index 000..f2da78c
> --- /dev/null
> +++ b/include/media/drv-intf/renesas-ceu.h
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +#ifndef __ASM_RENESAS_CEU_H__
> +#define __ASM_RENESAS_CEU_H__
> +
> +#include 
> +
> +#define CEU_FLAG_PRIMARY_SENSBIT(0)
> +#define CEU_MAX_SENS 2
> +
> +struct ceu_async_subdev {
> + unsigned long flags;
> + unsigned char bus_width;
> + unsigned char bus_shift;
> + unsigned int i2c_adapter_id;
> + unsigned int i2c_address;
> +};
> +
> +struct ceu_info {
> + unsigned int num_subdevs;
> + struct ceu_async_subdev subdevs[CEU_MAX_SENS];
> +};
> +
> +#endif /* __ASM_RENESAS_CEU_H__ */
> --
> 2.7.4
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi


Re: [PATCH v2] dt-bindings: PCI: rcar: Add device tree support for r8a7743

2017-11-15 Thread Simon Horman
On Tue, Nov 14, 2017 at 09:59:03AM +, Biju Das wrote:
> Add support for r8a7743. The Renesas RZ/G1M(R8A7743)PCIe controller
> is identical to the R-Car Gen2 family.
> 
> No driver change is needed due to the fallback compatible value
> "renesas,pcie-rcar-gen2".
> Adding the SoC-specific compatible values here has three purposes:
> 1. Document which SoCs have this hardware module,
> 2. Allow checkpatch to validate compatible values.
> 3. Allow the driver to support SoC specific implementations in future
>as necessary.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 
> Reviewed-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

> ---
> v1-->v2
>Corrected RZ-G1 to RZ/G1.
> 
>  Documentation/devicetree/bindings/pci/rcar-pci.txt | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt 
> b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index 76ba3a6..1fb614e 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -1,13 +1,15 @@
>  * Renesas R-Car PCIe interface
>  
>  Required properties:
> -compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> +compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC;
> + "renesas,pcie-r8a7779" for the R8A7779 SoC;
>   "renesas,pcie-r8a7790" for the R8A7790 SoC;
>   "renesas,pcie-r8a7791" for the R8A7791 SoC;
>   "renesas,pcie-r8a7793" for the R8A7793 SoC;
>   "renesas,pcie-r8a7795" for the R8A7795 SoC;
>   "renesas,pcie-r8a7796" for the R8A7796 SoC;
> - "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
> + "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 or
> +  RZ/G1 compatible device.
>   "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
>  
>   When compatible with the generic version, nodes must list the
> -- 
> 1.9.1
> 


Re: [RFC v2 2/2] base: dma-mapping: Postpone page_to_pfn() on mmap()

2017-11-15 Thread Robin Murphy

On 14/11/17 17:08, Jacopo Mondi wrote:

On SH4 architecture, with SPARSEMEM memory model, translating page to
pfn hangs the CPU. Post-pone translation to pfn after
dma_mmap_from_dev_coherent() function call as it succeeds and make page
translation not necessary.

This patch was suggested by Laurent Pinchart and he's working to submit
a proper fix mainline. Not sending for inclusion at the moment.


Y'know, I think this patch does have some merit by itself - until we 
know that cpu_addr *doesn't* represent some device-private memory which 
is not guaranteed to be backed by a struct page, calling virt_to_page() 
on it is arguably semantically incorrect, even if it might happen to be 
benign in most cases.


Robin.


Suggested-by: Laurent Pinchart 
Signed-off-by: Jacopo Mondi 
---
  drivers/base/dma-mapping.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index e584edd..73d64d3 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -227,8 +227,8 @@ int dma_common_mmap(struct device *dev, struct 
vm_area_struct *vma,
  #ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
unsigned long user_count = vma_pages(vma);
unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
unsigned long off = vma->vm_pgoff;
+   unsigned long pfn;

vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

@@ -236,6 +236,7 @@ int dma_common_mmap(struct device *dev, struct 
vm_area_struct *vma,
return ret;

if (off < count && user_count <= (count - off)) {
+   pfn = page_to_pfn(virt_to_page(cpu_addr));
ret = remap_pfn_range(vma, vma->vm_start,
  pfn + off,
  user_count << PAGE_SHIFT,
--
2.7.4

___
iommu mailing list
io...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu



Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

2017-11-15 Thread Sakari Ailus
Hi Jacopo,

Could you remove the original driver and send the patch using git
send-email -C ? That way a single patch would address converting it to a
proper V4L2 driver as well as move it to the correct location. The changes
would be easier to review that way since then, well, it'd be easier to see
the changes. :-)

The same goes for the two V4L2 SoC camera sensor / video decoder drivers at
the end of the set.

On Wed, Nov 15, 2017 at 11:55:56AM +0100, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
> 
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
> 
> This driver aims to replace the soc_camera based sh_mobile_ceu one.
> 
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
> 
> Tested with ov7725 camera sensor on SH4 platform Migo-R.

Nice!

> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/Kconfig   |9 +
>  drivers/media/platform/Makefile  |2 +
>  drivers/media/platform/renesas-ceu.c | 1768 
> ++
>  3 files changed, 1779 insertions(+)
>  create mode 100644 drivers/media/platform/renesas-ceu.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3c4f7fa..401caea 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
> To compile this driver as a module, choose M here: the module
> will be called stm32-dcmi.
> 
> +config VIDEO_RENESAS_CEU
> + tristate "Renesas Capture Engine Unit (CEU) driver"
> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_FWNODE
> + ---help---
> +   This is a v4l2 driver for the Renesas CEU Interface
> +
>  source "drivers/media/platform/soc_camera/Kconfig"
>  source "drivers/media/platform/exynos4-is/Kconfig"
>  source "drivers/media/platform/am437x/Kconfig"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 327f80a..0d1f02b 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA)+= coda/
> 
>  obj-$(CONFIG_VIDEO_SH_VEU)   += sh_veu.o
> 
> +obj-$(CONFIG_VIDEO_RENESAS_CEU)  += renesas-ceu.o
> +
>  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)  += m2m-deinterlace.o
> 
>  obj-$(CONFIG_VIDEO_MUX)  += video-mux.o
> diff --git a/drivers/media/platform/renesas-ceu.c 
> b/drivers/media/platform/renesas-ceu.c
> new file mode 100644
> index 000..aaba3cd
> --- /dev/null
> +++ b/drivers/media/platform/renesas-ceu.c
> @@ -0,0 +1,1768 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
> + *
> + * Copyright (C) 2017 Jacopo Mondi 
> + *
> + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
> + * Copyright (C) 2008 Magnus Damm
> + *
> + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
> + * Copyright (C) 2006, Sascha Hauer, Pengutronix
> + * Copyright (C) 2008, Guennadi Liakhovetski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 

Do you need this header? There would seem some that I wouldn't expect to be
needed below, such as linux/init.h.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define DRIVER_NAME  "renesas-ceu"
> +
> +/* 
> 
> + * CEU registers offsets and masks
> + */
> +#define CEU_CAPSR0x00 /* Capture start register  */
> +#define CEU_CAPCR0x04 /* Capture control register*/
> +#define CEU_CAMCR0x08 /* Capture interface control register  */
> +#define CEU_CAMOR0x10 /* Capture interface offset register   */
> +#define CEU_CAPWR0x14 /* Capture interface width register*/
> +#define CEU_CAIFR0x18 /* Capture interface input format register */
> +#define CEU_CRCNTR   0x28 /* CEU register control register   */
> +#define CEU_CRCMPR   0x2c /* CEU register forcible control register  */
> +#define CEU_CFLCR0x30 /* Capture filter control register */
> +#define CEU_CFSZR0x34 /* Capture filter size 

Re: [PATCH V2 5/5] PCI: rcar: Add the suspend/resume for pcie-rcar driver

2017-11-15 Thread Simon Horman
On Fri, Nov 10, 2017 at 10:58:43PM +0100, Marek Vasut wrote:
> From: Kazufumi Ikeda 
> 
> This adds the suspend/resume supports for pcie-rcar. The resume handler
> reprograms the hardware based on the software state kept in specific
> device structures. Also it doesn't need to save any registers.
> 
> Signed-off-by: Kazufumi Ikeda 
> Signed-off-by: Gaku Inami 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org

Acked-by: Simon Horman 



Re: [PATCH V2 2/5] PCI: rcar: Clean up the macros

2017-11-15 Thread Simon Horman
On Mon, Nov 13, 2017 at 07:11:54PM +0100, Marek Vasut wrote:
> On 11/13/2017 08:03 AM, Simon Horman wrote:
> > On Fri, Nov 10, 2017 at 10:58:40PM +0100, Marek Vasut wrote:
> >> Just clean up the macros in the RCar PCI driver, no functional change.
> > 
> > Could you describe the cleanup in slightly more detail?
> > My reading is 1. Use BIT() macro 2. tidy up whitespace.
> > 
> That's all there is, indeed.

Right, but I'd rather that the changelog be expanded to include that
information. With that fixed feel free to add:

Acked-by: Simon Horman 



Re: [PATCH 1/2] serial: sh-sci: Support for variable HSCIF hardware RX timeout

2017-11-15 Thread Wolfram Sang
On Fri, Sep 29, 2017 at 03:08:53PM +0200, Ulrich Hecht wrote:
> HSCIF has facilities that allow changing the timeout after which an RX
> interrupt is triggered even if the FIFO is not filled. This patch allows
> changing the default (15 bits of silence) using the existing sysfs
> attribute "rx_fifo_timeout".
> 
> Signed-off-by: Ulrich Hecht 

Can't this patch be resent independently of the other? With Geert's tag
added?



signature.asc
Description: PGP signature


[PATCH 2/6] i2c: rcar: enable for R-Car D3 (r8a77995)

2017-11-15 Thread Ulrich Hecht
Same as other Gen3 SoCs.

Signed-off-by: Ulrich Hecht 
---
 drivers/i2c/busses/i2c-rcar.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 15d764a..9469f01 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -809,6 +809,7 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
{ .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
+   { .compatible = "renesas,i2c-r8a77995", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
/* Deprecated */
{ .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 
},
{ .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 
},
-- 
2.7.4



[PATCH 3/6] arm64: renesas: r8a77995: add I2C support

2017-11-15 Thread Ulrich Hecht
Defines R-Car D3 I2C controllers 0-3.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 5fa7572..b3113003 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -400,6 +400,70 @@
status = "disabled";
};
 
+   i2c0: i2c@e650 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a77995",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe650 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 931>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 931>;
+   dmas = < 0x91>, < 0x90>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <110>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@e6508000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a77995",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe6508000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 930>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 930>;
+   dmas = < 0x93>, < 0x92>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@e651 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a77995",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe651 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 929>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 929>;
+   dmas = < 0x95>, < 0x94>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@e66d {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a77995",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe66d 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 928>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 928>;
+   dmas = < 0x97>, < 0x96>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <110>;
+   status = "disabled";
+   };
+
pwm0: pwm@e6e3 {
compatible = "renesas,pwm-r8a77995", "renesas,pwm-rcar";
reg = <0 0xe6e3 0 0x8>;
-- 
2.7.4



[PATCH 0/6] R-Car D3 (r8a77995) I2C integration

2017-11-15 Thread Ulrich Hecht
Hi!

This adds I2C controllers to the D3 device tree and enables I2C busses 0
and 1 on the Draak board. (I2C2 is not connected on that board.)

Includes missing pins, DMA support and the Draak's serial EEPROM.

CU
Uli


Ulrich Hecht (6):
  pinctrl: sh-pfc: r8a77995: add missing pins SCL0 and SDA0 to pinmux
data
  i2c: rcar: enable for R-Car D3 (r8a77995)
  arm64: renesas: r8a77995: add I2C support
  arm64: renesas: draak: enable I2C controller 0 and EEPROM
  arm64: renesas: draak: enable I2C controller 1
  i2c: rcar: document R8A77970 bindings

 Documentation/devicetree/bindings/i2c/i2c-rcar.txt |  1 +
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 28 ++
 arch/arm64/boot/dts/renesas/r8a77995.dtsi  | 64 ++
 drivers/i2c/busses/i2c-rcar.c  |  1 +
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c  |  2 +
 5 files changed, 96 insertions(+)

-- 
2.7.4



[PATCH 5/6] arm64: renesas: draak: enable I2C controller 1

2017-11-15 Thread Ulrich Hecht
No devices to add, I2C1 has an external connector only.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 64a6339..91f247f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -51,6 +51,11 @@
function = "i2c0";
};
 
+   i2c1_pins: i2c1 {
+   groups = "i2c1";
+   function = "i2c1";
+   };
+
pwm0_pins: pwm0 {
groups = "pwm0_c";
function = "pwm0";
@@ -84,6 +89,12 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.7.4



[PATCH 1/3] arm64: dts: r8a77995: add SYS-DMAC nodes

2017-11-15 Thread Ulrich Hecht
Differs from other Gen3 SoCs in that each controller only supports eight
channels.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 72 +++
 1 file changed, 72 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 788e3af..04a392a 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -155,6 +155,78 @@
resets = < 407>;
};
 
+   dmac0: dma-controller@e670 {
+   compatible = "renesas,dmac-r8a77995",
+"renesas,rcar-dmac";
+   reg = <0 0xe670 0 0x1>;
+   interrupts = ;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7";
+   clocks = < CPG_MOD 219>;
+   clock-names = "fck";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 219>;
+   #dma-cells = <1>;
+   dma-channels = <8>;
+   };
+
+   dmac1: dma-controller@e730 {
+   compatible = "renesas,dmac-r8a77995",
+"renesas,rcar-dmac";
+   reg = <0 0xe730 0 0x1>;
+   interrupts = ;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7";
+   clocks = < CPG_MOD 218>;
+   clock-names = "fck";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 218>;
+   #dma-cells = <1>;
+   dma-channels = <8>;
+   };
+
+   dmac2: dma-controller@e731 {
+   compatible = "renesas,dmac-r8a77995",
+"renesas,rcar-dmac";
+   reg = <0 0xe731 0 0x1>;
+   interrupts = ;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7";
+   clocks = < CPG_MOD 217>;
+   clock-names = "fck";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 217>;
+   #dma-cells = <1>;
+   dma-channels = <8>;
+   };
+
gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a77995",
 "renesas,rcar-gen3-gpio",
-- 
2.7.4



[PATCH 2/3] arm64: dts: r8a7795: add DMA for SCIF2

2017-11-15 Thread Ulrich Hecht
Tested on Draak.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 04a392a..5fa7572 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -393,6 +393,8 @@
 < CPG_CORE R8A77995_CLK_S3D1C>,
 <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x13>, < 0x12>;
+   dma-names = "tx", "rx";
power-domains = < R8A77995_PD_ALWAYS_ON>;
resets = < 310>;
status = "disabled";
-- 
2.7.4



[PATCH 4/6] arm64: renesas: draak: enable I2C controller 0 and EEPROM

2017-11-15 Thread Ulrich Hecht
Enables EEPROM on I2C0 on the Draak board.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 09de73b..64a6339 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -46,6 +46,11 @@
};
};
 
+   i2c0_pins: i2c0 {
+   groups = "i2c0";
+   function = "i2c0";
+   };
+
pwm0_pins: pwm0 {
groups = "pwm0_c";
function = "pwm0";
@@ -67,6 +72,18 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   eeprom@50 {
+   compatible = "atmel,24c01";
+   reg = <0x50>;
+   pagesize = <8>;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4



[PATCH 0/3] R-Car D3 (r8a77995) SYS-DMAC integration

2017-11-15 Thread Ulrich Hecht
Hi!

This adds DT nodes and bindings for the SYS-DMAC on R-Car D3 and enables
the DMAs for SCIF2.

CU
Uli


Ulrich Hecht (3):
  arm64: dts: r8a77995: add SYS-DMAC nodes
  arm64: dts: r8a7795: add DMA for SCIF2
  dmaengine: rcar-dmac: Document R-Car D3 bindings

 .../devicetree/bindings/dma/renesas,rcar-dmac.txt  |  1 +
 arch/arm64/boot/dts/renesas/r8a77995.dtsi  | 74 ++
 2 files changed, 75 insertions(+)

-- 
2.7.4



[PATCH 1/6] pinctrl: sh-pfc: r8a77995: add missing pins SCL0 and SDA0 to pinmux data

2017-11-15 Thread Ulrich Hecht
Required for I2C0 operation.

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

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
index 89b7541..2c9a71a 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
@@ -518,6 +518,8 @@ static const u16 pinmux_data[] = {
PINMUX_SINGLE(QSPI0_MISO_IO1),
PINMUX_SINGLE(QSPI0_MOSI_IO0),
PINMUX_SINGLE(QSPI0_SPCLK),
+   PINMUX_SINGLE(SCL0),
+   PINMUX_SINGLE(SDA0),
 
/* IPSR0 */
PINMUX_IPSR_MSEL(IP0_3_0,   IRQ0_A, SEL_IRQ_0_0),
-- 
2.7.4



[PATCH 3/3] dmaengine: rcar-dmac: Document R-Car D3 bindings

2017-11-15 Thread Ulrich Hecht
R8A77995's SYS-DMAC is R-Car Gen3-compatible.

Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt 
b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
index 891db41..af071ed 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
@@ -26,6 +26,7 @@ Required Properties:
- "renesas,dmac-r8a7795" (R-Car H3)
- "renesas,dmac-r8a7796" (R-Car M3-W)
- "renesas,dmac-r8a77970" (R-Car V3M)
+   - "renesas,dmac-r8a77995" (R-Car D3)
 
 - reg: base address and length of the registers block for the DMAC
 
-- 
2.7.4



[PATCH] v4l: async: use the v4l2_dev from the root notifier when matching sub-devices

2017-11-15 Thread Niklas Söderlund
When matching and registering a sub-device from a sub-notifier use the
v4l2_device from the root parent notifier. Using the v4l2_dev stored in
the sub-notifier itself is incorrect as it might not be set.

This can be demonstrated by unbinding and rebinding the adv748x driver
and observing that it fails to probe due to the check !v4l2_dev in
v4l2_device_register_subdev().

# echo 4-0070 > /sys/bus/i2c/drivers/adv748x/unbind
# echo 4-0070 > /sys/bus/i2c/drivers/adv748x/bind
adv748x 4-0070: chip found @ 0xe0 revision 2143
adv748x 4-0070: Failed to probe TXA
adv748x: probe of 4-0070 failed with error -22

Looking at the commit which adds sub-notifiers to V4L2 it looks like
this is the intended behavior of the original commit. Whit this fix the
adv748x can be re-bound and still function properly.

Fixes: 2cab00bb076b9f0e ("media: v4l: async: Allow binding notifiers to 
sub-devices")
Signed-off-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-async.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index a7c3464976f24361..e5acfab470a5ee6b 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -558,8 +558,7 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
if (!asd)
continue;
 
-   ret = v4l2_async_match_notify(notifier, notifier->v4l2_dev, sd,
- asd);
+   ret = v4l2_async_match_notify(notifier, v4l2_dev, sd, asd);
if (ret)
goto err_unbind;
 
-- 
2.15.0



Re: [PATCH 2/2] serial: sh-sci: Support for HSCIF RX sampling point adjustment

2017-11-15 Thread Wolfram Sang
On Fri, Sep 29, 2017 at 03:08:54PM +0200, Ulrich Hecht wrote:
> HSCIF has facilities that allow moving the RX sampling point by between
> -8 and 7 sampling cycles (one sampling cycles equals 1/15 of a bit
> by default) to improve the error margin in case of slightly mismatched
> bit rates between sender and receiver.
> 
> This patch allows changing the default (0, meaning center) using the
> sysfs attribute "rx_sampling_point".
> 
> Signed-off-by: Ulrich Hecht 

Wasn't there a conclusion in a chat meeting we had how to move this
forward? How much effort would be implementing that?



signature.asc
Description: PGP signature


[PATCH 2/4] arm64: dts: r8a77995: Add SDHI (MMC) support

2017-11-15 Thread Ulrich Hecht
R-Car D3 has only one SDHI controller.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index b3113003..89cb32e 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -504,6 +504,18 @@
status = "disabled";
};
 
+   sdhi2: sd@ee14 {
+   compatible = "renesas,sdhi-r8a77995",
+"renesas,rcar-gen3-sdhi";
+   reg = <0 0xee14 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 312>;
+   max-frequency = <2>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 312>;
+   status = "disabled";
+   };
+
ehci0: usb@ee080100 {
compatible = "generic-ehci";
reg = <0 0xee080100 0 0x100>;
-- 
2.7.4



[PATCH 0/4] R-Car D3 (r8a77995) SDHI (eMMC) integration

2017-11-15 Thread Ulrich Hecht
Hi!

This integrates the SDHI hardware on R-Car D3 and enables the Draak board's
eMMC drive. Includes whitelisting the internal DMAC on D3.

CU
Uli


Ulrich Hecht (4):
  mmc: renesas_sdhi: enable R-Car D3 (r8a77995) support
  arm64: dts: r8a77995: Add SDHI (MMC) support
  arm64: dts: r8a77995: draak: enable SDHI2
  dt-bindings: mmc: renesas_sdhi: Add r8a77995 support

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 44 ++
 arch/arm64/boot/dts/renesas/r8a77995.dtsi  | 12 ++
 drivers/mmc/host/renesas_sdhi_internal_dmac.c  |  2 +
 4 files changed, 59 insertions(+)

-- 
2.7.4



[PATCH 4/4] dt-bindings: mmc: renesas_sdhi: Add r8a77995 support

2017-11-15 Thread Ulrich Hecht
Adds bindings for the R-Car D3 SoC's SDHI IP.

Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt 
b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 3c67624..d8685cb 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -26,6 +26,7 @@ Required properties:
"renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
"renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
"renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC
+   "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC
"renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller
"renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller
"renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 or RZ/G1
-- 
2.7.4



[PATCH 3/4] arm64: dts: r8a77995: draak: enable SDHI2

2017-11-15 Thread Ulrich Hecht
The single SDHI controller is connected to eMMC.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 91f247f..cd3823b 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -32,6 +32,24 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x1800>;
};
+
+   reg_1p8v: regulator0 {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator1 {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
 };
 
 _clk {
@@ -71,6 +89,18 @@
function = "scif2";
};
 
+   sdhi2_pins: sd2 {
+   groups = "mmc_data8", "mmc_ctrl";
+   function = "mmc";
+   power-source = <3300>;
+   };
+
+   sdhi2_pins_uhs: sd2_uhs {
+   groups = "mmc_data8", "mmc_ctrl";
+   function = "mmc";
+   power-source = <1800>;
+   };
+
usb0_pins: usb0 {
groups = "usb0";
function = "usb0";
@@ -125,6 +155,20 @@
status = "okay";
 };
 
+ {
+   /* used for on-board eMMC */
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
+
+   vmmc-supply = <_3p3v>;
+   vqmmc-supply = <_1p8v>;
+   bus-width = <8>;
+   mmc-hs200-1_8v;
+   non-removable;
+   status = "okay";
+};
+
 _phy0 {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.7.4



[PATCH 6/6] i2c: rcar: document R8A77970 bindings

2017-11-15 Thread Ulrich Hecht
R-Car D3 (R8A77995) SoC has a R-Car Gen3-compatible I2C controller.

Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt 
b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index a777477..e91dbaf 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -14,6 +14,7 @@ Required properties:
"renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
"renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
"renesas,i2c-r8a77970" if the device is a part of a R8A77970 SoC.
+   "renesas,i2c-r8a77995" if the device is a part of a R8A77995 SoC.
"renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible
device.
-- 
2.7.4



[PATCH 1/4] mmc: renesas_sdhi: enable R-Car D3 (r8a77995) support

2017-11-15 Thread Ulrich Hecht
Adds compatible string and whitelists for internal DMAC implementation.

Signed-off-by: Ulrich Hecht 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 41cbe84..f16d8f4 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -88,6 +88,7 @@ static const struct renesas_sdhi_of_data 
of_rcar_gen3_compatible = {
 static const struct of_device_id renesas_sdhi_internal_dmac_of_match[] = {
{ .compatible = "renesas,sdhi-r8a7795", .data = 
_rcar_gen3_compatible, },
{ .compatible = "renesas,sdhi-r8a7796", .data = 
_rcar_gen3_compatible, },
+   { .compatible = "renesas,sdhi-r8a77995", .data = 
_rcar_gen3_compatible, },
{ .compatible = "renesas,rcar-gen3-sdhi", .data = 
_rcar_gen3_compatible, },
{},
 };
@@ -255,6 +256,7 @@ static const struct soc_device_attribute 
gen3_soc_whitelist[] = {
 { .soc_id = "r8a7795", .revision = "ES1.*" },
 { .soc_id = "r8a7795", .revision = "ES2.0" },
 { .soc_id = "r8a7796", .revision = "ES1.0" },
+{ .soc_id = "r8a77995", .revision = "*" },
 { /* sentinel */ }
 };
 
-- 
2.7.4



Re: [PATCH 1/2] serial: sh-sci: Support for variable HSCIF hardware RX timeout

2017-11-15 Thread Wolfram Sang

> No need to resend, see commit fa2abb03637a5528 ("serial: sh-sci: Support
> for variable HSCIF hardware RX timeout") in today's upstream.

In deed. Nice!



signature.asc
Description: PGP signature


Re: [PATCH v2 2/2] pinctrl: sh-pfc: r8a7791: Add can_clk function

2017-11-15 Thread Geert Uytterhoeven
Hi Fabrizio,

On Tue, Nov 14, 2017 at 4:41 PM, Fabrizio Castro
 wrote:
> This patch adds can_clk function to r8a7743/r8a7791 which is cleaner,
> and allows for independent configuration.
> We keep the can_clk* pins definitions from within can0_groups and
> can1_groups for uniformity and backwards compatibility.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Ramesh Shanmugasundaram 
> ---
> v1->v2
> * Retained can_clk* pins inside can[01]_groups
> * Added comments

Thanks for the update!

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.16.

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 3/3] arm64: dts: renesas: eagle: add EtherAVB pins

2017-11-15 Thread Geert Uytterhoeven
Hi Sergei,

On Tue, Nov 14, 2017 at 7:00 PM, Sergei Shtylyov
 wrote:
> On 11/14/2017 11:44 AM, Geert Uytterhoeven wrote:
>>> Add the (previously omitted) EtherAVB pin data to the Eagle board's
>>> device tree.

>>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
>>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
>>> @@ -34,6 +34,9 @@
>
> [...]
>>>
>>> @@ -53,6 +56,11 @@
>>>   };
>>>
>>>{
>>> +   avb_pins: avb {
>>> +   groups = "avb0_mdio", "avb0_mii";
>>
>>
>> Oh no, its'called "avb0_mdio" here, but "avb(0)_mdc" on all other
>> R-Car Gen3 SoCs?
>
>
>Can you remember the reason? I don;t want to follow the bad example. :-)

Sorry, I don't know.

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 2/3] tools: 8camera-status: Expand to 9 cameras

2017-11-15 Thread Niklas Söderlund
Hi Kieran,

Thanks for your patch, applied.

On 2017-11-15 14:38:30 +, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The 8th camera has an address conflict on the Salvator-X.
> As such it has been moved to the right by one address,
> Include this '9th' camera in the reporting status
> 
> Signed-off-by: Kieran Bingham 
> ---
>  tools/8camera-status | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/8camera-status b/tools/8camera-status
> index cdfe76ef286f..846673578f09 100755
> --- a/tools/8camera-status
> +++ b/tools/8camera-status
> @@ -1,7 +1,7 @@
>  #!/usr/bin/awk -f
>  
>  BEGIN {
> - for (x = 0; x <= 8; x++)
> + for (x = 0; x <= 9; x++)
>   cameras[x] = "-"
>  }
>  
> @@ -67,15 +67,15 @@ function ParseProbe ( line )
>  
>  function PrintCameras()
>  {
> - print ""
> - print "| 1 | 2 | 3 | 4 |  | 5 | 6 | 7 | 8 |"
> - for (x=1; x <= 8; x++) {
> + print ""
> + print "| 1 | 2 | 3 | 4 |  | 5 | 6 | 7 | 8 | 9 |"
> + for (x=1; x <= 9; x++) {
>   printf "| " cameras[x] " "
>   if (x == 4)
>   printf("|  ")
>   }
>   printf "|\n"
> - print ""
> + print "==="
>  }
>  
>  function Summarise() {
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund


Re: [PATCH] arm64: dts: renesas: ulcb-kf: add pfc node for USB3.0 channel 0

2017-11-15 Thread Geert Uytterhoeven
Hi Vladimir,

On Wed, Nov 8, 2017 at 2:06 PM, Vladimir Barinov
 wrote:
> Adds the pfc node for USB3.0 channel 0.
>
> Signed-off-by: Vladimir Barinov 
> ---
>  arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi 
> b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> index 48a2e8f..2ecb6ac 100644
> --- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> @@ -173,6 +173,11 @@
> groups = "usb0";
> function = "usb0";
> };
> +
> +   usb30_pins: usb30 {
> +   groups = "usb30";
> +   function = "usb30";

This enabled USB30_PWEN and USB30_OVC.

However, these pins are routed via CN1A pins A97/A98 to HDMI_CS_A
and HDMI_CS_B, not to a USB PHY?

USB30_PWEN of the real USB PHY is provided by the i2c GPIO
expander U11.

I'm a bit puzzled by this... What am I missing?

> +   };
>  };
>
>   {
> @@ -191,5 +196,8 @@
>  };
>
>   {
> +   pinctrl-0 = <_pins>;
> +   pinctrl-names = "default";
> +
> status = "okay";
>  };

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] arm64: dts: ulcb-kf: add dr_mode property for USB2.0 channel 0

2017-11-15 Thread Geert Uytterhoeven
On Wed, Nov 8, 2017 at 2:09 PM, Vladimir Barinov
 wrote:
> ULCB-KF has a USB2.0 dual-role channel (CN13).
> This adds dr_mode property for USB2.0 channel 0 (EHCI/OHCI and HS-USB)
> as "otg".
>
> Signed-off-by: Vladimir Barinov 

Reviewed-by: Geert Uytterhoeven 

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/2] arm64: dts: renesas: r8a77970: add GPIO support

2017-11-15 Thread Geert Uytterhoeven
On Mon, Nov 13, 2017 at 10:23 PM, Sergei Shtylyov
 wrote:
> Describe all 6 GPIO controllers in the R8A77970 device tree.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 

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 2/2] arm64: dts: renesas: eagle: specify EtherAVB PHY IRQ

2017-11-15 Thread Geert Uytterhoeven
On Mon, Nov 13, 2017 at 10:23 PM, Sergei Shtylyov
 wrote:
> Specify  EtherAVB PHY IRQ  in the Eagle board's device tree, now that we
> have the GPIO support (previously phylib had to resort to polling).
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 

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 v2 1/2] pinctrl: sh-pfc: r8a7794: Add can_clk function

2017-11-15 Thread Geert Uytterhoeven
Hi Fabrizio,

On Tue, Nov 14, 2017 at 4:41 PM, Fabrizio Castro
 wrote:
> This patch adds can_clk function to r8a7745/r8a7794 which is cleaner,
> and allows for independent configuration.
> We keep the can_clk* pins definitions from within can0_groups and
> can1_groups for uniformity and backwards compatibility.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Ramesh Shanmugasundaram 
> ---
> v1->v2
> * Retained can_clk* pins inside can[01]_groups
> * Added comments

Thanks for the update!

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.16.

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/3] tools: 8camera-status: Fix write failure mis-allocations

2017-11-15 Thread Niklas Söderlund
Hi Kieran,

Thanks for your patch, applied.

On 2017-11-15 14:38:29 +, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Debug prints of the max9271_write call are appearing in the failure counts.
> 
> Fix the 'catcher' so that it is more specific to the failure
> 
> Signed-off-by: Kieran Bingham 
> ---
>  tools/8camera-status | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/8camera-status b/tools/8camera-status
> index 234b8a0cab2b..cdfe76ef286f 100755
> --- a/tools/8camera-status
> +++ b/tools/8camera-status
> @@ -21,7 +21,7 @@ BEGIN {
>   print
>  }
>  
> -/max9271_write/ {
> +/max9271_write.*write failed/ {
>   max9271_write_fail++
>   print
>  }
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund


Re: [PATCH v2] arm64: dts: ulcb-kf: enable USB2 PHY of channel 0

2017-11-15 Thread Geert Uytterhoeven
Hi Vladimir,

On Wed, Nov 8, 2017 at 1:21 PM, Vladimir Barinov
 wrote:
> This supports USB2 PHY channel #0 on ULCB Kingfisher board
>
> The dedicated USB0_PWEN pin is used to control CN13 VBUS source from U43
> power supply.
> MAX3355 can also provide VBUS, hence it should be disabled via OTG_OFFVBUSn
> node coming from gpio expander TCA9539.
> Set MAX3355 enabled using OTG_EXTLPn node to be able to read OTG ID of CN13.
>
> Signed-off-by: Vladimir Barinov 
> ---
> Changes in version 2:
> - added gpio hogs for MAX3355 VBUS and SHDN

Thanks for the update!

Reviewed-by: Geert Uytterhoeven 

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 3/3] vin-tests: Refactor mc_get_dev

2017-11-15 Thread Niklas Söderlund
Hi Kieran,

Thanks for your patch.

Unfortunately I experience some problems with this patch.

On 2017-11-15 14:38:31 +, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Rather that using shell parsing of each file when looking for a device
> node, use a combination of grep and sed to identify the device.
> 
> This is a remarkable speed optimisation for this code segment.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  scripts/vin-tests.sh | 14 +++---
>  1 file changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/scripts/vin-tests.sh b/scripts/vin-tests.sh
> index 7c81aa51c1c5..2e6214bc95e6 100644
> --- a/scripts/vin-tests.sh
> +++ b/scripts/vin-tests.sh
> @@ -99,17 +99,9 @@ mc_get_mdev() {
>  }
>  
>  mc_get_dev() {
> -name=$1
> -mdev=$(mc_get_mdev)
> -
> -for dev in  /sys/class/video4linux/*; do
> -if [[ "$(cat $dev/name)" == "$name" ]]; then
> -basename $dev
> -return 0
> -fi
> -done
> -
> -error "Can't find device"
> +name="$1"
> +grep -l "$name" /sys/class/video4linux/video*/name | \
> + sed 's#.*video4linux\(.*\)/name#/dev\1#g'

The only user of mc_get_dev() is the set-edid utility, which uses it to 
find the adv748x HDMI subdevice (adv748x 4-0070 hdmi) so it can program 
the EDID. I had to change search path above to 
/sys/class/video4linux/*/name to also searches in v4l-subdevX 
directories to find thatt device.

Also the return value changes from 'v4l-subdev42' to /dev/v4l-subdev42' 
so the set-edid tool needed a small update to handle that :-)

I have applied this patch as-is, and then a followup which takes care of 
the above. Out of curiosity, are you working on any new tests which uses 
mc_get_dev()?

>  }
>  
>  mc_log() {
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund


Re: [PULL REQUEST] renesas/topic/mmc-delay-refactor-for-geert for renesas drivers

2017-11-15 Thread Geert Uytterhoeven
Hi Wolfram,

On Wed, Nov 15, 2017 at 12:06 AM, Wolfram Sang  wrote:
> here is a topic branch for renesas-drivers removing calls to udelay() in
> both, TMIO core and the MMC core itself. I hope they land upstream in
> v4.16. Would be nice to get them boot tested via renesas-drivers. The
> test page can be found here:
>
> https://elinux.org/Tests:mmc-delay-refactor
>
> The branch is based on mmc/next (which should be soon in v4.15-rc1).
>
> Thanks and kind regards,
>
>Wolfram
>
>
> The following changes since commit 06641e8deae68ee2769c734158bc9170be257bb9:
>
>   sdhci-fujitsu: add support for setting the CMD_DAT_DELAY attribute 
> (2017-11-07 13:43:23 +0100)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
> renesas/topic/mmc-delay-refactor-for-geert
>
> for you to fetch changes up to edfceba9d1b241e5258e80f997bb5579a5dea895:
>
>   mmc: core: use usleep_range rather than HZ magic in mmc_delay() (2017-11-14 
> 23:47:24 +0100)

Thanks, looks good to me.

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: [GIT PULL FOR renesas-drivers] R-Car DU IOMMU

2017-11-15 Thread Geert Uytterhoeven
Hi Laurent,

On Wed, Nov 15, 2017 at 8:13 AM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
> The following changes since commit d65d31388a23b14df9494135ad6c6549a59a3caa:
>
>   Merge tag 'drm-misc-next-fixes-2017-11-07' of git://anongit.freedesktop.org/
> drm/drm-misc into drm-next (2017-11-08 05:22:49 +1000)
>
> are available in the git repository at:
>
>   git://linuxtv.org/pinchartl/media.git drm-du-iommu-v1-20171115
>
> for you to fetch changes up to 6cb711c0fabae1101bfde1c8dce0dfd992822f6b:
>
>   drm: rcar-du: Allow importing non-contiguous dma-buf with VSP (2017-11-15
> 09:00:43 +0200)

Thanks, looks good to me.

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