Re: [PATCH can-next 1/2] CAN: rcar: add gen[12] fallback compatibility strings

On 02/22/2016 04:37 AM, Rob Herring wrote: > On Mon, Feb 22, 2016 at 11:15:49AM +0900, Simon Horman wrote: >> Add fallback compatibility string for R-Car Gen 1 and Gen2 families. >> This is in keeping with the fallback scheme being adopted wherever >> appropriate for drivers for Renesas SoCs. >>

[RFD] Sharing GPIOs for input (buttons) and output (LEDs)

TL;DR: If a GPIO is connected to both a push button and an LED, can we (1) still use both, or can we (2) chose which one to use? This affects both the hardware description in DT and user policies. Introduction On the Renesas Salvator-X development board, 3 GPIO pins are connected

Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS

Hi Simon, On Tuesday 23 February 2016 09:11:03 Simon Horman wrote: > On Mon, Feb 22, 2016 at 03:05:58PM +0200, Laurent Pinchart wrote: > > On Monday 22 February 2016 13:39:37 Geert Uytterhoeven wrote: > >> On Mon, Feb 22, 2016 at 1:24 PM, Laurent Pinchart wrote: > >>> On Monday 22 February 2016

Re: [PATCH][CFT]: dmaengine: make slave address physical

On Mon, Feb 22, 2016 at 09:37:10AM +0100, Geert Uytterhoeven wrote: > Hi Vinod, > > On Sun, Feb 21, 2016 at 4:20 PM, Vinod Koul wrote: > > The slave dmaengine semantics required the client to map dma > > addresses and pass DMA address to dmaengine drivers. While this > >

Re: [RFC/PATCH] [media] rcar-vin: add Renesas R-Car VIN IP core

On Sun, Feb 14, 2016 at 5:55 PM, Niklas Söderlund wrote: > Also I > could only get frames if the video signal on the composite IN was NTSC, > but this also applied to the soc_camera driver, it might be my test > setup. I think it is. For me, PAL works just

Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS

Hi Geert, On Monday 22 February 2016 13:39:37 Geert Uytterhoeven wrote: > On Mon, Feb 22, 2016 at 1:24 PM, Laurent Pinchart wrote: > > On Monday 22 February 2016 10:59:51 Simon Horman wrote: > >> Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > >> > >> This is part of an ongoing process to

Re: [PATCH] iommu: ipmmu-vmsa: Use ARCH_RENESAS

On Mon, Feb 22, 2016 at 2:41 AM, Simon Horman wrote: > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more >

Re: [PATCH] i2c: riic, sh_mobile, rcar: Use ARCH_RENESAS

On Mon, Feb 22, 2016 at 2:15 AM, Simon Horman wrote: > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more >

Re: [RFC/PATCH] [media] rcar-vin: add Renesas R-Car VIN IP core

On 2016-02-22 14:31:29 +0100, Ulrich Hecht wrote: > On Sun, Feb 14, 2016 at 5:55 PM, Niklas Söderlund > wrote: > > Also I > > could only get frames if the video signal on the composite IN was NTSC, > > but this also applied to the soc_camera driver, it might

Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS

Hi Laurent, On Mon, Feb 22, 2016 at 1:24 PM, Laurent Pinchart wrote: > On Monday 22 February 2016 10:59:51 Simon Horman wrote: >> Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. >> >> This is part of an ongoing process to migrate from ARCH_SHMOBILE to >>

[RFC] Revert "ARM: shmobile: defconfig: Do not enable CONFIG_CPU_BPREDICT_DISABLE"

From: Wolfram Sang This reverts commit 406663ed61c8ad2b792824af1c1bc0e4faa711c6. With BPREDICT enabled, my Lager board can't boot anymore and gets stuck early in the boot process (mostly without any printout, sometimes with a little printout) Signed-off-by:

Re: [PATCH][CFT]: dmaengine: make slave address physical

On Mon, Feb 22, 2016 at 10:49:08AM +0100, Niklas Söderlund wrote: > Hi Vinod, > > On 2016-02-21 20:50:46 +0530, Vinod Koul wrote: > > The slave dmaengine semantics required the client to map dma > > addresses and pass DMA address to dmaengine drivers. While this > > was a convenient notion coming

Re: [RFC] Revert "ARM: shmobile: defconfig: Do not enable CONFIG_CPU_BPREDICT_DISABLE"

> > This reverts commit 406663ed61c8ad2b792824af1c1bc0e4faa711c6. With > > BPREDICT enabled, my Lager board can't boot anymore and gets stuck > > early in the boot process (mostly without any printout, sometimes with a > > little printout) > > And it just stops without printing anything special?

Re: [PATCH][CFT]: dmaengine: make slave address physical

> > But in case of slave, we know the dmaengine and always use a > > specific one. Further the IOMMU cases can lead to failure of this > > notion, so make this as physical address and now dmaengine driver > > will do the required mapping. > > You could also add "This finally bring the code in

Re: [PATCH] iommu: ipmmu-vmsa: Use ARCH_RENESAS

Hi Simon, Thank you for the patch. On Monday 22 February 2016 10:41:35 Simon Horman wrote: > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more

Re: [RFC] Revert "ARM: shmobile: defconfig: Do not enable CONFIG_CPU_BPREDICT_DISABLE"

Hi Wolfram, On Mon, Feb 22, 2016 at 3:10 PM, Wolfram Sang wrote: > From: Wolfram Sang > > This reverts commit 406663ed61c8ad2b792824af1c1bc0e4faa711c6. With > BPREDICT enabled, my Lager board can't boot anymore and gets stuck > early in the

Re: [PATCH][CFT]: dmaengine: make slave address physical

Hi Vinod, On Sunday 21 February 2016 20:50:46 Vinod Koul wrote: > The slave dmaengine semantics required the client to map dma > addresses and pass DMA address to dmaengine drivers. While this s/While this/This/ ? > was a convenient notion coming from generic dma offload cases > where

Re: [PATCH][CFT]: dmaengine: make slave address physical

On Monday 22 February 2016 13:31:04 Wolfram Sang wrote: > > > > Original-patch-by: Linus Walleij > > > > You've dropped a few > > > > Original-patch-acked-by: Lee Jones > > Original-patch-acked-by: Arnd Bergmann > > I'd

[PATCH] drm: rcar-du: Use ARCH_RENESAS

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Signed-off-by: Simon

[PATCH 2/2] arm64: dts: r8a7795: use fallback etheravb compatibility string

Use recently added fallback compatibility string in r8a7795 device tree. Signed-off-by: Simon Horman --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi

Re: [PATCH 0/2] ARM: shmobile: use Lager as reference for I2C slave and core switch

> My feeling is yes for consistency. Yes, valid point. > Are you concerned about bloat in multiv7_defconfig? To be honest, I forgot my reasoning for not doing it :) It was surely not bloat of multi_v7. If I can't remember it tomorrow, I'll just send a patch. > Sure, I have tentatively queued

[PATCH] clk: shmobile: Remove ARCH_SHMOBILE_MULTI

As of 9b5ba0df4ea4 ("ARM: shmobile: Introduce ARCH_RENESAS") all platforms that use Renesas clock drivers now select ARCH_RENESAS. As it is present in drivers/clk/Makefile ARCH_SHMOBILE_MULTI may now be removed. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the

Re: [PATCH can-next 1/2] CAN: rcar: add gen[12] fallback compatibility strings

On Mon, Feb 22, 2016 at 04:40:39PM +0100, Geert Uytterhoeven wrote: > On Mon, Feb 22, 2016 at 3:15 AM, Simon Horman > wrote: > > Add fallback compatibility string for R-Car Gen 1 and Gen2 families. > > This is in keeping with the fallback scheme being adopted wherever

[PATCH] gpio: rcar: Use ARCH_RENESAS

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Signed-off-by: Simon

RE: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling

Hi Kishon, Would you review this patch? I checked the latest linux-phy.git / next branch today, this patch can be applied on the top of branch. commit 6b825eb7323a634cdd1014a4aa9a8ff07cf8040c Author: Heiko Stuebner Date: Mon Feb 22 12:55:01 2016 +0100 phy: rockchip-usb:

Re: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling

Hi, On Tuesday 23 February 2016 11:54 AM, Yoshihiro Shimoda wrote: > Hi Kishon, > > Would you review this patch? merged it now. Thanks for reminding. -Kishon > > I checked the latest linux-phy.git / next branch today, > this patch can be applied on the top of branch. > > commit

Re: [PATCH] drm: rcar-du: Use ARCH_RENESAS

Hi Simon, Thank you for the patch. On Tuesday 23 February 2016 10:06:12 Simon Horman wrote: > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more

[PATCH/RFC v2 0/9] Add support for USB2.0 host/peripheral on R-Car H3

This patch set is based on the renesas-drivers.git / renesas-drivers-2016-02-16-v4.5-rc4 tag (commit id = a633abe6e6393c60417bd8cb0cf82f3297740198), and the following patches: [ renesas_usbhs driver ]

[PATCH/RFC v2 2/9] phy: rcar-gen3-usb2: Add vbus-supply to handle VBUS on/off

To handle the VBUS on/off by a regulator driver, this patch adds regulator APIs calling in the driver and description about vbus-supply in the rcar-gen3-phy-usb2.txt. Signed-off-by: Yoshihiro Shimoda --- .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2

[PATCH/RFC v2 3/9] phy: rcar-gen3-usb2: add extcon support

This patch adds extcon support for otg related channel. Signed-off-by: Yoshihiro Shimoda --- drivers/phy/Kconfig | 1 + drivers/phy/phy-rcar-gen3-usb2.c | 26 ++ 2 files changed, 27 insertions(+) diff --git

[PATCH/RFC v2 5/9] arm64: dts: r8a7795: add USB2.0 Host (EHCI/OHCI) device nodes

Signed-off-by: Yoshihiro Shimoda --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 66 1 file changed, 66 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index

[PATCH/RFC v2 6/9] arm64: dts: r8a7795: add HS-USB device node

Signed-off-by: Yoshihiro Shimoda --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index 75142f3..76ad097 100644

Re: [PATCH RESEND 3/3] arm64: dts: r8a7795: salvator-x: enable SDHI0 & 3

> There was a syntax error in my previous effort. > Please look over this one instead. Yeah, wit the missing '}' it's even better ;) signature.asc Description: PGP signature

Re: [PATCH][CFT]: dmaengine: make slave address physical

Hi Vinod, On Sun, Feb 21, 2016 at 4:20 PM, Vinod Koul wrote: > The slave dmaengine semantics required the client to map dma > addresses and pass DMA address to dmaengine drivers. While this > was a convenient notion coming from generic dma offload cases > where dmaengines

Re: [PATCH RESEND 3/3] arm64: dts: r8a7795: salvator-x: enable SDHI0 & 3

> I have queued up the following after resolving a minor conflict. > There was also some fuzz when I applied patch 2/2 so I'd appreciate it if > you could double check that too. Looks good to me. Thanks! signature.asc Description: PGP signature