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
