RE: [PATCH] dmaengine: usb-dmac: Add soctype for R-Car M3-W

[Yoshihiro Shimoda]

Hi Rob,

> From: Rob Herring
> Sent: Friday, August 11, 2017 1:26 AM
> 
> On Wed, Aug 02, 2017 at 08:33:34PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds R-Car M3-W device tree bindings for usb-dmac driver.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Acked-by: Rob Herring 

Thank you for your Acked-by!

Hi, Vinod,

I checked your next branch today, but it doesn't have this patch.
So, would you apply this patch into your repo?

Best regards,
Yoshihiro Shimoda

[PATCH] serial: sh-sci: document R8A7797 bindings

[Sergei Shtylyov]

R-Car V3M (R8A7797) SoC also has the R-Car gen3 compatible SCIF and HSCIF
ports, so document the SoC specific bindings.

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'tty-next' branch of GregKH's 'tty.git' repo.

 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt |2 ++
 1 file changed, 2 insertions(+)

Index: tty/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
===
--- tty.orig/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ tty/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -41,6 +41,8 @@ Required properties:
 - "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART.
 - "renesas,scif-r8a7796" for R8A7796 (R-Car M3-W) SCIF compatible UART.
 - "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART.
+- "renesas,scif-r8a7797" for R8A7797 (R-Car V3M) SCIF compatible UART.
+- "renesas,hscif-r8a7797" for R8A7797 (R-Car V3M) HSCIF compatible UART.
 - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART.
 - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART.
 - "renesas,rcar-gen1-scif" for R-Car Gen1 SCIF compatible UART,

Re: [PATCH] dmaengine: rcar-dmac: document R8A7797 bindings

[Sergei Shtylyov]

On 08/24/2017 10:56 PM, Sergei Shtylyov wrote:


Renesas  R-Car V3M (R8A7797) SoC also has the R-Car gen2/3 compatible DMA

 ^^
   Oops, didn't notice the double space. Could be fixed while applying, I 
guess (I know Rob will be upset about double spaces)?



controllers, so document the SoC specific binding.

Signed-off-by: Sergei Shtylyov 

[...]

MBR, Sergei

[PATCH] dmaengine: rcar-dmac: document R8A7797 bindings

[Sergei Shtylyov]

Renesas  R-Car V3M (R8A7797) SoC also has the R-Car gen2/3 compatible DMA
controllers, so document the SoC specific binding.

Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'next' branch of Vinod Koul's 'slave-dma.git' repo.
 
 Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt |1 +
 1 file changed, 1 insertion(+)

Index: slave-dma/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
===
--- slave-dma.orig/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
+++ slave-dma/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
@@ -25,6 +25,7 @@ Required Properties:
- "renesas,dmac-r8a7794" (R-Car E2)
- "renesas,dmac-r8a7795" (R-Car H3)
- "renesas,dmac-r8a7796" (R-Car M3-W)
+   - "renesas,dmac-r8a7797" (R-Car V3M)
 
 - reg: base address and length of the registers block for the DMAC
 

Re: [PATCH 2/4] v4l: async: abort if memory allocation fails when unregistering notifiers

[Sakari Ailus]

Hi Niklas,

On Mon, Jul 31, 2017 at 12:31:56AM +0200, Niklas Söderlund wrote:
> Instead of trying to cope with the failed memory allocation and still
> leaving the kernel in a semi-broken state (the subdevices will be
> released but never re-probed) simply abort. The kernel have already
> printed a warning about allocation failure but keep the error printout
> to ease pinpointing the problem if it happens.
> 
> By doing this we can increase the readability of this complex function
> which puts it in a better state to separate the v4l2 housekeeping tasks
> from the re-probing of devices. It also serves to prepare for adding
> subnotifers.

By the time the notifier has been removed from the notifier list, we're the
sole user of the notifier done list. There is thus no need to acquire the
list lock to serialise access to that list.

Is there something that prevents re-probing the devices directly off the
notifier's done list without gathering the device pointers first? As the
notifier has been removed from the notifier list already, there will be no
matches found.

> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 0acf288d7227ba97..67852f0f2d3000c9 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -215,6 +215,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   if (!dev) {
>   dev_err(notifier->v4l2_dev->dev,
>   "Failed to allocate device cache!\n");
> + return;
>   }
>  
>   mutex_lock(_lock);
> @@ -234,23 +235,13 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   /* If we handled USB devices, we'd have to lock the parent too 
> */
>   device_release_driver(d);
>  
> - /*
> -  * Store device at the device cache, in order to call
> -  * put_device() on the final step
> -  */
> - if (dev)
> - dev[i++] = d;
> - else
> - put_device(d);
> + dev[i++] = d;
>   }
>  
>   mutex_unlock(_lock);
>  
>   /*
>* Call device_attach() to reprobe devices
> -  *
> -  * NOTE: If dev allocation fails, i is 0, and the whole loop won't be
> -  * executed.
>*/
>   while (i--) {
>   struct device *d = dev[i];
> -- 
> 2.13.3
> 

-- 
Regards,

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

Re: [PATCH 4/4] v4l: async: add comment about re-probing to v4l2_async_notifier_unregister()

[Sakari Ailus]

Hi Hans,

On Thu, Aug 24, 2017 at 09:59:41AM +0200, Hans Verkuil wrote:
> On 08/23/17 21:03, Niklas Söderlund wrote:
> > Hi,
> > 
> > On 2017-08-18 15:42:37 +0200, Niklas Söderlund wrote:
> >> Hi Sakari and Laurent,
> >>
> >> Thanks for your feedback.
> >>
> >> On 2017-08-18 14:20:08 +0300, Laurent Pinchart wrote:
> >>> Hello,
> >>>
> >>> On Tuesday 15 Aug 2017 19:09:33 Sakari Ailus wrote:
>  On Mon, Jul 31, 2017 at 12:31:58AM +0200, Niklas Söderlund wrote:
> > The re-probing of subdevices when unregistering a notifier is tricky to
> > understand, and implemented somewhat as a hack. Add a comment trying to
> > explain why the re-probing is needed in the first place and why existing
> > helper functions can't be used in this situation.
> >
> > Signed-off-by: Niklas Söderlund 
> > ---
> >
> >  drivers/media/v4l2-core/v4l2-async.c | 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c
> > b/drivers/media/v4l2-core/v4l2-async.c index
> > d91ff0a33fd3eaff..a3c5a1f6d4d2ab03 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -234,6 +234,23 @@ void v4l2_async_notifier_unregister(struct
> > v4l2_async_notifier *notifier)> 
> > mutex_unlock(_lock);
> >
> > +   /*
> > +* Try to re-probe the subdevices which where part of the 
> > notifier.
> > +* This is done so subdevices which where part of the notifier 
> > will
> > +* be re-probed to a pristine state and put back on the global
> > +* list of subdevices so they can once more be found and 
> > associated
> > +* with a new notifier.
> 
>  Instead of tweaking the code trying to handle unhandleable error 
>  conditions
>  in notifier unregistration and adding lengthy stories on why this is done
>  the way it is, could we simply get rid of the driver re-probing?
> 
>  I can't see why drivers shouldn't simply cope with the current interfaces
>  without re-probing to which I've never seen any reasoned cause. When a
>  sub-device driver is unbound, simply return the sub-device node to the 
>  list
>  of async sub-devices.
> >>>
> >>> I agree, this is a hack that we should get rid of. Reprobing has been 
> >>> there 
> >>> from the very beginning, it's now 4 years and a half old, let's allow it 
> >>> to 
> >>> retire :-)
> >>
> >> I would also be happy to see this code go away :-)
> >>
> >>>
>  Or can someone come up with a valid reason why the re-probing code should
>  stay? :-)
> >>
> >> Hans kindly dug out the original reason talking about why this code was 
> >> added in the first place at
> >>
> >> http://lkml.iu.edu/hypermail/linux/kernel/1210.2/00713.html
> >>
> >> I would also like record here what Laurent stated about this after 
> >> reading the above on #v4l 
> >>
> >> 13:53  pinchartl : what could happen is this
> >> 13:53  pinchartl : the master could export resources used by the subdev
> >> 13:53  pinchartl : the omap3 isp driver, for instance, is a clock source
> >> 13:54  pinchartl : and the clock can be used by sensors
> >> 13:54  pinchartl : so if you remove the omap3 isp, the clock won't be 
> >>there anymore
> >> 13:54  pinchartl : and that's bad for the subdev

Re-probing never helped anything with omap3isp driver as the clock is
removed *after* unregistering async notifier. This means that the
re-probing sub-device driver will get the same clock which is about to be
removed and continues with that happily, only to find the clock gone in a
brief moment.

This could be fixed in the omap3isp driver but it is telling that _no-one
ever complained_.

> >>
> >>
> >> I don't claim I fully understand all the consequences of removing this 
> >> reprobing now. But maybe it's safer to lave the current behavior in for 
> >> now until the full problem is understood and move forward whit these 
> >> patches since at least they document the behavior and removes another 
> >> funky bit when trying to handle the situation where the memory 
> >> allocation fails? What do you guys think?
> > 
> > Any thoughts about how I can move forward with this? The reason I'm 
> > asking is that this is a dependency for the sub-notifier patches which 
> > in turn is dependency for the R-Car CSI-2 driver :-) If someone wants to 
> > think more about this that is fine I just don't want it to be forgotten.  
> > As I see it these are the options open to me, but as always I'm always 
> > open to other solutions which I'm to narrow minded to see :-)
> > 
> > - If after the latest discussions it feels the safest option is to keep 
> >   the re-probe logic but separating the v4l2 housekeeping from re-probe 
> >   logic move forward with this series as-is.
> 
> I prefer this. We can always remove the 

Re: [PATCH 1/2] tests: Use POSIX '.' as 'source'

[Kieran Bingham]

Hi Laurent,

On 24/08/17 10:23, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 24 August 2017 01:41:03 EEST Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> On posix shells, only the '.' command is supported.
>> Even when running on a full bash shell, the file to source must be
>> either fully or locally qualified.
> 
> "must be" makes me think of a bash requirement, while I believe you mean it 
> should be fully qualified to avoid picking a random version of the file that 
> would be present in $PATH. Is my understanding correct ? If so I'll update 
> the 
> commit message when applying.

Yes, that's fine too!

Cheers

Kieran

>> Fix both issues by swapping to the posix standard
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  tests/vsp-unit-test-0001.sh | 2 +-
>>  tests/vsp-unit-test-0002.sh | 2 +-
>>  tests/vsp-unit-test-0003.sh | 2 +-
>>  tests/vsp-unit-test-0004.sh | 2 +-
>>  tests/vsp-unit-test-0005.sh | 2 +-
>>  tests/vsp-unit-test-0006.sh | 2 +-
>>  tests/vsp-unit-test-0007.sh | 2 +-
>>  tests/vsp-unit-test-0008.sh | 2 +-
>>  tests/vsp-unit-test-0009.sh | 2 +-
>>  tests/vsp-unit-test-0010.sh | 2 +-
>>  tests/vsp-unit-test-0011.sh | 2 +-
>>  tests/vsp-unit-test-0012.sh | 2 +-
>>  tests/vsp-unit-test-0013.sh | 2 +-
>>  tests/vsp-unit-test-0014.sh | 2 +-
>>  tests/vsp-unit-test-0015.sh | 2 +-
>>  tests/vsp-unit-test-0016.sh | 2 +-
>>  tests/vsp-unit-test-0017.sh | 2 +-
>>  tests/vsp-unit-test-0018.sh | 2 +-
>>  tests/vsp-unit-test-0019.sh | 2 +-
>>  tests/vsp-unit-test-0020.sh | 2 +-
>>  tests/vsp-unit-test-0021.sh | 2 +-
>>  tests/vsp-unit-test-0022.sh | 2 +-
>>  tests/vsp-unit-test-0023.sh | 2 +-
>>  23 files changed, 23 insertions(+), 23 deletions(-)
>>
>> diff --git a/tests/vsp-unit-test-0001.sh b/tests/vsp-unit-test-0001.sh
>> index 727ead7ffc4d..746e652418ff 100755
>> --- a/tests/vsp-unit-test-0001.sh
>> +++ b/tests/vsp-unit-test-0001.sh
>> @@ -6,7 +6,7 @@
>>  # by the WPF.
>>  #
>>
>> -source vsp-lib.sh
>> +. ./vsp-lib.sh
>>
>>  features="rpf.0 wpf.0"
>>  formats="RGB332 ARGB555 XRGB555 RGB565 BGR24 RGB24 ABGR32 ARGB32 XBGR32
>> XRGB32" diff --git a/tests/vsp-unit-test-0002.sh
>> b/tests/vsp-unit-test-0002.sh index cc18126b7722..1a617a8b4d4d 100755
>> --- a/tests/vsp-unit-test-0002.sh
>> +++ b/tests/vsp-unit-test-0002.sh
>> @@ -6,7 +6,7 @@
>>  # by the WPF.
>>  #
>>
>> -source vsp-lib.sh
>> +. ./vsp-lib.sh
>>
>>  features="rpf.0 wpf.0"
>>  formats="NV12M NV16M NV21M NV61M UYVY VYUY YUV420M YUV422M YUV444M YVU420M
>> YVU422M YVU444M YUYV YVYU" diff --git a/tests/vsp-unit-test-0003.sh
>> b/tests/vsp-unit-test-0003.sh index ff1cf3047a99..41c40b9ae1fb 100755
>> --- a/tests/vsp-unit-test-0003.sh
>> +++ b/tests/vsp-unit-test-0003.sh
>> @@ -5,7 +5,7 @@
>>  # pipeline with identical input and output formats.
>>  #
>>
>> -source vsp-lib.sh
>> +. ./vsp-lib.sh
>>
>>  features="rpf.0 uds wpf.0"
>>  formats="RGB24 YUV444M"
>> diff --git a/tests/vsp-unit-test-0004.sh b/tests/vsp-unit-test-0004.sh
>> index 7dc5613f5450..69b875bbd81c 100755
>> --- a/tests/vsp-unit-test-0004.sh
>> +++ b/tests/vsp-unit-test-0004.sh
>> @@ -5,7 +5,7 @@
>>  # up at the RPF output.
>>  #
>>
>> -source vsp-lib.sh
>> +. ./vsp-lib.sh
>>
>>  features="hgo rpf.0 wpf.0"
>>  formats="RGB24 YUV444M"
>> diff --git a/tests/vsp-unit-test-0005.sh b/tests/vsp-unit-test-0005.sh
>> index 66c26b49f759..04c79c4b321c 100755
>> --- a/tests/vsp-unit-test-0005.sh
>> +++ b/tests/vsp-unit-test-0005.sh
>> @@ -5,7 +5,7 @@
>>  # much, use RGB24 to simplify frame comparison.
>>  #
>>
>> -source vsp-lib.sh
>> +. ./vsp-lib.sh
>>
>>  features="rpf.0 rpf.1 wpf.0"
>>  optional_features="rpf.2 rpf.3 rpf.4"
>> diff --git a/tests/vsp-unit-test-0006.sh b/tests/vsp-unit-test-0006.sh
>> index 8e6a3fb5bc4e..8781498d3bcd 100755
>> --- a/tests/vsp-unit-test-0006.sh
>> +++ b/tests/vsp-unit-test-0006.sh
>> @@ -4,7 +4,7 @@
>>  # Test invalid pipelines, without an RPF or without a WPF.
>>  #
>>
>> -source vsp-lib.sh
>> +. ./vsp-lib.sh
>>
>>  features="rpf.0 wpf.0"
>>  format=RGB24
>> diff --git a/tests/vsp-unit-test-0007.sh b/tests/vsp-unit-test-0007.sh
>> index 3e965134569a..d5ba44c2ab37 100755
>> --- a/tests/vsp-unit-test-0007.sh
>> +++ b/tests/vsp-unit-test-0007.sh
>> @@ -4,7 +4,7 @@
>>  # Test composition through the BRU in RGB and YUV formats.
>>  #
>>
>> -source vsp-lib.sh
>> +. ./vsp-lib.sh
>>
>>  features="rpf.0 rpf.1 bru wpf.0"
>>  formats="RGB24 YUV444M"
>> diff --git a/tests/vsp-unit-test-0008.sh b/tests/vsp-unit-test-0008.sh
>> index 3c752c69a8f0..717560f8cfae 100755
>> --- a/tests/vsp-unit-test-0008.sh
>> +++ b/tests/vsp-unit-test-0008.sh
>> @@ -5,7 +5,7 @@
>>  # the pipeline, both before and after the scaler.
>>  #
>>
>> -source vsp-lib.sh
>> +. ./vsp-lib.sh
>>
>>  features="bru rpf.0 uds wpf.0"
>>  formats="RGB24 YUV444M"
>> diff --git a/tests/vsp-unit-test-0009.sh b/tests/vsp-unit-test-0009.sh
>> index dbc2ec5e881c..8814665b01f8 100755
>> --- 

Re: [PATCH 2/2] README: Document need for killall command

[Kieran Bingham]

Hi Laurent,

On 24/08/17 10:36, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 24 August 2017 01:41:04 EEST Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> The killall command is provided by the psmisc package on debian based
>> systems. On other systems it should be built or added to the filesystem as
>> appropriate.
>>
>> Also remove unnecessary blank line.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  README | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/README b/README
>> index e503a2c41aef..7efcef394ae9 100644
>> --- a/README
>> +++ b/README
>> @@ -43,6 +43,7 @@ system in a directory included in $PATH.
>>  * media-ctl (part of v4l-utils, available at
>> git://linuxtv.org/v4l-utils.git) * raw2rgbpnm (available at
>> git://git.retiisi.org.uk/~sailus/raw2rgbpnm.git) * yavta (available at
>> git://git.ideasonboard.org/yavta.git)
>> +* killall (available from the psmisc package)
> 
> I've moved this between compare and media-ctl to keep the dependencies 
> alphabetically sorted.

That's fine with me.

>>  All but the HGO and CLU/LUT tests can be run with the latest version of
>> these tools. To test the HGO, HGT and CLU/LUT, the 'vsp' branch of 'yavta'
>> is currently @@ -53,7 +54,6 @@ tool is not available the corresponding
>> tests will be skipped.
>>
>>  * stress (available at http://people.seas.harvard.edu/~apw/stress/)
>>
>> -
> 
> I like this blank line :-) There are two blank lines before each section 
> title 
> in the README file.
> 

Ah ok, I must have seen two lines and deleted one without looking further.

> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 
> 
> If you're fine the comments I'll update the patch when applying and push it.

Sure, that's fine.

--
Kieran

RE: [PATCH v2] ARM: dts: iwg20d-q7: Add RTC support

[Biju Das]

> -Original Message-
> From: Simon Horman [mailto:ho...@verge.net.au]
> Sent: 24 August 2017 11:47
> To: Chris Paterson 
> Cc: Rob Herring ; Mark Rutland
> ; Magnus Damm ;
> Russell King ; Biju Das ;
> devicet...@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v2] ARM: dts: iwg20d-q7: Add RTC support
>
> On Wed, Aug 16, 2017 at 10:16:30AM +0100, Chris Paterson wrote:
> > From: Biju Das 
> >
> > Define the iWave RainboW-G20D-Qseven board dependent part of the RTC
> > device node.
> >
> > Signed-off-by: Biju Das 
> > [chris: corrected bq32000 compatible string]
> > Signed-off-by: Chris Paterson 
> > ---
> > v1 -> v2
> > Added ti to bq32000 compatible string - Thanks Geert
>
> Thanks, applied for v4.15.

Looks like i2c2_pins nodes are misplaced. Please drop this patch,
So that I can send a new patch.





Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

RE: [PATCH ] ARM: dts: iwg20d-q7: Add chosen node

[Biju Das]

> -Original Message-
> From: Simon Horman [mailto:ho...@verge.net.au]
> Sent: 22 August 2017 09:08
> To: Biju Das 
> Cc: Rob Herring ; Mark Rutland
> ; Magnus Damm ;
> Russell King ; Chris Paterson
> ; Fabrizio Castro
> ; devicet...@vger.kernel.org; linux-renesas-
> s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH ] ARM: dts: iwg20d-q7: Add chosen node
>
> On Fri, Aug 18, 2017 at 05:58:08PM +0100, Biju Das wrote:
> > Signed-off-by: Biju Das 
> > ---
> > This patch tested against renesas-dev tag
> > renesas-devel-20170815-v4.13-rc5
>
> Thanks, I have applied this for v4.15.
>
> There was some fuzz when applying this patch.
> Please check that it is correct when I have pushed today's devel tag to the
> renesas tree.

Looks like this node is misplaced. I will repost this patch.

> >
> >  arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
> > b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
> > index 081af01..305a6a1 100644
> > --- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
> > +++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
> > @@ -19,6 +19,11 @@
> >  serial0 = 
> >  ethernet0 = 
> >  };
> > +
> > +chosen {
> > +bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> > +stdout-path = "serial0:115200n8";
> > +};
> >  };
> >
> >   {
> > --
> > 1.9.1
> >



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

[PATCH resend] ARM: dts: r8a7745: Add Ethernet AVB support

[Biju Das]

Add Ethernet AVB support for r8a7745 SoC.

Signed-off-by: Biju Das <biju@bp.renesas.com>
---
It is applying cleanly on renesas-devel branch tag
renesas-devel-20170824-v4.13-rc6.

It is tested against renesas-devel branch tag
renesas-devel-20170824-v4.13-rc6.

 arch/arm/boot/dts/r8a7745.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 7fd2967..c34f88e 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -707,6 +707,19 @@
status = "disabled";
};
 
+   avb: ethernet@e680 {
+   compatible = "renesas,etheravb-r8a7745",
+"renesas,etheravb-rcar-gen2";
+   reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
+   interrupts = ;
+   clocks = < CPG_MOD 812>;
+   power-domains = < R8A7745_PD_ALWAYS_ON>;
+   resets = < 812>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
mmcif0: mmc@ee20 {
compatible = "renesas,mmcif-r8a7745",
 "renesas,sh-mmcif";
-- 
1.9.1

RE: [PATCH ] ARM: dts: r8a7745: Add Ethernet AVB support

[Biju Das]

> -Original Message-
> From: Simon Horman [mailto:ho...@verge.net.au]
> Sent: 24 August 2017 11:19
> To: Biju Das 
> Cc: Rob Herring ; Mark Rutland
> ; Magnus Damm ;
> Russell King ; Chris Paterson
> ; devicet...@vger.kernel.org; linux-renesas-
> s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH ] ARM: dts: r8a7745: Add Ethernet AVB support
>
> On Tue, Aug 22, 2017 at 08:53:25AM +0100, Biju Das wrote:
> > Add Ethernet AVB support for r8a7745 SoC.
> >
> > Signed-off-by: Biju Das 
> > ---
> > This patch is depend upon the below patch [1/2] ARM: dts: r8a7745: Add
> > MMC interface support https://patchwork.kernel.org/patch/9906803/
> >
> > It is tested against renesas-devel branch tag
> > renesas-devel-20170821-v4.13-rc5
>
> This patch does not seem to apply cleanly (using git am) on top of the tag
> above. Please resolve this problem and resubmit.

Thanks. I will resubmit the patch.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH v2 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support

[Geert Uytterhoeven]

Hi Simon,

On Mon, Aug 21, 2017 at 3:01 PM, Simon Horman
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Z2 clock divider support for R-Car Gen3 SoC.
>
> Signed-off-by: Takeshi Kihara 
> [simon: add recalc_rate() helper; use bitops macros]
> Signed-off-by: Simon Horman 

Thanks for this patch!

> --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> +++ b/drivers/clk/renesas/rcar-gen3-cpg.c

> @@ -69,6 +69,26 @@ static unsigned long cpg_z_clk_recalc_rate(struct clk_hw 
> *hw,
> return rate;
>  }
>
> +static unsigned long cpg_z_clk_recalc_rate(struct clk_hw *hw,
> +  unsigned long parent_rate)
> +{
> +   struct cpg_z_clk *zclk = to_z_clk(hw);
> +   unsigned int val;
> +
> +   val = FIELD_GET(CPG_FRQCRC_ZFC_MASK, clk_readl(zclk->reg));
> +   return __cpg_z_clk_recalc_rate(parent_rate, val);
> +}
> +
> +static unsigned long cpg_z2_clk_recalc_rate(struct clk_hw *hw,
> +  unsigned long parent_rate)
> +{
> +   struct cpg_z_clk *zclk = to_z_clk(hw);
> +   unsigned int val;
> +
> +   val = FIELD_GET(CPG_FRQCRC_Z2FC_MASK, clk_readl(zclk->reg));
> +   return __cpg_z_clk_recalc_rate(parent_rate, val);
> +}
> +
>  static long cpg_z_clk_round_rate(struct clk_hw *hw, unsigned long rate,
>  unsigned long *parent_rate)
>  {
> @@ -129,12 +149,25 @@ static int cpg_z_clk_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> return -ETIMEDOUT;
>  }
>
> +static int cpg_z2_clk_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> +   pr_info("Do not support Z2 clock changing\n");

Oops?
This can be handled like the Z clock, can't it?
If not, please ignore some of my comments below.

> +   return 0;
> +}
> +
>  static const struct clk_ops cpg_z_clk_ops = {
> .recalc_rate = cpg_z_clk_recalc_rate,
> .round_rate = cpg_z_clk_round_rate,
> .set_rate = cpg_z_clk_set_rate,
>  };
>
> +static const struct clk_ops cpg_z2_clk_ops = {
> +   .recalc_rate = cpg_z2_clk_recalc_rate,
> +   .round_rate = cpg_z_clk_round_rate,
> +   .set_rate = cpg_z2_clk_set_rate,
> +};

Apart from the field mask, above ops are identical.
What about storing the field mask in struct cpg_z_clk instead, so the ops
can be unified?
They can even be reused for the ZR (Cortex-R7) clock, which uses yet
another field mask in the same register.

The field mask can be obtained from the r8a7795_core_clks[] table,
cfr. the offset for SD clocks used by DEF_GEN3_SD().
With a new DEF_GEN3_Z() macro, we can use a single CLK_TYPE_GEN3_Z
type for all 3 clocks.

> @@ -164,6 +197,35 @@ static struct clk * __init cpg_z_clk_register(const char 
> *name,
> return clk;
>  }
>
> +static struct clk * __init cpg_z2_clk_register(const char *name,
> + const char *parent_name,
> + void __iomem *reg)
> +{

> +   init.ops = _z2_clk_ops;

This is the only difference in this function, compared to cpg_z_clk_register()
(assumed you pass the field mask to this function).

> +   zclk->reg = reg + CPG_FRQCRC;
> +   zclk->kick_reg = reg + CPG_FRQCRB;

Given the same registers are used for Z and Z2 (and ZR), what about just
storing the base address (reg) here?
And the field mask, of course.

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/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Thanks Geert,

On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>

[snip]

> > I haven't find any mention in device tree bindings documentation of a
> > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > u-boot and mbed, the interface is reset before any actual
> > configuration is performed. I feel like that should be the place where
> > that gpio is requested and cycled...
>
> Documentation/devicetree/bindings/net/mdio.txt says
>
> These are generic properties that can apply to any MDIO bus.
>

I have now used mdio defined generic properties

 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;

status = "okay";

reset-gpios = < 2 GPIO_ACTIVE_LOW>;
reset-delay-us = <5>;

renesas,no-ether-link;
phy-handle = <>;
phy0: ethernet-phy@0 {
   reg = <0>;
};
};

I see the gpio being cycled, but same results as before: device gets
probed, address set, but I cannot ping, device gets probed, address
gets set, but I cannot ping

--- target ---
[0.00] libphy: sh_mii: probed
[0.00] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 
68:14:97:20:97:00, IRQ 22.

# ifconfig eth0 192.168.100.50
[0.00] Generic PHY e8203000.ethernet-:00: attached PHY driver 
[Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)

--- host ---
$ping 192.168.100.50
PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable


Let's leave this out of the DTS series I've just sent for now, ok?

Thanks
   j

> 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/6] clk: renesas: rcar-gen3: Add Z clock divider support

[Geert Uytterhoeven]

Hi Simon,

On Mon, Aug 21, 2017 at 3:01 PM, Simon Horman
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Z clock divider support for R-Car Gen3 SoC.
>
> Signed-off-by: Takeshi Kihara 
> [simon: divide parent by 2; use bitops macros]
> Signed-off-by: Simon Horman 

Thanks for this patch!

> --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> @@ -13,6 +13,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,139 @@
>  #define CPG_PLL2CR 0x002c
>  #define CPG_PLL4CR 0x01f4
>
> +/* Z Clock

/*
 * Z Clock

> + *
> + * Traits of this clock:
> + * prepare - clk_prepare only ensures that parents are prepared
> + * enable - clk_enable only ensures that parents are enabled
> + * rate - rate is adjustable.  clk->rate = (parent->rate * mult / 32 ) / 2
> + * parent - fixed parent.  No clk_set_parent support
> + */
> +#define CPG_FRQCRB 0x0004
> +#define CPG_FRQCRB_KICKBIT(31)
> +#define CPG_FRQCRC 0x00e0
> +#define CPG_FRQCRC_ZFC_MASKGENMASK(12, 8)
> +
> +struct cpg_z_clk {
> +   struct clk_hw hw;
> +   void __iomem *reg;
> +   void __iomem *kick_reg;
> +};
> +
> +#define to_z_clk(_hw)  container_of(_hw, struct cpg_z_clk, hw)
> +
> +static unsigned long cpg_z_clk_recalc_rate(struct clk_hw *hw,
> +  unsigned long parent_rate)
> +{
> +   struct cpg_z_clk *zclk = to_z_clk(hw);
> +   unsigned long rate;
> +   unsigned int mult;
> +
> +   mult = 32 - FIELD_GET(CPG_FRQCRC_ZFC_MASK, clk_readl(zclk->reg));
> +   /* There is a PLL post-divider of 1/2,

/*
 * There is a PLL post-divider of 1/2,

> +* thus the doubling of the divisor below.
> +*/
> +   rate = div_u64((u64)parent_rate * mult + 16, 32 * 2);

DIV_ROUND_CLOSEST_ULL()

> +   /* Round to closest value at 100MHz unit */
> +   rate = 1 * DIV_ROUND_CLOSEST(rate, 1);

Why?

With this rounding, we can no longer distinguish between e.g.
121875 and 1265625000 Hz.

> +
> +   return rate;
> +}
> +
> +static long cpg_z_clk_round_rate(struct clk_hw *hw, unsigned long rate,
> +unsigned long *parent_rate)
> +{
> +   unsigned long prate = *parent_rate;
> +   unsigned int mult;
> +
> +   if (!prate)
> +   prate = 1;

Can this really happen?

> +
> +   mult = div_u64((u64)rate * 32 + prate/2, prate);

mult = DIV_ROUND_CLOSEST_ULL(rate * 32ULL, prate);

> +   mult = clamp(mult, 1U, 32U);
> +
> +   return *parent_rate / 32 * mult;

To avoid losing precision, you should do the multiplication first, using
64-bit math.

> +}
> +
> +static int cpg_z_clk_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> +   struct cpg_z_clk *zclk = to_z_clk(hw);
> +   unsigned int mult;
> +   unsigned int i;
> +   u32 val, kick;
> +
> +   mult = div_u64((u64)rate * 32 + parent_rate/2, parent_rate);

DIV_ROUND_CLOSEST_ULL()

> +   /*
> +* Note: There is no HW information about the worst case latency.
> +*
> +* Using experimental measurements, it seems that no more than
> +* ~10 iterations are needed, independently of the CPU rate.
> +* Since this value might be dependent of external xtal rate, pll1
> +* rate or even the other emulation clocks rate, use 1000 as a

another emulated clock rate?
(Yeah, copied from Gen2 ;-)

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 1:46 PM, jmondi  wrote:
> On Thu, Aug 24, 2017 at 11:48:14AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
>>  wrote:
>> > Add pin configuration subnode for ETHER pin group.
>> > The interface can be configured and probed, but no traffic can be
>> > transmitted or received.
>> >
>> > Signed-off-by: Jacopo Mondi 
>> >
>> > ---
>> > When in u-boot console I can ping a connected host, after the
>> > system has booted I can configure an ip address on the interface but
>> > cannot exchange any traffic.
>> > I have compared the pin configuration procedure with the u-boot
>> > implemented one and some sketches from mbed operating system libraries,
>> > the configured pins are correct and registers values seems to match.
>> > Not sure if this patch should be sent for inclusion but sending it out
>> > anyway for you to judge this.

>> All OK, but do you need P4_2, which is used for ET_nRST?
>
> I tried requesting the GPIO in the "ether" subnode and define it as
> "active low", so that it is kept high during regular operations.
> I have verified through register writes dump it is cycled just after
> the gpio is requested, and this should reset the interface before the
> actual sh_eth driver kicks in.
>
> I haven't find any mention in device tree bindings documentation of a
> "reset-gpio" property for sh_eth, in the code examples I've seen in
> u-boot and mbed, the interface is reset before any actual
> configuration is performed. I feel like that should be the place where
> that gpio is requested and cycled...

Documentation/devicetree/bindings/net/mdio.txt says

These are generic properties that can apply to any MDIO bus.

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 6/6] clk: renesas: r8a7796: Add Z2 clock

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 1:50 PM, Geert Uytterhoeven
 wrote:
> On Mon, Aug 21, 2017 at 3:01 PM, Simon Horman
>  wrote:
>> From: Takeshi Kihara 
>>
>> This patch adds Z2 clock for R8A7796 SoC.
>>
>> Signed-off-by: Takeshi Kihara 
>> Signed-off-by: Simon Horman 
>
> Reviewed-by: Geert Uytterhoeven 
> (queue up pending acceptance of patch 1/6)

2/6, of course.

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 4/6] clk: renesas: r8a7795: Add Z2 clock

[Geert Uytterhoeven]

On Mon, Aug 21, 2017 at 3:01 PM, Simon Horman
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Z2 clock for r8a7795 SoC.
>
> Signed-off-by: Takeshi Kihara 

Reviewed-by: Geert Uytterhoeven 
(queue up pending acceptance of patch 2/6)

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 5/6] clk: renesas: r8a7796: Add Z clock

[Geert Uytterhoeven]

On Mon, Aug 21, 2017 at 3:01 PM, Simon Horman
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Z clock for R8A7796 SoC.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 
(queue up pending acceptance of patch 1/6)

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 3/6] clk: renesas: r8a7795: Add Z clock

[Geert Uytterhoeven]

On Mon, Aug 21, 2017 at 3:01 PM, Simon Horman
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Z clock for R8A7795 SoC.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 
(queue up pending acceptance of patch 1/6)

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/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Hi Geert,

On Thu, Aug 24, 2017 at 11:48:14AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
>  wrote:
> > Add pin configuration subnode for ETHER pin group.
> > The interface can be configured and probed, but no traffic can be
> > transmitted or received.
> >
> > Signed-off-by: Jacopo Mondi 
> >
> > ---
> > When in u-boot console I can ping a connected host, after the
> > system has booted I can configure an ip address on the interface but
> > cannot exchange any traffic.
> > I have compared the pin configuration procedure with the u-boot
> > implemented one and some sketches from mbed operating system libraries,
> > the configured pins are correct and registers values seems to match.
> > Not sure if this patch should be sent for inclusion but sending it out
> > anyway for you to judge this.
> >
> > Thanks
> >j
> > ---
> >  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 
> > +
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts 
> > b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > index bcfa644..5ce558f 100644
> > --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > @@ -58,6 +58,28 @@
> > /* P6_2 as RxD2; P6_3 as TxD2 */
> > pinmux = , ;
> > };
> > +
> > +   ether_pins: ether {
> > +   /* Ethernet on Ports 1,3,5,10 */
> > +   pinmux = , /* P1_14 = ET_COL   */
> > +,  /* P3_0 = ET_TXCLK  */
> > +,  /* P3_3 = ET_MDIO   */
> > +,  /* P3_4 = ET_RXCLK  */
> > +,  /* P3_5 = ET_RXER   */
> > +,  /* P3_6 = ET_RXDV   */
> > +,  /* P5_9 = ET_MDC*/
> > +, /* P10_1 = ET_TXER  */
> > +, /* P10_2 = ET_TXEN  */
> > +, /* P10_3 = ET_CRS   */
> > +, /* P10_4 = ET_TXD0  */
> > +, /* P10_5 = ET_TXD1  */
> > +, /* P10_6 = ET_TXD2  */
> > +, /* P10_7 = ET_TXD3  */
> > +, /* P10_8 = ET_RXD0  */
> > +, /* P10_9 = ET_RXD1  */
> > +,/* P10_10 = ET_RXD2 */
> > +;/* P10_11 = ET_RXD3 */
>
> All OK, but do you need P4_2, which is used for ET_nRST?

I tried requesting the GPIO in the "ether" subnode and define it as
"active low", so that it is kept high during regular operations.
I have verified through register writes dump it is cycled just after
the gpio is requested, and this should reset the interface before the
actual sh_eth driver kicks in.

I haven't find any mention in device tree bindings documentation of a
"reset-gpio" property for sh_eth, in the code examples I've seen in
u-boot and mbed, the interface is reset before any actual
configuration is performed. I feel like that should be the place where
that gpio is requested and cycled...

Thanks
   j
>
> 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 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 06:53:50AM -0400, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> > Hello Simon,
> >now that RZ/A1 pin controller is merged, it's time to enable some 
> > peripheral
> > devices on GR-Peach has it has been done for Genmai and RSK boards.
> > 
> > The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it 
> > should
> > be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes 
> > to
> > be defined in r7s72100.dtsi.
> > 
> > Patch 2/4 enables EHTER interface, even if I've not been able to exchange 
> > any
> > traffic on that. I can set the ip address and probe the device and double
> > checked the pin configuration process against u-boot sources (where the
> > interface is working instead). Sending the patch anyway and let you decide 
> > what
> > to do with that.
> > 
> > Thanks
> >j
> > 
> > Jacopo Mondi (4):
> >   arm: dts: gr-peach: Remove empty line
> >   arm: dts: gr-peach: Add SCIF2 pin group
> >   arm: dts: gr-peach: Add ETHER pin group
> >   arm: dts: gr-peach: Add user led device nodes
> 
> Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for 
> v4.15.
> I am leaving the 3rd (ETHER) patch pending resolution of the review
> provided by Geert.

BTW, the prefix these patches should start with "ARM:".
I fixed this when applying the patches described above.

Re: [PATCH ] phy: rcar-gen2: Add r8a7743/5 support

[Simon Horman]

On Thu, Aug 24, 2017 at 10:59:33AM +0100, Biju Das wrote:
> Add USB PHY support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5)
> USB PHY is identical to the R-Car Gen2 family.
> 
> Signed-off-by: Biju Das 

Acked-by: Simon Horman 

Re: [PATCH ] PCI: rcar: Add r8a7743/5 support

[Simon Horman]

On Thu, Aug 24, 2017 at 10:35:44AM +0100, Biju Das wrote:
> Add internal PCI bridge support for r8a7743/5 SoC. Renesas RZ/G1[ME]
> (R8A7743/5) internal PCI bridge is identical to the R-Car Gen2 family.
> 
> Signed-off-by: Biju Das <biju@bp.renesas.com>

Acked-by: Simon Horman <horms+rene...@verge.net.au>

> ---
> This patch is tested against Linux next tag next-20170824 and
> renesas-dev branch renesas-devel-20170822-v4.13-rc6. 
> 
>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt 
> b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> index 07a7509..3d03863 100644
> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -6,11 +6,14 @@ AHB. There is one bridge instance per USB port connected to 
> the internal
>  OHCI and EHCI controllers.
>  
>  Required properties:
> -- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> +- compatible: "renesas,pci-r8a7743" for the R8A7743 SoC;
> +   "renesas,pci-r8a7745" for the R8A7745 SoC;
> +   "renesas,pci-r8a7790" for the R8A7790 SoC;
> "renesas,pci-r8a7791" for the R8A7791 SoC;
> "renesas,pci-r8a7793" for the R8A7793 SoC;
> "renesas,pci-r8a7794" for the R8A7794 SoC;
> -   "renesas,pci-rcar-gen2" for a generic R-Car Gen2 compatible device
> +   "renesas,pci-rcar-gen2" for a generic R-Car Gen2 or
> +   RZ/G1 compatible device.
>  
>  
> When compatible with the generic version, nodes must list the
> -- 
> 1.9.1
> 

Re: [PATCH 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> Hello Simon,
>now that RZ/A1 pin controller is merged, it's time to enable some 
> peripheral
> devices on GR-Peach has it has been done for Genmai and RSK boards.
> 
> The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it 
> should
> be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
> be defined in r7s72100.dtsi.
> 
> Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
> traffic on that. I can set the ip address and probe the device and double
> checked the pin configuration process against u-boot sources (where the
> interface is working instead). Sending the patch anyway and let you decide 
> what
> to do with that.
> 
> Thanks
>j
> 
> Jacopo Mondi (4):
>   arm: dts: gr-peach: Remove empty line
>   arm: dts: gr-peach: Add SCIF2 pin group
>   arm: dts: gr-peach: Add ETHER pin group
>   arm: dts: gr-peach: Add user led device nodes

Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for v4.15.
I am leaving the 3rd (ETHER) patch pending resolution of the review
provided by Geert.

Re: [PATCH v3 0/2] ARM: dts: r8a7791: CPG/MSSR conversion fallout

[Simon Horman]

On Wed, Aug 23, 2017 at 01:59:24PM +0200, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> Here are the two remaining patches from the series "[PATCH v2 0/5] ARM:
> dts: rcar-gen2: Convert to new CPG/MSSR bindings" and "[PATCH v2 0/4] ARM:
> dts: rcar-gen2: Stop grouping clocks under a "clocks" subnode", rebased
> against renesas-devel-20170822-v4.13-rc6 (actually no changes at all!).
> 
> Thanks for applying!
> 
> Geert Uytterhoeven (2):
>   ARM: dts: r8a7791: Convert to new CPG/MSSR bindings
>   ARM: dts: r8a7791: Stop grouping clocks under a "clocks" subnode

Thanks, applied for v4.15

Re: [PATCH v2] ARM: dts: iwg20d-q7: Add RTC support

[Simon Horman]

On Wed, Aug 16, 2017 at 10:16:30AM +0100, Chris Paterson wrote:
> From: Biju Das 
> 
> Define the iWave RainboW-G20D-Qseven board dependent part of the
> RTC device node.
> 
> Signed-off-by: Biju Das 
> [chris: corrected bq32000 compatible string]
> Signed-off-by: Chris Paterson 
> ---
> v1 -> v2
> Added ti to bq32000 compatible string - Thanks Geert

Thanks, applied for v4.15.

Re: [PATCH 0/2] ARM: dtsi: r8a7745: iwg22m: Add eMMC support

[Simon Horman]

On Thu, Aug 17, 2017 at 06:31:41PM +0100, Fabrizio Castro wrote:
> This series adds eMMC support to r8a7745 SoC and iW-RainboW-G22M-SM SoM.
> 
> Testing has been made on top of Renesas's devel branch.
> 
> The patches contained in this series depend on the following patches:
> [1/2] ARM: dts: iwg22m: Add iWave RZG1E SODIMM SOM - 
> https://patchwork.kernel.org/patch/9901619/
> [2/2] ARM: dts: iwg22d-sodimm: Add support for iWave G22D-SODIMM board - 
> https://patchwork.kernel.org/patch/9901623/
> dt-bindings: mmc: sh_mmcif: Document r8a7745 DT bindings - 
> https://patchwork.kernel.org/patch/9902199/

Thanks, applied for v4.15.

Re: [PATCH] ARM: dtsi: r8a7745: Add I2C DT support

[Simon Horman]

On Tue, Aug 22, 2017 at 04:27:02PM +0100, Fabrizio Castro wrote:
> Add I2C[0-5] devices to the r8a7745 device tree.
> 
> Signed-off-by: Fabrizio Castro 

Thanks, applied for v4.15.

Re: [PATCH] dt-bindings: apmu: Document r8a7745 support

[Simon Horman]

On Tue, Aug 22, 2017 at 02:52:19PM +0100, Fabrizio Castro wrote:
> Document APMU and SMP enable method for RZ/G1E (also known as
> r8a7745) SoC.
> 
> Signed-off-by: Fabrizio Castro 

Thanks, applied for v4.15.

Re: [PATCH ] ARM: dts: r8a7745: Add Ethernet AVB support

[Simon Horman]

On Tue, Aug 22, 2017 at 08:53:25AM +0100, Biju Das wrote:
> Add Ethernet AVB support for r8a7745 SoC.
> 
> Signed-off-by: Biju Das 
> ---
> This patch is depend upon the below patch
> [1/2] ARM: dts: r8a7745: Add MMC interface support
> https://patchwork.kernel.org/patch/9906803/
> 
> It is tested against renesas-devel branch tag
> renesas-devel-20170821-v4.13-rc5

This patch does not seem to apply cleanly (using git am)
on top of the tag above. Please resolve this problem and resubmit.

[PATCH ] phy: rcar-gen2: Add r8a7743/5 support

[Biju Das]

Add USB PHY support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5)
USB PHY is identical to the R-Car Gen2 family.

Signed-off-by: Biju Das <biju@bp.renesas.com>
---
This patch is tested against Linux next tag next-20170824 and 
renesas-dev branch renesas-devel-20170822-v4.13-rc6. 

 Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
index 91da947..eeb9e18 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
@@ -4,10 +4,13 @@ This file provides information on what the device node for 
the R-Car generation
 2 USB PHY contains.
 
 Required properties:
-- compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
+- compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC.
+ "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC.
+ "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
  "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
  "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC.
- "renesas,rcar-gen2-usb-phy" for a generic R-Car Gen2 compatible 
device.
+ "renesas,rcar-gen2-usb-phy" for a generic R-Car Gen2 or
+ RZ/G1 compatible device.
 
  When compatible with the generic version, nodes must list the
  SoC-specific version corresponding to the platform first
-- 
1.9.1

Re: [PATCH v2 0/6] clk: renesas: r8a779[56]: Add Z and Z2 clock support

[Simon Horman]

On Wed, Aug 23, 2017 at 05:20:55PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Mon, Aug 21, 2017 at 3:01 PM, Simon Horman
>  wrote:
> > this patch-set adds Z and Z2 clock support.
> >
> > These are dependencies for supporting CPUFreq. The remainder of that
> > work is being posted separately and can be found at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> > topic/rcar-gen3-cpufreq
> >
> > A description of steps taken to lightly exercise the same feature for the
> > r88a7795 the above can be found at the link below. The results are the same
> > for the r8a7796 with the exception that it has two active CPU cores rather
> > than four.
> >
> > http://elinux.org/Tests:R-CAR-GEN3-CPUFreq
> 
> Thanks for your patches, and the wiki page!
> 
> I gave it a try on R-Car H3 (ES1.0 and ES2.0) and M3-W (ES1.0), and the
> off-by-two factor of the Z clock frequency is gone.
> I couldn't test on R-Car H3 ES1.1. Probably it's OK, too (ES1.1 fixed the
> missing PLL0/2/4 post-divider in ES1.0).
> 
> 1. After boot-up, the CPU clock frequency is 1.5 GHz, and
>/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq and
>/sys/kernel/debug/clk/z/clk_rate agree. Good.
> 
> 2. After switching to the conservative governor, scaling_cur_freq reports
>either a 500 MHz or 1 GHz clock rate.
>But /sys/kernel/debug/clk/z/clk_rate disagrees: it reports either a 200
>or 700 MHz clock rate.
> 
>Ah, there's also cpuinfo_cur_freq. That value matches the Z clock.
>Interestingly, cpuinfo_cur_freq is lower than cpuinfo_min_freq?
>/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:20
>/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:150
>/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:50
> 
> 3. After switching back to the performance governor, scaling_cur_freq reports
>1.5 GHz again.
>But cpuinfo_cur_freq is still only 700 MHz, just like z/clk_rate.
> 
> Do you know what's wrong?

Unfortunately not. I will look into this.

Re: [PATCH 0/2] ARM: dts: Add iWave RZ/G1E board support

[Simon Horman]

On Tue, Aug 22, 2017 at 04:03:23PM +, Chris Paterson wrote:
> Hello Simon,
> 
> > From: Biju Das [mailto:biju@bp.renesas.com]
> > Sent: 15 August 2017 11:54
> > 
> > Hello,
> > 
> > This series aims to add iWave RZ/G1E (R8A7745) based RainboW-G22M-SM
> > SODIMM SoM and RainboW-G22D board support.
> > 
> > This series has been tested against linux-next tag next-20170815 as well as
> > renesas-dev tag 20170814-v4.13-rc5
> > 
> > This patch has documentation dependency on below patches
> 
> The below patches are now in your v4.14 branch. Does this mean that this DT 
> series can now be accepted?

Thanks, I have applied them for v4.15.

[PATCH ] PCI: rcar: Add r8a7743/5 support

[Biju Das]

Add internal PCI bridge support for r8a7743/5 SoC. Renesas RZ/G1[ME]
(R8A7743/5) internal PCI bridge is identical to the R-Car Gen2 family.

Signed-off-by: Biju Das <biju@bp.renesas.com>
---
This patch is tested against Linux next tag next-20170824 and
renesas-dev branch renesas-devel-20170822-v4.13-rc6. 

 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt 
b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index 07a7509..3d03863 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -6,11 +6,14 @@ AHB. There is one bridge instance per USB port connected to 
the internal
 OHCI and EHCI controllers.
 
 Required properties:
-- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
+- compatible: "renesas,pci-r8a7743" for the R8A7743 SoC;
+ "renesas,pci-r8a7745" for the R8A7745 SoC;
+ "renesas,pci-r8a7790" for the R8A7790 SoC;
  "renesas,pci-r8a7791" for the R8A7791 SoC;
  "renesas,pci-r8a7793" for the R8A7793 SoC;
  "renesas,pci-r8a7794" for the R8A7794 SoC;
- "renesas,pci-rcar-gen2" for a generic R-Car Gen2 compatible device
+ "renesas,pci-rcar-gen2" for a generic R-Car Gen2 or
+ RZ/G1 compatible device.
 
 
  When compatible with the generic version, nodes must list the
-- 
1.9.1

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
 wrote:
> Add pin configuration subnode for ETHER pin group.
> The interface can be configured and probed, but no traffic can be
> transmitted or received.
>
> Signed-off-by: Jacopo Mondi 
>
> ---
> When in u-boot console I can ping a connected host, after the
> system has booted I can configure an ip address on the interface but
> cannot exchange any traffic.
> I have compared the pin configuration procedure with the u-boot
> implemented one and some sketches from mbed operating system libraries,
> the configured pins are correct and registers values seems to match.
> Not sure if this patch should be sent for inclusion but sending it out
> anyway for you to judge this.
>
> Thanks
>j
> ---
>  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 
> +
>  1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts 
> b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> index bcfa644..5ce558f 100644
> --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> @@ -58,6 +58,28 @@
> /* P6_2 as RxD2; P6_3 as TxD2 */
> pinmux = , ;
> };
> +
> +   ether_pins: ether {
> +   /* Ethernet on Ports 1,3,5,10 */
> +   pinmux = , /* P1_14 = ET_COL   */
> +,  /* P3_0 = ET_TXCLK  */
> +,  /* P3_3 = ET_MDIO   */
> +,  /* P3_4 = ET_RXCLK  */
> +,  /* P3_5 = ET_RXER   */
> +,  /* P3_6 = ET_RXDV   */
> +,  /* P5_9 = ET_MDC*/
> +, /* P10_1 = ET_TXER  */
> +, /* P10_2 = ET_TXEN  */
> +, /* P10_3 = ET_CRS   */
> +, /* P10_4 = ET_TXD0  */
> +, /* P10_5 = ET_TXD1  */
> +, /* P10_6 = ET_TXD2  */
> +, /* P10_7 = ET_TXD3  */
> +, /* P10_8 = ET_RXD0  */
> +, /* P10_9 = ET_RXD1  */
> +,/* P10_10 = ET_RXD2 */
> +;/* P10_11 = ET_RXD3 */

All OK, but do you need P4_2, which is used for ET_nRST?

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] README: Document need for killall command

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 24 August 2017 01:41:04 EEST Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The killall command is provided by the psmisc package on debian based
> systems. On other systems it should be built or added to the filesystem as
> appropriate.
> 
> Also remove unnecessary blank line.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/README b/README
> index e503a2c41aef..7efcef394ae9 100644
> --- a/README
> +++ b/README
> @@ -43,6 +43,7 @@ system in a directory included in $PATH.
>  * media-ctl (part of v4l-utils, available at
> git://linuxtv.org/v4l-utils.git) * raw2rgbpnm (available at
> git://git.retiisi.org.uk/~sailus/raw2rgbpnm.git) * yavta (available at
> git://git.ideasonboard.org/yavta.git)
> +* killall (available from the psmisc package)

I've moved this between compare and media-ctl to keep the dependencies 
alphabetically sorted.

> 
>  All but the HGO and CLU/LUT tests can be run with the latest version of
> these tools. To test the HGO, HGT and CLU/LUT, the 'vsp' branch of 'yavta'
> is currently @@ -53,7 +54,6 @@ tool is not available the corresponding
> tests will be skipped.
> 
>  * stress (available at http://people.seas.harvard.edu/~apw/stress/)
> 
> -

I like this blank line :-) There are two blank lines before each section title 
in the README file.

Apart from that,

Reviewed-by: Laurent Pinchart 

If you're fine the comments I'll update the patch when applying and push it.

>  -
>  Running the Tests
>  -


-- 
Regards,

Laurent Pinchart

Re: [PATCH 4/4] arm: dts: gr-peach: Add user led device nodes

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
 wrote:
> Add device nodes for user leds on gr-peach board.

Singular? (also in the one-line summary)

> Signed-off-by: Jacopo Mondi 

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] vsp-tests: Add BRS test

[Laurent Pinchart]

Hello,

This patch series adds a test to the VSP unit test suite for the BRS module.

The BRS is the Blend/ROP Secondary unit, a stripped-down version of the BRU
that supports two inputs only. It is present in some VSPD instances, in
particular on the H3 ES2.0.

As the VSPD is used for display pipelines only the BRS can't be tested through
the V4L2 API with the upstream VSP driver. A simple hack that exposes the VSPD
through V4L2 is needed.

Laurent Pinchart (3):
  vsp-lib: Use the correct media device name to count BRU inputs
  vsp-lib: Add support for RPF-BRS-WPF pipelines
  tests: Add BRS test

 scripts/vsp-lib.sh  | 63 +++--
 tests/vsp-unit-test-0024.sh | 45 
 2 files changed, 88 insertions(+), 20 deletions(-)
 create mode 100755 tests/vsp-unit-test-0024.sh

-- 
Regards,

Laurent Pinchart

[PATCH 3/3] tests: Add BRS test

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 tests/vsp-unit-test-0024.sh | 45 +
 1 file changed, 45 insertions(+)
 create mode 100755 tests/vsp-unit-test-0024.sh

diff --git a/tests/vsp-unit-test-0024.sh b/tests/vsp-unit-test-0024.sh
new file mode 100755
index ..036429254a8f
--- /dev/null
+++ b/tests/vsp-unit-test-0024.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+#
+# Test composition through the BRS in RGB and YUV formats.
+#
+
+source vsp-lib.sh
+
+features="rpf.0 rpf.1 brs wpf.0"
+formats="RGB24 YUV444M"
+
+test_brs() {
+   local format=$1
+   local ninputs=$2
+
+   test_start "BRS in $format with $ninputs inputs"
+
+   pipe_configure rpf-brs $ninputs
+   format_configure rpf-brs $format 1024x768 $ninputs
+
+   local input
+   for input in `seq 0 1 $((ninputs-1))` ; do
+   vsp_runner rpf.$input &
+   done
+   vsp_runner wpf.0
+
+   local result=$(compare_frames)
+
+   test_complete $result
+}
+
+test_main() {
+   local num_inputs=2
+   local format
+   local ninputs
+
+   for format in $formats ; do
+   for ninputs in `seq $num_inputs` ; do
+   test_brs $format $ninputs
+   done
+   done
+}
+
+test_init $0 "$features"
+test_run
-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/4] arm: dts: gr-peach: Remove empty line

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
 wrote:
> Remove an empty line in gr-peach device tree source file.
>
> Signed-off-by: Jacopo Mondi 

Acked-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/RFC 3/3] ARM: dts: armadillo800eva: Convert to named i2c-gpio bindings

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts 
b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
index 153609c1a5d83923..d62d22c36da1c9b9 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
@@ -131,9 +131,8 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "i2c-gpio";
-   gpios = < 208 GPIO_ACTIVE_HIGH /* sda */
- 91 GPIO_ACTIVE_HIGH /* scl */
-   >;
+   sda-gpios = < 208 GPIO_ACTIVE_HIGH>;
+   scl-gpios = < 91 GPIO_ACTIVE_HIGH>;
i2c-gpio,delay-us = <5>;
};
 
-- 
2.7.4

[PATCH/RFC 2/3] i2c: gpio: Add support for named gpios in DT

[Geert Uytterhoeven]

Add support for the new DT bindings using named gpios, which are less
error-prone than unnamed gpios.  The latter are still supported as a
fallback.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/i2c/busses/i2c-gpio.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index 0ef8fcc6ac3aca1e..45b7ec99dc210bbe 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -88,6 +88,15 @@ static int i2c_gpio_getscl(void *data)
 static int of_i2c_gpio_get_pins(struct device_node *np,
unsigned int *sda_pin, unsigned int *scl_pin)
 {
+   *sda_pin = of_get_named_gpio(np, "sda-gpios", 0);
+   *scl_pin = of_get_named_gpio(np, "scl-gpios", 0);
+   if (*sda_pin == -EPROBE_DEFER || *scl_pin == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
+   if (gpio_is_valid(*sda_pin) && gpio_is_valid(*scl_pin))
+   return 0;
+
+   /* Try deprecated unnamed gpios */
if (of_gpio_count(np) < 2)
return -ENODEV;
 
-- 
2.7.4

[PATCH/RFC 0/3] i2c: gpio: Add support for named gpios in DT

[Geert Uytterhoeven]

Hi all,

The current i2c-gpio DT bindings use a single unnamed "gpios" property
to refer to the SDA and SCL signal lines by index.  This is error-prone
for the casual DT writer and reviewer, as one has to look up the order
in the DT bindings, and leads to the addition of comments in DTS files,
like

gpios = < 208 GPIO_ACTIVE_HIGH /* sda */
  91 GPIO_ACTIVE_HIGH /* scl */
>;

This patch series:
  - Amends the DT bindings to use named gpios,
  - Adds support for the new bindings to the driver,
  - Converts the armadillo800eva to use the new bindings, as an example.

Thanks for your comments!

Geert Uytterhoeven (3):
  dt-bindings: i2c: i2c-gpio: Add support for named gpios
  i2c: gpio: Add support for named gpios in DT
  ARM: dts: armadillo800eva: Convert to named i2c-gpio bindings

 Documentation/devicetree/bindings/i2c/i2c-gpio.txt | 5 +++--
 arch/arm/boot/dts/r8a7740-armadillo800eva.dts  | 5 ++---
 drivers/i2c/busses/i2c-gpio.c  | 9 +
 3 files changed, 14 insertions(+), 5 deletions(-)

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

[PATCH/RFC 1/3] dt-bindings: i2c: i2c-gpio: Add support for named gpios

[Geert Uytterhoeven]

The current i2c-gpio DT bindings use a single unnamed "gpios" property
to refer to the SDA and SCL signal lines by index.  This is error-prone
for the casual DT writer and reviewer, as one has to look up the order
in the DT bindings.

Fix this by amending the DT bindings to use two separate named gpios
properties, and deprecate the old unnamed variant.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/i2c/i2c-gpio.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-gpio.txt 
b/Documentation/devicetree/bindings/i2c/i2c-gpio.txt
index 4f8ec947c6bd9cad..61033f73577dd70e 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-gpio.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-gpio.txt
@@ -2,8 +2,9 @@ Device-Tree bindings for i2c gpio driver
 
 Required properties:
- compatible = "i2c-gpio";
-   - gpios: sda and scl gpio
-
+   - sda-gpios: gpio used for the sda signal
+   - scl-gpios: gpio used for the scl signal
+   - gpios: sda and scl gpio, alternative for {sda,scl}-gpios (deprecated)
 
 Optional properties:
- i2c-gpio,sda-open-drain: sda as open drain
-- 
2.7.4

[PATCH] pinctrl: rza1: Remove suffix from gpiochip label

[Jacopo Mondi]

The OF node name already contains the gpio chip identifier, no need to
append it when creating the label.

The following debug message clearly shows the suffix is not required
"pinctrl-rza1 fcfe3000.pin-controller: Parsed gpiochip gpio-0-0 with 6
pins"

Signed-off-by: Jacopo Mondi 
---
 drivers/pinctrl/pinctrl-rza1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rza1.c b/drivers/pinctrl/pinctrl-rza1.c
index dc164da..7e896bd 100644
--- a/drivers/pinctrl/pinctrl-rza1.c
+++ b/drivers/pinctrl/pinctrl-rza1.c
@@ -1096,8 +1096,8 @@ static int rza1_parse_gpiochip(struct rza1_pinctrl 
*rza1_pctl,

*chip   = rza1_gpiochip_template;
chip->base  = -1;
-   chip->label = devm_kasprintf(rza1_pctl->dev, GFP_KERNEL, "%s-%u",
-np->name, gpioport);
+   chip->label = devm_kasprintf(rza1_pctl->dev, GFP_KERNEL, "%s",
+np->name);
chip->ngpio = of_args.args[2];
chip->of_node   = np;
chip->parent= rza1_pctl->dev;
--
2.7.4

[PATCH 4/4] arm: dts: gr-peach: Add user led device nodes

[Jacopo Mondi]

Add device nodes for user leds on gr-peach board.

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

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts 
b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 5ce558f..29ad54e 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include 
 #include 
 
 / {
@@ -51,6 +52,15 @@
reg = <0x0060 0x0020>;
};
};
+
+leds {
+   status = "okay";
+   compatible = "gpio-leds";
+
+   led1 {
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+   };
 };
 
  {
-- 
2.7.4

[PATCH 2/4] arm: dts: gr-peach: Add SCIF2 pin group

[Jacopo Mondi]

Add pin configuration subnode for SCIF2 serial debug interface.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts 
b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 1c40a1a..bcfa644 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include 
 
 / {
model = "GR-Peach";
@@ -52,6 +53,13 @@
};
 };
 
+ {
+   scif2_pins: serial2 {
+   /* P6_2 as RxD2; P6_3 as TxD2 */
+   pinmux = , ;
+   };
+};
+
 _clk {
clock-frequency = <1000>;
 };
@@ -61,5 +69,8 @@
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
status = "okay";
 };
-- 
2.7.4

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Jacopo Mondi]

Add pin configuration subnode for ETHER pin group.
The interface can be configured and probed, but no traffic can be
transmitted or received.

Signed-off-by: Jacopo Mondi 

---
When in u-boot console I can ping a connected host, after the
system has booted I can configure an ip address on the interface but
cannot exchange any traffic.
I have compared the pin configuration procedure with the u-boot
implemented one and some sketches from mbed operating system libraries,
the configured pins are correct and registers values seems to match.
Not sure if this patch should be sent for inclusion but sending it out
anyway for you to judge this.

Thanks
   j
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts 
b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index bcfa644..5ce558f 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -58,6 +58,28 @@
/* P6_2 as RxD2; P6_3 as TxD2 */
pinmux = , ;
};
+
+   ether_pins: ether {
+   /* Ethernet on Ports 1,3,5,10 */
+   pinmux = , /* P1_14 = ET_COL   */
+,  /* P3_0 = ET_TXCLK  */
+,  /* P3_3 = ET_MDIO   */
+,  /* P3_4 = ET_RXCLK  */
+,  /* P3_5 = ET_RXER   */
+,  /* P3_6 = ET_RXDV   */
+,  /* P5_9 = ET_MDC*/
+, /* P10_1 = ET_TXER  */
+, /* P10_2 = ET_TXEN  */
+, /* P10_3 = ET_CRS   */
+, /* P10_4 = ET_TXD0  */
+, /* P10_5 = ET_TXD1  */
+, /* P10_6 = ET_TXD2  */
+, /* P10_7 = ET_TXD3  */
+, /* P10_8 = ET_RXD0  */
+, /* P10_9 = ET_RXD1  */
+,/* P10_10 = ET_RXD2 */
+;/* P10_11 = ET_RXD3 */
+   };
 };
 
 _clk {
@@ -74,3 +96,16 @@
 
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   renesas,no-ether-link;
+   phy-handle = <>;
+   phy0: ethernet-phy@0 {
+   reg = <0>;
+   };
+};
-- 
2.7.4

[PATCH 0/4] GR-Peach DTS update

[Jacopo Mondi]

Hello Simon,
   now that RZ/A1 pin controller is merged, it's time to enable some peripheral
devices on GR-Peach has it has been done for Genmai and RSK boards.

The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
be defined in r7s72100.dtsi.

Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
traffic on that. I can set the ip address and probe the device and double
checked the pin configuration process against u-boot sources (where the
interface is working instead). Sending the patch anyway and let you decide what
to do with that.

Thanks
   j

Jacopo Mondi (4):
  arm: dts: gr-peach: Remove empty line
  arm: dts: gr-peach: Add SCIF2 pin group
  arm: dts: gr-peach: Add ETHER pin group
  arm: dts: gr-peach: Add user led device nodes

 arch/arm/boot/dts/r7s72100-gr-peach.dts | 57 -
 1 file changed, 56 insertions(+), 1 deletion(-)

--
2.7.4

[PATCH 1/4] arm: dts: gr-peach: Remove empty line

[Jacopo Mondi]

Remove an empty line in gr-peach device tree source file.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts 
b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index a1b2aef9..1c40a1a 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -28,7 +28,6 @@
memory@2000 {
device_type = "memory";
reg = <0x2000 0x00a0>;
-
};
 
lbsc {
-- 
2.7.4

Re: [PATCH 4/4] v4l: async: add comment about re-probing to v4l2_async_notifier_unregister()

[Hans Verkuil]

On 08/23/17 21:03, Niklas Söderlund wrote:
> Hi,
> 
> On 2017-08-18 15:42:37 +0200, Niklas Söderlund wrote:
>> Hi Sakari and Laurent,
>>
>> Thanks for your feedback.
>>
>> On 2017-08-18 14:20:08 +0300, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> On Tuesday 15 Aug 2017 19:09:33 Sakari Ailus wrote:
 On Mon, Jul 31, 2017 at 12:31:58AM +0200, Niklas Söderlund wrote:
> The re-probing of subdevices when unregistering a notifier is tricky to
> understand, and implemented somewhat as a hack. Add a comment trying to
> explain why the re-probing is needed in the first place and why existing
> helper functions can't be used in this situation.
>
> Signed-off-by: Niklas Söderlund 
> ---
>
>  drivers/media/v4l2-core/v4l2-async.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-async.c
> b/drivers/media/v4l2-core/v4l2-async.c index
> d91ff0a33fd3eaff..a3c5a1f6d4d2ab03 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -234,6 +234,23 @@ void v4l2_async_notifier_unregister(struct
> v4l2_async_notifier *notifier)> 
>   mutex_unlock(_lock);
>
> + /*
> +  * Try to re-probe the subdevices which where part of the notifier.
> +  * This is done so subdevices which where part of the notifier will
> +  * be re-probed to a pristine state and put back on the global
> +  * list of subdevices so they can once more be found and associated
> +  * with a new notifier.

 Instead of tweaking the code trying to handle unhandleable error conditions
 in notifier unregistration and adding lengthy stories on why this is done
 the way it is, could we simply get rid of the driver re-probing?

 I can't see why drivers shouldn't simply cope with the current interfaces
 without re-probing to which I've never seen any reasoned cause. When a
 sub-device driver is unbound, simply return the sub-device node to the list
 of async sub-devices.
>>>
>>> I agree, this is a hack that we should get rid of. Reprobing has been there 
>>> from the very beginning, it's now 4 years and a half old, let's allow it to 
>>> retire :-)
>>
>> I would also be happy to see this code go away :-)
>>
>>>
 Or can someone come up with a valid reason why the re-probing code should
 stay? :-)
>>
>> Hans kindly dug out the original reason talking about why this code was 
>> added in the first place at
>>
>> http://lkml.iu.edu/hypermail/linux/kernel/1210.2/00713.html
>>
>> I would also like record here what Laurent stated about this after 
>> reading the above on #v4l 
>>
>> 13:53  pinchartl : what could happen is this
>> 13:53  pinchartl : the master could export resources used by the subdev
>> 13:53  pinchartl : the omap3 isp driver, for instance, is a clock source
>> 13:54  pinchartl : and the clock can be used by sensors
>> 13:54  pinchartl : so if you remove the omap3 isp, the clock won't be 
>>there anymore
>> 13:54  pinchartl : and that's bad for the subdev
>>
>>
>> I don't claim I fully understand all the consequences of removing this 
>> reprobing now. But maybe it's safer to lave the current behavior in for 
>> now until the full problem is understood and move forward whit these 
>> patches since at least they document the behavior and removes another 
>> funky bit when trying to handle the situation where the memory 
>> allocation fails? What do you guys think?
> 
> Any thoughts about how I can move forward with this? The reason I'm 
> asking is that this is a dependency for the sub-notifier patches which 
> in turn is dependency for the R-Car CSI-2 driver :-) If someone wants to 
> think more about this that is fine I just don't want it to be forgotten.  
> As I see it these are the options open to me, but as always I'm always 
> open to other solutions which I'm to narrow minded to see :-)
> 
> - If after the latest discussions it feels the safest option is to keep 
>   the re-probe logic but separating the v4l2 housekeeping from re-probe 
>   logic move forward with this series as-is.

I prefer this. We can always remove the reprobe code later once we have
a better understanding. I see no downside to this cleanup series and it
doesn't block any future development.

> - Post 1/4 separately and repost patch 2/4 -- 4/4 in a v2 to allow for 
>   more input on what is the right thing to do here.

I'm OK with this as well, we missed the 4.14 merge window anyway.

> - Post 1/4 separately, drop patch 2/4 -- 4/4 and create a new patch 
>   which removes all re-probe related code and post that as a new patch.  
>   I would feel a but uneasy about this without a consensus from all you 
>   guys since I don't understand all the ramifications in doing so.

I'm uneasy about this as well.

> - Post 1/4 separately, drop patch 2/4 -- 4/4 and try to rework the 
>   sub-notifier code to