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 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
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
Hi, > 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. Thank you! Best regards, Yoshihiro Shimoda > -Kishon >
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 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
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
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
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 1/2] ARM: dts: r8a7790: use fallback etheravb compatibility string
Use recently added fallback compatibility string in r8a7790 device tree. Signed-off-by: Simon Horman --- arch/arm/boot/dts/r8a7790.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi index ba4c2530d79f..ec933f6ff5bf 100644 --- a/arch/arm/boot/dts/r8a7790.dtsi +++ b/arch/arm/boot/dts/r8a7790.dtsi @@ -773,7 +773,7 @@ }; avb: ethernet@e680 { - compatible = "renesas,etheravb-r8a7790"; + compatible = "renesas,etheravb-r8a7790", "renesas,etheravb-rcar-gen2"; reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>; interrupts = ; clocks = <&mstp8_clks R8A7790_CLK_ETHERAVB>; -- 2.1.4
[PATCH 0/2] ARM, arm64: dts: use fallback etheravb compatibility string
Use recently added fallback etheravb compatibility string in device trees where it is not already used. Based on renesas-devel-20160222-v4.5-rc5 Simon Horman (2): ARM: dts: r8a7790: use fallback etheravb compatibility string arm64: dts: r8a7795: use fallback etheravb compatibility string arch/arm/boot/dts/r8a7790.dtsi | 2 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) -- 2.1.4
[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 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
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
On Tue, Feb 23, 2016 at 01:07:20AM +0100, Wolfram Sang wrote: > > > 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. Great, thanks. > > Sure, I have tentatively queued this up for v4.6. > > Thanks!
Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS
On Mon, Feb 22, 2016 at 03:05:58PM +0200, Laurent Pinchart wrote: > 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. >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. 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?
Re: [PATCH can-next 1/2] CAN: rcar: add gen[12] fallback compatibility strings
On Mon, Feb 22, 2016 at 10:40:37AM +0100, Marc Kleine-Budde wrote: > 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. In the case of Renesas R-Car hardware we know that there are generations of SoCs, e.g. Gen 1 and Gen 2, but beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7779 is older than r8a7778 but that doesn't imply that the latter is a descendant of the former or vice versa.
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 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
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 = <&mstp9_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: [PATCH can-next 2/2] CAN: rcar: add device tree support for r8a779[234]
On Mon, Feb 22, 2016 at 02:48:39PM +0100, Geert Uytterhoeven wrote: > On Mon, Feb 22, 2016 at 3:15 AM, Simon Horman > wrote: > > Simply document new compatibility string. > > As a previous patch adds a generic R-Car Gen2 compatibility string > > there appears to be no need for a driver updates. > > By documenting this compat sting it may be used in DTSs shipped, for > > string > > > example as part of ROMs. It must be used in conjunction with the Gen2 > > fallback compat string. At this time there are no known differences between > > the r8a779[234] IP blocks and that implemented by the driver for the Gen2 > > fallback compat string. Thus there is no need to update the driver as the > ^ > > use of the Gen2 fallback compat string will activate the correct code in > ^^ > > > the current driver while leaving the option for r8a779[234]-specific driver > > code to be activated in an updated driver should the need arise. > > > > Signed-off-by: Simon Horman > > --- > > Documentation/devicetree/bindings/net/can/rcar_can.txt | 3 +++ > > drivers/net/can/rcar_can.c | 3 +++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt > > b/Documentation/devicetree/bindings/net/can/rcar_can.txt > > index 036786e1f70d..c6fb74d7c809 100644 > > --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt > > +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt > > @@ -6,6 +6,9 @@ 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-r8a7792" if CAN controller is a part of R8A7792 > > SoC. > > + "renesas,can-r8a7793" if CAN controller is a part of R8A7793 > > SoC. > > + "renesas,can-r8a7794" if CAN controller is a part of R8A7794 > > SoC. > > "renesas,can-gen1" for a generic R-Car Gen1 compatible device. > > "renesas,can-gen2" for a generic R-Car Gen2 compatible device. > > - reg: physical base address and size of the R-Car CAN register map. > > diff --git a/drivers/net/can/rcar_can.c b/drivers/net/can/rcar_can.c > > index c70a1f795933..73761a4dd1bf 100644 > > --- a/drivers/net/can/rcar_can.c > > +++ b/drivers/net/can/rcar_can.c > > @@ -904,6 +904,9 @@ 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-r8a7792" }, > > + { .compatible = "renesas,can-r8a7793" }, > > + { .compatible = "renesas,can-r8a7794" }, > > So why do you update the driver? > > There's no upstream DTS using "renesas,can-r8a779[234]", so > "renesas,can-gen2" should be fine. True. I'm not sure how that slipped in. > > { .compatible = "renesas,can-gen1" }, > > { .compatible = "renesas,can-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 0/2] ARM: shmobile: use Lager as reference for I2C slave and core switch
On Mon, Feb 22, 2016 at 09:47:34AM +0100, Wolfram Sang wrote: > On Mon, Feb 15, 2016 at 01:57:47PM +0100, Wolfram Sang wrote: > > This series provides the necessary preparation to use Lager for testing the > > above mentioned features. After this, the rest is done at runtime as > > described > > in the upstream documentation. > > > > This series depends on the i2c-demux-pinctrl driver which is in linux-next > > already. Because IIC0/I2C0 is unpopulated and even so, IIC0 is used as > > default > > like before, chances of a regression are extremly unlikely. The only > > regression > > I can think of is someone using: > > a) IIC0 with an external board > > b) the Lager DTS from upstream unmodified > > c) a private .config and forgot to activate the i2c-demux-pinctrl driver > > > > We could point this person to the working shmobile_defconfig, though. > > However, > > I'd think that someone using IIC0 externally will also have a private Lager > > DTS > > and in that case will be made aware by the merge conflict. > > > > Another minor question for me is: Do we need to update multiv7_defconfig, > > too. > > My feeling is no, so I left it out, but may be convinced otherwise. My feeling is yes for consistency. Are you concerned about bloat in multiv7_defconfig? > > Magnus: I hope this is what you had in mind for the reference platform idea. > > > > Kind regards, > > > >Wolfram > > Can we have this in 4.6? Sure, I have tentatively queued this up for v4.6.
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? 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
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! > > > Original-patch-by: Linus Walleij > > You've dropped a few ;-) > > Original-patch-acked-by: Lee Jones > Original-patch-acked-by: Arnd Bergmann I never collected those :) Added now, But will use Arnd latest ack... > > > Signed-off-by: Vinod Koul > > Acked-by: Geert Uytterhoeven Thanks, any chance you could test on your boards? > > > --- > > 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 -- ~Vinod
Re: [PATCH][CFT]: dmaengine: make slave address physical
On Mon, Feb 22, 2016 at 01:31:04PM +0100, Wolfram Sang wrote: > 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. I did check build warnings and pushed this out, Feng's bot didn't complain so was more concerned about testing, so thanks for getting that done. -- ~Vinod signature.asc Description: Digital signature
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 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: [PATCH][CFT]: dmaengine: make slave address physical
On Mon, Feb 22, 2016 at 05:02:07PM +0200, Laurent Pinchart wrote: > 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 Updated 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, > > Laurent Pinchart > -- ~Vinod
Re: [PATCH can-next 1/2] CAN: rcar: add gen[12] fallback compatibility strings
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" ;-) Nothing further to say about SoC-specific vs. generic compatible values? > - 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 = <&mstp9_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"
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
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: [RFC/PATCH] [media] rcar-vin: add Renesas R-Car VIN IP core
Hi Niklas, On Monday 22 February 2016 15:36:16 Niklas Söderlund wrote: > 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. I think we need an SNES screenshot as a proof ;-) > 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. What errors do you get ? > 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, Laurent Pinchart
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 > 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
> > 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
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
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"
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 can-next 2/2] CAN: rcar: add device tree support for r8a779[234]
On Mon, Feb 22, 2016 at 3:15 AM, Simon Horman wrote: > Simply document new compatibility string. > As a previous patch adds a generic R-Car Gen2 compatibility string > there appears to be no need for a driver updates. > By documenting this compat sting it may be used in DTSs shipped, for string > example as part of ROMs. It must be used in conjunction with the Gen2 > fallback compat string. At this time there are no known differences between > the r8a779[234] IP blocks and that implemented by the driver for the Gen2 > fallback compat string. Thus there is no need to update the driver as the ^ > use of the Gen2 fallback compat string will activate the correct code in ^^ > the current driver while leaving the option for r8a779[234]-specific driver > code to be activated in an updated driver should the need arise. > > Signed-off-by: Simon Horman > --- > Documentation/devicetree/bindings/net/can/rcar_can.txt | 3 +++ > drivers/net/can/rcar_can.c | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt > b/Documentation/devicetree/bindings/net/can/rcar_can.txt > index 036786e1f70d..c6fb74d7c809 100644 > --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt > +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt > @@ -6,6 +6,9 @@ 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-r8a7792" if CAN controller is a part of R8A7792 > SoC. > + "renesas,can-r8a7793" if CAN controller is a part of R8A7793 > SoC. > + "renesas,can-r8a7794" if CAN controller is a part of R8A7794 > SoC. > "renesas,can-gen1" for a generic R-Car Gen1 compatible device. > "renesas,can-gen2" for a generic R-Car Gen2 compatible device. > - reg: physical base address and size of the R-Car CAN register map. > diff --git a/drivers/net/can/rcar_can.c b/drivers/net/can/rcar_can.c > index c70a1f795933..73761a4dd1bf 100644 > --- a/drivers/net/can/rcar_can.c > +++ b/drivers/net/can/rcar_can.c > @@ -904,6 +904,9 @@ 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-r8a7792" }, > + { .compatible = "renesas,can-r8a7793" }, > + { .compatible = "renesas,can-r8a7794" }, So why do you update the driver? There's no upstream DTS using "renesas,can-r8a779[234]", so "renesas,can-gen2" should be fine. > { .compatible = "renesas,can-gen1" }, > { .compatible = "renesas,can-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] 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 > 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
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
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
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
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
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
Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS
Hi Simon, Thank you for the patch. 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. > --- > drivers/video/fbdev/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Based on v4.5-rc1 > > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig > index 8ea45a5cd806..936ebd4bcf73 100644 > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1985,7 +1985,7 @@ config FB_W100 > > config FB_SH_MOBILE_LCDC > tristate "SuperH Mobile LCDC framebuffer support" > - depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK > + depends on FB && (SUPERH || ARCH_RENESAS) && HAVE_CLK > depends on FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM > select FB_SYS_FILLRECT > select FB_SYS_COPYAREA -- Regards, Laurent Pinchart
[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 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 = <&gpio6 11 GPIO_ACTIVE_LOW>; label = "SW20"; wakeup-source; linux,code = ; }; key-b { gpios = <&gpio6 12 GPIO_ACTIVE_LOW>; label = "SW21"; wakeup-source; linux,code = ; }; key-c { gpios = <&gpio6 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 = <&gpio6 11 GPIO_ACTIVE_HIGH>; label = "LED4"; }; led5 { gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>; label = "LED5"; }; led6 { gpios = <&gpio6 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
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 9/9] arm64: dts: salvator-x: enable HS-USB
Signed-off-by: Yoshihiro Shimoda --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index f9d904b..66e7e04 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts @@ -388,3 +388,7 @@ &ohci2 { status = "okay"; }; + +&hsusb { + status = "okay"; +}; -- 1.9.1
[PATCH/RFC v2 8/9] arm64: dts: salvator-x: enable USB 2.0 Host channels
We should set SW15 to pin 2-3 side on the board before we use CN9 as USB host or peripheral. Signed-off-by: Yoshihiro Shimoda --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 24 ++ 1 file changed, 24 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index 6adb65f..f9d904b 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts @@ -364,3 +364,27 @@ pinctrl-0 = <&usb2_pins>; pinctrl-names = "default"; }; + +&ehci0 { + status = "okay"; +}; + +&ehci1 { + status = "okay"; +}; + +&ehci2 { + status = "okay"; +}; + +&ohci0 { + status = "okay"; +}; + +&ohci1 { + status = "okay"; +}; + +&ohci2 { + status = "okay"; +}; -- 1.9.1
[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 ++ 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 1/9] phy: rcar-gen3-usb2: remove unnecesary struct rcar_gen3_data
Since this driver uses the struct rcar_gen3_data in struct rcar_gen3_chan only, we can remove the rcar_gen3_data. Signed-off-by: Yoshihiro Shimoda --- drivers/phy/phy-rcar-gen3-usb2.c | 33 ++--- 1 file changed, 14 insertions(+), 19 deletions(-) diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c index bc4f7dd..2da2148 100644 --- a/drivers/phy/phy-rcar-gen3-usb2.c +++ b/drivers/phy/phy-rcar-gen3-usb2.c @@ -74,20 +74,15 @@ #define USB2_ADPCTRL_IDPULLUP BIT(5) /* 1 = ID sampling is enabled */ #define USB2_ADPCTRL_DRVVBUS BIT(4) -struct rcar_gen3_data { - void __iomem *base; - struct clk *clk; -}; - struct rcar_gen3_chan { - struct rcar_gen3_data usb2; + void __iomem *base; struct phy *phy; bool has_otg; }; static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host) { - void __iomem *usb2_base = ch->usb2.base; + void __iomem *usb2_base = ch->base; u32 val = readl(usb2_base + USB2_COMMCTRL); dev_vdbg(&ch->phy->dev, "%s: %08x, %d\n", __func__, val, host); @@ -100,7 +95,7 @@ static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host) static void rcar_gen3_set_linectrl(struct rcar_gen3_chan *ch, int dp, int dm) { - void __iomem *usb2_base = ch->usb2.base; + void __iomem *usb2_base = ch->base; u32 val = readl(usb2_base + USB2_LINECTRL1); dev_vdbg(&ch->phy->dev, "%s: %08x, %d, %d\n", __func__, val, dp, dm); @@ -114,7 +109,7 @@ static void rcar_gen3_set_linectrl(struct rcar_gen3_chan *ch, int dp, int dm) static void rcar_gen3_enable_vbus_ctrl(struct rcar_gen3_chan *ch, int vbus) { - void __iomem *usb2_base = ch->usb2.base; + void __iomem *usb2_base = ch->base; u32 val = readl(usb2_base + USB2_ADPCTRL); dev_vdbg(&ch->phy->dev, "%s: %08x, %d\n", __func__, val, vbus); @@ -141,13 +136,13 @@ static void rcar_gen3_init_for_peri(struct rcar_gen3_chan *ch) static bool rcar_gen3_check_vbus(struct rcar_gen3_chan *ch) { - return !!(readl(ch->usb2.base + USB2_ADPCTRL) & + return !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_OTGSESSVLD); } static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch) { - return !!(readl(ch->usb2.base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG); + return !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG); } static void rcar_gen3_device_recognition(struct rcar_gen3_chan *ch) @@ -166,7 +161,7 @@ static void rcar_gen3_device_recognition(struct rcar_gen3_chan *ch) static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch) { - void __iomem *usb2_base = ch->usb2.base; + void __iomem *usb2_base = ch->base; u32 val; val = readl(usb2_base + USB2_VBCTRL); @@ -187,7 +182,7 @@ static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch) static int rcar_gen3_phy_usb2_init(struct phy *p) { struct rcar_gen3_chan *channel = phy_get_drvdata(p); - void __iomem *usb2_base = channel->usb2.base; + void __iomem *usb2_base = channel->base; /* Initialize USB2 part */ writel(USB2_INT_ENABLE_INIT, usb2_base + USB2_INT_ENABLE); @@ -205,7 +200,7 @@ static int rcar_gen3_phy_usb2_exit(struct phy *p) { struct rcar_gen3_chan *channel = phy_get_drvdata(p); - writel(0, channel->usb2.base + USB2_INT_ENABLE); + writel(0, channel->base + USB2_INT_ENABLE); return 0; } @@ -213,7 +208,7 @@ static int rcar_gen3_phy_usb2_exit(struct phy *p) 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->usb2.base; + void __iomem *usb2_base = channel->base; u32 val; val = readl(usb2_base + USB2_USBCTR); @@ -235,7 +230,7 @@ static struct phy_ops rcar_gen3_phy_usb2_ops = { static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void *_ch) { struct rcar_gen3_chan *ch = _ch; - void __iomem *usb2_base = ch->usb2.base; + void __iomem *usb2_base = ch->base; u32 status = readl(usb2_base + USB2_OBINTSTA); irqreturn_t ret = IRQ_NONE; @@ -273,9 +268,9 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev) return -ENOMEM; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - channel->usb2.base = devm_ioremap_resource(dev, res); - if (IS_ERR(channel->usb2.base)) - return PTR_ERR(channel->usb2.base); + channel->base = devm_ioremap_resource(dev, res); + if (IS_ERR(channel->base)) + return PTR_ERR(channel->base); /* call request_irq for OTG */ irq = platform_get_irq(pdev, 0); -- 1.9.1
[PATCH/RFC v2 7/9] arm64: dts: salvator-x: enable usb2_phy
This patch also adds a regulator node for USB2.0 to handle VBUS on/off by the generic PHY framework. This board has a MAX3355 chip. However, we cannot use the extcon/max3355 driver because the ID pin doesn't connect to a gpio pin (in other words, it connects to the SoC specific pin). Signed-off-by: Yoshihiro Shimoda --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 45 +- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index fb1f382..6adb65f 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts @@ -33,6 +33,7 @@ /dts-v1/; #include "r8a7795.dtsi" +#include / { model = "Renesas Salvator-X board based on r8a7795"; @@ -118,6 +119,15 @@ }; }; }; + + vcc_usb2_phy0: regulator@0 { + compatible = "regulator-fixed"; + regulator-name = "USB20_VBUS0"; + regulator-min-microvolt = <500>; + regulator-max-microvolt = <500>; + gpio = <&gpio6 16 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; }; &du { @@ -173,8 +183,22 @@ "audio_clkout_a", "audio_clkout3_a"; renesas,function = "audio_clk"; }; -}; + usb0_pins: usb0 { + renesas,groups = "usb0"; + renesas,function = "usb"; + }; + + usb1_pins: usb1 { + renesas,groups = "usb1"; + renesas,function = "usb"; + }; + + usb2_pins: usb2 { + renesas,groups = "usb2"; + renesas,function = "usb"; + }; +}; &scif1 { pinctrl-0 = <&scif1_pins>; pinctrl-names = "default"; @@ -321,3 +345,22 @@ &xhci0 { status = "okay"; }; + +&usb2_phy0 { + status = "okay"; + vbus-supply = <&vcc_usb2_phy0>; + pinctrl-0 = <&usb0_pins>; + pinctrl-names = "default"; +}; + +&usb2_phy1 { + status = "okay"; + pinctrl-0 = <&usb1_pins>; + pinctrl-names = "default"; +}; + +&usb2_phy2 { + status = "okay"; + pinctrl-0 = <&usb2_pins>; + pinctrl-names = "default"; +}; -- 1.9.1
[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 ] http://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=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
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 = &pdev->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
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 CPG_MOD 703>; + phys = <&usb2_phy0>; + phy-names = "usb"; + power-domains = <&cpg>; + status = "disabled"; + }; + + ehci1: usb@ee0a0100 { + compatible = "renesas,ehci-r8a7795", "generic-ehci"; + reg = <0 0xee0a0100 0 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 702>; + phys = <&usb2_phy1>; + phy-names = "usb"; + power-domains = <&cpg>; + status = "disabled"; + }; + + ehci2: usb@ee0c0100 { + compatible = "renesas,ehci-r8a7795", "generic-ehci"; + reg = <0 0xee0c0100 0 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 701>; + phys = <&usb2_phy2>; + phy-names = "usb"; + power-domains = <&cpg>; + status = "disabled"; + }; + + ohci0: usb@ee08 { + compatible = "renesas,ohci-r8a7795", "generic-ohci"; + reg = <0 0xee08 0 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 703>; + phys = <&usb2_phy0>; + phy-names = "usb"; + power-domains = <&cpg>; + status = "disabled"; + }; + + ohci1: usb@ee0a { + compatible = "renesas,ohci-r8a7795", "generic-ohci"; + reg = <0 0xee0a 0 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 702>; + phys = <&usb2_phy1>; + phy-names = "usb"; + power-domains = <&cpg>; + status = "disabled"; + }; + + ohci2: usb@ee0c { + compatible = "renesas,ohci-r8a7795", "generic-ohci"; + reg = <0 0xee0c 0 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 701>; + phys = <&usb2_phy2>; + phy-names = "usb"; + power-domains = <&cpg>; + status = "disabled"; + }; }; }; -- 1.9.1
[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 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -1500,5 +1500,18 @@ power-domains = <&cpg>; 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 CPG_MOD 704>; + renesas,buswait = <11>; + phys = <&usb2_phy0>; + phy-names = "usb"; + power-domains = <&cpg>; + status = "disabled"; + }; }; }; -- 1.9.1
[PATCH/RFC v2 4/9] arm64: dts: r8a7795: add usb2_phy device nodes
Signed-off-by: Yoshihiro Shimoda --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 28 1 file changed, 28 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index e77f5fd..2203b8e 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -1406,5 +1406,33 @@ }; }; }; + + usb2_phy0: usb-phy@ee080200 { + compatible = "renesas,usb2-phy-r8a7795"; + reg = <0 0xee080200 0 0x700>; + interrupts = ; + clocks = <&cpg CPG_MOD 703>; + power-domains = <&cpg>; + #phy-cells = <0>; + status = "disabled"; + }; + + usb2_phy1: usb-phy@ee0a0200 { + compatible = "renesas,usb2-phy-r8a7795"; + reg = <0 0xee0a0200 0 0x700>; + clocks = <&cpg CPG_MOD 702>; + power-domains = <&cpg>; + #phy-cells = <0>; + status = "disabled"; + }; + + usb2_phy2: usb-phy@ee0c0200 { + compatible = "renesas,usb2-phy-r8a7795"; + reg = <0 0xee0c0200 0 0x700>; + clocks = <&cpg CPG_MOD 701>; + power-domains = <&cpg>; + #phy-cells = <0>; + status = "disabled"; + }; }; }; -- 1.9.1
Re: [PATCH][CFT]: dmaengine: make slave address physical
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 > --- > 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
Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS
On Mon, Feb 22, 2016 at 2:59 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 0/2] ARM: shmobile: use Lager as reference for I2C slave and core switch
On Mon, Feb 15, 2016 at 01:57:47PM +0100, Wolfram Sang wrote: > This series provides the necessary preparation to use Lager for testing the > above mentioned features. After this, the rest is done at runtime as described > in the upstream documentation. > > This series depends on the i2c-demux-pinctrl driver which is in linux-next > already. Because IIC0/I2C0 is unpopulated and even so, IIC0 is used as default > like before, chances of a regression are extremly unlikely. The only > regression > I can think of is someone using: > a) IIC0 with an external board > b) the Lager DTS from upstream unmodified > c) a private .config and forgot to activate the i2c-demux-pinctrl driver > > We could point this person to the working shmobile_defconfig, though. However, > I'd think that someone using IIC0 externally will also have a private Lager > DTS > and in that case will be made aware by the merge conflict. > > Another minor question for me is: Do we need to update multiv7_defconfig, too. > My feeling is no, so I left it out, but may be convinced otherwise. > > Magnus: I hope this is what you had in mind for the reference platform idea. > > Kind regards, > >Wolfram Can we have this in 4.6? 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 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
> 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
> 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