RE: [RFC v3 1/2] pinctrl: core: Add pinctrl_mux_gpio_request_enable
Hello Linus, Thank you for your feedback! > From: Linus Walleij > Sent: 05 December 2018 21:46 > Subject: Re: [RFC v3 1/2] pinctrl: core: Add pinctrl_mux_gpio_request_enable > > On Tue, Nov 20, 2018 at 4:19 PM Fabrizio Castro > wrote: > > > Sometimes there is the need to change the muxing of a pin to make it > > a GPIO without going through gpiolib. > > This patch adds pinctrl_mux_gpio_request_enable to deal with this new > > use case from code that has nothing to do with pinctrl. > > It has a lot to do with pinctrl I think, so I get confused by this > commit message. I can improve that > > > extern int pinctrl_gpio_request(unsigned gpio); > > +extern int pinctrl_mux_gpio_request_enable(unsigned gpio); > > What's wrong with just using the existing call > pinctrl_gpio_request() right above your new one? > > It's not like we're reference counting or something, it's just > a callback. Sprinkle some comments to show what's going > on. I tried that, and it was working for me, then something changed lately in gpiolib that broke that solution, and Geert picked it up on his end. Please see this: https://patchwork.kernel.org/patch/10671325/ This patch was made to overcome the problems of the previous patch. > > If you for some reason need a new call for this specific > use case, it needs to be named after the use case, > like pinctrl_gpio_request_for_irq() > so it is obvious what the function is doing. I can do that, but I would like to hear from Geert first, no point in going around in circle if this solution is not acceptable to him. Geert, what do you think? Thanks! Fab > > Yours, > Linus Walleij [https://www2.renesas.eu/media/email/unicef.jpg] This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world. We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year. Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [RFC] watchdog: renesas_wdt: don't keep timer value during suspend/resume
Hello Wolfram,
> From: Wolfram Sang
> Sent: 04 December 2018 12:02
> Subject: [RFC] watchdog: renesas_wdt: don't keep timer value during
> suspend/resume
>
> After discussing this mail thread [1] again, we concluded that giving
> userspace enough time to prepare is our favourite option. So, do not
> keep the time value when suspended but reset it when resuming.
>
> [1] https://patchwork.kernel.org/patch/10252209/
>
> Signed-off-by: Wolfram Sang
> ---
>
> Fabrizio: can you agree to that? The R-Car BSP team and we (the R-Car upstream
> team) would prefer it this way (knowing it is also not perfect).
I am not too sure, as the system relies on the watchdog to fix problems that
won't resolve
on their own, therefore if you have an application made of two threads, one
very critical
for the health of the system (but unfortunately buggy, which means it is
destined to not
ping watchdog on time), and the other thread takes care of putting the system
to sleep,
you may find yourself in a place where the system doesn't work properly (as the
critical
thread won't work as expected) and never restarts (because the other thread
works properly
and putting the system to sleep resets the watchdog).
Sometimes the line between policies and mechanisms is not a clear cut, I think
this patch
looks more like a policy decision, but I may be wrong.
Cheers,
Fab
>
> drivers/watchdog/renesas_wdt.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index b570962e84f3..9f2307bf727b 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -48,7 +48,6 @@ struct rwdt_priv {
> void __iomem *base;
> struct watchdog_device wdev;
> unsigned long clk_rate;
> -u16 time_left;
> u8 cks;
> };
>
> @@ -263,10 +262,9 @@ static int __maybe_unused rwdt_suspend(struct device
> *dev)
> {
> struct rwdt_priv *priv = dev_get_drvdata(dev);
>
> -if (watchdog_active(>wdev)) {
> -priv->time_left = readw(priv->base + RWTCNT);
> +if (watchdog_active(>wdev))
> rwdt_stop(>wdev);
> -}
> +
> return 0;
> }
>
> @@ -274,10 +272,9 @@ static int __maybe_unused rwdt_resume(struct device *dev)
> {
> struct rwdt_priv *priv = dev_get_drvdata(dev);
>
> -if (watchdog_active(>wdev)) {
> +if (watchdog_active(>wdev))
> rwdt_start(>wdev);
> -rwdt_write(priv, priv->time_left, RWTCNT);
> -}
> +
> return 0;
> }
>
> --
> 2.11.0
[https://www2.renesas.eu/media/email/unicef.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have
decided to support Unicef with a donation. For further details click
here
[RFC v3 2/2] gpio: rcar: Set pin as a GPIO when configuring an interrupt
As it turns out, the bootloader or a POR may get in the way of the current implementation of gpio_rcar_irq_set_type, as the pinmuxing may not be GPIO. This patch makes sure the pin is configured as a GPIO when requesting it an interrupt, as that's necessary for the interrupt to work properly. Failing to do so may damage the board as this can cause shorts. Signed-off-by: Fabrizio Castro --- drivers/gpio/gpio-rcar.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c index 1322f7e..615404c 100644 --- a/drivers/gpio/gpio-rcar.c +++ b/drivers/gpio/gpio-rcar.c @@ -168,6 +168,9 @@ static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type) default: return -EINVAL; } + + pinctrl_mux_gpio_request_enable(gc->base + hwirq); + return 0; } -- 2.7.4
[RFC v3 0/2] Request GPIO when enabling interrupt
Dear All, here is a new iteration of the fix for the pinmuxing issue while requesting an interrupt. I don't like this implementation either as: * pinctrl_mux_gpio_request_enable is very similar to pinctrl_gpio_request, and the name I have picked up is not exactly brilliant... * it may cause an error message like "Pin X is busy, can't configure it as GPIO." (for cd-gpios pins for example) as it can't check the status of the pin before requesting it (can it?) * because it's discarding errors returned by pinctrl_mux_gpio_request_enable This problem needs fixing, but the solutions proposed so far don't look great, as they are not spectacularly neat. What's the best way to fix this? Ideas and comments very welcome! Thanks, Fab Fabrizio Castro (2): pinctrl: core: Add pinctrl_mux_gpio_request_enable gpio: rcar: Set pin as a GPIO when configuring an interrupt drivers/gpio/gpio-rcar.c | 3 +++ drivers/pinctrl/core.c | 34 ++ include/linux/pinctrl/consumer.h | 6 ++ 3 files changed, 43 insertions(+) -- 2.7.4
[RFC v3 1/2] pinctrl: core: Add pinctrl_mux_gpio_request_enable
Sometimes there is the need to change the muxing of a pin to make it
a GPIO without going through gpiolib.
This patch adds pinctrl_mux_gpio_request_enable to deal with this new
use case from code that has nothing to do with pinctrl.
Signed-off-by: Fabrizio Castro
---
drivers/pinctrl/core.c | 34 ++
include/linux/pinctrl/consumer.h | 6 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c6ff4d5..d5f4128 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_GPIOLIB
#include
@@ -796,6 +797,39 @@ int pinctrl_gpio_request(unsigned gpio)
EXPORT_SYMBOL_GPL(pinctrl_gpio_request);
/**
+ * pinctrl_mux_gpio_request_enable() - request the pinmuxing of a single pin to
+ * be set as a GPIO.
+ * @gpio: the GPIO pin number from the GPIO subsystem number space
+ */
+int pinctrl_mux_gpio_request_enable(unsigned gpio)
+{
+ struct pinctrl_dev *pctldev;
+ struct pinctrl_gpio_range *range;
+ const struct pinmux_ops *ops;
+ int ret;
+ int pin;
+
+ ret = pinctrl_get_device_gpio_range(gpio, , );
+ if (ret)
+ return ret;
+
+ ops = pctldev->desc->pmxops;
+
+ mutex_lock(>mutex);
+
+ /* Convert to the pin controllers number space */
+ pin = gpio_to_pin(range, gpio);
+
+ if (ops->gpio_request_enable)
+ ret = ops->gpio_request_enable(pctldev, range, pin);
+
+ mutex_unlock(>mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pinctrl_mux_gpio_request_enable);
+
+/**
* pinctrl_gpio_free() - free control on a single pin, currently used as GPIO
* @gpio: the GPIO pin number from the GPIO subsystem number space
*
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index 0412cc9..3fa32cf 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -26,6 +26,7 @@ struct device;
/* External interface to pin control */
extern int pinctrl_gpio_request(unsigned gpio);
+extern int pinctrl_mux_gpio_request_enable(unsigned gpio);
extern void pinctrl_gpio_free(unsigned gpio);
extern int pinctrl_gpio_direction_input(unsigned gpio);
extern int pinctrl_gpio_direction_output(unsigned gpio);
@@ -67,6 +68,11 @@ static inline int pinctrl_gpio_request(unsigned gpio)
return 0;
}
+static inline int pinctrl_mux_gpio_request_enable(unsigned gpio)
+{
+ return 0;
+}
+
static inline void pinctrl_gpio_free(unsigned gpio)
{
}
--
2.7.4
[PATCH v3] drm/bridge/sii902x: Add missing dependency on I2C_MUX
kbuild test robot reports:
>> ERROR: "i2c_mux_add_adapter" [drivers/gpu/drm/bridge/sii902x.ko]
undefined!
>> ERROR: "i2c_mux_alloc" [drivers/gpu/drm/bridge/sii902x.ko]
undefined!
>> ERROR: "i2c_mux_del_adapters" [drivers/gpu/drm/bridge/sii902x.ko]
undefined!
Quite obviously the driver depends on I2C_MUX, but adding a "depends on"
introduces a recursive dependency, therefore this patch selects I2C_MUX
instead.
Fixes: 21d808405fe4 ("drm/bridge/sii902x: Fix EDID readback")
Signed-off-by: Fabrizio Castro
Link: https://lists.01.org/pipermail/kbuild-all/2018-November/054924.html
---
v2->v3:
* Changed the title
v1->v2:
* Added "Fixes" tag
drivers/gpu/drm/bridge/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 9eeb8ef..2fee47b 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -95,6 +95,7 @@ config DRM_SII902X
depends on OF
select DRM_KMS_HELPER
select REGMAP_I2C
+ select I2C_MUX
---help---
Silicon Image sii902x bridge chip driver.
--
2.7.4
RE: [PATCH] drm/bridge: Fix 0-day build error
> -Original Message-
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Boris Brezillon
> Sent: 19 November 2018 13:23
> To: Fabrizio Castro
> Cc: Peter Rosin ; Archit Taneja ;
> Andrzej Hajda ; David Airlie
> ; Laurent Pinchart ;
> dri-de...@lists.freedesktop.org; Simon Horman
> ; Geert Uytterhoeven ; Chris
> Paterson ; Biju Das
> ; linux-renesas-soc@vger.kernel.org
> Subject: Re: [PATCH] drm/bridge: Fix 0-day build error
>
> On Mon, 19 Nov 2018 13:09:16 +
> Fabrizio Castro wrote:
>
> > Hi Boris,
> >
> > > From: Boris Brezillon
> > > Sent: 19 November 2018 12:51
> > > Subject: Re: [PATCH] drm/bridge: Fix 0-day build error
> > >
> > > Hi Fabrizio,
> > >
> > > The prefix should be "drm/bridge/sii902x:" and I'd prefer a short
> > > explanation of what is problematic in the subject rather than "Fix
> > > 0-day build error". Maybe something like
> > >
> > > "drm/bridge/sii902x: Add missing dependency on I2C_MUX"
> > >
> > > On Mon, 19 Nov 2018 12:44:23 +
> > > Fabrizio Castro wrote:
> > >
> > > > kbuild test robot reports:
> > > >
> > > > >> ERROR: "i2c_mux_add_adapter" [drivers/gpu/drm/bridge/sii902x.ko]
> > > > undefined!
> > > > >> ERROR: "i2c_mux_alloc" [drivers/gpu/drm/bridge/sii902x.ko]
> > > > undefined!
> > > > >> ERROR: "i2c_mux_del_adapters" [drivers/gpu/drm/bridge/sii902x.ko]
> > > > undefined!
> > > >
> > > > Quite obviously the driver depends on I2C_MUX, but adding a "depends on"
> > > > introduces a recursive dependency, therefore this patch selects I2C_MUX
> > > > instead.
> > > >
> > >
> > > You need a fixes tag here:
> > >
> > > Fixes: 21d808405fe4 ("drm/bridge/sii902x: Fix EDID readback")
> >
> > Thank you for spotting this, I'll send a v2 right away.
>
> Looks like you didn't change the subject in your v2.
Will send a v3...
Thanks,
Fab
>
> >
> > Cheers,
> > Fab
> >
> > >
> > > Thanks,
> > >
> > > Boris
> > >
> > > > Signed-off-by: Fabrizio Castro
> > > > Link:
> > > > https://lists.01.org/pipermail/kbuild-all/2018-November/054924.html
> > > > ---
> > > > drivers/gpu/drm/bridge/Kconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > index 9eeb8ef..2fee47b 100644
> > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > @@ -95,6 +95,7 @@ config DRM_SII902X
> > > > depends on OF
> > > > select DRM_KMS_HELPER
> > > > select REGMAP_I2C
> > > > +select I2C_MUX
> > > > ---help---
> > > >Silicon Image sii902x bridge chip driver.
> > > >
> >
> >
> >
> >
> > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
> > Buckinghamshire, SL8 5FH, UK. Registered in England
> & Wales under Registered No. 04586709.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
[PATCH v2] drm/bridge: Fix 0-day build error
kbuild test robot reports:
>> ERROR: "i2c_mux_add_adapter" [drivers/gpu/drm/bridge/sii902x.ko]
undefined!
>> ERROR: "i2c_mux_alloc" [drivers/gpu/drm/bridge/sii902x.ko]
undefined!
>> ERROR: "i2c_mux_del_adapters" [drivers/gpu/drm/bridge/sii902x.ko]
undefined!
Quite obviously the driver depends on I2C_MUX, but adding a "depends on"
introduces a recursive dependency, therefore this patch selects I2C_MUX
instead.
Fixes: 21d808405fe4 ("drm/bridge/sii902x: Fix EDID readback")
Signed-off-by: Fabrizio Castro
Link: https://lists.01.org/pipermail/kbuild-all/2018-November/054924.html
---
v1->v2:
* Added "Fixes" tag
drivers/gpu/drm/bridge/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 9eeb8ef..2fee47b 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -95,6 +95,7 @@ config DRM_SII902X
depends on OF
select DRM_KMS_HELPER
select REGMAP_I2C
+ select I2C_MUX
---help---
Silicon Image sii902x bridge chip driver.
--
2.7.4
RE: [PATCH] drm/bridge: Fix 0-day build error
Hi Boris,
> From: Boris Brezillon
> Sent: 19 November 2018 12:51
> Subject: Re: [PATCH] drm/bridge: Fix 0-day build error
>
> Hi Fabrizio,
>
> The prefix should be "drm/bridge/sii902x:" and I'd prefer a short
> explanation of what is problematic in the subject rather than "Fix
> 0-day build error". Maybe something like
>
> "drm/bridge/sii902x: Add missing dependency on I2C_MUX"
>
> On Mon, 19 Nov 2018 12:44:23 +
> Fabrizio Castro wrote:
>
> > kbuild test robot reports:
> >
> > >> ERROR: "i2c_mux_add_adapter" [drivers/gpu/drm/bridge/sii902x.ko]
> > undefined!
> > >> ERROR: "i2c_mux_alloc" [drivers/gpu/drm/bridge/sii902x.ko]
> > undefined!
> > >> ERROR: "i2c_mux_del_adapters" [drivers/gpu/drm/bridge/sii902x.ko]
> > undefined!
> >
> > Quite obviously the driver depends on I2C_MUX, but adding a "depends on"
> > introduces a recursive dependency, therefore this patch selects I2C_MUX
> > instead.
> >
>
> You need a fixes tag here:
>
> Fixes: 21d808405fe4 ("drm/bridge/sii902x: Fix EDID readback")
Thank you for spotting this, I'll send a v2 right away.
Cheers,
Fab
>
> Thanks,
>
> Boris
>
> > Signed-off-by: Fabrizio Castro
> > Link: https://lists.01.org/pipermail/kbuild-all/2018-November/054924.html
> > ---
> > drivers/gpu/drm/bridge/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 9eeb8ef..2fee47b 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -95,6 +95,7 @@ config DRM_SII902X
> > depends on OF
> > select DRM_KMS_HELPER
> > select REGMAP_I2C
> > +select I2C_MUX
> > ---help---
> >Silicon Image sii902x bridge chip driver.
> >
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
[PATCH] drm/bridge: Fix 0-day build error
kbuild test robot reports: >> ERROR: "i2c_mux_add_adapter" [drivers/gpu/drm/bridge/sii902x.ko] undefined! >> ERROR: "i2c_mux_alloc" [drivers/gpu/drm/bridge/sii902x.ko] undefined! >> ERROR: "i2c_mux_del_adapters" [drivers/gpu/drm/bridge/sii902x.ko] undefined! Quite obviously the driver depends on I2C_MUX, but adding a "depends on" introduces a recursive dependency, therefore this patch selects I2C_MUX instead. Signed-off-by: Fabrizio Castro Link: https://lists.01.org/pipermail/kbuild-all/2018-November/054924.html --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 9eeb8ef..2fee47b 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -95,6 +95,7 @@ config DRM_SII902X depends on OF select DRM_KMS_HELPER select REGMAP_I2C + select I2C_MUX ---help--- Silicon Image sii902x bridge chip driver. -- 2.7.4
RE: [PATCH v2] gpio: rcar: Request GPIO while enabling interrupt
Hello Geert, Thank you for your feedback! > From: Geert Uytterhoeven > Sent: 14 November 2018 12:52 > Subject: Re: [PATCH v2] gpio: rcar: Request GPIO while enabling interrupt > > Hi Fabrizio, > > On Tue, Nov 6, 2018 at 8:19 PM Fabrizio Castro > wrote: > > There are cases when the bootloader configures a pin to work > > as a function rather than GPIO, and other cases when the pin > > is configured as a function at POR. > > This commit makes sure the pin is configured as a GPIO the > > moment we need it to work as an interrupt. > > > > Signed-off-by: Fabrizio Castro > > > > --- > > v1->v2: > > * Moved gpio_rcar_request call from gpio_rcar_irq_set_type to > > rcar_gpio_irq_request_resources > > * Added rcar_gpio_irq_release_resources for calling gpio_rcar_free > > Thanks for your patch! > > While I could see no obvious deficiencies at first glance, I gave your > patch a try on Koelsch and Salvator-XS. Thank you for testing the patch! These issues seem to be related to a few patches that were merged only recently, I have rebased my work on top of the next-20181115 now, and I get the same thing. I need to look into this from scratch again, I'll be in touch as soon as I have found an alternative way to fix the issue. Thanks, Fab > > Koelsch: > > - ADV7511 HDMI encoder WARN_ON(!test_bit(FLAG_USED_AS_IRQ, >flags) > in gpiochip_enable_irq(): > > WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:3513 > gpiochip_irq_enable+0x18/0x34 > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 4.20.0-rc2-koelsch-00873-gf433e294a90792da-dirty #179 > Hardware name: Generic R-Car Gen2 (Flattened Device Tree) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x7c/0x9c) > [] (dump_stack) from [] (__warn+0xd0/0xec) > [] (__warn) from [] (warn_slowpath_null+0x38/0x44) > [] (warn_slowpath_null) from [] > (gpiochip_irq_enable+0x18/0x34) > [] (gpiochip_irq_enable) from [] > (irq_enable+0x3c/0x50) > [] (irq_enable) from [] (__irq_startup+0x94/0xa4) > [] (__irq_startup) from [] (irq_startup+0x4c/0x11c) > [] (irq_startup) from [] (__setup_irq+0x4d0/0x6a4) > [] (__setup_irq) from [] > (request_threaded_irq+0x9c/0x134) > [] (request_threaded_irq) from [] > (devm_request_threaded_irq+0x68/0xa4) > [] (devm_request_threaded_irq) from [] > (adv7511_probe+0x748/0x860) > [] (adv7511_probe) from [] > (i2c_device_probe+0x210/0x228) > [] (i2c_device_probe) from [] > (really_probe+0x1f0/0x2c0) > [] (really_probe) from [] > (driver_probe_device+0x140/0x15c) > [] (driver_probe_device) from [] > (bus_for_each_drv+0xa0/0xb4) > [] (bus_for_each_drv) from [] > (__device_attach+0xb0/0x124) > [] (__device_attach) from [] > (bus_probe_device+0x28/0x80) > [] (bus_probe_device) from [] (device_add+0x438/0x570) > [] (device_add) from [] (i2c_new_device+0x238/0x278) > [] (i2c_new_device) from [] > (of_i2c_register_device+0x40/0x80) > [] (of_i2c_register_device) from [] > (of_i2c_register_devices+0x80/0xc0) > [] (of_i2c_register_devices) from [] > (i2c_register_adapter+0x1ec/0x390) > [] (i2c_register_adapter) from [] > (i2c_demux_activate_master+0xd4/0x158) > [] (i2c_demux_activate_master) from [] > (i2c_demux_pinctrl_probe+0x190/0x1f0) > [] (i2c_demux_pinctrl_probe) from [] > (platform_drv_probe+0x48/0x94) > [] (platform_drv_probe) from [] > (really_probe+0x1f0/0x2c0) > [] (really_probe) from [] > (driver_probe_device+0x140/0x15c) > [] (driver_probe_device) from [] > (__driver_attach+0x8c/0xc8) > [] (__driver_attach) from [] > (bus_for_each_dev+0x64/0xa0) > [] (bus_for_each_dev) from [] > (bus_add_driver+0x16c/0x1d4) > [] (bus_add_driver) from [] > (driver_register+0xac/0xf0) > [] (driver_register) from [] > (do_one_initcall+0x70/0x170) > [] (do_one_initcall) from [] > (kernel_init_freeable+0x194/0x1d8) > [] (kernel_init_freeable) from [] > (kernel_init+0x8/0x110) > [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) > Exception stack(0xeb44dfb0 to 0xeb44dff8) > dfa0: > > dfc0: > > dfe0: 0013 > > - SDHI CD pin failure (first channel shown only): > > sh-pfc e606.pin-controller: pin GP_6_6 already requested by > e6055400.gpio:812; cannot claim for e6055400.gpio:812 > sh-pfc e606.pin-controller: pin-198 (e6055400.gpio:812) status -2
[PATCH resend] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
From: Biju Das This patch adds binding for r8a774a1 (RZ/G2M). Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro Acked-by: Vinod Koul Reviewed-by: Simon Horman Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt index a1e7b814..5e2c7e8 100644 --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt @@ -7,6 +7,7 @@ Required Properties: - "renesas,r8a7744-usb-dmac" (RZ/G1N) - "renesas,r8a7745-usb-dmac" (RZ/G1E) - "renesas,r8a77470-usb-dmac" (RZ/G1C) + - "renesas,r8a774a1-usb-dmac" (RZ/G2M) - "renesas,r8a7790-usb-dmac" (R-Car H2) - "renesas,r8a7791-usb-dmac" (R-Car M2-W) - "renesas,r8a7793-usb-dmac" (R-Car M2-N) -- 2.7.4
[PATCH resend] dmaengine: rcar-dmac: Document R8A774A1 bindings
Renesas' RZ/G2M (R8A774A1) SoC has DMA controllers compatible with this driver, therefore document RZ/G2M specific bindings. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das Reviewed-by: Rob Herring Reviewed-by: Simon Horman --- Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt index a5a7c3f..cdf32b2 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt @@ -1,6 +1,6 @@ * Renesas R-Car (RZ/G) DMA Controller Device Tree bindings -Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA +Renesas R-Car (Gen 2/3) and RZ/G SoCs have multiple multi-channel DMA controller instances named DMAC capable of serving multiple clients. Channels can be dedicated to specific clients or shared between a large number of clients. @@ -20,6 +20,7 @@ Required Properties: - "renesas,dmac-r8a7744" (RZ/G1N) - "renesas,dmac-r8a7745" (RZ/G1E) - "renesas,dmac-r8a77470" (RZ/G1C) + - "renesas,dmac-r8a774a1" (RZ/G2M) - "renesas,dmac-r8a7790" (R-Car H2) - "renesas,dmac-r8a7791" (R-Car M2-W) - "renesas,dmac-r8a7792" (R-Car V2H) -- 2.7.4
RE: [PATCH 2/2] arm64: dts: renesas: r8a774a1: Replace clock magic numbers
Thank you Geert for spotting the issue, thank you Simon for fixing.
Cheers,
Fab
> From: Simon Horman
> Sent: 13 November 2018 14:46
> Subject: Re: [PATCH 2/2] arm64: dts: renesas: r8a774a1: Replace clock magic
> numbers
>
> On Tue, Nov 13, 2018 at 09:53:55AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Nov 7, 2018 at 4:24 PM Fabrizio Castro
> > wrote:
> > > Now that include/dt-bindings/clock/r8a774a1-cpg-mssr.h is in Linus'
> > > master branch we can replace clock related magic numbers with the
> > > corresponding labels.
> > >
> > > Signed-off-by: Fabrizio Castro
> >
> > Reviewed-by: Geert Uytterhoeven
> >
> > > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> >
> > > @@ -87,7 +87,7 @@
> > > power-domains = < R8A774A1_PD_CA53_CPU0>;
> > > next-level-cache = <_CA53>;
> > > enable-method = "psci";
> > > - clocks =< CPG_CORE 1>;
> > > + clocks =< CPG_CORE R8A774A1_CLK_Z2>;
> >
> > There are a few pre-existing whitespace issues in the CPU nodes' clocks
> > properties.
>
> Thanks I have fixed that when applying this patch for v4.21.
> The result is as follows:
>
> From: Fabrizio Castro
> Subject: [PATCH] arm64: dts: renesas: r8a774a1: Replace clock magic numbers
>
> Now that include/dt-bindings/clock/r8a774a1-cpg-mssr.h is in Linus'
> master branch we can replace clock related magic numbers with the
> corresponding labels.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Geert Uytterhoeven
> [simon: corrected whitespace]
> Signed-off-by: Simon Horman
> ---
> arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 38
> +++
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> index d549755a4025..20745a8528c5 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> @@ -7,7 +7,7 @@
>
> #include
> #include
> -#include
> +#include
> #include
>
> / {
> @@ -67,7 +67,7 @@
> power-domains = < R8A774A1_PD_CA57_CPU0>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> -clocks = < CPG_CORE 0>;
> +clocks = < CPG_CORE R8A774A1_CLK_Z>;
> };
>
> a57_1: cpu@1 {
> @@ -77,7 +77,7 @@
> power-domains = < R8A774A1_PD_CA57_CPU1>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> -clocks = < CPG_CORE 0>;
> +clocks = < CPG_CORE R8A774A1_CLK_Z>;
> };
>
> a53_0: cpu@100 {
> @@ -87,7 +87,7 @@
> power-domains = < R8A774A1_PD_CA53_CPU0>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> -clocks =< CPG_CORE 1>;
> +clocks = < CPG_CORE R8A774A1_CLK_Z2>;
> };
>
> a53_1: cpu@101 {
> @@ -97,7 +97,7 @@
> power-domains = < R8A774A1_PD_CA53_CPU1>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> -clocks =< CPG_CORE 1>;
> +clocks = < CPG_CORE R8A774A1_CLK_Z2>;
> };
>
> a53_2: cpu@102 {
> @@ -107,7 +107,7 @@
> power-domains = < R8A774A1_PD_CA53_CPU2>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> -clocks =< CPG_CORE 1>;
> +clocks = < CPG_CORE R8A774A1_CLK_Z2>;
> };
>
> a53_3: cpu@103 {
> @@ -117,7 +117,7 @@
> power-domains = < R8A774A1_PD_CA53_CPU3>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> -clocks =< CPG_CORE 1>;
> +clocks = < CPG_CORE R8A774A1_CLK_Z2>;
> };
>
> L2_CA57: cache-controller-0 {
> @@ -515,7 +515,7 @@
> reg = <0 0xe654 0 0x60>;
> interrupts = ;
> clocks = < CPG_MOD 520>,
> - < CPG_CORE 19>,
> + < CPG_CORE R8A774A1_CLK_S3D1>,
> <_clk>;
> clock-names = "fck", "brg_int", "scif_clk";
> dmas = < 0x31>, < 0x30>,
> @@ -533,7 +533,7 @@
> reg = <0 0xe655 0 0x60>;
> interrupts = ;
> clocks = < CPG_MOD 519>,
> - < CPG_CORE 19>,
> + < CPG_CORE R8A774A1_CLK_S3D1>,
> <_clk>;
> clock-names = "fck", "brg_int", "scif_clk";
> dmas = < 0x33>, < 0x32>,
> @@ -551,7 +551,7 @@
> reg = <0 0xe656 0 0x60>;
> interrupts = ;
> clocks = < CPG_MOD 518>,
> - < CPG_CORE 19>,
> +
[PATCH v2 0/3] Add QSPI flash support to iwg23s
Dear All, this series includes all that is necessary to add QSPI flash support to the iwg23s board powered by the RZ/G1C SoC (a.k.a. r8a77470). The second version of this series is to address a comment made by both Simon and Geert on one of the patches. This series applies on top of renesas-devel-20181108v3-v4.20-rc1 Thanks, Fab Fabrizio Castro (3): mtd: spi-nor: Add support for is25lp016d ARM: dts: r8a77470: Add QSPI support ARM: dts: iwg23s-sbc: Add QSPI flash support arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 26 + arch/arm/boot/dts/r8a77470.dtsi | 32 +++ drivers/mtd/spi-nor/spi-nor.c | 2 ++ 3 files changed, 60 insertions(+) -- 2.7.4
[PATCH v2 3/3] ARM: dts: iwg23s-sbc: Add QSPI flash support
This commit adds QSPI flash support to the iwg23s board specific
device tree.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* No Change
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 52f23b8..40b7f98 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -96,6 +96,11 @@
power-source = <1800>;
};
+ qspi0_pins: qspi0 {
+ groups = "qspi0_ctrl", "qspi0_data2";
+ function = "qspi0";
+ };
+
scif1_pins: scif1 {
groups = "scif1_data_b";
function = "scif1";
@@ -114,6 +119,27 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* WARNING - This device contains the bootloader. Handle with care. */
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "issi,is25lp016d", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <13300>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ m25p,fast-read;
+ spi-cpol;
+ spi-cpha;
+ };
+};
+
{
timeout-sec = <60>;
status = "okay";
--
2.7.4
[PATCH v2 1/3] mtd: spi-nor: Add support for is25lp016d
The is25lp016d is found on the iwg23s from iWave, therefore
add driver support for it so that we can upstream board support.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* No change
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5..85d869b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1352,6 +1352,8 @@ static const struct flash_info spi_nor_ids[] = {
{ "is25cd512", INFO(0x7f9d20, 0, 32 * 1024, 2, SECT_4K) },
{ "is25lq040b", INFO(0x9d4013, 0, 64 * 1024, 8,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "is25lp016d", INFO(0x9d6015, 0, 64 * 1024, 32,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "is25lp080d", INFO(0x9d6014, 0, 64 * 1024, 16,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "is25lp128", INFO(0x9d6018, 0, 64 * 1024, 256,
--
2.7.4
[PATCH v2 2/3] ARM: dts: r8a77470: Add QSPI support
Add QSPI[01] support to the RZ/G1C SoC specific device tree.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* Removed aliases
arch/arm/boot/dts/r8a77470.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 5c0e48d..f4e232b 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -460,6 +460,38 @@
status = "disabled";
};
+ qspi0: spi@e6b1 {
+ compatible = "renesas,qspi-r8a77470", "renesas,qspi";
+ reg = <0 0xe6b1 0 0x2c>;
+ interrupts = ;
+ clocks = < CPG_MOD 918>;
+ dmas = < 0x17>, < 0x18>,
+ < 0x17>, < 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 918>;
+ status = "disabled";
+ };
+
+ qspi1: spi@ee20 {
+ compatible = "renesas,qspi-r8a77470", "renesas,qspi";
+ reg = <0 0xee20 0 0x2c>;
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ dmas = < 0xd1>, < 0xd2>,
+ < 0xd1>, < 0xd2>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 917>;
+ status = "disabled";
+ };
+
scif0: serial@e6e6 {
compatible = "renesas,scif-r8a77470",
"renesas,rcar-gen2-scif", "renesas,scif";
--
2.7.4
RE: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
Hi Geert,
Thank you for your feedback!
> Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
>
> Hi Fabrizio,
>
> On Thu, Nov 8, 2018 at 11:31 AM Fabrizio Castro
> wrote:
> > > On Thu, Nov 8, 2018 at 11:22 AM Fabrizio Castro
> > > wrote:
> > > > > From: Simon Horman
> > > > > Sent: 02 November 2018 11:50
> > > > > Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
> > > > >
> > > > > On Thu, Nov 01, 2018 at 12:35:04PM +, Fabrizio Castro wrote:
> > > > > > Add QSPI[01] support to the RZ/G1C SoC specific device tree.
> > > > > >
> > > > > > Signed-off-by: Fabrizio Castro
> > > > > > ---
> > > > > > arch/arm/boot/dts/r8a77470.dtsi | 34
> > > > > > ++
> > > > > > 1 file changed, 34 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/arm/boot/dts/r8a77470.dtsi
> > > > > > b/arch/arm/boot/dts/r8a77470.dtsi
> > > > > > index e6407e5..04a8877 100644
> > > > > > --- a/arch/arm/boot/dts/r8a77470.dtsi
> > > > > > +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > > > > > @@ -20,6 +20,8 @@
> > > > > > i2c2 =
> > > > > > i2c3 =
> > > > > > i2c4 =
> > > > > > +spi0 =
> > > > > > +spi1 =
> > > > > > };
> > > > >
> > > > > Geert can comment but I believe we are moving away from using aliases
> > > > > in this way and that it would be best if the above hunk was dropped
> > > > > from this patch.
> > > > >
> > > > > https://patchwork.kernel.org/patch/10644159/
> > > >
> > > > Geert, what do you want me to do here?
> > >
> > > Please drop the aliases. Thanks!
> >
> > Will do, will send a new version without the additional aliases.
>
> Thanks!
>
> > My understanding is that your personal preference is to only leave debug
> > console and ethernet,
>
> Labeled serial ports and primary Ethernet, so U-Boot knows which MAC address
> property to update.
>
> > shall I also get rid of what was already upstreamed for RZ/G related
> > boards that is not in line
> > with the new policy?
>
> I believe these are all serial ports, using aliases that match the documented
> and/or labeled port names? So they don't have to be removed.
We have also been using aliases for i2c, spi (like in this case), vin, etc.,
for all of the RZ/G boards,
shall I get rid of those?
Cheers,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
Hello Geert,
Thank you for your feedback!
> Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
>
> Hi Fabrizio,
>
> On Thu, Nov 8, 2018 at 11:22 AM Fabrizio Castro
> wrote:
> > > From: Simon Horman
> > > Sent: 02 November 2018 11:50
> > > Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
> > >
> > > On Thu, Nov 01, 2018 at 12:35:04PM +, Fabrizio Castro wrote:
> > > > Add QSPI[01] support to the RZ/G1C SoC specific device tree.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > > ---
> > > > arch/arm/boot/dts/r8a77470.dtsi | 34 ++
> > > > 1 file changed, 34 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/r8a77470.dtsi
> > > > b/arch/arm/boot/dts/r8a77470.dtsi
> > > > index e6407e5..04a8877 100644
> > > > --- a/arch/arm/boot/dts/r8a77470.dtsi
> > > > +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > > > @@ -20,6 +20,8 @@
> > > > i2c2 =
> > > > i2c3 =
> > > > i2c4 =
> > > > +spi0 =
> > > > +spi1 =
> > > > };
> > >
> > > Geert can comment but I believe we are moving away from using aliases
> > > in this way and that it would be best if the above hunk was dropped
> > > from this patch.
> > >
> > > https://patchwork.kernel.org/patch/10644159/
> >
> > Geert, what do you want me to do here?
>
> Please drop the aliases. Thanks!
Will do, will send a new version without the additional aliases.
My understanding is that your personal preference is to only leave debug
console and ethernet,
shall I also get rid of what was already upstreamed for RZ/G related boards
that is not in line
with the new policy?
Thanks,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
Hello Simon,
Thank you for your feedback!
> From: Simon Horman
> Sent: 02 November 2018 11:50
> Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
>
> On Thu, Nov 01, 2018 at 12:35:04PM +, Fabrizio Castro wrote:
> > Add QSPI[01] support to the RZ/G1C SoC specific device tree.
> >
> > Signed-off-by: Fabrizio Castro
> > ---
> > arch/arm/boot/dts/r8a77470.dtsi | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r8a77470.dtsi
> > b/arch/arm/boot/dts/r8a77470.dtsi
> > index e6407e5..04a8877 100644
> > --- a/arch/arm/boot/dts/r8a77470.dtsi
> > +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > @@ -20,6 +20,8 @@
> > i2c2 =
> > i2c3 =
> > i2c4 =
> > +spi0 =
> > +spi1 =
> > };
>
> Geert can comment but I believe we are moving away from using aliases
> in this way and that it would be best if the above hunk was dropped
> from this patch.
>
> https://patchwork.kernel.org/patch/10644159/
Geert, what do you want me to do here?
Thanks,
Fab
>
> The rest of the patch looks fine to me.
>
> >
> > cpus {
> > @@ -460,6 +462,38 @@
> > status = "disabled";
> > };
> >
> > +qspi0: spi@e6b1 {
> > +compatible = "renesas,qspi-r8a77470", "renesas,qspi";
> > +reg = <0 0xe6b1 0 0x2c>;
> > +interrupts = ;
> > +clocks = < CPG_MOD 918>;
> > +dmas = < 0x17>, < 0x18>,
> > + < 0x17>, < 0x18>;
> > +dma-names = "tx", "rx", "tx", "rx";
> > +power-domains = < R8A77470_PD_ALWAYS_ON>;
> > +num-cs = <1>;
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +resets = < 918>;
> > +status = "disabled";
> > +};
> > +
> > +qspi1: spi@ee20 {
> > +compatible = "renesas,qspi-r8a77470", "renesas,qspi";
> > +reg = <0 0xee20 0 0x2c>;
> > +interrupts = ;
> > +clocks = < CPG_MOD 917>;
> > +dmas = < 0xd1>, < 0xd2>,
> > + < 0xd1>, < 0xd2>;
> > +dma-names = "tx", "rx", "tx", "rx";
> > +power-domains = < R8A77470_PD_ALWAYS_ON>;
> > +num-cs = <1>;
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +resets = < 917>;
> > +status = "disabled";
> > +};
> > +
> > scif0: serial@e6e6 {
> > compatible = "renesas,scif-r8a77470",
> > "renesas,rcar-gen2-scif", "renesas,scif";
> > --
> > 2.7.4
> >
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH v2] watchdog: renesas_wdt: don't set divider while watchdog is running
Hi Wolfram,
Thank you for your patch!
> Subject: [PATCH v2] watchdog: renesas_wdt: don't set divider while watchdog
> is running
>
> The datasheet says we must stop the timer before changing the clock
> divider. This can happen when the restart handler is called while the
> watchdog is running.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Fabrizio Castro
> ---
>
> Change since V1: reworded commit message.
>
> I sent V1 back then when it was more a recommendation of the datasheet to do
> it
> like this. But meanwhile the code changed, so we actually need to do it.
>
> drivers/watchdog/renesas_wdt.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index 0d74c3e48979..55c9eb6c6e51 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -74,12 +74,17 @@ static int rwdt_init_timeout(struct watchdog_device *wdev)
> static int rwdt_start(struct watchdog_device *wdev)
> {
> struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
> +u8 val;
>
> pm_runtime_get_sync(wdev->parent);
>
> -rwdt_write(priv, 0, RWTCSRB);
> -rwdt_write(priv, priv->cks, RWTCSRA);
> +/* Stop the timer before we modify any register */
> +val = readb_relaxed(priv->base + RWTCSRA) & ~RWTCSRA_TME;
> +rwdt_write(priv, val, RWTCSRA);
> +
> rwdt_init_timeout(wdev);
> +rwdt_write(priv, priv->cks, RWTCSRA);
> +rwdt_write(priv, 0, RWTCSRB);
>
> while (readb_relaxed(priv->base + RWTCSRA) & RWTCSRA_WRFLG)
> cpu_relax();
> --
> 2.11.0
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
[PATCH 2/2] arm64: dts: renesas: r8a774a1: Replace clock magic numbers
Now that include/dt-bindings/clock/r8a774a1-cpg-mssr.h is in Linus'
master branch we can replace clock related magic numbers with the
corresponding labels.
Signed-off-by: Fabrizio Castro
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 38 +++
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d549755..e0f8bd9 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -7,7 +7,7 @@
#include
#include
-#include
+#include
#include
/ {
@@ -67,7 +67,7 @@
power-domains = < R8A774A1_PD_CA57_CPU0>;
next-level-cache = <_CA57>;
enable-method = "psci";
- clocks = < CPG_CORE 0>;
+ clocks = < CPG_CORE R8A774A1_CLK_Z>;
};
a57_1: cpu@1 {
@@ -77,7 +77,7 @@
power-domains = < R8A774A1_PD_CA57_CPU1>;
next-level-cache = <_CA57>;
enable-method = "psci";
- clocks = < CPG_CORE 0>;
+ clocks = < CPG_CORE R8A774A1_CLK_Z>;
};
a53_0: cpu@100 {
@@ -87,7 +87,7 @@
power-domains = < R8A774A1_PD_CA53_CPU0>;
next-level-cache = <_CA53>;
enable-method = "psci";
- clocks =< CPG_CORE 1>;
+ clocks =< CPG_CORE R8A774A1_CLK_Z2>;
};
a53_1: cpu@101 {
@@ -97,7 +97,7 @@
power-domains = < R8A774A1_PD_CA53_CPU1>;
next-level-cache = <_CA53>;
enable-method = "psci";
- clocks =< CPG_CORE 1>;
+ clocks =< CPG_CORE R8A774A1_CLK_Z2>;
};
a53_2: cpu@102 {
@@ -107,7 +107,7 @@
power-domains = < R8A774A1_PD_CA53_CPU2>;
next-level-cache = <_CA53>;
enable-method = "psci";
- clocks =< CPG_CORE 1>;
+ clocks =< CPG_CORE R8A774A1_CLK_Z2>;
};
a53_3: cpu@103 {
@@ -117,7 +117,7 @@
power-domains = < R8A774A1_PD_CA53_CPU3>;
next-level-cache = <_CA53>;
enable-method = "psci";
- clocks =< CPG_CORE 1>;
+ clocks =< CPG_CORE R8A774A1_CLK_Z2>;
};
L2_CA57: cache-controller-0 {
@@ -515,7 +515,7 @@
reg = <0 0xe654 0 0x60>;
interrupts = ;
clocks = < CPG_MOD 520>,
-< CPG_CORE 19>,
+< CPG_CORE R8A774A1_CLK_S3D1>,
<_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x31>, < 0x30>,
@@ -533,7 +533,7 @@
reg = <0 0xe655 0 0x60>;
interrupts = ;
clocks = < CPG_MOD 519>,
-< CPG_CORE 19>,
+< CPG_CORE R8A774A1_CLK_S3D1>,
<_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x33>, < 0x32>,
@@ -551,7 +551,7 @@
reg = <0 0xe656 0 0x60>;
interrupts = ;
clocks = < CPG_MOD 518>,
-< CPG_CORE 19>,
+< CPG_CORE R8A774A1_CLK_S3D1>,
<_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x35>, < 0x34>,
@@ -569,7 +569,7 @@
reg = <0 0xe66a 0 0x60>;
interrupts = ;
clocks = < CPG_MOD 517>,
-< CPG_CORE 19>,
+< CPG_CORE R8A774A1_CLK_S3D1>,
<_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x37>, < 0x36>;
@@ -586,7 +586,7 @@
reg
[PATCH 1/2] arm64: dts: renesas: r8a774a1: Replace power magic numbers
Now that include/dt-bindings/power/r8a774a1-sysc.h is in Linus'
master branch we can replace power related magic numbers with
the corresponding labels.
Signed-off-by: Fabrizio Castro
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 201 +++---
1 file changed, 101 insertions(+), 100 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 78ac8e3..d549755 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/ {
compatible = "renesas,r8a774a1";
@@ -63,7 +64,7 @@
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x0>;
device_type = "cpu";
- power-domains = < 0>;
+ power-domains = < R8A774A1_PD_CA57_CPU0>;
next-level-cache = <_CA57>;
enable-method = "psci";
clocks = < CPG_CORE 0>;
@@ -73,7 +74,7 @@
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x1>;
device_type = "cpu";
- power-domains = < 1>;
+ power-domains = < R8A774A1_PD_CA57_CPU1>;
next-level-cache = <_CA57>;
enable-method = "psci";
clocks = < CPG_CORE 0>;
@@ -83,7 +84,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x100>;
device_type = "cpu";
- power-domains = < 5>;
+ power-domains = < R8A774A1_PD_CA53_CPU0>;
next-level-cache = <_CA53>;
enable-method = "psci";
clocks =< CPG_CORE 1>;
@@ -93,7 +94,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x101>;
device_type = "cpu";
- power-domains = < 6>;
+ power-domains = < R8A774A1_PD_CA53_CPU1>;
next-level-cache = <_CA53>;
enable-method = "psci";
clocks =< CPG_CORE 1>;
@@ -103,7 +104,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x102>;
device_type = "cpu";
- power-domains = < 7>;
+ power-domains = < R8A774A1_PD_CA53_CPU2>;
next-level-cache = <_CA53>;
enable-method = "psci";
clocks =< CPG_CORE 1>;
@@ -113,7 +114,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x103>;
device_type = "cpu";
- power-domains = < 8>;
+ power-domains = < R8A774A1_PD_CA53_CPU3>;
next-level-cache = <_CA53>;
enable-method = "psci";
clocks =< CPG_CORE 1>;
@@ -121,14 +122,14 @@
L2_CA57: cache-controller-0 {
compatible = "cache";
- power-domains = < 12>;
+ power-domains = < R8A774A1_PD_CA57_SCU>;
cache-unified;
cache-level = <2>;
};
L2_CA53: cache-controller-1 {
compatible = "cache";
- power-domains = < 21>;
+ power-domains = < R8A774A1_PD_CA53_SCU>;
cache-unified;
cache-level = <2>;
};
@@ -195,7 +196,7 @@
"renesas,rcar-gen3-wdt";
reg = <0 0xe602 0 0x0c>;
clocks = < CPG_MOD 402>;
- power-domains = < 32>;
+ power-domains = < R8A774A1_PD_ALWAYS_ON>;
resets = < 402>;
status = "disabled";
};
@@ -211,7 +212,7 @@
#interrupt-cells = <2>;
interrupt-controller;
clocks = <
[PATCH 0/2] Replace magic numbers in RZ/G2M dtsi
Dear All, We were waiting for v4.20 RC1 to be out for replacing clock and power magic numbers within r8a774a1.dtsi as there was a dependency with the corresponding bindings. This series takes care of the magic numbers now that the bindings are available by replacing them with the corresponding macros. Thanks, Fab Fabrizio Castro (2): arm64: dts: renesas: r8a774a1: Replace power magic numbers arm64: dts: renesas: r8a774a1: Replace clock magic numbers arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 239 +++--- 1 file changed, 120 insertions(+), 119 deletions(-) -- 2.7.4
RE: [PATCH] dt-bindings: thermal: rcar-gen3-thermal: All variants use 3 interrupts
> Subject: [PATCH] dt-bindings: thermal: rcar-gen3-thermal: All variants use 3
> interrupts
>
> RZ/G2M also has 3 interrupts routed to the TSC, but the list was not
> updated to reflect this.
>
> Just drop the list, as this is the case for this TSC variant in all
> R-Car Gen3 and RZ/G2 SoCs.
>
> Fixes: be6af481f3b2d508 ("dt-bindings: thermal: rcar-gen3-thermal: Add
> r8a774a1 support")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Fabrizio Castro
> ---
> .../devicetree/bindings/thermal/rcar-gen3-thermal.txt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
> b/Documentation/devicetree/bindings/thermal/rcar-
> gen3-thermal.txt
> index ad9a435afef446f6..b6ab60f6abbf95fd 100644
> --- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
> @@ -21,8 +21,7 @@ Required properties:
>
> Optional properties:
>
> -- interrupts: interrupts routed to the TSC (3 for H3, M3-W, M3-N,
> - and V3H)
> +- interrupts: interrupts routed to the TSC (must be 3).
> - power-domain: Must contain a reference to the power domain. This
>property is mandatory if the thermal sensor instance
>is part of a controllable power domain.
> --
> 2.17.1
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
[PATCH v3 resend] ARM: dts: iwg23s-sbc: Add pinctl support for EtherAVB
From: Biju Das
Adding pinctrl support for EtherAVB interface.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Fabrizio Castro
---
v4.20 RC1 is out, this update rebases the patch on top of
renesas-devel-20181107-v4.20-rc1
Thanks,
Fab
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 18d2263..52f23b8 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -60,6 +60,9 @@
};
{
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
phy-handle = <>;
phy-mode = "gmii";
renesas,no-ether-link;
@@ -82,6 +85,11 @@
};
{
+ avb_pins: avb {
+ groups = "avb_mdio", "avb_gmii_tx_rx";
+ function = "avb";
+ };
+
mmc_pins_uhs: mmc_uhs {
groups = "mmc_data8", "mmc_ctrl";
function = "mmc";
--
2.7.4
[PATCH v2] gpio: rcar: Request GPIO while enabling interrupt
There are cases when the bootloader configures a pin to work
as a function rather than GPIO, and other cases when the pin
is configured as a function at POR.
This commit makes sure the pin is configured as a GPIO the
moment we need it to work as an interrupt.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* Moved gpio_rcar_request call from gpio_rcar_irq_set_type to
rcar_gpio_irq_request_resources
* Added rcar_gpio_irq_release_resources for calling gpio_rcar_free
Comments very welcome!
drivers/gpio/gpio-rcar.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 3c82bb3..c16598b 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -344,6 +344,29 @@ static int gpio_rcar_direction_output(struct gpio_chip
*chip, unsigned offset,
return 0;
}
+static int rcar_gpio_irq_request_resources(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+ unsigned int hwirq = irqd_to_hwirq(d);
+ int err;
+
+ gpio_rcar_direction_input(gc, hwirq);
+ err = gpio_rcar_request(gc, hwirq);
+ if (err)
+ dev_err(>pdev->dev, "Can't request GPIO %u from %s\n", hwirq,
+ gc->label);
+ return err;
+}
+
+static void rcar_gpio_irq_release_resources(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ unsigned int hwirq = irqd_to_hwirq(d);
+
+ gpio_rcar_free(gc, hwirq);
+}
+
struct gpio_rcar_info {
bool has_both_edge_trigger;
};
@@ -491,6 +514,8 @@ static int gpio_rcar_probe(struct platform_device *pdev)
irq_chip->irq_set_type = gpio_rcar_irq_set_type;
irq_chip->irq_set_wake = gpio_rcar_irq_set_wake;
irq_chip->flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_MASK_ON_SUSPEND;
+ irq_chip->irq_request_resources = rcar_gpio_irq_request_resources;
+ irq_chip->irq_release_resources = rcar_gpio_irq_release_resources;
ret = gpiochip_add_data(gpio_chip, p);
if (ret) {
--
2.7.4
RE: [PATCH] gpio: rcar: Request GPIO while enabling interrupt
Hello Geert,
Thank you for your feedback!
> Subject: Re: [PATCH] gpio: rcar: Request GPIO while enabling interrupt
>
> Hi Fabrizio,
>
> On Fri, Nov 2, 2018 at 8:10 PM Fabrizio Castro
> wrote:
> > There are cases when the bootloader configures a pin to work
> > as a function rather than GPIO, and other cases when the pin
> > is configured as a function at POR.
> > This commit makes sure the pin is configured as a GPIO the
> > moment we need it to work as an interrupt.
> >
> > Signed-off-by: Fabrizio Castro
> > ---
> > RFC->PATCH:
> > * Moved gc->request to the bottom of gpio_rcar_irq_set_type
>
> Thanks for the update!
>
> > --- a/drivers/gpio/gpio-rcar.c
> > +++ b/drivers/gpio/gpio-rcar.c
> > @@ -147,6 +147,7 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
> > unsigned int type)
> > struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> > struct gpio_rcar_priv *p = gpiochip_get_data(gc);
> > unsigned int hwirq = irqd_to_hwirq(d);
> > + int err;
> >
> > dev_dbg(>pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
> >
> > @@ -176,6 +177,13 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
> > unsigned int type)
> > default:
> > return -EINVAL;
> > }
> > +
> > + err = gc->request(gc, hwirq);
>
> Call gpio_rcar_request() directly?
Will change
>
> Where should the matching gpio_rcar_free() be called?
That is the question, isn't it?! I have looked around and I couldn't find
anywhere sensible where to
call gpio_rcar_free from in such a way that would be somehow balance
gpio_rcar_request from
gpio_rcar_irq_set_type.
Thank you for suggesting irq_request_resources and irq_release_resources on
IRC, it seems appropriate
to me, and after testing it everything seems to be working fine, I'll send a
new version exploring this
option, and I'll wait for valuable comments.
>
> > + if (err) {
> > + dev_err(>pdev->dev, "Can't request GPIO %d from %s\n",
> > hwirq,
>
> %u for unsigned int
Well spotted, will fix
Thanks,
Fab
>
> > + gc->label);
> > + return err;
> > + }
> > return 0;
> > }
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [RFC] gpio: rcar: Request GPIO before enabling interrupt
Hello Geert,
Thank you for your feedback!
> Subject: Re: [RFC] gpio: rcar: Request GPIO before enabling interrupt
>
> Hi Fabrizio,
>
> On Fri, Oct 26, 2018 at 9:57 PM Fabrizio Castro
> wrote:
> > There are cases when the bootloader configures a pin to work
> > as a function rather than GPIO, and other cases when the pin
> > is configured as a function at POR.
> > This commit makes sure the pin is configured as a GPIO the
> > moment we need it to work as an interrupt.
> >
> > Signed-off-by: Fabrizio Castro
> > ---
> >
> > Dear All,
> >
> > we have got some issues while trying to bring up the interrupt
> > line of the HDMI transmitter on the iwg23s, as GP2_29 is configured
> > as a function when the kernel starts, and therefore setting up the
> > interrupt from the driver won't have the desired effect.
> > This patch makes sure the pinctrl driver sets GP2[29] to GP-2-29
> > before enabling the interrupt, but it doesn't addresses the
> > "direction problem", as in the pin will be a GPIO after calling
> > gc->request, but the direction would be whatever was previously
> > configured. There could be the option of moving the additional
> > code added by this patch to the bottom of function
> > gpio_rcar_irq_set_type, but is that going to behave properly on
> > every SoC this driver is supporting?
> > Is configuring every gpio with direction input while probing
> > something that should be looked into to reduce concerns over
> > switching from function to GPIO?
>
> Configuring everything to input may cause issues where a GPIO is connected
> to the reset line of an external device, and where the bootloader configured
> the
> line to deassert the reset.
I am going to stay away from this then.
Thanks,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
[PATCH v2] watchdog: renesas_wdt: Fix typos
Do not use "," but ";" to separate instructions. Signed-off-by: Fabrizio Castro Reviewed-by: Guenter Roeck --- v1->v2: * Added changelog as suggested by Guenter Roeck drivers/watchdog/renesas_wdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index 0d74c3e..b570962 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -220,8 +220,8 @@ static int rwdt_probe(struct platform_device *pdev) goto out_pm_disable; } - priv->wdev.info = _ident, - priv->wdev.ops = _ops, + priv->wdev.info = _ident; + priv->wdev.ops = _ops; priv->wdev.parent = >dev; priv->wdev.min_timeout = 1; priv->wdev.max_timeout = DIV_BY_CLKS_PER_SEC(priv, 65536); -- 2.7.4
RE: [PATCH] watchdog: renesas_wdt: Fix typos
> Subject: Re: [PATCH] watchdog: renesas_wdt: Fix typos > > On Fri, Nov 02, 2018 at 07:21:11PM +, Fabrizio Castro wrote: > > Do not use "," but ";" to separate instructions. I agree, will send a v2 for this. Thanks, Fab > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Guenter Roeck > > > --- > > drivers/watchdog/renesas_wdt.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c > > index 0d74c3e..b570962 100644 > > --- a/drivers/watchdog/renesas_wdt.c > > +++ b/drivers/watchdog/renesas_wdt.c > > @@ -220,8 +220,8 @@ static int rwdt_probe(struct platform_device *pdev) > > goto out_pm_disable; > > } > > > > -priv->wdev.info = _ident, > > -priv->wdev.ops = _ops, > > +priv->wdev.info = _ident; > > +priv->wdev.ops = _ops; > > priv->wdev.parent = >dev; > > priv->wdev.min_timeout = 1; > > priv->wdev.max_timeout = DIV_BY_CLKS_PER_SEC(priv, 65536); > > -- > > 2.7.4 > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
[PATCH] watchdog: renesas_wdt: Fix typos
Signed-off-by: Fabrizio Castro --- drivers/watchdog/renesas_wdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index 0d74c3e..b570962 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -220,8 +220,8 @@ static int rwdt_probe(struct platform_device *pdev) goto out_pm_disable; } - priv->wdev.info = _ident, - priv->wdev.ops = _ops, + priv->wdev.info = _ident; + priv->wdev.ops = _ops; priv->wdev.parent = >dev; priv->wdev.min_timeout = 1; priv->wdev.max_timeout = DIV_BY_CLKS_PER_SEC(priv, 65536); -- 2.7.4
[PATCH] gpio: rcar: Request GPIO while enabling interrupt
There are cases when the bootloader configures a pin to work
as a function rather than GPIO, and other cases when the pin
is configured as a function at POR.
This commit makes sure the pin is configured as a GPIO the
moment we need it to work as an interrupt.
Signed-off-by: Fabrizio Castro
---
RFC->PATCH:
* Moved gc->request to the bottom of gpio_rcar_irq_set_type
drivers/gpio/gpio-rcar.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 3c82bb3..5b96ee3 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -147,6 +147,7 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
unsigned int type)
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct gpio_rcar_priv *p = gpiochip_get_data(gc);
unsigned int hwirq = irqd_to_hwirq(d);
+ int err;
dev_dbg(>pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
@@ -176,6 +177,13 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
unsigned int type)
default:
return -EINVAL;
}
+
+ err = gc->request(gc, hwirq);
+ if (err) {
+ dev_err(>pdev->dev, "Can't request GPIO %d from %s\n", hwirq,
+ gc->label);
+ return err;
+ }
return 0;
}
--
2.7.4
RE: [RFC] gpio: rcar: Request GPIO before enabling interrupt
Hello Linus, Thank you for your feedback! I am sorry for the delay of my answer, I was hoping others would jump in the discussion as well. > > + err = gc->request(gc, hwirq); > > This is done in some drivers when what you want is exactly > the work carried out by that callback. But can't you just call > gpio_rcar_request() directly in this case so it is clear that > the driver is meddling with the internal state of the hardware > and not really intending to loop out into the external > API or external callbacks? gpio_rcar_request is static unfortunately, maybe I should export the symbol? > > You're not on one of these platforms that prefer setting up > the pin as GPIO using a pin control hog in the device tree? My personal preference would be to deal with this from within irqchip, as when you hook up a gpio as interrupt from the DT the kernel should do everything that's necessary to make it happen, but that is just a personal opinion. Anyway, I did give gpio-hog a try and it works for me. > > Sadly there is sometimes more than one way to do things > around here :/ so true > > Geert will know what is best. Yeah, I am really keen in hearing from him about this, in the meantime I went through a bunch of manuals, and moving the gpio request to the bottom of gpio_rcar_irq_set_type seems to be okay for RCar devices in general, but Geert knows definitely better. I'll send this other option out as a patch this time, hoping to get more feedbacks about the topic. Again, thank you. Fab > > Yours, > Linus Walleij Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
[PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
Add QSPI[01] support to the RZ/G1C SoC specific device tree.
Signed-off-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a77470.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index e6407e5..04a8877 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -20,6 +20,8 @@
i2c2 =
i2c3 =
i2c4 =
+ spi0 =
+ spi1 =
};
cpus {
@@ -460,6 +462,38 @@
status = "disabled";
};
+ qspi0: spi@e6b1 {
+ compatible = "renesas,qspi-r8a77470", "renesas,qspi";
+ reg = <0 0xe6b1 0 0x2c>;
+ interrupts = ;
+ clocks = < CPG_MOD 918>;
+ dmas = < 0x17>, < 0x18>,
+ < 0x17>, < 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 918>;
+ status = "disabled";
+ };
+
+ qspi1: spi@ee20 {
+ compatible = "renesas,qspi-r8a77470", "renesas,qspi";
+ reg = <0 0xee20 0 0x2c>;
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ dmas = < 0xd1>, < 0xd2>,
+ < 0xd1>, < 0xd2>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 917>;
+ status = "disabled";
+ };
+
scif0: serial@e6e6 {
compatible = "renesas,scif-r8a77470",
"renesas,rcar-gen2-scif", "renesas,scif";
--
2.7.4
[PATCH 1/4] spi: rspi: Add r8a77470 to the compatible list
Add r8a77470 to the list of examples with soctypes. No driver change is needed as "renesas,qspi" will activate the right code within the corresponding driver. Signed-off-by: Fabrizio Castro --- As per Mark Brown's comment on patch "dt-bindings: spi: rspi: Add r8a7744 to the compatible list", this patch doesn't come with the "dt-bindings" prefix in the title. Documentation/devicetree/bindings/spi/spi-rspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt index fc97ad6..421722b 100644 --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt @@ -15,6 +15,7 @@ Required properties: - "renesas,qspi-r8a7743" (RZ/G1M) - "renesas,qspi-r8a7744" (RZ/G1N) - "renesas,qspi-r8a7745" (RZ/G1E) + - "renesas,qspi-r8a77470" (RZ/G1C) - "renesas,qspi-r8a7790" (R-Car H2) - "renesas,qspi-r8a7791" (R-Car M2-W) - "renesas,qspi-r8a7792" (R-Car V2H) -- 2.7.4
[PATCH 2/4] mtd: spi-nor: Add support for is25lp016d
The is25lp016d is found on the iwg23s from iWave, therefore
add driver support for it so that we can upstream board support.
Signed-off-by: Fabrizio Castro
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5..85d869b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1352,6 +1352,8 @@ static const struct flash_info spi_nor_ids[] = {
{ "is25cd512", INFO(0x7f9d20, 0, 32 * 1024, 2, SECT_4K) },
{ "is25lq040b", INFO(0x9d4013, 0, 64 * 1024, 8,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "is25lp016d", INFO(0x9d6015, 0, 64 * 1024, 32,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "is25lp080d", INFO(0x9d6014, 0, 64 * 1024, 16,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "is25lp128", INFO(0x9d6018, 0, 64 * 1024, 256,
--
2.7.4
[PATCH 4/4] ARM: dts: iwg23s-sbc: Add QSPI flash support
This commit adds QSPI flash support to the iwg23s board specific
device tree.
Signed-off-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 18d2263..5245a1e 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -88,6 +88,11 @@
power-source = <1800>;
};
+ qspi0_pins: qspi0 {
+ groups = "qspi0_ctrl", "qspi0_data2";
+ function = "qspi0";
+ };
+
scif1_pins: scif1 {
groups = "scif1_data_b";
function = "scif1";
@@ -106,6 +111,27 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* WARNING - This device contains the bootloader. Handle with care. */
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "issi,is25lp016d", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <13300>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ m25p,fast-read;
+ spi-cpol;
+ spi-cpha;
+ };
+};
+
{
timeout-sec = <60>;
status = "okay";
--
2.7.4
[PATCH 0/4] Add QSPI flash support to iwg23s
Dear All, this series includes all that is necessary to add QSPI flash support to the iwg23s board powered by the RZ/G1C SoC (a.k.a. r8a77470). Thanks, Fab Fabrizio Castro (4): spi: rspi: Add r8a77470 to the compatible list mtd: spi-nor: Add support for is25lp016d ARM: dts: r8a77470: Add QSPI support ARM: dts: iwg23s-sbc: Add QSPI flash support Documentation/devicetree/bindings/spi/spi-rspi.txt | 1 + arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 26 + arch/arm/boot/dts/r8a77470.dtsi| 34 ++ drivers/mtd/spi-nor/spi-nor.c | 2 ++ 4 files changed, 63 insertions(+) -- 2.7.4
[RFC] gpio: rcar: Request GPIO before enabling interrupt
There are cases when the bootloader configures a pin to work
as a function rather than GPIO, and other cases when the pin
is configured as a function at POR.
This commit makes sure the pin is configured as a GPIO the
moment we need it to work as an interrupt.
Signed-off-by: Fabrizio Castro
---
Dear All,
we have got some issues while trying to bring up the interrupt
line of the HDMI transmitter on the iwg23s, as GP2_29 is configured
as a function when the kernel starts, and therefore setting up the
interrupt from the driver won't have the desired effect.
This patch makes sure the pinctrl driver sets GP2[29] to GP-2-29
before enabling the interrupt, but it doesn't addresses the
"direction problem", as in the pin will be a GPIO after calling
gc->request, but the direction would be whatever was previously
configured. There could be the option of moving the additional
code added by this patch to the bottom of function
gpio_rcar_irq_set_type, but is that going to behave properly on
every SoC this driver is supporting?
Is configuring every gpio with direction input while probing
something that should be looked into to reduce concerns over
switching from function to GPIO?
Comments very welcome!
Thanks,
Fab
drivers/gpio/gpio-rcar.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 3c82bb3..8c69431 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -147,6 +147,14 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
unsigned int type)
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct gpio_rcar_priv *p = gpiochip_get_data(gc);
unsigned int hwirq = irqd_to_hwirq(d);
+ int err;
+
+ err = gc->request(gc, hwirq);
+ if (err) {
+ dev_err(>pdev->dev, "Can't request GPIO %d from %s\n", hwirq,
+ gc->label);
+ return err;
+ }
dev_dbg(>pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
--
2.7.4
RE: [PATCH] dt-bindings: watchdog: renesas-wdt: Document r8a77470 support
> Subject: [PATCH] dt-bindings: watchdog: renesas-wdt: Document r8a77470 support > > RZ/G1C (R8A77470) watchdog implementation is compatible with R-Car > Gen2, therefore add relevant documentation. > > Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro > --- > This patch is tested against linux-next > --- > Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt > b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt > index a8ee29f..a47bdea 100644 > --- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt > @@ -8,6 +8,7 @@ Required properties: > - "renesas,r8a7743-wdt" (RZ/G1M) > - "renesas,r8a7744-wdt" (RZ/G1N) > - "renesas,r8a7745-wdt" (RZ/G1E) > + - "renesas,r8a77470-wdt" (RZ/G1C) > - "renesas,r8a774a1-wdt" (RZ/G2M) > - "renesas,r8a7790-wdt" (R-Car H2) > - "renesas,r8a7791-wdt" (R-Car M2-W) > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT support
> Subject: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT > support > > Document SoC specific compatible strings for r8a77470. No driver change > is needed as the fallback strings will activate the right code. > > Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro > --- > This patch is tested against linux-next > --- > Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt > b/Documentation/devicetree/bindings/timer/renesas,cmt.txt > index 6de27b6..eb602c5 100644 > --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt > +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt > @@ -28,6 +28,8 @@ Required Properties: > - "renesas,r8a7744-cmt1" for the 48-bit CMT1 device included in r8a7744. > - "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745. > - "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745. > +- "renesas,r8a77470-cmt0" for the 32-bit CMT0 device included in > r8a77470. > +- "renesas,r8a77470-cmt1" for the 48-bit CMT1 device included in > r8a77470. > - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790. > - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790. > - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791. > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable cmt0
> Subject: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable cmt0
>
> This patch enables cmt0 support on the iWave iwg23s sbc.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> index 518b0c0..6277571 100644
> --- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> +++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> @@ -73,6 +73,10 @@
> };
> };
>
> + {
> +status = "okay";
> +};
> +
> {
> status = "okay";
> };
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH] arm64: dts: renesas: r8a7796: Add CMT device nodes
> Subject: [PATCH] arm64: dts: renesas: r8a7796: Add CMT device nodes
>
> This patch adds CMT{0|1|2|3} device nodes for r8a7796 SoC.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> This patch is tested against renesas-dev
>
> I have executed on inconsistency-check, nanosleep and clocksource_switch
> selftests on this arm64 SoC. The inconsistency-check and nanosleep tests
> are working fine.The clocksource_switch asynchronous test is failing due
> to inconsistency-check failure on "arch_sys_counter".
>
> But if i skip the clocksource_switching of "arch_sys_counter", the
> asynchronous test is passing for CMT0/1/2/3 timer.
>
> Has any one noticed this issue?
> ---
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 70
>
> 1 file changed, 70 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> index 1ec6aaa..d62febd0 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -401,6 +401,76 @@
> reg = <0 0xe606 0 0x50c>;
> };
>
> +cmt0: timer@e60f {
> +compatible = "renesas,r8a7796-cmt0",
> + "renesas,rcar-gen3-cmt0";
> +reg = <0 0xe60f 0 0x1004>;
> +interrupts = ,
> + ;
> +clocks = < CPG_MOD 303>;
> +clock-names = "fck";
> +power-domains = < R8A7796_PD_ALWAYS_ON>;
> +resets = < 303>;
> +status = "disabled";
> +};
> +
> +cmt1: timer@e613 {
> +compatible = "renesas,r8a7796-cmt1",
> + "renesas,rcar-gen3-cmt1";
> +reg = <0 0xe613 0 0x1004>;
> +interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> +clocks = < CPG_MOD 302>;
> +clock-names = "fck";
> +power-domains = < R8A7796_PD_ALWAYS_ON>;
> +resets = < 302>;
> +status = "disabled";
> +};
> +
> +cmt2: timer@e614 {
> +compatible = "renesas,r8a7796-cmt1",
> + "renesas,rcar-gen3-cmt1";
> +reg = <0 0xe614 0 0x1004>;
> +interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> +clocks = < CPG_MOD 301>;
> +clock-names = "fck";
> +power-domains = < R8A7796_PD_ALWAYS_ON>;
> +resets = < 301>;
> +status = "disabled";
> +};
> +
> +cmt3: timer@e6148000 {
> +compatible = "renesas,r8a7796-cmt1",
> + "renesas,rcar-gen3-cmt1";
> +reg = <0 0xe6148000 0 0x1004>;
> +interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> +clocks = < CPG_MOD 300>;
> +clock-names = "fck";
> +power-domains = < R8A7796_PD_ALWAYS_ON>;
> +resets = < 300>;
> +status = "disabled";
> +};
> +
> cpg: clock-controller@e615 {
> compatible = "renesas,r8a7796-cpg-mssr";
> reg = <0 0xe615 0 0x1000>;
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/2] ARM: dts: r8a77470: Add CMT SoC specific support
> Subject: [PATCH 1/2] ARM: dts: r8a77470: Add CMT SoC specific support
>
> Add CMT[01] support to r8a77470 SoC DT.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> This patch is tested against renesas-dev
> ---
> arch/arm/boot/dts/r8a77470.dtsi | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
> index 74ca5d3..e40f5a9 100644
> --- a/arch/arm/boot/dts/r8a77470.dtsi
> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> @@ -710,6 +710,38 @@
> compatible = "renesas,prr";
> reg = <0 0xff44 0 4>;
> };
> +
> +cmt0: timer@ffca {
> +compatible = "renesas,r8a77470-cmt0",
> + "renesas,rcar-gen2-cmt0";
> +reg = <0 0xffca 0 0x1004>;
> +interrupts = ,
> + ;
> +clocks = < CPG_MOD 124>;
> +clock-names = "fck";
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 124>;
> +status = "disabled";
> +};
> +
> +cmt1: timer@e613 {
> +compatible = "renesas,r8a77470-cmt1",
> + "renesas,rcar-gen2-cmt1";
> +reg = <0 0xe613 0 0x1004>;
> +interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> +clocks = < CPG_MOD 329>;
> +clock-names = "fck";
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 329>;
> +status = "disabled";
> +};
> };
>
> timer {
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 2/2] ARM: dts: r8a77470: Add USB-DMAC device nodes
> Subject: [PATCH 2/2] ARM: dts: r8a77470: Add USB-DMAC device nodes
>
> This patch adds USB DMAC nodes.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> This patch depend upon the below patch.
>
> https://patchwork.kernel.org/patch/10655861/
> ---
> arch/arm/boot/dts/r8a77470.dtsi | 56
> +
> 1 file changed, 56 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
> index 935b82b..eec71dd 100644
> --- a/arch/arm/boot/dts/r8a77470.dtsi
> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> @@ -353,6 +353,62 @@
> };
> };
>
> +usb_dmac00: dma-controller@e65a {
> +compatible = "renesas,r8a77470-usb-dmac",
> + "renesas,usb-dmac";
> +reg = <0 0xe65a 0 0x100>;
> +interrupts = + GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
> +interrupt-names = "ch0", "ch1";
> +clocks = < CPG_MOD 330>;
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 330>;
> +#dma-cells = <1>;
> +dma-channels = <2>;
> +};
> +
> +usb_dmac10: dma-controller@e65b {
> +compatible = "renesas,r8a77470-usb-dmac",
> + "renesas,usb-dmac";
> +reg = <0 0xe65b 0 0x100>;
> +interrupts = + GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> +interrupt-names = "ch0", "ch1";
> +clocks = < CPG_MOD 331>;
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 331>;
> +#dma-cells = <1>;
> +dma-channels = <2>;
> +};
> +
> +usb_dmac01: dma-controller@e65a8000 {
> +compatible = "renesas,r8a77470-usb-dmac",
> + "renesas,usb-dmac";
> +reg = <0 0xe65a8000 0 0x100>;
> +interrupts = + GIC_SPI 293 IRQ_TYPE_LEVEL_HIGH>;
> +interrupt-names = "ch0", "ch1";
> +clocks = < CPG_MOD 326>;
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 326>;
> +#dma-cells = <1>;
> +dma-channels = <2>;
> +};
> +
> +usb_dmac11: dma-controller@e65b8000 {
> +compatible = "renesas,r8a77470-usb-dmac",
> + "renesas,usb-dmac";
> +reg = <0 0xe65b8000 0 0x100>;
> +interrupts = + GIC_SPI 292 IRQ_TYPE_LEVEL_HIGH>;
> +interrupt-names = "ch0", "ch1";
> +clocks = < CPG_MOD 327>;
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 327>;
> +#dma-cells = <1>;
> +dma-channels = <2>;
> +};
> +
> dmac0: dma-controller@e670 {
> compatible = "renesas,dmac-r8a77470",
> "renesas,rcar-dmac";
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a7796 CMT support
> Subject: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a7796 CMT > support > > Document SoC specific bindings for R-Car M3-W (r8a7796) SoC. > > Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro > --- > This patch is tested against linu-next > --- > Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt > b/Documentation/devicetree/bindings/timer/renesas,cmt.txt > index 3399267..6de27b6 100644 > --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt > +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt > @@ -36,6 +36,8 @@ Required Properties: > - "renesas,r8a7793-cmt1" for the 48-bit CMT1 device included in r8a7793. > - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794. > - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794. > +- "renesas,r8a7796-cmt0" for the 32-bit CMT0 device included in r8a7796. > +- "renesas,r8a7796-cmt1" for the 48-bit CMT1 device included in r8a7796. > - "renesas,r8a77970-cmt0" for the 32-bit CMT0 device included in > r8a77970. > - "renesas,r8a77970-cmt1" for the 48-bit CMT1 device included in > r8a77970. > - "renesas,r8a77980-cmt0" for the 32-bit CMT0 device included in > r8a77980. > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 1/2] dt-bindings: dmaengine: usb-dmac: Add binding for r8a77470
> Subject: [PATCH 1/2] dt-bindings: dmaengine: usb-dmac: Add binding for > r8a77470 > > This patch adds usb high-speed dmac binding for r8a77470 (RZ/G1C) SoC. > > Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro > --- > This patch tested against linux-next. > --- > Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > index 1743017..a1e7b814 100644 > --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > @@ -6,6 +6,7 @@ Required Properties: >- "renesas,r8a7743-usb-dmac" (RZ/G1M) >- "renesas,r8a7744-usb-dmac" (RZ/G1N) >- "renesas,r8a7745-usb-dmac" (RZ/G1E) > + - "renesas,r8a77470-usb-dmac" (RZ/G1C) >- "renesas,r8a7790-usb-dmac" (R-Car H2) >- "renesas,r8a7791-usb-dmac" (R-Car M2-W) >- "renesas,r8a7793-usb-dmac" (R-Car M2-N) > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 6/7] ARM: dts: iwg23s-sbc: Enable USB USB2.0 Host
> Subject: [PATCH 6/7] ARM: dts: iwg23s-sbc: Enable USB USB2.0 Host
>
> Enable USB2.0 host on USB port1 of the iwg23s sbc.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> This patch is tested against renesas-devel.
> ---
> arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> index 157af7c..7aa7993e 100644
> --- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> +++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> @@ -73,10 +73,18 @@
> };
> };
>
> + {
> +status = "okay";
> +};
> +
> _clk {
> clock-frequency = <2000>;
> };
>
> + {
> +status = "okay";
> +};
> +
> {
> mmc_pins_uhs: mmc_uhs {
> groups = "mmc_data8", "mmc_ctrl";
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 7/7] ARM: shmobile: Enable USB [EO]HCI HCD PLATFORM support in shmobile_defconfig
> Subject: [PATCH 7/7] ARM: shmobile: Enable USB [EO]HCI HCD PLATFORM support > in shmobile_defconfig > > The USB [EO]HCI controller on RZ/G1C SoC doesn't have PCI bridge like > other R-Car Gen2 devices. So enable generic USB [EO]HCI HCD PLATFORM > support in shmobile_defconfig. > > Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro > --- > arch/arm/configs/shmobile_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/configs/shmobile_defconfig > b/arch/arm/configs/shmobile_defconfig > index f8faf37..b0db52c 100644 > --- a/arch/arm/configs/shmobile_defconfig > +++ b/arch/arm/configs/shmobile_defconfig > @@ -163,7 +163,9 @@ CONFIG_USB=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_PLATFORM=y > CONFIG_USB_EHCI_HCD=y > +CONFIG_USB_EHCI_HCD_PLATFORM=y > CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_OHCI_HCD_PLATFORM=y > CONFIG_USB_R8A66597_HCD=y > CONFIG_USB_RENESAS_USBHS=y > CONFIG_USB_GADGET=y > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 4/7] ARM: dts: iwg23s-sbc: Enable USB Phy[01]
> Subject: [PATCH 4/7] ARM: dts: iwg23s-sbc: Enable USB Phy[01]
>
> Enable USB phy[01] on iWave iwg23s sbc based on RZ/G1C SoC.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> This patch is tested against renesas devel.
> ---
> arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> index e5cfb50..157af7c 100644
> --- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> +++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> @@ -100,6 +100,16 @@
> function = "sdhi2";
> power-source = <1800>;
> };
> +
> +usb0_pins: usb0 {
> +groups = "usb0";
> +function = "usb0";
> +};
> +
> +usb1_pins: usb1 {
> +groups = "usb1";
> +function = "usb1";
> +};
> };
>
> {
> @@ -134,3 +144,17 @@
> sd-uhs-sdr50;
> status = "okay";
> };
> +
> + {
> +pinctrl-0 = <_pins>;
> +pinctrl-names = "default";
> +
> +status = "okay";
> +};
> +
> + {
> +pinctrl-0 = <_pins>;
> +pinctrl-names = "default";
> +
> +status = "okay";
> +};
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 5/7] ARM: dts: r8a77470: Add USB2.0 Host (EHCI/OHCI) device nodes
> Subject: [PATCH 5/7] ARM: dts: r8a77470: Add USB2.0 Host (EHCI/OHCI) device
> nodes
>
> Define the r8a77470 generic part of the USB2.0 Host Controller device
> nodes (ehci[01]/ohci[01]).
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> This patch is tested against renesas devel.
> ---
> arch/arm/boot/dts/r8a77470.dtsi | 50
> +
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
> index 7d20c3b..935b82b 100644
> --- a/arch/arm/boot/dts/r8a77470.dtsi
> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> @@ -528,6 +528,56 @@
> status = "disabled";
> };
>
> +ohci0: usb@ee08 {
> +compatible = "generic-ohci";
> +reg = <0 0xee08 0 0x100>;
> +interrupts = ;
> +clocks = < CPG_MOD 703>;
> +phys = < 0>;
> +phy-names = "usb";
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 703>;
> +status = "disabled";
> +};
> +
> +ohci1: usb@ee0c {
> +compatible = "generic-ohci";
> +reg = <0 0xee0c 0 0x100>;
> +interrupts = ;
> +clocks = < CPG_MOD 705>;
> +phys = < 0>, < 1>;
> +phy-names = "usb";
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 705>;
> +status = "disabled";
> +};
> +
> +ehci0: usb@ee080100 {
> +compatible = "generic-ehci";
> +reg = <0 0xee080100 0 0x100>;
> +interrupts = ;
> +clocks = < CPG_MOD 703>;
> +phys = < 0>;
> +phy-names = "usb";
> +companion = <>;
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 703>;
> +status = "disabled";
> +};
> +
> +ehci1: usb@ee0c0100 {
> +compatible = "generic-ehci";
> +reg = <0 0xee0c0100 0 0x100>;
> +interrupts = ;
> +clocks = < CPG_MOD 705>;
> +phys = < 0>, < 1>;
> +phy-names = "usb";
> +companion = <>;
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 705>;
> +status = "disabled";
> +};
> +
> sdhi0: sd@ee10 {
> compatible = "renesas,sdhi-r8a77470",
> "renesas,rcar-gen2-sdhi";
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 3/7] ARM: dts: r8a77470: Add USB PHY DT support
> Subject: [PATCH 3/7] ARM: dts: r8a77470: Add USB PHY DT support
>
> Define the r8a77470 generic part of the USB PHY device node.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> This patch is tested against renesas-devel
> ---
> arch/arm/boot/dts/r8a77470.dtsi | 38 ++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
> index 6ac7f46..7d20c3b 100644
> --- a/arch/arm/boot/dts/r8a77470.dtsi
> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> @@ -315,6 +315,44 @@
> status = "disabled";
> };
>
> +usbphy0: usb-phy@e6590100 {
> +compatible = "renesas,usb-phy-r8a77470",
> + "renesas,rcar-gen2-usb-phy";
> +reg = <0 0xe6590100 0 0x100>,
> +<0 0xee080200 0 0x118>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +clocks = < CPG_MOD 704>, < CPG_MOD 703>;
> +clock-names = "usbhs", "usb20_host";
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 704>, < 703>;
> +status = "disabled";
> +
> +usb0: usb-channel@0 {
> +reg = <0>;
> +#phy-cells = <1>;
> +};
> +};
> +
> +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>;
> +};
> +};
> +
> dmac0: dma-controller@e670 {
> compatible = "renesas,dmac-r8a77470",
> "renesas,rcar-dmac";
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/7] dt-bindings: phy: rcar-gen2: Add r8a77470 support
> Subject: [PATCH 1/7] dt-bindings: phy: rcar-gen2: Add r8a77470 support
>
> Add USB PHY support for r8a77470 SoC. Renesas RZ/G1C (R8A77470)
> USB PHY is similar to the R-Car Gen2 family, but has the below
> features compared to other RZ/G1 and R-Car Gen2/3 SoCs
>
> It has a shared pll reset for usbphy0/usbphy1 and this register
> reside in usbphy0 block
>
> Each USB2.0 host needs to deassert the pll reset of usbphy0 block.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> .../devicetree/bindings/phy/rcar-gen2-phy.txt | 64
> +++---
> 1 file changed, 55 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> index eeb9e18..0a59971 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> @@ -6,6 +6,7 @@ This file provides information on what the device node for
> the R-Car generation
> Required properties:
> - compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743
> SoC.
>"renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC.
> + "renesas,usb-phy-r8a77470" if the device is a part of R8A77470 SoC.
>"renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
>"renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
>"renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC.
> @@ -23,13 +24,23 @@ Required properties:
> - clocks: clock phandle and specifier pair.
> - clock-names: string, clock input name, must be "usbhs".
>
> +Optional properties (r8a77470 SoC Only):
> +To use a USB channel as USB 2.0 Host, the device tree node should set below
> +optional properties. This is because USB2.0 Host needs to deassert pll reset,
> +apart from initializing interrupt enable, OVC detection timer and suspend/
> +resume timer register.
> +
> +- reg: offset and length of the partial USB2.0 Host register block.
> +- clocks: clock phandle and specifier pair for usb2.0 host.
> +- clk-names: string, clock input name, must be "usb20_host".
> +
> The USB PHY device tree node should have the subnodes corresponding to the
> USB
> channels. These subnodes must contain the following properties:
> - reg: the USB controller selector; see the table below for the values.
> - #phy-cells: see phy-bindings.txt in the same directory, must be <1>.
>
> The phandle's argument in the PHY specifier is the USB controller selector
> for
> -the USB channel; see the selector meanings below:
> +the USB channel other than r8a77470 SoC; see the selector meanings below:
>
> +---+---+---+
> |\ Selector | | |
> @@ -40,22 +51,57 @@ the USB channel; see the selector meanings below:
> | 2 | PCI EHCI/OHCI | xHCI |
> +---+---+---+
>
> +For r8a77470 SoC see the selector meaning below:
> +
> ++---+---+---+
> +|\ Selector | | |
> ++ - + 0 | 1 |
> +| Channel \| | |
> ++---+---+---+
> +| 0 | EHCI/OHCI | HS-USB|
> ++---+---+---+
> +
> Example (Lager board):
>
> -usb-phy@e6590100 {
> -compatible = "renesas,usb-phy-r8a7790", "renesas,rcar-gen2-usb-phy";
> +usbphy: usb-phy@e6590100 {
> +compatible = "renesas,usb-phy-r8a7790",
> + "renesas,rcar-gen2-usb-phy";
> reg = <0 0xe6590100 0 0x100>;
> #address-cells = <1>;
> #size-cells = <0>;
> -clocks = <_clks R8A7790_CLK_HSUSB>;
> +clocks = < CPG_MOD 704>;
> clock-names = "usbhs";
> +power-domains = < R8A7790_PD_ALWAYS_ON>;
> +resets = < 704>;
> +status = "disabled";
>
> -usb-channel@0 {
> -reg = <0>;
> -#phy-cells = <1>;
> +usb0: usb-channel@0 {
> +reg = <0>;
> +#phy-cells = <1>;
> +};
> +usb2: usb-channel@2 {
> +reg = <2>;
> +#phy-cells = <1>;
> };
> -usb-channel@2 {
> -reg = <2>;
> +};
> +
> +Example (iWave RZ/G1C SBC):
> +
> +usbphy0: usb-phy0@e6590100 {
> +compatible = "renesas,usb-phy-r8a77470",
> + "renesas,rcar-gen2-usb-phy";
> +reg = <0 0xe6590100 0 0x100>,
> + <0 0xee080200 0 0x118>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +clocks = < CPG_MOD 704>, < CPG_MOD 703>;
> +clock-names = "usbhs", "usb20_host";
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 704>, < 703>;
> +status = "disabled";
> +
> +usb0: usb-channel@0 {
> +reg = <0>;
> #phy-cells = <1>;
> };
> };
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/2] ARM: dts: r8a77470: Add watchdog support to SoC dtsi
> Subject: [PATCH 1/2] ARM: dts: r8a77470: Add watchdog support to SoC dtsi
>
> This patch adds watchdog support to the r8a77470 SoC dtsi.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> This patch tested against renesas-dev
> ---
> arch/arm/boot/dts/r8a77470.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
> index e40f5a9..872ad3a 100644
> --- a/arch/arm/boot/dts/r8a77470.dtsi
> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> @@ -196,6 +196,16 @@
> reg = <0 0xe616 0 0x100>;
> };
>
> +rwdt: watchdog@e602 {
> +compatible = "renesas,r8a77470-wdt",
> + "renesas,rcar-gen2-wdt";
> +reg = <0 0xe602 0 0x0c>;
> +clocks = < CPG_MOD 402>;
> +power-domains = < R8A77470_PD_ALWAYS_ON>;
> +resets = < 402>;
> +status = "disabled";
> +};
> +
> sysc: system-controller@e618 {
> compatible = "renesas,r8a77470-sysc";
> reg = <0 0xe618 0 0x200>;
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable watchdog support
> Subject: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable watchdog support
>
> This patch enables watchdog support on the iWave iwg23s sbc.
>
> Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
> ---
> arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> index 6277571..bc953fa 100644
> --- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> +++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> @@ -128,6 +128,11 @@
> };
> };
>
> + {
> +timeout-sec = <60>;
> +status = "okay";
> +};
> +
> {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: Delay between stop condition and start condition
> Subject: Re: Delay between stop condition and start condition > > > > The passthrough mode is not default, it gets activated by the driver so that > > drm_get_edid can then fetch the EDID. One other nasty thing is that to end > > the conversation > > with the monitor you are supposed to write 0x00 to register 0x1a of the > > HDMI transmitter, > > which means the SoC puts address 0x39 on the bus, but the HDMI transmitter > > lets that > > through, the monitor NACKs the address (because its address is 0x50), and > > from that > > moment on the control is back with the HDMI transmitter. > > Unfortunately I don't have any other slave on the same bus, but I wonder > > what happens > > if someone else tries to use the same bus while the pass through mode is > > operating... > > Wouldn't all this really speak for an i2c gate? Do all enablement stuff > in select(), all disablement stuff in deselect(), and make sure > deselect() is called after every transfer. That would mean the > passthrough is only active when the EDID eeprom is accessed. Would that > work? Given the above, it looks quite sane to do it like that in order > to avoid side-effects of the open passthrough. It sounds like an i2c gate could fit the purpose. I'll give it a shot! Thank you All! Fab Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: Delay between stop condition and start condition
> Subject: Re: Delay between stop condition and start condition > > > > be fixed in its driver. It probably could be a generic driver, or? > > Wishful thinking. Setting the passthrough mode is probably not default, > so it is device specific. The passthrough mode is not default, it gets activated by the driver so that drm_get_edid can then fetch the EDID. One other nasty thing is that to end the conversation with the monitor you are supposed to write 0x00 to register 0x1a of the HDMI transmitter, which means the SoC puts address 0x39 on the bus, but the HDMI transmitter lets that through, the monitor NACKs the address (because its address is 0x50), and from that moment on the control is back with the HDMI transmitter. Unfortunately I don't have any other slave on the same bus, but I wonder what happens if someone else tries to use the same bus while the pass through mode is operating... Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: Delay between stop condition and start condition
Hello Wolfram, Thank you so much for your feedback! > Subject: Re: Delay between stop condition and start condition > > Hi Fabrizio, everyone, > > Thanks for bringing this up! > > > What's the best way to address this? I could pull in the HDMI > > transmitter driver the code to read the EDID back from the monitor so > > that I can fit device specific delays without impacting the generic > > implementation of the EDID readback, but that would replicate some > > code and the driver would not benefit from fixes made to the generic > > implementation. I could change the RCar I2C driver in order to fit a > > new DT parameter (i2c-delay-after-stop-us?), and the driver would put > > in the desired delay after every stop condition, but isn't this > > parameter something every I2C controller would benefit from (now that > > we know we have a use case for it)? What are your thoughts and > > recommendations? > > No need for a property. The I2C standard has a clearly defined value for > that which is named 'tbuf' and is in general the same value as the > minimal low period of the SCL signal. So, it must be handled at the I2C > bus master level. > > Currently, we have no rule at what time drivers have to leave the > master_xfer() callback. Some exit when STOP is still processed, some > when STOP has been sent. I am not aware of a driver respecting tbuf. It > seems worth recommending to respect tbuf. > > I think this needs to be completely handled in the bus master driver. We > have USB-to-I2C bridges which we can control only high level and the > firmware of those need to respect tbuf. I don't see how the I2C core > could support individual drivers here. > > So, that's how I see this situation. Other comments? Other ideas? My understanding is that when this HDMI transmitter is configured in pass through mode then a bigger 'tbuf' is required. The I2C spec (v2.1) says that in "standard mode" tbuf>=4.7us" and in fast-mode "tbuf>=1.3us", in this particular case the 20us of bus free time between the STOP and START conditions you find in the trace are not enough. This device seems to require an out of spec solution (an hack..), what's the most acceptable solution from an upstreaming perspective? Other platforms may want to use the same HDMI transmitter in their solutions and may stumble across the same problem if the platform is quick enough. I may just put this delay in the driver and call it a day by wrapping writes/reads/modifies and stuff? What do you think? Thanks, Fab > > Thanks, > >Wolfram Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH v4 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
Hello Simon,
Thank you for your feedback.
> >
> > +static int r8a77470_pin_to_pocctrl(struct sh_pfc *pfc, unsigned int pin,
> > + u32 *pocctrl)
> > +{
> > +int bit = -EINVAL;
> > +
> > +*pocctrl = 0xe60600b0;
> > +
> > +if (pin >= RCAR_GP_PIN(0, 5) && pin <= RCAR_GP_PIN(0, 10))
> > +bit = 0;
>
> Is it intentional that the range above excludes GP0_11 and 12?
Yes, it is, GPO_11 and GPO_12 can't be voltage controlled, they only work at
3.3V
>
> > +
> > +if (pin >= RCAR_GP_PIN(0, 13) && pin <= RCAR_GP_PIN(0, 22))
> > +bit = 2;
> > +
> > +if (pin >= RCAR_GP_PIN(4, 14) && pin <= RCAR_GP_PIN(4, 19))
>
> And likewise GP4_20 and 21 here.
Same thing here, GP4_20 and GP4_21 can't be voltage controlled, they only work
at 3.3V
Thanks, Fab
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
[PATCH v4 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI pins
capable of switching voltage, also add pin groups and functions
for SDHI0 and SDHI1. Please note that with the RZ/G1C only 1
bit of the POC Control Register is used to control each interface.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
Reviewed-by: Geert Uytterhoeven
---
v3->v4:
* Fixed voltage control of GP0_11 and GP0_12
v2->v3:
* No change
v1->v2:
* Reworked implementation of r8a77470_pin_to_pocctrl as per Wolfram's
and Geert's comments
* Added SDHI0 and SDHI1 pins and IO voltage control
* Added SDHI0 and SDHI1 pin groups and functions
* Reworked changelog and title
* Please note that there is some overlapping between mmc pin groups
and sdhi1 pin groups
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162 +-
1 file changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 5e29b95..4359aeb 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -10,14 +10,45 @@
#include "sh_pfc.h"
#define CPU_ALL_PORT(fn, sfx) \
- PORT_GP_23(0, fn, sfx), \
+ PORT_GP_4(0, fn, sfx), \
+ PORT_GP_1(0, 4, fn, sfx), \
+ PORT_GP_CFG_1(0, 5, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 6, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 7, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 8, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 9, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 10, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_1(0, 11, fn, sfx), \
+ PORT_GP_1(0, 12, fn, sfx), \
+ PORT_GP_CFG_1(0, 13, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 20, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 21, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 22, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
PORT_GP_23(1, fn, sfx), \
PORT_GP_32(2, fn, sfx), \
PORT_GP_17(3, fn, sfx), \
PORT_GP_1(3, 27, fn, sfx), \
PORT_GP_1(3, 28, fn, sfx), \
PORT_GP_1(3, 29, fn, sfx), \
- PORT_GP_26(4, fn, sfx), \
+ PORT_GP_14(4, fn, sfx), \
+ PORT_GP_CFG_1(4, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_1(4, 20, fn, sfx), \
+ PORT_GP_1(4, 21, fn, sfx), \
+ PORT_GP_1(4, 22, fn, sfx), \
+ PORT_GP_1(4, 23, fn, sfx), \
+ PORT_GP_1(4, 24, fn, sfx), \
+ PORT_GP_1(4, 25, fn, sfx), \
PORT_GP_32(5, fn, sfx)
enum {
@@ -1865,6 +1896,81 @@ static const unsigned int scif_clk_b_pins[] = {
static const unsigned int scif_clk_b_mux[] = {
SCIF_CLK_B_MARK,
};
+/* - SDHI0 --
*/
+static const unsigned int sdhi0_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(0, 7),
+};
+static const unsigned int sdhi0_data1_mux[] = {
+ SD0_DAT0_MARK,
+};
+static const unsigned int sdhi0_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(0, 7), RCAR_GP_PIN(0, 8),
+ RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 10),
+};
+static const unsigned int sdhi0_data4_mux[] = {
+ SD0_DAT0_MARK, SD0_DAT1_MARK, SD0_DAT2_MARK, SD0_DAT3_MARK,
+};
+st
Delay between stop condition and start condition
Hello Wolfram, While working out what's needed to add HDMI support to the iwg23s from iWave I have stumbled across a problem with the HDMI transmitter (SiI9022ACNU). Such an HDMI transmitter has a DDC pass through mode that allows the SoC to talk directly to the monitor (to allow the SoC to read the EDID back from the monitor, for example). While in this working mode, if the SoC generates a start condition too close to the previous stop condition, then the monitor will miss the start condition, alongside a clock cycle. The consequences of this may be catastrophic, as you can imagine. I have attached a picture of a trace grabbed with my logic analyser, where SDA and SDL are related to the I2C bus between the SoC and the HDMI transmitter, while DDCT_SDA and DDCT_SCL (digital and analogic traces) are related to the I2C bus connecting the HDMI transmitter to the monitor. What's the best way to address this? I could pull in the HDMI transmitter driver the code to read the EDID back from the monitor so that I can fit device specific delays without impacting the generic implementation of the EDID readback, but that would replicate some code and the driver would not benefit from fixes made to the generic implementation. I could change the RCar I2C driver in order to fit a new DT parameter (i2c-delay-after-stop-us?), and the driver would put in the desired delay after every stop condition, but isn't this parameter something every I2C controller would benefit from (now that we know we have a use case for it)? What are your thoughts and recommendations? Thanks, Fab Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH v3 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
Hello Geert, Thank you for your feedback! > Subject: Re: [PATCH v3 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support > > Hi Fabrizio, > > On Mon, Oct 8, 2018 at 10:52 AM Fabrizio Castro > wrote: > > Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI pins > > capable of switching voltage, also add pin groups and functions > > for SDHI0 and SDHI1. Please note that with the RZ/G1C only 1 > > bit of the POC Control Register is used to control each interface. > > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Biju Das > > > > --- > > v2->v3: > > * No change > > > > v1->v2: > > * Reworked implementation of r8a77470_pin_to_pocctrl as per Wolfram's > > and Geert's comments > > * Added SDHI0 and SDHI1 pins and IO voltage control > > * Added SDHI0 and SDHI1 pin groups and functions > > * Reworked changelog and title > > * Please note that there is some overlapping between mmc pin groups > > and sdhi1 pin groups > > Thanks for the update! > > > --- > > drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162 > > +- > > 1 file changed, 160 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c > > b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c > > index 3d36e5f..fa0d42b 100644 > > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c > > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c > > @@ -10,14 +10,45 @@ > > #include "sh_pfc.h" > > > > #define CPU_ALL_PORT(fn, sfx) \ > > - PORT_GP_23(0, fn, sfx), \ > > + PORT_GP_4(0, fn, sfx), \ > > + PORT_GP_1(0, 4, fn, sfx), \ > > + PORT_GP_CFG_1(0, 5, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 6, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 7, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 8, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 9, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 10, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 11, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 12, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > GP0_11 and GP0_12 do not have I/O voltage controls. > Hence they're also not handled by r8a77470_pin_to_pocctrl() below. You are right! I'll wait for comments on the remaining patches of this series and then I'll send out a final version. Thanks, Fab > > With the above fixed: > Reviewed-by: Geert Uytterhoeven > > > + PORT_GP_CFG_1(0, 13, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 20, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 21, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(0, 22, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > PORT_GP_23(1, fn, sfx), \ > > PORT_GP_32(2, fn, sfx), \ > > PORT_GP_17(3, fn, sfx), \ > > PORT_GP_1(3, 27, fn, sfx), \ > > PORT_GP_1(3, 28, fn, sfx), \ > > PORT_GP_1(3, 29, fn, sfx), \ > > - PORT_GP_26(4, fn, sfx), \ > > + PORT_GP_14(4, fn, sfx), \ > > + PORT_GP_CFG_1(4, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(4, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(4, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(4, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(4, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \ > > + PORT_GP_CFG_1(
[PATCH] ARM: dts: r8a77470: Add I2C[0123] support
Add device tree nodes for the I2C[0123] controllers. Also, add
the aliases node.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
This patch depends on:
https://patchwork.kernel.org/patch/10630265/
https://patchwork.kernel.org/patch/10630267/
---
arch/arm/boot/dts/r8a77470.dtsi | 64 +
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 48902b4..6ac7f46 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -14,6 +14,14 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 =
+ i2c1 =
+ i2c2 =
+ i2c3 =
+ i2c4 =
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -237,6 +245,62 @@
reg = <0 0xe630 0 0x2>;
};
+ i2c0: i2c@e6508000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77470",
+"renesas,rcar-gen2-i2c";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 931>;
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ resets = < 931>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@e6518000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77470",
+"renesas,rcar-gen2-i2c";
+ reg = <0 0xe6518000 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 930>;
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ resets = < 930>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@e653 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77470",
+"renesas,rcar-gen2-i2c";
+ reg = <0 0xe653 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 929>;
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ resets = < 929>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@e654 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77470",
+"renesas,rcar-gen2-i2c";
+ reg = <0 0xe654 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 928>;
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ resets = < 928>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
i2c4: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
--
2.7.4
[PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add DU1 pin groups
Add DU1 pin groups and function to the RZ/G1C (a.k.a. R8A77470)
pinctrl driver.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 108 ++
1 file changed, 108 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index b321a7a..64f542c 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -1315,6 +1315,92 @@ static const unsigned int du0_disp_pins[] = {
static const unsigned int du0_disp_mux[] = {
DU0_DISP_MARK
};
+static const unsigned int du1_rgb666_pins[] = {
+ /* R[7:2], G[7:2], B[7:2] */
+ RCAR_GP_PIN(4, 9), RCAR_GP_PIN(4, 8), RCAR_GP_PIN(4, 7),
+ RCAR_GP_PIN(4, 6), RCAR_GP_PIN(4, 5), RCAR_GP_PIN(4, 4),
+ RCAR_GP_PIN(4, 17), RCAR_GP_PIN(4, 16), RCAR_GP_PIN(4, 15),
+ RCAR_GP_PIN(4, 14), RCAR_GP_PIN(4, 13), RCAR_GP_PIN(4, 12),
+ RCAR_GP_PIN(4, 25), RCAR_GP_PIN(4, 24), RCAR_GP_PIN(4, 23),
+ RCAR_GP_PIN(4, 22), RCAR_GP_PIN(4, 21), RCAR_GP_PIN(4, 20),
+};
+static const unsigned int du1_rgb666_mux[] = {
+ DU1_DR7_MARK, DU1_DR6_MARK, DU1_DR5_MARK, DU1_DR4_MARK,
+ DU1_DR3_MARK, DU1_DR2_MARK,
+ DU1_DG7_MARK, DU1_DG6_MARK, DU1_DG5_MARK, DU1_DG4_MARK,
+ DU1_DG3_MARK, DU1_DG2_MARK,
+ DU1_DB7_MARK, DU1_DB6_MARK, DU1_DB5_MARK, DU1_DB4_MARK,
+ DU1_DB3_MARK, DU1_DB2_MARK,
+};
+static const unsigned int du1_rgb888_pins[] = {
+ /* R[7:0], G[7:0], B[7:0] */
+ RCAR_GP_PIN(4, 9), RCAR_GP_PIN(4, 8), RCAR_GP_PIN(4, 7),
+ RCAR_GP_PIN(4, 6), RCAR_GP_PIN(4, 5), RCAR_GP_PIN(4, 4),
+ RCAR_GP_PIN(4, 3), RCAR_GP_PIN(4, 2),
+ RCAR_GP_PIN(4, 17), RCAR_GP_PIN(4, 16), RCAR_GP_PIN(4, 15),
+ RCAR_GP_PIN(4, 14), RCAR_GP_PIN(4, 13), RCAR_GP_PIN(4, 12),
+ RCAR_GP_PIN(4, 11), RCAR_GP_PIN(4, 10),
+ RCAR_GP_PIN(4, 25), RCAR_GP_PIN(4, 24), RCAR_GP_PIN(4, 23),
+ RCAR_GP_PIN(4, 22), RCAR_GP_PIN(4, 21), RCAR_GP_PIN(4, 20),
+ RCAR_GP_PIN(4, 19), RCAR_GP_PIN(4, 18),
+};
+static const unsigned int du1_rgb888_mux[] = {
+ DU1_DR7_MARK, DU1_DR6_MARK, DU1_DR5_MARK, DU1_DR4_MARK,
+ DU1_DR3_MARK, DU1_DR2_MARK, DU1_DR1_MARK, DU1_DR0_MARK,
+ DU1_DG7_MARK, DU1_DG6_MARK, DU1_DG5_MARK, DU1_DG4_MARK,
+ DU1_DG3_MARK, DU1_DG2_MARK, DU1_DG1_MARK, DU1_DG0_MARK,
+ DU1_DB7_MARK, DU1_DB6_MARK, DU1_DB5_MARK, DU1_DB4_MARK,
+ DU1_DB3_MARK, DU1_DB2_MARK, DU1_DB1_MARK, DU1_DB0_MARK,
+};
+static const unsigned int du1_clk0_out_pins[] = {
+ /* DOTCLKOUT0 */
+ RCAR_GP_PIN(5, 2),
+};
+static const unsigned int du1_clk0_out_mux[] = {
+ DU1_DOTCLKOUT0_MARK
+};
+static const unsigned int du1_clk1_out_pins[] = {
+ /* DOTCLKOUT1 */
+ RCAR_GP_PIN(5, 0),
+};
+static const unsigned int du1_clk1_out_mux[] = {
+ DU1_DOTCLKOUT1_MARK
+};
+static const unsigned int du1_clk_in_pins[] = {
+ /* DOTCLKIN */
+ RCAR_GP_PIN(5, 1),
+};
+static const unsigned int du1_clk_in_mux[] = {
+ DU1_DOTCLKIN_MARK
+};
+static const unsigned int du1_sync_pins[] = {
+ /* EXVSYNC/VSYNC, EXHSYNC/HSYNC */
+ RCAR_GP_PIN(5, 5), RCAR_GP_PIN(5, 4),
+};
+static const unsigned int du1_sync_mux[] = {
+ DU1_EXVSYNC_DU1_VSYNC_MARK, DU1_EXHSYNC_DU1_HSYNC_MARK
+};
+static const unsigned int du1_oddf_pins[] = {
+ /* EXODDF/ODDF/DISP/CDE */
+ RCAR_GP_PIN(5, 3),
+};
+static const unsigned int du1_oddf_mux[] = {
+ DU1_EXODDF_DU1_ODDF_DISP_CDE_MARK,
+};
+static const unsigned int du1_cde_pins[] = {
+ /* CDE */
+ RCAR_GP_PIN(5, 7),
+};
+static const unsigned int du1_cde_mux[] = {
+ DU1_CDE_MARK
+};
+static const unsigned int du1_disp_pins[] = {
+ /* DISP */
+ RCAR_GP_PIN(5, 6),
+};
+static const unsigned int du1_disp_mux[] = {
+ DU1_DISP_MARK
+};
/* - I2C0 ---
*/
static const unsigned int i2c0_a_pins[] = {
/* SCL, SDA */
@@ -1941,6 +2027,15 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(du0_oddf),
SH_PFC_PIN_GROUP(du0_cde),
SH_PFC_PIN_GROUP(du0_disp),
+ SH_PFC_PIN_GROUP(du1_rgb666),
+ SH_PFC_PIN_GROUP(du1_rgb888),
+ SH_PFC_PIN_GROUP(du1_clk0_out),
+ SH_PFC_PIN_GROUP(du1_clk1_out),
+ SH_PFC_PIN_GROUP(du1_clk_in),
+ SH_PFC_PIN_GROUP(du1_sync),
+ SH_PFC_PIN_GROUP(du1_oddf),
+ SH_PFC_PIN_GROUP(du1_cde),
+ SH_PFC_PIN_GROUP(du1_disp),
SH_PFC_PIN_GROUP(i2c0_a),
SH_PFC_PIN_GROUP(i2c0_b),
SH_PFC_PIN_GROUP(i2c0_c),
@@ -2052,6 +2147,18 @@ static const char * const du0_groups[] = {
"du0_disp",
};
+static const char * const du1_groups[] = {
+ "du1_rgb666",
+ "du1_rgb888",
+ "du1_clk0_out",
+ "du1_clk1_out",
+ "du1_clk_in",
+ "du
[PATCH 0/4] Improve pinctrl support for the RZ/G1C
Dear All, this series adds support for I2C[0123], DU1, VIN[01], and QSPI1 to the pinctrl driver of the RZ/G1C (a.k.a. R8A77470). This series applies on top of next-20181005, and depends on: https://patchwork.kernel.org/patch/10630259/ Thanks, Fab Fabrizio Castro (4): pinctrl: sh-pfc: r8a77470: Add remaining I2C pin groups pinctrl: sh-pfc: r8a77470: Add DU1 pin groups pinctrl: sh-pfc: r8a77470: Add VIN pin groups pinctrl: sh-pfc: r8a77470: Add QSPI1 pin groups drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 516 ++ 1 file changed, 516 insertions(+) -- 2.7.4
[PATCH 3/4] pinctrl: sh-pfc: r8a77470: Add VIN pin groups
Add VIN[01] pin groups and functions to the RZ/G1C (a.k.a.
R8A77470) pinctrl driver.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 184 ++
1 file changed, 184 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 64f542c..726e3da 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -2003,6 +2003,146 @@ static const unsigned int usb1_mux[] = {
USB1_PWEN_MARK,
USB1_OVC_MARK,
};
+/* - VIN0 ---
*/
+static const union vin_data vin0_data_pins = {
+ .data24 = {
+ /* B */
+ RCAR_GP_PIN(5, 20), RCAR_GP_PIN(5, 21),
+ RCAR_GP_PIN(5, 22), RCAR_GP_PIN(5, 23),
+ RCAR_GP_PIN(5, 24), RCAR_GP_PIN(5, 25),
+ RCAR_GP_PIN(5, 26), RCAR_GP_PIN(5, 27),
+ /* G */
+ RCAR_GP_PIN(4, 2), RCAR_GP_PIN(4, 3),
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+ RCAR_GP_PIN(4, 6), RCAR_GP_PIN(5, 8),
+ RCAR_GP_PIN(5, 9), RCAR_GP_PIN(5, 10),
+ /* R */
+ RCAR_GP_PIN(5, 11), RCAR_GP_PIN(5, 12),
+ RCAR_GP_PIN(5, 13), RCAR_GP_PIN(5, 14),
+ RCAR_GP_PIN(5, 15), RCAR_GP_PIN(5, 16),
+ RCAR_GP_PIN(5, 17), RCAR_GP_PIN(5, 19),
+ },
+};
+static const union vin_data vin0_data_mux = {
+ .data24 = {
+ /* B */
+ VI0_DATA0_VI0_B0_MARK, VI0_DATA1_VI0_B1_MARK,
+ VI0_DATA2_VI0_B2_MARK, VI0_DATA3_VI0_B3_MARK,
+ VI0_DATA4_VI0_B4_MARK, VI0_DATA5_VI0_B5_MARK,
+ VI0_DATA6_VI0_B6_MARK, VI0_DATA7_VI0_B7_MARK,
+ /* G */
+ VI0_G0_MARK, VI0_G1_MARK,
+ VI0_G2_MARK, VI0_G3_MARK,
+ VI0_G4_MARK, VI0_G5_MARK,
+ VI0_G6_MARK, VI0_G7_MARK,
+ /* R */
+ VI0_R0_MARK, VI0_R1_MARK,
+ VI0_R2_MARK, VI0_R3_MARK,
+ VI0_R4_MARK, VI0_R5_MARK,
+ VI0_R6_MARK, VI0_R7_MARK,
+ },
+};
+static const unsigned int vin0_data18_pins[] = {
+ /* B */
+ RCAR_GP_PIN(5, 22), RCAR_GP_PIN(5, 23),
+ RCAR_GP_PIN(5, 24), RCAR_GP_PIN(5, 25),
+ RCAR_GP_PIN(5, 26), RCAR_GP_PIN(5, 27),
+ /* G */
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+ RCAR_GP_PIN(4, 6), RCAR_GP_PIN(5, 8),
+ RCAR_GP_PIN(5, 9), RCAR_GP_PIN(5, 10),
+ /* R */
+ RCAR_GP_PIN(5, 13), RCAR_GP_PIN(5, 14),
+ RCAR_GP_PIN(5, 15), RCAR_GP_PIN(5, 16),
+ RCAR_GP_PIN(5, 17), RCAR_GP_PIN(5, 19),
+};
+static const unsigned int vin0_data18_mux[] = {
+ /* B */
+ VI0_DATA2_VI0_B2_MARK, VI0_DATA3_VI0_B3_MARK,
+ VI0_DATA4_VI0_B4_MARK, VI0_DATA5_VI0_B5_MARK,
+ VI0_DATA6_VI0_B6_MARK, VI0_DATA7_VI0_B7_MARK,
+ /* G */
+ VI0_G2_MARK, VI0_G3_MARK,
+ VI0_G4_MARK, VI0_G5_MARK,
+ VI0_G6_MARK, VI0_G7_MARK,
+ /* R */
+ VI0_R2_MARK, VI0_R3_MARK,
+ VI0_R4_MARK, VI0_R5_MARK,
+ VI0_R6_MARK, VI0_R7_MARK,
+};
+static const unsigned int vin0_sync_pins[] = {
+ RCAR_GP_PIN(5, 30), /* HSYNC */
+ RCAR_GP_PIN(5, 31), /* VSYNC */
+};
+static const unsigned int vin0_sync_mux[] = {
+ VI0_HSYNC_N_MARK,
+ VI0_VSYNC_N_MARK,
+};
+static const unsigned int vin0_field_pins[] = {
+ RCAR_GP_PIN(5, 29),
+};
+static const unsigned int vin0_field_mux[] = {
+ VI0_FIELD_MARK,
+};
+static const unsigned int vin0_clkenb_pins[] = {
+ RCAR_GP_PIN(5, 28),
+};
+static const unsigned int vin0_clkenb_mux[] = {
+ VI0_CLKENB_MARK,
+};
+static const unsigned int vin0_clk_pins[] = {
+ RCAR_GP_PIN(5, 18),
+};
+static const unsigned int vin0_clk_mux[] = {
+ VI0_CLK_MARK,
+};
+/* - VIN1 ---
*/
+static const union vin_data vin1_data_pins = {
+ .data12 = {
+ RCAR_GP_PIN(3, 1), RCAR_GP_PIN(3, 2),
+ RCAR_GP_PIN(3, 3), RCAR_GP_PIN(3, 4),
+ RCAR_GP_PIN(3, 5), RCAR_GP_PIN(3, 6),
+ RCAR_GP_PIN(3, 7), RCAR_GP_PIN(3, 8),
+ RCAR_GP_PIN(3, 13), RCAR_GP_PIN(3, 14),
+ RCAR_GP_PIN(3, 15), RCAR_GP_PIN(3, 16),
+ },
+};
+static const union vin_data vin1_data_mux = {
+ .data12 = {
+ VI1_DATA0_MARK, VI1_DATA1_MARK,
+ VI1_DATA2_MARK, VI1_DATA3_MARK,
+ VI1_DATA4_MARK, VI1_DATA5_MARK,
+ VI1_DATA6_MARK, VI1_DATA7_MARK,
+ VI1_DATA8_MARK, VI1_DATA9_MARK,
+ VI1_DATA10_MARK, VI1_DATA11_MARK,
+ },
+};
+static const unsigned int vin1_sync_pins[] = {
+ RCAR_GP_PIN(3, 11), /* HSYNC */
+ RCAR_GP_PIN(3, 12), /* VSYNC */
+};
+static const unsigned int vin1_sync_mux
[PATCH 1/4] pinctrl: sh-pfc: r8a77470: Add remaining I2C pin groups
This patch adds I2C[0123] groups and functions to the RZ/G1C
(a.k.a. R8A77470) pinctrl driver.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 191 ++
1 file changed, 191 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index fa0d42b..b321a7a 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -1315,6 +1315,143 @@ static const unsigned int du0_disp_pins[] = {
static const unsigned int du0_disp_mux[] = {
DU0_DISP_MARK
};
+/* - I2C0 ---
*/
+static const unsigned int i2c0_a_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(4, 0), RCAR_GP_PIN(4, 1),
+};
+static const unsigned int i2c0_a_mux[] = {
+ SCL0_A_MARK, SDA0_A_MARK,
+};
+static const unsigned int i2c0_b_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(5, 28), RCAR_GP_PIN(5, 29),
+};
+static const unsigned int i2c0_b_mux[] = {
+ SCL0_B_MARK, SDA0_B_MARK,
+};
+static const unsigned int i2c0_c_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(3, 11), RCAR_GP_PIN(3, 12),
+};
+static const unsigned int i2c0_c_mux[] = {
+ SCL0_C_MARK, SDA0_C_MARK,
+};
+static const unsigned int i2c0_d_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+};
+static const unsigned int i2c0_d_mux[] = {
+ SCL0_D_MARK, SDA0_D_MARK,
+};
+static const unsigned int i2c0_e_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+};
+static const unsigned int i2c0_e_mux[] = {
+ SCL0_E_MARK, SDA0_E_MARK,
+};
+/* - I2C1 ---
*/
+static const unsigned int i2c1_a_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(4, 2), RCAR_GP_PIN(4, 3),
+};
+static const unsigned int i2c1_a_mux[] = {
+ SCL1_A_MARK, SDA1_A_MARK,
+};
+static const unsigned int i2c1_b_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(1, 5), RCAR_GP_PIN(1, 6),
+};
+static const unsigned int i2c1_b_mux[] = {
+ SCL1_B_MARK, SDA1_B_MARK,
+};
+static const unsigned int i2c1_c_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(4, 22), RCAR_GP_PIN(4, 23),
+};
+static const unsigned int i2c1_c_mux[] = {
+ SCL1_C_MARK, SDA1_C_MARK,
+};
+static const unsigned int i2c1_d_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 9),
+};
+static const unsigned int i2c1_d_mux[] = {
+ SCL1_D_MARK, SDA1_D_MARK,
+};
+static const unsigned int i2c1_e_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(4, 16), RCAR_GP_PIN(4, 17),
+};
+static const unsigned int i2c1_e_mux[] = {
+ SCL1_E_MARK, SDA1_E_MARK,
+};
+/* - I2C2 ---
*/
+static const unsigned int i2c2_a_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(4, 24), RCAR_GP_PIN(4, 25),
+};
+static const unsigned int i2c2_a_mux[] = {
+ SCL2_A_MARK, SDA2_A_MARK,
+};
+static const unsigned int i2c2_b_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(3, 13), RCAR_GP_PIN(3, 14),
+};
+static const unsigned int i2c2_b_mux[] = {
+ SCL2_B_MARK, SDA2_B_MARK,
+};
+static const unsigned int i2c2_c_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+};
+static const unsigned int i2c2_c_mux[] = {
+ SCL2_C_MARK, SDA2_C_MARK,
+};
+static const unsigned int i2c2_d_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+};
+static const unsigned int i2c2_d_mux[] = {
+ SCL2_D_MARK, SDA2_D_MARK,
+};
+/* - I2C3 ---
*/
+static const unsigned int i2c3_a_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(3, 9), RCAR_GP_PIN(3, 10),
+};
+static const unsigned int i2c3_a_mux[] = {
+ SCL3_A_MARK, SDA3_A_MARK,
+};
+static const unsigned int i2c3_b_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+};
+static const unsigned int i2c3_b_mux[] = {
+ SCL3_B_MARK, SDA3_B_MARK,
+};
+static const unsigned int i2c3_c_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(5, 1), RCAR_GP_PIN(5, 2),
+};
+static const unsigned int i2c3_c_mux[] = {
+ SCL3_C_MARK, SDA3_C_MARK,
+};
+static const unsigned int i2c3_d_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+};
+static const unsigned int i2c3_d_mux[] = {
+ SCL3_D_MARK, SDA3_D_MARK,
+};
+static const unsigned int i2c3_e_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(5, 25), RCAR_GP_PIN(5, 26),
+};
+static const unsigned int i2c3_e_mux[] = {
+ SCL3_E_MARK, SDA3_E_MARK,
+};
/* - I2C4 ---
*/
static const unsigned int i2c4_a_pins[] = {
/* SCL, SDA */
@@ -1804,6 +1941,25 @@ static const struct sh_pfc_pin_group pinmux_groups
[PATCH 4/4] pinctrl: sh-pfc: r8a77470: Add QSPI1 pin groups
Add QSPI1 pin groups and function to the RZ/G1C (a.k.a. R8A77470)
pinctrl driver.
Signed-off-by: Fabrizio Castro
Reviewed-by: Fabrizio Castro
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 726e3da..d9c6a03 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -1635,6 +1635,29 @@ static const unsigned int qspi0_data4_mux[] = {
QSPI0_MOSI_QSPI0_IO0_MARK, QSPI0_MISO_QSPI0_IO1_MARK,
QSPI0_IO2_MARK, QSPI0_IO3_MARK,
};
+static const unsigned int qspi1_ctrl_pins[] = {
+ /* SPCLK, SSL */
+ RCAR_GP_PIN(4, 6), RCAR_GP_PIN(4, 9),
+};
+static const unsigned int qspi1_ctrl_mux[] = {
+ QSPI1_SPCLK_MARK, QSPI1_SSL_MARK,
+};
+static const unsigned int qspi1_data2_pins[] = {
+ /* MOSI_IO0, MISO_IO1 */
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+};
+static const unsigned int qspi1_data2_mux[] = {
+ QSPI1_MOSI_QSPI1_IO0_MARK, QSPI1_MISO_QSPI1_IO1_MARK,
+};
+static const unsigned int qspi1_data4_pins[] = {
+ /* MOSI_IO0, MISO_IO1, IO2, IO3 */
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5), RCAR_GP_PIN(4, 7),
+ RCAR_GP_PIN(4, 8),
+};
+static const unsigned int qspi1_data4_mux[] = {
+ QSPI1_MOSI_QSPI1_IO0_MARK, QSPI1_MISO_QSPI1_IO1_MARK,
+ QSPI1_IO2_MARK, QSPI1_IO3_MARK,
+};
/* - SCIF0 --
*/
static const unsigned int scif0_data_a_pins[] = {
/* RX, TX */
@@ -2207,6 +2230,9 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(qspi0_ctrl),
SH_PFC_PIN_GROUP(qspi0_data2),
SH_PFC_PIN_GROUP(qspi0_data4),
+ SH_PFC_PIN_GROUP(qspi1_ctrl),
+ SH_PFC_PIN_GROUP(qspi1_data2),
+ SH_PFC_PIN_GROUP(qspi1_data4),
SH_PFC_PIN_GROUP(scif0_data_a),
SH_PFC_PIN_GROUP(scif0_data_b),
SH_PFC_PIN_GROUP(scif0_data_c),
@@ -2369,6 +2395,12 @@ static const char * const qspi0_groups[] = {
"qspi0_data4",
};
+static const char * const qspi1_groups[] = {
+ "qspi1_ctrl",
+ "qspi1_data2",
+ "qspi1_data4",
+};
+
static const char * const scif0_groups[] = {
"scif0_data_a",
"scif0_data_b",
@@ -2490,6 +2522,7 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(i2c4),
SH_PFC_FUNCTION(mmc),
SH_PFC_FUNCTION(qspi0),
+ SH_PFC_FUNCTION(qspi1),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif1),
SH_PFC_FUNCTION(scif2),
--
2.7.4
[PATCH v3 4/6] ARM: dts: r8a77470: Add SDHI0 support
RZ/G1C comes with two different types of IP for the SDHI
interfaces, SDHI0 and SDHI2 share the same IP type, and
such an IP is also compatible with the one found in R-Car
Gen2. SDHI1 IP on the other hand is compatible with R-Car
Gen3 with internal DMA.
This patch completes the SDHI support of the R-Car Gen2
compatible IPs, including fixing the max-frequency
definition of SDHI2, as it turns out there is a bug in
Section 1.3.9 of the RZ/G1C Hardware User's Manual (Rev.
1.00 Oct. 2017).
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2->v3:
* No change
v2:
* New patch
---
arch/arm/boot/dts/r8a77470.dtsi | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 9e7f86d..e01df9c 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -412,6 +412,21 @@
status = "disabled";
};
+ sdhi0: sd@ee10 {
+ compatible = "renesas,sdhi-r8a77470",
+"renesas,rcar-gen2-sdhi";
+ reg = <0 0xee10 0 0x328>;
+ interrupts = ;
+ clocks = < CPG_MOD 314>;
+ dmas = < 0xcd>, < 0xce>,
+ < 0xcd>, < 0xce>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <15600>;
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ resets = < 314>;
+ status = "disabled";
+ };
+
sdhi2: sd@ee16 {
compatible = "renesas,sdhi-r8a77470",
"renesas,rcar-gen2-sdhi";
@@ -421,7 +436,7 @@
dmas = < 0xd3>, < 0xd4>,
< 0xd3>, < 0xd4>;
dma-names = "tx", "rx", "tx", "rx";
- max-frequency = <9750>;
+ max-frequency = <7800>;
power-domains = < R8A77470_PD_ALWAYS_ON>;
resets = < 312>;
status = "disabled";
--
2.7.4
[PATCH v3 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI pins
capable of switching voltage, also add pin groups and functions
for SDHI0 and SDHI1. Please note that with the RZ/G1C only 1
bit of the POC Control Register is used to control each interface.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2->v3:
* No change
v1->v2:
* Reworked implementation of r8a77470_pin_to_pocctrl as per Wolfram's
and Geert's comments
* Added SDHI0 and SDHI1 pins and IO voltage control
* Added SDHI0 and SDHI1 pin groups and functions
* Reworked changelog and title
* Please note that there is some overlapping between mmc pin groups
and sdhi1 pin groups
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162 +-
1 file changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 3d36e5f..fa0d42b 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -10,14 +10,45 @@
#include "sh_pfc.h"
#define CPU_ALL_PORT(fn, sfx) \
- PORT_GP_23(0, fn, sfx), \
+ PORT_GP_4(0, fn, sfx), \
+ PORT_GP_1(0, 4, fn, sfx), \
+ PORT_GP_CFG_1(0, 5, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 6, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 7, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 8, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 9, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 10, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 11, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 12, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 13, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 20, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 21, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 22, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
PORT_GP_23(1, fn, sfx), \
PORT_GP_32(2, fn, sfx), \
PORT_GP_17(3, fn, sfx), \
PORT_GP_1(3, 27, fn, sfx), \
PORT_GP_1(3, 28, fn, sfx), \
PORT_GP_1(3, 29, fn, sfx), \
- PORT_GP_26(4, fn, sfx), \
+ PORT_GP_14(4, fn, sfx), \
+ PORT_GP_CFG_1(4, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_1(4, 20, fn, sfx), \
+ PORT_GP_1(4, 21, fn, sfx), \
+ PORT_GP_1(4, 22, fn, sfx), \
+ PORT_GP_1(4, 23, fn, sfx), \
+ PORT_GP_1(4, 24, fn, sfx), \
+ PORT_GP_1(4, 25, fn, sfx), \
PORT_GP_32(5, fn, sfx)
enum {
@@ -1619,6 +1650,81 @@ static const unsigned int scif_clk_b_pins[] = {
static const unsigned int scif_clk_b_mux[] = {
SCIF_CLK_B_MARK,
};
+/* - SDHI0 --
*/
+static const unsigned int sdhi0_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(0, 7),
+};
+static const unsigned int sdhi0_data1_mux[] = {
+ SD0_DAT0_MARK,
+};
+static const unsigned int sdhi0_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(0, 7), RCAR_GP_PIN(0, 8),
+ RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 10),
+};
+static const unsigned int sdhi0_data4_mux[] = {
+ SD0_DAT0_MARK, SD0_DAT1_MARK, SD0_DAT2_MARK, SD0_DAT3_MARK,
+};
+static const unsigned int sdhi0_ctrl_pins[] = {
+ /* CLK, CMD */
+
[PATCH v3 3/6] mmc: renesas_sdhi: Add r8a77470 SDHI1 support
The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces,
SDHI0 and SDHI2 are compatible with the R-Car Gen2 SDHIs, SDHI1
is compatible with R-Car Gen3 SDHIs and it can be used as
eMMC as well. This patch adds driver compatibility, and makes
sure both drivers get compiled for the R8A77470.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2->v3:
* No change
v2:
* New patch
---
drivers/mmc/host/Kconfig | 4 ++--
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 694d082..fb654cd 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -622,9 +622,9 @@ config MMC_SDHI_SYS_DMAC
config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
- depends on ARM64 || COMPILE_TEST
+ depends on ARM64 || ARCH_R8A77470 || COMPILE_TEST
depends on MMC_SDHI
- default MMC_SDHI if ARM64
+ default MMC_SDHI if (ARM64 || ARCH_R8A77470)
help
This provides DMA support for SDHI SD/SDIO controllers
using on-chip bus mastering. This supports the controllers
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index e5e5015..e729c39 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -113,6 +113,7 @@ static const struct renesas_sdhi_of_data
of_rcar_gen3_compatible = {
};
static const struct of_device_id renesas_sdhi_internal_dmac_of_match[] = {
+ { .compatible = "renesas,sdhi-mmc-r8a77470", .data =
_rcar_gen3_compatible, },
{ .compatible = "renesas,sdhi-r8a7795", .data =
_rcar_r8a7795_compatible, },
{ .compatible = "renesas,sdhi-r8a7796", .data =
_rcar_r8a7795_compatible, },
{ .compatible = "renesas,rcar-gen3-sdhi", .data =
_rcar_gen3_compatible, },
@@ -288,7 +289,7 @@ static const struct tmio_mmc_dma_ops
renesas_sdhi_internal_dmac_dma_ops = {
* Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
* implementation as others may use a different implementation.
*/
-static const struct soc_device_attribute gen3_soc_whitelist[] = {
+static const struct soc_device_attribute soc_whitelist[] = {
/* specific ones */
{ .soc_id = "r8a7795", .revision = "ES1.*",
.data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
@@ -296,6 +297,7 @@ static const struct soc_device_attribute
gen3_soc_whitelist[] = {
.data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
/* generic ones */
{ .soc_id = "r8a774a1" },
+ { .soc_id = "r8a77470" },
{ .soc_id = "r8a7795" },
{ .soc_id = "r8a7796" },
{ .soc_id = "r8a77965" },
@@ -307,7 +309,7 @@ static const struct soc_device_attribute
gen3_soc_whitelist[] = {
static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
{
- const struct soc_device_attribute *soc =
soc_device_match(gen3_soc_whitelist);
+ const struct soc_device_attribute *soc =
soc_device_match(soc_whitelist);
struct device *dev = >dev;
if (!soc)
--
2.7.4
[PATCH v3 0/6] Add uSD and eMMC to iwg23s
Dear All, this new version incorporates Geert's comments. This series applies on top of next-20181005. Thanks, Fab Fabrizio Castro (6): dt-bindings: mmc: renesas_sdhi: Add r8a77470 support pinctrl: sh-pfc: r8a77470: Add SDHI support mmc: renesas_sdhi: Add r8a77470 SDHI1 support ARM: dts: r8a77470: Add SDHI0 support ARM: dts: r8a77470: Add SDHI1 support ARM: dts: iwg23s-sbc: Add uSD and eMMC support Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 +- arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 76 ++ arch/arm/boot/dts/r8a77470.dtsi| 28 +++- drivers/mmc/host/Kconfig | 4 +- drivers/mmc/host/renesas_sdhi_internal_dmac.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162 - 6 files changed, 273 insertions(+), 9 deletions(-) -- 2.7.4
[PATCH v3 6/6] ARM: dts: iwg23s-sbc: Add uSD and eMMC support
Add uSD card and eMMC support to the iwg23s single board
computer powered by the RZ/G1C SoC (a.k.a. r8a77470).
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2->v3:
* No change
v1->v2:
* Added eMMC support as well
* Reworked title and changelog
* Reworked voltage regulators for uSD card on sdhi2
---
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 76 +++
1 file changed, 76 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 22da819..e5cfb50 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -6,6 +6,7 @@
*/
/dts-v1/;
+#include
#include "r8a77470.dtsi"
/ {
model = "iWave iW-RainboW-G23S single board computer based on RZ/G1C";
@@ -25,6 +26,37 @@
device_type = "memory";
reg = <0 0x4000 0 0x2000>;
};
+
+ reg_1p8v: reg-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: reg-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vccq_sdhi2: regulator-vccq-sdhi2 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI2 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = < 24 GPIO_ACTIVE_LOW>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
{
@@ -46,10 +78,28 @@
};
{
+ mmc_pins_uhs: mmc_uhs {
+ groups = "mmc_data8", "mmc_ctrl";
+ function = "mmc";
+ power-source = <1800>;
+ };
+
scif1_pins: scif1 {
groups = "scif1_data_b";
function = "scif1";
};
+
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
};
{
@@ -58,3 +108,29 @@
status = "okay";
};
+
+ {
+ pinctrl-0 = <_pins_uhs>;
+ pinctrl-names = "state_uhs";
+
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_1p8v>;
+ bus-width = <8>;
+ mmc-hs200-1_8v;
+ non-removable;
+ fixed-emmc-driver-type = <1>;
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_sdhi2>;
+ bus-width = <4>;
+ cd-gpios = < 20 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
+ status = "okay";
+};
--
2.7.4
[PATCH v3 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces, SDHI0 and SDHI2 are compatible with R-Car Gen2 SDHIs, and SDHI1 is compatible with R-Car Gen3 SDHIs, as it comes with an internal DMAC, therefore SDHI1 is fully compatible with driver renesas_sdhi_internal_dmac driver. As a result, the compatible strings for the R8A77470 SDHI interfaces are a little bit special. Document SDHI support for the RZ/G1C SoC. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven --- v2->v3: * Incorporated comments from Geert v1->v2: * Added "renesas,sdhi-mmc-r8a77470" * Using generic/fallback compatibilty only for SDHI[02] * Reworked changelog --- Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index d39d5e4..27f2eab 100644 --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -19,6 +19,8 @@ Required properties: "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC "renesas,sdhi-r8a774a1" - SDHI IP on R8A774A1 SoC + "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC + "renesas,sdhi-mmc-r8a77470" - SDHI/MMC IP on R8A77470 SoC "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC @@ -35,8 +37,8 @@ Required properties: "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller - "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 or RZ/G1 - SDHI controller + "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1 SDHI + (not SDHI/MMC) controller "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 or RZ/G2 SDHI controller -- 2.7.4
[PATCH v3 5/6] ARM: dts: r8a77470: Add SDHI1 support
Althought interface SDHI1 found on the RZ/G1C SoC (a.k.a.
r8a77470) is compatible with the R-Car Gen3 ones, its OF
compatibility is restricted to the SoC specific compatible
string to avoid confusion, as from a more generic perspective
the RZ/G1C is sharing the most similarities with the R-Car
Gen2 family of SoCs, and there is a combination of R-Car
Gen2 compatible SDHI IPs and R-Car Gen3 compatible SDHI IP
on this specific chip.
This patch adds the SoC specific part of SDHI1 support, and
since SDHI1 comes with internal DMA, its DT node looks fairly
different from SDHI0 and SDHI2.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2->v3:
* No change
v2:
* New patch
---
arch/arm/boot/dts/r8a77470.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index e01df9c..3e39777 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -427,6 +427,17 @@
status = "disabled";
};
+ sdhi1: sd@ee30 {
+ compatible = "renesas,sdhi-mmc-r8a77470";
+ reg = <0 0xee30 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 313>;
+ max-frequency = <15600>;
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ resets = < 313>;
+ status = "disabled";
+ };
+
sdhi2: sd@ee16 {
compatible = "renesas,sdhi-r8a77470",
"renesas,rcar-gen2-sdhi";
--
2.7.4
RE: [PATCH 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
Hello Geert,
Thank you for your feedback!
> Subject: Re: [PATCH 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Wed, Oct 3, 2018 at 1:06 PM Fabrizio Castro
> wrote:
> > The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces,
> > SDHI0 and SDHI2 are compatible with R-Car Gen2 SDHIs, and
> > SDHI1 is compatible with R-Car Gen3 SDHIs, as it comes with an
> > internal DMAC, therefore SDHI1 is fully compatible with driver
> > renesas_sdhi_internal_dmac driver. As a result, the compatible
> > strings for the R8A77470 SDHI interfaces are a little bit special.
> > Document SDHI support for the RZ/G1C SoC.
> >
> > Signed-off-by: Fabrizio Castro
> > Reviewed-by: Biju Das
> >
> > ---
> > v1->v2:
> > * Added "renesas,sdhi-mmc-r8a77470"
> > * Using generic/fallback compatibilty only for SDHI[02]
> > * Reworked changelog
>
> Thanks for the update!
>
> Reviewed-by: Geert Uytterhoeven
>
> > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > @@ -19,6 +19,8 @@ Required properties:
> > "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC
> > "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > "renesas,sdhi-r8a774a1" - SDHI IP on R8A774A1 SoC
> > + "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC (SDHI[02])
> > + "renesas,sdhi-mmc-r8a77470" - SDHI IP on R8A77470 SoC
> > (SDHI1)
>
> I'm wondering if this would be clearer:
>
>"renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
>"renesas,sdhi-mmc-r8a77470" - SDHI/MMC IP on R8A77470 SoC
>
> > "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
> > @@ -35,8 +37,8 @@ Required properties:
> > "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC
> > "renesas,sdhi-shmobile" - a generic sh-mobile SDHI
> > controller
> > "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI
> > controller
> > - "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 or RZ/G1
> > - SDHI controller
> > + "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1
> > (but
> > + not RZ/G1C SDHI1) SDHI controller
>
> And:
>
>"renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1 SDHI
> (not SDHI/MMC) controller
>
> as it not only applies to RZ/G1C, but also to R-Car E2X (which is not yet
> supported upstream).
>
> > "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 or RZ/G2
> >SDHI controller
>
> What do you think?
It makes sense to me, I will wait for Simon's reply and if he is happy as well
I'll
send a new version incorporating your recommendations (and his, in case he
has any).
Thanks!
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
Hello Simon, Thank you for your feedback! > Subject: Re: [PATCH 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support > > On Wed, Oct 03, 2018 at 12:05:39PM +0100, Fabrizio Castro wrote: > > The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces, > > SDHI0 and SDHI2 are compatible with R-Car Gen2 SDHIs, and > > SDHI1 is compatible with R-Car Gen3 SDHIs, as it comes with an > > internal DMAC, therefore SDHI1 is fully compatible with driver > > renesas_sdhi_internal_dmac driver. As a result, the compatible > > strings for the R8A77470 SDHI interfaces are a little bit special. > > Document SDHI support for the RZ/G1C SoC. > > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Biju Das > > > > --- > > v1->v2: > > * Added "renesas,sdhi-mmc-r8a77470" > > * Using generic/fallback compatibilty only for SDHI[02] > > * Reworked changelog > > --- > > Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > > b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > > index d39d5e4..247abee 100644 > > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > > @@ -19,6 +19,8 @@ Required properties: > > "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC > > "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC > > "renesas,sdhi-r8a774a1" - SDHI IP on R8A774A1 SoC > > +"renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC (SDHI[02]) > > +"renesas,sdhi-mmc-r8a77470" - SDHI IP on R8A77470 SoC (SDHI1) > > I understand that SDHI[02] is different to SDHI1 on this SoC. > But I'm not clear on why SDHI1 is more "mmc" than SDHI[02]. Only SDHI1 can be used as MMC interface, from Section 40.1.1 of the SD Card manual: " This LSI has three SD card interfaces (SDHI0 to SDHI2), one of which can also be used as MMC interfaces (SDHI1)." > > > "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC > > "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC > > "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC > > @@ -35,8 +37,8 @@ Required properties: > > "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC > > "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller > > "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller > > -"renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 or RZ/G1 > > - SDHI controller > > +"renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1 (but > > + not RZ/G1C SDHI1) SDHI controller > > "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 or RZ/G2 > > SDHI controller > > renesas,rcar-gen3-sdhi can be used with RZ/G1C SDHI1, right? It can be used, but when we previously discussed about this I have received bad feedbacks from both yourself and Geert: Geert: "I'm a bit reluctant to add "renesas,rcar-gen3-sdhi", though" You: "I am also reluctant to add "renesas,rcar-gen3-sdhi", because as we are seeing things are not so simple wrt to compatible." We need to make a final decision here, but automatically detecting the IP doesn't seem to be great, so the final solution has to rely on compatible strings. > The naming is starting to break down at this point :( Personally, I am not too bothered about using "renesas,rcar-gen3-sdhi" for this specific IP, as this chip "borrows" Gen3 implementation, but of course it exposes some cross compatibility with other families of products which could result in some confusion to the final user. Anyway, as long as we document things properly there should be no confusion. Thanks, Fab > > > > > -- > > 2.7.4 > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
[PATCH] dt-bindings: arm: Fix RZ/G2E part number
Fix RZ/G2E part number from its description. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das --- Documentation/devicetree/bindings/arm/shmobile.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index f5e0f82..58c4256 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -27,7 +27,7 @@ SoCs: compatible = "renesas,r8a77470" - RZ/G2M (R8A774A1) compatible = "renesas,r8a774a1" - - RZ/G2E (RA8774C0) + - RZ/G2E (R8A774C0) compatible = "renesas,r8a774c0" - R-Car M1A (R8A77781) compatible = "renesas,r8a7778" -- 2.7.4
[PATCH 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI pins
capable of switching voltage, also add pin groups and functions
for SDHI0 and SDHI1. Please note that with the RZ/G1C only 1
bit of the POC Control Register is used to control each interface.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v1->v2:
* Reworked implementation of r8a77470_pin_to_pocctrl as per Wolfram's
and Geert's comments
* Added SDHI0 and SDHI1 pins and IO voltage control
* Added SDHI0 and SDHI1 pin groups and functions
* Reworked changelog and title
* Please note that there is some overlapping between mmc pin groups
and sdhi1 pin groups
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162 +-
1 file changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 3d36e5f..fa0d42b 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -10,14 +10,45 @@
#include "sh_pfc.h"
#define CPU_ALL_PORT(fn, sfx) \
- PORT_GP_23(0, fn, sfx), \
+ PORT_GP_4(0, fn, sfx), \
+ PORT_GP_1(0, 4, fn, sfx), \
+ PORT_GP_CFG_1(0, 5, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 6, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 7, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 8, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 9, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 10, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 11, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 12, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 13, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 20, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 21, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 22, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
PORT_GP_23(1, fn, sfx), \
PORT_GP_32(2, fn, sfx), \
PORT_GP_17(3, fn, sfx), \
PORT_GP_1(3, 27, fn, sfx), \
PORT_GP_1(3, 28, fn, sfx), \
PORT_GP_1(3, 29, fn, sfx), \
- PORT_GP_26(4, fn, sfx), \
+ PORT_GP_14(4, fn, sfx), \
+ PORT_GP_CFG_1(4, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_1(4, 20, fn, sfx), \
+ PORT_GP_1(4, 21, fn, sfx), \
+ PORT_GP_1(4, 22, fn, sfx), \
+ PORT_GP_1(4, 23, fn, sfx), \
+ PORT_GP_1(4, 24, fn, sfx), \
+ PORT_GP_1(4, 25, fn, sfx), \
PORT_GP_32(5, fn, sfx)
enum {
@@ -1619,6 +1650,81 @@ static const unsigned int scif_clk_b_pins[] = {
static const unsigned int scif_clk_b_mux[] = {
SCIF_CLK_B_MARK,
};
+/* - SDHI0 --
*/
+static const unsigned int sdhi0_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(0, 7),
+};
+static const unsigned int sdhi0_data1_mux[] = {
+ SD0_DAT0_MARK,
+};
+static const unsigned int sdhi0_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(0, 7), RCAR_GP_PIN(0, 8),
+ RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 10),
+};
+static const unsigned int sdhi0_data4_mux[] = {
+ SD0_DAT0_MARK, SD0_DAT1_MARK, SD0_DAT2_MARK, SD0_DAT3_MARK,
+};
+static const unsigned int sdhi0_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6)
[PATCH 4/6] ARM: dts: r8a77470: Add SDHI0 support
RZ/G1C comes with two different types of IP for the SDHI
interfaces, SDHI0 and SDHI2 share the same IP type, and
such an IP is also compatible with the one found in R-Car
Gen2. SDHI1 IP on the other hand is compatible with R-Car
Gen3 with internal DMA.
This patch completes the SDHI support of the R-Car Gen2
compatible IPs, including fixing the max-frequency
definition of SDHI2, as it turns out there is a bug in
Section 1.3.9 of the RZ/G1C Hardware User's Manual (Rev.
1.00 Oct. 2017).
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2:
* New patch
---
arch/arm/boot/dts/r8a77470.dtsi | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 9e7f86d..e01df9c 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -412,6 +412,21 @@
status = "disabled";
};
+ sdhi0: sd@ee10 {
+ compatible = "renesas,sdhi-r8a77470",
+"renesas,rcar-gen2-sdhi";
+ reg = <0 0xee10 0 0x328>;
+ interrupts = ;
+ clocks = < CPG_MOD 314>;
+ dmas = < 0xcd>, < 0xce>,
+ < 0xcd>, < 0xce>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <15600>;
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ resets = < 314>;
+ status = "disabled";
+ };
+
sdhi2: sd@ee16 {
compatible = "renesas,sdhi-r8a77470",
"renesas,rcar-gen2-sdhi";
@@ -421,7 +436,7 @@
dmas = < 0xd3>, < 0xd4>,
< 0xd3>, < 0xd4>;
dma-names = "tx", "rx", "tx", "rx";
- max-frequency = <9750>;
+ max-frequency = <7800>;
power-domains = < R8A77470_PD_ALWAYS_ON>;
resets = < 312>;
status = "disabled";
--
2.7.4
[PATCH 5/6] ARM: dts: r8a77470: Add SDHI1 support
Althought interface SDHI1 found on the RZ/G1C SoC (a.k.a.
r8a77470) is compatible with the R-Car Gen3 ones, its OF
compatibility is restricted to the SoC specific compatible
string to avoid confusion, as from a more generic perspective
the RZ/G1C is sharing the most similarities with the R-Car
Gen2 family of SoCs, and there is a combination of R-Car
Gen2 compatible SDHI IPs and R-Car Gen3 compatible SDHI IP
on this specific chip.
This patch adds the SoC specific part of SDHI1 support, and
since SDHI1 comes with internal DMA, its DT node looks fairly
different from SDHI0 and SDHI2.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2:
* New patch
---
arch/arm/boot/dts/r8a77470.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index e01df9c..3e39777 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -427,6 +427,17 @@
status = "disabled";
};
+ sdhi1: sd@ee30 {
+ compatible = "renesas,sdhi-mmc-r8a77470";
+ reg = <0 0xee30 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 313>;
+ max-frequency = <15600>;
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ resets = < 313>;
+ status = "disabled";
+ };
+
sdhi2: sd@ee16 {
compatible = "renesas,sdhi-r8a77470",
"renesas,rcar-gen2-sdhi";
--
2.7.4
[PATCH 3/6] mmc: renesas_sdhi: Add r8a77470 SDHI1 support
The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces,
SDHI0 and SDHI2 are compatible with the R-Car Gen2 SDHIs, SDHI1
is compatible with R-Car Gen3 SDHIs and it can be used as
eMMC as well. This patch adds driver compatibility, and makes
sure both drivers get compiled for the R8A77470.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2:
* New patch
---
drivers/mmc/host/Kconfig | 4 ++--
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 694d082..fb654cd 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -622,9 +622,9 @@ config MMC_SDHI_SYS_DMAC
config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
- depends on ARM64 || COMPILE_TEST
+ depends on ARM64 || ARCH_R8A77470 || COMPILE_TEST
depends on MMC_SDHI
- default MMC_SDHI if ARM64
+ default MMC_SDHI if (ARM64 || ARCH_R8A77470)
help
This provides DMA support for SDHI SD/SDIO controllers
using on-chip bus mastering. This supports the controllers
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index e5e5015..e729c39 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -113,6 +113,7 @@ static const struct renesas_sdhi_of_data
of_rcar_gen3_compatible = {
};
static const struct of_device_id renesas_sdhi_internal_dmac_of_match[] = {
+ { .compatible = "renesas,sdhi-mmc-r8a77470", .data =
_rcar_gen3_compatible, },
{ .compatible = "renesas,sdhi-r8a7795", .data =
_rcar_r8a7795_compatible, },
{ .compatible = "renesas,sdhi-r8a7796", .data =
_rcar_r8a7795_compatible, },
{ .compatible = "renesas,rcar-gen3-sdhi", .data =
_rcar_gen3_compatible, },
@@ -288,7 +289,7 @@ static const struct tmio_mmc_dma_ops
renesas_sdhi_internal_dmac_dma_ops = {
* Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
* implementation as others may use a different implementation.
*/
-static const struct soc_device_attribute gen3_soc_whitelist[] = {
+static const struct soc_device_attribute soc_whitelist[] = {
/* specific ones */
{ .soc_id = "r8a7795", .revision = "ES1.*",
.data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
@@ -296,6 +297,7 @@ static const struct soc_device_attribute
gen3_soc_whitelist[] = {
.data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
/* generic ones */
{ .soc_id = "r8a774a1" },
+ { .soc_id = "r8a77470" },
{ .soc_id = "r8a7795" },
{ .soc_id = "r8a7796" },
{ .soc_id = "r8a77965" },
@@ -307,7 +309,7 @@ static const struct soc_device_attribute
gen3_soc_whitelist[] = {
static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
{
- const struct soc_device_attribute *soc =
soc_device_match(gen3_soc_whitelist);
+ const struct soc_device_attribute *soc =
soc_device_match(soc_whitelist);
struct device *dev = >dev;
if (!soc)
--
2.7.4
[PATCH 6/6] ARM: dts: iwg23s-sbc: Add uSD and eMMC support
Add uSD card and eMMC support to the iwg23s single board
computer powered by the RZ/G1C SoC (a.k.a. r8a77470).
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v1->v2:
* Added eMMC support as well
* Reworked title and changelog
* Reworked voltage regulators for uSD card on sdhi2
---
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 76 +++
1 file changed, 76 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 22da819..e5cfb50 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -6,6 +6,7 @@
*/
/dts-v1/;
+#include
#include "r8a77470.dtsi"
/ {
model = "iWave iW-RainboW-G23S single board computer based on RZ/G1C";
@@ -25,6 +26,37 @@
device_type = "memory";
reg = <0 0x4000 0 0x2000>;
};
+
+ reg_1p8v: reg-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: reg-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vccq_sdhi2: regulator-vccq-sdhi2 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI2 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = < 24 GPIO_ACTIVE_LOW>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
{
@@ -46,10 +78,28 @@
};
{
+ mmc_pins_uhs: mmc_uhs {
+ groups = "mmc_data8", "mmc_ctrl";
+ function = "mmc";
+ power-source = <1800>;
+ };
+
scif1_pins: scif1 {
groups = "scif1_data_b";
function = "scif1";
};
+
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
};
{
@@ -58,3 +108,29 @@
status = "okay";
};
+
+ {
+ pinctrl-0 = <_pins_uhs>;
+ pinctrl-names = "state_uhs";
+
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_1p8v>;
+ bus-width = <8>;
+ mmc-hs200-1_8v;
+ non-removable;
+ fixed-emmc-driver-type = <1>;
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_sdhi2>;
+ bus-width = <4>;
+ cd-gpios = < 20 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
+ status = "okay";
+};
--
2.7.4
[PATCH 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces, SDHI0 and SDHI2 are compatible with R-Car Gen2 SDHIs, and SDHI1 is compatible with R-Car Gen3 SDHIs, as it comes with an internal DMAC, therefore SDHI1 is fully compatible with driver renesas_sdhi_internal_dmac driver. As a result, the compatible strings for the R8A77470 SDHI interfaces are a little bit special. Document SDHI support for the RZ/G1C SoC. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das --- v1->v2: * Added "renesas,sdhi-mmc-r8a77470" * Using generic/fallback compatibilty only for SDHI[02] * Reworked changelog --- Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index d39d5e4..247abee 100644 --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -19,6 +19,8 @@ Required properties: "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC "renesas,sdhi-r8a774a1" - SDHI IP on R8A774A1 SoC + "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC (SDHI[02]) + "renesas,sdhi-mmc-r8a77470" - SDHI IP on R8A77470 SoC (SDHI1) "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC @@ -35,8 +37,8 @@ Required properties: "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller - "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 or RZ/G1 - SDHI controller + "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1 (but + not RZ/G1C SDHI1) SDHI controller "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 or RZ/G2 SDHI controller -- 2.7.4
[PATCH 0/6] Add uSD and eMMC to iwg23s
Dear All, this series includes all that is necessary for uSD and eMMC to work on the iwg23s board, powered by the RZ/G1C (a.k.a. r8a77470). This work applies on top of next-20181002 Thanks, Fab Fabrizio Castro (6): dt-bindings: mmc: renesas_sdhi: Add r8a77470 support pinctrl: sh-pfc: r8a77470: Add SDHI support mmc: renesas_sdhi: Add r8a77470 SDHI1 support ARM: dts: r8a77470: Add SDHI0 support ARM: dts: r8a77470: Add SDHI1 support ARM: dts: iwg23s-sbc: Add uSD and eMMC support Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 +- arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 76 ++ arch/arm/boot/dts/r8a77470.dtsi| 28 +++- drivers/mmc/host/Kconfig | 4 +- drivers/mmc/host/renesas_sdhi_internal_dmac.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162 - 6 files changed, 273 insertions(+), 9 deletions(-) -- 2.7.4
RE: [PATCH v2 1/3] dt-bindings: arm: Document RZ/G2E SoC DT bindings
Hello Simon, > Subject: Re: [PATCH v2 1/3] dt-bindings: arm: Document RZ/G2E SoC DT bindings > > On Fri, Sep 28, 2018 at 11:16:35AM +0100, Fabrizio Castro wrote: > > Add device tree bindings documentation for Renesas RZ/G2E (r8a774c0) > > SoC. > > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Biju Das > > Reviewed-by: Geert Uytterhoeven > > Signed-off-by: Simon Horman > > > > --- > > v1->v2: > > * Fixed typo within the part number, thanks Geert for spotting this > > Unfortunately v1 already went upstream. > > Please send an incremental patch to resolve this problem. Thank you, will do. Cheers, Fab Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support
Hello Simon, > Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support > > On Fri, Sep 28, 2018 at 09:31:16AM +, Fabrizio Castro wrote: > > Hello Simon, > > > > Do you think you can drop this patch or is it too late? > > Unfortunately it was too late. No worries, thank you anyway. Cheers, Fab Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
[PATCH v2 1/3] dt-bindings: arm: Document RZ/G2E SoC DT bindings
Add device tree bindings documentation for Renesas RZ/G2E (r8a774c0) SoC. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das Reviewed-by: Geert Uytterhoeven Signed-off-by: Simon Horman --- v1->v2: * Fixed typo within the part number, thanks Geert for spotting this Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index 4a03a6b..58c4256 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -27,6 +27,8 @@ SoCs: compatible = "renesas,r8a77470" - RZ/G2M (R8A774A1) compatible = "renesas,r8a774a1" + - RZ/G2E (R8A774C0) +compatible = "renesas,r8a774c0" - R-Car M1A (R8A77781) compatible = "renesas,r8a7778" - R-Car H1 (R8A77790) -- 2.7.4
RE: [PATCH 1/3] dt-bindings: arm: Document RZ/G2E SoC DT bindings
Hello Geert,
> Subject: Re: [PATCH 1/3] dt-bindings: arm: Document RZ/G2E SoC DT bindings
>
> On Mon, Sep 10, 2018 at 1:54 PM Fabrizio Castro
> wrote:
> > Add device tree bindings documentation for Renesas RZ/G2E (r8a774c0)
> > SoC.
> >
> > Signed-off-by: Fabrizio Castro
> > Reviewed-by: Biju Das
> > ---
> > Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
> > b/Documentation/devicetree/bindings/arm/shmobile.txt
> > index 4a03a6b..f5e0f82 100644
> > --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> > @@ -27,6 +27,8 @@ SoCs:
> > compatible = "renesas,r8a77470"
> >- RZ/G2M (R8A774A1)
> > compatible = "renesas,r8a774a1"
> > + - RZ/G2E (RA8774C0)
>
> Silly typo no one noticed before: s/A8/8A/
That is a really good catch!
Simon, could you please drop it so that I can send a v2.
Cheers,
Fab
>
> > +compatible = "renesas,r8a774c0"
> >- R-Car M1A (R8A77781)
> > compatible = "renesas,r8a7778"
> >- R-Car H1 (R8A77790)
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support
Hello Simon, Do you think you can drop this patch or is it too late? Cheers, Fab > Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support > > On Sat, Sep 22, 2018 at 08:44:50PM +0200, Wolfram Sang wrote: > > On Fri, Sep 21, 2018 at 12:55:10PM +0100, Fabrizio Castro wrote: > > > Add SoC specific device tree definitions for the SDHI2 interface. > > > > > > Signed-off-by: Fabrizio Castro > > > Reviewed-by: Biju Das > > > > Acked-by: Wolfram Sang > > Thanks, applied for v4.20. Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH v2 3/3] arm64: dts: renesas: r8a774a1: Add CAN nodes
Hello Simon,
> Subject: Re: [PATCH v2 3/3] arm64: dts: renesas: r8a774a1: Add CAN nodes
>
> On Mon, Sep 10, 2018 at 11:43:15AM +0100, Fabrizio Castro wrote:
> > From: Chris Paterson
> >
> > Add the device nodes for both RZ/G2M CAN channels.
> >
> > Signed-off-by: Chris Paterson
> > Reviewed-by: Biju Das
> > ---
> >
> > v1->v2:
> > * replaced "renesas,rzg-gen2-can" with "renesas,rcar-gen3-can" as per
> > Geert's comment.
> >
> > This patch applies on top of renesas-devel-20180906-v4.19-rc2.
>
> Thanks Fabrizio,
>
> I would like to waif for the bindings to be accepted before accepting this
> patch.
Marc has taken the bindings, I guess we can unblock this patch now?
Thanks,
Fab
>
> >
> > arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > index 046fc93..867e875 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > @@ -874,6 +874,30 @@
> > status = "disabled";
> > };
> >
> > +can0: can@e6c3 {
> > +compatible = "renesas,can-r8a774a1",
> > + "renesas,rcar-gen3-can";
> > +reg = <0 0xe6c3 0 0x1000>;
> > +interrupts = ;
> > +clocks = < CPG_MOD 916>, <_clk>;
> > +clock-names = "clkp1", "can_clk";
> > +power-domains = < 32>;
> > +resets = < 916>;
> > +status = "disabled";
> > +};
> > +
> > +can1: can@e6c38000 {
> > +compatible = "renesas,can-r8a774a1",
> > + "renesas,rcar-gen3-can";
> > +reg = <0 0xe6c38000 0 0x1000>;
> > +interrupts = ;
> > +clocks = < CPG_MOD 915>, <_clk>;
> > +clock-names = "clkp1", "can_clk";
> > +power-domains = < 32>;
> > +resets = < 915>;
> > +status = "disabled";
> > +};
> > +
> > pwm0: pwm@e6e3 {
> > compatible = "renesas,pwm-r8a774a1", "renesas,pwm-rcar";
> > reg = <0 0xe6e3 0 0x8>;
> > --
> > 2.7.4
> >
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
Hello Geert,
> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Mon, Sep 24, 2018 at 8:34 PM Fabrizio Castro
> wrote:
> > > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470
> > > support
> > > On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> > > wrote:
> > > > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > > Reviewed-by: Biju Das
>
> > > > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > @@ -17,6 +17,7 @@ Required properties:
> > > > "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> > > > "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> > > > "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > > > + "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> > > > "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > > > "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > > > "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
> > >
> > > It seems RZ/G1C has two slighty different types of SD card interfaces:
> > > 1. SDHI0 and SDHI2 use SYS-DMAC,
> > > 2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
> > >
> > > Do we need to distinguish between them using the compatible value, or
> > > are there other ways?
> >
> > The most sensible thing to do here is probably to distinguish between them
> > using
> > the compatible value, we were thinking about using the following for SDHI1:
> > compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";
> >
> > What do you guys think?
>
> Oh, so it's identical (or "sufficiently compatible") with the SD card
> interface on R-Car Gen3?
It seems identical to R-Car Gen3. I have done proper testing now and everything
seems to be working as expected.
> "renesas,sdhi-mmc-r8a77470" may be a good way to distinguish.
> I'm a bit reluctant to add "renesas,rcar-gen3-sdhi", though.
We could just use "renesas,sdhi-mmc-r8a77470" for SDHI1 and "renesas,sdhi-
r8a77470"
for SDHI0 and SDHI2 then, without generic compatible strings, or maybe we could
use "renesas,rcar-gen2-sdhi" for both even though that would be incorrect as
per the
current implementation of the drivers.
Today I have given some thought on how to distinguish the two types of IP from
the
two different drivers without having driver specific compatible strings, and
unfortunately
we would still need to take into account some information coming from the
device tree
(like the memory address of the interface) in order to decide if we need to
fail the probing.
I can't use the VERSION register to make any decision as to read the registers
in a meaningful
way we still need to know bus_shift, and then the DMA properties are optional,
therefore
using different compatible strings for the two types of IP still feels like the
best option to me.
I am dropping all of the patches from this series and I am going to send
another version
to address the comments on the implementation of r8a77470_pin_to_pocctrl, but
also
to address both SD card and eMMC, so that we can reason about what's the best
thing to do
by looking at the implementation of a working example.
Cheers,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH] ARM: dts: iwg20d-q7-dbcm-ca: Improve model string
> Subject: [PATCH] ARM: dts: iwg20d-q7-dbcm-ca: Improve model string
>
> Update the model string for this platform configuration and fix the
> grammar at the same time.
>
> This brings the syntax in line with the RZ/G1E iWave board.
>
> Signed-off-by: Chris Paterson
Reviewed-by: Fabrizio Castro
> ---
> Perhaps this patch isn't really needed, but the current string annoys me.
>
> Patch applies cleanly to renesas-devel-20180925-v4.19-rc5.
> ---
> arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts
> b/arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts
> index 0d006aea99da1b40..6811ddc4af6460ce 100644
> --- a/arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts
> +++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts
> @@ -11,7 +11,7 @@
> #include "iwg20d-q7-dbcm-ca.dtsi"
>
> / {
> -model = "iW-RainboW-G20D-Q7 RZ/G1M based plus camera daughter board";
> +model = "iWave RainboW-G20D-Q7 RZ/G1M based board with camera add-on";
> compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743";
> };
>
> --
> 1.9.1
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
Hello Geert,
> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Tue, Sep 25, 2018 at 2:45 PM Fabrizio Castro
> wrote:
> > > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470
> > > support
> > > On Tue, Sep 25, 2018 at 10:22 AM Wolfram Sang wrote:
> > > > > > Perhaps stating the obvious: this feels a lot like the problem we
> > > > > > thought
> > > > > > we had with different Gen-3 SoCs/ES versions. And in that case we
> > > > > > decided
> > > > > > against using compat strings to differentiate. The main difference
> > > > > > here
> > > > > > seems to be that we need to differentiate between different ports
> > > > > > on the
> > > > > > same SoC.
> > > >
> > > > Yes, I agree. Our so far agreed solution didn't take into account that
> > > > there are different SDHI versions on the same SoC. Adding a compatible
> > > > might be the easiest solution, but then we have a mix of compatibles,
> > > > soc_device_match, and even version register (deeper in the driver). My
> > > > gut feeling is we should take the time to rethink all this?
> > > >
> > > > > So either
> > > > > a) SDHI0/2 vs. SDHI1 are different, deserving different compatible
> > > > > values, or
> > > > > b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving
> > > > > the same
> > > > > compatible value, but one or more additional properties
> > > > > describing the
> > > > > different wiring.
> > > >
> > > > Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
> > > > have the SDHI specific docs, but from the main docs, all SDHI instances
> > > > are different.
> > >
> > > I forgot about the version register.
> > >
> > > Fabrizio: can you please check what the 3 instances report in their
> > > version
> > > registers? Thanks!
> >
> > SDHI0: 0xcc0d
> > SDHI1: 0xcc10
> > SDHI2: 0xcc0d
>
> Thank you. So SDHI1 differs from SDH0/2.
> SDHI2 probably doesn't support SDR104 because its parent clock is a div6
> clock, while the others have SDCKCR parents.
>
> Plus we don't describe the relation to the SDH clock yet.
I am looking into the remaining SDHI interfaces now, how do you want me to
handle SDHI1?
Thanks,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
Hi Geert,
> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Wolfram,
>
> On Tue, Sep 25, 2018 at 10:22 AM Wolfram Sang wrote:
> > > > Perhaps stating the obvious: this feels a lot like the problem we
> > > > thought
> > > > we had with different Gen-3 SoCs/ES versions. And in that case we
> > > > decided
> > > > against using compat strings to differentiate. The main difference here
> > > > seems to be that we need to differentiate between different ports on the
> > > > same SoC.
> >
> > Yes, I agree. Our so far agreed solution didn't take into account that
> > there are different SDHI versions on the same SoC. Adding a compatible
> > might be the easiest solution, but then we have a mix of compatibles,
> > soc_device_match, and even version register (deeper in the driver). My
> > gut feeling is we should take the time to rethink all this?
> >
> > > So either
> > > a) SDHI0/2 vs. SDHI1 are different, deserving different compatible
> > > values, or
> > > b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the
> > > same
> > > compatible value, but one or more additional properties describing
> > > the
> > > different wiring.
> >
> > Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
> > have the SDHI specific docs, but from the main docs, all SDHI instances
> > are different.
>
> I forgot about the version register.
>
> Fabrizio: can you please check what the 3 instances report in their version
> registers? Thanks!
SDHI0: 0xcc0d
SDHI1: 0xcc10
SDHI2: 0xcc0d
Cheers,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch
Hello Geert, hello Wolfram,
Thank you both for your feedback.
> Subject: Re: [PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch
>
> On Sat, Sep 22, 2018 at 8:44 PM Wolfram Sang wrote:
> > On Fri, Sep 21, 2018 at 12:55:09PM +0100, Fabrizio Castro wrote:
> > > Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI2 pins
> > > capable of switching voltage. Please note that with the
> > > RZ/G1C only 1 bit of the POC Control Register is used to
> > > control each interface.
> > >
> > > Signed-off-by: Fabrizio Castro
> > > Reviewed-by: Biju Das
> >
> > In general:
> >
> > Acked-by: Wolfram Sang
> >
> > > + if (_bank == 4 && _pin >= 14 && _pin <= 19)
> > > + return 1;
> > > +
> > > + return -EINVAL;
> >
> > I'd like a tad better to bail out on the error case and have the main
> > path returning on the good case, but no strong opinion...
>
> And we have these nice RCAR_GP_PIN() macros to check pin ranges.
> Please have a look at the flow in e.g. r8a7795_pin_to_pocctrl().
I'll send a v2 to address this, thank you for pointing me to the right
direction.
Cheers,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
Hello Geert,
> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> wrote:
> > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> >
> > Signed-off-by: Fabrizio Castro
> > Reviewed-by: Biju Das
> > ---
> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > index c434200..8f3a113 100644
> > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > @@ -17,6 +17,7 @@ Required properties:
> > "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> > "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> > "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > + "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> > "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
>
> It seems RZ/G1C has two slighty different types of SD card interfaces:
> 1. SDHI0 and SDHI2 use SYS-DMAC,
> 2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
>
> Do we need to distinguish between them using the compatible value, or
> are there other ways?
The most sensible thing to do here is probably to distinguish between them using
the compatible value, we were thinking about using the following for SDHI1:
compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";
What do you guys think?
I have a prototype for this and it seems to be working fine, but I have only
run some
basic checks at run time on the MMC, that's why I haven't sent anything just
yet.
Thanks,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/4] dt-bindings: i2c: rcar: Add r8a77470 support
Hello Wolfram, > Subject: Re: [PATCH 1/4] dt-bindings: i2c: rcar: Add r8a77470 support > > > > > It seems to me that the RZ/G1C has some extra registers described > > > for I2C when compared with both other RZ/G1 and R-Car Gen2 SoCs. > > > > Exactly. The extra registers found with the RZ/G1C I2C controller are > > also found in R-Car Gen3, but the driver doesn't handle them. R-Car > > Gen3 has more registers on top of those found with the RZ/G1C. > > I don't have he RZ documentation yet, could you name which ones are Gen3 > only? ICDMAER and ICFBSCR are the registers found in R-Car Gen3 but not in RZ/G1C. Thanks, Fab Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
