Re: [PATCH v3 2/2] dt-bindings: watchdog: renesas-wdt: Add support for R7S9210
On Thu, 6 Sep 2018 20:22:43 -0500, Chris Brandt wrote: > Document support for RZ/A2 > > Signed-off-by: Chris Brandt > --- > Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
Re: [PATCH] clocksource: sh_cmt: fix clocksource width for 32-bit machines
On 09/10/2018 11:22 PM, Sergei Shtylyov wrote:
> The driver seems to abuse *unsigned long* not only for the (32-bit)
> register values but also for the 'sh_cmt_channel::total_cycles' which
> needs to always be 64-bit -- as a result, the clocksource's mask is
> needlessly clamped down to 32-bits on the 32-bit machines...
I thought this bug was present from the start but no...
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Sergei Shtylyov
Fixes: 19bdc9d061bc ("clocksource: sh_cmt clocksource support")
[...]
MBR, Sergei
[PATCH] clocksource: sh_cmt: fix clocksource width for 32-bit machines
The driver seems to abuse *unsigned long* not only for the (32-bit)
register values but also for the 'sh_cmt_channel::total_cycles' which
needs to always be 64-bit -- as a result, the clocksource's mask is
needlessly clamped down to 32-bits on the 32-bit machines...
Reported-by: Geert Uytterhoeven
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'tip.git' repo's 'timers/core' branch plus the fixup
for the 64-bit machines reposted last Saturday...
drivers/clocksource/sh_cmt.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: tip/drivers/clocksource/sh_cmt.c
===
--- tip.orig/drivers/clocksource/sh_cmt.c
+++ tip/drivers/clocksource/sh_cmt.c
@@ -108,7 +108,7 @@ struct sh_cmt_channel {
raw_spinlock_t lock;
struct clock_event_device ced;
struct clocksource cs;
- unsigned long total_cycles;
+ u64 total_cycles;
bool cs_enabled;
};
@@ -613,8 +613,8 @@ static u64 sh_cmt_clocksource_read(struc
{
struct sh_cmt_channel *ch = cs_to_sh_cmt(cs);
unsigned long flags;
- unsigned long value;
u32 has_wrapped;
+ u64 value;
u32 raw;
raw_spin_lock_irqsave(>lock, flags);
@@ -688,7 +688,7 @@ static int sh_cmt_register_clocksource(s
cs->disable = sh_cmt_clocksource_disable;
cs->suspend = sh_cmt_clocksource_suspend;
cs->resume = sh_cmt_clocksource_resume;
- cs->mask = CLOCKSOURCE_MASK(sizeof(unsigned long) * 8);
+ cs->mask = CLOCKSOURCE_MASK(sizeof(u64) * 8);
cs->flags = CLOCK_SOURCE_IS_CONTINUOUS;
dev_info(>cmt->pdev->dev, "ch%u: used as clock source\n",
[PATCH v4 0/2] Add support for RZ/A2 wdt
Slightly modify the rza_wdt.c driver and update the binding docs. Chris Brandt (2): watchdog: rza_wdt: Support longer timeouts dt-bindings: watchdog: renesas-wdt: Add support for R7S9210 .../devicetree/bindings/watchdog/renesas-wdt.txt | 1 + drivers/watchdog/rza_wdt.c | 88 +- 2 files changed, 71 insertions(+), 18 deletions(-) -- 2.16.1
[PATCH v4 2/2] dt-bindings: watchdog: renesas-wdt: Add support for R7S9210
Document support for RZ/A2 Signed-off-by: Chris Brandt --- 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 5d47a262474c..45a709dd0345 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt @@ -19,6 +19,7 @@ Required properties: - "renesas,r8a77990-wdt" (R-Car E3) - "renesas,r8a77995-wdt" (R-Car D3) - "renesas,r7s72100-wdt" (RZ/A1) +- "renesas,r7s9210-wdt" (RZ/A2) The generic compatible string must be: - "renesas,rza-wdt" for RZ/A - "renesas,rcar-gen2-wdt" for R-Car Gen2 and RZ/G -- 2.16.1
[PATCH v4 1/2] watchdog: rza_wdt: Support longer timeouts
The RZ/A2 watchdog timer extends the clock source options in order to
allow for longer timeouts.
Signed-off-by: Chris Brandt
---
v4:
* Documented CKS_3BIT/CKS_4BIT better
* Changed 16384 and 4194304 into #define
* Removed rza_wdt.timeout
* Removed extra ( ) from DIV_ROUND_UP
* Removed check for counter value > 256
* Added set_timeout function
* Removed checking for new timeout value in ping function
* Removed unneeded 'else' case when checking .data in probe
v3:
* Removed + 1 from DIV_ROUND_UP line
* resetting to 0 if time to big did not make as much sense are resetting
to 256
v2:
* use DIV_ROUND_UP
* use %u for pr_debug
* use of_match data to determine the size of CKS register
---
drivers/watchdog/rza_wdt.c | 88 --
1 file changed, 70 insertions(+), 18 deletions(-)
diff --git a/drivers/watchdog/rza_wdt.c b/drivers/watchdog/rza_wdt.c
index e618218d2374..aeca6b13c797 100644
--- a/drivers/watchdog/rza_wdt.c
+++ b/drivers/watchdog/rza_wdt.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,12 +35,45 @@
#define WRCSR_RSTE BIT(6)
#define WRCSR_CLEAR_WOVF 0xA500 /* special value */
+/* The maximum CKS register setting value to get the longest timeout */
+#define CKS_3BIT 0x7
+#define CKS_4BIT 0xF
+
+#define DIVIDER_3BIT 16384 /* Clock divider when CKS = 0x7 */
+#define DIVIDER_4BIT 4194304 /* Clock divider when CKS = 0xF */
+
struct rza_wdt {
struct watchdog_device wdev;
void __iomem *base;
struct clk *clk;
+ u8 count;
+ u8 cks;
};
+static void rza_wdt_calc_timeout(struct rza_wdt *priv, int timeout)
+{
+ unsigned long rate = clk_get_rate(priv->clk);
+ unsigned int ticks;
+
+ if (priv->cks == CKS_4BIT) {
+ ticks = DIV_ROUND_UP(timeout * rate, DIVIDER_4BIT);
+
+ /*
+* Since max_timeout was set in probe, we know that the timeout
+* value passed will never calculate to a tick value greater
+* than 256.
+*/
+ priv->count = 256 - ticks;
+
+ } else {
+ /* Start timer with longest timeout */
+ priv->count = 0;
+ }
+
+ pr_debug("%s: timeout set to %u (WTCNT=%d)\n", __func__,
+timeout, priv->count);
+}
+
static int rza_wdt_start(struct watchdog_device *wdev)
{
struct rza_wdt *priv = watchdog_get_drvdata(wdev);
@@ -51,13 +85,12 @@ static int rza_wdt_start(struct watchdog_device *wdev)
readb(priv->base + WRCSR);
writew(WRCSR_CLEAR_WOVF, priv->base + WRCSR);
- /*
-* Start timer with slowest clock source and reset option enabled.
-*/
+ rza_wdt_calc_timeout(priv, wdev->timeout);
+
writew(WRCSR_MAGIC | WRCSR_RSTE, priv->base + WRCSR);
- writew(WTCNT_MAGIC | 0, priv->base + WTCNT);
- writew(WTCSR_MAGIC | WTSCR_WT | WTSCR_TME | WTSCR_CKS(7),
- priv->base + WTCSR);
+ writew(WTCNT_MAGIC | priv->count, priv->base + WTCNT);
+ writew(WTCSR_MAGIC | WTSCR_WT | WTSCR_TME |
+ WTSCR_CKS(priv->cks), priv->base + WTCSR);
return 0;
}
@@ -75,8 +108,17 @@ static int rza_wdt_ping(struct watchdog_device *wdev)
{
struct rza_wdt *priv = watchdog_get_drvdata(wdev);
- writew(WTCNT_MAGIC | 0, priv->base + WTCNT);
+ writew(WTCNT_MAGIC | priv->count, priv->base + WTCNT);
+ pr_debug("%s: timeout = %u\n", __func__, wdev->timeout);
+
+ return 0;
+}
+
+static int rza_set_timeout(struct watchdog_device *wdev, unsigned int timeout)
+{
+ wdev->timeout = timeout;
+ rza_wdt_start(wdev);
return 0;
}
@@ -121,6 +163,7 @@ static const struct watchdog_ops rza_wdt_ops = {
.start = rza_wdt_start,
.stop = rza_wdt_stop,
.ping = rza_wdt_ping,
+ .set_timeout = rza_set_timeout,
.restart = rza_wdt_restart,
};
@@ -150,20 +193,28 @@ static int rza_wdt_probe(struct platform_device *pdev)
return -ENOENT;
}
- /* Assume slowest clock rate possible (CKS=7) */
- rate /= 16384;
-
priv->wdev.info = _wdt_ident,
priv->wdev.ops = _wdt_ops,
priv->wdev.parent = >dev;
- /*
-* Since the max possible timeout of our 8-bit count register is less
-* than a second, we must use max_hw_heartbeat_ms.
-*/
- priv->wdev.max_hw_heartbeat_ms = (1000 * U8_MAX) / rate;
- dev_dbg(>dev, "max hw timeout of %dms\n",
-priv->wdev.max_hw_heartbeat_ms);
+ priv->cks = (unsigned int)of_device_get_match_data(>dev);
+ if (priv->cks == CKS_4BIT) {
+ /* Assume slowest clock rate possible (CKS=0xF) */
+ priv->wdev.max_timeout = (DIVIDER_4BIT * U8_MAX) / rate;
+
+ } else if (priv->cks == CKS_3BIT) {
+ /* Assume slowest clock
Re: [PATCH 2/2] clocksource: sh_cmt: add R-Car gen3 support
On 09/10/2018 10:30 PM, Sergei Shtylyov wrote:
>>> From: devicetree-ow...@vger.kernel.org >> ow...@vger.kernel.org> On Behalf Of Sergei Shtylyov
>>> Sent: 05 September 2018 21:32
>>>
>>> Add support for the R-Car gen3 CMT0 and CMT1 bindings -- they seem to be
>>> the same CMT0 and CMT1 as in R-Car gen2 SoCs. Also document R8A779{7|8}
>>> bindings as these are the R-Car gen3 SoCs for which the initial support was
>>> done.
>>
>> Is it allowed to combine the bindings doc update with the driver change? (I
>> usually get a checkpatch warning for this).
>
>I don't (and have double checked that this patch is checkpatch-clean).
Hm... triple checking has revealed something new: the patch is good only in
the context
of tip.git, 4.19-rc3 based branch from renesas.git complains about the binding
not being
in a separate patch. Well, I have to comply... :-)
[...]
>> Kind regards, Chris
MBR, Sergei
Re: [PATCH 2/2] clocksource: sh_cmt: add R-Car gen3 support
Hello!
On 09/06/2018 11:06 AM, Chris Paterson wrote:
>> From: devicetree-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Sergei Shtylyov
>> Sent: 05 September 2018 21:32
>>
>> Add support for the R-Car gen3 CMT0 and CMT1 bindings -- they seem to be
>> the same CMT0 and CMT1 as in R-Car gen2 SoCs. Also document R8A779{7|8}
>> bindings as these are the R-Car gen3 SoCs for which the initial support was
>> done.
>
> Is it allowed to combine the bindings doc update with the driver change? (I
> usually get a checkpatch warning for this).
I don't (and have double checked that this patch is checkpatch-clean).
> It it's not a problem:
Let's hear what Rob says...
However note that Documentation/devicetree/bindings/timer/ is
listed under the CLOCKSOURCE, CLOCKEVENT DRIVERS entry in MAINTAINERS.
> Reviewed-by: Chris Paterson
Thank you!
> Kind regards, Chris
MBR, Sergei
Re: [PATCH 2/2] clocksource: sh_cmt: add R-Car gen3 support
Hello!
On 09/06/2018 11:27 AM, Biju Das wrote:
>> -Original Message-
>> From: devicetree-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Sergei Shtylyov
>> Sent: 05 September 2018 21:32
>> To: Daniel Lezcano ; Thomas Gleixner
>> ; Rob Herring ;
>> devicet...@vger.kernel.org
>> Cc: linux-renesas-soc@vger.kernel.org; linux...@vger.kernel.org
>> Subject: [PATCH 2/2] clocksource: sh_cmt: add R-Car gen3 support
>>
>> Add support for the R-Car gen3 CMT0 and CMT1 bindings -- they seem to be
>> the same CMT0 and CMT1 as in R-Car gen2 SoCs. Also document R8A779{7|8}
>> bindings as these are the R-Car gen3 SoCs for which the initial support was
>> done.
>>
>> Signed-off-by: Sergei Shtylyov
>>
>> ---
>> Documentation/devicetree/bindings/timer/renesas,cmt.txt |7 +++
>> drivers/clocksource/sh_cmt.c|8
>> 2 files changed, 15 insertions(+)
>>
>> Index: renesas/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> ==
>> =
>> --- renesas.orig/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> +++ renesas/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> @@ -34,6 +34,10 @@ 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,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.
>> +- "renesas,r8a77980-cmt1" for the 48-bit CMT1 device included in
>> r8a77980.
>>
>> - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car
>> Gen2
>> and RZ/G1.
>> @@ -41,6 +45,9 @@ Required Properties:
>> and RZ/G1.
>> These are fallbacks for r8a73a4, R-Car Gen2 and RZ/G1
>> entries
>> listed above.
>> +- "renesas,rcar-gen3-cmt0" for 32-bit CMT0 devices included in R-Car
>> Gen3.
>> +- "renesas,rcar-gen3-cmt1" for 48-bit CMT1 devices included in R-Car
>
> Do we need to mention CMT1/2/3 instead of CMT1, since CMT2/3 is similar to
> CMT1?
Well, the manual only describes CMT0 and CMT1 separately. Perhaps it would
have been
clearer to call them CMTT0 and CMTT1 as they stand for Compare Match Timer Type
0/1?
Note at this point we already have a history of describing CMT0/1 only in the
bindings
as well...
[...]
MBR, Sergei
Re: [PATCH v4] clk: renesas: cpg-mssr: Add R7S9210 support
On Fri, Sep 07, 2018 at 11:58:49AM -0500, Chris Brandt wrote:
> Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> Standby.
>
> The Module Standby HW in the RZ/A series is very close to R-Car HW, except
> for how the registers are laid out.
> The MSTP registers are only 8-bits wide, there is no status registers
> (MSTPSR), and the register offsets are a little different. Since the RZ/A
> hardware manuals refer to these registers as the Standby Control Registers,
> we'll use that name to distinguish the RZ/A type from the R-Car type.
>
> Signed-off-by: Chris Brandt
> ---
> v4:
> * Preserved sort order of SoC listings
> * Removed R7S9210_CLK_PLL from dt-binding since it's an internal clock
> * ratio_tab is now a struct making it look a little nicer
> * Removed CLK_I,...CLK_P0 because they are already defined in dt-bindings
> * Sorted mod_clks by ascending MSTP number
> * Removed cast from clk_get_rate(parent)
> * Corrected register index of stbcr[1]
> * Don't use MOD_CLK_PACK_10 for non priv->stbyctrl devices (bug fix)
> v3:
> * Use actual register bit names and numbers from manual for both DT and
>tables ("36" instead of "306")
> * Do not register reset controller for stbyctrl (RZ/A) SoCs
> * Changed SPDX from "GPL-2.0+" to "GPL-2.0"
> v2:
> * num_hw_mod_clks was wrong
> * added ethernet clocks
> ---
> .../devicetree/bindings/clock/renesas,cpg-mssr.txt | 5 +-
> drivers/clk/renesas/Kconfig| 5 +
> drivers/clk/renesas/Makefile | 1 +
> drivers/clk/renesas/r7s9210-cpg-mssr.c | 189
> +
> drivers/clk/renesas/renesas-cpg-mssr.c | 81 +++--
> drivers/clk/renesas/renesas-cpg-mssr.h | 13 ++
> include/dt-bindings/clock/r7s9210-cpg-mssr.h | 20 +++
For DT bits,
Acked-by: Rob Herring
> 7 files changed, 300 insertions(+), 14 deletions(-)
> create mode 100644 drivers/clk/renesas/r7s9210-cpg-mssr.c
> create mode 100644 include/dt-bindings/clock/r7s9210-cpg-mssr.h
Re: [PATCH v2 4/8] media: rcar-csi2: Add R8A77990 support
Hi Jacopo,
Thanks for your patch.
On 2018-09-05 17:29:41 +0200, Jacopo Mondi wrote:
> Add support for R-Car E3 R8A77965 to R-Car CSI-2 driver.
> Based on the experimental patch from Magnus Damm.
>
> Signed-off-by: Jacopo Mondi
Acked-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index dc5ae80..f82b668 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -959,6 +959,11 @@ static const struct rcar_csi2_info
> rcar_csi2_info_r8a77970 = {
> .confirm_start = rcsi2_confirm_start_v3m_e3,
> };
>
> +static const struct rcar_csi2_info rcar_csi2_info_r8a77990 = {
> + .init_phtw = rcsi2_init_phtw_v3m_e3,
> + .confirm_start = rcsi2_confirm_start_v3m_e3,
> +};
> +
> static const struct of_device_id rcar_csi2_of_table[] = {
> {
> .compatible = "renesas,r8a7795-csi2",
> @@ -976,6 +981,10 @@ static const struct of_device_id rcar_csi2_of_table[] = {
> .compatible = "renesas,r8a77970-csi2",
> .data = _csi2_info_r8a77970,
> },
> + {
> + .compatible = "renesas,r8a77990-csi2",
> + .data = _csi2_info_r8a77990,
> + },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, rcar_csi2_of_table);
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
Re: [PATCH v2 3/8] media: dt-bindings: rcar-csi2: Add R8A77990
Hi Jacopo, Thanks for your patch. On 2018-09-05 17:29:40 +0200, Jacopo Mondi wrote: > Add compatible string for R-Car E3 R8A77990 to the list of supported SoCs. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Rob Herring Acked-by: Niklas Söderlund > --- > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > index 2d385b6..2824489 100644 > --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > @@ -12,6 +12,7 @@ Mandatory properties > - "renesas,r8a7796-csi2" for the R8A7796 device. > - "renesas,r8a77965-csi2" for the R8A77965 device. > - "renesas,r8a77970-csi2" for the R8A77970 device. > + - "renesas,r8a77990-csi2" for the R8A77990 device. > > - reg: the register base and size for the device registers > - interrupts: the interrupt for the device > -- > 2.7.4 > -- Regards, Niklas Söderlund
Re: [PATCH v2 2/8] media: rcar-vin: Add support for R-Car R8A77990
Hi Jacopo,
Thanks for for work.
On 2018-09-05 17:29:39 +0200, Jacopo Mondi wrote:
> Add R-Car E3 R8A77990 SoC to the rcar-vin supported ones.
> Based on the experimental patch from Magnus Damm.
>
> Signed-off-by: Jacopo Mondi
Acked-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index ce09799..d443c09 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1085,6 +1085,22 @@ static const struct rvin_info rcar_info_r8a77970 = {
> .routes = rcar_info_r8a77970_routes,
> };
>
> +static const struct rvin_group_route rcar_info_r8a77990_routes[] = {
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 4, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a77990 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = rcar_info_r8a77990_routes,
> +};
> +
> static const struct rvin_group_route rcar_info_r8a77995_routes[] = {
> { /* Sentinel */ }
> };
> @@ -1143,6 +1159,10 @@ static const struct of_device_id rvin_of_id_table[] = {
> .data = _info_r8a77970,
> },
> {
> + .compatible = "renesas,vin-r8a77990",
> + .data = _info_r8a77990,
> + },
> + {
> .compatible = "renesas,vin-r8a77995",
> .data = _info_r8a77995,
> },
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
Re: [PATCH v2 1/8] media: dt-bindings: rcar-vin: Add R8A77990 support
Hi Jacopo, Thanks for your patch. On 2018-09-05 17:29:38 +0200, Jacopo Mondi wrote: > Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by > rcar-vin driver. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Rob Herring Acked-by: Niklas Söderlund > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > b/Documentation/devicetree/bindings/media/rcar_vin.txt > index 2f42005..dfd6058 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -23,6 +23,7 @@ on Gen3 platforms to a CSI-2 receiver. > - "renesas,vin-r8a7796" for the R8A7796 device > - "renesas,vin-r8a77965" for the R8A77965 device > - "renesas,vin-r8a77970" for the R8A77970 device > + - "renesas,vin-r8a77990" for the R8A77990 device > - "renesas,vin-r8a77995" for the R8A77995 device > - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible > device. > -- > 2.7.4 > -- Regards, Niklas Söderlund
RE: [PATCH v3 1/2] watchdog: rza_wdt: Support longer timeouts
On Monday, September 10, 2018, Guenter Roeck wrote: > > If you really don't like checking in .ping, I can add a set_timeout > > function and remove the local priv->timeout. > > > > No, I do not like checking and setting the timeout in the ping function > at all. That is what the set_timeout function is for, and I don't see > a point in bypassing the infrastructure. OK. I will add a set_timeout and resubmit. Chris
Re: [PATCH v3 1/2] watchdog: rza_wdt: Support longer timeouts
On Mon, Sep 10, 2018 at 05:36:39PM +, Chris Brandt wrote:
> On Monday, September 10, 2018 1, Guenter Roeck wrote:
> > > #2. If the CKS is only 4-bits, the max HW timeout is 32 seconds. (so
> > > 'timeout' can never be more that a u8).
> > >
> > That is not the point. The point is that there is no need to keep two
> > 'timeout' variables.
>
> But there was a reason.
>
> The reason was that the upper layer would call the .ping() function
> without calling .start() again.
>
> Meaning it would change 'timeout' in the structure, but not explicitly
> tell the driver.
>
It does that because there is no set_timeout function.
> That why I had to keep track of my own timeout (what the HW was actually
> set to).
>
> Every time the upper layer calls .ping(), I have to see if the timeout
> field still matches.
>
>
> > > The number "4194304" is exactly how it is documented in the hardware
> > > manual, that is why I'm using it that way. Yes, 0x40 makes more
> > > sense, but I like matching the device documenting as much as possible to
> > > help the next person that comes along and has to debug this code.
> > >
> > Use at least a define.
>
> OK.
>
>
> > > Because when I was doing all my testing, I found cases where '.ping' was
> > > called from the upper layer without '.start' being called first. So, I
> > > changed the code as you see it now. This guaranteed I would also get the
> > > timeout the user was requesting.
> > >
> > That would only happen if the watchdog is considered to be running.
> > Also, we are talking about the set_timeout function which is the one which
> > should set the timeout and update the HW if needed, ie if the watchdog is
> > already running.
>
> This driver doesn't have .set_timeout
>
> static const struct watchdog_ops rza_wdt_ops = {
> .owner = THIS_MODULE,
> .start = rza_wdt_start,
> .stop = rza_wdt_stop,
> .ping = rza_wdt_ping,
> .restart = rza_wdt_restart,
> };
>
It wasn't needed before, but that doesn't mean it is not needed now.
>
> If you really don't like checking in .ping, I can add a set_timeout
> function and remove the local priv->timeout.
>
No, I do not like checking and setting the timeout in the ping function
at all. That is what the set_timeout function is for, and I don't see
a point in bypassing the infrastructure.
Guenter
RE: [PATCH v3 1/2] watchdog: rza_wdt: Support longer timeouts
On Monday, September 10, 2018 1, Guenter Roeck wrote:
> > #2. If the CKS is only 4-bits, the max HW timeout is 32 seconds. (so
> > 'timeout' can never be more that a u8).
> >
> That is not the point. The point is that there is no need to keep two
> 'timeout' variables.
But there was a reason.
The reason was that the upper layer would call the .ping() function
without calling .start() again.
Meaning it would change 'timeout' in the structure, but not explicitly
tell the driver.
That why I had to keep track of my own timeout (what the HW was actually
set to).
Every time the upper layer calls .ping(), I have to see if the timeout
field still matches.
> > The number "4194304" is exactly how it is documented in the hardware
> > manual, that is why I'm using it that way. Yes, 0x40 makes more
> > sense, but I like matching the device documenting as much as possible to
> > help the next person that comes along and has to debug this code.
> >
> Use at least a define.
OK.
> > Because when I was doing all my testing, I found cases where '.ping' was
> > called from the upper layer without '.start' being called first. So, I
> > changed the code as you see it now. This guaranteed I would also get the
> > timeout the user was requesting.
> >
> That would only happen if the watchdog is considered to be running.
> Also, we are talking about the set_timeout function which is the one which
> should set the timeout and update the HW if needed, ie if the watchdog is
> already running.
This driver doesn't have .set_timeout
static const struct watchdog_ops rza_wdt_ops = {
.owner = THIS_MODULE,
.start = rza_wdt_start,
.stop = rza_wdt_stop,
.ping = rza_wdt_ping,
.restart = rza_wdt_restart,
};
If you really don't like checking in .ping, I can add a set_timeout
function and remove the local priv->timeout.
Chris
RE: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration
On Monday, September 10, 2018, Rob Herring wrote: > > The current OSTM driver uses TIMER_OF_DECLARE and that basically means > > it will never work with my new SoC. > > > > For now, can I change the driver to register a standard platform driver > > in subsys_initcall like the other Renesas timer drivers? > > I'm confused how this can even work as an initcall. The whole reason > *_OF_DECLARE exists is for things that have to be setup before > initcalls. I wrote a long explanation of the issue, but the summary is: The timer (which is currently using TIMER_OF_DECLARE) can't start up until the clocks are set up because of_clk_get fails(). But, the clock driver is a platform driver that is not started until subsys_initcall. So, unless you have a clock driver with CLK_OF_DECLARE, you can't use a timer driver with a TIMER_OF_DECLARE driver. And, there is no such thing as a deferred probe for timer drivers declared with IMER_OF_DECLARE. Chris
Re: [PATCH v3 1/2] watchdog: rza_wdt: Support longer timeouts
On Mon, Sep 10, 2018 at 01:53:28PM +, Chris Brandt wrote:
> On Saturday, September 08, 2018 1, Guenter Roeck wrote:
> > > +#define CKS_3BIT 0x7
> > > +#define CKS_4BIT 0xF
> >
> > Any special reason for the value of those defines ? They are just used as
> > flags,
> > or am I missing something ? Why not just use 0 / 1 or an enum ?
>
> Geert's suggestion was:
>
> >> I suggest storing cks in rza_wdt_of_match[].data, and
> >> retrieving it with of_device_get_match_data() in your
> >> probe function...
>
> So now I just literally read in the value I want to write into CKS
> register in the probe function.
>
> priv->cks = (unsigned int)of_device_get_match_data(>dev);
>
> And since I want to slowest clock source (CKS) possible, that's '0x7' if
> CKS is only 3 bits, and '0xF' if CKS is 4 bits.
> I can add a comment above the #define to explain my reasoning.
>
Yes, that would help.
>
> > > struct rza_wdt {
> > > struct watchdog_device wdev;
> > > void __iomem *base;
> > > struct clk *clk;
> > > + u8 count;
> > > + u8 cks;
> > > + u8 timeout;
> >
> > Hmm ... this limits the effective timeout to 255 seconds. That seems odd.
> > Maybe it is true in practice, if the clock is always guaranteed to be
> > above 4194304 Hz, but it is an odd assumption that isn't really reflected
> > in the code.
>
> I can change that to something else like u16.
>
Sorry, I see no point ion 1) keeping this a separate variable and not using
the one in the watchdog data structure.
> In reality, there are 2 variations of HW:
>
> #1. If the CKS is only 3-bits, the max HW timeout is 200ms, so I'm
> setting 'max_hw_heartbeat_ms' and then the use can set a timeout as long as
> they want (but it's not really a true HW watchdog).
>
> #2. If the CKS is only 4-bits, the max HW timeout is 32 seconds. (so
> 'timeout' can never be more that a u8).
>
That is not the point. The point is that there is no need to keep two
'timeout' variables.
>
> > > + if (priv->cks == CKS_4BIT) {
> > > + ticks = DIV_ROUND_UP((timeout * rate), 4194304);
> >
> > The ( ) around timeout * rate is unnecessary.
>
> Yes, you're right.
>
>
> > Also, it would be nice
> > to have a define and explanation for 4194304 (and 0x40 would probably
> > be a better value to use).
>
> The number "4194304" is exactly how it is documented in the hardware
> manual, that is why I'm using it that way. Yes, 0x40 makes more
> sense, but I like matching the device documenting as much as possible to
> help the next person that comes along and has to debug this code.
>
Use at least a define.
>
> > > + if (ticks > 256)
> > > + ticks = 256;
> >
> > If you keep this, you should as well recalculate timeout since it won't
> > match the expected value.
> >
> > if (ticks > 256) {
> > ticks = 256;
> > timeout = ticks * 4194304 / rate;
> > }
>
> That's a good point!
>
>
> > Not that it can ever happen, since max_timeout limits the value.
> > Personally I would rather see this dropped with a comment stating that
> > ticks <= 256 is guaranteed by max_timeout; I am not a friend of dead code
> > in the kernel.
>
> I agree. I will drop this code and put a comment.
>
>
> > > @@ -75,7 +103,12 @@ static int rza_wdt_ping(struct watchdog_device
> > *wdev)
> > > {
> > > struct rza_wdt *priv = watchdog_get_drvdata(wdev);
> > >
> > > - writew(WTCNT_MAGIC | 0, priv->base + WTCNT);
> > > + if (priv->timeout != wdev->timeout)
> > > + rza_wdt_calc_timeout(priv, wdev->timeout);
> > > +
> > FWIW, odd way of updating the timeout. Why not do it in the set_timeout()
> > function where it belongs. Which makes me wonder why priv->timeout is
> > needed
> > in the first place (and why it is u8 - as mentioned above).
>
> Because when I was doing all my testing, I found cases where '.ping' was
> called from the upper layer without '.start' being called first. So, I
> changed the code as you see it now. This guaranteed I would also get the
> timeout the user was requesting.
>
That would only happen if the watchdog is considered to be running.
Also, we are talking about the set_timeout function which is the one which
should set the timeout and update the HW if needed, ie if the watchdog is
already running.
>
> > > + writew(WTCNT_MAGIC | priv->count, priv->base + WTCNT);
> > > +
> > > + pr_debug("%s: timeout = %u\n", __func__, wdev->timeout);
> > >
> >
> > Do you really want this displayed with each ping, even as debug message ?
> > Just wondering.
>
> This is how you can see that sometimes '.ping' is called without '.start'
> being called first.
>
If that happens and the watchdog was not already started, it would be
a bug that would affect all watchdog drivers. If that is the case,
working around it in a driver is most definitely the wrong solution.
Guenter
[PATCH v2] ARM: dts: r9a06g032: Correct UART and add all other UARTs
- UART0 was missing the bus clock ("apb_pclk").
- Now that the relevant rzn1 bindings have been added, replace the Synopsys
compat string with the rzn1 strings.
- Add all the other UARTs.
Signed-off-by: Phil Edworthy
---
v2:
- Keep the "snps,dw-apb-uart" fallback for uarts 0..2 as these are unmodified
peripherals.
---
arch/arm/boot/dts/r9a06g032.dtsi | 83 ++--
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 3e45375b79aa..eaf94976ed6d 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -78,13 +78,90 @@
};
uart0: serial@4006 {
- compatible = "snps,dw-apb-uart";
+ compatible = "renesas,r9a06g032-uart",
"renesas,rzn1-uart", "snps,dw-apb-uart";
reg = <0x4006 0x400>;
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
- clocks = < R9A06G032_CLK_UART0>;
- clock-names = "baudclk";
+ clocks = < R9A06G032_CLK_UART0>, <
R9A06G032_HCLK_UART0>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart1: serial@40061000 {
+ compatible = "renesas,r9a06g032-uart",
"renesas,rzn1-uart", "snps,dw-apb-uart";
+ reg = <0x40061000 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = < R9A06G032_CLK_UART1>, <
R9A06G032_HCLK_UART1>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart2: serial@40062000 {
+ compatible = "renesas,r9a06g032-uart",
"renesas,rzn1-uart", "snps,dw-apb-uart";
+ reg = <0x40062000 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = < R9A06G032_CLK_UART2>, <
R9A06G032_HCLK_UART2>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart3: serial@5000 {
+ compatible = "renesas,r9a06g032-uart",
"renesas,rzn1-uart";
+ reg = <0x5000 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = < R9A06G032_CLK_UART3>, <
R9A06G032_HCLK_UART3>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart4: serial@50001000 {
+ compatible = "renesas,r9a06g032-uart",
"renesas,rzn1-uart";
+ reg = <0x50001000 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = < R9A06G032_CLK_UART4>, <
R9A06G032_HCLK_UART4>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart5: serial@50002000 {
+ compatible = "renesas,r9a06g032-uart",
"renesas,rzn1-uart";
+ reg = <0x50002000 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = < R9A06G032_CLK_UART5>, <
R9A06G032_HCLK_UART5>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart6: serial@50003000 {
+ compatible = "renesas,r9a06g032-uart",
"renesas,rzn1-uart";
+ reg = <0x50003000 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = < R9A06G032_CLK_UART6>, <
R9A06G032_HCLK_UART6>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart7: serial@50004000 {
+ compatible = "renesas,r9a06g032-uart",
"renesas,rzn1-uart";
+ reg = <0x50004000 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = < R9A06G032_CLK_UART7>, <
R9A06G032_HCLK_UART7>;
+ clock-names = "baudclk", "apb_pclk";
status = "disabled";
};
--
[PATCH 0/2] Add RZ/G2E RST support
Dear All, this series adds RST support for the RZ/G2E SoC. It applies on top of renesas-devel-20180906-v4.19-rc2. Thanks, Fab Fabrizio Castro (2): dt-bindings: reset: rcar-rst: Document r8a774c0 rst soc: renesas: rcar-rst: Add support for RZ/G2E Documentation/devicetree/bindings/reset/renesas,rst.txt | 1 + drivers/soc/renesas/Kconfig | 6 +++--- drivers/soc/renesas/rcar-rst.c | 1 + 3 files changed, 5 insertions(+), 3 deletions(-) -- 2.7.4
[PATCH 1/2] dt-bindings: reset: rcar-rst: Document r8a774c0 rst
Document bindings for the RZ/G2E (a.k.a. R8A774C0) reset module. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das --- Documentation/devicetree/bindings/reset/renesas,rst.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt index e4fe0ab..25e6db5 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.txt +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt @@ -19,6 +19,7 @@ Required properties: - "renesas,r8a7745-rst" (RZ/G1E) - "renesas,r8a77470-rst" (RZ/G1C) - "renesas,r8a774a1-rst" (RZ/G2M) + - "renesas,r8a774c0-rst" (RZ/G2E) - "renesas,r8a7778-reset-wdt" (R-Car M1A) - "renesas,r8a7779-reset-wdt" (R-Car H1) - "renesas,r8a7790-rst" (R-Car H2) -- 2.7.4
[PATCH 3/3] dt-bindings: power: rcar-sysc: Document r8a774c0 sysc
Document bindings for the RZ/G2E (a.k.a. R8A774C0) system controller. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das --- Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt index 4e3ec6a..4cb97d4 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt @@ -11,6 +11,7 @@ Required properties: - "renesas,r8a7745-sysc" (RZ/G1E) - "renesas,r8a77470-sysc" (RZ/G1C) - "renesas,r8a774a1-sysc" (RZ/G2M) + - "renesas,r8a774c0-sysc" (RZ/G2E) - "renesas,r8a7779-sysc" (R-Car H1) - "renesas,r8a7790-sysc" (R-Car H2) - "renesas,r8a7791-sysc" (R-Car M2-W) -- 2.7.4
[PATCH 0/3] Add RZ/G2E SYSC support
Dear All, this series adds SYSC support for RZ/G2E SoC (a.k.a. r8a774c0). Thanks, Fab Fabrizio Castro (3): dt-bindings: power: Add r8a774c0 SYSC power domain definitions soc: renesas: rcar-sysc: Add r8a774c0 support dt-bindings: power: rcar-sysc: Document r8a774c0 sysc .../bindings/power/renesas,rcar-sysc.txt | 1 + drivers/soc/renesas/Kconfig| 5 ++ drivers/soc/renesas/Makefile | 1 + drivers/soc/renesas/r8a774c0-sysc.c| 68 ++ drivers/soc/renesas/rcar-sysc.c| 3 + drivers/soc/renesas/rcar-sysc.h| 1 + include/dt-bindings/power/r8a774c0-sysc.h | 25 7 files changed, 104 insertions(+) create mode 100644 drivers/soc/renesas/r8a774c0-sysc.c create mode 100644 include/dt-bindings/power/r8a774c0-sysc.h -- 2.7.4
[PATCH 2/3] soc: renesas: rcar-sysc: Add r8a774c0 support
Add support for the RZ/G2E (R8A774C0) SoC power areas to the
R-Car SYSC driver.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/soc/renesas/Kconfig | 5 +++
drivers/soc/renesas/Makefile| 1 +
drivers/soc/renesas/r8a774c0-sysc.c | 68 +
drivers/soc/renesas/rcar-sysc.c | 3 ++
drivers/soc/renesas/rcar-sysc.h | 1 +
5 files changed, 78 insertions(+)
create mode 100644 drivers/soc/renesas/r8a774c0-sysc.c
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 00d4c9d..163e666 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -10,6 +10,7 @@ config SOC_RENESAS
select SYSC_R8A7745 if ARCH_R8A7745
select SYSC_R8A77470 if ARCH_R8A77470
select SYSC_R8A774A1 if ARCH_R8A774A1
+ select SYSC_R8A774C0 if ARCH_R8A774C0
select SYSC_R8A7779 if ARCH_R8A7779
select SYSC_R8A7790 if ARCH_R8A7790
select SYSC_R8A7791 if ARCH_R8A7791 || ARCH_R8A7793
@@ -42,6 +43,10 @@ config SYSC_R8A774A1
bool "RZ/G2M System Controller support" if COMPILE_TEST
select SYSC_RCAR
+config SYSC_R8A774C0
+ bool "RZ/G2E System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
config SYSC_R8A7779
bool "R-Car H1 System Controller support" if COMPILE_TEST
select SYSC_RCAR
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 6adb9d6..3bdd7db 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_SYSC_R8A7743) += r8a7743-sysc.o
obj-$(CONFIG_SYSC_R8A7745) += r8a7745-sysc.o
obj-$(CONFIG_SYSC_R8A77470)+= r8a77470-sysc.o
obj-$(CONFIG_SYSC_R8A774A1)+= r8a774a1-sysc.o
+obj-$(CONFIG_SYSC_R8A774C0)+= r8a774c0-sysc.o
obj-$(CONFIG_SYSC_R8A7779) += r8a7779-sysc.o
obj-$(CONFIG_SYSC_R8A7790) += r8a7790-sysc.o
obj-$(CONFIG_SYSC_R8A7791) += r8a7791-sysc.o
diff --git a/drivers/soc/renesas/r8a774c0-sysc.c
b/drivers/soc/renesas/r8a774c0-sysc.c
new file mode 100644
index 000..e1ac4c0
--- /dev/null
+++ b/drivers/soc/renesas/r8a774c0-sysc.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas RZ/G2E System Controller
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ *
+ * Based on Renesas R-Car E3 System Controller
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "rcar-sysc.h"
+
+static struct rcar_sysc_area r8a774c0_areas[] __initdata = {
+ { "always-on", 0, 0, R8A774C0_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
+ { "ca53-scu", 0x140, 0, R8A774C0_PD_CA53_SCU, R8A774C0_PD_ALWAYS_ON,
+ PD_SCU },
+ { "ca53-cpu0", 0x200, 0, R8A774C0_PD_CA53_CPU0, R8A774C0_PD_CA53_SCU,
+ PD_CPU_NOCR },
+ { "ca53-cpu1", 0x200, 1, R8A774C0_PD_CA53_CPU1, R8A774C0_PD_CA53_SCU,
+ PD_CPU_NOCR },
+ { "a3vc", 0x380, 0, R8A774C0_PD_A3VC, R8A774C0_PD_ALWAYS_ON },
+ { "a2vc1", 0x3c0, 1, R8A774C0_PD_A2VC1,R8A774C0_PD_A3VC },
+ { "3dg-a", 0x100, 0, R8A774C0_PD_3DG_A,R8A774C0_PD_ALWAYS_ON },
+ { "3dg-b", 0x100, 1, R8A774C0_PD_3DG_B,R8A774C0_PD_3DG_A },
+};
+
+static void __init rcar_sysc_fix_parent(struct rcar_sysc_area *areas,
+ unsigned int num_areas, u8 id,
+ int new_parent)
+{
+ unsigned int i;
+
+ for (i = 0; i < num_areas; i++)
+ if (areas[i].isr_bit == id) {
+ areas[i].parent = new_parent;
+ return;
+ }
+}
+
+/* Fixups for RZ/G2E ES1.0 revision */
+static const struct soc_device_attribute r8a774c0[] __initconst = {
+ { .soc_id = "r8a774c0", .revision = "ES1.0" },
+ { /* sentinel */ }
+};
+
+static int __init r8a774c0_sysc_init(void)
+{
+ if (soc_device_match(r8a774c0)) {
+ rcar_sysc_fix_parent(r8a774c0_areas,
+ARRAY_SIZE(r8a774c0_areas),
+R8A774C0_PD_3DG_A, R8A774C0_PD_3DG_B);
+ rcar_sysc_fix_parent(r8a774c0_areas,
+ARRAY_SIZE(r8a774c0_areas),
+R8A774C0_PD_3DG_B, R8A774C0_PD_ALWAYS_ON);
+ }
+
+ return 0;
+}
+
+const struct rcar_sysc_info r8a774c0_sysc_info __initconst = {
+ .init = r8a774c0_sysc_init,
+ .areas = r8a774c0_areas,
+ .num_areas = ARRAY_SIZE(r8a774c0_areas),
+};
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index fe32f7a..e63d7a2 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -278,6 +278,9 @@ static const struct of_device_id rcar_sysc_matches[]
__initconst = {
#ifdef CONFIG_SYSC_R8A774A1
{ .compatible = "renesas,r8a774a1-sysc", .data = _sysc_info },
#endif
+#ifdef CONFIG_SYSC_R8A774C0
+ { .compatible = "renesas,r8a774c0-sysc", .data =
[PATCH 1/3] dt-bindings: power: Add r8a774c0 SYSC power domain definitions
This patch adds power domain indices for RZ/G2E. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das --- include/dt-bindings/power/r8a774c0-sysc.h | 25 + 1 file changed, 25 insertions(+) create mode 100644 include/dt-bindings/power/r8a774c0-sysc.h diff --git a/include/dt-bindings/power/r8a774c0-sysc.h b/include/dt-bindings/power/r8a774c0-sysc.h new file mode 100644 index 000..9922d4c --- /dev/null +++ b/include/dt-bindings/power/r8a774c0-sysc.h @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (C) 2018 Renesas Electronics Corp. + */ +#ifndef __DT_BINDINGS_POWER_R8A774C0_SYSC_H__ +#define __DT_BINDINGS_POWER_R8A774C0_SYSC_H__ + +/* + * These power domain indices match the numbers of the interrupt bits + * representing the power areas in the various Interrupt Registers + * (e.g. SYSCISR, Interrupt Status Register) + */ + +#define R8A774C0_PD_CA53_CPU0 5 +#define R8A774C0_PD_CA53_CPU1 6 +#define R8A774C0_PD_A3VC 14 +#define R8A774C0_PD_3DG_A 17 +#define R8A774C0_PD_3DG_B 18 +#define R8A774C0_PD_CA53_SCU 21 +#define R8A774C0_PD_A2VC1 26 + +/* Always-on power area */ +#define R8A774C0_PD_ALWAYS_ON 32 + +#endif /* __DT_BINDINGS_POWER_R8A774C0_SYSC_H__ */ -- 2.7.4
[PATCH 5/5] arm64: dts: renesas: r8a774a1: Add VIN and CSI-2 nodes
Add VIN and CSI-2 nodes to RZ/G2M SoC dtsi.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 367 ++
1 file changed, 367 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d9005cb..43db993 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1127,6 +1127,262 @@
status = "disabled";
};
+ vin0: video@e6ef {
+ compatible = "renesas,vin-r8a774a1";
+ reg = <0 0xe6ef 0 0x1000>;
+ interrupts = ;
+ clocks = < CPG_MOD 811>;
+ power-domains = < 32>;
+ resets = < 811>;
+ renesas,id = <0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <1>;
+
+ vin0csi20: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <>;
+ };
+ vin0csi40: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <>;
+ };
+ };
+ };
+ };
+
+ vin1: video@e6ef1000 {
+ compatible = "renesas,vin-r8a774a1";
+ reg = <0 0xe6ef1000 0 0x1000>;
+ interrupts = ;
+ clocks = < CPG_MOD 810>;
+ power-domains = < 32>;
+ resets = < 810>;
+ renesas,id = <1>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <1>;
+
+ vin1csi20: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <>;
+ };
+ vin1csi40: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <>;
+ };
+ };
+ };
+ };
+
+ vin2: video@e6ef2000 {
+ compatible = "renesas,vin-r8a774a1";
+ reg = <0 0xe6ef2000 0 0x1000>;
+ interrupts = ;
+ clocks = < CPG_MOD 809>;
+ power-domains = < 32>;
+ resets = < 809>;
+ renesas,id = <2>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <1>;
+
+ vin2csi20: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <>;
+ };
+ vin2csi40: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <>;
+ };
+ };
+ };
+ };
+
+ vin3: video@e6ef3000 {
+ compatible = "renesas,vin-r8a774a1";
+ reg = <0 0xe6ef3000 0 0x1000>;
+ interrupts = ;
+ clocks = < CPG_MOD 808>;
+ power-domains = < 32>;
+ resets = < 808>;
+ renesas,id = <3>;
+ status = "disabled";
+
+ ports {
+
Re: [PATCH 3/3] soc: renesas: Identify RZ/G2E
On Mon, Sep 10, 2018 at 1:54 PM Fabrizio Castro
wrote:
> Add support for identifying the RZ/G2E (r8a774c0) SoC.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/3] arm64: Add Renesas R8A774C0 support
On Mon, Sep 10, 2018 at 1:54 PM Fabrizio Castro
wrote:
> Add configuration option for the RZ/G2E (R8A774C0) SoC.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
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
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Chris,
On Mon, Sep 10, 2018 at 4:16 PM Chris Brandt wrote:
> On Monday, September 10, 2018 1, Geert Uytterhoeven wrote:
> > Reviewed-by: Geert Uytterhoeven
> > i.e. will queue in clk-renesas-for-v4.20.
>
> Thank you!
>
> Now that I have a clock, I can go ahead and submit a Device Tree.
> However, I still don't have a solution for my OSTM timer driver when
> using this new clock driver architecture.
>
> Should I remove the ostm entries in r7s9210_mod_clks[] before you queue
> it up?
I see no issue with converting the OSTM driver to a platform driver (assumed
it works for you ;-)
> > One possible area for improvement is removing the unused entries in the
> > module clocks part of the priv->clks[] array:
> >
> > + .num_hw_mod_clks = 11 * 32, /* includes STBCR0 which doesn't exist
> > */
> >
> > Due to having 8-bit instead of 32-bit registers, 11 * 24 entries are not
> > used.
> > Fixing that means adding more checks in several functions, though, so I
> > don't know if you want to go that far...
>
> That's basically why I didn't touch it. I didn't see any big benefit
> from a system resource point of view.
OK, so you are aware of it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] dt-bindings: timer: renesas: tmu: document R8A779{7|8}0 bindings
Hi Sergei,
On Fri, Sep 7, 2018 at 10:03 PM Sergei Shtylyov
wrote:
> Document the R-Car V3{M|H} (R8A779{7|8}0) SoC in the Renesas TMU bindings;
> the TMU hardware in those is the Renesas standard 3-channel timer unit.
>
> Signed-off-by: Sergei Shtylyov
Thanks for your patch!
Not all channels seem to be identical, but the driver just matches against
the "renesas,tmu" fallback?
In addition, the V3H TMU seems to differ from the TMU in other R-Car Gen3
variants?
How is this handled?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 8/8] arm64: dts: renesas: ebisu: Add HDMI and CVBS input
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:45 EEST Jacopo Mondi wrote:
> Add HDMI and CVBS inputs device nodes to R-Car E3 Ebisu board.
>
> Both HDMI and CVBS inputs are connected to an ADV7482 video decoder hooked
> to the SoC CSI-2 receiver port.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 +++
> 1 file changed, 86 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts index 2bc3a48..d2faf3e
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -28,6 +28,29 @@
> /* first 128MB is reserved for secure area. */
> reg = <0x0 0x4800 0x0 0x3800>;
> };
> +
> + cvbs-in {
> + compatible = "composite-video-connector";
> + label = "CVBS IN";
> +
> + port {
> + cvbs_con: endpoint {
> + remote-endpoint = <_ain7>;
> + };
> + };
> + };
> +
> + hdmi-in {
> + compatible = "hdmi-connector";
> + label = "HDMI IN";
> + type = "a";
> +
> + port {
> + hdmi_in_con: endpoint {
> + remote-endpoint = <_hdmi>;
> + };
> + };
> + };
> };
>
> {
> @@ -47,6 +70,22 @@
> };
> };
>
> + {
> + status = "okay";
> +
> + ports {
> + port@0 {
> + reg = <0>;
> +
> + csi40_in: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + remote-endpoint = <_txa>;
> + };
> + };
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -55,6 +94,49 @@
> clock-frequency = <4800>;
> };
>
> + {
> + status = "okay";
> +
> + video-receiver@70 {
> + compatible = "adi,adv7482";
> + reg = <0x70>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + interrupt-parent = <>;
> + interrupt-names = "intrq1", "intrq2";
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>,
> + <17 IRQ_TYPE_LEVEL_LOW>;
> +
> + port@7 {
> + reg = <7>;
> +
> + adv7482_ain7: endpoint {
> + remote-endpoint = <_con>;
> + };
> + };
> +
> + port@8 {
> + reg = <8>;
> +
> + adv7482_hdmi: endpoint {
> + remote-endpoint = <_in_con>;
> + };
> + };
> +
> + port@a {
> + reg = <0xa>;
> +
> + adv7482_txa: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -94,6 +176,10 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
--
Regards,
Laurent Pinchart
RE: [PATCH v4] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Geert, On Monday, September 10, 2018 1, Geert Uytterhoeven wrote: > Reviewed-by: Geert Uytterhoeven > i.e. will queue in clk-renesas-for-v4.20. Thank you! Now that I have a clock, I can go ahead and submit a Device Tree. However, I still don't have a solution for my OSTM timer driver when using this new clock driver architecture. Should I remove the ostm entries in r7s9210_mod_clks[] before you queue it up? > One possible area for improvement is removing the unused entries in the > module clocks part of the priv->clks[] array: > > + .num_hw_mod_clks = 11 * 32, /* includes STBCR0 which doesn't exist > */ > > Due to having 8-bit instead of 32-bit registers, 11 * 24 entries are not > used. > Fixing that means adding more checks in several functions, though, so I > don't know if you want to go that far... That's basically why I didn't touch it. I didn't see any big benefit from a system resource point of view. Chris
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> From: Koji Matsuoka
>
> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device tree.
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> 1 file changed, 79 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -337,6 +337,85 @@
> status = "disabled";
> };
>
> + csi40: csi2@feaa {
I believe Simon would like to keep the nodes sorted by address
> + compatible = "renesas,r8a77990-csi2",
> "renesas,rcar-gen3-csi2";
> + reg = <0 0xfeaa 0 0x1>;
0x1 seems pretty large to me.
Apart from that,
Reviewed-by: Laurent Pinchart
> + interrupts = ;
> + clocks = < CPG_MOD 716>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 716>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <1>;
> +
> + csi40vin4: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <>;
> + };
> + csi40vin5: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <>;
> + };
> + };
> + };
> + };
> +
> + vin4: video@e6ef4000 {
> + compatible = "renesas,vin-r8a77990";
> + reg = <0 0xe6ef4000 0 0x1000>;
> + interrupts = ;
> + clocks = < CPG_MOD 807>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 807>;
> + renesas,id = <4>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + vin4csi40: endpoint {
> + remote-endpoint= <>;
> + };
> + };
> + };
> + };
> +
> + vin5: video@e6ef5000 {
> + compatible = "renesas,vin-r8a77990";
> + reg = <0 0xe6ef5000 0 0x1000>;
> + interrupts = ;
> + clocks = < CPG_MOD 806>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 806>;
> + renesas,id = <5>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + vin5csi40: endpoint {
> + remote-endpoint= <>;
> + };
> + };
> + };
> + };
> +
> scif2: serial@e6e88000 {
> compatible = "renesas,scif-r8a77990",
>"renesas,rcar-gen3-scif", "renesas,scif";
--
Regards,
Laurent Pinchart
Re: [PATCH] soc: renesas: convert to SPDX identifiers
On Fri, Sep 7, 2018 at 5:06 AM Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] clk: renesas: r8a77970: add TMU clocks
On Thu, Sep 6, 2018 at 10:28 PM Sergei Shtylyov
wrote:
> The TMU clocks weren't present in the original R8A77970 patch by Daisuke
> Matsushita, they were added in a later BSP version...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
i.e. will queue in clk-renesas-for-v4.20.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 4/8] media: rcar-csi2: Add R8A77990 support
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:41 EEST Jacopo Mondi wrote:
> Add support for R-Car E3 R8A77965 to R-Car CSI-2 driver.
> Based on the experimental patch from Magnus Damm.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c index dc5ae80..f82b668 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -959,6 +959,11 @@ static const struct rcar_csi2_info
> rcar_csi2_info_r8a77970 = { .confirm_start = rcsi2_confirm_start_v3m_e3,
> };
>
> +static const struct rcar_csi2_info rcar_csi2_info_r8a77990 = {
> + .init_phtw = rcsi2_init_phtw_v3m_e3,
> + .confirm_start = rcsi2_confirm_start_v3m_e3,
> +};
> +
> static const struct of_device_id rcar_csi2_of_table[] = {
> {
> .compatible = "renesas,r8a7795-csi2",
> @@ -976,6 +981,10 @@ static const struct of_device_id rcar_csi2_of_table[] =
> { .compatible = "renesas,r8a77970-csi2",
> .data = _csi2_info_r8a77970,
> },
> + {
> + .compatible = "renesas,r8a77990-csi2",
> + .data = _csi2_info_r8a77990,
> + },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, rcar_csi2_of_table);
--
Regards,
Laurent Pinchart
Re: [PATCH v4] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Chris,
On Fri, Sep 7, 2018 at 6:59 PM Chris Brandt wrote:
> Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> Standby.
>
> The Module Standby HW in the RZ/A series is very close to R-Car HW, except
> for how the registers are laid out.
> The MSTP registers are only 8-bits wide, there is no status registers
> (MSTPSR), and the register offsets are a little different. Since the RZ/A
> hardware manuals refer to these registers as the Standby Control Registers,
> we'll use that name to distinguish the RZ/A type from the R-Car type.
>
> Signed-off-by: Chris Brandt
> ---
> v4:
> * Preserved sort order of SoC listings
> * Removed R7S9210_CLK_PLL from dt-binding since it's an internal clock
> * ratio_tab is now a struct making it look a little nicer
> * Removed CLK_I,...CLK_P0 because they are already defined in dt-bindings
> * Sorted mod_clks by ascending MSTP number
> * Removed cast from clk_get_rate(parent)
> * Corrected register index of stbcr[1]
> * Don't use MOD_CLK_PACK_10 for non priv->stbyctrl devices (bug fix)
Thanks for the update!
Reviewed-by: Geert Uytterhoeven
i.e. will queue in clk-renesas-for-v4.20.
One possible area for improvement is removing the unused entries in the
module clocks part of the priv->clks[] array:
+ .num_hw_mod_clks = 11 * 32, /* includes STBCR0 which doesn't exist */
Due to having 8-bit instead of 32-bit registers, 11 * 24 entries are not used.
Fixing that means adding more checks in several functions, though, so I
don't know if you want to go that far...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/8] media: dt-bindings: rcar-csi2: Add R8A77990
Hi Jacopo, Thank you for the patch. On Wednesday, 5 September 2018 18:29:40 EEST Jacopo Mondi wrote: > Add compatible string for R-Car E3 R8A77990 to the list of supported SoCs. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt index > 2d385b6..2824489 100644 > --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > @@ -12,6 +12,7 @@ Mandatory properties > - "renesas,r8a7796-csi2" for the R8A7796 device. > - "renesas,r8a77965-csi2" for the R8A77965 device. > - "renesas,r8a77970-csi2" for the R8A77970 device. > + - "renesas,r8a77990-csi2" for the R8A77990 device. > > - reg: the register base and size for the device registers > - interrupts: the interrupt for the device -- Regards, Laurent Pinchart
Re: [PATCH v2 2/8] media: rcar-vin: Add support for R-Car R8A77990
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:39 EEST Jacopo Mondi wrote:
> Add R-Car E3 R8A77990 SoC to the rcar-vin supported ones.
> Based on the experimental patch from Magnus Damm.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index ce09799..d443c09 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1085,6 +1085,22 @@ static const struct rvin_info rcar_info_r8a77970 = {
> .routes = rcar_info_r8a77970_routes,
> };
>
> +static const struct rvin_group_route rcar_info_r8a77990_routes[] = {
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 4, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a77990 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = rcar_info_r8a77990_routes,
> +};
> +
> static const struct rvin_group_route rcar_info_r8a77995_routes[] = {
> { /* Sentinel */ }
> };
> @@ -1143,6 +1159,10 @@ static const struct of_device_id rvin_of_id_table[] =
> { .data = _info_r8a77970,
> },
> {
> + .compatible = "renesas,vin-r8a77990",
> + .data = _info_r8a77990,
> + },
> + {
> .compatible = "renesas,vin-r8a77995",
> .data = _info_r8a77995,
> },
--
Regards,
Laurent Pinchart
Re: [PATCH v2 1/8] media: dt-bindings: rcar-vin: Add R8A77990 support
Hi Jacopo, Thank you for the patch. On Wednesday, 5 September 2018 18:29:38 EEST Jacopo Mondi wrote: > Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by > rcar-vin driver. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > b/Documentation/devicetree/bindings/media/rcar_vin.txt index > 2f42005..dfd6058 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -23,6 +23,7 @@ on Gen3 platforms to a CSI-2 receiver. > - "renesas,vin-r8a7796" for the R8A7796 device > - "renesas,vin-r8a77965" for the R8A77965 device > - "renesas,vin-r8a77970" for the R8A77970 device > + - "renesas,vin-r8a77990" for the R8A77990 device > - "renesas,vin-r8a77995" for the R8A77995 device > - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible > device. -- Regards, Laurent Pinchart
RE: [PATCH v3 1/2] watchdog: rza_wdt: Support longer timeouts
On Saturday, September 08, 2018 1, Guenter Roeck wrote:
> > +#define CKS_3BIT 0x7
> > +#define CKS_4BIT 0xF
>
> Any special reason for the value of those defines ? They are just used as
> flags,
> or am I missing something ? Why not just use 0 / 1 or an enum ?
Geert's suggestion was:
>> I suggest storing cks in rza_wdt_of_match[].data, and
>> retrieving it with of_device_get_match_data() in your
>> probe function...
So now I just literally read in the value I want to write into CKS
register in the probe function.
priv->cks = (unsigned int)of_device_get_match_data(>dev);
And since I want to slowest clock source (CKS) possible, that's '0x7' if
CKS is only 3 bits, and '0xF' if CKS is 4 bits.
I can add a comment above the #define to explain my reasoning.
> > struct rza_wdt {
> > struct watchdog_device wdev;
> > void __iomem *base;
> > struct clk *clk;
> > + u8 count;
> > + u8 cks;
> > + u8 timeout;
>
> Hmm ... this limits the effective timeout to 255 seconds. That seems odd.
> Maybe it is true in practice, if the clock is always guaranteed to be
> above 4194304 Hz, but it is an odd assumption that isn't really reflected
> in the code.
I can change that to something else like u16.
In reality, there are 2 variations of HW:
#1. If the CKS is only 3-bits, the max HW timeout is 200ms, so I'm
setting 'max_hw_heartbeat_ms' and then the use can set a timeout as long as
they want (but it's not really a true HW watchdog).
#2. If the CKS is only 4-bits, the max HW timeout is 32 seconds. (so
'timeout' can never be more that a u8).
> > + if (priv->cks == CKS_4BIT) {
> > + ticks = DIV_ROUND_UP((timeout * rate), 4194304);
>
> The ( ) around timeout * rate is unnecessary.
Yes, you're right.
> Also, it would be nice
> to have a define and explanation for 4194304 (and 0x40 would probably
> be a better value to use).
The number "4194304" is exactly how it is documented in the hardware
manual, that is why I'm using it that way. Yes, 0x40 makes more
sense, but I like matching the device documenting as much as possible to
help the next person that comes along and has to debug this code.
> > + if (ticks > 256)
> > + ticks = 256;
>
> If you keep this, you should as well recalculate timeout since it won't
> match the expected value.
>
> if (ticks > 256) {
> ticks = 256;
> timeout = ticks * 4194304 / rate;
> }
That's a good point!
> Not that it can ever happen, since max_timeout limits the value.
> Personally I would rather see this dropped with a comment stating that
> ticks <= 256 is guaranteed by max_timeout; I am not a friend of dead code
> in the kernel.
I agree. I will drop this code and put a comment.
> > @@ -75,7 +103,12 @@ static int rza_wdt_ping(struct watchdog_device
> *wdev)
> > {
> > struct rza_wdt *priv = watchdog_get_drvdata(wdev);
> >
> > - writew(WTCNT_MAGIC | 0, priv->base + WTCNT);
> > + if (priv->timeout != wdev->timeout)
> > + rza_wdt_calc_timeout(priv, wdev->timeout);
> > +
> FWIW, odd way of updating the timeout. Why not do it in the set_timeout()
> function where it belongs. Which makes me wonder why priv->timeout is
> needed
> in the first place (and why it is u8 - as mentioned above).
Because when I was doing all my testing, I found cases where '.ping' was
called from the upper layer without '.start' being called first. So, I
changed the code as you see it now. This guaranteed I would also get the
timeout the user was requesting.
> > + writew(WTCNT_MAGIC | priv->count, priv->base + WTCNT);
> > +
> > + pr_debug("%s: timeout = %u\n", __func__, wdev->timeout);
> >
>
> Do you really want this displayed with each ping, even as debug message ?
> Just wondering.
This is how you can see that sometimes '.ping' is called without '.start'
being called first.
> > + if (priv->cks == CKS_4BIT) {
> > + /* Assume slowest clock rate possible (CKS=0xF) */
> > + priv->wdev.max_timeout = (4194304 * U8_MAX) / rate;
> > +
> > + } else if (priv->cks == CKS_3BIT) {
> > + /* Assume slowest clock rate possible (CKS=7) */
> > + rate /= 16384;
> > +
> > + /*
> > +* Since the max possible timeout of our 8-bit count
> > +* register is less than a second, we must use
> > +* max_hw_heartbeat_ms.
> > +*/
> > + priv->wdev.max_hw_heartbeat_ms = (1000 * U8_MAX) / rate;
> > + dev_dbg(>dev, "max hw timeout of %dms\n",
> > +priv->wdev.max_hw_heartbeat_ms);
> > + } else {
> > + dev_err(>dev, "invalid CKS value (%u)\n", priv->cks);
> > + return -EINVAL;
> > + }
>
> I don't really see the point of this else statement. It is pretty much
> dead code,
> and the message is quite useless for the user.
Good point. The only time you would hit this is if you
Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration
On Fri, Sep 7, 2018 at 10:16 AM Chris Brandt wrote: > > On Thursday, August 30, 2018, Daniel Lezcano wrote: > > > AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE. > > > IMHO it would be pointless, as it would be much easier to just switch to > > real > > > platform drivers. > > > > May be, may be not. > > > > From your point of view, the change is simple because it touches only a > > single driver. > > > > From my point of view, the change implies a split in the approach while > > I'm trying to unify the drivers little by little and there are hundred > > of them. > > > > It is not the first time we face this situation and Bartosz Golaszewski > > has a similar problem [1]. > > > > We have all the frameworks we need to solve this properly but I would > > like something we can propagate to all drivers (OF and !OF) so we end up > > with unified code. > > > > It is time we clearly state the dependency issues and we find a proper > > way to solve it. > > > On Thursday, August 30, 2018, Bartosz Golaszewski wrote: > > This was my latest proposal for early platform drivers: > > > > https://lkml.org/lkml/2018/5/11/488 > > > > I still intend on continuing this work, I just don't have the time right > > now. > > Daniel, > > So what is your final thought on this? > > The current OSTM driver uses TIMER_OF_DECLARE and that basically means > it will never work with my new SoC. > > For now, can I change the driver to register a standard platform driver > in subsys_initcall like the other Renesas timer drivers? I'm confused how this can even work as an initcall. The whole reason *_OF_DECLARE exists is for things that have to be setup before initcalls. Rob
Re: [PATCH v3] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Chris,
On Thu, Sep 6, 2018 at 4:31 PM Chris Brandt wrote:
> > What about other clocks: BSCCLK, OCTCLK, HYPCLK, and SPICLK?
>
> At this time, I'm considering them 'out of scope' from this driver as
> they really need to be set up early in device boot (ie, u-boot).
> Unless you were just thinking of adding them as #defines, but never
> really using them.
OK, you can always add them later, when the need arises.
include/dt-bindings/clock/*.h is append-only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] pinctrl: rza1: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 02:13:48AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman
Re: [PATCH] power: reset: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 02:15:08AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman
Re: [PATCH] pwm: rcar: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 02:06:36AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman
Re: [PATCH] ARM: shmobile: convert to SPDX identifiers
On Fri, Sep 7, 2018 at 5:00 AM Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] pwm: renesas-tpu: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 02:06:15AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman
Re: [PATCH] soc: renesas: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 02:04:19AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH] dma: sh: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 01:58:59AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman
Re: [PATCH] dt-bindings: renesas: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 01:52:28AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text on Renesas related headers. > > Signed-off-by: Kuninori Morimoto Thanks Morimoto-san, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH] ARM: shmobile: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 01:43:23AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman
Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
On Wed, Sep 05, 2018 at 05:29:42PM +0200, Jacopo Mondi wrote:
> This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 250
> ++
> 1 file changed, 250 insertions(+)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> index b81c807..0797940 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> @@ -1831,6 +1831,194 @@ static const unsigned int usb30_id_mux[] = {
> USB3HS0_ID_MARK,
> };
>
> +/* - VIN4
> --- */
> +static const union vin_data vin4_data_a_pins = {
> + .data24 = {
> + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
> + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
> + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
> + },
> +};
> +
> +static const union vin_data vin4_data_a_mux = {
> + .data24 = {
> + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> + VI4_DATA8_MARK, VI4_DATA9_MARK,
> + VI4_DATA10_MARK, VI4_DATA11_MARK,
> + VI4_DATA12_MARK, VI4_DATA13_MARK,
> + VI4_DATA14_MARK, VI4_DATA15_MARK,
> + VI4_DATA16_MARK, VI4_DATA17_MARK,
> + VI4_DATA18_MARK, VI4_DATA19_MARK,
> + VI4_DATA20_MARK, VI4_DATA21_MARK,
> + VI4_DATA22_MARK, VI4_DATA23_MARK,
> + },
> +};
> +
> +static const union vin_data vin4_data_b_pins = {
> + .data24 = {
> + RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
> + RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
> + RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
> + RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
I am curious to know why the data B pins below (8 - 23)
are duplicates of the corresponding data A pins in vin4_data_a_pins.
> + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
> + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 15),
> + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
> + },
> +};
> +
> +static const union vin_data vin4_data_b_mux = {
> + .data24 = {
> + VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
> + VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
> + VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
> + VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
> + VI4_DATA8_MARK, VI4_DATA9_MARK,
> + VI4_DATA10_MARK, VI4_DATA11_MARK,
> + VI4_DATA12_MARK, VI4_DATA13_MARK,
> + VI4_DATA14_MARK, VI4_DATA15_MARK,
> + VI4_DATA16_MARK, VI4_DATA17_MARK,
> + VI4_DATA18_MARK, VI4_DATA19_MARK,
> + VI4_DATA20_MARK, VI4_DATA21_MARK,
> + VI4_DATA22_MARK, VI4_DATA23_MARK,
> + },
> +};
> +
> +static const unsigned int vin4_sync_pins[] = {
> + /* HSYNC, VSYNC */
> + RCAR_GP_PIN(2, 25), RCAR_GP_PIN(2, 24),
> +};
> +
> +static const unsigned int vin4_sync_mux[] = {
> + VI4_HSYNC_N_MARK, VI4_VSYNC_N_MARK,
> +};
> +
> +static const unsigned int vin4_field_pins[] = {
> + RCAR_GP_PIN(2, 23),
> +};
> +
> +static const unsigned int vin4_field_mux[] = {
> + VI4_FIELD_MARK,
> +};
> +
> +static const unsigned int vin4_clkenb_pins[] = {
> + RCAR_GP_PIN(1, 2),
> +};
> +
> +static const unsigned int vin4_clkenb_mux[] = {
> + VI4_CLKENB_MARK,
> +};
> +
> +static const unsigned int vin4_clk_pins[] = {
> + RCAR_GP_PIN(2, 22),
> +};
> +
> +static const unsigned int vin4_clk_mux[] = {
> + VI4_CLK_MARK,
> +};
> +
> +/* - VIN5
> --- */
> +static const union vin_data vin5_data_a_pins = {
> + .data16 = {
> + RCAR_GP_PIN(1, 1), RCAR_GP_PIN(1, 2),
> + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 12),
> + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
> + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> + RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
> + RCAR_GP_PIN(0,
Re: [PATCH] pinctrl: sh-pfc: convert to SPDX identifiers
On Fri, Sep 7, 2018 at 4:13 AM Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.20.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/8] media: dt-bindings: rcar-csi2: Add R8A77990
On Wed, Sep 05, 2018 at 05:29:40PM +0200, Jacopo Mondi wrote: > Add compatible string for R-Car E3 R8A77990 to the list of supported SoCs. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Rob Herring Reviewed-by: Simon Horman > --- > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > index 2d385b6..2824489 100644 > --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > @@ -12,6 +12,7 @@ Mandatory properties > - "renesas,r8a7796-csi2" for the R8A7796 device. > - "renesas,r8a77965-csi2" for the R8A77965 device. > - "renesas,r8a77970-csi2" for the R8A77970 device. > + - "renesas,r8a77990-csi2" for the R8A77990 device. > > - reg: the register base and size for the device registers > - interrupts: the interrupt for the device > -- > 2.7.4 >
Re: [PATCH v2 1/8] media: dt-bindings: rcar-vin: Add R8A77990 support
On Wed, Sep 05, 2018 at 05:29:38PM +0200, Jacopo Mondi wrote: > Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by > rcar-vin driver. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Rob Herring Reviewed-by: Simon Horman
[PATCH 3/3] soc: renesas: Identify RZ/G2E
Add support for identifying the RZ/G2E (r8a774c0) SoC.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/soc/renesas/renesas-soc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/renesas/renesas-soc.c
b/drivers/soc/renesas/renesas-soc.c
index ce19b27..d9a30b5 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -124,6 +124,11 @@ static const struct renesas_soc soc_rz_g2m __initconst
__maybe_unused = {
.id = 0x52,
};
+static const struct renesas_soc soc_rz_g2e __initconst __maybe_unused = {
+ .family = _rzg2,
+ .id = 0x57,
+};
+
static const struct renesas_soc soc_rcar_m1a __initconst __maybe_unused = {
.family = _rcar_gen1,
};
@@ -230,6 +235,9 @@ static const struct of_device_id renesas_socs[] __initconst
= {
#ifdef CONFIG_ARCH_R8A774A1
{ .compatible = "renesas,r8a774a1", .data = _rz_g2m },
#endif
+#ifdef CONFIG_ARCH_R8A774C0
+ { .compatible = "renesas,r8a774c0", .data = _rz_g2e },
+#endif
#ifdef CONFIG_ARCH_R8A7778
{ .compatible = "renesas,r8a7778", .data = _rcar_m1a },
#endif
--
2.7.4
[PATCH 2/3] arm64: Add Renesas R8A774C0 support
Add configuration option for the RZ/G2E (R8A774C0) SoC. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das --- arch/arm64/Kconfig.platforms | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index b2e513e..0b65c03 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -170,6 +170,12 @@ config ARCH_R8A774A1 help This enables support for the Renesas RZ/G2M SoC. +config ARCH_R8A774C0 + bool "Renesas RZ/G2E SoC Platform" + depends on ARCH_RENESAS + help + This enables support for the Renesas RZ/G2E SoC. + config ARCH_R8A7795 bool "Renesas R-Car H3 SoC Platform" depends on ARCH_RENESAS -- 2.7.4
[PATCH 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 --- 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) +compatible = "renesas,r8a774c0" - R-Car M1A (R8A77781) compatible = "renesas,r8a7778" - R-Car H1 (R8A77790) -- 2.7.4
[PATCH 0/3] Add basic definitions for RZ/G2E
Dear All, this series adds basic identification for the RZ/G2E (a.k.a. r8a774c0). It applies on top of renesas-devel-20180906-v4.19-rc2. Thanks, Fab Fabrizio Castro (3): dt-bindings: arm: Document RZ/G2E SoC DT bindings arm64: Add Renesas R8A774C0 support soc: renesas: Identify RZ/G2E Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++ arch/arm64/Kconfig.platforms | 6 ++ drivers/soc/renesas/renesas-soc.c | 8 3 files changed, 16 insertions(+) -- 2.7.4
[PATCH v2 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support
Document RZ/G2M (r8a774a1) SoC specific bindings. Signed-off-by: Fabrizio Castro Signed-off-by: Chris Paterson Reviewed-by: Biju Das --- v1->v2: * dropped "renesas,rzg-gen2-can" and fixed "clocks" property description as per Geert's comments. This patch applies on top of next-20180910. Documentation/devicetree/bindings/net/can/rcar_can.txt | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt index 94a7f33..f3b160c 100644 --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt @@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings Required properties: - compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC. "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. + "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC. "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. @@ -16,15 +17,21 @@ Required properties: "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 compatible device. - "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device. + "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2 + compatible device. When compatible with the generic version, nodes must list the SoC-specific version corresponding to the platform first followed by the generic version. - reg: physical base address and size of the R-Car CAN register map. - interrupts: interrupt specifier for the sole interrupt. -- clocks: phandles and clock specifiers for 3 CAN clock inputs. -- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk". +- clocks: phandles and clock specifiers for 2 CAN clock inputs for RZ/G2 + devices. + phandles and clock specifiers for 3 CAN clock inputs for every other + SoC. +- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk". + 3 clock input name strings for every other SoC: "clkp1", "clkp2", + "can_clk". - pinctrl-0: pin control group to be used for this controller. - pinctrl-names: must be "default". @@ -41,8 +48,9 @@ using the below properties: Optional properties: - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are: <0x0> (default) : Peripheral clock (clkp1) - <0x1> : Peripheral clock (clkp2) - <0x3> : Externally input clock + <0x1> : Peripheral clock (clkp2) (not supported by + RZ/G2 devices) + <0x3> : External input clock Example --- -- 2.7.4
[PATCH v2 3/3] arm64: dts: renesas: r8a774a1: Add CAN nodes
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.
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
Re: [PATCH] arm64: dts: renesas: r8a779{7|8}0: add TMU support
On Fri, Sep 07, 2018 at 11:14:40PM +0300, Sergei Shtylyov wrote:
> Describe TMUs in the R8A779{7|8}0 device trees.
>
> Based on the original (and large) patches by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
>
> ---
> This patch is against the 'renesas-devel-20180906-v4.19-rc2' branch of
> Simon Horman's 'renesas.git' repo plus the R8A779{7|8}0 DT patch adding
> the CMT support).
>
> The R8A779{7|8}0 TMU DT binding update have been just posted...
>
> arch/arm64/boot/dts/renesas/r8a77970.dtsi | 66
> ++
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 66
> ++
> 2 files changed, 132 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -316,6 +316,72 @@
> resets = < 407>;
> };
>
> + tmu0: timer@e61e {
> + compatible = "renesas,tmu-r8a77970", "renesas,tmu";
> + reg = <0 0xe61e 0 0x30>;
> + interrupts = ,
> + ,
> + ;
> + clocks = < CPG_MOD 125>;
> + clock-names = "fck";
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 125>;
> + status = "disabled";
> + };
> +
> + tmu1: timer@e6fc {
> + compatible = "renesas,tmu-r8a77970", "renesas,tmu";
> + reg = <0 0xe6fc 0 0x30>;
> + interrupts = ,
> + ,
> + ;
> + clocks = < CPG_MOD 124>;
> + clock-names = "fck";
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 124>;
> + status = "disabled";
> + };
> +
> + tmu2: timer@e6fd {
> + compatible = "renesas,tmu-r8a77970", "renesas,tmu";
> + reg = <0 0xe6fd 0 0x30>;
> + interrupts = ,
> + ,
> + ;
Should GIC_SPI 306 also be here for TMU 2 channel 3?
And likewise for the r8a77980 (V3H)
The documentation seems inconsistent as I see this listed in the
interrupt controller documentation. But I do not see that channel
documented in the TMU documentation.
> + clocks = < CPG_MOD 123>;
> + clock-names = "fck";
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 123>;
> + status = "disabled";
> + };
> +
> + tmu3: timer@e6fe {
> + compatible = "renesas,tmu-r8a7797", "renesas,tmu";
> + reg = <0 0xe6fe 0 0x30>;
> + interrupts = ,
> + ,
> + ;
> + clocks = < CPG_MOD 122>;
> + clock-names = "fck";
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 122>;
> + status = "disabled";
> + };
> +
> + tmu4: timer@ffc0 {
> + compatible = "renesas,tmu-r8a7797", "renesas,tmu";
> + reg = <0 0xffc0 0 0x30>;
> + interrupts = ,
> + ,
> + ,
> + ;
Should GIC_SPI 369 for TMU 4 channel 3 be present not here for
the r8a77970 (V3M) but rather below for the r8a77980 (V3H) ?
As per my note above, the documentation seems inconsistent here.
> + clocks = < CPG_MOD 121>;
> + clock-names = "fck";
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 121>;
> + status = "disabled";
> + };
> +
> i2c0: i2c@e650 {
> compatible = "renesas,i2c-r8a77970",
>"renesas,rcar-gen3-i2c";
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -346,6 +346,72 @@
> resets = < 407>;
> };
>
> + tmu0: timer@e61e {
> + compatible = "renesas,tmu-r8a77980", "renesas,tmu";
> + reg = <0 0xe61e 0 0x30>;
> +
Re: [PATCH v2] arm64: dts: renesas: r8a779{7|8}0: add CMT support
On Fri, Sep 07, 2018 at 09:58:41PM +0300, Sergei Shtylyov wrote:
> Describe CMTs in the R8A779{7|8}0 device trees.
>
> Based on the original (and large) patches by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Thanks Sergei,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman
Re: [PATCH V2 RESEND] gpio: of: make example syntactically correct
On Sun, Jan 21, 2018 at 1:12 PM Wolfram Sang wrote: > The ';' was missing. And cosmetic: there was a space too much. > > Signed-off-by: Wolfram Sang > Reviewed-by: Niklas Söderlund > --- > > No changes since V2, only Niklas' tag added. Patch applied with Geert's ACK. Yours, Linus Walleij
