Re: [PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
On 10/28/2018 10:34 PM, Wolfram Sang wrote: > Hi Marek, Hi, > On Sat, Oct 27, 2018 at 06:34:10PM +0200, Marek Vasut wrote: >> The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND >> array and the VCCQ supplies the bus. On this particular board, the VCC is >> connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust >> the pinmux to match the bus, which is always operating in 1.8V mode. >> >> Signed-off-by: Marek Vasut > > Thanks for this! > > I think Olof (and thus, Simon ;)) will be happy if those two patches are > merged. Fine by me. > Other than that, I think we should remove sdhi2_pins_uhs then because it > is the same as sdhi2_pins. And then use later "pinctrl-1 = > <&sdhi2_pins>;". So, basically the same phandles for both pinctrls. We > can re-add the second one when we need it. I wonder if removing the sdhi2_pins_uhs is what we want to do, given that we might need to adjust TDSEL or pull resistor configurations for the HS200/HS400 modes in the future. Thoughts ? >> Cc: Geert Uytterhoeven >> Cc: Simon Horman >> Cc: Wolfram Sang >> Cc: Yoshihiro Shimoda >> Cc: linux-renesas-soc@vger.kernel.org >> --- >> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi >> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi >> index 7d3d866a0063..d9a309b28fcf 100644 >> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi >> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi >> @@ -602,7 +602,7 @@ >> sdhi2_pins: sd2 { >> groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds"; >> function = "sdhi2"; >> -power-source = <3300>; >> +power-source = <1800>; >> }; >> >> sdhi2_pins_uhs: sd2_uhs { >> -- >> 2.17.1 >> -- Best regards, Marek Vasut
RE: [PATCH 3/7] ARM: dts: r8a77470: Add USB PHY DT support
Hi Biju-san, > From: Biju Das, Sent: Thursday, October 25, 2018 10:57 PM > > Define the r8a77470 generic part of the USB PHY device node. > > Signed-off-by: Biju Das > --- > This patch is tested against renesas-devel Thank you for the patch! > + usbphy1: usb-phy@e6598100 { > + compatible = "renesas,usb-phy-r8a77470", > + "renesas,rcar-gen2-usb-phy"; > + reg = <0 0xe6598100 0 0x100>, > + <0 0xee0c0200 0 0x118>; > + #address-cells = <1>; > + #size-cells = <0>; > + clocks = <&cpg CPG_MOD 706>, <&cpg CPG_MOD 705>; > + clock-names = "usbhs", "usb20_host"; > + status = "disabled"; > + resets = <&cpg 706>, <&cpg 705>; > + power-domains = <&sysc R8A77470_PD_ALWAYS_ON>; > + > + usb1: usb-channel@0 { > + reg = <0>; > + #phy-cells = <1>; > + }; > + }; I think this usbphy1 has to have 'status = "disabled"'. Best regards, Yoshihiro Shimoda
RE: [PATCH 2/7] phy: renesas: phy-rcar-gen2: Add support for r8a77470
Hi Biju-san, > From: Biju Das, Sent: Thursday, October 25, 2018 10:57 PM > > This patch adds support for RZ/G1C (r8a77470) SoC. RZ/G1C SoC has a > PLL register shared between hsusb0 and hsusb1. Compared to other RZ/G1 > and R-Car Gen2/3, USB Host needs to deassert the pll reset. > > Signed-off-by: Biju Das > --- > This patch is tested against phy-next Thank you for the patch! > --- > drivers/phy/renesas/phy-rcar-gen2.c | 188 > +++- > 1 file changed, 184 insertions(+), 4 deletions(-) > > diff --git a/drivers/phy/renesas/phy-rcar-gen2.c > b/drivers/phy/renesas/phy-rcar-gen2.c > index 72eeb06..3d3ebc8 100644 > --- a/drivers/phy/renesas/phy-rcar-gen2.c > +++ b/drivers/phy/renesas/phy-rcar-gen2.c > @@ -4,6 +4,7 @@ > * > * Copyright (C) 2014 Renesas Solutions Corp. > * Copyright (C) 2014 Cogent Embedded, Inc. > + * Copyright (C) 2018 Renesas Electronics Corp. > */ > > #include > @@ -15,6 +16,7 @@ > #include > #include > #include > +#include > > #define USBHS_LPSTS 0x02 > #define USBHS_UGCTRL 0x80 > @@ -35,10 +37,36 @@ > #define USBHS_UGCTRL2_USB0SEL0x0030 > #define USBHS_UGCTRL2_USB0SEL_PCI0x0010 > #define USBHS_UGCTRL2_USB0SEL_HS_USB 0x0030 > +#define USBHS_UGCTRL2_USB0SEL_USB20 0x0010 > +#define USBHS_UGCTRL2_USB0SEL_HS_USB_USB20 0x0020 > > /* USB General status register (UGSTS) */ > #define USBHS_UGSTS_LOCK 0x0100 /* From technical update */ > > +/* USB2.0 Host registers (original offset is +0x200) */ > +#define USB2_INT_ENABLE 0x000 > +#define USB2_USBCTR 0x00c > +#define USB2_SPD_RSM_TIMSET 0x10c > +#define USB2_OC_TIMSET 0x110 > + > +/* RZ/G1C shared PLL RESET REG */ > +#define USBHS_UGCTRL_PLL_RESET_REG 0xE6590180 I don't think this is acceptable for upstream... This register area may be mapped by usbphy0 on this driver's probe as base. > + > +/* INT_ENABLE */ > +#define USB2_INT_ENABLE_USBH_INTB_EN BIT(2) > +#define USB2_INT_ENABLE_USBH_INTA_EN BIT(1) > +#define USB2_INT_ENABLE_INIT (USB2_INT_ENABLE_USBH_INTB_EN | \ > + USB2_INT_ENABLE_USBH_INTA_EN) > + > +/* USBCTR */ > +#define USB2_USBCTR_PLL_RST BIT(1) > + > +/* SPD_RSM_TIMSET */ > +#define USB2_SPD_RSM_TIMSET_INIT 0x014e029b > + > +/* OC_TIMSET */ > +#define USB2_OC_TIMSET_INIT 0x000209ab > + > #define PHYS_PER_CHANNEL 2 > > struct rcar_gen2_phy { > @@ -57,8 +85,8 @@ struct rcar_gen2_channel { > }; > > struct rcar_gen2_phy_driver { > - void __iomem *base; > - struct clk *clk; > + void __iomem *base, *host_base; > + struct clk *clk, *host_clk; > spinlock_t lock; > int num_channels; > struct rcar_gen2_channel *channels; > @@ -180,6 +208,111 @@ static int rcar_gen2_phy_power_off(struct phy *p) > return 0; > } > > +/* UGCTRL PLLRESET is shared between HSUSB0 and HSUSB1 */ > +static void __iomem *pll_reg_base; HSUSB0 (usbphy0) has this register. So, mapping this register on usbphy1 is not good, I think. > +static atomic_t pll_reset_ref_cnt; > > +static int rz_g1c_phy_init(struct phy *p) > +{ > + struct rcar_gen2_phy *phy = phy_get_drvdata(p); > + struct rcar_gen2_channel *channel = phy->channel; > + struct rcar_gen2_phy_driver *drv = channel->drv; > + int retval; > + > + retval = rcar_gen2_phy_init(p); > + if (retval) > + return retval; > + > + /* Initialize USB2 part */ > + if (phy->select_value != USBHS_UGCTRL2_USB0SEL_HS_USB_USB20) { > + clk_prepare_enable(drv->host_clk); > + writel(USB2_INT_ENABLE_INIT, drv->host_base + USB2_INT_ENABLE); > + writel(USB2_SPD_RSM_TIMSET_INIT, > + drv->host_base + USB2_SPD_RSM_TIMSET); > + writel(USB2_OC_TIMSET_INIT, drv->host_base + USB2_OC_TIMSET); > + } > + > + return 0; > +} > + > +static int rz_g1c_phy_exit(struct phy *p) > +{ > + struct rcar_gen2_phy *phy = phy_get_drvdata(p); > + struct rcar_gen2_channel *channel = phy->channel; > + struct rcar_gen2_phy_driver *drv = channel->drv; > + > + if (phy->select_value != USBHS_UGCTRL2_USB0SEL_HS_USB_USB20) { > + writel(0, drv->host_base + USB2_INT_ENABLE); > + clk_disable_unprepare(channel->drv->host_clk); > + } > + > + clk_disable_unprepare(channel->drv->clk); > + > + channel->selected_phy = -1; > + > + return 0; > +} > + > +static int rz_g1c_phy_power_on(struct phy *p) > +{ > + struct rcar_gen2_phy *phy = phy_get_drvdata(p); > + struct rcar_gen2_phy_driver *drv = phy->channel->drv; > + void __iomem *base = drv->base; > + unsigned long flags; > + u32 value; > + > + spin_lock_irqsave(&drv->lock, flags); > + > + /* Power on USBHS PHY */ > + if (atomic_read(&pll_reset_ref_cnt) == 0) { > + value = readl(pll_reg_base); > +
Re: [PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
> > <&sdhi2_pins>;". So, basically the same phandles for both pinctrls. We > > can re-add the second one when we need it. > > I wonder if removing the sdhi2_pins_uhs is what we want to do, given > that we might need to adjust TDSEL or pull resistor configurations for > the HS200/HS400 modes in the future. Well, quoting myself "We can re-add the second one when we need it". It is possible but a tad unlikely. That's my take on it but it is ultimately up to Simon, of course. signature.asc Description: PGP signature
RE: [PATCH 3/7] ARM: dts: r8a77470: Add USB PHY DT support
Hi Shimoda-San, Thanks for the feedback. Regards, Biju > -Original Message- > From: Yoshihiro Shimoda > Sent: 29 October 2018 08:42 > To: Biju Das ; Rob Herring > ; Mark Rutland > Cc: Biju Das ; Simon Horman > ; Magnus Damm ; > linux-renesas-soc@vger.kernel.org; devicet...@vger.kernel.org; Geert > Uytterhoeven ; Chris Paterson > ; Fabrizio Castro > > Subject: RE: [PATCH 3/7] ARM: dts: r8a77470: Add USB PHY DT support > > Hi Biju-san, > > > From: Biju Das, Sent: Thursday, October 25, 2018 10:57 PM > > > > Define the r8a77470 generic part of the USB PHY device node. > > > > Signed-off-by: Biju Das > > --- > > This patch is tested against renesas-devel > > Thank you for the patch! > > > > +usbphy1: usb-phy@e6598100 { > > +compatible = "renesas,usb-phy-r8a77470", > > + "renesas,rcar-gen2-usb-phy"; > > +reg = <0 0xe6598100 0 0x100>, > > + <0 0xee0c0200 0 0x118>; > > +#address-cells = <1>; > > +#size-cells = <0>; > > +clocks = <&cpg CPG_MOD 706>, <&cpg CPG_MOD > 705>; > > +clock-names = "usbhs", "usb20_host"; > > +status = "disabled"; 'status = "disabled"'. > > +resets = <&cpg 706>, <&cpg 705>; > > +power-domains = <&sysc > R8A77470_PD_ALWAYS_ON>; > > + > > +usb1: usb-channel@0 { > > +reg = <0>; > > +#phy-cells = <1>; > > +}; > > +}; > > I think this usbphy1 has to have 'status = "disabled"'. It is already disabled please see above. Regards, Biju Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 2/7] phy: renesas: phy-rcar-gen2: Add support for r8a77470
Hi Shimoda-San, Thanks for the feedback. > Subject: RE: [PATCH 2/7] phy: renesas: phy-rcar-gen2: Add support for > r8a77470 > > Hi Biju-san, > > > From: Biju Das, Sent: Thursday, October 25, 2018 10:57 PM > > > > This patch adds support for RZ/G1C (r8a77470) SoC. RZ/G1C SoC has a > > PLL register shared between hsusb0 and hsusb1. Compared to other RZ/G1 > > and R-Car Gen2/3, USB Host needs to deassert the pll reset. > > > > Signed-off-by: Biju Das > > --- > > This patch is tested against phy-next > > Thank you for the patch! > > > --- > > drivers/phy/renesas/phy-rcar-gen2.c | 188 > > +++- > > 1 file changed, 184 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/phy/renesas/phy-rcar-gen2.c > > b/drivers/phy/renesas/phy-rcar-gen2.c > > index 72eeb06..3d3ebc8 100644 > > --- a/drivers/phy/renesas/phy-rcar-gen2.c > > +++ b/drivers/phy/renesas/phy-rcar-gen2.c > > @@ -4,6 +4,7 @@ > > * > > * Copyright (C) 2014 Renesas Solutions Corp. > > * Copyright (C) 2014 Cogent Embedded, Inc. > > + * Copyright (C) 2018 Renesas Electronics Corp. > > */ > > > > #include > > @@ -15,6 +16,7 @@ > > #include > > #include > > #include > > +#include > > > > #define USBHS_LPSTS0x02 > > #define USBHS_UGCTRL0x80 > > @@ -35,10 +37,36 @@ > > #define USBHS_UGCTRL2_USB0SEL0x0030 > > #define USBHS_UGCTRL2_USB0SEL_PCI0x0010 > > #define USBHS_UGCTRL2_USB0SEL_HS_USB0x0030 > > +#define USBHS_UGCTRL2_USB0SEL_USB200x0010 > > +#define USBHS_UGCTRL2_USB0SEL_HS_USB_USB200x0020 > > > > /* USB General status register (UGSTS) */ > > #define USBHS_UGSTS_LOCK0x0100 /* From technical > update */ > > > > +/* USB2.0 Host registers (original offset is +0x200) */ > > +#define USB2_INT_ENABLE0x000 > > +#define USB2_USBCTR0x00c > > +#define USB2_SPD_RSM_TIMSET0x10c > > +#define USB2_OC_TIMSET0x110 > > + > > +/* RZ/G1C shared PLL RESET REG */ > > +#define USBHS_UGCTRL_PLL_RESET_REG0xE6590180 > > I don't think this is acceptable for upstream... > This register area may be mapped by usbphy0 on this driver's probe as base. I was under the impression that ioremap with same cachetype won't be a problem. OK, will change this. > > + > > +/* INT_ENABLE */ > > +#define USB2_INT_ENABLE_USBH_INTB_ENBIT(2) > > +#define USB2_INT_ENABLE_USBH_INTA_ENBIT(1) > > +#define USB2_INT_ENABLE_INIT > (USB2_INT_ENABLE_USBH_INTB_EN | \ > > + USB2_INT_ENABLE_USBH_INTA_EN) > > + > > +/* USBCTR */ > > +#define USB2_USBCTR_PLL_RSTBIT(1) > > + > > +/* SPD_RSM_TIMSET */ > > +#define USB2_SPD_RSM_TIMSET_INIT0x014e029b > > + > > +/* OC_TIMSET */ > > +#define USB2_OC_TIMSET_INIT0x000209ab > > + > > #define PHYS_PER_CHANNEL2 > > > > struct rcar_gen2_phy { > > @@ -57,8 +85,8 @@ struct rcar_gen2_channel { }; > > > > struct rcar_gen2_phy_driver { > > -void __iomem *base; > > -struct clk *clk; > > +void __iomem *base, *host_base; > > +struct clk *clk, *host_clk; > > spinlock_t lock; > > int num_channels; > > struct rcar_gen2_channel *channels; > > @@ -180,6 +208,111 @@ static int rcar_gen2_phy_power_off(struct phy > *p) > > return 0; > > } > > > > +/* UGCTRL PLLRESET is shared between HSUSB0 and HSUSB1 */ static void > > +__iomem *pll_reg_base; > > HSUSB0 (usbphy0) has this register. > So, mapping this register on usbphy1 is not good, I think. OK, will change this. > > +static atomic_t pll_reset_ref_cnt; > > > > +static int rz_g1c_phy_init(struct phy *p) { > > +struct rcar_gen2_phy *phy = phy_get_drvdata(p); > > +struct rcar_gen2_channel *channel = phy->channel; > > +struct rcar_gen2_phy_driver *drv = channel->drv; > > +int retval; > > + > > +retval = rcar_gen2_phy_init(p); > > +if (retval) > > +return retval; > > + > > +/* Initialize USB2 part */ > > +if (phy->select_value != USBHS_UGCTRL2_USB0SEL_HS_USB_USB20) > { > > +clk_prepare_enable(drv->host_clk); > > +writel(USB2_INT_ENABLE_INIT, drv->host_base + > USB2_INT_ENABLE); > > +writel(USB2_SPD_RSM_TIMSET_INIT, > > +drv->host_base + > USB2_SPD_RSM_TIMSET); > > +writel(USB2_OC_TIMSET_INIT, drv->host_base + > USB2_OC_TIMSET); > > +} > > + > > +return 0; > > +} > > + > > +static int rz_g1c_phy_exit(struct phy *p) { > > +struct rcar_gen2_phy *phy = phy_get_drvdata(p); > > +struct rcar_gen2_channel *channel = phy->channel; > > +struct rcar_gen2_phy_driver *drv = channel->drv; > > + > > +if (phy->select_value != USBHS_UGCTRL2_USB0SEL_HS_USB_USB20) > { > > +writel(0, drv->host_base + USB2_INT_ENABLE); > > +clk_disable_unprepare(channel->drv->host_clk); > > +} > > + > > +clk_disable_unprepare(channel->drv->clk); > > + > > +channel->selected_phy = -1; > > + > > +return 0; > > +} > > + > > +static int rz_g1c_phy_power_on(struct phy *p) { > > +struct rcar_gen2_phy *phy = phy_get_drvdata(p); > > +struct rcar_gen2_phy_driver *drv = phy->channel->drv; > > +void __iomem *base = drv->base; > > +unsigned long flags; > > +u32 value; > > + > > +spin_lock_irqsave(&drv->lock, flags); > > + > > +/* Power on USBHS PHY */ > > +if (atomic_read(&pll_reset_ref_cnt) == 0)
Re: [PATCH] arm64: defconfig: Enable R-Car thermal driver
On Wed, Oct 17, 2018 at 12:07:18PM +0200, Simon Horman wrote: > Enable the R-Car thermal driver as a module. > > This driver is used in conjunction with the R-Car V3M (r8a77970), > E3 (r8a77990) and D3 (r8a77995) SoCs. > > Signed-off-by: Simon Horman Applied for v4.21. > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index e6ec9858d33d..205d212eac58 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -365,6 +365,7 @@ CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y > CONFIG_CPU_THERMAL=y > CONFIG_THERMAL_EMULATION=y > CONFIG_ROCKCHIP_THERMAL=m > +CONFIG_RCAR_THERMAL=m > CONFIG_RCAR_GEN3_THERMAL=y > CONFIG_ARMADA_THERMAL=y > CONFIG_BRCMSTB_THERMAL=m > -- > 2.11.0 >
Re: [PATCH] arm64: renesas_defconfig: Enable R-Car thermal driver
On Wed, Oct 17, 2018 at 12:07:22PM +0200, Simon Horman wrote: > Enable the R-Car thermal driver. > > This driver is used in conjunction with the R-Car V3M (r8a77970), > E3 (r8a77990) and D3 (r8a77995) SoCs. > > Signed-off-by: Simon Horman > --- > N.B: This is targeted at the devel branch of the renesas tree > but not upstream where renesas_defconfig does not currently exist Applied to the topic/renesas_defconfig branch of the renesas tree which is carried in the devel branch of the same tree but not targeted at upstream.
Re: [PATCH v2] arm64: dts: renesas: r8a779{7|8}0: add MSIOF support
On Fri, Oct 19, 2018 at 10:10:44PM +0300, Sergei Shtylyov wrote: > Describe MSIOF in the R8A779{7|8}0 device trees. > > The DMA props are omitted for R8A77980 as the RT-DMAC isn't supported > (yet?)... > > Based on the original (and large) patches by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov > > --- > This patch is against the 'renesas-devel-20181015-v4.19-rc8' branch of > Simon Horman's 'renesas.git' repo. > > Changes in version 2: > - removed the aliases; > - restored the DMA props on R8A77970, updated the description accordingly; > - mentioned Vladimir in the description and added his signoff; > - refreshed the patch. Thanks, applied for v4.21.
Re: [PATCH/RFT] arm64: dts: renesas: r8a77990: Add SCIF-{0,1,3,4,5} device nodes
On Sun, Oct 21, 2018 at 06:30:00AM +0900, Yoshihiro Kaneko wrote: > From: Takeshi Kihara > > This patch adds the device nodes for SCIF-{0,1,3,4,5} serial ports to > the R8A77990 SoC. > > Signed-off-by: Takeshi Kihara > Signed-off-by: Yoshihiro Kaneko Thanks. I don't believe this can (easily) be tested as SCIF-{0,1,3,4,5} do not appear to be exposed on the Ebisu board. I have checked this patch with reference to the documentation and it looks good to me. I have applied if for v4.21.
RE: [PATCH 3/7] ARM: dts: r8a77470: Add USB PHY DT support
Hi Biju-san, > From: Biju Das, Sent: Monday, October 29, 2018 6:15 PM > > -Original Message- > > From: Yoshihiro Shimoda > > Sent: 29 October 2018 08:42 > > > > Hi Biju-san, > > > > > From: Biju Das, Sent: Thursday, October 25, 2018 10:57 PM > > > > > > Define the r8a77470 generic part of the USB PHY device node. > > > > > > Signed-off-by: Biju Das > > > --- > > > This patch is tested against renesas-devel > > > > Thank you for the patch! > > > > > > > + usbphy1: usb-phy@e6598100 { > > > + compatible = "renesas,usb-phy-r8a77470", > > > + "renesas,rcar-gen2-usb-phy"; > > > + reg = <0 0xe6598100 0 0x100>, > > > + <0 0xee0c0200 0 0x118>; > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + clocks = <&cpg CPG_MOD 706>, <&cpg CPG_MOD > > 705>; > > > + clock-names = "usbhs", "usb20_host"; > > > + status = "disabled"; > > 'status = "disabled"'. Oops! I overlooked this line... > > > + resets = <&cpg 706>, <&cpg 705>; > > > + power-domains = <&sysc > > R8A77470_PD_ALWAYS_ON>; > > > + > > > + usb1: usb-channel@0 { > > > + reg = <0>; > > > + #phy-cells = <1>; > > > + }; > > > + }; > > > > I think this usbphy1 has to have 'status = "disabled"'. > > It is already disabled please see above. Indeed. However, I prefer that properties order of both usbphy0 and usbphy1 are the same because it improves readability. Best regards, Yoshihiro Shimoda > Regards, > Biju
RE: [PATCH 3/7] ARM: dts: r8a77470: Add USB PHY DT support
HI Shimoda-San, Thanks for the feedback. > Subject: RE: [PATCH 3/7] ARM: dts: r8a77470: Add USB PHY DT support > > Hi Biju-san, > > > From: Biju Das, Sent: Monday, October 29, 2018 6:15 PM > > > -Original Message- > > > From: Yoshihiro Shimoda > > > Sent: 29 October 2018 08:42 > > > > > > Hi Biju-san, > > > > > > > From: Biju Das, Sent: Thursday, October 25, 2018 10:57 PM > > > > > > > > Define the r8a77470 generic part of the USB PHY device node. > > > > > > > > Signed-off-by: Biju Das > > > > --- > > > > This patch is tested against renesas-devel > > > > > > Thank you for the patch! > > > > > > > > > > +usbphy1: usb-phy@e6598100 { > > > > +compatible = "renesas,usb-phy-r8a77470", > > > > + "renesas,rcar-gen2-usb-phy"; > > > > +reg = <0 0xe6598100 0 0x100>, > > > > + <0 0xee0c0200 0 0x118>; > > > > +#address-cells = <1>; > > > > +#size-cells = <0>; > > > > +clocks = <&cpg CPG_MOD 706>, <&cpg CPG_MOD > > > 705>; > > > > +clock-names = "usbhs", "usb20_host"; > > > > +status = "disabled"; > > > > 'status = "disabled"'. > > Oops! I overlooked this line... > > > > > +resets = <&cpg 706>, <&cpg 705>; > > > > +power-domains = <&sysc > > > R8A77470_PD_ALWAYS_ON>; > > > > + > > > > +usb1: usb-channel@0 { > > > > +reg = <0>; > > > > +#phy-cells = <1>; > > > > +}; > > > > +}; > > > > > > I think this usbphy1 has to have 'status = "disabled"'. > > > > It is already disabled please see above. > > Indeed. > However, I prefer that properties order of both usbphy0 and usbphy1 are > the same because it improves readability. OK. Will fix this. Regards, Biju Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH] arm64: dts: renesas: r8a77990: add/enable USB3.0 peripheral device node
On Mon, Oct 22, 2018 at 03:47:08PM +0900, Yoshihiro Shimoda wrote: > This patch adds/enables USB3.0 peripheral device node for r8a77990 > ebisu board. > > Signed-off-by: Yoshihiro Shimoda Thanks Shimoda-san, applied for v4.21.
Re: [PATCH 01/03] arm64: dts: renesas: r8a77965: Connect R-Car M3-N AVB to IPMMU
On Mon, Oct 22, 2018 at 02:14:44AM +0900, Magnus Damm wrote: > From: Magnus Damm > > Hook up the R-Car M3-N AVB device to IPMMU-DS0 16 as described in > the data sheet. > > Signed-off-by: Magnus Damm Tested-by: Simon Horman I will apply this for v4.21. > --- > > arch/arm64/boot/dts/renesas/r8a77965.dtsi |1 + > 1 file changed, 1 insertion(+) > > --- 0001/arch/arm64/boot/dts/renesas/r8a77965.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a77965.dtsi2018-10-22 > 01:46:02.498689171 +0900 > @@ -900,6 +900,7 @@ > power-domains = <&sysc R8A77965_PD_ALWAYS_ON>; > resets = <&cpg 812>; > phy-mode = "rgmii"; > + iommus = <&ipmmu_ds0 16>; > #address-cells = <1>; > #size-cells = <0>; > status = "disabled"; >
Re: [PATCH 03/03] arm64: dts: renesas: r8a77990: Connect R-Car E3 AVB to IPMMU
On Mon, Oct 22, 2018 at 02:15:03AM +0900, Magnus Damm wrote: > From: Magnus Damm > > Hook up the R-Car E3 AVB device to IPMMU-DS0 16 as described in > the data sheet. > > Signed-off-by: Magnus Damm Tested-by: Simon Horman I will apply this for v4.21. > --- > > arch/arm64/boot/dts/renesas/r8a77990.dtsi |1 + > 1 file changed, 1 insertion(+) > > --- 0001/arch/arm64/boot/dts/renesas/r8a77990.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a77990.dtsi2018-10-22 > 01:48:50.488496607 +0900 > @@ -604,6 +604,7 @@ > power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; > resets = <&cpg 812>; > phy-mode = "rgmii"; > + iommus = <&ipmmu_ds0 16>; > #address-cells = <1>; > #size-cells = <0>; > status = "disabled"; >
Re: [PATCH 02/03] arm64: dts: renesas: r8a77980: Connect R-Car V3H AVB to IPMMU
On Mon, Oct 22, 2018 at 02:14:54AM +0900, Magnus Damm wrote: > From: Magnus Damm > > Hook up the R-Car V3H AVB device to IPMMU-DS1 33 as described in > the data sheet. > > Signed-off-by: Magnus Damm Thanks Magnus, applied for v4.21.
Re: [PATCH] arm64: dts: renesas: salvator-common: add companion property in usb3_peri0
On Mon, Oct 22, 2018 at 03:47:29PM +0900, Yoshihiro Shimoda wrote: > This patch adds a property "companion" with xhci0 phandle to > the usb3_peri0 node in salvator-common.dtsi. > > About the detail of this property for renesas_usb3 udc driver, please > refer to the commit 39facfa01c9f ("usb: gadget: udc: renesas_usb3: > Add register of usb role switch"). > > Signed-off-by: Yoshihiro Shimoda Thanks Shimoda-san, applied for v4.21. > --- > arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi > b/arch/arm64/boot/dts/renesas/salvator-common.dtsi > index 054a7ee..a3e8950 100644 > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi > +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi > @@ -817,6 +817,8 @@ > phys = <&usb3_phy0>; > phy-names = "usb"; > > + companion = <&xhci0>; > + > status = "okay"; > }; > > -- > 1.9.1 >
Re: [PATCH 03/03] arm: dts: Include SoC name in DTSI for sh73a0
On Mon, Oct 22, 2018 at 11:07:08AM +0300, Sergei Shtylyov wrote: > Hello! > >2 patches with the same name? > > On 21.10.2018 21:21, Magnus Damm wrote: > > > From: Magnus Damm > > > > Update the Emma Mobile EV2 DTSI to include product name. > >Shouldn't this be in the subject instead of sh73a0? I have applied this with an updated subject: From: Magnus Damm Date: Mon, 22 Oct 2018 03:21:39 +0900 Subject: [PATCH] arm: dts: Include SoC name in DTSI for Emma Mobile EV2 Update the Emma Mobile EV2 DTSI to include product name. Signed-off-by: Magnus Damm Signed-off-by: Simon Horman --- arch/arm/boot/dts/emev2.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi index 373ea8720769..67d86012a85c 100644 --- a/arch/arm/boot/dts/emev2.dtsi +++ b/arch/arm/boot/dts/emev2.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the EMEV2 SoC + * Device Tree Source for the Emma Mobile EV2 SoC * * Copyright (C) 2012 Renesas Solutions Corp. */ -- 2.11.0
Re: [PATCH 02/03] arm: dts: Include SoC name in DTSI for sh73a0
On Mon, Oct 22, 2018 at 03:21:30AM +0900, Magnus Damm wrote: > From: Magnus Damm > > Update the SH-Mobile AG5 DTSI to include product name. > > Signed-off-by: Magnus Damm Thanks, applied for v4.21.
Re: [PATCH 01/03] arm: dts: Include SoC name in DTSI for r8a7740
On Mon, Oct 22, 2018 at 03:21:20AM +0900, Magnus Damm wrote: > From: Magnus Damm > > Update the R-Mobile A1 DTSI to include product name. > > Signed-off-by: Magnus Damm Thanks, applied for v4.21.
Re: [PATCH v3] arm64: dts: renesas: add/enable USB2.0 peripheral for R-Car [DE]3
On Wed, Oct 24, 2018 at 05:32:33PM +0900, Yoshihiro Shimoda wrote: > This patch adds/enables USB2.0 peripheral for R-Car [DE]3 boards. > > R-Car E3 Ebisu board connects the ID pin to the SoC, so this adds > a group "usb0_id" into usb0_pins node. Also, to use SW15 pin 3 side, > this patch adds vbus0_usb2 node on r8a77990-ebisu.dts. > > R-Car D3 Draak board doesn't connect the ID pin, so this adds > "renesas,no-otg-pins" property into usb2_phy0 node. > > Signed-off-by: Yoshihiro Shimoda > --- > Changed from v2: > - Use otg pin on r8a77990-ebisu board. So, I revise the commit log. > - I got Reviewed-by from Simon-san at v2. However, since I change >the integration at v3 as above. I didn't add Reviewed-by on this. > > Changed from v1: > - Revise the reg size for each hsusb node. Thanks, applied for v4.21.
Re: [PATCH 1/2] ARM: dts: r8a77470: Add watchdog support to SoC dtsi
On Fri, Oct 26, 2018 at 09:42:38AM +, Fabrizio Castro wrote: > > Subject: [PATCH 1/2] ARM: dts: r8a77470: Add watchdog support to SoC dtsi > > > > This patch adds watchdog support to the r8a77470 SoC dtsi. > > > > Signed-off-by: Biju Das > > Reviewed-by: Fabrizio Castro Thanks, applied for v4.21.
Re: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable watchdog support
On Fri, Oct 26, 2018 at 09:42:40AM +, Fabrizio Castro wrote: > > Subject: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable watchdog support > > > > This patch enables watchdog support on the iWave iwg23s sbc. > > > > Signed-off-by: Biju Das > > Reviewed-by: Fabrizio Castro Thanks, applied for v4.21.
Re: [PATCH 1/2] dt-bindings: dmaengine: usb-dmac: Add binding for r8a77470
On Thu, Oct 25, 2018 at 03:53:37PM +0100, Biju Das wrote: > This patch adds usb high-speed dmac binding for r8a77470 (RZ/G1C) SoC. > > Signed-off-by: Biju Das Reviewed-by: Simon Horman
Re: [PATCH 2/2] ARM: dts: r8a77470: Add USB-DMAC device nodes
On Fri, Oct 26, 2018 at 09:47:09AM +, Fabrizio Castro wrote: > > Subject: [PATCH 2/2] ARM: dts: r8a77470: Add USB-DMAC device nodes > > > > This patch adds USB DMAC nodes. > > > > Signed-off-by: Biju Das > > Reviewed-by: Fabrizio Castro Thanks, applied for v4.21.
[PATCH] serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeout
This patch fixes an issue that the sci_remove() could not remove dev_attr_rx_fifo_timeout because uart_remove_one_port() set the port->port.type to PORT_UNKNOWN. Reported-by: Hiromitsu Yamasaki Fixes: 5d23188a473d ("serial: sh-sci: make RX FIFO parameters tunable via sysfs") Cc: # v4.11+ Signed-off-by: Yoshihiro Shimoda --- drivers/tty/serial/sh-sci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index ab3f6e91..3649b83 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -3102,6 +3102,7 @@ static inline int sci_probe_earlyprintk(struct platform_device *pdev) static int sci_remove(struct platform_device *dev) { struct sci_port *port = platform_get_drvdata(dev); + unsigned int type = port->port.type;/* uart_remove_... clears it */ sci_ports_in_use &= ~BIT(port->port.line); uart_remove_one_port(&sci_uart_driver, &port->port); @@ -3112,8 +3113,7 @@ static int sci_remove(struct platform_device *dev) sysfs_remove_file(&dev->dev.kobj, &dev_attr_rx_fifo_trigger.attr); } - if (port->port.type == PORT_SCIFA || port->port.type == PORT_SCIFB || - port->port.type == PORT_HSCIF) { + if (type == PORT_SCIFA || type == PORT_SCIFB || type == PORT_HSCIF) { sysfs_remove_file(&dev->dev.kobj, &dev_attr_rx_fifo_timeout.attr); } -- 1.9.1
Re: [PATCH linux-next v1 2/4] clk: renesas: Add binding document for AVB Counter Clock
On Thu, Oct 25, 2018 at 9:32 PM Jiada Wang wrote: > > Hi Rob > > > On 2018/10/26 6:49, Rob Herring wrote: > > On Thu, Oct 25, 2018 at 04:23:47PM +0900, jiada_w...@mentor.com wrote: > >> From: Jiada Wang > >> > >> Add device tree bindings for avb counter clock for Renesas > >> R-Car Socs. > >> > >> Signed-off-by: Jiada Wang > >> --- > >> .../bindings/clock/renesas,avb-clk.txt| 19 +++ > >> 1 file changed, 19 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/clock/renesas,avb-clk.txt > >> > >> diff --git a/Documentation/devicetree/bindings/clock/renesas,avb-clk.txt > >> b/Documentation/devicetree/bindings/clock/renesas,avb-clk.txt > >> new file mode 100644 > >> index ..03bf50b5830c > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/clock/renesas,avb-clk.txt > >> @@ -0,0 +1,19 @@ > >> +* Renesas AVB Counter Clock > >> + > >> +The AVB Counter Clocks are provided by avb_counter8 Clock Generator, > >> +avb_counter8 has dividers which operates with S0D1ϕ clock and has > >> +8 output clocks. > >> + > >> +Required Properties: > >> + - compatible: Must be "renesas,clk-avb" > > Should be SoC specific? > yes, avb counter clock is SoC specific, I will move avb clock node to > Soc .dtsi in next version The compatible string should be SoC specific too then. Rob
Re: [PATCH 5/5] pinctrl: pinctrl-at91-pio4: simplify getting .driver_data
On Sun, Oct 21, 2018 at 10:00:31PM +0200, Wolfram Sang wrote: > We should get 'driver_data' from 'struct device' directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Acked-by: Ludovic Desroches Thanks > --- > > Build tested only. buildbot is happy. > > drivers/pinctrl/pinctrl-at91-pio4.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c > b/drivers/pinctrl/pinctrl-at91-pio4.c > index 5a850491a5cb..4ee135d7b883 100644 > --- a/drivers/pinctrl/pinctrl-at91-pio4.c > +++ b/drivers/pinctrl/pinctrl-at91-pio4.c > @@ -868,8 +868,7 @@ static struct pinctrl_desc atmel_pinctrl_desc = { > > static int __maybe_unused atmel_pctrl_suspend(struct device *dev) > { > - struct platform_device *pdev = to_platform_device(dev); > - struct atmel_pioctrl *atmel_pioctrl = platform_get_drvdata(pdev); > + struct atmel_pioctrl *atmel_pioctrl = dev_get_drvdata(dev); > int i, j; > > /* > @@ -897,8 +896,7 @@ static int __maybe_unused atmel_pctrl_suspend(struct > device *dev) > > static int __maybe_unused atmel_pctrl_resume(struct device *dev) > { > - struct platform_device *pdev = to_platform_device(dev); > - struct atmel_pioctrl *atmel_pioctrl = platform_get_drvdata(pdev); > + struct atmel_pioctrl *atmel_pioctrl = dev_get_drvdata(dev); > int i, j; > > for (i = 0; i < atmel_pioctrl->nbanks; i++) { > -- > 2.19.0 >
[PATCH 0/2] pinctrl: sh-pfc: r8a77965: Add VIN4 and VIN5
Hello, this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N. On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups could appear on different sets of pins, usually the 'a' and 'b' one. With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as: VIN_DATA_PIN_GROUP(vin4_data_a, 8) which results in the group being named as "vin4_data_a_8" which is un-consistent with the canonical group names (eg. "vin4_data8_a"). This series adds a macro that allows to specify the group 'version' along with the pin and mux numbers in patch [1/1]. I haven't been able to find a better term than 'version' as 'group' was already taken. Suggestions welcome. As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not wired, I made sure the macro creates correct names and fields not only by compile testing it, but with a small C program [1] that replicates the VIN data layout defined in the PFC module and access fields (and has helped me testing more easily the preprocessor stringification/concatenation process). Final note: Simon, you took the E3 patches in your tree, and I expect them to land on v4.20-rc1. They use the old macros, are follow up patches ok?) Thanks j [1] https://paste.debian.net/1049603/ Jacopo Mondi (2): pinctrl: sh-pfc: Introduce VIN_DATA_PIN_GROUP_VER pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++ drivers/pinctrl/sh-pfc/sh_pfc.h | 20 ++- 2 files changed, 269 insertions(+), 5 deletions(-) -- 2.7.4
[PATCH 2/2] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
The VIN4 and VIN5 interfaces supports parallel video input. Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N. Signed-off-by: Jacopo Mondi --- drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++ 1 file changed, 254 insertions(+) diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c index dfdd982..1aca4b0 100644 --- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c @@ -3725,6 +3725,216 @@ static const unsigned int usb30_mux[] = { USB30_PWEN_MARK, USB30_OVC_MARK, }; +/* - VIN4 --- */ +static const unsigned int vin4_data18_a_pins[] = { + RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11), + RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13), + RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15), + RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3), + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7), + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3), + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7), +}; + +static const unsigned int vin4_data18_a_mux[] = { + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK, + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK, + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK, + VI4_DATA10_MARK, VI4_DATA11_MARK, + VI4_DATA12_MARK, VI4_DATA13_MARK, + VI4_DATA14_MARK, VI4_DATA15_MARK, + VI4_DATA18_MARK, VI4_DATA19_MARK, + VI4_DATA20_MARK, VI4_DATA21_MARK, + VI4_DATA22_MARK, VI4_DATA23_MARK, +}; + +static const union vin_data vin4_data_a_pins = { + .data24 = { + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9), + RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11), + RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13), + RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15), + RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1), + RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3), + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7), + RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1), + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3), + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7), + }, +}; + +static const union vin_data vin4_data_a_mux = { + .data24 = { + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK, + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK, + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK, + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK, + VI4_DATA8_MARK, VI4_DATA9_MARK, + VI4_DATA10_MARK, VI4_DATA11_MARK, + VI4_DATA12_MARK, VI4_DATA13_MARK, + VI4_DATA14_MARK, VI4_DATA15_MARK, + VI4_DATA16_MARK, VI4_DATA17_MARK, + VI4_DATA18_MARK, VI4_DATA19_MARK, + VI4_DATA20_MARK, VI4_DATA21_MARK, + VI4_DATA22_MARK, VI4_DATA23_MARK, + }, +}; + +static const unsigned int vin4_data18_b_pins[] = { + RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3), + RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5), + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7), + RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3), + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7), + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3), + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7), +}; + +static const unsigned int vin4_data18_b_mux[] = { + VI4_DATA2_B_MARK, VI4_DATA3_B_MARK, + VI4_DATA4_B_MARK, VI4_DATA5_B_MARK, + VI4_DATA6_B_MARK, VI4_DATA7_B_MARK, + VI4_DATA10_MARK, VI4_DATA11_MARK, + VI4_DATA12_MARK, VI4_DATA13_MARK, + VI4_DATA14_MARK, VI4_DATA15_MARK, + VI4_DATA18_MARK, VI4_DATA19_MARK, + VI4_DATA20_MARK, VI4_DATA21_MARK, + VI4_DATA22_MARK, VI4_DATA23_MARK, +}; + +static const union vin_data vin4_data_b_pins = { + .data24 = { + RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1), + RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3), + RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5), + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7), + RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1), + RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3), + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7), + RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1), + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3), + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7), + }, +}; + +static const union vin_data vin4_data_b_mux = { + .data24 = { + VI4_DATA0_B_MARK, VI4_DATA1_B_MARK, + VI4_DATA2_B_MARK, VI4_DATA3_B_MARK, + VI4_DATA4_B_MARK, VI4_DATA5_B_MARK, + VI4_DATA6_B_MARK, VI4_DATA7_B_MAR
[PATCH 1/2] pinctrl: sh-pfc: Introduce VIN_DATA_PIN_GROUP_VER
VIN data groups may appear on different sets of pins, usually named "vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support appending the 'a' or 'b' suffix, leading to the definition of groups names not consistent with the ones defined using SH_PFC_PIN_GROUP() macro. Fix this by adding a macro that supports appending suffixes when required. Signed-off-by: Jacopo Mondi --- drivers/pinctrl/sh-pfc/sh_pfc.h | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h index 458ae0a..2930e9a 100644 --- a/drivers/pinctrl/sh-pfc/sh_pfc.h +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h @@ -54,17 +54,27 @@ struct sh_pfc_pin_group { /* * Using union vin_data saves memory occupied by the VIN data pins. - * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups - * in this case. + * + * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups, + * while VIN_DATA_PIN_GROUP_VER() is used when the same pin group can appear + * on different sets of pins. */ -#define VIN_DATA_PIN_GROUP(n, s) \ - { \ - .name = #n#s, \ +#define __VIN_DATA_PIN_GROUP(n, s) \ .pins = n##_pins.data##s, \ .mux = n##_mux.data##s, \ .nr_pins = ARRAY_SIZE(n##_pins.data##s),\ } +#define VIN_DATA_PIN_GROUP(n, s) \ + { \ + .name = #n#s, \ + __VIN_DATA_PIN_GROUP(n, s) + +#define VIN_DATA_PIN_GROUP_VER(n, v, s)\ + { \ + .name = #n#s"_"#v, \ + __VIN_DATA_PIN_GROUP(n##_##v, s) + union vin_data { unsigned int data24[24]; unsigned int data20[20]; -- 2.7.4
Re: [PATCH linux-next v1 2/4] clk: renesas: Add binding document for AVB Counter Clock
Quoting jiada_w...@mentor.com (2018-10-25 00:23:47) > From: Jiada Wang > > Add device tree bindings for avb counter clock for Renesas > R-Car Socs. > > Signed-off-by: Jiada Wang > --- > .../bindings/clock/renesas,avb-clk.txt| 19 +++ > 1 file changed, 19 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/renesas,avb-clk.txt > > diff --git a/Documentation/devicetree/bindings/clock/renesas,avb-clk.txt > b/Documentation/devicetree/bindings/clock/renesas,avb-clk.txt > new file mode 100644 > index ..03bf50b5830c > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/renesas,avb-clk.txt > @@ -0,0 +1,19 @@ > +* Renesas AVB Counter Clock > + > +The AVB Counter Clocks are provided by avb_counter8 Clock Generator, > +avb_counter8 has dividers which operates with S0D1ϕ clock and has > +8 output clocks. > + > +Required Properties: > + - compatible: Must be "renesas,clk-avb" > + - reg: Base address and length of the memory resource used by the AVB > + - #clock-cells: Must be 1 > + > +Example > +--- > + > + clk_avb: avb-clock@ec5a011c { > + compatible = "renesas,clk-avb"; > + reg = <0 0xec5a011c 0 0x24>; This is an odd register offset. Is this just one clk inside of a larger clk controller?
Re: [PATCH linux-next v1 1/4] clk: renesas: clk-avb: add AVB Clock driver
Quoting jiada_w...@mentor.com (2018-10-25 00:23:46) > diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile > index 71d4cafe15c0..17b05955e4f4 100644 > --- a/drivers/clk/renesas/Makefile > +++ b/drivers/clk/renesas/Makefile > @@ -34,3 +34,4 @@ obj-$(CONFIG_CLK_RCAR_USB2_CLOCK_SEL) += > rcar-usb2-clock-sel.o > obj-$(CONFIG_CLK_RENESAS_CPG_MSSR) += renesas-cpg-mssr.o > obj-$(CONFIG_CLK_RENESAS_CPG_MSTP) += clk-mstp.o > obj-$(CONFIG_CLK_RENESAS_DIV6) += clk-div6.o > +obj-$(CONFIG_CLK_RENESAS_CLK_AVB) += clk-avb.o Any reason this can't be placed in some sort of alphabetical order instead of at the end of the file? > diff --git a/drivers/clk/renesas/clk-avb.c b/drivers/clk/renesas/clk-avb.c > new file mode 100644 > index ..bb1eef0e9bee > --- /dev/null > +++ b/drivers/clk/renesas/clk-avb.c > @@ -0,0 +1,257 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2017 Mentor > + * > + * Contact: Jiada Wang > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; version 2 of the License. Can you remove this paragraph? It duplicates the SPDX tag. > + * > + * avb Common Clock Framework support > + */ > + > +#include > +#include > +#include > +#include > + > +struct clk_avb_data { > + void __iomem *base; > + > + struct clk_onecell_data clk_data; > + /* lock reg access */ > + spinlock_t lock; > +}; > + > +struct clk_avb { > + struct clk_hw hw; > + unsigned int idx; > + struct clk_avb_data *data; > +}; > + > +#define to_clk_avb(_hw) container_of(_hw, struct clk_avb, hw) > + > +#define AVB_DIV_MASK 0x3 > +#define AVB_MAX_DIV0x3ffc0 > +#define AVB_COUNTER_MAX_FREQ 2500 > +#define AVB_COUNTER_NUM8 > +#define AVB_CLK_NAME_SIZE 10 > +#define AVB_ID_TO_DIV(id) ((id) * 4) > + > +#define AVB_CLK_CONFIG 0x20 > +#define AVB_DIV_EN_COM BIT(31) > +#define AVB_CLK_NAME "avb" > +#define ADG_CLK_NAME "adg" > + > +static int clk_avb_is_enabled(struct clk_hw *hw) > +{ > + struct clk_avb *avb = to_clk_avb(hw); > + > + return (clk_readl(avb->data->base + AVB_CLK_CONFIG) & BIT(avb->idx)); Please drop the extra parenthesis. > +} > + > +static int clk_avb_enabledisable(struct clk_hw *hw, int enable) > +{ > + struct clk_avb *avb = to_clk_avb(hw); > + u32 val; > + > + spin_lock(&avb->data->lock); > + > + val = clk_readl(avb->data->base + AVB_CLK_CONFIG); > + if (enable) > + val |= BIT(avb->idx); > + else > + val &= ~BIT(avb->idx); > + clk_writel(val, avb->data->base + AVB_CLK_CONFIG); > + > + spin_unlock(&avb->data->lock); > + > + return 0; > +} > + > +static int clk_avb_enable(struct clk_hw *hw) > +{ > + return clk_avb_enabledisable(hw, 1); > +} > + > +static void clk_avb_disable(struct clk_hw *hw) > +{ > + clk_avb_enabledisable(hw, 0); > +} > + > +static unsigned long clk_avb_recalc_rate(struct clk_hw *hw, > +unsigned long parent_rate) > +{ > + struct clk_avb *avb = to_clk_avb(hw); > + u32 div; > + > + div = clk_readl(avb->data->base + AVB_ID_TO_DIV(avb->idx)) & > + AVB_DIV_MASK; Split this to two lines: div = readl(...); div &= AVB_DIV_MASK; > + if (!div) > + return parent_rate; > + > + return parent_rate * 32 / div; > +} > + > +static unsigned int clk_avb_calc_div(unsigned long rate, > +unsigned long parent_rate) > +{ > + unsigned int div; > + > + if (!rate) > + rate = 1; > + > + if (rate > AVB_COUNTER_MAX_FREQ) > + rate = AVB_COUNTER_MAX_FREQ; rate = min(rate, AVB_COUNTER_MAX_FREQ); > + > + div = DIV_ROUND_CLOSEST(parent_rate * 32, rate); > + > + if (div > AVB_MAX_DIV) > + div = AVB_MAX_DIV; div = min(div, AVB_MAX_DIV); > + > + return div; > +} > + > +static long clk_avb_round_rate(struct clk_hw *hw, unsigned long rate, > + unsigned long *parent_rate) > +{ > + unsigned int div = clk_avb_calc_div(rate, *parent_rate); > + > + return (*parent_rate * 32) / div; > +} > + > +static int clk_avb_set_rate(struct clk_hw *hw, unsigned long rate, > + unsigned long parent_rate) > +{ > + struct clk_avb *avb = to_clk_avb(hw); > + unsigned int div = clk_avb_calc_div(rate, parent_rate); > + u32 val; > + > + val = clk_readl(avb->data->base + AVB_ID_TO_DIV(avb->idx)) & > + ~AVB_DIV_MASK; > + clk_writel(val | div, avb->data->base + AVB_ID_TO_DIV(avb->idx)); Any reason to use clk_readl/writel? Preferably these APIs aren't used and you just use readl/writel instead. > +
Re: [PATCH 1/2] pinctrl: sh-pfc: Introduce VIN_DATA_PIN_GROUP_VER
> On October 29, 2018 at 7:13 PM Jacopo Mondi wrote: > > > VIN data groups may appear on different sets of pins, usually named > "vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support > appending > the 'a' or 'b' suffix, leading to the definition of groups names not > consistent > with the ones defined using SH_PFC_PIN_GROUP() macro. > > Fix this by adding a macro that supports appending suffixes when required. > > Signed-off-by: Jacopo Mondi > --- > drivers/pinctrl/sh-pfc/sh_pfc.h | 20 +++- > 1 file changed, 15 insertions(+), 5 deletions(-) > > diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h > index 458ae0a..2930e9a 100644 > --- a/drivers/pinctrl/sh-pfc/sh_pfc.h > +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h > @@ -54,17 +54,27 @@ struct sh_pfc_pin_group { > > /* > * Using union vin_data saves memory occupied by the VIN data pins. > - * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups > - * in this case. > + * > + * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups, Maybe fix the odd spacing, while you're at it? > + * while VIN_DATA_PIN_GROUP_VER() is used when the same pin group can appear > + * on different sets of pins. > */ > -#define VIN_DATA_PIN_GROUP(n, s) \ > - { \ > - .name = #n#s, \ > +#define __VIN_DATA_PIN_GROUP(n, s) \ > .pins = n##_pins.data##s, \ > .mux = n##_mux.data##s, \ > .nr_pins = ARRAY_SIZE(n##_pins.data##s),\ > } > > +#define VIN_DATA_PIN_GROUP(n, s) \ > + { \ > + .name = #n#s, \ > + __VIN_DATA_PIN_GROUP(n, s) > + > +#define VIN_DATA_PIN_GROUP_VER(n, v, s) \ > + { \ > + .name = #n#s"_"#v, \ > + __VIN_DATA_PIN_GROUP(n##_##v, s) > + > union vin_data { > unsigned int data24[24]; > unsigned int data20[20]; > -- > 2.7.4 > With or without the whitespace fix: Reviewed-by: Ulrich Hecht CU Uli
Re: [PATCH 2/2] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
Thank you for your patch. > On October 29, 2018 at 7:13 PM Jacopo Mondi wrote: > > > The VIN4 and VIN5 interfaces supports parallel video input. > Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N. > > Signed-off-by: Jacopo Mondi > --- > drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 > ++ > 1 file changed, 254 insertions(+) > > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c > b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c > index dfdd982..1aca4b0 100644 > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c > @@ -3725,6 +3725,216 @@ static const unsigned int usb30_mux[] = { > USB30_PWEN_MARK, USB30_OVC_MARK, > }; > > +/* - VIN4 > --- */ > +static const unsigned int vin4_data18_a_pins[] = { > + RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11), > + RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13), > + RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15), > + RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3), > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7), > + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3), > + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), > + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7), > +}; > + > +static const unsigned int vin4_data18_a_mux[] = { > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK, > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK, > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK, > + VI4_DATA10_MARK, VI4_DATA11_MARK, > + VI4_DATA12_MARK, VI4_DATA13_MARK, > + VI4_DATA14_MARK, VI4_DATA15_MARK, > + VI4_DATA18_MARK, VI4_DATA19_MARK, > + VI4_DATA20_MARK, VI4_DATA21_MARK, > + VI4_DATA22_MARK, VI4_DATA23_MARK, > +}; > + > +static const union vin_data vin4_data_a_pins = { > + .data24 = { > + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9), > + RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11), > + RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13), > + RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15), > + RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1), > + RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3), > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7), > + RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1), > + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3), > + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), > + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7), > + }, > +}; > + > +static const union vin_data vin4_data_a_mux = { > + .data24 = { > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK, > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK, > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK, > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK, > + VI4_DATA8_MARK, VI4_DATA9_MARK, > + VI4_DATA10_MARK, VI4_DATA11_MARK, > + VI4_DATA12_MARK, VI4_DATA13_MARK, > + VI4_DATA14_MARK, VI4_DATA15_MARK, > + VI4_DATA16_MARK, VI4_DATA17_MARK, > + VI4_DATA18_MARK, VI4_DATA19_MARK, > + VI4_DATA20_MARK, VI4_DATA21_MARK, > + VI4_DATA22_MARK, VI4_DATA23_MARK, > + }, > +}; > + > +static const unsigned int vin4_data18_b_pins[] = { > + RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3), > + RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5), > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7), > + RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3), > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7), > + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3), > + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), > + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7), > +}; > + > +static const unsigned int vin4_data18_b_mux[] = { > + VI4_DATA2_B_MARK, VI4_DATA3_B_MARK, > + VI4_DATA4_B_MARK, VI4_DATA5_B_MARK, > + VI4_DATA6_B_MARK, VI4_DATA7_B_MARK, > + VI4_DATA10_MARK, VI4_DATA11_MARK, > + VI4_DATA12_MARK, VI4_DATA13_MARK, > + VI4_DATA14_MARK, VI4_DATA15_MARK, > + VI4_DATA18_MARK, VI4_DATA19_MARK, > + VI4_DATA20_MARK, VI4_DATA21_MARK, > + VI4_DATA22_MARK, VI4_DATA23_MARK, > +}; > + > +static const union vin_data vin4_data_b_pins = { > + .data24 = { > + RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1), > + RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3), > + RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5), > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7), > + RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1), > + RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3), > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7), > + RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1), > + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3), > + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), > + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7), > + }, > +}; > + > +static const union vin_data vin4_data_b_mux = { > + .data24 = { > + VI4_DATA0_B_MARK, V