Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS

[Laurent Pinchart]

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 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
>  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 Horman 
> >>> 
> >>> Wouldn't it make sense to drop the driver instead ? We have a DRM
> >>> driver that replaces it.
> >> 
> >> Does the DRM driver work on all hardware supported by the fbdev driver?
> >> It's not only used on r8a7740/armadillo (through staging/board due to
> >> lack of DT support), but also on many SH boards.
> > 
> > It's supposed to be a replacement (lacking support for SYS panels though),
> > but has obviously not been tested on SH boards.
> 
> From my point of view it would be overreach to remove the driver as we
> aren't in a position to test the SH boards.

I'd be surprised if the driver still worked on those boards, but I like good 
surprises :-)

> We could stop using it on the Renesas ARM SoCs and in turn remove
> ARCH_SHMOBILE/ARCH_RENESAS. Am I right in thinking that would only
> effect the r8a7740/armadillo at this time?

That's correct.

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

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
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> 
> Signed-off-by: Simon Horman 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  Based on drm-next
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> b/drivers/gpu/drm/rcar-du/Kconfig index 96dcd4a78951..4af0db0d08a1 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -1,7 +1,7 @@
>  config DRM_RCAR_DU
>   tristate "DRM Support for R-Car Display Unit"
>   depends on DRM && ARM && OF
> - depends on ARCH_SHMOBILE || COMPILE_TEST
> + depends on ARCH_RENESAS || COMPILE_TEST
>   select DRM_KMS_HELPER
>   select DRM_KMS_CMA_HELPER
>   select DRM_GEM_CMA_HELPER

-- 
Regards,

Laurent Pinchart

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

[Kishon Vijay Abraham I]

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 6b825eb7323a634cdd1014a4aa9a8ff07cf8040c
> Author: Heiko Stuebner 
> Date:   Mon Feb 22 12:55:01 2016 +0100
> 
> phy: rockchip-usb: add handler for usb-uart functionality
> 
> Best regards,
> Yoshihiro Shimoda
> 
>> -Original Message-
>> From: Yoshihiro Shimoda
>> Sent: Tuesday, February 02, 2016 5:29 PM
>> To: kis...@ti.com
>> Cc: pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; 
>> ga...@codeaurora.org;
>> linux-ker...@vger.kernel.org; devicet...@vger.kernel.org; 
>> linux...@vger.kernel.org; 'Rob Herring' ;
>> linux-renesas-soc@vger.kernel.org
>> Subject: 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, and it is the same 
>> as the following.
>>
  This patch is based on the linux-phy / next branch.
  (commit id = 9955a7835bf376e12482583958b2661f501b868b)
>>
>> Best regards,
>> Yoshihiro Shimoda
>>
>>> From: Rob Herring [mailto:r...@kernel.org]
>>> Sent: Sunday, January 10, 2016 7:33 AM
>>> To: Yoshihiro Shimoda 
>>> Cc: kis...@ti.com; pawel.m...@arm.com; mark.rutl...@arm.com; 
>>> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
>>> linux-ker...@vger.kernel.org; devicet...@vger.kernel.org; 
>>> linux...@vger.kernel.org
>>> Subject: Re: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling
>>>
>>> On Thu, Jan 07, 2016 at 06:16:44PM +0900, Yoshihiro Shimoda wrote:
 Since the related driver (CPG/MSSR driver) only manages the first module
 clock, this driver should not handle the HSUSB registers. So, this patch
 removes the HSUSB registers handling.

 Signed-off-by: Yoshihiro Shimoda 
 ---
  This patch is based on the linux-phy / next branch.
  (commit id = 9955a7835bf376e12482583958b2661f501b868b)

  .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 15 ++--
>>>
>>> Acked-by: Rob Herring 
>>>
  drivers/phy/phy-rcar-gen3-usb2.c   | 83 
 +++---
  2 files changed, 15 insertions(+), 83 deletions(-)
>>>
> 

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

[Yoshihiro Shimoda]

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: add handler for usb-uart functionality

Best regards,
Yoshihiro Shimoda

> -Original Message-
> From: Yoshihiro Shimoda
> Sent: Tuesday, February 02, 2016 5:29 PM
> To: kis...@ti.com
> Cc: pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; 
> ga...@codeaurora.org;
> linux-ker...@vger.kernel.org; devicet...@vger.kernel.org; 
> linux...@vger.kernel.org; 'Rob Herring' ;
> linux-renesas-soc@vger.kernel.org
> Subject: 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, and it is the same as 
> the following.
> 
> > >  This patch is based on the linux-phy / next branch.
> > >  (commit id = 9955a7835bf376e12482583958b2661f501b868b)
> 
> Best regards,
> Yoshihiro Shimoda
> 
> > From: Rob Herring [mailto:r...@kernel.org]
> > Sent: Sunday, January 10, 2016 7:33 AM
> > To: Yoshihiro Shimoda 
> > Cc: kis...@ti.com; pawel.m...@arm.com; mark.rutl...@arm.com; 
> > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
> > linux-ker...@vger.kernel.org; devicet...@vger.kernel.org; 
> > linux...@vger.kernel.org
> > Subject: Re: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling
> >
> > On Thu, Jan 07, 2016 at 06:16:44PM +0900, Yoshihiro Shimoda wrote:
> > > Since the related driver (CPG/MSSR driver) only manages the first module
> > > clock, this driver should not handle the HSUSB registers. So, this patch
> > > removes the HSUSB registers handling.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >  This patch is based on the linux-phy / next branch.
> > >  (commit id = 9955a7835bf376e12482583958b2661f501b868b)
> > >
> > >  .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 15 ++--
> >
> > Acked-by: Rob Herring 
> >
> > >  drivers/phy/phy-rcar-gen3-usb2.c   | 83 
> > > +++---
> > >  2 files changed, 15 insertions(+), 83 deletions(-)
> >

[PATCH] gpio: rcar: Use ARCH_RENESAS

[Simon Horman]

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 Horman 
---
 drivers/gpio/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ad226485a8e4..5584ba457161 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -351,7 +351,7 @@ config GPIO_PXA
 
 config GPIO_RCAR
tristate "Renesas R-Car GPIO"
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say yes here to support GPIO on Renesas R-Car SoCs.
-- 
2.1.4

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

[Simon Horman]

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 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index c2bffd160c18..39d6dc104206 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -473,7 +473,8 @@
};
 
avb: ethernet@e680 {
-   compatible = "renesas,etheravb-r8a7795";
+   compatible = "renesas,etheravb-r8a7795",
+"renesas,etheravb-rcar-gen3",
reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
interrupts = ,
 ,
-- 
2.1.4

[PATCH] drm: rcar-du: Use ARCH_RENESAS

[Simon Horman]

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 Horman 
---
 drivers/gpu/drm/rcar-du/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

 Based on drm-next

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 96dcd4a78951..4af0db0d08a1 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -1,7 +1,7 @@
 config DRM_RCAR_DU
tristate "DRM Support for R-Car Display Unit"
depends on DRM && ARM && OF
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
-- 
2.1.4

[PATCH] clk: shmobile: Remove ARCH_SHMOBILE_MULTI

[Simon Horman]

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 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 Horman 
---
 drivers/clk/Makefile | 1 -
 1 file changed, 1 deletion(-)

 Based on clk-next

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index bae4be6501df..b19af449d2f3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -70,7 +70,6 @@ obj-$(CONFIG_COMMON_CLK_PXA)  += pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_COMMON_CLK_SAMSUNG)   += samsung/
-obj-$(CONFIG_ARCH_SHMOBILE_MULTI)  += shmobile/
 obj-$(CONFIG_ARCH_RENESAS) += shmobile/
 obj-$(CONFIG_ARCH_SIRF)+= sirf/
 obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
-- 
2.1.4

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

[Wolfram Sang]

> 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 this up for v4.6.

Thanks!



signature.asc
Description: PGP signature

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

[Simon Horman]

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
> > appropriate for drivers for Renesas SoCs.
> >
> > Signed-off-by: Simon Horman 
> > ---
> >  Documentation/devicetree/bindings/net/can/rcar_can.txt | 4 +++-
> >  drivers/net/can/rcar_can.c | 2 ++
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt 
> > b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > index 002d8440bf66..036786e1f70d 100644
> > --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > @@ -6,6 +6,8 @@ Required properties:
> >   "renesas,can-r8a7779" if CAN controller is a part of R8A7779 
> > SoC.
> >   "renesas,can-r8a7790" if CAN controller is a part of R8A7790 
> > SoC.
> >   "renesas,can-r8a7791" if CAN controller is a part of R8A7791 
> > SoC.
> > + "renesas,can-gen1" for a generic R-Car Gen1 compatible device.
> > + "renesas,can-gen2" for a generic R-Car Gen2 compatible device.
> 
> "renesas,rcar-gen1-can", "renesas,rcar-gen2-can"?
> 
> (Yeah, "can" looks a lot like "rcar" ;-)

Sure, I'll update that as you suggest.

> Nothing further to say about SoC-specific vs. generic compatible values?

Sure, I'll add some text about that.

> >  - reg: physical base address and size of the R-Car CAN register map.
> >  - interrupts: interrupt specifier for the sole interrupt.
> >  - clocks: phandles and clock specifiers for 3 CAN clock inputs.
> > @@ -25,7 +27,7 @@ Example
> >  SoC common .dtsi file:
> >
> > can0: can@e6e8 {
> > -   compatible = "renesas,can-r8a7791";
> > +   compatible = "renesas,can-r8a7791", "renesas,can-gen2";
> 
> "renesas,rcar-gen2-can".
> 
> > reg = <0 0xe6e8 0 0x1000>;
> > interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = <_clks R8A7791_CLK_RCAN0>,
> > diff --git a/drivers/net/can/rcar_can.c b/drivers/net/can/rcar_can.c
> > index bc46be39549d..c70a1f795933 100644
> > --- a/drivers/net/can/rcar_can.c
> > +++ b/drivers/net/can/rcar_can.c
> > @@ -904,6 +904,8 @@ static const struct of_device_id rcar_can_of_table[] 
> > __maybe_unused = {
> > { .compatible = "renesas,can-r8a7779" },
> > { .compatible = "renesas,can-r8a7790" },
> > { .compatible = "renesas,can-r8a7791" },
> > +   { .compatible = "renesas,can-gen1" },
> > +   { .compatible = "renesas,can-gen2" },
> 
> "renesas,rcar-gen1-can"
> "renesas,rcar-gen2-can".
> 
> 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: [RFC] Revert "ARM: shmobile: defconfig: Do not enable CONFIG_CPU_BPREDICT_DISABLE"

[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)
> 
> And it just stops without printing anything special?

Yes. The only notable difference I recognized in the output was the set
bit for branch prediction in the cr register output. That's why I
assumed this commit to be guilty...

> 
> > Signed-off-by: Wolfram Sang 
> 
> I suspect you're bitten by the issue from "RCU lockup? (was: Re: [PATCH v2
> tip/core/rcu 10/14] rcu: Don't redundantly disable irqs in
> rcu_irq_{enter,exit}())" 
> (http://www.spinics.net/lists/kernel/msg2167464.html).

... but it seems you are right on the spot here. Thanks!

> Does it help if you add a function
> 
> void filler(void)
> {
> asm("nop");
> asm("nop");
> }

Adding 21 nops made the board boot again. (Wow, adding NOPs everywhere
really feels like hacking the Commodore 64 when trying to get the timing
stable :D)

This is gonna be a nasty one :(



signature.asc
Description: PGP signature

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

[Vinod Koul]

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 from generic dma offload cases
> > where dmaengines are interchangeable and client is not aware of
> > which engine to map to.
> >
> > 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.
> 
> Thanks! I have tested this patch with my IOMMU series and it works
> nicely.
> 
> >
> > Original-patch-by: Linus Walleij 
> > Signed-off-by: Vinod Koul 
> 
> Tested-by: Niklas Söderlund 

Thanks :)

> 
> > ---
> >  include/linux/dmaengine.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index 16a1cad30c33..d85ecd20af50 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -357,8 +357,8 @@ enum dma_slave_buswidth {
> >   */
> >  struct dma_slave_config {
> > enum dma_transfer_direction direction;
> > -   dma_addr_t src_addr;
> > -   dma_addr_t dst_addr;
> > +   phys_addr_t src_addr;
> > +   phys_addr_t dst_addr;
> > enum dma_slave_buswidth src_addr_width;
> > enum dma_slave_buswidth dst_addr_width;
> > u32 src_maxburst;
> 
> --
> Regards,
> Niklas Söderlund
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
~Vinod

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

[Geert Uytterhoeven]

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 boot process (mostly without any printout, sometimes with a
> little printout)

And it just stops without printing anything special?

> Signed-off-by: Wolfram Sang 

I suspect you're bitten by the issue from "RCU lockup? (was: Re: [PATCH v2
tip/core/rcu 10/14] rcu: Don't redundantly disable irqs in
rcu_irq_{enter,exit}())" (http://www.spinics.net/lists/kernel/msg2167464.html).

At one point, I also thought it was related to CONFIG_CPU_BPREDICT_DISABLE,
but then I managed to reproduce the issue with that option disabled.
I suspect the issue is just more likely to happen with
CONFIG_CPU_BPREDICT_DISABLE=y.

Does it help if you add a function

void filler(void)
{
asm("nop");
asm("nop");
}

to a file under arch/arm/mach-shmobile/?

What I saw was that the failure mode depends on the number of NOPs.
Sometimes it hangs early, sometimes it continues and hangs later,
sometimes it works reliably.

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][CFT]: dmaengine: make slave address physical

[Arnd Bergmann]

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 vote for dropping the "Original-patch-" prefix and keep the original
> SoB and Acks because the content of the patch is still the same. And
> while the new commit message is a lot more precise, it is also in the
> same spirit as the old one.
> 
> That being said:
> 
> Acked-by: Wolfram Sang 
> Tested-by: Wolfram Sang 
> 
> I tested it on my Lager board on top of my sdhi-uhs testing branch and
> used DMA with SD cards and for I2C transfers. No regressions seen. Also
> no build warnings.
> 

Acked-by: Arnd Bergmann 

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

[Laurent Pinchart]

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
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> 
> Signed-off-by: Simon Horman 

Acked-by: Laurent Pinchart 

> ---
>  drivers/iommu/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  Based on the next branch of Joerg's iommu tree on kernel.org
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index a1e75cba18e0..d4b38e4d27fe 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -266,7 +266,7 @@ config EXYNOS_IOMMU_DEBUG
>  config IPMMU_VMSA
>   bool "Renesas VMSA-compatible IPMMU"
>   depends on ARM_LPAE
> - depends on ARCH_SHMOBILE || COMPILE_TEST
> + depends on ARCH_RENESAS || COMPILE_TEST
>   select IOMMU_API
>   select IOMMU_IO_PGTABLE_LPAE
>   select ARM_DMA_USE_IOMMU

-- 
Regards,

Laurent Pinchart

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

[Wolfram Sang]

> > 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 sync with the 
> documentation.".

s/finally bring/also brings/ ?



signature.asc
Description: PGP signature

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

[Laurent Pinchart]

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 dmaengines are interchangeable and client is not aware of
> which engine to map to.
> 
> 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 sync with the 
documentation.".

> Original-patch-by: Linus Walleij 
> Signed-off-by: Vinod Koul 

It took a long time but we finally got there :-) Thank you.

Reviewed-by: Laurent Pinchart 

> ---
>  include/linux/dmaengine.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 16a1cad30c33..d85ecd20af50 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -357,8 +357,8 @@ enum dma_slave_buswidth {
>   */
>  struct dma_slave_config {
>   enum dma_transfer_direction direction;
> - dma_addr_t src_addr;
> - dma_addr_t dst_addr;
> + phys_addr_t src_addr;
> + phys_addr_t dst_addr;
>   enum dma_slave_buswidth src_addr_width;
>   enum dma_slave_buswidth dst_addr_width;
>   u32 src_maxburst;

-- 
Regards,

Laurent Pinchart

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

[Niklas Söderlund]

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 be my test
> > setup.
>
> I think it is.  For me, PAL works just as well as NTSC.

Yes it must have been my setup, I'm now using a PAL SNES as my video
source and it works fine. I'm about ready to send out a v2 of this patch
with all of Hans comments fixed. I only need to look at
vidioc_[gs]_selection.

It took some extra time since I found some bugs in how I handled DMA and
that I had been to libera in porting the format code from soc-camera.
It's all fixed and all v4l2-compliance tests I tried works.

One concern I have is that I can't get some of the formats to display
properly in qv4l2 (V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_RGB555X,
V4L2_PIX_FMT_RGB32) but I get the same 'errors' in the feed as I do with
the soc-camera driver so I'm not spending so much time on the issue right
now.

Unfortunate the rework I have done clashes with your HDMI series Ulrich.
If you wish I can rework the parts of your series that touches rcar-vin
and post them as a separate series after v2? Let me know what you think.

--
Regards,
Niklas Söderlund

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

[Wolfram Sang]

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: Wolfram Sang 
---

Let me know if I can do something to give you more information. Maybe we can
resolve it differently. But as it stands now, it is a regression.

 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index b7b714c3958c2f..6582b88e30672e 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -20,6 +20,7 @@ CONFIG_ARCH_R8A7791=y
 CONFIG_ARCH_R8A7793=y
 CONFIG_ARCH_R8A7794=y
 CONFIG_ARCH_SH73A0=y
+CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
 CONFIG_PCI=y
-- 
2.7.0

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

[Geert Uytterhoeven]

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
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>
> Signed-off-by: Simon Horman 

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

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

[Geert Uytterhoeven]

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
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>
> Signed-off-by: Simon Horman 

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

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

[Ulrich Hecht]

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 as well as NTSC.

CU
Uli

Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS

[Laurent Pinchart]

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 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 Horman 
> > 
> > Wouldn't it make sense to drop the driver instead ? We have a DRM driver
> > that replaces it.
> 
> Does the DRM driver work on all hardware supported by the fbdev driver?
> It's not only used on r8a7740/armadillo (through staging/board due to lack
> of DT support), but also on many SH boards.

It's supposed to be a replacement (lacking support for SYS panels though), but 
has obviously not been tested on SH boards.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS

[Geert Uytterhoeven]

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
>> 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 Horman 
>
> Wouldn't it make sense to drop the driver instead ? We have a DRM driver that
> replaces it.

Does the DRM driver work on all hardware supported by the fbdev driver?
It's not only used on r8a7740/armadillo (through staging/board due to lack of
DT support), but also on many SH boards.

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][CFT]: dmaengine: make slave address physical

[Wolfram Sang]

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
> > was a convenient notion coming from generic dma offload cases
> > where dmaengines are interchangeable and client is not aware of
> > which engine to map to.
> >
> > 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.
> 
> Thanks a lot!

Yes, thanks!

> > Original-patch-by: Linus Walleij 
> 
> You've dropped a few ;-)
> 
> Original-patch-acked-by: Lee Jones 
> Original-patch-acked-by: Arnd Bergmann 

I'd vote for dropping the "Original-patch-" prefix and keep the original
SoB and Acks because the content of the patch is still the same. And
while the new commit message is a lot more precise, it is also in the
same spirit as the old one.

That being said:

Acked-by: Wolfram Sang 
Tested-by: Wolfram Sang 

I tested it on my Lager board on top of my sdhi-uhs testing branch and
used DMA with SD cards and for I2C transfers. No regressions seen. Also
no build warnings.

Regards,

   Wolfram



signature.asc
Description: PGP signature

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

[Geert Uytterhoeven]

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 to both
push buttons and LEDs.
  - If the GPIO is configured for output, it can control the LED,
  - If the GPIO is configured for input, the push button status can be
read. Note that the LED is on if the push button is not pressed; it is
turned off while holding the button.


DT Hardware Description
---

There exist device tree bindings for push buttons connected to GPIOs,
and the following works:

keyboard {
compatible = "gpio-keys";

key-a {
gpios = < 11 GPIO_ACTIVE_LOW>;
label = "SW20";
wakeup-source;
linux,code = ;
};
key-b {
gpios = < 12 GPIO_ACTIVE_LOW>;
label = "SW21";
wakeup-source;
linux,code = ;
};
key-c {
gpios = < 13 GPIO_ACTIVE_LOW>;
label = "SW22";
wakeup-source;
linux,code = ;
};
};


There exist device tree bindings for LEDs connected to GPIOs, and the
following also works:

leds {
compatible = "gpio-leds";

led4 {
gpios = < 11 GPIO_ACTIVE_HIGH>;
label = "LED4";
};
led5 {
gpios = < 12 GPIO_ACTIVE_HIGH>;
label = "LED5";
};
led6 {
gpios = < 13 GPIO_ACTIVE_HIGH>;
label = "LED6";
};
};


However, having both in the DTS doesn't mean you'll have working buttons
and LEDs. The first driver initialized will bind to the GPIOs. The
second driver will fail to initialize as the GPIOs are already busy.

One option to solve this is to introduce new bindings for GPIOs shared
by push buttons and LEDs. But that isn't without its own set of
problems. E.g. in my case the buttons use GPIO_ACTIVE_LOW, while the
LEDs use GPIO_ACTIVE_HIGH (I'm sure other combinations are possible),
which is supposed to be encoded in the GPIO descriptor.

Hence I'm inclined to keep the existing bindings, as they do describe
the hardware.


Device Driver
-

As a proof-of-concept, I hacked up a new driver that binds to both
"gpio-keys" and "gpio-leds", by combining the existing gpio-keys-polled
and gpio-leds drivers.

If a GPIO is found busy during initialization, and if it's already in
use by the other half of the driver, the driver switches to a special
"polled-key-and-LED" mode. I.e. during polling, it does:
  - Save the GPIO output state,
  - Switch the GPIO to input mode,
  - Wait 5 ms (else it will read the old output state, depending on
e.g. hardware capacitance),
  - Read the GPIO input state,
  - Switch the GPIO to output mode,
  - Restore the GPIO output state.

And it works, the LEDs can be controlled, and the push button states can
be read!

However, due to the 5 ms delay, there's a visible flickering of LEDs
that are supposed to be turned off (remember, when the GPIO is
configured for input and the button is not pressed, the LED is lit).

If we go this route, adding support for non-polled GPIOs (if the GPIO is
not shared with an LED) and wake-up should be doable.


User Policies
-

Hence we can have support for GPIOs connected to both push buttons and
LEDs. But perhaps the user doesn't want to use both at the same time,
or not for all GPIOs. On a final product this is probably not the case,
but it is on a development board like Salvator-X.

If it wasn't for the visible flickering when both are enabled, this
wouldn't matter. But the flickering may be considered annoying, so it
would be good if the user could disable either the push button or LED by
software.

One option is to disable the keyboard node using a DT overlay. But
that's cheating, as it modifies the hardware description, while this is
clearly a user policy.

Another use case would be to use the LEDs, and not the buttons, except
for system wake-up. Then there wouldn't be a need to poll during normal
system operation.


Thanks for your comments!

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 can-next 1/2] CAN: rcar: add gen[12] fallback compatibility strings

[Marc Kleine-Budde]

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.
>>
>> Signed-off-by: Simon Horman 
>> ---
>>  Documentation/devicetree/bindings/net/can/rcar_can.txt | 4 +++-
>>  drivers/net/can/rcar_can.c | 2 ++
>>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> Acked-by: Rob Herring 

I'm not following the latest DT discussions, is there a (new) decision
to add such "generic" compatibles? AFAIK you add the oldest device
that's compatible with your driver to your SoC dtsi at rightmost
compatible. You can add one that identifies your SoC's IP core in front
of it. So there's no need to modify the driver until an IP core needs
different handling.

In your case you'd identify the oldest SoC that implements the Gen1 IP
core and use this instead of "renesas,can-gen1. Same for Gen2 IP core.

regards,
Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

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

[Yoshihiro Shimoda]

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 ++
 drivers/phy/phy-rcar-gen3-usb2.c   | 28 ++
 2 files changed, 30 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index eaf7e9b..2ffb856 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -15,6 +15,8 @@ To use a USB channel where USB 2.0 Host and HSUSB (USB 2.0 
Peripheral) are
 combined, the device tree node should set interrupt properties to use the
 channel as USB OTG:
 - interrupts: interrupt specifier for the PHY.
+- vbus-supply: Phandle to a regulator that provides power to the VBUS. This
+  regulator will be managed during the PHY power on/off sequence.
 
 Example (R-Car H3):
 
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index 2da2148..c2bfde8 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*** USB2.0 Host registers (original offset is +0x200) ***/
 #define USB2_INT_ENABLE0x000
@@ -77,6 +78,7 @@
 struct rcar_gen3_chan {
void __iomem *base;
struct phy *phy;
+   struct regulator *vbus;
bool has_otg;
 };
 
@@ -210,6 +212,13 @@ static int rcar_gen3_phy_usb2_power_on(struct phy *p)
struct rcar_gen3_chan *channel = phy_get_drvdata(p);
void __iomem *usb2_base = channel->base;
u32 val;
+   int ret;
+
+   if (channel->vbus) {
+   ret = regulator_enable(channel->vbus);
+   if (ret)
+   return ret;
+   }
 
val = readl(usb2_base + USB2_USBCTR);
val |= USB2_USBCTR_PLL_RST;
@@ -220,10 +229,22 @@ static int rcar_gen3_phy_usb2_power_on(struct phy *p)
return 0;
 }
 
+static int rcar_gen3_phy_usb2_power_off(struct phy *p)
+{
+   struct rcar_gen3_chan *channel = phy_get_drvdata(p);
+   int ret = 0;
+
+   if (channel->vbus)
+   ret = regulator_disable(channel->vbus);
+
+   return ret;
+}
+
 static struct phy_ops rcar_gen3_phy_usb2_ops = {
.init   = rcar_gen3_phy_usb2_init,
.exit   = rcar_gen3_phy_usb2_exit,
.power_on   = rcar_gen3_phy_usb2_power_on,
+   .power_off  = rcar_gen3_phy_usb2_power_off,
.owner  = THIS_MODULE,
 };
 
@@ -289,6 +310,13 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
return PTR_ERR(channel->phy);
}
 
+   channel->vbus = devm_regulator_get_optional(dev, "vbus");
+   if (IS_ERR(channel->vbus)) {
+   if (PTR_ERR(channel->vbus) == -EPROBE_DEFER)
+   return PTR_ERR(channel->vbus);
+   channel->vbus = NULL;
+   }
+
phy_set_drvdata(channel->phy, channel);
 
provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
-- 
1.9.1

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

[Yoshihiro Shimoda]

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 ]
http://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next=cff0fef33d77bd7e98463029e5d0a4191d9bbb95

[ generic phy driver for R-Car H3 ]
http://thread.gmane.org/gmane.linux.kernel/2120685

This patch set contains patches that are related to generic phy driver.
As I wrote a comment in patch 7, to handle VBUS on/off for USB2.0 host
channel 0, I use a regulator driver instead of extcon/max3355 driver.
This is a reason that I marked this patch set is a RFC because I'm not
sure that this way is acceptable or not.

Also patch 5 should resolve checkpatch.pl warnings, and patch 6 should
have dmas property to use USB-DMAC later.

Changes from v1:
 - Remove PFC for usb2.0 host patch because it contains the renesas-drivers.
 - Change the patch order of the phy driver. (clean up code is in first.)
 - Change the property of "phy-supply" to "vbus-supply".

Yoshihiro Shimoda (9):
  phy: rcar-gen3-usb2: remove unnecesary struct rcar_gen3_data
  phy: rcar-gen3-usb2: Add vbus-supply to handle VBUS on/off
  phy: rcar-gen3-usb2: add extcon support
  arm64: dts: r8a7795: add usb2_phy device nodes
  arm64: dts: r8a7795: add USB2.0 Host (EHCI/OHCI) device nodes
  arm64: dts: r8a7795: add HS-USB device node
  arm64: dts: salvator-x: enable usb2_phy
  arm64: dts: salvator-x: enable USB 2.0 Host channels
  arm64: dts: salvator-x: enable HS-USB

 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |   2 +
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  73 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 107 +
 drivers/phy/Kconfig|   1 +
 drivers/phy/phy-rcar-gen3-usb2.c   |  87 +
 5 files changed, 250 insertions(+), 20 deletions(-)

-- 
1.9.1

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

[Yoshihiro Shimoda]

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 a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0124d17..32c7088 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -121,6 +121,7 @@ config PHY_RCAR_GEN2
 config PHY_RCAR_GEN3_USB2
tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
depends on OF && ARCH_SHMOBILE
+   depends on EXTCON
select GENERIC_PHY
help
  Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index c2bfde8..d4af4dc 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -12,6 +12,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -77,6 +78,7 @@
 
 struct rcar_gen3_chan {
void __iomem *base;
+   struct extcon_dev *extcon;
struct phy *phy;
struct regulator *vbus;
bool has_otg;
@@ -127,6 +129,9 @@ static void rcar_gen3_init_for_host(struct rcar_gen3_chan 
*ch)
rcar_gen3_set_linectrl(ch, 1, 1);
rcar_gen3_set_host_mode(ch, 1);
rcar_gen3_enable_vbus_ctrl(ch, 1);
+
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
 }
 
 static void rcar_gen3_init_for_peri(struct rcar_gen3_chan *ch)
@@ -134,6 +139,9 @@ static void rcar_gen3_init_for_peri(struct rcar_gen3_chan 
*ch)
rcar_gen3_set_linectrl(ch, 0, 1);
rcar_gen3_set_host_mode(ch, 0);
rcar_gen3_enable_vbus_ctrl(ch, 0);
+
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
 }
 
 static bool rcar_gen3_check_vbus(struct rcar_gen3_chan *ch)
@@ -271,6 +279,12 @@ static const struct of_device_id 
rcar_gen3_phy_usb2_match_table[] = {
 };
 MODULE_DEVICE_TABLE(of, rcar_gen3_phy_usb2_match_table);
 
+static const unsigned int rcar_gen3_phy_cable[] = {
+   EXTCON_USB,
+   EXTCON_USB_HOST,
+   EXTCON_NONE,
+};
+
 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -296,11 +310,23 @@ static int rcar_gen3_phy_usb2_probe(struct 
platform_device *pdev)
/* call request_irq for OTG */
irq = platform_get_irq(pdev, 0);
if (irq >= 0) {
+   int ret;
+
irq = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
   IRQF_SHARED, dev_name(dev), channel);
if (irq < 0)
dev_err(dev, "No irq handler (%d)\n", irq);
channel->has_otg = true;
+   channel->extcon = devm_extcon_dev_allocate(dev,
+   rcar_gen3_phy_cable);
+   if (IS_ERR(channel->extcon))
+   return PTR_ERR(channel->extcon);
+
+   ret = devm_extcon_dev_register(dev, channel->extcon);
+   if (ret < 0) {
+   dev_err(dev, "Failed to register extcon\n");
+   return ret;
+   }
}
 
/* devm_phy_create() will call pm_runtime_enable(dev); */
-- 
1.9.1

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

[Yoshihiro Shimoda]

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 2203b8e..75142f3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1434,5 +1434,71 @@
#phy-cells = <0>;
status = "disabled";
};
+
+   ehci0: usb@ee080100 {
+   compatible = "renesas,ehci-r8a7795", "generic-ehci";
+   reg = <0 0xee080100 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 703>;
+   phys = <_phy0>;
+   phy-names = "usb";
+   power-domains = <>;
+   status = "disabled";
+   };
+
+   ehci1: usb@ee0a0100 {
+   compatible = "renesas,ehci-r8a7795", "generic-ehci";
+   reg = <0 0xee0a0100 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 702>;
+   phys = <_phy1>;
+   phy-names = "usb";
+   power-domains = <>;
+   status = "disabled";
+   };
+
+   ehci2: usb@ee0c0100 {
+   compatible = "renesas,ehci-r8a7795", "generic-ehci";
+   reg = <0 0xee0c0100 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 701>;
+   phys = <_phy2>;
+   phy-names = "usb";
+   power-domains = <>;
+   status = "disabled";
+   };
+
+   ohci0: usb@ee08 {
+   compatible = "renesas,ohci-r8a7795", "generic-ohci";
+   reg = <0 0xee08 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 703>;
+   phys = <_phy0>;
+   phy-names = "usb";
+   power-domains = <>;
+   status = "disabled";
+   };
+
+   ohci1: usb@ee0a {
+   compatible = "renesas,ohci-r8a7795", "generic-ohci";
+   reg = <0 0xee0a 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 702>;
+   phys = <_phy1>;
+   phy-names = "usb";
+   power-domains = <>;
+   status = "disabled";
+   };
+
+   ohci2: usb@ee0c {
+   compatible = "renesas,ohci-r8a7795", "generic-ohci";
+   reg = <0 0xee0c 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 701>;
+   phys = <_phy2>;
+   phy-names = "usb";
+   power-domains = <>;
+   status = "disabled";
+   };
};
 };
-- 
1.9.1

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

[Yoshihiro Shimoda]

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
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1500,5 +1500,18 @@
power-domains = <>;
status = "disabled";
};
+
+   hsusb: usb@e659 {
+   compatible = "renesas,usbhs-r8a7795",
+"renesas,rcar-gen3-usbhs";
+   reg = <0 0xe659 0 0x100>;
+   interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < CPG_MOD 704>;
+   renesas,buswait = <11>;
+   phys = <_phy0>;
+   phy-names = "usb";
+   power-domains = <>;
+   status = "disabled";
+   };
};
 };
-- 
1.9.1

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

[Geert Uytterhoeven]

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 are interchangeable and client is not aware of
> which engine to map to.
>
> 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.

Thanks a lot!

> Original-patch-by: Linus Walleij 

You've dropped a few ;-)

Original-patch-acked-by: Lee Jones 
Original-patch-acked-by: Arnd Bergmann 

> Signed-off-by: Vinod Koul 

Acked-by: Geert Uytterhoeven 

> ---
>  include/linux/dmaengine.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 16a1cad30c33..d85ecd20af50 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -357,8 +357,8 @@ enum dma_slave_buswidth {
>   */
>  struct dma_slave_config {
> enum dma_transfer_direction direction;
> -   dma_addr_t src_addr;
> -   dma_addr_t dst_addr;
> +   phys_addr_t src_addr;
> +   phys_addr_t dst_addr;
> enum dma_slave_buswidth src_addr_width;
> enum dma_slave_buswidth dst_addr_width;
> u32 src_maxburst;

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 RESEND 3/3] arm64: dts: r8a7795: salvator-x: enable SDHI0 & 3

[Wolfram Sang]

> 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 RESEND 3/3] arm64: dts: r8a7795: salvator-x: enable SDHI0 & 3

[Wolfram Sang]

> 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