[PATCH 3/5] pwm: rcar: Use "atomic" API on rcar_pwm_resume()
To remove legacy API related functions in the future, this patch
uses "atomic" related function instead. No change in behavior.
Signed-off-by: Yoshihiro Shimoda
---
drivers/pwm/pwm-rcar.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index a5ea0f3..1bcb662 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -319,18 +319,16 @@ static int rcar_pwm_suspend(struct device *dev)
static int rcar_pwm_resume(struct device *dev)
{
struct pwm_device *pwm = rcar_pwm_dev_to_pwm_dev(dev);
+ struct pwm_state state;
if (!test_bit(PWMF_REQUESTED, >flags))
return 0;
pm_runtime_get_sync(dev);
- rcar_pwm_config(pwm->chip, pwm, pwm->state.duty_cycle,
- pwm->state.period);
- if (pwm_is_enabled(pwm))
- rcar_pwm_enable(pwm->chip, pwm);
+ pwm_get_state(pwm, );
- return 0;
+ return rcar_pwm_apply(pwm->chip, pwm, );
}
#endif /* CONFIG_PM_SLEEP */
static SIMPLE_DEV_PM_OPS(rcar_pwm_pm_ops, rcar_pwm_suspend, rcar_pwm_resume);
--
1.9.1
[PATCH 5/5] pwm: rcar: add workaround to output "pseudo" low level
This PWM Timer cannot output low because setting 0x000 is prohibited
on PWMCNT.PH0 (High-Level Period) bitfields. So, avoiding
the prohibited, this patch adds a workaround function to change
the value from 0 to 1 as pseudo low level.
Signed-off-by: Yoshihiro Shimoda
---
drivers/pwm/pwm-rcar.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index e479b6a..888cb37 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -166,6 +166,20 @@ static void rcar_pwm_disable(struct rcar_pwm_chip *rp)
rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
}
+static void rcar_pwm_workaround_output_low(struct rcar_pwm_chip *rp)
+{
+ /*
+* This PWM Timer cannot output low because setting 0x000 is
+* prohibited on PWMCNT.PH0 (High-Level Period) bitfields. So, avoiding
+* the prohibited, this function changes the value from 0 to 1 as
+* pseudo low level.
+*
+* TODO: Add GPIO handling to output low level.
+*/
+ if ((rp->pwmcnt & RCAR_PWMCNT_PH0_MASK) == 0)
+ rp->pwmcnt |= 1;
+}
+
static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state)
{
@@ -179,6 +193,7 @@ static int rcar_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
rcar_pwm_calc_counter(rp, div, state->duty_cycle, state->period);
+ rcar_pwm_workaround_output_low(rp);
ret = rcar_pwm_set_counter(rp);
if (!ret)
rcar_pwm_set_clock_control(rp, div);
--
1.9.1
[PATCH 2/5] pwm: rcar: Add support "atomic" API
This patch adds support for "atomic" API. Behavior is the same as
when using legacy APIs.
Signed-off-by: Yoshihiro Shimoda
---
drivers/pwm/pwm-rcar.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index 9cf4567..a5ea0f3 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -200,12 +200,44 @@ static void rcar_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
}
+static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct rcar_pwm_chip *rp = to_rcar_pwm_chip(chip);
+ int div, ret;
+
+ div = rcar_pwm_get_clock_division(rp, state->period);
+ if (div < 0)
+ return div;
+
+ rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
+
+ rcar_pwm_calc_counter(rp, div, state->duty_cycle, state->period);
+ ret = rcar_pwm_set_counter(rp);
+ if (!ret)
+ rcar_pwm_set_clock_control(rp, div);
+
+ /* The SYNC should be set to 0 even if rcar_pwm_set_counter failed */
+ rcar_pwm_update(rp, RCAR_PWMCR_SYNC, 0, RCAR_PWMCR);
+
+ if (!ret && state->enabled)
+ ret = rcar_pwm_enable(chip, pwm);
+
+ if (!state->enabled) {
+ rcar_pwm_disable(chip, pwm);
+ ret = 0;
+ }
+
+ return ret;
+}
+
static const struct pwm_ops rcar_pwm_ops = {
.request = rcar_pwm_request,
.free = rcar_pwm_free,
.config = rcar_pwm_config,
.enable = rcar_pwm_enable,
.disable = rcar_pwm_disable,
+ .apply = rcar_pwm_apply,
.owner = THIS_MODULE,
};
--
1.9.1
[PATCH 1/5] pwm: rcar: add rcar_pwm_calc_counter() to calculate PWMCNT value only
To add a workaround in the future, this patch adds a function
rcar_pwm_calc_counter() from rcar_pwm_set_counter().
The rcar_pwm_calc_counter() calculates PWMCNT value only, and
rcar_pwm_set_counter() set the PWMCNT register by using
the calculated value. No change in behavior.
Signed-off-by: Yoshihiro Shimoda
---
drivers/pwm/pwm-rcar.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index a41812f..9cf4567 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -36,6 +36,7 @@ struct rcar_pwm_chip {
struct pwm_chip chip;
void __iomem *base;
struct clk *clk;
+ u32 pwmcnt;
};
static inline struct rcar_pwm_chip *to_rcar_pwm_chip(struct pwm_chip *chip)
@@ -102,8 +103,8 @@ static void rcar_pwm_set_clock_control(struct rcar_pwm_chip
*rp,
rcar_pwm_write(rp, value, RCAR_PWMCR);
}
-static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp, int div, int duty_ns,
- int period_ns)
+static void rcar_pwm_calc_counter(struct rcar_pwm_chip *rp, int div,
+ int duty_ns, int period_ns)
{
unsigned long long one_cycle, tmp; /* 0.01 nanoseconds */
unsigned long clk_rate = clk_get_rate(rp->clk);
@@ -120,11 +121,17 @@ static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp,
int div, int duty_ns,
do_div(tmp, one_cycle);
ph = tmp & RCAR_PWMCNT_PH0_MASK;
+ rp->pwmcnt = cyc | ph;
+}
+
+static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp)
+{
/* Avoid prohibited setting */
- if (cyc == 0 || ph == 0)
+ if ((rp->pwmcnt & RCAR_PWMCNT_CYC0_MASK) == 0 ||
+ (rp->pwmcnt & RCAR_PWMCNT_PH0_MASK) == 0)
return -EINVAL;
- rcar_pwm_write(rp, cyc | ph, RCAR_PWMCNT);
+ rcar_pwm_write(rp, rp->pwmcnt, RCAR_PWMCNT);
return 0;
}
@@ -159,7 +166,8 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
- ret = rcar_pwm_set_counter(rp, div, duty_ns, period_ns);
+ rcar_pwm_calc_counter(rp, div, duty_ns, period_ns);
+ ret = rcar_pwm_set_counter(rp);
if (!ret)
rcar_pwm_set_clock_control(rp, div);
--
1.9.1
[PATCH 0/5] pwm: rcar: Add support "atomic" API and workaround
This patch adds support for PWM "atomic" API. This patch also adds a workaround to output "pseudo" low level. Otherwise, the PWM backlight driver doesn't work correctly, especially it cannot output maximum brightness actually. Yoshihiro Shimoda (5): pwm: rcar: add rcar_pwm_calc_counter() to calculate PWMCNT value only pwm: rcar: Add support "atomic" API pwm: rcar: Use "atomic" API on rcar_pwm_resume() pwm: rcar: remove legacy APIs pwm: rcar: add workaround to output "pseudo" low level drivers/pwm/pwm-rcar.c | 108 - 1 file changed, 62 insertions(+), 46 deletions(-) -- 1.9.1
RE: [PATCH 2/3] phy: renesas: rcar-gen3-usb2: Add support for R7S9210
Hi Chris-san, > From: Chris Brandt, Sent: Thursday, November 15, 2018 9:34 PM > > Hi Shimodaさん > > > From: Yoshihiro Shimoda > > Sent: Thursday, November 15, 2018 4:20 AM > > > > Host does NOT work: > > > //else > > > // /* No otg, so default to host mode */ > > > // writel(0x, usb2_base + USB2_COMMCTRL); > > > > I got it. However, I have a concern how to set the mode to peripheral on > > RZ/A2 > > if we applied this code. If someone would like to use the USB as > > peripheral > > on his board, this code is not suitable. > > But USB peripheral is a different driver. So, this code will not run. So > USB2_COMMCTRL will keep the default value 0x8000. > > Correct? Ah, this is you're correct. R-Car Gen3 code (drivers/usb/renesas_usbhs/rcar3.c) doesn't have phy control for now. > > So, I have an idea to set the default mode by using "dr_mode" property, > > instead of hardcoded. Since the driver already has such a function, > > we can reuse rcar_gen3_device_recognition() to set the default value. > > To achieve that, we need to modify the following though. > > - Don't enable "is_otg_channel". > > - Don't call rcar_gen3_enable_vbus_ctrl() to avoid ADPCTRL register > >because RZ/A2 doesn't have it. > > - Don't need to call rcar_gen3_set_linectrl to avoid LINECTRL1 register > >because RZ/A2 doesn't seem to need the setting on host mode. > > > > What do you think? > > If a board is designed for USB peripheral, why would they enable a EHCI > host driver for the same USB channel? > I am confused. I meant that USB peripheral of RZ/A2 need the phy driver, not a EHCI host driver. And I read Figure 32.1 of the RZ/A2 documentation and I wonder if we need to release USBCTR.PLL_RST even if we use USB peripheral mode. # Since the documentations doesn't mention the PHY area exactly, it's confusable for us though. # But, the phy driver assumed the driver handled "AHB Bridge", "Core" and "UCOM" registers. > > > > (In other words, if we use the port as peripheral with the reset value > > > > 0x8000, does it work?) > > > > > > We have not been able to get USB peripheral working on RZ/A2 yet. > > > For peripheral, RZ/A2 has HS-USB. > > > After plugging into the PC, HS-USB goes to Suspended state (DVSQ = > > "0110"). > > > It should go to Configured state (DVSQ = "0011") > > > > I guess we need to modify ./drivers/usb/renesas_usbhs/rza.c for RZ/A2 > > because RZ/A2's HS-USB has SYSCFG.CNEN, but doesn't have SYSCFG.UPLLE? > > Today for RZ/A1, we tell people to use USB0 first in their board design, > then use USB1 if they need a second USB channel. USB pins are dedicated > (no other function) so there should be no design conflicts. > > If only USB1 is used, USB0 must also be enabled in DT as a dummy driver > (so SYSCFG.UPLLE can get set for USB1). Oh, I heard RZ/G1C also has such a hardware register [1]. [1] https://patchwork.kernel.org/patch/10655855/ RZ/G1C channel 0 only has UGCTRL register, but need to set for channel 1. Best regards, Yoshihiro Shimoda > > > According to the RZ/A2 Hardware Manual, COMMCTRL should be 0x8000 > > when > > > using HS-USB. > > > > > > There are 2 channels of USB on RZ/A2 (host x 2, HS_USB x 2) > > > > I got it. So, I guess someone wants to use 1 host and 1 peripheral :) > > Yes. > > Chris
RE: [PATCH 2/3] phy: renesas: rcar-gen3-usb2: Add support for R7S9210
Hi Chris-san, > From: Chris Brandt, Sent: Wednesday, November 14, 2018 10:03 PM > > Hi Shimoda-san, > > > From: Yoshihiro Shimoda > > Sent: Wednesday, November 14, 2018 7:24 AM > > > > > config PHY_RCAR_GEN3_USB2 > > > > > tristate "Renesas R-Car generation 3 USB 2.0 PHY driver" > > > > > depends on ARCH_RENESAS > > > > > - depends on EXTCON > > > > > + depends on EXTCON || ARCH_R7S9210 > > > > > > > > Does this mean that you don't want to use EXTCON if ARCH_R7S9210=y? > > > > > > EXTCON is not required for RZ/A2. So, I want to be able to leave EXTCON > > > un-selected (save flash space). > > > > I got it. > > I added the depend on EXTCON, but R-Car Gen3 environment can build > > EXTCON=n. > > However, I realized that build error happens if EXTCON=m. > > So, I think we have to revise this line as following at first: > > > > "depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in" > > like drivers/phy/qualcomm/Kconfig. > > OK. I will change it. > >(should this be a separate patch?) Yes, this should be a separate patch. > > > Without this code, RZ/A2 will not work. > > > > I'd like to clarify this. Does this mean RZ/A2 will not work as host mode? > > Correct. If I remove 'else' code, RZ/A2 host mode does not work. > I just tested again now. > > Host works: > else > /* No otg, so default to host mode */ > writel(0x, usb2_base + USB2_COMMCTRL); > > Host does NOT work: > //else > // /* No otg, so default to host mode */ > // writel(0x, usb2_base + USB2_COMMCTRL); I got it. However, I have a concern how to set the mode to peripheral on RZ/A2 if we applied this code. If someone would like to use the USB as peripheral on his board, this code is not suitable. So, I have an idea to set the default mode by using "dr_mode" property, instead of hardcoded. Since the driver already has such a function, we can reuse rcar_gen3_device_recognition() to set the default value. To achieve that, we need to modify the following though. - Don't enable "is_otg_channel". - Don't call rcar_gen3_enable_vbus_ctrl() to avoid ADPCTRL register because RZ/A2 doesn't have it. - Don't need to call rcar_gen3_set_linectrl to avoid LINECTRL1 register because RZ/A2 doesn't seem to need the setting on host mode. What do you think? > > (In other words, if we use the port as peripheral with the reset value > > 0x8000, does it work?) > > We have not been able to get USB peripheral working on RZ/A2 yet. > For peripheral, RZ/A2 has HS-USB. > After plugging into the PC, HS-USB goes to Suspended state (DVSQ = "0110"). > It should go to Configured state (DVSQ = "0011") I guess we need to modify ./drivers/usb/renesas_usbhs/rza.c for RZ/A2 because RZ/A2's HS-USB has SYSCFG.CNEN, but doesn't have SYSCFG.UPLLE? > According to the RZ/A2 Hardware Manual, COMMCTRL should be 0x8000 when > using HS-USB. > > There are 2 channels of USB on RZ/A2 (host x 2, HS_USB x 2) I got it. So, I guess someone wants to use 1 host and 1 peripheral :) Best regards, Yoshihiro Shimoda > Chris
RE: [PATCH 2/3] phy: renesas: rcar-gen3-usb2: Add support for R7S9210
Hi Chris-san, > From: Chris Brandt, Sent: Wednesday, November 14, 2018 8:18 PM > > Hi Shimoda-san, > > > From: Yoshihiro Shimoda > > Sent: Wednesday, November 14, 2018 5:50 AM > > > config PHY_RCAR_GEN3_USB2 > > > tristate "Renesas R-Car generation 3 USB 2.0 PHY driver" > > > depends on ARCH_RENESAS > > > - depends on EXTCON > > > + depends on EXTCON || ARCH_R7S9210 > > > > Does this mean that you don't want to use EXTCON if ARCH_R7S9210=y? > > EXTCON is not required for RZ/A2. So, I want to be able to leave EXTCON > un-selected (save flash space). I got it. I added the depend on EXTCON, but R-Car Gen3 environment can build EXTCON=n. However, I realized that build error happens if EXTCON=m. So, I think we have to revise this line as following at first: "depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in" like drivers/phy/qualcomm/Kconfig. > > > /* Initialize otg part */ > > > if (channel->is_otg_channel) > > > rcar_gen3_init_otg(channel); > > > + else > > > + /* No otg, so default to host mode */ > > > + writel(0x, usb2_base + USB2_COMMCTRL); > > > > This "else" code will run on R-Car H3 USB port1(host only) for instance. > > I think adding this code is possible, but I'd like to separate patch from > > this adding R7S9210 support. What do you think? > > This code is required for RZ/A2. > The reason is the reset value for COMMCTRL in RZ/A2 is 0x8000 (Peripheral > mode). This value is the same as all R-Car Gen3 hardware. However, host only ports don't seem to use this value... > The reset value in R-Car H3 is 0x (Host mode). No. R-Car H3's reset value is also 0x8000 (Peripheral mode). # Note that R-Car H3 can select the mode by HS-USB / UGCTRL2 register though... > Without this code, RZ/A2 will not work. I'd like to clarify this. Does this mean RZ/A2 will not work as host mode? (In other words, if we use the port as peripheral with the reset value 0x8000, does it work?) Best regards, Yoshihiro Shimoda > > Chris
RE: [PATCH 3/3] dt-bindings: rcar-gen3-phy-usb2: Add r7s9210 support
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, November 14, 2018 8:03 PM
>
> Hi Chris,
>
> On Wed, Nov 7, 2018 at 6:36 PM Chris Brandt wrote:
> > @@ -16,8 +18,8 @@ Required properties:
> > R8A77990 SoC.
> > "renesas,usb2-phy-r8a77995" if the device is a part of an
> > R8A77995 SoC.
> > - "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 or RZ/G2
> > - compatible device.
> > + "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3, RZ/G2
> > or
> > + RZ/A2 compatible device.
>
> Is it a good idea to declare RZ/A2 compatible to R-Car Gen3?
> Usually we don't do that for Renesas IP cores used in different families[*].
> Of course, I know you do have a good relationship with the actual RZ/A2
> hardware designers ;-)
>
> In light of Shimoda-san's comment w.r.t. R-Car H3 USB port1 in the driver
> code, perhaps "renesas,rcar-gen3-usb2-phy" should not be used?
Sorry for lack explanation.
- The default value of COMMCTRL on each port of R-Car Gen3 is the same
(0x8000).
- However, R-Car H3 USB port1 seems to ignore this value because
the port always acts as host. If I changed the register to 0 on R-Car H3
ES3.0,
the port1 can work as host.
So, I meant all "renesas,rcar-gen3-usb2-phy" devices without "is_otg_channel"
can set the COMMCTRL register to 0.
Of course, adding a new RZ/A2 family compatible is OK to me.
Best regards,
Yoshihiro Shimoda
> [*] Sole exceptions I'm aware of are:
> - "renesas,rmobile-iic", in addition to "renesas,rcar-gen2-iic" or
> "renesas,rcar-gen3-iic" on R-Car Gen2/3,
> - "renesas,rcar-gen2-cmt1" and "renesas,rcar-thermal" on R-Mobile APE6.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
RE: [PATCH/RFC] iommu/ipmmu-vmsa: R-Car M3-N/V3H/E3 AVB whitelist prototype
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Monday, November 12, 2018 6:08 PM
>
> Hi Shimoda-san,
>
> On Mon, Nov 12, 2018 at 9:53 AM Yoshihiro Shimoda
> wrote:
> > > From: Geert Uytterhoeven, Sent: Monday, November 12, 2018 5:19 PM
> > > On Mon, Nov 12, 2018 at 8:24 AM Yoshihiro Shimoda
> > > wrote:
> > @@ -770,7 +768,8 @@ static int ipmmu_of_xlate(struct device *dev,
> > struct of_phandle_args *spec)
> > {
> > /* For R-Car Gen3 use a white list to opt-in slave devices */
> > - if (soc_device_match(soc_rcar_gen3) && !ipmmu_slave_whitelist(dev))
> > + if (!soc_device_match(soc_rcar_gen3_blacklist) &&
> > + !ipmmu_slave_whitelist(dev))
> > return -ENODEV;
>
> Ah, this has the side effect of applying ipmmu_slave_whitelist() on R-Car
> Gen2, too, which is probably not what we want?
Oops! You're correct. The current code behavior is:
- Gen2 doesn't use any whitelist.
- Gen3 uses the whitelist.
If we apply this my patch above:
- Gen2 and Gen3 use the whitelist anyway.
This is not our expected, so I think we keep to use the current style.
# Note that my first suggestion [1] also broke the code because
# r8a7795 ES2.0 or older and r8a7796 don't use the whitelist...
#
# [1] https://www.spinics.net/lists/linux-renesas-soc/msg35048.html
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
RE: [PATCH 3/3] dt-bindings: rcar-gen3-phy-usb2: Add r7s9210 support
Hi Chris-san, Thank you for the patch! > From: Chris Brandt, Sent: Thursday, November 8, 2018 2:36 AM > > Document RZ/A2 (R7S9210) SoC bindings. > > Signed-off-by: Chris Brandt > --- > Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt > b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt > index de7b5393c163..b545daf8ccb3 100644 > --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt > +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt > @@ -1,10 +1,12 @@ > * Renesas R-Car generation 3 USB 2.0 PHY > > This file provides information on what the device node for the R-Car > generation > -3 and RZ/G2 USB 2.0 PHY contain. > +3, RZ/G2 and RZ/A2 USB 2.0 PHY contain. > > Required properties: > -- compatible: "renesas,usb2-phy-r8a774a1" if the device is a part of an > R8A774A1 > +- compatible: "renesas,usb2-phy-r7s9210" if the device is a part of an > R7S9210 > + SoC. > + "renesas,usb2-phy-r8a774a1" if the device is a part of an R8A774A1 > SoC. > "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795 > SoC. > @@ -16,8 +18,8 @@ Required properties: > R8A77990 SoC. > "renesas,usb2-phy-r8a77995" if the device is a part of an > R8A77995 SoC. > - "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 or RZ/G2 > - compatible device. > + "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3, RZ/G2 or > + RZ/A2 compatible device. > > When compatible with the generic version, nodes must list the > SoC-specific version corresponding to the platform first > -- > 2.16.1 As I mentioned the PATCH 2/3, we should describe a new property "renesas,uses_usb_x1" as optional properties here. Best regards, Yoshihiro Shimoda
RE: [PATCH 2/3] phy: renesas: rcar-gen3-usb2: Add support for R7S9210
Hi Chris-san,
Thank you for the patch!
> From: Chris Brandt, Sent: Thursday, November 8, 2018 2:36 AM
>
> The RZ/A2 has the same USB2 host controller as R-Car Gen3 with only some
> minor differences.
>
> Signed-off-by: Chris Brandt
> ---
> drivers/phy/renesas/Kconfig | 2 +-
> drivers/phy/renesas/phy-rcar-gen3-usb2.c | 12
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/renesas/Kconfig b/drivers/phy/renesas/Kconfig
> index e340a925bbb1..beebeba31e84 100644
> --- a/drivers/phy/renesas/Kconfig
> +++ b/drivers/phy/renesas/Kconfig
> @@ -19,7 +19,7 @@ config PHY_RCAR_GEN3_PCIE
> config PHY_RCAR_GEN3_USB2
> tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
> depends on ARCH_RENESAS
> - depends on EXTCON
> + depends on EXTCON || ARCH_R7S9210
Does this mean that you don't want to use EXTCON if ARCH_R7S9210=y?
> depends on USB_SUPPORT
> select GENERIC_PHY
> select USB_COMMON
> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> index d0f412c25981..96ac75ba40ea 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -34,6 +34,7 @@
> #define USB2_VBCTRL 0x60c
> #define USB2_LINECTRL1 0x610
> #define USB2_ADPCTRL 0x630
> +#define USB2_PHYCLK_CTRL 0x644
>
> /* INT_ENABLE */
> #define USB2_INT_ENABLE_UCOM_INTEN BIT(3)
> @@ -88,6 +89,7 @@ struct rcar_gen3_chan {
> bool extcon_host;
> bool is_otg_channel;
> bool uses_otg_pins;
> + bool uses_usb_x1;
> };
>
> /*
> @@ -326,6 +328,9 @@ static int rcar_gen3_phy_usb2_init(struct phy *p)
> struct rcar_gen3_chan *channel = phy_get_drvdata(p);
> void __iomem *usb2_base = channel->base;
>
> + if (channel->uses_usb_x1)
> + writel(0x0001, usb2_base + USB2_PHYCLK_CTRL);
> +
> /* Initialize USB2 part */
> writel(USB2_INT_ENABLE_INIT, usb2_base + USB2_INT_ENABLE);
> writel(USB2_SPD_RSM_TIMSET_INIT, usb2_base + USB2_SPD_RSM_TIMSET);
> @@ -334,6 +339,9 @@ static int rcar_gen3_phy_usb2_init(struct phy *p)
> /* Initialize otg part */
> if (channel->is_otg_channel)
> rcar_gen3_init_otg(channel);
> + else
> + /* No otg, so default to host mode */
> + writel(0x, usb2_base + USB2_COMMCTRL);
This "else" code will run on R-Car H3 USB port1(host only) for instance.
I think adding this code is possible, but I'd like to separate patch from
this adding R7S9210 support. What do you think?
> return 0;
> }
> @@ -406,6 +414,7 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void
> *_ch)
> }
>
> static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
> + { .compatible = "renesas,usb2-phy-r7s9210" },
According to the PATCH 3/3, R7S9210 will use "renesas,rcar-gen3-usb2-phy".
So, you can remove this line.
> { .compatible = "renesas,usb2-phy-r8a7795" },
> { .compatible = "renesas,usb2-phy-r8a7796" },
> { .compatible = "renesas,usb2-phy-r8a77965" },
> @@ -471,6 +480,9 @@ static int rcar_gen3_phy_usb2_probe(struct
> platform_device *pdev)
> }
> }
>
> + if (of_property_read_bool(dev->of_node, "renesas,uses_usb_x1"))
> + channel->uses_usb_x1 = true;
> +
I'll reply the PATCH 3/3 though, we have to describe the new property into the
dt-bindings doc.
Best regards,
Yoshihiro Shimoda
> /*
>* devm_phy_create() will call pm_runtime_enable(>dev);
>* And then, phy-core will manage runtime pm for this device.
> --
> 2.16.1
RE: [PATCH/RFC] iommu/ipmmu-vmsa: R-Car M3-N/V3H/E3 AVB whitelist prototype
Hi Geert-san,
Thank you for the comment!
> From: Geert Uytterhoeven, Sent: Monday, November 12, 2018 5:19 PM
>
> Hi Shimoda-san,
>
> On Mon, Nov 12, 2018 at 8:24 AM Yoshihiro Shimoda
> wrote:
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -758,10 +758,10 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> > }
> >
> > static const struct soc_device_attribute soc_rcar_gen3[] = {
> > - { .soc_id = "r8a7795", },
> > - { .soc_id = "r8a7796", },
> > + { .soc_id = "r8a7795", .revision = "ES3.*" },
> > { .soc_id = "r8a77965", },
> > { .soc_id = "r8a77970", },
> > + { .soc_id = "r8a77990", },
> > { .soc_id = "r8a77995", },
> > { /* sentinel */ }
> > };
>
> Given the above, I think the time is ripe to convert this from a whitelist to
> a
> blacklist?
About the SoCs, I think so. (I updated example patch below and it seems better
:) )
However, I would like to keep ipmmu_slave_whitelist to avoid any trouble for
now...
---
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index b98a031..ab24128 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -757,12 +757,10 @@ static bool ipmmu_slave_whitelist(struct device *dev)
return false;
}
-static const struct soc_device_attribute soc_rcar_gen3[] = {
- { .soc_id = "r8a7795", },
- { .soc_id = "r8a7796", },
- { .soc_id = "r8a77965", },
- { .soc_id = "r8a77970", },
- { .soc_id = "r8a77995", },
+static const struct soc_device_attribute soc_rcar_gen3_blacklist[] = {
+ { .soc_id = "r8a7795", .revision = "ES1.*" },
+ { .soc_id = "r8a7795", .revision = "ES2.*" },
+ { .soc_id = "r8a7796", .revision = "ES1.*" },
{ /* sentinel */ }
};
@@ -770,7 +768,8 @@ static int ipmmu_of_xlate(struct device *dev,
struct of_phandle_args *spec)
{
/* For R-Car Gen3 use a white list to opt-in slave devices */
- if (soc_device_match(soc_rcar_gen3) && !ipmmu_slave_whitelist(dev))
+ if (!soc_device_match(soc_rcar_gen3_blacklist) &&
+ !ipmmu_slave_whitelist(dev))
return -ENODEV;
iommu_fwspec_add_ids(dev, spec->args, 1);
---
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
RE: [PATCH/RFC] iommu/ipmmu-vmsa: R-Car M3-N/V3H/E3 AVB whitelist prototype
Hi Magnus-san, Geert-san,
> From: Geert Uytterhoeven, Sent: Sunday, October 28, 2018 10:33 PM
>
> Hi Magnus,
>
> Thanks for your patch!
>
> On Sun, Oct 21, 2018 at 7:56 PM Magnus Damm wrote:
> > From: Magnus Damm
> >
> > For testing purpose enable IPMMU for Ethernet-AVB on R-Car M3-N/V3H/E3.
> >
> > Not for upstream merge.
> >
> > Not-Yet-Signed-off-by: Magnus Damm
> > ---
> >
> > Applies on top of renesas-devel-20181019-v4.19-rc8
> >
> > drivers/iommu/ipmmu-vmsa.c |4
> > 1 file changed, 4 insertions(+)
> >
> > --- 0001/drivers/iommu/ipmmu-vmsa.c
> > +++ work/drivers/iommu/ipmmu-vmsa.c 2018-10-22 02:46:30.139880557 +0900
> > @@ -756,6 +756,10 @@ static int ipmmu_init_platform_device(st
> >
> > static bool ipmmu_slave_whitelist(struct device *dev)
> > {
> > + /* R-Car M3-N/V3H/E3 Ethernet-AVB */
> > + if (!strcmp(dev_name(dev), "e680.ethernet"))
> > + return true;
>
> I'm afraid the whitelisting doesn't work that way: with the above check, it
> will
> be enabled on all R-Car Gen3 SoCs.
I agree with Geert-san.
So, how about adding .revision into the soc_rcar_gen3 like a whitelist of SoCs
first as following?
I believe almost all R-Car Gen3 SoCs can use IPMMU safety, except H3 ES2.0 or
older and M3-W ES1.*.
---
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index b98a031..7a528b8 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -758,10 +758,10 @@ static bool ipmmu_slave_whitelist(struct device *dev)
}
static const struct soc_device_attribute soc_rcar_gen3[] = {
- { .soc_id = "r8a7795", },
- { .soc_id = "r8a7796", },
+ { .soc_id = "r8a7795", .revision = "ES3.*" },
{ .soc_id = "r8a77965", },
{ .soc_id = "r8a77970", },
+ { .soc_id = "r8a77990", },
{ .soc_id = "r8a77995", },
{ /* sentinel */ }
};
Best regards,
Yoshihiro Shimoda
> > +
> > /* By default, do not allow use of IPMMU */
> > return false;
> > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
RE: [PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>
> From: Takeshi Kihara
>
> This patch enables SD card slot connected to SDHI0, micro SD card slot
> connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board using
> the R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: Yoshihiro Shimoda
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
I have a few nit comments below.
> .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 136 ++
> 1 file changed, 136 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> index 611f0265fcc5..bda1765dcdbd 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> + sdhi3_pins: sd3 {
> + groups = "sdhi3_data8", "sdhi3_ctrl";
> + function = "sdhi3";
> + power-source = <1800>;
> + };
> +
> + sdhi3_pins_uhs: sd3_uhs {
> + groups = "sdhi3_data8", "sdhi3_ctrl";
> + function = "sdhi3";
> + power-source = <1800>;
> + };
I assumed that we will add "sdhi3_ds" into these groups when we add support for
HS400 mode.
Best regards,
Yoshihiro Shimoda
RE: [PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>
> From: Takeshi Kihara
>
> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: Yoshihiro Shimoda
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
I guess this patch and the 2/2 patch for ebisu have to be merged into a patch
though.
Best regards,
Yoshihiro Shimoda
RE: [PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add voltage switch operations for SDHI
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:40 AM
>
> From: Takeshi Kihara
>
> This patch supports the {get,set}_io_voltage operations of SDHI.
>
> This operates the IOCTRL30 register on the R8A77990 SoC and makes
> 1.8V/3.3V signal voltage switch possible.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: Yoshihiro Shimoda
> Cc: linux-renesas-soc@vger.kernel.org
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH 1/2] pinctrl: sh-pfc: r8a77990: Add SDHI pins, groups and functions
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:40 AM
>
> From: Takeshi Kihara
>
> This patch adds SDHI{0,1,3} pins, groups and functions to the R8A77990
> SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: Yoshihiro Shimoda
> Cc: linux-renesas-soc@vger.kernel.org
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] mmc: renesas_sdhi: Whitelist R8A77990 SDHI
Hello Marek-san, > From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:40 AM > > Whitelist R8A77990 E3 SoC in the SDHI driver. The SDHI core > present in the SoC is an 8tap variant of the Gen3 SDHI core. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Simon Horman > Cc: Wolfram Sang > Cc: Yoshihiro Shimoda > Cc: Ulf Hansson > Cc: linux-renesas-soc@vger.kernel.org > --- Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:39 AM
>
> From: Takeshi Kihara
>
> This patch adds pin control for SCIF2 on R8A77990 E3 Ebisu.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: Yoshihiro Shimoda
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> index f342dd85b152..611f0265fcc5 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -321,6 +321,11 @@
> function = "pwm5";
> };
>
> + scif2_pins: scif2 {
> + groups = "scif2_data_a";
> + function = "scif2";
> + };
> +
> usb0_pins: usb {
> groups = "usb0_b";
> function = "usb0";
> @@ -352,6 +357,9 @@
> };
>
> {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> status = "okay";
> };
>
> --
> 2.18.0
[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(_uart_driver, >port);
@@ -3112,8 +3113,7 @@ static int sci_remove(struct platform_device *dev)
sysfs_remove_file(>dev.kobj,
_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.kobj,
_attr_rx_fifo_timeout.attr);
}
--
1.9.1
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_MOD 706>, < CPG_MOD
> > 705>;
> > > + clock-names = "usbhs", "usb20_host";
> > > + status = "disabled";
>
> 'status = "disabled"'.
Oops! I overlooked this line...
> > > + resets = < 706>, < 705>;
> > > + power-domains = <
> > 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 2/7] phy: renesas: phy-rcar-gen2: Add support for r8a77470
; +}
> +
> +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(>lock, flags);
> +
> + /* Power on USBHS PHY */
> + if (atomic_read(_reset_ref_cnt) == 0) {
> + value = readl(pll_reg_base);
> + value &= ~USBHS_UGCTRL_PLLRESET;
> + writel(value, pll_reg_base);
How about this register is only accessed by usbphy0 and
usb channel 1 (ehci1/ohci1/hsusb1) nodes enable both usbphy0 and usbphy1?
Of course, usb channel 1 has to enable usbphy0 first.
After that, we don't need these pll_reset_ref_cnt and pll_reg_base.
Best regards,
Yoshihiro Shimoda
> + /* As per the data sheet wait 340 micro sec for power stable */
> + udelay(340);
> + }
> +
> + atomic_inc(_reset_ref_cnt);
> +
> + if (phy->select_value == USBHS_UGCTRL2_USB0SEL_HS_USB_USB20) {
> + value = readw(base + USBHS_LPSTS);
> + value |= USBHS_LPSTS_SUSPM;
> + writew(value, base + USBHS_LPSTS);
> + }
> +
> + spin_unlock_irqrestore(>lock, flags);
> +
> + return 0;
> +}
> +
> +static int rz_g1c_phy_power_off(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(>lock, flags);
> + /* Power off USBHS PHY */
> + if (phy->select_value == USBHS_UGCTRL2_USB0SEL_HS_USB_USB20) {
> + value = readw(base + USBHS_LPSTS);
> + value &= ~USBHS_LPSTS_SUSPM;
> + writew(value, base + USBHS_LPSTS);
> + }
> +
> + if (atomic_dec_and_test(_reset_ref_cnt)) {
> + value = readl(pll_reg_base);
> + value |= USBHS_UGCTRL_PLLRESET;
> + writel(value, pll_reg_base);
> + }
> +
> + spin_unlock_irqrestore(>lock, flags);
> +
> + return 0;
> +}
> +
> static const struct phy_ops rcar_gen2_phy_ops = {
> .init = rcar_gen2_phy_init,
> .exit = rcar_gen2_phy_exit,
> @@ -188,6 +321,14 @@ static const struct phy_ops rcar_gen2_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static const struct phy_ops rz_g1c_phy_ops = {
> + .init = rz_g1c_phy_init,
> + .exit = rz_g1c_phy_exit,
> + .power_on = rz_g1c_phy_power_on,
> + .power_off = rz_g1c_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> static const struct of_device_id rcar_gen2_phy_match_table[] = {
> { .compatible = "renesas,usb-phy-r8a7790" },
> { .compatible = "renesas,usb-phy-r8a7791" },
> @@ -224,11 +365,22 @@ static const u32 select_mask[] = {
> [2] = USBHS_UGCTRL2_USB2SEL,
> };
>
> -static const u32 select_value[][PHYS_PER_CHANNEL] = {
> +static const u32 pci_select_value[][PHYS_PER_CHANNEL] = {
> [0] = { USBHS_UGCTRL2_USB0SEL_PCI, USBHS_UGCTRL2_USB0SEL_HS_USB },
> [2] = { USBHS_UGCTRL2_USB2SEL_PCI, USBHS_UGCTRL2_USB2SEL_USB30 },
> };
>
> +static const u32 usb20_select_value[][PHYS_PER_CHANNEL] = {
> + { USBHS_UGCTRL2_USB0SEL_USB20, USBHS_UGCTRL2_USB0SEL_HS_USB_USB20 },
> +};
> +
> +static const struct soc_device_attribute soc_r8a77470[] = {
> + {
> + .soc_id = "r8a77470",
> + },
> + { /* sentinel */ }
> +};
> +
> static int rcar_gen2_phy_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -238,6 +390,8 @@ static int rcar_gen2_phy_probe(struct platform_device
> *pdev)
> struct resource *res;
> void __iomem *base;
> struct clk *clk;
> + const struct phy_ops *gen2_phy_ops = _gen2_phy_ops;
> + const u32 (*select_value)[PHYS_PER_CHANNEL] = pci_select_value;
> int i = 0;
>
> if (!dev->of_node) {
> @@ -266,6 +420,32 @@ static int rcar_gen2_phy_probe(struct platform_device
> *pdev)
> drv->clk = clk;
> drv->base = base;
>
> + if (soc_device_match(soc_r8a77470)) {
> + clk = devm_clk_get(dev, "usb20_host");
> + if (IS_ERR(clk)) {
> + dev_err(dev, "Can't get USB2.0 Host clock\n");
> + return PTR_ERR(clk);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +
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_MOD 706>, < CPG_MOD 705>;
> + clock-names = "usbhs", "usb20_host";
> + status = "disabled";
> + resets = < 706>, < 705>;
> + power-domains = < 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 v2] arm64: dts: renesas: add/enable USB2.0 peripheral for R-Car [DE]3
Hi Simon-san again, > From: Yoshihiro Shimoda, Sent: Wednesday, October 24, 2018 10:05 AM > > Hi Simon-san, > > > From: Simon Horman, Sent: Wednesday, October 17, 2018 5:54 PM > > > > On Tue, Oct 16, 2018 at 03:05:09PM +0900, Yoshihiro Shimoda wrote: > > > This patch adds/enables USB2.0 peripheral for R-Car [DE]3 boards. > > > So, the default mode on each board is: > > > - R-Car D3 Draak board (has a type-A connector) = host. > > > - R-Car E3 Ebisu board (has a type-B micro connector) = peripheral. > > > > > > Signed-off-by: Yoshihiro Shimoda > > > > Thanks Shimoda-san, > > > > This looks fine to me but I will wait to see if there are other reviews > > before applying. > > > > Reviewed-by: Simon Horman > > Thank you for your review! > However, I'm afraid but, would you wait to apply this patch for a moment? > I realized this board also connects the ID pin to the SoC. So. I'd like to > try to use > the pin like other R-Car Gen3 boards. The R-Car E3 Ebisu board can use the ID pin. # Main problem is my using usb connector converter for R-Car E3 doesn't connect the ID pin to the GND. # If I used other usb connector converter, it worked correctly... So, I submitted v3 patch like below: https://patchwork.kernel.org/patch/10654395/ Best regards, Yoshihiro Shimoda
[PATCH v3] arm64: dts: renesas: add/enable USB2.0 peripheral for R-Car [DE]3
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.
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21 +++-
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 45 ++
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 8 +
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 45 ++
4 files changed, 118 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index f342dd8..2538051 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -128,6 +128,17 @@
regulator-always-on;
};
+ vbus0_usb2: regulator-vbus0-usb2 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB20_VBUS_CN";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+
+ gpio = < 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
x13_clk: x13 {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -188,6 +199,7 @@
};
{
+ dr_mode = "otg";
status = "okay";
};
@@ -195,6 +207,11 @@
clock-frequency = <4800>;
};
+ {
+ dr_mode = "otg";
+ status = "okay";
+};
+
{
status = "okay";
@@ -295,6 +312,7 @@
};
{
+ dr_mode = "otg";
status = "okay";
};
@@ -322,7 +340,7 @@
};
usb0_pins: usb {
- groups = "usb0_b";
+ groups = "usb0_b", "usb0_id";
function = "usb0";
};
@@ -359,6 +377,7 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
+ vbus-supply = <_usb2>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 6d5efeb..4bafc38 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -357,6 +357,51 @@
resets = < 407>;
};
+ hsusb: usb@e659 {
+ compatible = "renesas,usbhs-r8a77990",
+"renesas,rcar-gen3-usbhs";
+ reg = <0 0xe659 0 0x200>;
+ interrupts = ;
+ clocks = < CPG_MOD 704>, < CPG_MOD 703>;
+ dmas = <_dmac0 0>, <_dmac0 1>,
+ <_dmac1 0>, <_dmac1 1>;
+ dma-names = "ch0", "ch1", "ch2", "ch3";
+ renesas,buswait = <11>;
+ phys = <_phy0>;
+ phy-names = "usb";
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 704>, < 703>;
+ status = "disabled";
+ };
+
+ usb_dmac0: dma-controller@e65a {
+ compatible = "renesas,r8a77990-usb-dmac",
+"renesas,usb-dmac";
+ reg = <0 0xe65a 0 0x100>;
+ interrupts = ;
+ interrupt-names = "ch0", "ch1";
+ clocks = < CPG_MOD 330>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 330>;
+ #dma-cells = <1>;
+ dma-channels = <2>;
+ };
+
+ usb_dmac1: dma-controller@e65b {
+ compatible = "renesas,r8a77990-usb-dmac",
+"renesas,usb-dmac";
+ reg = <0 0xe65b 0 0x100>;
+ interrupts = ;
+ interrupt-names = "ch0", "ch1";
+
RE: [PATCH v2] arm64: dts: renesas: add/enable USB2.0 peripheral for R-Car [DE]3
Hi Simon-san, > From: Simon Horman, Sent: Wednesday, October 17, 2018 5:54 PM > > On Tue, Oct 16, 2018 at 03:05:09PM +0900, Yoshihiro Shimoda wrote: > > This patch adds/enables USB2.0 peripheral for R-Car [DE]3 boards. > > So, the default mode on each board is: > > - R-Car D3 Draak board (has a type-A connector) = host. > > - R-Car E3 Ebisu board (has a type-B micro connector) = peripheral. > > > > Signed-off-by: Yoshihiro Shimoda > > Thanks Shimoda-san, > > This looks fine to me but I will wait to see if there are other reviews > before applying. > > Reviewed-by: Simon Horman Thank you for your review! However, I'm afraid but, would you wait to apply this patch for a moment? I realized this board also connects the ID pin to the SoC. So. I'd like to try to use the pin like other R-Car Gen3 boards. Best regards, Yoshihiro Shimoda
[PATCH] arm64: dts: renesas: salvator-common: add companion property in usb3_peri0
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
---
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 = <_phy0>;
phy-names = "usb";
+ companion = <>;
+
status = "okay";
};
--
1.9.1
[PATCH] arm64: dts: renesas: r8a77990: add/enable USB3.0 peripheral device node
This patch adds/enables USB3.0 peripheral device node for r8a77990
ebisu board.
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 5 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 11 +++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index f85655d..0ba8e33 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -370,6 +370,11 @@
status = "okay";
};
+_peri0 {
+ companion = <>;
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 4bafc38..e2d9601 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -860,6 +860,17 @@
status = "disabled";
};
+ usb3_peri0: usb@ee02 {
+ compatible = "renesas,r8a77990-usb3-peri",
+"renesas,rcar-gen3-usb3-peri";
+ reg = <0 0xee02 0 0x400>;
+ interrupts = ;
+ clocks = < CPG_MOD 328>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 328>;
+ status = "disabled";
+ };
+
ohci0: usb@ee08 {
compatible = "generic-ohci";
reg = <0 0xee08 0 0x100>;
--
1.9.1
RE: [PATCH] arm64: dts: renesas: revise hsusb's reg size
Hi Simon-san, Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, October 17, 2018 6:35 PM
>
> Hi Simon,
>
> On Wed, Oct 17, 2018 at 10:57 AM Simon Horman wrote:
> > On Tue, Oct 16, 2018 at 03:04:50PM +0900, Yoshihiro Shimoda wrote:
> > > This patch revises the reg size of each hsusb device node for
> > > r8a7795, r8a7796 and r8a77965.
> > >
> > > Reported-by: Biju Das
> > > Fixes: d2422e108812 ("arm64: dts: r8a7795: Add HSUSB device node")
> > > Fixes: 4725f2b88057 ("arm64: dts: renesas: r8a7795: add hsusb ch3 device
> > > node")
> > > Fixes: b9535853777f ("arm64: dts: r8a7796: Add HSUSB device node")
> > > Fixes: 9e1b00a2ef43 ("arm64: dts: renesas: r8a77965: Add "reg"
> > > properties")
> > > Signed-off-by: Yoshihiro Shimoda
> >
> > Thanks Shimoda-san,
> >
> > This looks fine to me but I will wait to see if there are other reviews
> > before applying.
> >
> > Reviewed-by: Simon Horman
> >
> >
> > Also, could you let me know if this has any run-time effect?
> > If so perhaps it should be treated as a fix for v4.20 rather than
> > a patch for v4.21.
>
> Probably not, as mapping granularity is PAGE_SIZE (> 0x200) anyway.
As Geert-san mentioned, I don't think this patch needs as a fix for v4.20.
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
[PATCH v2] arm64: dts: renesas: add/enable USB2.0 peripheral for R-Car [DE]3
This patch adds/enables USB2.0 peripheral for R-Car [DE]3 boards.
So, the default mode on each board is:
- R-Car D3 Draak board (has a type-A connector) = host.
- R-Car E3 Ebisu board (has a type-B micro connector) = peripheral.
Signed-off-by: Yoshihiro Shimoda
---
Changed from v1:
- Revise the reg size for each hsusb node.
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 45 ++
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 8 +
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 45 ++
4 files changed, 106 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index f342dd8..f85655d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -188,6 +188,7 @@
};
{
+ dr_mode = "peripheral";
status = "okay";
};
@@ -195,6 +196,11 @@
clock-frequency = <4800>;
};
+ {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
{
status = "okay";
@@ -295,6 +301,7 @@
};
{
+ dr_mode = "peripheral";
status = "okay";
};
@@ -359,6 +366,7 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
+ renesas,no-otg-pins;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 6d5efeb..4bafc38 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -357,6 +357,51 @@
resets = < 407>;
};
+ hsusb: usb@e659 {
+ compatible = "renesas,usbhs-r8a77990",
+"renesas,rcar-gen3-usbhs";
+ reg = <0 0xe659 0 0x200>;
+ interrupts = ;
+ clocks = < CPG_MOD 704>, < CPG_MOD 703>;
+ dmas = <_dmac0 0>, <_dmac0 1>,
+ <_dmac1 0>, <_dmac1 1>;
+ dma-names = "ch0", "ch1", "ch2", "ch3";
+ renesas,buswait = <11>;
+ phys = <_phy0>;
+ phy-names = "usb";
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 704>, < 703>;
+ status = "disabled";
+ };
+
+ usb_dmac0: dma-controller@e65a {
+ compatible = "renesas,r8a77990-usb-dmac",
+"renesas,usb-dmac";
+ reg = <0 0xe65a 0 0x100>;
+ interrupts = ;
+ interrupt-names = "ch0", "ch1";
+ clocks = < CPG_MOD 330>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 330>;
+ #dma-cells = <1>;
+ dma-channels = <2>;
+ };
+
+ usb_dmac1: dma-controller@e65b {
+ compatible = "renesas,r8a77990-usb-dmac",
+"renesas,usb-dmac";
+ reg = <0 0xe65b 0 0x100>;
+ interrupts = ;
+ interrupt-names = "ch0", "ch1";
+ clocks = < CPG_MOD 331>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 331>;
+ #dma-cells = <1>;
+ dma-channels = <2>;
+ };
+
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a77990",
"renesas,rcar-dmac";
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 2405eaa..48bb1d7 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -179,6 +179,7 @@
};
{
+ dr_mode = "host";
status = "okay";
};
@@ -186,6 +187,11 @@
clock-frequency = <4800>;
};
+ {
+ dr_mode = "host";
+ status = "okay";
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -337,6 +343,7 @@
};
{
+ dr_mode = "host";
status = "okay";
};
@@ -445,6 +452,7
[PATCH] arm64: dts: renesas: revise hsusb's reg size
This patch revises the reg size of each hsusb device node for
r8a7795, r8a7796 and r8a77965.
Reported-by: Biju Das
Fixes: d2422e108812 ("arm64: dts: r8a7795: Add HSUSB device node")
Fixes: 4725f2b88057 ("arm64: dts: renesas: r8a7795: add hsusb ch3 device node")
Fixes: b9535853777f ("arm64: dts: r8a7796: Add HSUSB device node")
Fixes: 9e1b00a2ef43 ("arm64: dts: renesas: r8a77965: Add "reg" properties")
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 5f6020e..0b54c53 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -695,7 +695,7 @@
hsusb: usb@e659 {
compatible = "renesas,usbhs-r8a7795",
"renesas,rcar-gen3-usbhs";
- reg = <0 0xe659 0 0x100>;
+ reg = <0 0xe659 0 0x200>;
interrupts = ;
clocks = < CPG_MOD 704>, < CPG_MOD 703>;
dmas = <_dmac0 0>, <_dmac0 1>,
@@ -712,7 +712,7 @@
hsusb3: usb@e659c000 {
compatible = "renesas,usbhs-r8a7795",
"renesas,rcar-gen3-usbhs";
- reg = <0 0xe659c000 0 0x100>;
+ reg = <0 0xe659c000 0 0x200>;
interrupts = ;
clocks = < CPG_MOD 705>, < CPG_MOD 700>;
dmas = <_dmac2 0>, <_dmac2 1>,
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 1ec6aaa..3baee26 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -674,7 +674,7 @@
hsusb: usb@e659 {
compatible = "renesas,usbhs-r8a7796",
"renesas,rcar-gen3-usbhs";
- reg = <0 0xe659 0 0x100>;
+ reg = <0 0xe659 0 0x200>;
interrupts = ;
clocks = < CPG_MOD 704>, < CPG_MOD 703>;
dmas = <_dmac0 0>, <_dmac0 1>,
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 83946ca..f12be5b 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -590,7 +590,7 @@
hsusb: usb@e659 {
compatible = "renesas,usbhs-r8a77965",
"renesas,rcar-gen3-usbhs";
- reg = <0 0xe659 0 0x100>;
+ reg = <0 0xe659 0 0x200>;
interrupts = ;
clocks = < CPG_MOD 704>, < CPG_MOD 703>;
dmas = <_dmac0 0>, <_dmac0 1>,
--
1.9.1
RE: USB2.0 blocks on RZ/G1C
Hello Biju-san, Thank you for the email. > From: Biju Das, Sent: Monday, October 15, 2018 11:55 PM > > Hello Shimoda-San and all, > > RZ/G1C USB2.0 host/function controller has the below features compared to > R-Car Gen2/Gen3 USB2.0 block > > 1) It has a shared pll reset register for hsusb0/hsusb1 and this register > reside in hsusb0 block. > 2) This implies, in order to enable USB1 host/peripheral, we need to enable > hsusb0 block as well. > 3) USB2.0 Host controller block is similar to R-Car Gen3 USB2.0 host > controller but with >few register sets. There is no PLL reset on the host side(USBCTR). I also checked the RZ/G1C datasheet and I understood them. - Each USB host needs to deassert the pll reset only if RZ/G1C. (In other words, other RZ/G1 and R-Car Gen2/3 don't need to deassert the pll reset of hsusb block for host side.) > To address 1 and 3, I have modified the phy-rcar-gen2 with rz/g1c specific > phy_ops . > Also added optional usb2.0 host reg property for initializing interrupt > enable, OVC detection timer and Suspend/resume > timer register . If so, you also have to add optional usb2.0 host clock and enable the clock on the phy-rcar-gen2 driver. > I will send the patch based on the below discussion. > > To address 2, I am seeing 2 solutions > > solution 1) On the SoC dtsi->define USB1 clocks(ehci1/ohci1/hsusb1) and > On the board dts-> enable hsusb0 + usb1 host/peripheral. > > solution 2) On the SoC dtsi->define USB1 clocks(ehci1/ohci1/hsusb1) followed > by hsusb0 clock and > On the board dts-> enable only usb1 host/peripheral. > This will allow us to do pll reset without enabling > hsusb0 on the board dts. I'm afraid but I don't understand these 2 solutions. Where are the USB1 clocks defined? > Do you have any preferences one way or the other? Or a third option? I'm thinking which nodes we will have on RZ/G1C dtsi: - We will have ehci[01]/ohci[01]/hsusb[01]/usbphy[01] nodes. - ehci0/ohci0/hsusb0 nodes have phys property with usbphy0. - ehci1/ohci1/hsusb1 nodes have phys property with both usbphy0 and usbphy1 to achieve the 2) you mentioned above. - usbphy[01] has reg/clocks as both own hsusb and usb host blocks. About the phy driver: - Add the 1) and 3) you mentioned above. Best regards, Yoshihiro Shimoda > Regards, > Biju
RE: [PATCH] arm64: dts: renesas: add/enable USB2.0 peripheral for R-Car [DE]3
Hi Biju-san,
> From: Biju Das, Sent: Friday, October 12, 2018 5:32 PM
>
> Hi Shimoda-San,
>
> Thanks for the patch.
>
> > -Original Message-
> > From: linux-renesas-soc-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Yoshihiro Shimoda
> > Sent: 09 October 2018 11:45
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > index 7278cd5..e3726307 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > @@ -357,6 +357,51 @@
> > resets = < 407>;
> > };
> >
> > + hsusb: usb@e659 {
> > + compatible = "renesas,usbhs-r8a77990",
> > +"renesas,rcar-gen3-usbhs";
> > + reg = <0 0xe659 0 0x100>;
>
> is it not 0x200?
>
> Renesas_usbhs driver("drivers/usb/renesas_usbhs/common.c ") maps the address
> up to 0x100 using "devm_ioremap_resource"
> function
>
> where as the "drivers/usb/renesas_usbhs/rcar3" access addresses beyond
> 0x100 (for eg:- 0x102,0x180,0x184,0x188) using
> iowrite32/16 calls.
>
> This issue is present in other R-Car Gen3 variant as well(for eg:- R-Car
> H3/M3-W,. etc).
Thank you very much for your report!
You're collect. So, I'll submit a patch to resolve it for all R-Car Gen3 SoCs.
Best regards,
Yoshihiro Shimoda
[PATCH] arm64: dts: renesas: add/enable USB2.0 peripheral for R-Car [DE]3
This patch adds/enables USB2.0 peripheral for R-Car [DE]3 boards.
So, the default mode on each board is:
- R-Car D3 Draak board (has a type-A connector) = host.
- R-Car E3 Ebisu board (has a type-B micro connector) = peripheral.
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 45 ++
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 8 +
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 45 ++
4 files changed, 106 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index f342dd8..f85655d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -188,6 +188,7 @@
};
{
+ dr_mode = "peripheral";
status = "okay";
};
@@ -195,6 +196,11 @@
clock-frequency = <4800>;
};
+ {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
{
status = "okay";
@@ -295,6 +301,7 @@
};
{
+ dr_mode = "peripheral";
status = "okay";
};
@@ -359,6 +366,7 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
+ renesas,no-otg-pins;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 7278cd5..e3726307 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -357,6 +357,51 @@
resets = < 407>;
};
+ hsusb: usb@e659 {
+ compatible = "renesas,usbhs-r8a77990",
+"renesas,rcar-gen3-usbhs";
+ reg = <0 0xe659 0 0x100>;
+ interrupts = ;
+ clocks = < CPG_MOD 704>, < CPG_MOD 703>;
+ dmas = <_dmac0 0>, <_dmac0 1>,
+ <_dmac1 0>, <_dmac1 1>;
+ dma-names = "ch0", "ch1", "ch2", "ch3";
+ renesas,buswait = <11>;
+ phys = <_phy0>;
+ phy-names = "usb";
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 704>, < 703>;
+ status = "disabled";
+ };
+
+ usb_dmac0: dma-controller@e65a {
+ compatible = "renesas,r8a77990-usb-dmac",
+"renesas,usb-dmac";
+ reg = <0 0xe65a 0 0x100>;
+ interrupts = ;
+ interrupt-names = "ch0", "ch1";
+ clocks = < CPG_MOD 330>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 330>;
+ #dma-cells = <1>;
+ dma-channels = <2>;
+ };
+
+ usb_dmac1: dma-controller@e65b {
+ compatible = "renesas,r8a77990-usb-dmac",
+"renesas,usb-dmac";
+ reg = <0 0xe65b 0 0x100>;
+ interrupts = ;
+ interrupt-names = "ch0", "ch1";
+ clocks = < CPG_MOD 331>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 331>;
+ #dma-cells = <1>;
+ dma-channels = <2>;
+ };
+
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a77990",
"renesas,rcar-dmac";
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 2405eaa..48bb1d7 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -179,6 +179,7 @@
};
{
+ dr_mode = "host";
status = "okay";
};
@@ -186,6 +187,11 @@
clock-frequency = <4800>;
};
+ {
+ dr_mode = "host";
+ status = "okay";
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -337,6 +343,7 @@
};
{
+ dr_mode = "host";
status = "okay";
};
@@ -445,6 +452,7 @@
pinctrl-0 = <
[PATCH 0/8] phy: renesas: rcar-gen3-usb2: re-design for all R-Car Gen3 SoCs
This patch set is based on the linux-phy / next branch (the commit id is 53706a1168631fa5bf2e6d47de4647ea7e69f270). Since all R-Car Gen3 SoCs have dedicated otg pins in fact, the previous code was not good to handle it. So, this patch set changes the design for all R-Car Gen3 SoCs. Yoshihiro Shimoda (8): dt-bindings: rcar-gen3-phy-usb2: add no-otg-pins property phy: renesas: rcar-gen3-usb2: fix vbus_ctrl for role sysfs phy: renesas: rcar-gen3-usb2: Rename has_otg_pins to uses_otg_pins phy: renesas: rcar-gen3-usb2: Check a property to use otg pins phy: renesas: rcar-gen3-usb2: unify OBINTEN handling phy: renesas: rcar-gen3-usb2: change a condition "dr_mode" phy: renesas: rcar-gen3-usb2: add conditions for uses_otg_pins == false phy: renesas: rcar-gen3-usb2: add is_otg_channel to use "role" sysfs .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 + drivers/phy/renesas/phy-rcar-gen3-usb2.c | 80 +- 2 files changed, 48 insertions(+), 34 deletions(-) -- 1.9.1
[PATCH 6/8] phy: renesas: rcar-gen3-usb2: change a condition "dr_mode"
This patch changes a condition about dr_mode. If a device node has
any dr_mode ("host", "peripheral" or "otg"), this driver allows to
set "is_otg_channel" to true. Also, this patch keeps the dr_mode
value for future use.
Signed-off-by: Yoshihiro Shimoda
---
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index e7eaed9..93ab860 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -84,6 +84,7 @@ struct rcar_gen3_chan {
struct phy *phy;
struct regulator *vbus;
struct work_struct work;
+ enum usb_dr_mode dr_mode;
bool extcon_host;
bool uses_otg_pins;
};
@@ -436,7 +437,8 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device
*pdev)
dev_err(dev, "No irq handler (%d)\n", irq);
}
- if (of_usb_get_dr_mode_by_phy(dev->of_node, 0) == USB_DR_MODE_OTG) {
+ channel->dr_mode = of_usb_get_dr_mode_by_phy(dev->of_node, 0);
+ if (channel->dr_mode != USB_DR_MODE_UNKNOWN) {
int ret;
channel->uses_otg_pins = !of_property_read_bool(dev->of_node,
--
1.9.1
[PATCH 8/8] phy: renesas: rcar-gen3-usb2: add is_otg_channel to use "role" sysfs
Even if a board doesn't have otg pins connection, this hardware can
change the role by a register setting. So, this patch adds
"is_otg_channel" for it.
Signed-off-by: Yoshihiro Shimoda
---
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 3f2efe5..9903aef 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -86,8 +86,19 @@ struct rcar_gen3_chan {
struct work_struct work;
enum usb_dr_mode dr_mode;
bool extcon_host;
+ bool is_otg_channel;
bool uses_otg_pins;
};
+/*
+ * Combination about is_otg_channel and uses_otg_pins:
+ *
+ * Parameters || Behaviors
+ * is_otg_channel | uses_otg_pins || irqs | role sysfs
+ * -+---++--+
+ * true| true || enabled | enabled
+ * true | false|| disabled | enabled
+ * false| any || disabled | disabled
+ */
static void rcar_gen3_phy_usb2_work(struct work_struct *work)
{
@@ -244,7 +255,7 @@ static ssize_t role_store(struct device *dev, struct
device_attribute *attr,
bool is_b_device;
enum phy_mode cur_mode, new_mode;
- if (!ch->uses_otg_pins || !ch->phy->init_count)
+ if (!ch->is_otg_channel || !ch->phy->init_count)
return -EIO;
if (!strncmp(buf, "host", strlen("host")))
@@ -282,7 +293,7 @@ static ssize_t role_show(struct device *dev, struct
device_attribute *attr,
{
struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
- if (!ch->uses_otg_pins || !ch->phy->init_count)
+ if (!ch->is_otg_channel || !ch->phy->init_count)
return -EIO;
return sprintf(buf, "%s\n", rcar_gen3_is_host(ch) ? "host" :
@@ -320,7 +331,7 @@ static int rcar_gen3_phy_usb2_init(struct phy *p)
writel(USB2_OC_TIMSET_INIT, usb2_base + USB2_OC_TIMSET);
/* Initialize otg part */
- if (channel->uses_otg_pins)
+ if (channel->is_otg_channel)
rcar_gen3_init_otg(channel);
return 0;
@@ -444,6 +455,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device
*pdev)
if (channel->dr_mode != USB_DR_MODE_UNKNOWN) {
int ret;
+ channel->is_otg_channel = true;
channel->uses_otg_pins = !of_property_read_bool(dev->of_node,
"renesas,no-otg-pins");
channel->extcon = devm_extcon_dev_allocate(dev,
@@ -487,7 +499,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device
*pdev)
dev_err(dev, "Failed to register PHY provider\n");
ret = PTR_ERR(provider);
goto error;
- } else if (channel->uses_otg_pins) {
+ } else if (channel->is_otg_channel) {
int ret;
ret = device_create_file(dev, _attr_role);
@@ -507,7 +519,7 @@ static int rcar_gen3_phy_usb2_remove(struct platform_device
*pdev)
{
struct rcar_gen3_chan *channel = platform_get_drvdata(pdev);
- if (channel->uses_otg_pins)
+ if (channel->is_otg_channel)
device_remove_file(>dev, _attr_role);
pm_runtime_disable(>dev);
--
1.9.1
[PATCH 7/8] phy: renesas: rcar-gen3-usb2: add conditions for uses_otg_pins == false
If uses_otg_pins is set to false, this driver 1) should disable otg
related interruptions, and 2) should not get ID pin signal, to avoid
unexpected behaviors. So, this patch adds conditions for it.
Signed-off-by: Yoshihiro Shimoda
---
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 93ab860..3f2efe5 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -148,7 +148,7 @@ static void rcar_gen3_control_otg_irq(struct rcar_gen3_chan
*ch, int enable)
void __iomem *usb2_base = ch->base;
u32 val = readl(usb2_base + USB2_OBINTEN);
- if (enable)
+ if (ch->uses_otg_pins && enable)
val |= USB2_OBINT_BITS;
else
val &= ~USB2_OBINT_BITS;
@@ -210,6 +210,9 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct
rcar_gen3_chan *ch)
static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
{
+ if (!ch->uses_otg_pins)
+ return (ch->dr_mode == USB_DR_MODE_HOST) ? false : true;
+
return !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
}
--
1.9.1
[PATCH 2/8] phy: renesas: rcar-gen3-usb2: fix vbus_ctrl for role sysfs
This patch fixes and issue that the vbus_ctrl is disabled by
rcar_gen3_init_from_a_peri_to_a_host(), so a usb host cannot
supply the vbus.
Note that this condition will exit when the otg irq happens
even if we don't apply this patch.
Fixes: 9bb86777fb71 ("phy: rcar-gen3-usb2: add sysfs for usb role swap")
Signed-off-by: Yoshihiro Shimoda
---
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 3d57ea1..a6db25c 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -195,7 +195,7 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct
rcar_gen3_chan *ch)
val = readl(usb2_base + USB2_OBINTEN);
writel(val & ~USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
- rcar_gen3_enable_vbus_ctrl(ch, 0);
+ rcar_gen3_enable_vbus_ctrl(ch, 1);
rcar_gen3_init_for_host(ch);
writel(val | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
--
1.9.1
RE: [PATCH] arm64: dts: renesas: revise properties for usb 2.0
Hi Simon-san, > From: Simon Horman, Sent: Friday, September 21, 2018 4:37 PM > > On Thu, Sep 20, 2018 at 05:55:00AM +, Yoshihiro Shimoda wrote: > > Hi Simon-san, > > > > > From: Simon Horman, Sent: Wednesday, September 5, 2018 7:33 PM > > > > > > On Fri, Aug 31, 2018 at 05:20:51PM +0900, Yoshihiro Shimoda wrote: > > > > R-Car Gen3 needs to enable/deassert clocks/resets of both usb 2.0 > > > > host (included phy) and peripheral. Otherwise, other side device > > > > cannot work correctly. So, this patch revises properties of clocks > > > > and resets. After that, each device driver can enable/deassert > > > > clocks/resets by its self. > > > > > > > > Notes: > > > > - To work the renesas_usbhs driver correctly when host side drivers > > > >are disabled and the renesas_usbhs driver doesn't have multiple > > > >clock management, this patch doesn't change the order of the clocks > > > >property in each hsusb node. > > > > - This patch doesn't have any side-effects even if the renesas_usbhs > > > >driver doesn't have reset_control and multiple clock management. > > > > > > > > Signed-off-by: Yoshihiro Shimoda > > > > > > Thanks Shimoda-san, > > > > > > This looks fine to me but I will wait to see if there are other reviews > > > before applying. > > > > > > Reviewed-by: Simon Horman > > > > Thank you for your review! > > However, since clock-names will be not used by renesas_usbhs driver, > > I'll submit v2 patch to remove the properties. > > Thanks, I'll wait for v2. I submitted v2 patch: https://patchwork.kernel.org/patch/10609245/ Best regards, Yoshihiro Shimoda
[PATCH v2] arm64: dts: renesas: revise properties for R-Car Gen3 SoCs' usb 2.0
R-Car Gen3 SoCs need to enable/deassert clocks/resets of both usb 2.0 host (included phy) and peripheral. Otherwise, other side device cannot work correctly. So, this patch revises properties of clocks and resets. After that, each device driver can enable/deassert clocks/resets by its self. Notes: - To work the renesas_usbhs driver correctly when host side drivers are disabled and the renesas_usbhs driver doesn't have multiple clock management, this patch doesn't change the order of the clocks property in each hsusb node. - This patch doesn't have any side-effects even if the renesas_usbhs driver doesn't have reset_control and multiple clock management. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Simon Horman --- This patch is based on the renesas.git / renesas-devel-20180919-v4.19-rc4 tag. This patch is related to the following patches which will be merged into v4.20: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing=0e4aeab775f9e9358c4bc522b87e9f6e2cfe0973 https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing=c29e240484ea17c756455149348e59523f462993 https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing=f181dbb4824130e84f46e5be5b49cf6456f96683 https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing=8e0d368a59bf87efa5ee4daea142527d01447864 https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing=3df0e240caba641e0d70640e3baf34d34c105176 Changes from v1: - Revise the subject and log a little. - Remove clock-names. - Add Simon-san's Reviewed-by. arch/arm64/boot/dts/renesas/r8a7795.dtsi | 32 +++ arch/arm64/boot/dts/renesas/r8a7796.dtsi | 16 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 16 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 12 ++-- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 12 ++-- 5 files changed, 44 insertions(+), 44 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index 83077fd..b5f2273 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -697,7 +697,7 @@ "renesas,rcar-gen3-usbhs"; reg = <0 0xe659 0 0x100>; interrupts = ; - clocks = < CPG_MOD 704>; + clocks = < CPG_MOD 704>, < CPG_MOD 703>; dmas = <_dmac0 0>, <_dmac0 1>, <_dmac1 0>, <_dmac1 1>; dma-names = "ch0", "ch1", "ch2", "ch3"; @@ -705,7 +705,7 @@ phys = <_phy0>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 704>; + resets = < 704>, < 703>; status = "disabled"; }; @@ -714,7 +714,7 @@ "renesas,rcar-gen3-usbhs"; reg = <0 0xe659c000 0 0x100>; interrupts = ; - clocks = < CPG_MOD 705>; + clocks = < CPG_MOD 705>, < CPG_MOD 700>; dmas = <_dmac2 0>, <_dmac2 1>, <_dmac3 0>, <_dmac3 1>; dma-names = "ch0", "ch1", "ch2", "ch3"; @@ -722,7 +722,7 @@ phys = <_phy3>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 705>; + resets = < 705>, < 700>; status = "disabled"; }; @@ -2097,11 +2097,11 @@ compatible = "generic-ohci"; reg = <0 0xee08 0 0x100>; interrupts = ; - clocks = < CPG_MOD 703>; + clocks = < CPG_MOD 703>, < CPG_MOD 704>; phys = <_phy0>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 703>; + resets = < 703>, < 704>; status = "disabled"; }; @@ -2133,11 +2133,11 @@ compatible = "generic-ohci"; reg = <0 0xee0e 0 0x100>; i
RE: [PATCH] arm64: dts: renesas: revise properties for usb 2.0
Hi Simon-san, > From: Simon Horman, Sent: Wednesday, September 5, 2018 7:33 PM > > On Fri, Aug 31, 2018 at 05:20:51PM +0900, Yoshihiro Shimoda wrote: > > R-Car Gen3 needs to enable/deassert clocks/resets of both usb 2.0 > > host (included phy) and peripheral. Otherwise, other side device > > cannot work correctly. So, this patch revises properties of clocks > > and resets. After that, each device driver can enable/deassert > > clocks/resets by its self. > > > > Notes: > > - To work the renesas_usbhs driver correctly when host side drivers > >are disabled and the renesas_usbhs driver doesn't have multiple > >clock management, this patch doesn't change the order of the clocks > >property in each hsusb node. > > - This patch doesn't have any side-effects even if the renesas_usbhs > >driver doesn't have reset_control and multiple clock management. > > > > Signed-off-by: Yoshihiro Shimoda > > Thanks Shimoda-san, > > This looks fine to me but I will wait to see if there are other reviews > before applying. > > Reviewed-by: Simon Horman Thank you for your review! However, since clock-names will be not used by renesas_usbhs driver, I'll submit v2 patch to remove the properties. Best regards, Yoshihiro Shimoda
RE: [PATCH] arm64: dts: renesas: revise properties for usb 2.0
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Thursday, September 6, 2018 7:19 PM
>
> Hi Shimoda-san,
>
> On Thu, Sep 6, 2018 at 12:09 PM Yoshihiro Shimoda
> wrote:
> > > From: Geert Uytterhoeven, Sent: Wednesday, September 5, 2018 9:59 PM
> > > On Fri, Aug 31, 2018 at 10:22 AM Yoshihiro Shimoda
> > > wrote:
> > > > R-Car Gen3 needs to enable/deassert clocks/resets of both usb 2.0
> > > > host (included phy) and peripheral. Otherwise, other side device
> > > > cannot work correctly. So, this patch revises properties of clocks
> > > > and resets. After that, each device driver can enable/deassert
> > > > clocks/resets by its self.
> > > >
> > > > Notes:
> > > > - To work the renesas_usbhs driver correctly when host side drivers
> > > >are disabled and the renesas_usbhs driver doesn't have multiple
> > > >clock management, this patch doesn't change the order of the clocks
> > > >property in each hsusb node.
> > > > - This patch doesn't have any side-effects even if the renesas_usbhs
> > > >driver doesn't have reset_control and multiple clock management.
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda
> > >
> > > Thanks for your patch!
> > >
> > > I'm a bit confused about the HS-USB <-> EHCI/OHCI topology.
> > > Can you please explain?
> > >
> > > Thanks!
> >
> > HS-USB <-> EHCI/OHCI topology on R-Car H3 is:
> >
> > EHCI/OHCI ch0/3 ---+--- PHY (is included on the EHCI/OHCI) --- External
> > pins
> > HS-USB ch0/3---+
> >
> > EHCI ch1/2 --- PHY (is included on the EHCI/OHCI) --- External
> > pins
> > # These channels don't have HS-USB.
>
> Thanks, that's the part is missed, and couldn't find immediately in the
> HW manual.
That's true...
> So HS-USB is the usb device ("gadget") part, and EHCI/OHCI is the
> usb host part?
That's right.
> >
> > And module stops and resets of HS-USB and EHCI/OHCI topology on R-Car H3 is:
> >
> > MSTP/RST703 ---+(OR)---+--- EHCI/OHCI ch0
> > MSTP/RST704 ---+ +--- HS-USB ch0
> >
> > MSTP/RST702 --- EHCI/OHCI ch1
> > MSTP/RST701 --- EHCI/OHCI ch2
> >
> > MSTP/RST700 ---+(OR)---+--- EHCI/OHCI ch3
> > MSTP/RST705 ---+ +--- HS-USB ch3
> >
> > Should I describe these topology on the commit log or somewhere?
>
> Yes, I think that would be helpful.
I got it. I'll submit v2 patch tomorrow or later.
Best regards,
Yoshihiro Shimoda
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
RE: [PATCH] arm64: dts: renesas: revise properties for usb 2.0
Hi Geert-san, > From: Geert Uytterhoeven, Sent: Wednesday, September 5, 2018 9:59 PM > > Hi Shimoda-san, > > On Fri, Aug 31, 2018 at 10:22 AM Yoshihiro Shimoda > wrote: > > R-Car Gen3 needs to enable/deassert clocks/resets of both usb 2.0 > > host (included phy) and peripheral. Otherwise, other side device > > cannot work correctly. So, this patch revises properties of clocks > > and resets. After that, each device driver can enable/deassert > > clocks/resets by its self. > > > > Notes: > > - To work the renesas_usbhs driver correctly when host side drivers > >are disabled and the renesas_usbhs driver doesn't have multiple > >clock management, this patch doesn't change the order of the clocks > >property in each hsusb node. > > - This patch doesn't have any side-effects even if the renesas_usbhs > >driver doesn't have reset_control and multiple clock management. > > > > Signed-off-by: Yoshihiro Shimoda > > Thanks for your patch! > > I'm a bit confused about the HS-USB <-> EHCI/OHCI topology. > Can you please explain? > > Thanks! HS-USB <-> EHCI/OHCI topology on R-Car H3 is: EHCI/OHCI ch0/3 ---+--- PHY (is included on the EHCI/OHCI) --- External pins HS-USB ch0/3---+ EHCI ch1/2 --- PHY (is included on the EHCI/OHCI) --- External pins # These channels don't have HS-USB. And module stops and resets of HS-USB and EHCI/OHCI topology on R-Car H3 is: MSTP/RST703 ---+(OR)---+--- EHCI/OHCI ch0 MSTP/RST704 ---+ +--- HS-USB ch0 MSTP/RST702 --- EHCI/OHCI ch1 MSTP/RST701 --- EHCI/OHCI ch2 MSTP/RST700 ---+(OR)---+--- EHCI/OHCI ch3 MSTP/RST705 ---+ +--- HS-USB ch3 Should I describe these topology on the commit log or somewhere? > > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > > @@ -707,7 +707,8 @@ > > "renesas,rcar-gen3-usbhs"; > > reg = <0 0xe659 0 0x100>; > > interrupts = ; > > - clocks = < CPG_MOD 704>; > > + clocks = < CPG_MOD 704>, < CPG_MOD 703>; > > + clock-names = "hsusb", "ehci/ohci"; > > 703 is EHCI/OHCI0. What about EHCI/OHCI1 and EHCI/OHCI2? EHCI/OHCI1 and EHCI/OHCI2 don't need because they are not related to the HS-USB0. > > dmas = <_dmac0 0>, <_dmac0 1>, > ><_dmac1 0>, <_dmac1 1>; > > dma-names = "ch0", "ch1", "ch2", "ch3"; > > @@ -715,7 +716,7 @@ > > phys = <_phy0>; > > phy-names = "usb"; > > power-domains = < R8A7795_PD_ALWAYS_ON>; > > - resets = < 704>; > > + resets = < 704>, < 703>; > > status = "disabled"; > > }; > > > > @@ -724,7 +725,8 @@ > > "renesas,rcar-gen3-usbhs"; > > reg = <0 0xe659c000 0 0x100>; > > interrupts = ; > > - clocks = < CPG_MOD 705>; > > + clocks = < CPG_MOD 705>, < CPG_MOD 700>; > > + clock-names = "hsusb", "ehci/ohci"; > > So this one is linked to EHCI/OHCI3? Yes. > > dmas = <_dmac2 0>, <_dmac2 1>, > ><_dmac3 0>, <_dmac3 1>; > > dma-names = "ch0", "ch1", "ch2", "ch3"; > > @@ -732,7 +734,7 @@ > > phys = <_phy3>; > > phy-names = "usb"; > > power-domains = < R8A7795_PD_ALWAYS_ON>; > > - resets = < 705>; > > + resets = < 705>, < 700>; > > status = "disabled"; > > }; > > > > @@ -2098,11 +2100,11 @@ > > compatible = "generic-ohci"; > > reg = <0 0xee08 0 0x100>; > > interrupts = ; > > - clocks = < CPG_MOD 703>; > > + clocks = < CPG_MOD 703>, < CPG_MOD 704>; > >
[PATCH v2 3/3] usb: renesas_usbhs: Add multiple clocks management
R-Car Gen3 needs to enable clocks of both host and peripheral.
Since [eo]hci-platform disables the reset(s) when the drivers are
removed, renesas_usbhs driver doesn't work correctly. To fix this
issue, this patch adds multiple clocks management on this
renesas_usbhs driver.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/renesas_usbhs/common.c | 35 +++
drivers/usb/renesas_usbhs/common.h | 3 +++
2 files changed, 38 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 1d355d5..39ed714 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -5,6 +5,7 @@
* Copyright (C) 2011 Renesas Solutions Corp.
* Kuninori Morimoto
*/
+#include
#include
#include
#include
@@ -336,11 +337,26 @@ static void usbhsc_power_ctrl(struct usbhs_priv *priv,
int enable)
{
struct platform_device *pdev = usbhs_priv_to_pdev(priv);
struct device *dev = usbhs_priv_to_dev(priv);
+ int ret;
if (enable) {
/* enable PM */
pm_runtime_get_sync(dev);
+ /* enable clks if exist */
+ if (priv->num_clks) {
+ ret = clk_bulk_prepare(priv->num_clks, priv->clks);
+ if (!ret) {
+ ret = clk_bulk_enable(priv->num_clks,
+ priv->clks);
+ if (ret) {
+ clk_bulk_unprepare(priv->num_clks,
+ priv->clks);
+ return;
+ }
+ }
+ }
+
/* enable platform power */
usbhs_platform_call(priv, power_ctrl, pdev, priv->base, enable);
@@ -353,6 +369,10 @@ static void usbhsc_power_ctrl(struct usbhs_priv *priv, int
enable)
/* disable platform power */
usbhs_platform_call(priv, power_ctrl, pdev, priv->base, enable);
+ /* disable clks if exist */
+ if (priv->num_clks)
+ clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+
/* disable PM */
pm_runtime_put_sync(dev);
}
@@ -620,6 +640,13 @@ static int usbhs_probe(struct platform_device *pdev)
break;
}
+ if (priv->dparam.type == USBHS_TYPE_RCAR_GEN3 ||
+ priv->dparam.type == USBHS_TYPE_RCAR_GEN3_WITH_PLL) {
+ priv->clks[0].id = "hsusb";
+ priv->clks[1].id = "ehci/ohci";
+ priv->num_clks = ARRAY_SIZE(priv->clks);
+ };
+
/* set driver callback functions for platform */
dfunc = >driver_callback;
dfunc->notify_hotplug = usbhsc_drvcllbck_notify_hotplug;
@@ -667,6 +694,12 @@ static int usbhs_probe(struct platform_device *pdev)
if (ret)
goto probe_fail_rst;
+ if (priv->num_clks) {
+ ret = clk_bulk_get(>dev, priv->num_clks, priv->clks);
+ if (ret == -EPROBE_DEFER)
+ goto probe_fail_clks;
+ }
+
/*
* deviece reset here because
* USB device might be used in boot loader.
@@ -720,6 +753,8 @@ static int usbhs_probe(struct platform_device *pdev)
return ret;
probe_end_mod_exit:
+ clk_bulk_put(priv->num_clks, priv->clks);
+probe_fail_clks:
reset_control_assert(priv->rsts);
probe_fail_rst:
usbhs_mod_remove(priv);
diff --git a/drivers/usb/renesas_usbhs/common.h
b/drivers/usb/renesas_usbhs/common.h
index bce7d35..6e7c5f2 100644
--- a/drivers/usb/renesas_usbhs/common.h
+++ b/drivers/usb/renesas_usbhs/common.h
@@ -8,6 +8,7 @@
#ifndef RENESAS_USB_DRIVER_H
#define RENESAS_USB_DRIVER_H
+#include
#include
#include
#include
@@ -279,6 +280,8 @@ struct usbhs_priv {
struct phy *phy;
struct reset_control *rsts;
+ struct clk_bulk_data clks[2];
+ int num_clks;
};
/*
--
1.9.1
[PATCH v2 0/3] usb: renesas_usbhs: add reset_control and multiple clocks management
This patch set is based on Felipe's usb.git / testing/next branch (the commit id is 5b394b2ddf0347bef56e50c69a58773c94343ff3) with the following patch: https://patchwork.kernel.org/patch/10574875/ Changes from v1: - Fix error path on patch 3/3. - Use clk_bulk_disable_unprepare() instead of two functions on patch 3/3. - Use staic array of struct clk_bulk_data instead of a pointer on patch 3/3. Yoshihiro Shimoda (3): usb: renesas_usbhs: Add reset_control dt-bindings: usb: renesas_usbhs: add clock-names property usb: renesas_usbhs: Add multiple clocks management .../devicetree/bindings/usb/renesas_usbhs.txt | 2 + drivers/usb/renesas_usbhs/common.c | 47 ++ drivers/usb/renesas_usbhs/common.h | 5 +++ 3 files changed, 54 insertions(+) -- 1.9.1
[PATCH] arm64: dts: renesas: revise properties for usb 2.0
R-Car Gen3 needs to enable/deassert clocks/resets of both usb 2.0 host (included phy) and peripheral. Otherwise, other side device cannot work correctly. So, this patch revises properties of clocks and resets. After that, each device driver can enable/deassert clocks/resets by its self. Notes: - To work the renesas_usbhs driver correctly when host side drivers are disabled and the renesas_usbhs driver doesn't have multiple clock management, this patch doesn't change the order of the clocks property in each hsusb node. - This patch doesn't have any side-effects even if the renesas_usbhs driver doesn't have reset_control and multiple clock management. Signed-off-by: Yoshihiro Shimoda --- This patch is based on the renesas.git / renesas-devel-20180830-v4.19-rc1 tag. This patch is related to the following patch series: https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=13587 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 34 --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 17 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 17 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 12 +-- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 12 +-- 5 files changed, 48 insertions(+), 44 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index c417d4a..9e9aead 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -707,7 +707,8 @@ "renesas,rcar-gen3-usbhs"; reg = <0 0xe659 0 0x100>; interrupts = ; - clocks = < CPG_MOD 704>; + clocks = < CPG_MOD 704>, < CPG_MOD 703>; + clock-names = "hsusb", "ehci/ohci"; dmas = <_dmac0 0>, <_dmac0 1>, <_dmac1 0>, <_dmac1 1>; dma-names = "ch0", "ch1", "ch2", "ch3"; @@ -715,7 +716,7 @@ phys = <_phy0>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 704>; + resets = < 704>, < 703>; status = "disabled"; }; @@ -724,7 +725,8 @@ "renesas,rcar-gen3-usbhs"; reg = <0 0xe659c000 0 0x100>; interrupts = ; - clocks = < CPG_MOD 705>; + clocks = < CPG_MOD 705>, < CPG_MOD 700>; + clock-names = "hsusb", "ehci/ohci"; dmas = <_dmac2 0>, <_dmac2 1>, <_dmac3 0>, <_dmac3 1>; dma-names = "ch0", "ch1", "ch2", "ch3"; @@ -732,7 +734,7 @@ phys = <_phy3>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 705>; + resets = < 705>, < 700>; status = "disabled"; }; @@ -2098,11 +2100,11 @@ compatible = "generic-ohci"; reg = <0 0xee08 0 0x100>; interrupts = ; - clocks = < CPG_MOD 703>; + clocks = < CPG_MOD 703>, < CPG_MOD 704>; phys = <_phy0>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 703>; + resets = < 703>, < 704>; status = "disabled"; }; @@ -2134,11 +2136,11 @@ compatible = "generic-ohci"; reg = <0 0xee0e 0 0x100>; interrupts = ; - clocks = < CPG_MOD 700>; + clocks = < CPG_MOD 700>, < CPG_MOD 705>; phys = <_phy3>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 700>; + resets = < 700>, < 705>; status = "disabled"; }; @@ -2146,12 +2148,12 @@ compatible = "generic-ehci";
RE: [PATCH] arm64: dts: renesas: r8a77965: Fix clock/reset for usb2_phy1
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, August 28, 2018 11:13 PM
>
> usb2_phy1 accidentally uses the same clock/reset as usb2_phy0.
>
> Fixes: b5857630a829a8d5 ("arm64: dts: renesas: r8a77965: add usb2_phy nodes")
> Signed-off-by: Geert Uytterhoeven
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] arm64: dts: renesas: r8a77965: Fix HS-USB compatible
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, August 28, 2018 10:57 PM
>
> Should be "renesas,usbhs-r8a77965", not "renesas,usbhs-r8a7796".
>
> Fixes: a06e8af801760a98 ("arm64: dts: renesas: r8a77965: add HS-USB node")
> Signed-off-by: Geert Uytterhoeven
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] usb: host: xhci-rcar: Add support for r8a774a1
Hi Biju-san,
Thank you for the patch!
> From: Biju Das, Sent: Friday, August 24, 2018 7:17 PM
>
> This patch adds support for r8a774a1 (RZ/G2M).
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
> ---
> drivers/usb/host/xhci-rcar.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> index f33ffc2..c906b13 100644
> --- a/drivers/usb/host/xhci-rcar.c
> +++ b/drivers/usb/host/xhci-rcar.c
> @@ -72,6 +72,10 @@ MODULE_FIRMWARE(XHCI_RCAR_FIRMWARE_NAME_V3);
>
> static const struct soc_device_attribute rcar_quirks_match[] = {
> {
> + .soc_id = "r8a774a1",
> + .data = (void *)RCAR_XHCI_FIRMWARE_V3,
> + },
> + {
I also don't think you need this patch actually because
you submitted adding a bindings patch for usb-xhci [1]
and it had "renesas,rcar-gen3-xhci" for RZ/G2.
In other words, if a xhci node of RZ/G2 dtsi has "renesas,rcar-gen3-xhci"
compatible,
this can probe the xhci-plat/rcar driver with the firmware V3.
[1]
https://patchwork.kernel.org/patch/10574887/
Best regards,
Yoshihiro Shimoda
> .soc_id = "r8a7795", .revision = "ES1.*",
> .data = (void *)RCAR_XHCI_FIRMWARE_V2,
> },
> --
> 2.7.4
RE: [PATCH] usb: renesas_usbhs: Add a compatible string for r8a774a1
Hi Biju-san,
Thank you for the patch!
> From: Biju Das, Sent: Friday, August 24, 2018 7:09 PM
>
> This patch adds support for r8a774a1 (RZ/G2M).
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
> ---
> drivers/usb/renesas_usbhs/common.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/renesas_usbhs/common.c
> b/drivers/usb/renesas_usbhs/common.c
> index 4310df4..f1a1694 100644
> --- a/drivers/usb/renesas_usbhs/common.c
> +++ b/drivers/usb/renesas_usbhs/common.c
> @@ -458,6 +458,10 @@ static int usbhsc_drvcllbck_notify_hotplug(struct
> platform_device *pdev)
> */
> static const struct of_device_id usbhs_of_match[] = {
> {
> + .compatible = "renesas,usbhs-r8a774a1",
> + .data = (void *)USBHS_TYPE_RCAR_GEN3,
> + },
> + {
I don't think you need this adding entry for r8a774a1 actually because
you also submitted a bindings patch [1] and it had "renesas,rcar-gen3-usbhs"
for RZ/G2.
[1]
https://patchwork.kernel.org/patch/10574875/
Best regards,
Yoshihiro Shimoda
> .compatible = "renesas,usbhs-r8a7790",
> .data = (void *)USBHS_TYPE_RCAR_GEN2,
> },
> --
> 2.7.4
RE: [LTSI-dev] [GIT/RFC PULL LTSI-4.14] Renesas SoCs and Drivers to v4.18-rc6
Hi Simon-san, > From: Simon Horman, Sent: Thursday, July 26, 2018 12:23 AM > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git > backport/v4.14.57/snapshot-to-v4.18-rc6+fixes-flattened Our test team found that the kernel image could not probe the gpio-pca953x driver because the following commit was missing in the branch: commit 8a64e557f399090f5d1917b2f32a065da2b12be1 Author: Sergei Shtylyov Date: Thu Nov 16 23:18:32 2017 +0300 gpio: pca953x: fix vendor prefix for PCA9654 So, would you backport the commit? Best regards, Yoshihiro Shimoda
[PATCH v2] arm64: dts: renesas: r8a77990: Enable PWM for Ebisu board
This patch adds PWM device nodes and enables PWM3 and PWM5 for
R-Car E3 Ebisu board. These devices are used for backlight control.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
---
I have submitted dt-bindings for R-Car E3 (not merged into PWM subsystem yet):
https://patchwork.kernel.org/patch/10548969/
Changes from v1:
- Add a comment about backlight on commit log.
- Add "Reviewed-by: Geert Uytterhoeven". (Thanks!)
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 24 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 70 ++
2 files changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 2bc3a48..31934a3 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -67,6 +67,16 @@
};
};
+ pwm3_pins: pwm3 {
+ groups = "pwm3_b";
+ function = "pwm3";
+ };
+
+ pwm5_pins: pwm5 {
+ groups = "pwm5_a";
+ function = "pwm5";
+ };
+
usb0_pins: usb {
groups = "usb0_b";
function = "usb0";
@@ -78,6 +88,20 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
{
timeout-sec = <60>;
status = "okay";
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 2c8f119..2ee0edf 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -337,6 +337,76 @@
status = "disabled";
};
+ pwm0: pwm@e6e3 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e3 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@e6e31000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e31000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@e6e32000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e32000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@e6e33000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e33000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm4: pwm@e6e34000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e34000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm5: pwm@e6e35000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e35000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm6: pwm@
RE: [PATCH] arm64: dts: renesas: r8a77990: Enable PWM for Ebisu board
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, July 31, 2018 3:39 PM
>
> Hi Shimoda-san,
>
> On Tue, Jul 31, 2018 at 8:14 AM Yoshihiro Shimoda
> wrote:
> > > From: Geert Uytterhoeven, Sent: Tuesday, July 31, 2018 12:34 AM
> > > On Mon, Jul 30, 2018 at 1:55 PM Yoshihiro Shimoda
> > > wrote:
> > > > This patch adds PWM device nodes and enables PWM3 and PWM5 for
> > > > R-Car E3 Ebisu board.
> > >
> > > Thanks for your patch!
> >
> > Thank you for your review!
> >
> > > This is used for blacklight control, right?
> >
> > Yes.
> >
> > > It may be a good idea to mention that in the comments and/or patch
> > > description.
> >
> > I got it. I'll revise the patch description as the following. Is it good?
> >
> > ---
> > This patch adds PWM device nodes and enables PWM3 and PWM5 for
> > R-Car E3 Ebisu board. These devices are used for backlight control.
>
> Sounds good to me. Thanks!
Thank you for your comment! I'll submit v2 patch.
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
RE: [PATCH] arm64: dts: renesas: r8a77990: Enable PWM for Ebisu board
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, July 31, 2018 12:34 AM
>
> Hi Shimoda-san,
>
> On Mon, Jul 30, 2018 at 1:55 PM Yoshihiro Shimoda
> wrote:
> > This patch adds PWM device nodes and enables PWM3 and PWM5 for
> > R-Car E3 Ebisu board.
>
> Thanks for your patch!
Thank you for your review!
> This is used for blacklight control, right?
Yes.
> It may be a good idea to mention that in the comments and/or patch
> description.
I got it. I'll revise the patch description as the following. Is it good?
---
This patch adds PWM device nodes and enables PWM3 and PWM5 for
R-Car E3 Ebisu board. These devices are used for backlight control.
---
Best regards,
Yoshihiro Shimoda
> > Signed-off-by: Yoshihiro Shimoda
>
> Reviewed-by: Geert Uytterhoeven
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
[PATCH] arm64: dts: renesas: r8a77990: Enable PWM for Ebisu board
This patch adds PWM device nodes and enables PWM3 and PWM5 for
R-Car E3 Ebisu board.
Signed-off-by: Yoshihiro Shimoda
---
I have submitted dt-bindings for R-Car E3 (not merged into PWM subsystem yet):
https://patchwork.kernel.org/patch/10548969/
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 24 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 70 ++
2 files changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 2bc3a48..31934a3 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -67,6 +67,16 @@
};
};
+ pwm3_pins: pwm3 {
+ groups = "pwm3_b";
+ function = "pwm3";
+ };
+
+ pwm5_pins: pwm5 {
+ groups = "pwm5_a";
+ function = "pwm5";
+ };
+
usb0_pins: usb {
groups = "usb0_b";
function = "usb0";
@@ -78,6 +88,20 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
{
timeout-sec = <60>;
status = "okay";
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 2c8f119..2ee0edf 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -337,6 +337,76 @@
status = "disabled";
};
+ pwm0: pwm@e6e3 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e3 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@e6e31000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e31000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@e6e32000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e32000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@e6e33000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e33000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm4: pwm@e6e34000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e34000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm5: pwm@e6e35000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e35000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm6: pwm@e6e36000 {
+ compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
+ reg = <0 0xe6e36000 0 0x8>;
+ clocks = < CPG_MOD 523>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a77990",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
[PATCH] pinctrl: sh-pfc: r8a77990: Add PWM pins, groups and functions
From: Takeshi Kihara
This patch adds PWM{0,1,2,3,4,5,6} pins, groups and functions to
the R8A77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Yoshihiro Shimoda
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 211 ++
1 file changed, 211 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index b81c807..5ea63e5 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1507,6 +1507,157 @@ enum {
SCL7_B_MARK, SDA7_B_MARK,
};
+/* - PWM0
*/
+static const unsigned int pwm0_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 22),
+};
+
+static const unsigned int pwm0_a_mux[] = {
+ PWM0_A_MARK,
+};
+
+static const unsigned int pwm0_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 3),
+};
+
+static const unsigned int pwm0_b_mux[] = {
+ PWM0_B_MARK,
+};
+
+/* - PWM1
*/
+static const unsigned int pwm1_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 23),
+};
+
+static const unsigned int pwm1_a_mux[] = {
+ PWM1_A_MARK,
+};
+
+static const unsigned int pwm1_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 4),
+};
+
+static const unsigned int pwm1_b_mux[] = {
+ PWM1_B_MARK,
+};
+
+/* - PWM2
*/
+static const unsigned int pwm2_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 0),
+};
+
+static const unsigned int pwm2_a_mux[] = {
+ PWM2_A_MARK,
+};
+
+static const unsigned int pwm2_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 4),
+};
+
+static const unsigned int pwm2_b_mux[] = {
+ PWM2_B_MARK,
+};
+
+static const unsigned int pwm2_c_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 5),
+};
+
+static const unsigned int pwm2_c_mux[] = {
+ PWM2_C_MARK,
+};
+
+/* - PWM3
*/
+static const unsigned int pwm3_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 1),
+};
+
+static const unsigned int pwm3_a_mux[] = {
+ PWM3_A_MARK,
+};
+
+static const unsigned int pwm3_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 5),
+};
+
+static const unsigned int pwm3_b_mux[] = {
+ PWM3_B_MARK,
+};
+
+static const unsigned int pwm3_c_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 6),
+};
+
+static const unsigned int pwm3_c_mux[] = {
+ PWM3_C_MARK,
+};
+
+/* - PWM4
*/
+static const unsigned int pwm4_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 3),
+};
+
+static const unsigned int pwm4_a_mux[] = {
+ PWM4_A_MARK,
+};
+
+static const unsigned int pwm4_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 7),
+};
+
+static const unsigned int pwm4_b_mux[] = {
+ PWM4_B_MARK,
+};
+
+/* - PWM5
*/
+static const unsigned int pwm5_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 24),
+};
+
+static const unsigned int pwm5_a_mux[] = {
+ PWM5_A_MARK,
+};
+
+static const unsigned int pwm5_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 10),
+};
+
+static const unsigned int pwm5_b_mux[] = {
+ PWM5_B_MARK,
+};
+
+/* - PWM6
*/
+static const unsigned int pwm6_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 25),
+};
+
+static const unsigned int pwm6_a_mux[] = {
+ PWM6_A_MARK,
+};
+
+static const unsigned int pwm6_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 11),
+};
+
+static const unsigned int pwm6_b_mux[] = {
+ PWM6_B_MARK,
+};
+
/* - SCIF0 --
*/
static const unsigned int scif0_data_a_pins[] = {
/* RX, TX */
@@ -1854,6 +2005,22 @@ enum {
SH_PFC_PIN_GROUP(i2c6_b),
SH_PFC_PIN_GROUP(i2c7_a),
SH_PFC_PIN_GROUP(i2c7_b),
+ SH_PFC_PIN_GROUP(pwm0_a),
+ SH_PFC_PIN_GROUP(pwm0_b),
+ SH_PFC_PIN_GROUP(pwm1_a),
+ SH_PFC_PIN_GROUP(pwm1_b),
+ SH_PFC_PIN_GROUP(pwm2_a),
+ SH_PFC_PIN_GROUP(pwm2_b),
+ SH_PFC_PIN_GROUP(pwm2_c),
+ SH_PFC_PIN_GROUP(pwm3_a),
+ SH_PFC_PIN_GROUP(pwm3_b),
+ SH_PFC_PIN_GROUP(pwm3_c),
+ SH_PFC_PIN_GROUP(pwm4_a),
+ SH_PFC_PIN_GROUP(pwm4_b),
+ SH_PFC_PIN_GROUP(pwm5_a),
+ SH_PFC_PIN_GROUP(pwm5_b),
+ SH_PFC_PIN_GROUP(pwm6_a),
+ SH_PFC_PIN_GROUP(pwm6_b),
SH_PFC_PIN_GROUP(scif0_data_a),
SH_PFC_PIN_GROUP(scif0_clk_a),
SH_PFC_PIN_GROUP(scif0_ctrl_a),
@@ -1934,6 +2101,43 @@ enum {
"i2c7_b",
};
+static const char * const pwm0_groups[] = {
+ "pwm0_a",
+ "pwm0_b",
+};
+
+static const char * const pwm
[PATCH] dmaengine: sh: rcar-dmac: Should not stop the DMAC by rcar_dmac_sync_tcr()
rcar_dmac_chan_get_residue() should not stop the DMAC, because
the commit 538603c6026c ("dmaengine: sh: rcar-dmac: avoid to write
CHCR.TE to 1 if TCR is set to 0") had fixed unexpected re-transferring
issue. But it had caused the next issue which might stop the cyclic
mode transferring. Thus, for example R-Car sound might be stopped
suddenly.
According to the commit 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB
instead of TCR for residue"), the purpose of clearing CHCR.DE bit is
flushing buffered data to calculate the exact residue.
Such the "exact" residue had been required by sh-sci driver. sh-sci
driver is calling dmaengine_pause() to stop transferring, and get
"exact" residue. Otherwise, it might receive extra data during
getting residue without pausing.
In rx_timer_fn() of sh-sci driver:
dmaengine_tx_status(); /* For checking roughly */
dmaengine_pause();
dmaengine_tx_status(); /* For getting residue */
dmaengine_terminate_all();
But, unfortunately the rcar-dmac driver didn't support dmaengine_pause()
at that time. So, the sh-sci driver cannot get the "exact" residue
without stopping the transferring, because rcar-dmac is buffering data
inside.
Because of these backgrounds, rcar-dmac had been cleared/set CHCR.DE
bit in rcar_dmac_chan_get_residue() to synchronizing data and getting
"exact" residue.
However, rcar-dmac driver has rcar_dmac_chan_pause() now, and clearing
CHCR.DE bit in rcar_dmac_chan_get_residue() doesn't need anymore.
So, this patch removes the rcar_dmac_sync_tcr().
Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for
residue")
Signed-off-by: Yoshihiro Shimoda
Tested-by: Hiroyuki Yokoyama
---
drivers/dma/sh/rcar-dmac.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index be82d69..48ee35e 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -770,20 +770,6 @@ static void rcar_dmac_clear_chcr_de(struct rcar_dmac_chan
*chan)
rcar_dmac_chcr_de_barrier(chan);
}
-static void rcar_dmac_sync_tcr(struct rcar_dmac_chan *chan)
-{
- u32 chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
-
- if (!(chcr & RCAR_DMACHCR_DE))
- return;
-
- rcar_dmac_clear_chcr_de(chan);
-
- /* back DE if remain data exists */
- if (rcar_dmac_chan_read(chan, RCAR_DMATCR))
- rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
-}
-
static void rcar_dmac_chan_halt(struct rcar_dmac_chan *chan)
{
u32 chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
@@ -1367,9 +1353,6 @@ static unsigned int rcar_dmac_chan_get_residue(struct
rcar_dmac_chan *chan,
residue += chunk->size;
}
- if (desc->direction == DMA_DEV_TO_MEM)
- rcar_dmac_sync_tcr(chan);
-
/* Add the residue for the current chunk. */
residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift;
--
1.9.1
[PATCH] arm64: dts: renesas: r8a77990: Enable USB3.0 host for Ebisu board
This patch adds and USB3.0 host device node and enable it for
R-Car E3 Ebisu board.
Signed-off-by: Yoshihiro Shimoda
---
- The dt-binding for usb-xhci has already been merged into linux-next:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/Documentation/devicetree/bindings/usb/usb-xhci.txt?h=next-20180717=4eb44f69e77141992e305d9e75e021b196071cdd
- However, peripheral side is not yet (because the spec is not the same
with other SoCs a little, so I need to modify the driver). So, I don't
add "usb3_peri0" for now.
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 12
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 11 +++
2 files changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 5e28c1b..2bc3a48 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -71,6 +71,11 @@
groups = "usb0_b";
function = "usb0";
};
+
+ usb30_pins: usb30 {
+ groups = "usb30";
+ function = "usb30";
+ };
};
{
@@ -88,3 +93,10 @@
status = "okay";
};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 28eccd1d..ae89260 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -349,6 +349,17 @@
status = "disabled";
};
+ xhci0: usb@ee00 {
+ compatible = "renesas,xhci-r8a77990",
+"renesas,rcar-gen3-xhci";
+ reg = <0 0xee00 0 0xc00>;
+ interrupts = ;
+ clocks = < CPG_MOD 328>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 328>;
+ status = "disabled";
+ };
+
ohci0: usb@ee08 {
compatible = "generic-ohci";
reg = <0 0xee08 0 0x100>;
--
1.9.1
[PATCH] arm64: dts: renesas: Unify the labels for RWDT
The labels for RWDT device node were named as 2 types now:
- wdt0: r8a7795, r8a7796, r8a77965.
- rwdt: r8a77970, r8a77990, r8a77995.
To be made consistent, this patch unifis the labels as the hardware
name "rwdt".
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi| 2 +-
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
arch/arm64/boot/dts/renesas/ulcb.dtsi| 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e07546f..fb9d08a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -288,7 +288,7 @@
#size-cells = <2>;
ranges;
- wdt0: watchdog@e602 {
+ rwdt: watchdog@e602 {
compatible = "renesas,r8a7795-wdt",
"renesas,rcar-gen3-wdt";
reg = <0 0xe602 0 0x0c>;
clocks = < CPG_MOD 402>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index af81962..cbd35c0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -266,7 +266,7 @@
#size-cells = <2>;
ranges;
- wdt0: watchdog@e602 {
+ rwdt: watchdog@e602 {
compatible = "renesas,r8a7796-wdt",
"renesas,rcar-gen3-wdt";
reg = <0 0xe602 0 0x0c>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index a37749c..59afc55 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -138,7 +138,7 @@
#size-cells = <2>;
ranges;
- wdt0: watchdog@e602 {
+ rwdt: watchdog@e602 {
compatible = "renesas,r8a77965-wdt",
"renesas,rcar-gen3-wdt";
reg = <0 0xe602 0 0x0c>;
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 9687166..7d3d866 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -850,7 +850,7 @@
status = "okay";
};
- {
+ {
timeout-sec = <60>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi
b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index 83c546c..0ead552 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -444,7 +444,7 @@
status = "okay";
};
- {
+ {
timeout-sec = <60>;
status = "okay";
};
--
1.9.1
RE: [PATCH 0/2] dma: sh: rcar-dmac: Add dma_pause operation
Hi Vinod, > From: Vinod, Sent: Wednesday, July 11, 2018 12:22 AM > > On 02-07-18, 18:21, Yoshihiro Shimoda wrote: > > This patch set is based on the lasest slave-dma / next branch. > > > > This issue can be reproduced by the following commands on r8a7795 > > Salvator-XS with the fixed patch [1] and Windows Teraterm :) : > > # stty 921600 > > (Change Teraterm baud rate) > > # cat > rx.txt > > (Send 5MiB file by Teraterm.) > > # cmp rx.txt > > output "differ: byte N, line MMM" > > This fails to apply for me. Please rebase. Also please fix the subsystem > name I'm sorry for the trouble. I submitted v2 patch. Best regards, Yoshihiro Shimoda
[PATCH v2 2/2] dmaengine: sh: rcar-dmac: Add dma_pause operation
This patch adds dma_pause operation. This patch is based on
Muhammad Hamza Farooq's patch.
After this patch applied, an issue that the sh-sci driver with
high baud rate might cause data lost disappeared because the DMAC
is possible to transmit between [1] and [2] below, and then
the residue of [1] is not true:
In rx_timer_fn() of the sh-sci.c:
dmaengine_pause();
...
dmaengine_tx_status(); /* [1] */
...
dmaengine_terminate_all(); /* [2] */
Signed-off-by: Yoshihiro Shimoda
---
drivers/dma/sh/rcar-dmac.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index d3b7388..be82d69 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -834,6 +834,17 @@ static void rcar_dmac_stop_all_chan(struct rcar_dmac *dmac)
}
}
+static int rcar_dmac_chan_pause(struct dma_chan *chan)
+{
+ unsigned long flags;
+ struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+
+ spin_lock_irqsave(>lock, flags);
+ rcar_dmac_clear_chcr_de(rchan);
+ spin_unlock_irqrestore(>lock, flags);
+
+ return 0;
+}
/*
-
* Descriptors preparation
@@ -1864,6 +1875,7 @@ static int rcar_dmac_probe(struct platform_device *pdev)
engine->device_prep_slave_sg= rcar_dmac_prep_slave_sg;
engine->device_prep_dma_cyclic = rcar_dmac_prep_dma_cyclic;
engine->device_config = rcar_dmac_device_config;
+ engine->device_pause= rcar_dmac_chan_pause;
engine->device_terminate_all= rcar_dmac_chan_terminate_all;
engine->device_tx_status= rcar_dmac_tx_status;
engine->device_issue_pending= rcar_dmac_issue_pending;
--
1.9.1
[PATCH v2 1/2] dmaengine: sh: rcar-dmac: add a new function to clear CHCR.DE with barrier
This patch adds a new function rcar_dmac_clear_chcr_de() to simplify
adding pause function later.
Signed-off-by: Yoshihiro Shimoda
---
drivers/dma/sh/rcar-dmac.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 9906a9c..d3b7388 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -759,18 +759,25 @@ static void rcar_dmac_chcr_de_barrier(struct
rcar_dmac_chan *chan)
dev_err(chan->chan.device->dev, "CHCR DE check error\n");
}
-static void rcar_dmac_sync_tcr(struct rcar_dmac_chan *chan)
+static void rcar_dmac_clear_chcr_de(struct rcar_dmac_chan *chan)
{
u32 chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
- if (!(chcr & RCAR_DMACHCR_DE))
- return;
-
/* set DE=0 and flush remaining data */
rcar_dmac_chan_write(chan, RCAR_DMACHCR, (chcr & ~RCAR_DMACHCR_DE));
/* make sure all remaining data was flushed */
rcar_dmac_chcr_de_barrier(chan);
+}
+
+static void rcar_dmac_sync_tcr(struct rcar_dmac_chan *chan)
+{
+ u32 chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
+
+ if (!(chcr & RCAR_DMACHCR_DE))
+ return;
+
+ rcar_dmac_clear_chcr_de(chan);
/* back DE if remain data exists */
if (rcar_dmac_chan_read(chan, RCAR_DMATCR))
--
1.9.1
[PATCH v2 0/2] dmaengine: sh: rcar-dmac: Add dma_pause operation
This patch set is based on the lasest slave-dma / next branch. This issue can be reproduced by the following commands on r8a7795 Salvator-XS with the fixed patch [1] and Windows Teraterm :) : # stty 921600 (Change Teraterm baud rate) # cat > rx.txt (Send 5MiB file by Teraterm.) # cmp rx.txt output "differ: byte N, line MMM" [1] https://patchwork.kernel.org/patch/10500775/ Changes from v1: - Rebase the latest slave-dma / next branch. - Fix the subsystem name in each subject. - Minor fix the commit log in patch 2. Yoshihiro Shimoda (2): dmaengine: sh: rcar-dmac: add a new function to clear CHCR.DE with barrier dmaengine: sh: rcar-dmac: Add dma_pause operation drivers/dma/sh/rcar-dmac.c | 27 +++ 1 file changed, 23 insertions(+), 4 deletions(-) -- 1.9.1
RE: [PATCH v6] usb: gadget: udc: renesas_usb3: Add register of usb role switch
Hi Felipe-san, Would you review this patch? Best regards, Yoshihiro Shimoda > From: Heikki Krogerus, Sent: Monday, June 11, 2018 11:09 PM > > On Thu, May 31, 2018 at 03:11:33PM +0900, Yoshihiro Shimoda wrote: > > This patch adds role switch support for R-Car SoCs into the USB 3.0 > > peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0 > > dual-role device controller which has the USB 3.0 xHCI host and > > Renesas USB 3.0 peripheral. > > > > Unfortunately, the mode change register (DRD_CON) contains > > the USB 3.0 peripheral controller side only. So, this renesas_usb3 > > driver manages the DRD_CON now. However, in peripheral mode, the host > > should stop. Also the host hardware needs to reinitialize its own > > registers when the mode changes from peripheral to host mode. > > Otherwise, the host cannot work correctly (e.g. detect a device > > as high-speed). > > > > To achieve this reinitialization by a driver, this driver also > > registers a role switch driver to manage the DRD_CON and get > > a device pointer of usb 3.0 host from "companion" property of OF. > > Then, when the usb role is changed, renesas_usb3_role_switch_set() > > will attach/release the xhci-plat driver to reinitialize the host > > hardware. > > > > Signed-off-by: Yoshihiro Shimoda > > Reviewed-by: Heikki Krogerus > > > --- > > This patch set is based on Felipe's usb.git / testing/next branch > > (commit id = 47265c067c0d129f3a0e94bc221293a780af9d78). > > > > Changes from v5 (https://patchwork.kernel.org/patch/10426483/): > > - Add a new function "usb3_set_mode_by_role_sw()" instead of reusing > >usb3_set_mode() and add _usb3_set_mode(). > > - Change a coding style of container_of. > > - Revise an error message in renesas_usb3_role_switch_set(). > > - Add "const" for "renesas_usb3_role_switch_desc". > > - Simplify a condition check of usb_of_get_companion_dev(). > > > > Changes from RFC v4 (https://patchwork.kernel.org/patch/10418265/): > > - Use "companion" device tree property simply instead of device_connection > >APIs with OF graph. > > - Merge patch 2 and 3 to one. > > - Revise the commit log (I should had revised this on RFC v4 though). > > > > Changes from RFC v3: > > - Rebase latest usb.git / testing/next branch. > > - Add graph parse into device_connection_find_match(). > > - Use workqueue to call _usb3_set_mode() in patch 3. > >(I realized renesas_usb3_role_switch_set() cannot run on atomic because > > device_attach() might sleep.) > > > > Changes from RFC v2: > > - Add registering usb role switch into drivers/usb/gadget/udc/renesas_usb3 > >because hardware resource (a register) is shared and remove individual > >usb role switch driver/dt-bindings for R-Car. > > - Remove "usb_role_switch_get_by_graph" API because the renesas_usb3 driver > >doesn't need such API now. > > > > Changes from RFC: > > - Remove "device-connection-id" and "usb role switch driver" dt-bingings. > > - Remove drivers/of code. > > - Add a new API for find the connection by using graph on devcon.c and > > roles.c. > > - Use each new API on the rcar usb role switch and renesas_usb3 drivers. > > - Update the dtsi file for r8a7795. > > > > > > drivers/usb/gadget/udc/Kconfig| 1 + > > drivers/usb/gadget/udc/renesas_usb3.c | 84 > > ++- > > 2 files changed, 84 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig > > index b838cae..78823cd 100644 > > --- a/drivers/usb/gadget/udc/Kconfig > > +++ b/drivers/usb/gadget/udc/Kconfig > > @@ -193,6 +193,7 @@ config USB_RENESAS_USB3 > > tristate 'Renesas USB3.0 Peripheral controller' > > depends on ARCH_RENESAS || COMPILE_TEST > > depends on EXTCON && HAS_DMA > > + select USB_ROLE_SWITCH > > help > >Renesas USB3.0 Peripheral controller is a USB peripheral controller > >that supports super, high, and full speed USB 3.0 data transfers. > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c > > b/drivers/usb/gadget/udc/renesas_usb3.c > > index 5caf78b..f44a4b1 100644 > > --- a/drivers/usb/gadget/udc/renesas_usb3.c > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c > > @@ -23,6 +23,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > > > /*
[PATCH] iommu/ipmmu-vmsa: IMUCTRn.TTSEL needs a special usage on R-Car Gen3
The TTSEL bit of IMUCTRn register of R-Car Gen3 needs to be set
unused MMU context number even if uTLBs are disabled
(The MMUEN bit of IMUCTRn register = 0).
Since initial values of IMUCTRn.TTSEL on all IPMMU-domains are 0,
this patch adds a new feature "reserved_context" to reserve IPMMU
context number 0 as the unused MMU context.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 6a0e714..6cbd2bd 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -47,6 +47,7 @@ struct ipmmu_features {
unsigned int number_of_contexts;
bool setup_imbuscr;
bool twobit_imttbcr_sl0;
+ bool reserved_context;
};
struct ipmmu_vmsa_device {
@@ -925,6 +926,7 @@ static void ipmmu_device_reset(struct ipmmu_vmsa_device
*mmu)
.number_of_contexts = 1, /* software only tested with one context */
.setup_imbuscr = true,
.twobit_imttbcr_sl0 = false,
+ .reserved_context = false,
};
static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -933,6 +935,7 @@ static void ipmmu_device_reset(struct ipmmu_vmsa_device
*mmu)
.number_of_contexts = 8,
.setup_imbuscr = false,
.twobit_imttbcr_sl0 = true,
+ .reserved_context = true,
};
static const struct of_device_id ipmmu_of_ids[] = {
@@ -1038,6 +1041,11 @@ static int ipmmu_probe(struct platform_device *pdev)
}
ipmmu_device_reset(mmu);
+
+ if (mmu->features->reserved_context) {
+ dev_info(>dev, "IPMMU context 0 is reserved\n");
+ set_bit(0, mmu->ctx);
+ }
}
/*
--
1.9.1
[PATCH] pinctrl: sh-pfc: r8a77990: Add USB3.0 pins, groups and functions
From: Takeshi Kihara
This patch adds USB30_{PWEN,OVC} and USB3HS0_ID pins, groups and functions
to the R8A77990 SoC.
Signed-off-by: Yoshihiro Shimoda
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index edefcc3..b81c807 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1812,6 +1812,25 @@ enum {
USB0_ID_MARK,
};
+/* - USB30 --
*/
+static const unsigned int usb30_pins[] = {
+ /* PWEN, OVC */
+ RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 9),
+};
+
+static const unsigned int usb30_mux[] = {
+ USB30_PWEN_MARK, USB30_OVC_MARK,
+};
+
+static const unsigned int usb30_id_pins[] = {
+ /* ID */
+ RCAR_GP_PIN(5, 0),
+};
+
+static const unsigned int usb30_id_mux[] = {
+ USB3HS0_ID_MARK,
+};
+
static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_link),
SH_PFC_PIN_GROUP(avb_magic),
@@ -1868,6 +1887,8 @@ enum {
SH_PFC_PIN_GROUP(usb0_a),
SH_PFC_PIN_GROUP(usb0_b),
SH_PFC_PIN_GROUP(usb0_id),
+ SH_PFC_PIN_GROUP(usb30),
+ SH_PFC_PIN_GROUP(usb30_id),
};
static const char * const avb_groups[] = {
@@ -1970,6 +1991,11 @@ enum {
"usb0_id",
};
+static const char * const usb30_groups[] = {
+ "usb30",
+ "usb30_id",
+};
+
static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(avb),
SH_PFC_FUNCTION(i2c1),
@@ -1986,6 +2012,7 @@ enum {
SH_PFC_FUNCTION(scif5),
SH_PFC_FUNCTION(scif_clk),
SH_PFC_FUNCTION(usb0),
+ SH_PFC_FUNCTION(usb30),
};
static const struct pinmux_cfg_reg pinmux_config_regs[] = {
--
1.9.1
[PATCH 0/2] dma: sh: rcar-dmac: Add dma_pause operation
This patch set is based on the lasest slave-dma / next branch. This issue can be reproduced by the following commands on r8a7795 Salvator-XS with the fixed patch [1] and Windows Teraterm :) : # stty 921600 (Change Teraterm baud rate) # cat > rx.txt (Send 5MiB file by Teraterm.) # cmp rx.txt output "differ: byte N, line MMM" [1] https://patchwork.kernel.org/patch/10500775/ Yoshihiro Shimoda (2): dma: sh: rcar-dmac: add a new function to clear CHCR.DE with barrier dma: sh: rcar-dmac: Add dma_pause operation drivers/dma/sh/rcar-dmac.c | 27 +++ 1 file changed, 23 insertions(+), 4 deletions(-) -- 1.9.1
[PATCH 1/2] dma: sh: rcar-dmac: add a new function to clear CHCR.DE with barrier
This patch adds a new function rcar_dmac_clear_chcr_de() to simplify
adding pause function later.
Signed-off-by: Yoshihiro Shimoda
---
drivers/dma/sh/rcar-dmac.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 279c930..afd8c7b 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -762,18 +762,25 @@ static void rcar_dmac_chcr_de_barrier(struct
rcar_dmac_chan *chan)
dev_err(chan->chan.device->dev, "CHCR DE check error\n");
}
-static void rcar_dmac_sync_tcr(struct rcar_dmac_chan *chan)
+static void rcar_dmac_clear_chcr_de(struct rcar_dmac_chan *chan)
{
u32 chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
- if (!(chcr & RCAR_DMACHCR_DE))
- return;
-
/* set DE=0 and flush remaining data */
rcar_dmac_chan_write(chan, RCAR_DMACHCR, (chcr & ~RCAR_DMACHCR_DE));
/* make sure all remaining data was flushed */
rcar_dmac_chcr_de_barrier(chan);
+}
+
+static void rcar_dmac_sync_tcr(struct rcar_dmac_chan *chan)
+{
+ u32 chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
+
+ if (!(chcr & RCAR_DMACHCR_DE))
+ return;
+
+ rcar_dmac_clear_chcr_de(chan);
/* back DE */
rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
--
1.9.1
[PATCH 2/2] dma: sh: rcar-dmac: Add dma_pause operation
This patch adds dma_pause operation. This patch is based on
Muhammad Hamza Farooq's patch.
After this patch applied, an issue that the sh-sci driver with
high baud rate might cause data lost disappeared because the DMAC
is possible to transmit between [1] and [2] below, and then
the residue of [1] is not true:
In rx_timer_fn() of the sh-sci.c:
dmaengine_pause();
...
dmaengine_tx_status(); /* [1] */
...
dmaengine_terminate_all() /* [2] */
Signed-off-by: Yoshihiro Shimoda
---
drivers/dma/sh/rcar-dmac.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index afd8c7b..285967b 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -836,6 +836,17 @@ static void rcar_dmac_stop_all_chan(struct rcar_dmac *dmac)
}
}
+static int rcar_dmac_chan_pause(struct dma_chan *chan)
+{
+ unsigned long flags;
+ struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+
+ spin_lock_irqsave(>lock, flags);
+ rcar_dmac_clear_chcr_de(rchan);
+ spin_unlock_irqrestore(>lock, flags);
+
+ return 0;
+}
/*
-
* Descriptors preparation
@@ -1858,6 +1869,7 @@ static int rcar_dmac_probe(struct platform_device *pdev)
engine->device_prep_slave_sg= rcar_dmac_prep_slave_sg;
engine->device_prep_dma_cyclic = rcar_dmac_prep_dma_cyclic;
engine->device_config = rcar_dmac_device_config;
+ engine->device_pause= rcar_dmac_chan_pause;
engine->device_terminate_all= rcar_dmac_chan_terminate_all;
engine->device_tx_status= rcar_dmac_tx_status;
engine->device_issue_pending= rcar_dmac_issue_pending;
--
1.9.1
[PATCH] dma: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0
This patch fixes an issue that unexpected retransfering happens
if TCR is set to 0 before rcar_dmac_sync_tcr() writes DE bit to
the CHCR register. For example, sh-sci driver can reproduce this
issue like below:
In rx_timer_fn(): /* CHCR DE bit may be set to 1 */
dmaengine_tx_status()
rcar_dmac_tx_status()
rcar_dmac_chan_get_residue()
rcar_dmac_sync_tcr() /* TCR is possible to be set to 0 */
According to the description of commit 73a47bd0da66 ("dmaengine:
rcar-dmac: use TCRB instead of TCR for residue"), "this buffered data
will be transferred if CHCR::DE bit was cleared". So, this patch
doesn't need to check TCRB register.
Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for
residue")
Signed-off-by: Yoshihiro Shimoda
---
This patch is based on the latest slave-dma / fixes branch.
This issue can be reproduced by the following commands on r8a7795
Salvator-XS and Windows Teraterm :) :
# stty 921600
(Change Teraterm baud rate)
# cat > rx.txt
(Send 5MiB file by Teraterm. After a few minutes later, we cannot
input any commands by the serial console.)
drivers/dma/sh/rcar-dmac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 2a2ccd9..8305a1c 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -774,8 +774,9 @@ static void rcar_dmac_sync_tcr(struct rcar_dmac_chan *chan)
/* make sure all remaining data was flushed */
rcar_dmac_chcr_de_barrier(chan);
- /* back DE */
- rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
+ /* back DE if remain data exists */
+ if (rcar_dmac_chan_read(chan, RCAR_DMATCR))
+ rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
}
static void rcar_dmac_chan_halt(struct rcar_dmac_chan *chan)
--
1.9.1
[PATCH v2 2/2] mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in abort
This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE
flag cannot be cleared because tmio_mmc_core sets the host->data
to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma().
So, this patch clears the SDHI_INTERNAL_DMAC_RX_IN_USE in
the renesas_sdhi_internal_dmac_abort_dma() anyway. This doesn't
cause any side effects.
Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
SoCs")
Cc: # v4.17+
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index d676a20..d032bd6 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -139,8 +139,7 @@
renesas_sdhi_internal_dmac_dm_write(host, DM_CM_RST,
RST_RESERVED_BITS | val);
- if (host->data && host->data->flags & MMC_DATA_READ)
- clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
+ clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
renesas_sdhi_internal_dmac_enable_dma(host, true);
}
--
1.9.1
[PATCH v2 0/2] mmc: renesas_sdhi_internal_dmac: fix two issues for error path
This patch set is based on the mmc.git / fixes branch. Changes from v1: - Add Reviewed-by Geert-san. - Add a new goto label for error path. Yoshihiro Shimoda (2): mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in abort drivers/mmc/host/renesas_sdhi_internal_dmac.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) -- 1.9.1
[PATCH v2 1/2] mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch
This patch fixes an issue that lacks the dma_unmap_sg() calling in
the error patch of renesas_sdhi_internal_dmac_start_dma().
Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
SoCs")
Cc: # v4.17+
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index f7f9773..d676a20 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -164,17 +164,14 @@
goto force_pio;
/* This DMAC cannot handle if buffer is not 8-bytes alignment */
- if (!IS_ALIGNED(sg_dma_address(sg), 8)) {
- dma_unmap_sg(>pdev->dev, sg, host->sg_len,
-mmc_get_dma_dir(data));
- goto force_pio;
- }
+ if (!IS_ALIGNED(sg_dma_address(sg), 8))
+ goto force_pio_with_unmap;
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
_flags))
- goto force_pio;
+ goto force_pio_with_unmap;
} else {
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
}
@@ -189,6 +186,9 @@
return;
+force_pio_with_unmap:
+ dma_unmap_sg(>pdev->dev, sg, host->sg_len, mmc_get_dma_dir(data));
+
force_pio:
host->force_pio = true;
renesas_sdhi_internal_dmac_enable_dma(host, false);
--
1.9.1
RE: [PATCH 1/2] mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Thursday, June 28, 2018 9:50 PM
>
> Hi Shimoda-san,
>
> On Thu, Jun 28, 2018 at 1:53 PM Yoshihiro Shimoda
> wrote:
> > This patch fixes an issue that lacks the dma_unmap_sg() calling in
> > the error patch of renesas_sdhi_internal_dmac_start_dma().
>
> Nice catch!
> Thanks for your patch!
>
> > Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
> > SoCs")
> > Cc: # v4.17+
> > Signed-off-by: Yoshihiro Shimoda
>
> Reviewed-by: Geert Uytterhoeven
Thank you for your review!
> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > @@ -173,8 +173,11 @@
> > if (data->flags & MMC_DATA_READ) {
> > dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
> > if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags)
> > &&
> > - test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
> > _flags))
> > + test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
> > _flags)) {
> > + dma_unmap_sg(>pdev->dev, sg, host->sg_len,
> > +mmc_get_dma_dir(data));
>
> Given there is already a call to dma_unmap_sg() a few lines earlier , you
> may want to introduce a new label before force_pio, and move the call to
> dma_unmap_sg() there.
Thank you for the comment. So, I'll submit v2 patch.
Best regards,
Yoshihiro Shimoda
[PATCH 1/2] mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch
This patch fixes an issue that lacks the dma_unmap_sg() calling in
the error patch of renesas_sdhi_internal_dmac_start_dma().
Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
SoCs")
Cc: # v4.17+
Signed-off-by: Yoshihiro Shimoda
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index f7f9773..d503511 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -173,8 +173,11 @@
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
- test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
_flags))
+ test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
_flags)) {
+ dma_unmap_sg(>pdev->dev, sg, host->sg_len,
+mmc_get_dma_dir(data));
goto force_pio;
+ }
} else {
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
}
--
1.9.1
[PATCH 2/2] mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in abort
This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE
flag cannot be cleared because tmio_mmc_core sets the host->data
to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma().
So, this patch clears the SDHI_INTERNAL_DMAC_RX_IN_USE in
the renesas_sdhi_internal_dmac_abort_dma() anyway. This doesn't
cause any side effects.
Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
SoCs")
Cc: # v4.17+
Signed-off-by: Yoshihiro Shimoda
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index d503511..3669981 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -139,8 +139,7 @@
renesas_sdhi_internal_dmac_dm_write(host, DM_CM_RST,
RST_RESERVED_BITS | val);
- if (host->data && host->data->flags & MMC_DATA_READ)
- clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
+ clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
renesas_sdhi_internal_dmac_enable_dma(host, true);
}
--
1.9.1
[PATCH 0/2] mmc: renesas_sdhi_internal_dmac: fix two issues for error path
This patch set is based on the mmc.git / fixes branch. Yoshihiro Shimoda (2): mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in abort drivers/mmc/host/renesas_sdhi_internal_dmac.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- 1.9.1
RE: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
Hi Wolfram-san, > From: Wolfram Sang, Sent: Wednesday, June 27, 2018 5:44 PM > > Hi, > > thanks for the discussion on this topic! > > > > The hardware team said: > > > - In CPG point of view: > > >- such polling doesn't need (because the reset pulse is generated > > > correctly). > > >- About the interval after deassert the reset, this is depend on each > > > hardware module. > > > (In other words, if each hardware module has a special handling > > > about after the deassert interval, > > > we should follow the special handling.) > > > - The I2C controller needs an interval of reading SRCR at least (this is > > > a special handling). > > > > > > So, I think adding this code is not good fit in CPG point of view. > > > > Calling reset_control_status() from i2c-rcar is fine for me. > > < snip > > > Where is this special handling documented BTW, I can't find it. Please refer to "57.5.4 Usage note for the transmission and reception procedure" in the datasheet Rev. 1.00. I agree waiting for maximum 1024ms > The BSP waits for maximum 1024ms which seems excessive to me. The BSP waits for maximum 1024us, not 1024ms. Best regards, Yoshihiro Shimoda
RE: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, June 26, 2018 5:58 PM
>
> Hi Shimoda-san,
>
> On Tue, Jun 26, 2018 at 10:38 AM Yoshihiro Shimoda
> wrote:
> > > From: Wolfram Sang , Sent: Tuesday, June 26, 2018
> > > 12:05 PM
> > > > > I got information about this topic.
> > > > >
> > > > > < In CPG / MSSR point of view >
> > > > > - This needs 35 usec wait while asserting.
> > > > > - After deasserted a reset, no wait needs.
> > > > > - In other words, there is each hardware IP dependence.
> > > >
> > > > Let's call the above procedure A.
> > > >
> > > > > < In I2C point of view >
> > > > > - After deasserted the reset, this nees SRCR register polling.
> > > >
> > > > Let's call the above procedure B.
> > > >
> > > > > So, I don't think cpg_mssr_reset() checks the status bit after
> > > > > deasserted a reset.
> > > > > But, what do you think?
> > > >
> > > > cpg_mssr_reset() indeed does not check the status bit after deasserting
> > > > the reset, as it follows procedure A.
> > > >
> > > > Such a check could be added, though. Then it'll become
> > > > (let's call this procedure C):
> > > >
> > > > /* Reset module */
> > > > spin_lock_irqsave(>rmw_lock, flags);
> > > > value = readl(priv->base + SRCR(reg));
> > > > value |= bitmask;
> > > > writel(value, priv->base + SRCR(reg));
> > > > spin_unlock_irqrestore(>rmw_lock, flags);
> > > >
> > > > /* Wait for at least one cycle of the RCLK clock (@ ca. 32 kHz)
> > > > */
> > > > udelay(35);
> > > >
> > > > /* Release module from reset state */
> > > > writel(bitmask, priv->base + SRSTCLR(reg));
> > > >
> > > > + /* Wait until deassertion has completed */
> > > > + while (readl(priv->base + SRCR(reg)) & bitmask)
> > > > + cpu_relax();
> > > >
> > > > Probably we need an upper limit on the number of loops, and call
> > > > udelay(1)
> > > > after each iteration?
> > > >
> > > > for (i 0; i < 35; i++) {
> > > > if (!(readl(priv->base + SRCR(reg)) & bitmask))
> > > > return 0;
> > > > udelay(1);
> > > > }
> > > > return -EIO;
> > > >
> > > > Any advice from the hardware team about that?
> >
> > The hardware team said:
> > - In CPG point of view:
> >- such polling doesn't need (because the reset pulse is generated
> > correctly).
> >- About the interval after deassert the reset, this is depend on each
> > hardware module.
> > (In other words, if each hardware module has a special handling about
> > after the deassert interval,
> > we should follow the special handling.)
> > - The I2C controller needs an interval of reading SRCR at least (this is a
> > special handling).
> >
> > So, I think adding this code is not good fit in CPG point of view.
> >
> > > > But according to procedure A, the check is not needed?
> >
> > As hardware team said, the check (that means procedure C) is not needed.
> >
> > > > Probably because 35µs is an upper limit satisfying all individual
> > > > hardware
> > > > modules?
> > > >
> > > > I'm wondering whether we could use procedure B in the general case,
> > > > as it explicitly checks for completion?
> > > >
> > > > Procedure C is safest, though, so probably the way to go.
> > >
> > > Any news about this topic?
> > >
> > > And how to upstream all this? My I2C patch is clearly a bugfix, but the
> > > necessary CPG update technically isn't? Not sure about this one...
> >
> > I think we have to add reset_control_status() calling into the i2c-rcar.c
> > to follow procedure B.
> > But, Geert-san, what do you think?
>
> Calling reset_control_status() from i2c-rcar is fine for me.
Thank you for your comment!
> Note that reset controller support is optional, so we want to add
>
> select RESET_CONTROLLER if ARCH_RENESAS && ARM64
>
RE: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
Hi Wolfram-san, Geert-san,
I'm sorry for delayed response. I completely overlooked this email...
> From: Wolfram Sang , Sent: Tuesday, June 26, 2018 12:05 PM
>
> > > I got information about this topic.
> > >
> > > < In CPG / MSSR point of view >
> > > - This needs 35 usec wait while asserting.
> > > - After deasserted a reset, no wait needs.
> > > - In other words, there is each hardware IP dependence.
> >
> > Let's call the above procedure A.
> >
> > > < In I2C point of view >
> > > - After deasserted the reset, this nees SRCR register polling.
> >
> > Let's call the above procedure B.
> >
> > > So, I don't think cpg_mssr_reset() checks the status bit after deasserted
> > > a reset.
> > > But, what do you think?
> >
> > cpg_mssr_reset() indeed does not check the status bit after deasserting
> > the reset, as it follows procedure A.
> >
> > Such a check could be added, though. Then it'll become
> > (let's call this procedure C):
> >
> > /* Reset module */
> > spin_lock_irqsave(>rmw_lock, flags);
> > value = readl(priv->base + SRCR(reg));
> > value |= bitmask;
> > writel(value, priv->base + SRCR(reg));
> > spin_unlock_irqrestore(>rmw_lock, flags);
> >
> > /* Wait for at least one cycle of the RCLK clock (@ ca. 32 kHz) */
> > udelay(35);
> >
> > /* Release module from reset state */
> > writel(bitmask, priv->base + SRSTCLR(reg));
> >
> > + /* Wait until deassertion has completed */
> > + while (readl(priv->base + SRCR(reg)) & bitmask)
> > + cpu_relax();
> >
> > Probably we need an upper limit on the number of loops, and call udelay(1)
> > after each iteration?
> >
> > for (i 0; i < 35; i++) {
> > if (!(readl(priv->base + SRCR(reg)) & bitmask))
> > return 0;
> > udelay(1);
> > }
> > return -EIO;
> >
> > Any advice from the hardware team about that?
The hardware team said:
- In CPG point of view:
- such polling doesn't need (because the reset pulse is generated correctly).
- About the interval after deassert the reset, this is depend on each
hardware module.
(In other words, if each hardware module has a special handling about
after the deassert interval,
we should follow the special handling.)
- The I2C controller needs an interval of reading SRCR at least (this is a
special handling).
So, I think adding this code is not good fit in CPG point of view.
> > But according to procedure A, the check is not needed?
As hardware team said, the check (that means procedure C) is not needed.
> > Probably because 35µs is an upper limit satisfying all individual hardware
> > modules?
> >
> > I'm wondering whether we could use procedure B in the general case,
> > as it explicitly checks for completion?
> >
> > Procedure C is safest, though, so probably the way to go.
>
> Any news about this topic?
>
> And how to upstream all this? My I2C patch is clearly a bugfix, but the
> necessary CPG update technically isn't? Not sure about this one...
I think we have to add reset_control_status() calling into the i2c-rcar.c
to follow procedure B.
But, Geert-san, what do you think?
Best regards,
Yoshihiro Shimoda
RE: [PATCH 1/3] arm64: dts: renesas: convert to SPDX identifiers
Hi Wolfram-san, Thank you for the patch! > From: Wolfram Sang, Sent: Monday, June 11, 2018 11:50 PM > > Signed-off-by: Wolfram Sang > --- > arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 5 + > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts| 5 + > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 + > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 5 + > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts| 5 + > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 5 + I tried to apply this patch on renesas-devel-20180608-v4.17 and this r8a7796 cannot be applied because conflict happened. So, I guess you need rebase. After rebased: Acked-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 5 + > arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 5 + > arch/arm64/boot/dts/renesas/r8a77970.dtsi | 5 + > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 5 + > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 5 + > arch/arm64/boot/dts/renesas/salvator-common.dtsi | 5 + > arch/arm64/boot/dts/renesas/salvator-x.dtsi| 5 + > arch/arm64/boot/dts/renesas/salvator-xs.dtsi | 5 + > arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 5 + > arch/arm64/boot/dts/renesas/ulcb.dtsi | 5 + > 24 files changed, 24 insertions(+), 96 deletions(-) > > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts > b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts > index 009cb1cb0dde..2f24dfc45617 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts > +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts > @@ -1,12 +1,9 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Device Tree Source for the H3ULCB Kingfisher board > * > * Copyright (C) 2017 Renesas Electronics Corp. > * Copyright (C) 2017 Cogent Embedded, Inc. > - * > - * This file is licensed under the terms of the GNU General Public License > - * version 2. This program is licensed "as is" without any warranty of any > - * kind, whether express or implied. > */ > > #include "r8a7795-es1-h3ulcb.dts" > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts > b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts > index dd4f9b6a4254..598b98168559 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts > +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts > @@ -1,12 +1,9 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Device Tree Source for the H3ULCB (R-Car Starter Kit Premier) board > * > * Copyright (C) 2016 Renesas Electronics Corp. > * Copyright (C) 2016 Cogent Embedded, Inc. > - * > - * This file is licensed under the terms of the GNU General Public License > - * version 2. This program is licensed "as is" without any warranty of any > - * kind, whether express or implied. > */ > > /dts-v1/; > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts > b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts > index 3f46345a4644..6b5fa91f1d5d 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts > +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts > @@ -1,11 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Device Tree Source for the Salvator-X board with R-Car H3 ES1.x > * > * Copyright (C) 2015 Renesas Electronics Corp. > - * > - * This file is licensed under the terms of the GNU General Public License > - * version 2. This program is licensed "as is" without any warranty of any > - * kind, whether express or implied. > */ > > /dts-v1/; > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > index e19dcd6cb767..fde3e84626d7 100644 > --- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > @@ -1,11 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Device Tree Source for the r8a7795 ES1.x SoC &g
RE: [PATCH 2/3] ARM: dts: convert to SPDX identifier for Renesas boards
Hi Wolfram-san, > From: Wolfram Sang, Sent: Monday, June 11, 2018 11:50 PM > > Signed-off-by: Wolfram Sang > --- This patch looks good. So, Acked-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda > arch/arm/boot/dts/emev2-kzm9d.dts | 5 + > arch/arm/boot/dts/emev2.dtsi| 5 + > arch/arm/boot/dts/iwg20d-q7-common.dtsi | 5 + > arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi| 5 + > arch/arm/boot/dts/r7s72100-genmai.dts | 5 + > arch/arm/boot/dts/r7s72100-gr-peach.dts | 5 + > arch/arm/boot/dts/r7s72100-rskrza1.dts | 5 + > arch/arm/boot/dts/r7s72100.dtsi | 5 + > arch/arm/boot/dts/r8a73a4-ape6evm.dts | 5 + > arch/arm/boot/dts/r8a73a4.dtsi | 5 + > arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 5 + > arch/arm/boot/dts/r8a7740.dtsi | 5 + > arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts | 5 + > arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 5 + > arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 5 + > arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 5 + > arch/arm/boot/dts/r8a7743.dtsi | 5 + > arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 5 + > arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 5 + > arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 5 + > arch/arm/boot/dts/r8a7745-sk-rzg1e.dts | 5 + > arch/arm/boot/dts/r8a7745.dtsi | 5 + > arch/arm/boot/dts/r8a7778-bockw.dts | 5 + > arch/arm/boot/dts/r8a7778.dtsi | 5 + > arch/arm/boot/dts/r8a7779-marzen.dts| 5 + > arch/arm/boot/dts/r8a7779.dtsi | 5 + > arch/arm/boot/dts/r8a7790-lager.dts | 5 + > arch/arm/boot/dts/r8a7790.dtsi | 5 + > arch/arm/boot/dts/r8a7791-koelsch.dts | 5 + > arch/arm/boot/dts/r8a7791-porter.dts| 5 + > arch/arm/boot/dts/r8a7791.dtsi | 5 + > arch/arm/boot/dts/r8a7792-blanche.dts | 5 + > arch/arm/boot/dts/r8a7792-wheat.dts | 5 + > arch/arm/boot/dts/r8a7792.dtsi | 5 + > arch/arm/boot/dts/r8a7793-gose.dts | 5 + > arch/arm/boot/dts/r8a7793.dtsi | 5 + > arch/arm/boot/dts/r8a7794-alt.dts | 5 + > arch/arm/boot/dts/r8a7794-silk.dts | 5 + > arch/arm/boot/dts/r8a7794.dtsi | 5 + > arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi | 5 + > arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi | 5 + > arch/arm/boot/dts/sh73a0-kzm9g.dts | 5 + > arch/arm/boot/dts/sh73a0.dtsi | 5 + > 43 files changed, 43 insertions(+), 172 deletions(-) > > diff --git a/arch/arm/boot/dts/emev2-kzm9d.dts > b/arch/arm/boot/dts/emev2-kzm9d.dts > index 0af44b7eadb9..1bb8e5c9d029 100644 > --- a/arch/arm/boot/dts/emev2-kzm9d.dts > +++ b/arch/arm/boot/dts/emev2-kzm9d.dts > @@ -1,11 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Device Tree Source for the KZM9D board > * > * Copyright (C) 2013 Renesas Solutions Corp. > - * > - * This file is licensed under the terms of the GNU General Public License > - * version 2. This program is licensed "as is" without any warranty of any > - * kind, whether express or implied. > */ > /dts-v1/; > > diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi > index fec1241b858f..373ea8720769 100644 > --- a/arch/arm/boot/dts/emev2.dtsi > +++ b/arch/arm/boot/dts/emev2.dtsi > @@ -1,11 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Device Tree Source for the EMEV2 SoC > * > * Copyright (C) 2012 Renesas Solutions Corp. > - * > - * This file is licensed under the terms of the GNU General Public License > - * version 2. This program is licensed "as is" without any warranty of any > - * kind, whether express or implied. > */ > > #include > diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi > b/arch/arm/boot/dts/iwg20d-q7-common.dtsi > index 66954aaf2c47..5cae74eb6cdd 100644 > --- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi > +++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi > @@ -1,11 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Device Tree Source for the iWave-RZ/G1M/G1N Qseven carrier board > * > * Copyright (C) 2017 Renesas Electronics Corp. > - * > -
RE: [PATCH 3/3] ARM: shmobile: convert to SPDX identifier
Hi Wolfram-san, Thank you for the patch! > From: Wolfram Sang, Sent: Monday, June 11, 2018 11:50 PM > > Signed-off-by: Wolfram Sang > --- > arch/arm/include/debug/renesas-scif.S | 5 + > arch/arm/mach-shmobile/headsmp-apmu.S | 5 + > arch/arm/mach-shmobile/platsmp-apmu.c | 5 + > arch/arm/mach-shmobile/platsmp-apmu.h | 10 +- I tried to apply this patch on renesas-devel-20180608-v4.17 and platsmp-apmu.h and other files were removed. So, I guess you need rebase. After rebased: Acked-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda > arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 10 +- > arch/arm/mach-shmobile/setup-emev2.c | 10 +- > arch/arm/mach-shmobile/setup-r7s72100.c| 10 +- > arch/arm/mach-shmobile/setup-r8a73a4.c | 10 +- > arch/arm/mach-shmobile/setup-r8a7740.c | 10 +- > arch/arm/mach-shmobile/setup-r8a7778.c | 10 +- > arch/arm/mach-shmobile/setup-r8a7779.c | 10 +- > arch/arm/mach-shmobile/setup-r8a7790.c | 10 +- > arch/arm/mach-shmobile/setup-r8a7791.c | 10 +- > arch/arm/mach-shmobile/setup-rcar-gen2.c | 10 +- > arch/arm/mach-shmobile/setup-sh73a0.c | 10 +- > arch/arm/mach-shmobile/smp-emev2.c | 10 +- > arch/arm/mach-shmobile/smp-r8a7779.c | 10 +- > arch/arm/mach-shmobile/smp-r8a7790.c | 10 +- > arch/arm/mach-shmobile/smp-r8a7791.c | 10 +- > 19 files changed, 19 insertions(+), 156 deletions(-) > > diff --git a/arch/arm/include/debug/renesas-scif.S > b/arch/arm/include/debug/renesas-scif.S > index 97820a8df51a..1c5f795587fc 100644 > --- a/arch/arm/include/debug/renesas-scif.S > +++ b/arch/arm/include/debug/renesas-scif.S > @@ -1,3 +1,4 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > /* > * Renesas SCIF(A) debugging macro include header > * > @@ -5,10 +6,6 @@ > * > * Copyright (C) 2012-2013 Renesas Electronics Corporation > * Copyright (C) 1994-1999 Russell King > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > */ > > #define SCIF_PHYSCONFIG_DEBUG_UART_PHYS > diff --git a/arch/arm/mach-shmobile/headsmp-apmu.S > b/arch/arm/mach-shmobile/headsmp-apmu.S > index 5672b5849401..94897f7f294c 100644 > --- a/arch/arm/mach-shmobile/headsmp-apmu.S > +++ b/arch/arm/mach-shmobile/headsmp-apmu.S > @@ -1,11 +1,8 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > /* > * SMP support for APMU based systems with Cortex A7/A15 > * > * Copyright (C) 2014 Renesas Electronics Corporation > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > */ > > #include > diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c > b/arch/arm/mach-shmobile/platsmp-apmu.c > index ba732effc90b..da64f5f56003 100644 > --- a/arch/arm/mach-shmobile/platsmp-apmu.c > +++ b/arch/arm/mach-shmobile/platsmp-apmu.c > @@ -1,12 +1,9 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * SMP support for SoCs with APMU > * > * Copyright (C) 2014 Renesas Electronics Corporation > * Copyright (C) 2013 Magnus Damm > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > */ > #include > #include > diff --git a/arch/arm/mach-shmobile/platsmp-apmu.h > b/arch/arm/mach-shmobile/platsmp-apmu.h > index 76512c9a2545..81169337dea5 100644 > --- a/arch/arm/mach-shmobile/platsmp-apmu.h > +++ b/arch/arm/mach-shmobile/platsmp-apmu.h > @@ -1,16 +1,8 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > /* > * rmobile apmu definition > * > * Copyright (C) 2014 Renesas Electronics Corporation > - * > - * 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. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ > > #
RE: [PATCH v2] arm64: dts: renesas: r8a77990: Enable USB2.0 Host for Ebisu board
Hi Simon-san,
> From: Simon Horman, Sent: Friday, June 8, 2018 5:19 PM
>
> On Wed, Jun 06, 2018 at 06:52:06PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds USB2.0 PHY and Host(EHCI/OHCI) nodes and
> > enables them for R-Car E3 Ebisu board.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > This patch set is based on renesas-drivers.git /
> > renesas-drivers-2018-06-05-v4.17 tag.
> >
> > Changes from v1:
> > - Squash 4 patches into a single patch.
>
> Thanks Shimoda-san, I have applied this for v4.19.
>
> I had to do so manually to resolve a trivial conflict in
> r8a779980-ebisu.dts. The result is below. Please check to make
> sure that I got it right.
Thank you very much for resolving the conflict.
I confirmed the resolved patch works correctly.
Best regards,
Yoshihiro Shimoda
> From: Yoshihiro Shimoda
> Subject: [PATCH] arm64: dts: renesas: r8a77990: Enable USB2.0 Host for Ebisu
> board
>
> This patch adds USB2.0 PHY and Host(EHCI/OHCI) nodes and
> enables them for R-Car E3 Ebisu board.
>
> Signed-off-by: Yoshihiro Shimoda
> Signed-off-by: Simon Horman
> ---
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 20 ++
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 37
> ++
> 2 files changed, 57 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> index 28945a8b9800..5e28c1b94b77 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -47,10 +47,18 @@
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> _clk {
> clock-frequency = <4800>;
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> avb_pins: avb {
> mux {
> @@ -58,6 +66,11 @@
> function = "avb";
> };
> };
> +
> + usb0_pins: usb {
> + groups = "usb0_b";
> + function = "usb0";
> + };
> };
>
> {
> @@ -68,3 +81,10 @@
> {
> status = "okay";
> };
> +
> +_phy0 {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> index 735881d4e57a..f8004608c595 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -267,6 +267,43 @@
> status = "disabled";
> };
>
> + ohci0: usb@ee08 {
> + compatible = "generic-ohci";
> + reg = <0 0xee08 0 0x100>;
> + interrupts = ;
> + clocks = < CPG_MOD 703>;
> + phys = <_phy0>;
> + phy-names = "usb";
> + power-domains = < 32>;
> + resets = < 703>;
> + status = "disabled";
> + };
> +
> + ehci0: usb@ee080100 {
> + compatible = "generic-ehci";
> + reg = <0 0xee080100 0 0x100>;
> + interrupts = ;
> + clocks = < CPG_MOD 703>;
> + phys = <_phy0>;
> + phy-names = "usb";
> + companion = <>;
> + power-domains = < 32>;
> + resets = < 703>;
> + status = "disabled";
> + };
> +
> + usb2_phy0: usb-phy@ee080200 {
> + compatible = "renesas,usb2-phy-r8a77990",
> + "renesas,rcar-gen3-usb2-phy";
> + reg = <0 0xee080200 0 0x700>;
> + interrupts = ;
> + clocks = < CPG_MOD 703>;
> + power-domains = < 32>;
> + resets = < 703>;
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> +
> gic: interrupt-controller@f101 {
> compatible = "arm,gic-400";
> #interrupt-cells = <3>;
> --
> 2.11.0
RE: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
Hi Geert-san,
> From: Yoshihiro Shimoda, Sent: Thursday, May 31, 2018 6:12 PM
>
> Hi Geert-san, Wolfram-san,
>
> > From: Geert Uytterhoeven, Sent: Thursday, May 31, 2018 5:45 PM
> >
> > Hi Shimoda-san,
> >
> > On Wed, May 30, 2018 at 10:35 AM, Yoshihiro Shimoda
> > wrote:
> > >> From: Wolfram Sang, Sent: Tuesday, May 29, 2018 7:59 PM
> > >> Subject: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
> > >
> > > If possible, I'd like to replace "bug" with "specification" or other
> > > words :)
> > >
> > >
> > >> @@ -743,6 +753,16 @@ static int rcar_i2c_master_xfer(struct i2c_adapter
> > >> *adap,
> > >>
> > >> pm_runtime_get_sync(dev);
> > >>
> > >> + /* Gen3 has a HW bug which needs a reset before allowing RX DMA
> > >> once */
> > >> + if (priv->devtype == I2C_RCAR_GEN3) {
> > >> + priv->flags |= ID_P_NO_RXDMA;
> > >> + if (!IS_ERR(priv->rstc)) {
> > >> + ret = reset_control_reset(priv->rstc);
> > >
> > > According to the datasheet Rev.1.00 page 57-69, we should do:
> > > reset_control_assert();
> > > udelay(1);
> > > reset_control_deassert();
> > > while (reset_control_status())
> > > ;
> > > instead of reset_control_reset(), I think.
> >
> > The i2c-specific procedure documented at page 57-69 thus differs from
> > the generic one at page 8A-58, which is what cpg_mssr_reset() implements.
> >
> > The latter waits 35µs instead of 1µs, so that should be safe.
> > But it doesn't check the status bit. Is the longer delay sufficient, or
> > should
> > a check polling the status bit be added to cpg_mssr_reset()?
>
> Thank you for the pointed out.
> I agree we should wait 35us for safe.
> But, anyway I'll ask HW team about this contradiction and really need polling
> the status.
I got information about this topic.
< In CPG / MSSR point of view >
- This needs 35 usec wait while asserting.
- After deasserted a reset, no wait needs.
- In other words, there is each hardware IP dependence.
< In I2C point of view >
- After deasserted the reset, this nees SRCR register polling.
So, I don't think cpg_mssr_reset() checks the status bit after deasserted a
reset.
But, what do you think?
Best regards,
Yoshihiro Shimoda
RE: [PATCH] soc: renesas: rcar-sysc: Make PM domain initialization more robust
Hi Geert-san,
> From: Behalf Of Geert Uytterhoeven, Sent: Wednesday, June 6, 2018 5:58 PM
>
> Hi Simon,
>
> On Wed, Jun 6, 2018 at 10:52 AM, Simon Horman wrote:
> > On Tue, Jun 05, 2018 at 05:05:15PM +0200, Geert Uytterhoeven wrote:
> > This looks fine to me but I will wait to see if there are other reviews
> > before applying.
>
> Let's wait for feedback from Shimoda-san. Perpaps the quirk did rely on
> the buggy behavior.
I checked /sys/kernel/debug/pm_genpd/pm_genpd_summary.
< Before applies the patch >
- "3dg-b's" status is "off-0".
- "3dg-b" doesn't have any slaves.
< After applied the patch >
- "3dg-b's" status is "on".
- "3dg-b" has "3dg-a" slave.
So,
Tested-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
> > Reviewed-by: Simon Horman
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
[PATCH v2] arm64: dts: renesas: r8a77990: Enable USB2.0 Host for Ebisu board
This patch adds USB2.0 PHY and Host(EHCI/OHCI) nodes and
enables them for R-Car E3 Ebisu board.
Signed-off-by: Yoshihiro Shimoda
---
This patch set is based on renesas-drivers.git /
renesas-drivers-2018-06-05-v4.17 tag.
Changes from v1:
- Squash 4 patches into a single patch.
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 20 ++
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 37 ++
2 files changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 7a09d05..76fa244 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -47,10 +47,18 @@
};
};
+ {
+ status = "okay";
+};
+
_clk {
clock-frequency = <4800>;
};
+ {
+ status = "okay";
+};
+
{
avb_pins: avb {
mux {
@@ -58,8 +66,20 @@
function = "avb";
};
};
+
+ usb0_pins: usb {
+ groups = "usb0_b";
+ function = "usb0";
+ };
};
{
status = "okay";
};
+
+_phy0 {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index be4f519..0b2bec3 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -248,6 +248,43 @@
status = "disabled";
};
+ ohci0: usb@ee08 {
+ compatible = "generic-ohci";
+ reg = <0 0xee08 0 0x100>;
+ interrupts = ;
+ clocks = < CPG_MOD 703>;
+ phys = <_phy0>;
+ phy-names = "usb";
+ power-domains = < 32>;
+ resets = < 703>;
+ status = "disabled";
+ };
+
+ ehci0: usb@ee080100 {
+ compatible = "generic-ehci";
+ reg = <0 0xee080100 0 0x100>;
+ interrupts = ;
+ clocks = < CPG_MOD 703>;
+ phys = <_phy0>;
+ phy-names = "usb";
+ companion = <>;
+ power-domains = < 32>;
+ resets = < 703>;
+ status = "disabled";
+ };
+
+ usb2_phy0: usb-phy@ee080200 {
+ compatible = "renesas,usb2-phy-r8a77990",
+"renesas,rcar-gen3-usb2-phy";
+ reg = <0 0xee080200 0 0x700>;
+ interrupts = ;
+ clocks = < CPG_MOD 703>;
+ power-domains = < 32>;
+ resets = < 703>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
1.9.1
RE: [PATCH 0/4] arm64: dts: renesas: r8a77990 and ebisu: Enable USB2.0 host
Hi Simon-san,
> From: Simon Horman, Sent: Wednesday, June 6, 2018 6:16 PM
>
> On Wed, Jun 06, 2018 at 03:56:07PM +0900, Yoshihiro Shimoda wrote:
> > This patch set is based on renesas-drivers.git /
> > renesas-drivers-2018-06-05-v4.17 tag.
> >
> > About dt-bindings of "renesas,usb2-phy-r8a77990", I submitted a patch:
> > https://patchwork.kernel.org/patch/10449723/
> >
> > But, the phy-rcar-gen3-usb2 driver works on the board without the bindings
> > because "renesas,rcar-gen3-usb2-phy" can bind the driver.
> >
> > Also, for now, I don't try to add/enable USB2.0 peripheral on the board
> > because the phy driver needs some modifications.
> >
> > Yoshihiro Shimoda (4):
> > arm64: dts: renesas: r8a77990: add usb2_phy device node
> > arm64: dts: renesas: r8a77990: add USB2.0 host device nodes
> > arm64: dts: renesas: r8a77990: ebisu: enable usb2_phy0
> > arm64: dts: renesas: r8a77990: ebisu: enable USB2.0 host
> >
> > arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 20 ++
> > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 37
> > ++
> > 2 files changed, 57 insertions(+)
>
> Hi Shomoda-san,
>
> the contents of this series looks good to me. However, given Olof
> Johansson's recent comments in ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> Updates for v4.18") please consider squashing this series into a single
> patch and reposting.
Sure. I'll resubmit v2 patch as a single patch.
Best regards,
Yoshihiro Shimoda
> Thanks!
[PATCH 3/4] arm64: dts: renesas: r8a77990: ebisu: enable usb2_phy0
This patch enables usb2_phy0 for r8a77990 Ebisu board.
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 7a09d05..1be10c9 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -58,8 +58,20 @@
function = "avb";
};
};
+
+ usb0_pins: usb {
+ groups = "usb0_b";
+ function = "usb0";
+ };
};
{
status = "okay";
};
+
+_phy0 {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
1.9.1
[PATCH 4/4] arm64: dts: renesas: r8a77990: ebisu: enable USB2.0 host
This patch enables USB2.0 host (EHCI/OHCI) for r8a77990 Ebisu board.
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 1be10c9..76fa244 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -47,10 +47,18 @@
};
};
+ {
+ status = "okay";
+};
+
_clk {
clock-frequency = <4800>;
};
+ {
+ status = "okay";
+};
+
{
avb_pins: avb {
mux {
--
1.9.1
[PATCH 1/4] arm64: dts: renesas: r8a77990: add usb2_phy device node
This patch adds USB2.0 phy device node for r8a77990.
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index be4f519..121c4a0 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -248,6 +248,18 @@
status = "disabled";
};
+ usb2_phy0: usb-phy@ee080200 {
+ compatible = "renesas,usb2-phy-r8a77990",
+"renesas,rcar-gen3-usb2-phy";
+ reg = <0 0xee080200 0 0x700>;
+ interrupts = ;
+ clocks = < CPG_MOD 703>;
+ power-domains = < 32>;
+ resets = < 703>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
1.9.1
[PATCH 0/4] arm64: dts: renesas: r8a77990 and ebisu: Enable USB2.0 host
This patch set is based on renesas-drivers.git / renesas-drivers-2018-06-05-v4.17 tag. About dt-bindings of "renesas,usb2-phy-r8a77990", I submitted a patch: https://patchwork.kernel.org/patch/10449723/ But, the phy-rcar-gen3-usb2 driver works on the board without the bindings because "renesas,rcar-gen3-usb2-phy" can bind the driver. Also, for now, I don't try to add/enable USB2.0 peripheral on the board because the phy driver needs some modifications. Yoshihiro Shimoda (4): arm64: dts: renesas: r8a77990: add usb2_phy device node arm64: dts: renesas: r8a77990: add USB2.0 host device nodes arm64: dts: renesas: r8a77990: ebisu: enable usb2_phy0 arm64: dts: renesas: r8a77990: ebisu: enable USB2.0 host arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 20 ++ arch/arm64/boot/dts/renesas/r8a77990.dtsi | 37 ++ 2 files changed, 57 insertions(+) -- 1.9.1
[PATCH 0/2] pinctrl: sh-pfc: r8a77990: Add USB2.0 pins, groups and funcrions
This patch set is based on renesas-drivers.git / renesas-drivers-2018-06-05-v4.17 tag. Takeshi Kihara (1): pinctrl: sh-pfc: r8a77990: Add USB2.0 pins, groups and functions Yoshihiro Shimoda (1): pinctrl: sh-pfc: r8a77990: Revise USB ID pin name drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 42 +-- 1 file changed, 40 insertions(+), 2 deletions(-) -- 1.9.1
[PATCH 1/2] pinctrl: sh-pfc: r8a77990: Revise USB ID pin name
Since the datasheet Rev.1.00 has an error about the USB ID pin name,
this patch revises it.
Signed-off-by: Yoshihiro Shimoda
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index a68fd65..dc4a957 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -277,7 +277,7 @@
#define IP11_15_12 FM(TX0_A) FM(HTX1_A)
FM(SSI_WS2_A) FM(RIF1_D0) F_(0, 0)F_(0,
0)F_(0, 0)FM(TS_SDAT1)F_(0, 0)F_(0, 0) F_(0, 0)
F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
#define IP11_19_16 FM(CTS0_N_A)FM(NFDATA14_A)
FM(AUDIO_CLKOUT_A) FM(RIF1_D1) FM(SCIF_CLK_A)
FM(FMCLK_A) F_(0, 0)F_(0, 0)F_(0, 0)F_(0, 0) F_(0,
0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
#define IP11_23_20 FM(RTS0_N_TANS_A) FM(NFDATA15_A)
FM(AUDIO_CLKOUT1_A) FM(RIF1_CLK)FM(SCL2_A)
FM(FMIN_A) F_(0, 0)F_(0, 0)F_(0, 0)F_(0, 0) F_(0,
0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
-#define IP11_27_24 FM(SCK0_A) FM(HSCK1_A)
FM(USB3HS0_ID) FM(RTS1_N_TANS) FM(SDA2_A)
FM(FMCLK_C) F_(0, 0)F_(0, 0)FM(USB1_ID) F_(0, 0) F_(0,
0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
+#define IP11_27_24 FM(SCK0_A) FM(HSCK1_A)
FM(USB3HS0_ID) FM(RTS1_N_TANS) FM(SDA2_A)
FM(FMCLK_C) F_(0, 0)F_(0, 0)FM(USB0_ID) F_(0, 0) F_(0,
0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
#define IP11_31_28 FM(RX1) FM(HRX2_B)
FM(SSI_SCK9_B) FM(AUDIO_CLKOUT1_B) F_(0, 0)F_(0,
0)F_(0, 0)F_(0, 0)F_(0, 0)F_(0, 0) F_(0, 0)
F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0) F_(0, 0)
/* IPSRx *//* 0 */ /* 1 */ /* 2 */
/* 3 */ /* 4 */ /* 5 */
/* 6 */ /* 7 */ /* 8 */ /* 9 - F */
@@ -1082,7 +1082,7 @@ enum {
PINMUX_IPSR_GPSR(IP11_27_24,RTS1_N_TANS),
PINMUX_IPSR_MSEL(IP11_27_24,SDA2_A, SEL_I2C2_0),
PINMUX_IPSR_MSEL(IP11_27_24,FMCLK_C,SEL_FM_2),
- PINMUX_IPSR_GPSR(IP11_27_24,USB1_ID),
+ PINMUX_IPSR_GPSR(IP11_27_24,USB0_ID),
PINMUX_IPSR_GPSR(IP11_31_28,RX1),
PINMUX_IPSR_MSEL(IP11_31_28,HRX2_B, SEL_HSCIF2_1),
--
1.9.1
[PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add USB2.0 pins, groups and functions
From: Takeshi Kihara
This patch adds USB0_{PWEN,OVC}_{A,B} and USB0_ID pins, groups and
functions to the R8A77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Yoshihiro Shimoda
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index dc4a957..edefcc3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1784,6 +1784,34 @@ enum {
SCIF_CLK_B_MARK,
};
+/* - USB0 ---
*/
+static const unsigned int usb0_a_pins[] = {
+ /* PWEN, OVC */
+ RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 9),
+};
+
+static const unsigned int usb0_a_mux[] = {
+ USB0_PWEN_A_MARK, USB0_OVC_A_MARK,
+};
+
+static const unsigned int usb0_b_pins[] = {
+ /* PWEN, OVC */
+ RCAR_GP_PIN(6, 11), RCAR_GP_PIN(6, 12),
+};
+
+static const unsigned int usb0_b_mux[] = {
+ USB0_PWEN_B_MARK, USB0_OVC_B_MARK,
+};
+
+static const unsigned int usb0_id_pins[] = {
+ /* ID */
+ RCAR_GP_PIN(5, 0)
+};
+
+static const unsigned int usb0_id_mux[] = {
+ USB0_ID_MARK,
+};
+
static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_link),
SH_PFC_PIN_GROUP(avb_magic),
@@ -1837,6 +1865,9 @@ enum {
SH_PFC_PIN_GROUP(scif5_data_c),
SH_PFC_PIN_GROUP(scif_clk_a),
SH_PFC_PIN_GROUP(scif_clk_b),
+ SH_PFC_PIN_GROUP(usb0_a),
+ SH_PFC_PIN_GROUP(usb0_b),
+ SH_PFC_PIN_GROUP(usb0_id),
};
static const char * const avb_groups[] = {
@@ -1933,6 +1964,12 @@ enum {
"scif_clk_b",
};
+static const char * const usb0_groups[] = {
+ "usb0_a",
+ "usb0_b",
+ "usb0_id",
+};
+
static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(avb),
SH_PFC_FUNCTION(i2c1),
@@ -1948,6 +1985,7 @@ enum {
SH_PFC_FUNCTION(scif4),
SH_PFC_FUNCTION(scif5),
SH_PFC_FUNCTION(scif_clk),
+ SH_PFC_FUNCTION(usb0),
};
static const struct pinmux_cfg_reg pinmux_config_regs[] = {
--
1.9.1
[PATCH] dt-bindings: rcar-gen3-phy-usb2: Add bindings for r8a77990
This patch adds suuport for r8a77990 (R-Car E3). Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt index dbd137c..fb4a204 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt @@ -10,6 +10,8 @@ Required properties: SoC. "renesas,usb2-phy-r8a77965" if the device is a part of an R8A77965 SoC. + "renesas,usb2-phy-r8a77990" if the device is a part of an + R8A77990 SoC. "renesas,usb2-phy-r8a77995" if the device is a part of an R8A77995 SoC. "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible device. -- 1.9.1
RE: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
Hello Wolfram-san,
> From: Wolfram Sang, Sent: Thursday, May 31, 2018 5:31 PM
>
> Hello Shimoda-san,
>
> > > Subject: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
> >
> > If possible, I'd like to replace "bug" with "specification" or other words
> > :)
>
> "behaviour" maybe is a better word?
It sounds good to me.
> > > + /* Gen3 has a HW bug which needs a reset before allowing RX DMA once */
> > > + if (priv->devtype == I2C_RCAR_GEN3) {
> > > + priv->flags |= ID_P_NO_RXDMA;
> > > + if (!IS_ERR(priv->rstc)) {
> > > + ret = reset_control_reset(priv->rstc);
> >
> > According to the datasheet Rev.1.00 page 57-69, we should do:
> > reset_control_assert();
> > udelay(1);
> > reset_control_deassert();
> > while (reset_control_status())
> > ;
> > instead of reset_control_reset(), I think.
>
> I was following Geert's suggestion here from the mail thread '[periperi] About
> BSP patch "i2c: rcar: Fix I2C DMA reception by adding reset':
>
> ===
>
> >> reset_control_assert() + reset_control_deassert() can be replaced by
> >> reset_control_assert().
> >
> > Do you mean 'reset_control_reset' maybe? I am not sure, I don't know
> > this API very well... but two time *_assert looks suspicious.
>
> Of course. Silly c
>
> >> In addition, that will make sure the delay of one cycle of the RCLK clock
> >> is taken into account, which is not the case with the current code.
> >
> > I guess this is why there is now this patch in the BSP which Shimoda-san
> > mentioned in a later mail:
> >
> > f0cd22525f73 ("i2c: rcar: Fix module reset function for hardware
> > specification")
>
> Exactly.
>
> ===
>
> As far as I understood it takes care of the proper reset mechanism with the
> delay?
I missed this email... As I replied to Geert-san on other email thread,
I'll ask HW team about this topic.
Best regards,
Yoshihiro Shimoda
> Kind regards,
>
>Wolfram
RE: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
Hi Geert-san, Wolfram-san,
> From: Geert Uytterhoeven, Sent: Thursday, May 31, 2018 5:45 PM
>
> Hi Shimoda-san,
>
> On Wed, May 30, 2018 at 10:35 AM, Yoshihiro Shimoda
> wrote:
> >> From: Wolfram Sang, Sent: Tuesday, May 29, 2018 7:59 PM
> >> Subject: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
> >
> > If possible, I'd like to replace "bug" with "specification" or other words
> > :)
> >
> >
> >> @@ -743,6 +753,16 @@ static int rcar_i2c_master_xfer(struct i2c_adapter
> >> *adap,
> >>
> >> pm_runtime_get_sync(dev);
> >>
> >> + /* Gen3 has a HW bug which needs a reset before allowing RX DMA once
> >> */
> >> + if (priv->devtype == I2C_RCAR_GEN3) {
> >> + priv->flags |= ID_P_NO_RXDMA;
> >> + if (!IS_ERR(priv->rstc)) {
> >> + ret = reset_control_reset(priv->rstc);
> >
> > According to the datasheet Rev.1.00 page 57-69, we should do:
> > reset_control_assert();
> > udelay(1);
> > reset_control_deassert();
> > while (reset_control_status())
> > ;
> > instead of reset_control_reset(), I think.
>
> The i2c-specific procedure documented at page 57-69 thus differs from
> the generic one at page 8A-58, which is what cpg_mssr_reset() implements.
>
> The latter waits 35µs instead of 1µs, so that should be safe.
> But it doesn't check the status bit. Is the longer delay sufficient, or should
> a check polling the status bit be added to cpg_mssr_reset()?
Thank you for the pointed out.
I agree we should wait 35us for safe.
But, anyway I'll ask HW team about this contradiction and really need polling
the status.
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
